Closed gabrielecoppi closed 1 year ago
Hi @gabrielecoppi
Thanks for this, but I'm a little unclear on the practical utility? pyubx2 is a protocol parser - I'm happy to be convinced otherwise, but removing the parsing option feels a bit like buying a car and taking the wheels off. WIthout the parsed data, you're simply reading the raw binary datastream, and you can do that with any serial reader utility - you wouldn't need pyubx2 at all.
Hi @semuadmin, I give you my specific application (for which I have modified pyubx2
). The package is still parsing by default but now I have added the option to not do it. I am currently using a RPi that is powered by a battery and it monitors multiple devices including a ublox. I found that I save some CPU without parsing data (and so I get the battery to last a bit longer). I also found out that with this structure I can save the message with the correct length, instead of random chunks of bytes. This ensures that all the messages saved are correct and significantly simplify the analysis whit the data. Finally, in my specific application saving binary format helps in saving space on the SD of the RPi.
Hi @semuadmin, I give you my specific application (for which I have modified
pyubx2
). The package is still parsing by default but now I have added the option to not do it. I am currently using a RPi that is powered by a battery and it monitors multiple devices including a ublox. I found that I save some CPU without parsing data (and so I get the battery to last a bit longer). I also found out that with this structure I can save the message with the correct length, instead of random chunks of bytes. This ensures that all the messages saved are correct and significantly simplify the analysis whit the data. Finally, in my specific application saving binary format helps in saving space on the SD of the RPi.
OK no issue with the change in principle but, as I say, if you simply want to save the binary UBX data without the CPU overhead of parsing, why not just pipe the serial stream directly to a file e.g. something like:
stdbuf -o0 cat /dev/ttyACM0 > ubx.bin
If you need to delimit individual UBX messages, you could grep the UBX delimiter b'\xb5\x62'. Just a thought...
I agree. This would be easier, but in my mind I am building this system in a future proof way, such that if I change the RPi to a different board, if I move to more fixed system with wall power, I just need to change a single flag and the code still work with the plus that now I can have the data parsed. I also forgot to mention that at the moment based on the measurement that I want to perform I need to configure the ublox with different output and that is done at the startup of the RPi, so I need to use a VALSET command (if I want or not the RTK data for example). As I mentioned is a specific case of mine, so I do not want to change the paradigm of the code that you wrote (thanks a lot by the way), I just thought that since I have done this modification and this is not affecting anything may be useful for others too
Ok I will reply here. I apologize for messing up the VScode settings.
For the other comments as suggested I set a self._parsing
constructor in UBXReader
to not break the iterator. The issues with the tests was that I messed up with the bitwise operator &
when checking the protocol filter. Now, it should be solved. I created a separate testing file for a no parsing case. Everything seems to work as can be seen
Ok I did not have noticed that you updated the test_stream.py
. So I have updated my branch too, to reflect this
pyubx2 Pull Request Template
Description
Added the option in
UBXReader.read()
to not parse the payload. This may be useful when continuously polling data with a low power computer and a lot of messages requested.Fixes # (issue)
Testing
Added two tests with the flag
parsing=False
to verify the behavior and they work (NAVHPPOS and HNRLOG) intest_stream.py
Checklist:
tests/test_*.py
unittest suite to maintain >= 99% code coverage.tests/test_*.py
unittest suite.