GNSS device not showing Longitude (ublox USB)

[bsimmo]

Problem

Longitude on a common GNSS device is not being reported.

Setup

A Ublox8 (m8030) Seen as ttyACM0 on PiZero. PiZero, Buster PiOS

Normally Works

Works fine with my own code with either pynmea2 off the serial port or gps3 with gpsd or gpsmon etc.

More Details

Longitude is not showing up, I've updated pip modules, OS and RPIEasy from within RPIEasy and rebooted.

Log

14:38:09 Event: > GNSS#Longitude=0.000000 14:38:09 Event: GNSS#Latitude=53.757545 14:38:09 Event: GNSS#Altitude=18.1 14:38:09 Event: GNSS#Speed=1.7 14:38:10 Event: SDS#PM25=1.6 14:38:10 Event: SDS#PM10=3.7 ... Snipped similar lines GNSS#Longitude=0.000000 14:38:26 Event: GNSS#Latitude=53.757527 14:38:26 Event: GNSS#Altitude=21.0 14:38:26 Event: GNSS#Speed=0.8 14:38:26 Event: SDS#PM25=1.8 14:38:26 Event: SDS#PM10=3.0

Edit remind me not to report these from OpenHUB android app, royal pain in the....

[enesbcs]

Standard GPGGA line looks like this: $GPGGA,190230.000,3358.5158,N,11718.6422,W,2,08,0.92,342.3,M,-32.9,M,0000,0000*5E

I've found the u-blox6 manual which shows this example: $GPGGA,092725.00,4717.11399,N,00833.91590,E,1,8,1.01,499.6,M,48.0,M,,0*5B

It looks like (at least the u-blox6) uses the same standard NMEA sentences.

As i do not have such a device (ublox8), could you please send the serial data, that your ublox sends?

[bsimmo]

I'll grab you some when I can but it is nmea v4.10 and will need to pick up GN TalkerID preferably. Pg 138 of a big ublox 8 manual

My guess is it's parsing in an older format for trailing zeros maybe? But I've not looked in the code, a move to a well use pynmea2 module that's had quite a bit of development may help at some point. No idea how you integrate them as plugins though. Can we get PPS for time to, I cannot see the option.

On Mon, 8 Mar 2021, 5:18 pm Alexander Nagy, notifications@github.com wrote:

As i do not have such a device, could you please send the serial data, that the ublox sends?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/enesbcs/rpieasy/issues/222#issuecomment-792917287, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYAXN4BTHO4RWSSHEDIGEDTCUBIFANCNFSM4YZRA2QQ .

[enesbcs]

I'll grab you some when I can but it is nmea v4.10 and will need to pick up GN TalkerID preferably. Pg 138 of a big ublox 8 manual My guess is it's parsing in an older format for trailing

I found this manual: https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf

The example GGA code is this:

$GPGGA,092725.00,4717.11399,N,00833.91590,E,1,8,1.01,499.6,M,48.0,M,,0*5B

Which is parsed by RPIEasy as: {'strType': '$GPGGA', 'fixTime': '092725.00', 'lat': '4717.11399', 'latDir': 'N', 'lon': '00833.91590', 'lonDir': 'E', 'fixQual': '1', 'numSat': '8', 'horDil': '1.01', 'alt': '499.6', 'altUnit': 'M', 'galt': '48.0', 'galtUnit': 'M', 'DPGS_updt': '', 'DPGS_ID': '0'}

After conversion to signed decimal: Latitude: 47.285233166666664 Longitude: 8.56526

But I've not looked in the code, a move to a well use pynmea2 module that's had quite a bit of development may help at some point. No idea how you

Could be done. But parsing done internally in 100 lines, instead linking to an external library.

Still need the exact line which fails to parse.

[bsimmo]

I think it's your dm_to_sd() that's failing

If you run 'lon': '00833.91590' through it is works, if you run 'lon': '00033.91590' which is similar to mine iirc it fails with a NoneType so fails the try returning 0

[enesbcs]

You are right, the regex failed when value resulted near zero. Fixed in commit https://github.com/enesbcs/rpieasy/commit/39029d5f24646b60bac6595a3e4252302a1cb996

[bsimmo]

you seem to have a lot of recasting of variables for no reason.

for example I think you get 'lon' as strings from the NMEA sentence, then cast it to float for noreason, then on the next line send it as a string into the function. Also the indenting is a nightmare to follow ;-) and now in dm_to_sd you are converting a string into a string.

Anyway i'll test in the morning as the battery on here is flashing at me. :-)

