Error when Longitude or Latitude is Negative!

Bugs-requests
1

I’m working with v 5.6.15 and getting Panda going over TCP and found a bug in conversion of Lat and Lon from the NMEA sentence to the dd.dddd format displaced on the screen. Also replicated the error in v5.5

In North America, so longitude it negative. South America will have problems with both.

In bench testing, I noticed that the longitude shown in Agio was off from actual. After looking at the results, it appears that the NMEA string conversion is not handling the negative properly. -08142.283464 (-81 Deg, 42.28464 min) should convert to -81.7047244 in decimal degrees. AGIO shows -80.2952756. It looks like the negative isn’t being handled correctly. Looks like it’s taking the -81 deg integer part and adding 42.28464/60 = .7047244 to the -81 for the result of -80.2952756!

When Longitude is negative, I find it easiest to strip the negative sign off, do the conversions, and then multiply by -1 to add it back into the decimal form. Also, to tested the theory by sending a negative latitude. Replicated the same problem.

Lon Error question

2

if there was a negative Lat or Lon, that may be a bug, but as far as I know there isn’t. That is what the NS and EW designation are for.

South and West denote a negative Lat or Lon and are post multiplied by -1 if they are.

We may have a problem with Panda code if it is sending a negative Latitude or Longitude.

Quick question, where did you get the negative (-08142.283) from ?

3

DOH! I’m working on taking the UBX PVAT sentence in UBX format and building it into a PANDA to send to agio. The negative came from the ubx format. Didn’t realize that in NMEA gga, etc they were unsigned and used the NESW designation. Easy enough to strip the negative and use the correct directional. Thanks!

1 Like