Open m1geo opened 3 years ago
dtostrf() adds leading blanks if the number is smaller than the reserved field. This should be the nicer approach (diff):
@@ -439,6 +532,7 @@ void updatePosition() { // Convert and set latitude NMEA string Degree Minute Hundreths of minutes ddmm.hh[S,N]. char latStr[10]; int temp = 0;
char *p;
double d_lat = gps.location.lat(); double dm_lat = 0.0; @@ -452,11 +546,10 @@ void updatePosition() { }
dtostrf(dm_lat, 7, 2, latStr);
if (dm_lat < 1000) {
latStr[0] = '0';
}
// smaller numbers lead to leading blanks. Replace by '0', for correct aprs positions
for (p = latStr; p && p == ' '; p++)
*p = '0';
if (d_lat >= 0.0) { latStr[7] = 'N'; } else { @@ -480,13 +573,9 @@ void updatePosition() {
dtostrf(dm_lon, 8, 2, lonStr);
if (dm_lon < 10000) {
lonStr[0] = '0';
}
if (dm_lon < 1000) {
lonStr[1] = '0';
}
// smaller numbers lead to leading blanks. Replace by '0', for correct aprs positions
for (p = lonStr; p && p == ' '; p++)
*p = '0'; if (d_lon >= 0.0) { lonStr[8] = 'E'; } else {
When referring to the code converting to Lat/Long for APRS transmission, there is a bug. The code only covers when
dm_lon
is less than 1000, but, should be extended to include <100 and <10:https://github.com/lightaprs/LightAPRS-1.0/blob/82fba0337935b802f001e48789f66ba36653b793/LightAPRS-vehicle/LightAPRS-vehicle.ino#L282-L287
Otherwise, this causes cases similar to below, where you can see that the longitude has a space in it since the case where
dm_lon
is less than 100 (as 10.83 is) is not covered.I added a the following to resolve the issue:
There should probably be similar tweaks to the latitude, allowing for operation close to the equator - however, this is not an issue for me...
Cheers, George - M1GEO.