GPS Async template not decoding Longitude correctly

[David Ferguson]

I have a customer who has an NMEA-compatible GPS sending data through a MoTeC STC to his EDL3.

He is getting GPS data, but the GPS Longitude is coming out positive even though he is in the western hemisphere. It seems like the decode of the ",W" is missing. What is unique about his GPS, is that the Latitude & Longitude values have 7 digits after the decimal point (I've only see 2-4 on other GPS receivers). A bug perhaps?

Here is an example NMEA sentence:

$GPRMC,152454.36,A,3859.9593406,N,07711.6700646,W,0.151,125.1,240118,0.0,E,A*2B
So the Latitude DDMM.MMMMMMM should be 3859.9593406,N
and the Longitude DDDMM.MMMMMMM should be 07711.6700646,W

We are unable to fix this in the comm template ourselves, or with a dash math channel. That is likely due to the double-precision nature of GPS Lat/Long values.

Anyone else had this problem?

[adrian]

I believe it isn't working because the lat and long values in this case are both larger than 32bits (you'll probably find if the lat was 'South' then it would give you the wrong value as well). When I tested that string with 2dp less precision it works correctly.

I'll add a feature request to ignore the extra precision so that you at least get the correct values. There isn't any way we could actually handle 64bit lat/long coordinates.