semuconsulting/PyGPSClient

KeyError on private RTCM3 messages

wdc-rsat opened this issue · 3 comments

pygpsclient 1.3.21 throws KeyError exceptions on receiving private STMicroelectronics and SwiftNav RTCM3 messages:

`KeyError: '999'
Exception in Tkinter callback
Traceback (most recent call last):
...
if self._labelmsm and "MSM" in RTCM_MSGIDS[self.identity]:
~~~~~~~~~~~^^^^^^^^^^^^^^^

KeyError: '4062'
Exception in Tkinter callback
Traceback (most recent call last):
...
if self._labelmsm and "MSM" in RTCM_MSGIDS[self.identity]:
~~~~~~~~~~~^^^^^^^^^^^^^^^
`

Hi @wdc-rsat

Sorry you're having difficulties. This is actually a bug in the pyrtcm library and I've transferred your error report over to that repo semuconsulting/pyrtcm#34.

The error itself is an easy fix, but can I clarify what your expectations are in terms of resolution?

The message identities you reference are - as you say - proprietary RTCM message types, the payload definitions of which are not, to the best of my knowledge, in the public domain. As things stand, pyrtcm (and therefore PyGPSClient) parses such messages as 'undefined' binary payloads but cannot decode individual attributes. If you're able to point me in the direction of a public domain payload definition for the 4062 message type, I'd be happy to add it in.

In addition, '999' does not sound like a valid proprietary RTCM3 message type - according to the RTCM3 specification, proprietary message identities should be in the range 4001 to 4095.

What's the provenance of these messages? Would it be possible to provide a sample binary data stream that I can use for testing?

Hi @wdc-rsat

The bug in pyrtcm has now been resolved with semuconsulting/pyrtcm#34. It will be available in the next release of pyrtcm (v1.0.8) - provisionally in the next week or so.

NB: in the absence of payload definitions for these proprietary message types, pyrtcm will parse them thus:

<RTCM(4062, DF002=4062, Not_Yet_Implemented)>
<RTCM(999, DF002=999, Not_Yet_Implemented)>

... though PyGPSClient is still able to pass the raw (binary) message through to a receiver which recognises these message types.

It would still be very helpful if you could provide a sample RTCM3 binary datastream containing these unknown message types for future reference.

Hi @wdc-rsat

I believe the issue as originally reported is now resolved. I'd be happy to look further into parsing a wider range of proprietary RTCM3 messages if the payload definitions can be made available, but I'll close this issue for now.

If you have any further queries or comments on this, feel free to raise them in the pyrtcm Discussions Channel.