semuconsulting / pynmeagps Goto Github PK

Describe the bug

• In the file example/nmeafile.py line 72-76 is a copy error from your other project pyubx2: self._ubxreader should be self_nmeareader

• In the msgID GBS is one attribute wrong: effLon should be errLon

• For the msgID GSA no distinction is made between the NMEA Talker IDs. This was tested with GPS and GLONASS data. The talker ID GN is always used.

Please specify the pynmeagps version:
1.0.0

To Reproduce

USE any type of nmea data

Desktop (please complete the following information):

Windows 10, VSC

GNSS/GPS Device (please complete the following information as best you can):

• Device Model/Generation: NEO-M8U-0
• Firmware Version: UDR 1.00
• Protocol: 19.00

Feel free to ask any questions.

Thanks for the awesome projects.

cy
cminton

Describe the bug

I am logging the NMEA messages to a file and the read them back by

`with open(file, 'rb') as nmeas:
    for raw_data, parsed_data in NMEAReader (nmeas, validate = 0x03):
        print(parsed_data)`

I get the message:

Unknown msgID ASHR142509.000 msgmode GET.

• Version: 1.0.33
• b'$PASHR,142509.000,179.885,T,-0.624,0.245,,0.029,0.029,0.502,2,3*17\r\n'

Expected Behavior

I expect the message to be decoded.

Desktop (please complete the following information):

• The operating system: Ubuntu
• The version of Python: 3.10
• The type of serial connection: N/A

GNSS/GPS Device (please complete the following information as best you can):

• Applanix

Describe the bug

I'm using NMEAReader.parse() to parse a line of text containing a GLL sentence. The resulting longitude is correct, but the latitude is not.

pynmeagps v1.0.24

To Reproduce

Steps to reproduce the behaviour:

msg = NMEAReader.parse('$GNGLL,02348.3822990,S,15313.5862807,E,040856.82,A,D*5F')
print(msg)

output:
<NMEA(GNGLL, lat=-7.80637165, NS=S, lon=153.2264380117, EW=E, time=04:08:56.820000, status=A, posMode=D)>

Expected Behavior

The output latitude should be -23.80637 degrees.

Desktop (please complete the following information):

Windows 10
jupyter_client 8.2.0 pyhd8ed1ab_0 conda-forge
jupyter_core 5.3.0 py311haa95532_0
anaconda Command line client (version 1.11.2)
Python 3.11.3
pynmeagps-1.0.24

GNSS/GPS Device (please complete the following information as best you can):

I'm post-processing text captured from a GNSS receiver. Example text shown above.

This is a pattern frequently seen in examples of box pyubx2 and pynmeagps. It seems to imply the intention of handling parsing errors in the except clause.
However, parsing exceptions are thrown from the next() iterator call which happens in line 74, the for loop, outside of the try-except block. So the except handler and the continue statement are never executed.

Here's my snippet with the corresponding call stack at the point of NMEATypeError exception throw:

One possible workaround is to use exception-hand wrapper around the iterator like this:

def exception_logging(gen):
    while True:
        try:
            yield next(gen)
        except StopIteration:
            break
        except Exception as e:
            print(e)

# usage: for (raw_data, parsed_data) in exception_logging(UBXReader(stream, ubxonly=False)):

Hi,

I came across your project, and I would like to know if it is possible to use it with GPSD? I'm using GPSD to feed my NTP-server, and I would like to parse GPSD's output on port 2947, instead of using serial input.

But I'm just learning Python, so please bear with me :)

Thanks

In an environment where the talker is not e.g. GP but IN instead, the NMEAReader stream reading refuses to parse anything silently. However parse() function works for these out of the box. The reason is that currently NMEAReader uses NMEA_HDR in its read() function which completely ignores many talkers such as IN. There is no easy way to augment this list from scripts using the pynmeagpslibrary, and you have to resort to patching the library instead.

As originally discussed in #45 (comment)

