Fast Car
"So take your fast car and keep on driving", Tracy Chapman
An observant mybiketraffic user noticed that a fast car that passed him on a ride wasn’t reported on the website. The driver of a Ferrari had passed the cyclist at an astonishing speed of 102 mph (164kph) on a small country road in Michigan, but the car wasn’t there when he checked the mybiketraffic website for the car after the ride!
Not giving up hope, the mybiketraffic user wrote his own code to export the FIT file and look for the car. Lo and behold, he found it and sent me this screenshot:
So what happened?
Why wasn’t this 102 mph Ferrari reported on the mybiketraffic.com website? It’s all about thresholds. The original threshold I set for “counting” and “reporting” a car was 30m. In other words, if the radar didn’t pick up the car when it was within 30m, it wouldn’t be counted.
30m is still a good distance behind the cyclist. It’s close enough for many situations, but there are still a number of situations where the road can turn with the car disappearing off the radar before appearing again. This can lead to the car being counted each time the car re-appears and then subsequently disappears off the radar again. In an effort to prevent overcounting cars, I tightened the threshold to 10m.
The downside of that tightened threshold is undercounting fast cars. If a car is going more than 10 m/s (22mph) faster than the cyclist, there is a chance that it won’t get picked up in that sub 10m range. Most cars going 10-20m/s faster than the cyclist will still get a reading within the threshold, but not all. And clearly the faster speeds, the more likely there won’t be a reading inside the 10m threshold.
So what can we do?
Since I have both the range and speed of the approaching car, I can make the threshold depend on the speed of the car. I am already doing this for my lateral passing iPhone app, but I hadn’t thought to apply it to the ConnectIQ radar app until the mybiketraffic user emailed me this morning. Look for a new update soon in the Garmin ConnectIQ store!
But prior to working on that update, I have already updated the backend on mybiketraffic.com to allow the user to set their own threshold of which cars to count. Since the threshold now depends on both distance and speed, the configurable unit is now time. A mybiketraffic user will soon be able to specify the distance threshold as the number of seconds it would take the car to pass if they continued at their current speed. The default (and lowest value) is 1 second. Even at this lowest value, the Ferrari would not have been missed. The closest reading was 21m, but the car was traveling 36 m/s faster than the cyclist, 36 m/s * 1 second = 36 meters for the threshold. 21m is well within 36m, and thus, this car would have been counted.
Time as a measure of distance
The threshold values are still distance, but configurable via time per the chart below showing three different time settings (1s, 2s, and 3s). Here is the official threshold calculation formula based on the speed of the car and the user time setting:
Note, that I subtract 1m to reduce the odds of a car getting missed if the only reading was exactly at that distance (e.g., 10m/s car with 1s setting = 9m threshold). Also note that 9m is set as the minimum threshold distance no matter the speed of the car. And 49m is set at the maximum threshold distance even for significantly faster cars.
The impact of this setting is on which cars get overcounted or undercounted. There is always going to be a tradeoff. If you set the threshold too close then fast cars will be undercounted. If you set the threshold too far then slower cars or even medium paced cars on twisty roads will get counted multiple times. Plus, cars that turn behind you and never pass will get counted even though they didn’t pass.
So the best setting for the most accurate data depends on what type of roads the user rides the most. If they ride roads with really fast cars then they may want to use the green setting (3 seconds) to avoid missing those cars. But if they keep this setting and ride on twisty roads, slower cars will likely be overcounted to some extent. The exact amount depends on how busy the road is and how twisty the road is.
The Results
First, let’s look at a screenshot to find the Ferrari. Using the blue setting (1 second) was enough to find this very fast car, so I’m going to make this the user setting for the range threshold to 1 second. For this fast car which was traveling 36 m/s faster than the cyclist, 1 second means 35m threshold. The closest reading on the car was 21m, well within the threshold for the car to be counted.
Impact on car counts
Lowering the threshold distance means fewer cars will be overcounted, but conversely it also means that more fast cars, such as the Ferrari in this post, will be missed. While changing the algorithm for new rides and for map display is quick and easy, re-running the algorithm with the new threshold against all the rides from 12,000+ riders in 98 different countries is neither quick nor easy.
Unfortunately, I have run out of time to finish this analysis before leaving for my next grand adventure. See my next post, which will hopefully come from Canada in the next day or two. Learn more here: https://toonecycling.com/2025/06/08/a-canadian-american-data-adventure/
What about keeping all the raw data and doing the thresholding/filtering all server side?