We're building a project to capture images from a Sony camera that outputs images over USB-C or Ethernet. For redundancy, we're feeding the images at high speeds to multiple MCUs running Linux, and are unsure how to inverse mux or split the image signal from one camera device to 3 hosts.

Here are the architectures I'm considering and my concerns with each- worth noting that all 3 would meet my data rate & timing requirements.

  • Camera USB-C output -> USB hub -> USB ports on MCUs: This was my 1st instinct, but as I understand it from this post, USB devices aren’t meant to talk to 2 hosts at once, i.e. the USB's underlying physical protocol doesn't let us treat the image as a signal to be 'split' to several MCUs that are all listening. Also raises the question of "how would the USB hub know which MCU(s) to forward the image to?"

  • Camera Ethernet output -> Ethernet repeater -> Gigabit Ethernet ports on MCUs: In theory, the repeater would listen for images and then instantly forward them to each MCU's Ethernet port. The drawback- for this particular camera model, Sony's SDK for MCU-to-camera handshaking only supports the USB physical layer, not Ethernet. So likely a no-go as our team insists on using the SDK.

  • Camera USB-C -> USB-to-MIPI CSI-2 bridge -> 1-to-3 splitter -> MIPI CSI-2 ports on MCUs: The MCUs have an MIPI CSI-2 interface in addition to USB and Ethernet. I've seen examples like this of bridging MIPI CSI-2 cameras (e.g. a RasPiCam) to other interfaces, but couldn't find much about the reverse: bridging to MIPI CSI-2. I would of course have to verify signal integrity after doing the 1-to-3 split. Here I would also be ditching the Sony SDK and instead reading raw bytes over CSI.

Image-sharing over a wireless network isn't a possibility since the system will live in an extreme, remote setting.

Before I start buying up equipment, I'd love to know if anyone has solved a similar problem, and any flaws with the 3 approaches I'm considering.

  • 2
    \$\begingroup\$ Can you explain how this is an electrical or electronic design question rather than just a question about buying the right equipment. Site rule: Questions on the use of electronic devices are off-topic as this site is intended specifically for questions on electronics design.. Another site rule about soliciting opinions: This question is likely to be answered with opinions rather than facts and citations. It should be updated so it will lead to fact-based answers. \$\endgroup\$
    – Andy aka
    Commented Nov 21, 2022 at 9:31

2 Answers 2


One solution is to send the packets in UDP using broadcast so every device will receive that, but not sure if the camera supports that.

You would have to configure everything with static IPs and through a HUB as a router would probably block this type of traffic.

The good part is that you can add/remove listeners without having to do any config on the broadcaster.

If the camera doesn't support that, you can probably do a bit of software to get the data and then broadcast. The advantage is that you'll use less bandwidth than sending two 3 devices with separate packets.

Second option is the broadcast still, but you could use a small embedded system like a raspberry pi to have the camera in USB, capture the images then broadcast them over UDP.


USB is one to one, so that doesn't work. Ethernet does support a broadcast mode (UDP) but it's questionable whether your camera will support it or can be hacked to support it.

You can look at a hybrid solutions using a primary/secondary architecture

  1. Connect the cameras via USB to one MCU which re-sends it via Ethernet to the others. Since you can control the MCUs that could be done in UDP with a single transfer or with TCP in multiples ones.
  2. Same as option one, but use Ethernet as the interface between the camera and the MCU. You maybe able to just rebroadcast the Ethernet packages to he secondaries at the driver level, which would keep the CPU load low on the primary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.