At my location, I am seeing very poor accuracy with specifically longitude. The values are bouncing around between +-60m of the true position, while the latitude is much more precise. I also see aliasing in the values, where they tend to line up in columns on the map. The issue is that there is not enough precision (meaning, not enough decimal places) in the values sent over BLE from the ground unit. For example, in my part of the world, the coordinates that I observe from the ground unit over a serial connection are typically something like (45.78341,-112.1404). Notice that the latitude has 5 decimal places, while the longitude only has 4.
This issue is caused by two precision issues in python. The first is that the format specifier for loko_string does not specific the floating point precision, so Python picks a variable number of decimals:
|
loko_string = f'{loko_data["id1"]},{loko_data["id2"]},{loko_data["lat"]},{loko_data["lon"]},{loko_data["vbat"]},{loko_data["alt"]},{loko_data["mps"]}' |
The second issue is that Micropython only uses single-precision floating point numbers, so precision is lost in the division in bin_unpack_lat_lon_32(...):
|
lat_lon = lat_lon_scaled / scaling_factor |
Because the coordinates are sent over BLE as a string anyways, it's possible to bypass both of these issues while retaining the full available precision sent from the Air unit by directly inserting the decimal point into a string representation of lat_lon_scaled and not doing any math to re-scale it. I have a pull request ready with this fix.
At my location, I am seeing very poor accuracy with specifically longitude. The values are bouncing around between +-60m of the true position, while the latitude is much more precise. I also see aliasing in the values, where they tend to line up in columns on the map. The issue is that there is not enough precision (meaning, not enough decimal places) in the values sent over BLE from the ground unit. For example, in my part of the world, the coordinates that I observe from the ground unit over a serial connection are typically something like
(45.78341,-112.1404). Notice that the latitude has 5 decimal places, while the longitude only has 4.This issue is caused by two precision issues in python. The first is that the format specifier for
loko_stringdoes not specific the floating point precision, so Python picks a variable number of decimals:Loko/Software/LokoGround Firmware/main_1.1.py
Line 663 in 5ae61c4
The second issue is that Micropython only uses single-precision floating point numbers, so precision is lost in the division in
bin_unpack_lat_lon_32(...):Loko/Software/LokoGround Firmware/main_1.1.py
Line 501 in 5ae61c4
Because the coordinates are sent over BLE as a string anyways, it's possible to bypass both of these issues while retaining the full available precision sent from the Air unit by directly inserting the decimal point into a string representation of
lat_lon_scaledand not doing any math to re-scale it. I have a pull request ready with this fix.