why
OAK camera in general is currently lacking easy approach to camera syncing, which does limit device usage when it comes to the setups requiring precise Frame Syncing. FSync input is in fact already present on the OAK-D-Pro-PoE cameras and is possible to sync and trigger frames on multiple cameras at the same time with 12V externally generate pulse as described in the docs here .
What gives you hard times is not great UX, meaning syncing the cameras out of the box either by daisy chaining multiple OAK cameras or connecting of the shelf Genlock generator to it is not possible.
Reasons are that the FSync pin on M8 connector is input only which does eliminate first option, second is M8 connector itself, which is not a known standard among the Genlock generators where BNC and DIN 1.0/2.3 seems to prevail.
Due to the written reasons Luxonis decided to take two separate paths solving Syncing issue, one being FSync Y-splitter and other Sync BOX (names to be revised).
First steps were already taken exposing additional M8 connector on our PoE devices, and with newly introduced OAK-D-SR-PoE #244 (EA samples available in May) we did already take care of the device side revising the M8 connector removing unnecessary isolation, adding additional GPIO and additional capability of internally MUXing multiple IOs to single connector pin.
what
Design an "accessory" that allows:
Connecting multiple Luxonis cameras in daisy chain, one of them being FSync master (named FSync Y-splitter)
Connecting multiple Luxonis cameras in daisy chain, where the externally connected Genlock generator provides Sync signal and LTC information
Device side:
Input/output pins will have 5V TTL characteristics without overvoltage protection.
Latest pinout:
FSync Y-splitter features following:
Female M8 --> M8 Female & M8 Male signal splitter
automatic definition of Master/Slave setup configuration
enables daisy chaining with use of Luxonis M8 pin F/M cable
same IP rating as OAK-D-Pro-PoE
SYNC BOX features following:
out of the box daisy chaining with coaxial cable
Genlock generator connectivity
Both LTC and FSYNC read is possible on RVC3 while RVC2 devices will originally support FSync only
reliability for long cables installations in harsh industrial environment
passing through USB2, STROBE, 2x GPIO controlling other accessories
IP rated
how
We haven't yet pinned down all the details mostly missing them for SYNC BOX as we are in pre-development phase still, but some specs can be shared already and more will follow later while project matures.
FSync Y-splitter
All cameras will have to be hardwired together, in that case a way to define FSync Master device would be embedding PD (pull-down resistor) into one side of the Y-Adapter/cable on a floating IO2 pin (used for master/slave identification) so that the PD gets effectively connected to the Slave FSync device only after using a cable. This should always enable only one master in the daisy chain either Master FSync being the "left/first" or "right/last" device.
SYNC BOX
BOX will be an accessory offering additional features aside from the ones already supported with the Y-splitter. BOX will be nicely designed accessory being as small as possible offering good options when used in space constrained environments as robotics normally always is.
IP rated connectors and enclosure including multiple mounting options; like mounting to wall, pole,... (specifics to be defined) is something that will be taken care of.
In terms of functionality default configuration will always be FSync, meaning that whenever the OAK is connected to the SYNC BOX it can expect FSync signal being ingested into the device. Anything on top of that are permutations we would enable later after we validate the basic functionality and as need be:
perm1: FSYNC acts as an input routed indirectly through KB/MX to CCMs in case of additional functionality is needed i.e. staggering frames in case of ToF
perm2: LTC being ingested through M8 (MUXed IOs to I2S) using external LTC generator
Renders coming later once we fully dive into the design.
Sharing prematurely with a intention that we can get some feedback from the market which could potentially effect specs and improve the products.
why
OAK camera in general is currently lacking easy approach to camera syncing, which does limit device usage when it comes to the setups requiring precise Frame Syncing. FSync input is in fact already present on the OAK-D-Pro-PoE cameras and is possible to sync and trigger frames on multiple cameras at the same time with 12V externally generate pulse as described in the docs here . What gives you hard times is not great UX, meaning syncing the cameras out of the box either by daisy chaining multiple OAK cameras or connecting of the shelf Genlock generator to it is not possible. Reasons are that the FSync pin on M8 connector is input only which does eliminate first option, second is M8 connector itself, which is not a known standard among the Genlock generators where BNC and DIN 1.0/2.3 seems to prevail.Due to the written reasons Luxonis decided to take two separate paths solving Syncing issue, one being FSync Y-splitter and other Sync BOX (names to be revised). First steps were already taken exposing additional M8 connector on our PoE devices, and with newly introduced OAK-D-SR-PoE #244 (EA samples available in May) we did already take care of the device side revising the M8 connector removing unnecessary isolation, adding additional GPIO and additional capability of internally MUXing multiple IOs to single connector pin.
what
Design an "accessory" that allows:Device side: Input/output pins will have 5V TTL characteristics without overvoltage protection. Latest pinout:
FSync Y-splitter features following:
SYNC BOX features following:
how
We haven't yet pinned down all the details mostly missing them for SYNC BOX as we are in pre-development phase still, but some specs can be shared already and more will follow later while project matures.FSync Y-splitter All cameras will have to be hardwired together, in that case a way to define FSync Master device would be embedding PD (pull-down resistor) into one side of the Y-Adapter/cable on a floating IO2 pin (used for master/slave identification) so that the PD gets effectively connected to the Slave FSync device only after using a cable. This should always enable only one master in the daisy chain either Master FSync being the "left/first" or "right/last" device.
SYNC BOX BOX will be an accessory offering additional features aside from the ones already supported with the Y-splitter. BOX will be nicely designed accessory being as small as possible offering good options when used in space constrained environments as robotics normally always is. IP rated connectors and enclosure including multiple mounting options; like mounting to wall, pole,... (specifics to be defined) is something that will be taken care of.
In terms of functionality default configuration will always be FSync, meaning that whenever the OAK is connected to the SYNC BOX it can expect FSync signal being ingested into the device. Anything on top of that are permutations we would enable later after we validate the basic functionality and as need be: perm1: FSYNC acts as an input routed indirectly through KB/MX to CCMs in case of additional functionality is needed i.e. staggering frames in case of ToF perm2: LTC being ingested through M8 (MUXed IOs to I2S) using external LTC generator
Renders coming later once we fully dive into the design. Sharing prematurely with a intention that we can get some feedback from the market which could potentially effect specs and improve the products.