Suggestion for improving telemetry track position lag

sbarton · Post by **sbarton** » Wed May 22, 2013 5:24 pm

From what I understand there is a lag in the telemetry showing the track position vs where they really are, due to receiving the data to the web server, processing the data, and then sending it out the the web browser and rendering it.

An idea to improve this is to use a predictive lap timing algorithm and use the last lap as a reference lap and the latest gps location received to predict current actual location on track.

ie if the latest update was that they were at the apex of T7 and the timestamp on that update was 1.2 seconds ago, based on the last lap, they would have traveled X distance in that 1.2 seconds, and therefore show the car as being in that location, not still back at T7.

-Scott

sbarton · Post by **sbarton** » Wed May 22, 2013 5:25 pm

In the meantime, is it possible to show the estimated lag time on the map? That way you can at least have a good guesstimate of where they actually are right now.

-Scott

dimondjack · Post by **dimondjack** » Wed May 22, 2013 6:23 pm

Scott,

I noticed this as well, however I noticed that the lag would get considerably worse over time. I'd be very happy with a 1-2 second lag (or even 5 seconds) so long as it was consistent. Refreshing the webpage would bring the lag down to around a second (or something), but then it would start climbing again over the next hour.

What do you want to have the predictive information for?

David

sbarton · Post by **sbarton** » Wed May 22, 2013 6:32 pm

I'd just like to have an accurate idea of where my car is on track for a variety of reasons. Are they in a location I know is within range of our radios (ie, would it be pointless to try to communicate with them right now)? How long before they would get into the pits if I call them in now? How far from Start/Finish are they? How soon until they come around to where we can see them (ie if we are pitted/standing in some weird location of the track and want to watch them drive by).

Predictive lap info? Most loggers have this feature (at least as part of their display). It could be used to provide feedback to the driver (ie as a coach to provide feedback if they don't have a right seat in the race car). Could also be used to let them know they are on a flying lap if qualifying. Would be cool to write a script that says if this is the currently the predicted fastest lap, trigger a light on the dash so you know this is your flyer. Tons of uses I guess.

-Scott

rdoherty · Post by **rdoherty** » Wed May 22, 2013 6:52 pm

Thanks for the notes on where/how you're seeing latency, it's a tough problem as cell phone networks are notoriously variable in latency, bandwidth, etc.

I'll note that refreshing the browser fixed the problem, that will help use debug.

blalor · Post by **blalor** » Wed May 22, 2013 6:56 pm

Those are great use-cases to know about. @diamondjack we haven't observed increasing delays in the client (hard to when you're a thousand miles from the race car…), but we'll do some investigation. If you notice that in the future, please try reloading the page and see if the delay decreases. If so, we may have a bug.

We *do* know that there are delays between when the data is sent from the car to the server. The cellular networks seem to have a fair bit of built-in latency, and we are going to experiment with ways to reduce that, including testing AT&T vs T-Mobile at the same time. If you have your RCP configured to send the GPS time, we use that to measure the approximate time that it took for the data to leave the car and be received by the server. That's more internal metadata that we're collecting for future analysis and quantification.

If you happen to be a network engineer for AT&T, Verizon, T-Mobile, Vodafone, Rogers, or any of the other carriers and want to help us tune, please speak up!

sbarton · Post by **sbarton** » Wed May 22, 2013 6:59 pm

Ryan so a lot of the latency issues is in the cellular data rate? Looking at T-Mobile's coverage, most of the race tracks are located in 2G zones so I can see that.

Can you transmit via telemetry less data points then you are actualy logging to the SD card? That could reduce the data sent. ie Don't send any of the sensors recording over 10Hz, or any other sensors you really don't need to see via telemetry. Would that also reduce latency times?

-Scott

sbarton · Post by **sbarton** » Wed May 22, 2013 7:05 pm

Brian, if we send GPS time, can you do a calc right before you send the data to the browser to show the latency? That would be a huge benefit as you could then have a good chance of guesstimating correctly where the car actually is right now. Also would be useful to help us help you guys debug as well as know when we should refresh the page if latency gets too high. or better yet, script into the web page to aut-refresh when latency gets above x.

Also how are you synching GPS time to server time?

-Scott

dimondjack · Post by **dimondjack** » Wed May 22, 2013 8:41 pm

Brian,

While racing at NHMS refreshing the page definitely reduced the delay. It seemed like the delay would build up to being as much as a minute, but didn't always build up at a constant rate. For example, some times we logged for 10 minutes and the delay became unbearable, some times it took an hour or more. When first refreshed I could see where the car was in real time within a few hundred feet on the main straight.

We didn't like refreshing as we lost all lap time data via telemetry. It wasn't a big deal, but we didn't take the time to write down best laps per driver, sectors, etc.

sbarton · Post by **sbarton** » Wed May 22, 2013 9:00 pm

Is there a way to export that data from the browser?

-Scott

rdoherty · Post by **rdoherty** » Wed May 22, 2013 9:21 pm

@dimonjack We have since added loading previous lap times to the live dashboard, it will work for new events

There is also the data logged to the SD card which you can use to do further analysis.