You need to provide a little more information on the rationale behind the change (e.g. what is the origin of the INGGA messages?) [...]
Re. the change you've made, I'm not sure this is necessarily the safest approach. "IN" is a recognised Talker ID (Integrated Navigation). I would be inclined to simply add "$I" to the list of acceptable NMEA_HDR values. But happy to be challenged in the Discussions channel.

Sorry, I don't have all the information about the source. I'm not sure exactly what is the source as I was troubleshooting an issue for a friend and I don't work with or have available the actual environment where this is used. All I know it involves a large ship and probably some integrated navigation equipment related to it. For testing I just created a quick local mock server. All the messages received in this environment are from an IN talker source.

I did consider augmenting the NMEA_HDR list, but it felt a bit wrong to add just one more thing there. The thing is, there are so many many talker IDs listed in here, but basically the default NMEA_HDR list ignores most of them without explained rationale or a way to configure it without having to patch the library source, so that's why I'm suggesting to open it up in the NMEAReader constructor instead as in my original PR. Basically, I mean, the library user should be able to choose what talkers to listen to.

Hi, is there a command or function to output the number of satellite seen by the GNSS?

Discussed in #54

from pynmeagps import NMEAMessage, GET
msgsp = NMEAMessage('GN', 'GLL', GET, lat=43.123456789, lon=-2.987654321, 
                    status='A', posMode='A', hpnmeamode=0) # standard precision
print(repr(msgsp))
msghp = NMEAMessage('GN', 'GLL', GET, lat=-43.123456789, lon=2.987654321, 
                    status='A', posMode='A', hpnmeamode=1) # high precision
print(repr(msghp))

NMEAMessage('GN','GLL', 0, payload=['4307.40741', 'N', '00259.25926', 'E', '202808.32', 'A', 'A'])
NMEAMessage('GN','GLL', 0, payload=['4307.4074073', 'N', '00259.2592593', 'E', '202808.32', 'A', 'A'])

The title says it all. This docstring:

:param int validate (kwarg): bitfield validation flags - VALCKSUM (default), VALMSGID
and
:return: NMEAMessage object (or None if unknown message and VALMSGID is not set)

is a lie. When I pass validate=0 to the parse method or to the NMEAReader constructor, it still raises an NMEAParseError when it's fed a line that isn't valid NMEA. I would expect an NMEAReader instance to just skip over the invalid line, and NMEAReader.parse() to return None, as specified in the docstring.

Since u-blox receivers are frequently configured to emit both UBX and NMEA message types, it could be useful to have a reader module that can process such a stream and parse it correctly using both pyubx2 and pynmeagps.

Something like the code in pygpsclient/serial_handler.py, but packaged for reusability, with an interface like NMEAReader / UBXReader.

There is a typo in the bitfield description of the "UBX00" (NMEA-PUBX-00) message in "nmeatypes_get.py".
In line 488 it says:
"PDOP": DE
indicating Positional DOP. However, according to the interface manual of the u-blox ZED-F9P receiver, and the u-center software, the field indicates TDOP, meaning Time DOP. Hence, the correct label would be
"TDOP": DE

Thank you very much for pynmeagps. It is a wonderful starting point for my project.

I know this may be a ridiculous request but I would appreciate the decimal places on NMEA sentence LAT LON coordinates be increased from 5 to 7 decimal places. I would be happy with 6 but 7 would completely rule out any accuracy concerns.

Please correct me if I am wrong but I believe 5 decimal places provides precision in the 1 - 2 cm range? This is described in this u-blox thread:

https://portal.u-blox.com/s/question/0D52p00008HKCpZCAX/how-to-increase-the-precision-of-latitude-longitude-information-to-6-digits-in-nmea-message

My project is to generate a GPS file in NMEA sentence format compatible with Sensors & Software's EKKO-Project tool for processing Ground Penetrating Radar (GPR) data. My input file will be a POS trajectory file that has been corrected with PPK post processing using Emlid's Emlid Studio. The original GPS data is collected with an Emlid Reach RS2 on a GPR sled. Here are example lines from the resulting POS trajectory file. This input file provides 9 decimal places of precision on decimal degrees. I know these example lines are not "fixed". This data has not been PPKed yet.

