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.