Closed dl9sau closed 1 week ago
Thank you Thomas, have you tested your fix with a pico balloon launch? If you think your fix is working for other locations, you can create a pull request.
Hello Mustafa,
Am 03.10.2021 um 14:53 schrieb Mustafa Tan @.***>:
Thank you Thomas, have you tested your fix with a pico balloon launch?
I've testet it on the ground and I verified it by entering various gps locations by hand.
I also proved the rounding problem at 59.9999 with dtostrf().
Btw, upon request of dg4nob (who is very active in pico ballooning), I implemented the WSPR S4 encoding extension (https://qrp-labs.com/flights/s4.html) I also implemented WSPR type2 and type3 messages, HF band hopping (according to "local time" of current longitude), etc..
During the last weeks, I spent time for FT8 position/telemetry encoding. I hoped, pskreporter.info will show my sent locations and telemetry - but unfortunately, it doesn't. -> This is still work in progress.
$ git diff LightAPRS-W-pico-balloon.ino | wc -l 2431 ;)
I liked to show you what I've done, but I've not found your E-Mail contact.
An other interesting option is the js8call mode (i.e. their aprs positioning format); js8cll also has many listeners around the world. Unfortunately, there's no embedded controller library available. I asked the developer for some info; I still hope he'll answer. Reverse-engineering would be a hard job (complex code, much fortran and c++ wrappers, lack of documentation).
If you think your fix is working for other locations, you can create a pull request.
ok
vy 73,
you contact me via support@lightaprs.com
updatePosition uses dtostrf for ggmin.nn lat/lon encoding. Imagine we're at 53 deg, 59.99 min north. -> Everything is still fine. The used dtostrf() does, like sprintf("%5.2f", ..) function, does upounding. This is ok, because at 53.3096 minutes, we are closer to 53.31 than to 53.30.
It fails, if our position is 59.996nnnnnnn. Then minute is rounded to 60.00, and our position at 53° 59.996min north (with aprs notation 5399.99N) will become 5360.00N. In this case, we do not really need to change degrees to 54 and minutes to 00.00. It's enough to assert 53.99nnnnn will not become 60.00.
Ugly fix:
===
dtostrf() has some other limitations. I.e. dtostrf(dm_lat, 7, 2, latStr); for dm_lat 5301.23 (53 degrees) is ok, but for 901.23 (9 degrees), the resulting string will be " 901.23" (leading blank). The unavailable sprintf("%07.4f", ..) is better in this.. ^space You mitigate that problem with
But what's up with 0 degrees? ;)
If fixed this with
Furthermore, I strongly recommend to terminate the string in pos 8 (latStr) and pos 9 (lonStr):
===
Better approach:
I stumbled over this extension // APRS PRECISION AND DATUM OPTION http://www.aprs.org/aprs12/datum.txt ; this extension should be added at end of beacon message. .. and needed to prevent unexpected rounding.
I avoided dtostrf and rounded for myself, in a precision I needed:
=>
My updateTelemetry() (where I moved updatePosition() to) ends with
For debuging purposes and prove everything is precise, I added
sprintf(telemetry_buff + strlen(telemetry_buff), " debug: %lu %lu", (uint32_t ) gps.location.rawLat().billionths, (uint32_t ) gps.location.rawLng().billionths);
and saw those correct reports (s. findu.com):