[enesbcs]

you seem to have a lot of recasting of variables for no reason.

Python variables can be anything, and i am actively using this feature. :D

for example I think you get 'lon' as strings from the NMEA sentence, then cast it to float for noreason, then on the next line send it as a string into the function.

It has a reason, as it casted float to make a division, as string can not be divided. It is converted back to a string, as every variable in tasks are stored as strings globally. First i tried to store floats, but it didnt worked well with every tasks, so i changed it to strings.

and now in dm_to_sd you are converting a string into a string.

Just for sure. It enforces to be a string for the input, in case it is not. In python anything can be the input. :) There are no harm if we convert a string to string, but adding a string to a float will raise errors.

[bsimmo]

It can be anything, but only at the input and you check to make sure, after that you have already set it, they don't magically change, it just uses up memory and time :-)

If I get time, I'll tidy it up. I might work out how you're making plugins too.

On Tue, 9 Mar 2021, 6:16 am Alexander Nagy, notifications@github.com wrote:

you seem to have a lot of recasting of variables for no reason.

Python variables can be anything, and i am actively using this feature. :D

for example I think you get 'lon' as strings from the NMEA sentence, then cast it to float for noreason, then on the next line send it as a string into the function. It has a reason, as it casted to float to make a division, as string can not be divided. It is converted back to a string, as every variable in tasks are stored as strings globally. First i tried to store floats, but it didnt worked well with every tasks, so i changed it to strings.

and now in dm_to_sd you are converting a string into a string.

Just for sure. It enforces to be a string for the input, in case it is not. In python anything can be the input. :) There are no harm if we convert a string to string, but adding a string to a float will raise errors.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/enesbcs/rpieasy/issues/222#issuecomment-793446252, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYAXNZM7RICUM4RFF3BJHTTCW4KHANCNFSM4YZRA2QQ .

[TD-er]

Just as a remark, as it has biten me quite a lot in the past. Watch out for interpreting numericals starting with a 0 as they may be considered octal. I don't know enough about Python, but it might also cause issues there when converting "0123" and not for "00123" or "0128".

[bsimmo]

Octal uses a different number format (0x0123) (edit correction (0o0123) ) in Python3 so x=0123 and x=0128 causes an error (token error) though x=0123.0 would be fine as it knows it's a float.

That's why it's held as a string. (though the float cast will strip the leading 0's

Anyway, just tested this and it's currently working and showing up for me now.
Be helpful if others can test too :-)

[enesbcs]

That's why it's held as a string. (though the float cast will strip the leading 0's

Yes, string conversion is removing zeros. :)

Float conversion removed at commit https://github.com/enesbcs/rpieasy/commit/9946ccc9294222c847f5005e2b38a4c66a2bfa64

It should work, but honestly needs some more testing. :)

[bsimmo]

Check my pull request to, sorted that problem of loads of variable casting, sorts out time problems, etc and creates a date/time that could be used as an event/variable but not programmed to do so. Re ordered lat/lon to the correct order (lat is always first) And added proper debug code for the Logging facility.

There is still one major bug I haven't had a look at that in the original plugin, reloading the plug in page, stops screen gnss/GPS updates forever. It's a todo and need follow the code, it's one of the fixlock variables doing it (it continues in the background fine).

Also some other fixes here and there.

EDIT:/ Helps if I make the pull request correctly #225

Ben

On Wed, 10 Mar 2021, 5:59 pm Alexander Nagy, notifications@github.com wrote:

That's why it's held as a string. (though the float cast will strip the leading 0's

Yes, string conversion is removing zeros. :)

Float conversion removed at commit 9946ccc https://github.com/enesbcs/rpieasy/commit/9946ccc9294222c847f5005e2b38a4c66a2bfa64

It should work, but honestly needs some more testing. :)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/enesbcs/rpieasy/issues/222#issuecomment-795828407, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYAXN76LLO2Q3PFAJX6TXDTC6XRDANCNFSM4YZRA2QQ .

[enesbcs]

Closed as merged

[enesbcs]

New plugin reported to be unaccessable. https://github.com/enesbcs/rpieasy/issues/226

[bsimmo]

I'll have a look, it's been working fine on my couple of units

[enesbcs]

self.gnssdate and self.gnsstime has no initial value, they break plugin after upgrading from old version. create_datetime has a flow with DDMMYYY input, added fallback method and exception handling.

Fixed at commit https://github.com/enesbcs/rpieasy/commit/fae69ff8447fd6ee2a2ad3ef2b894d3013e3ef8d