We are using the popular ZED-F9P device from u-Blox in a module reads-deserializes-transforms-serializes-writes messages. The pynmea2 package is properly reading the PUBX message it but fails to serialize back to an identical string. Specifically, it skips the message type field. E.g., with input message: $PUBX,03,32,1,-,172... the render method returns: $PUBX32,1,-,172.... As a workaround we are monkey patching the library with
@add_method(pynmea2.NMEASentence)
def serialize(self): # pylint: disable=unused-variable
data = self.render(checksum=False, dollar=False)
if hasattr(self, 'manufacturer') and self.manufacturer == 'UBX':
data = data[:4] + f',{self.sentence_type[-2:]},' + data[4:]
data += '*%02X\r\n' % pynmea2.NMEASentence.checksum(data)
return bytearray('$' + data, encoding='ascii')
I assume the challenge here is that we cannot accommodate every possible proprietary format because not all of them have the same payload grammar. However, for some of the most popular cases maybe special cases can be created, or a more natural hook up point than our monkey patching workaround for the user to inject behavior as a formatter of sorts.
Knio
commented
3 years ago
We are using the popular ZED-F9P device from u-Blox in a module reads-deserializes-transforms-serializes-writes messages. The
pynmea2package is properly reading thePUBXmessage it but fails to serialize back to an identical string. Specifically, it skips the message type field. E.g., with input message:$PUBX,03,32,1,-,172...therendermethod returns:$PUBX32,1,-,172.... As a workaround we are monkey patching the library withI assume the challenge here is that we cannot accommodate every possible proprietary format because not all of them have the same payload grammar. However, for some of the most popular cases maybe special cases can be created, or a more natural hook up point than our monkey patching workaround for the user to inject behavior as a formatter of sorts.