% program : ES 1 Beta 10
% inp file : C:\Users\acreight\DOI\ALC- Projects - Documents\GPS\New folder\CWSC-1-rove_raw_202204251822_RINEX_3_03\CWSC-1-rove_raw_202204251822.22O
% inp file : C:\Users\acreight\DOI\ALC- Projects - Documents\GPS\New folder\CWSC-1-rove_raw_202204251822_RINEX_3_03\CWSC-1-rove_raw_202204251822.22P
% obs start : 2022/04/25 18:22:52.0 GPST (week2207 152572.0s)
% obs end : 2022/04/25 19:48:42.0 GPST (week2207 157722.0s)
%
% (lat/lon/height=WGS84/ellipsoidal,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=# of satellites)
% GPST latitude(deg) longitude(deg) height(m) Q ns sdn(m) sde(m) sdu(m) sdne(m) sdeu(m) sdun(m) age(s) ratio
2022/04/25 18:22:52.000 37.907054390 -107.726219853 3695.9964 5 16 3.2086 3.4894 7.2942 -1.1259 1.7928 -1.3556 0.00 0.0
2022/04/25 18:22:53.000 37.907054256 -107.726219850 3696.0308 5 16 3.2087 3.4896 7.2942 -1.1258 1.7939 -1.3558 0.00 0.0
2022/04/25 18:22:54.000 37.907054019 -107.726218720 3696.0449 5 17 3.1779 3.1165 7.2608 -0.7546 1.4581 -1.2364 0.00 0.0
2022/04/25 18:22:55.000 37.907054206 -107.726219340 3696.0215 5 18 3.1461 3.0529 7.1496 -0.5359 1.1556 -0.9800 0.00 0.0
2022/04/25 18:22:56.000 37.907054341 -107.726219948 3695.9748 5 18 3.1461 3.0530 7.1497 -0.5357 1.1572 -0.9802 0.00 0.0
2022/04/25 18:22:57.000 37.907054426 -107.726220263 3695.9737 5 18 3.1462 3.0532 7.1497 -0.5355 1.1589 -0.9804 0.00 0.0
2022/04/25 18:22:58.000 37.907055122 -107.726221381 3695.7856 5 20 2.9597 2.8730 6.1703 0.8442 -0.6558 -0.8601 0.00 0.0

I know asking for precision greater than 1-2cm is a bit ridiculous. Where possible, I am striving to rule out sources of error as my colleagues research measuring snow depth and density.

Thank you for considering this change.

The non-serialized output of NMEAMessage appears to maintain the original precision. The serialize() output truncates to 5 decimal places:

from pynmeagps import NMEAMessage, GET
msg = NMEAMessage('GN', 'GGA', GET, lat=37.907054390, NS='N', lon=107.726219853, EW='W', status='A', posMode='A')
print(msg)
print(msg.serialize().decode("utf-8"))

<NMEA(GNGGA, time=20:58:02.969459, lat=37.90705439, NS=N, lon=-107.726219853, EW=W, quality=0, numSV=0, HDOP=0.0, alt=0.0, altUnit=, sep=0.0, sepUnit=, diffAge=0.0, diffStation=0)>
$GNGGA,205802.96,3754.42326,N,10743.57319,W,0,0,0.0,0.0,,0.0,,0.0,0*71

I made an attempt increasing the decimal places in nmeahelpers.py ddd2dmm but it looks like additional changes are need in other functions. The resulting output from serialize

https://github.com/semuconsulting/pynmeagps/blob/master/pynmeagps/nmeahelpers.py#L137

Discussed in #41

example message from u-blox F9P receiver:

$GBGSV,2,2,06,14,55,175,46,40,29,043,18,B*06

Not the 0xB value at last position