Azure-kinect-sensor-sdk: Triggering Azure Kinects externally using 3.5mm audio cable (using RPi etc)

[this-username-is-taken]

Is your feature request related to a problem? Please describe.

I'd like to have an external device trigger Azure Kinects and control the triggering time. For example, extend an 3.5mm audio cable from a RPi or Arduino and connect to Azure Kinects (all in slave mode). Essentially, the RPi/Arduino will act as master and trigger the Azure Kinects.

Describe the solution you'd like

I'd like to know what the triggering sequence is. In other words, what signals I should send through the 3.5mm audio cable in order to trigger an Azure Kinect capture.

[wes-b]

Good idea, I need to gather info about this.

[tesych]

1. The SYNC signals are active high and pulse width should be greater than 8us.
2. We currently support 30, 15 and 5 fps, so frequency of master VSYNC signal from your board (developed to generate signal) should also be one of these 3.
3. Kinect DK 1 should be connected to your board, Kinect DK 2 to your Kinect DK 1 and Kinect DK 3 to your Kinect DK 2, say daisy-chain.
4. SYNC signal from the board should be 5V TTL/CMOS with maximum driving capacity no less than 8mA.
5. The below plugs can be used with Kinect DK, and all sleeves and rings are shorted together inside Kinect DK and they are connected to ground of master Kinect DK. Tip is the sync signal.

[tim-depthkit]

Would the Azure Kinect respond poorly to a sync signal produced at a broadcast frame rate, such as 29.97?

[TomHVR]

Maybe look into this hardware to convert the signals?

https://www.canford.co.uk/Products/90-3029_LYNX-YELLOBRIK-SPG-1707-SYNC-PULSE-GENERATOR-3x-HD-tri-level-3x-SD-bi-level-genlock-input

[wes-b]

@tesych is this done?

[jmarkow]

Hopping on this thread for something related. I'd like to sync external equipment with the Kinect. If I activate the SYNC OUT port on a Kinect, what signal is sent out exactly (pulse width, voltage, etc.) and how does that signal relate to the timing of each frame?

[wes-b]

The signal is the subordinates VSYNC. You can use subordinate_delay_off_master_usec set a delay or deliver the pulse immediately.

[neurojaym]

Hey all, jumping onboard with some more information and questions regarding external device control of a Kinect Azure (all on Windows 10 Pro, SDK v1.3.0). I've been trying to control the K4 with an Arduino Mega2560 microcontroller. I'm sending out a fixed number of 1ms, 30Hz, >5V pulses from the arduino to the sync-in port on the K4 which is designated as subordinate.
Workflow is as follows:

1. Go to command line and type k4recorded.exe -l 5 --external-sync sub <filepath> for a 5 sec recording
2. The cmd line prompt shows: device info, device started...[subordinate mode] Waiting for signal from master...
3. Program stalls and waits
4. I hit the start/reset button on my arduino microcontroller which begins 30Hz pulsing for 5s (verified by LED)
5. Recording automatically stops on k4 and saves the correct 5s/150frame .mkv file

However, I tried to break my own system as a check for robustness and noticed the following: if I designate the k4recorder file to be longer, say 10 seconds [-l 10 in cmd line], while maintaining a 5s pulse train from the arduino, I notice that the recording still starts at the designated time (when I start the Arduino) but records a full 10 seconds, despite only 5 seconds of Arduino-generated pulses, suggesting that subordinate k4's don't actually listen to individual pulses coming in from an external "master", rather they rely purely on their own hardware to record and only "listen" to the opening pulse to timelock signals across daisy-chained components. @microsoft, is this a correct interpretation of what might be happening here? Could you please provide some more insight regarding how subordinate k4's read in information from the 'sync in' port? Thanks very much!

[wes-b]

Correct, while the subordinate will wait for the first pulse from master, the subordinate no longer needs to pulse to take samples N+1 and beyond. The pulses do need to stay periodic and matched as that is how the 90KHz clocks between the two devices are resynchronized to help avoid drift.

[tesych]

documented in Multi-camera sync article.