You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @zacharyedwardbull, thanks for putting together the library and @tensorturtle for adding radar support. I wrote a little hobby application (https://github.com/maciejwie/radar-logger) using your work this weekend and it was (mostly) pretty painless. Good news is that I can add a datapoint that the RTL515 works.
One issue I ran into was around the accuracy of the data returned by the sensor, which consistently read high. For example, detected pedestrians are reported as moving at 10-11 km/h where a more likely value is ~5 km/h. I also asked someone to drive at consistent and known speeds and the data there as well was pretty consistently 5 km/h high.
Below are some data I collected using my application. The data section is a list of [speed, distance] tuples. All of the speeds also fall off as the vehicle gets close to the sensor but I believe that's just behaviour of the radar.
In your testing, did you see something similar? I added calibration parameters on my end to handle this, but am wondering if it's something that affects more people upstream.
Hi @maciejwie thanks for your kind words and your project looks exciting! Unfortunately I did not do any meaningful speed accuracy testing. I think you're probably right about threat_id.
Hey! Thanks for doing this detailed investigation and writeup. Sadly I don't have a radar so I haven't been able to do any work on this myself. If you work out what needs updating please create a CL and I'll merge it in!
Hi @zacharyedwardbull, thanks for putting together the library and @tensorturtle for adding radar support. I wrote a little hobby application (https://github.com/maciejwie/radar-logger) using your work this weekend and it was (mostly) pretty painless. Good news is that I can add a datapoint that the RTL515 works.
One issue I ran into was around the accuracy of the data returned by the sensor, which consistently read high. For example, detected pedestrians are reported as moving at 10-11 km/h where a more likely value is ~5 km/h. I also asked someone to drive at consistent and known speeds and the data there as well was pretty consistently 5 km/h high.
Below are some data I collected using my application. The
data
section is a list of[speed, distance]
tuples. All of the speeds also fall off as the vehicle gets close to the sensor but I believe that's just behaviour of the radar.Pass 1, vehicle traveling at 30 km/h. Data:
Pass 2, vehicle traveling at 20 km/h. Data:
Pass 3, vehicle traveling at 35 km/h. Data:
Pass 4, vehicle traveling at 40 km/h. Data:
In your testing, did you see something similar? I added calibration parameters on my end to handle this, but am wondering if it's something that affects more people upstream.
I also looked at how other projects handle this. The only open ones which uses BLE (most use ANT+) I found is OpenWorkoutTracker and they don't use the speed bytes at all and instead calculate them using distance and time. See: https://github.com/msimms/OpenWorkoutTracker/blob/4c42b61c5169208026d0d9aaa794079a05d2296e/IOS/Sensors/BtleDiscovery.m#L283 and Tacho (https://github.com/Wunderfitz/harbour-tacho/blob/cc7e23ab7c97a11d32acbf7688ed5233060d7dba/src/variaconnectivity.cpp#L161) which uses the values as-is like we do.
MyBikeTraffic is a CIQ app which uses the Garmin API (which returns m/s for speed) and also uses it as-is (after converting to km/h or mph): https://github.com/kartoone/mybiketraffic/blob/4af398d180085f58dd0aa3bd2c695ee6def5ddb4/source/MyBikeTrafficFitContributions.mc#L126
There is also closed-source ARadar on watchOS which should also use BLE (https://robertoviola.cloud/2022/05/27/garmin-varia-on-apple-watch-finally/ ) and who may also have some insight or experience with it.
I think the
threat_id
is also not quite right and I only saw values between 128 and 191, so it seems like only the bottom 6 bits are used for this. Not sure what the upper 2 bits might be. The ANT+ documentation (https://developer.garmin.com/connect-iq/api-docs/Toybox/AntPlus/RadarTarget.html) references 2-bitTHREAT_SIDE
andTHREAT_LEVEL
(https://developer.garmin.com/connect-iq/api-docs/Toybox/AntPlus.html#ThreatLevel-module) but those may go in byte 0.Don't have any patches to submit, just looking to compare notes right now.
The text was updated successfully, but these errors were encountered: