|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
#14
|
|||
|
|||
|
Re: TABLET FOR DRIVER STATION
Quote:
You can look at the numbers on the DS to see what the trip time is for small packets like the control packets. It is also pretty easy to make a latency tester to numerically measure it. 1. Use the dashboard PC to display a numeric indicator with a large font and the camera image. 2. In a loop, update the indicator every 5ms or so with the milliseconds value. 3. In a parallel loop, get the camera images and display in the image display. 4. Point the remote camera at the computer display. You now have a side-by-side display of the source time and measured time updating too fast to really see. 5. Take a screen-shot to freeze the display and you'll see that the camera image is delayed by x milliseconds compared to the source. You should do this a few times and plot the numbers you get. Keep in mind that the monitor will not display text to the screen when you tell it to, but on the next refresh, which is up to 10 or 12ms later. So you have jitter in your measurement, but the smallest number in your sample is a good estimate of the latency you'd see for a source that isn't a raster display. To time latency with a computer that doesn't have a display, you may need to flash LEDs or use a 7 segment display that you drive via digital lines -- get creative to drive a source, and do processing to measure what the camera sees. Determine how long in the past, the camera is accurately describing things. You can also have the source be something not controlled by the computer, but measured by it in different ways. You could have a pot or encoder connected to a pendulum, and measure the location of the pendulum with the camera as well and compare the latency of the camera measurement. My point is that I encourage you to measure the latency rather than assume one approach has it and the other doesn't. Greg McKaskle |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|