Synching two Teensy 4.0

R

robedney

Active member
I've done some searching and research on this, and I've come back confused. I want to measure the latency in a video broadcast system at various distances (for FPV drones). It's easy to do on the bench using one Teensy. An LED and a light sensor are connected to the Teensy. The LED is placed in front of the camera lens, and the sensor is taped to the OLED display. Pushing a button tells the Teensy to turn on the light and capture the time. Once the light is turned on and the time captured, the Teensy waits for the sensor to see the light and captures that time. The difference between the two is the "on bench latency" (after the system is initially calibrated). This measurement is used to evaluate the efficiency and speed of the video transmitter and receiver.

What I want to do next is to measure the latency at fixed distances, like 100 meters, 200 meters, etc. The solution I've thought of is to use two Teensys. The first is connected to the light sensor, while the second is connected to the LED. These two can be separated by any give distance. In order for this to work I need to initially synchronize the "clock" on the two Teensys. The anticipated readings are between 30ms and 100ms, so I need to be accurate to within perhaps 3 milliseconds (more or less). Is there an easy way to do this, and do you think it would be accurate enough???
 
I think you could come up various ways of connecting the two Teensys, so the button signal that turns on the LED actually goes to both Teensy via RS-485, which is good for the types of distances you're talking about. There would be some small latency, but the "receving" Teensy would have both the start time (via the button) and the end time. Another solution would be to have a GPS on each Teensy so that even though the Teensys are not connected, you can get an accurate absolute time via the PPS signal. Those should be accurate to much better than 1 ms, perhaps even 1 us. That's more elegant, but a bit more complicated to compute an absolute time between PPS pulses.
 
That all interesting, particularly the GPS idea, but I'm looking for something simpler. Perhaps I've not been clear? I want to start the two Teensys and then "pair" them so that they both have the same starting time. The Teensy with the LED will then be manually triggered and capture the time. The Teensy with the light sensor will trigger when the light is detected and capture the time. The LED "on" time will then be subtracted from the sensor "detect" time and the result will be the latency.
 
The idea would be that you use the GPS signal as a clock source to ensure they are synchronized (GPS isn't only useful for location).

Could you measure the round-trip latency instead? So one Teensy would signal the other, which would then signal back? Then they wouldn't need synchronized clocks at all.
 
In the setup I've described there is no way to signal back and I'm trying to keep things simple. How about this idea: Both Teensys run the same stopwatch sketch and I use a display on each to show elapsed time. Before making the measurement, the two are tethered together with a button in the tether cable. They can then be separated. Pressing the tether button triggers whatever pin is used to start the timer simultaneously in both Teensys, and they are now running the same sketch. Assuming the button press is clean (debounced, etc.) this ought to work. To test and calibrate, the same button could be used to "stop" the timers together and the results checked for consistency. The question is how accurate would it be.
 
I don't know what you mean by tether, or running the same sketch, but assuming you get the signals to do what you want, there might be minor differences in the start times and minor differences in the clocks on the two Teensy, but those should be microseconds, not milliseconds, over these relatively short measurement times.
 
Thanks! What I mean by tether is that I temporarily run a jumper to the same digital pin on both Teensys (and ground of course). The button then connects ground to both pins at the same time, so they start same sketch on both Teenys simultaneously (that sketch basically being an interval timer).
 
If you use the same 100 meter setup on the bench (now in close proximity between radio transmitter and receiver), and there's no re-syncing of the video broadcast over the air waves, the 100 meter separation test is only introducing a latency at the speed of light, 300km/ms (approximately, we're not dealing with a vacuum). This latency should be insignificant. So, a bench test should have similar result as field separation testing. A separation of 300km would introduce 1ms of latency.

Have you seen issues with this previously, or is this a first time experiment?
 
Thanks, BillFM, for pointing out the obvious! You're right, latency on the bench should pretty much match latency at a reasonable distance and this idea of mine is actually silly. I got here by reading comments in the FPV flying world that go something like "yeah, but that's latency on the bench -- what about the real world?". Well, physics is hard to deny, and so long as you've got the video signal physics dictates that real world latency will pretty much match bench latency. Part of the confusion around this is that some of the HD video systems have packet error checking, in that if the receiver thinks it's not gotten a packet it will ask the transmitter to resend it. This results in better video, but also creates variable latency, etc. But that's not "real" latency, it's an artifact of the way the system works. Anyway, thanks for the reality check!
 
I thought your single Teensy latency measurement method was pretty cool.

You might want to implement the 2x Teensy latency measurement (on the bench) just for a bit of self-satisfaction. You've already spent the time thinking about it.

If you want to watch packet thru-put go down the tubes, operate an old electric drill near the receiver. It's a good test to see how well the packet protocol recovers (or doesn't).
 
You must log in or register to reply here.
Back
Top