getRXMSFRBX and getRXMRAWX contain odd call to TIM related functionality
FerdinandvHagen opened this issue · 3 comments
Subject of the issue
I'm not sure if this is really an issue but it might be related to issues reported in conjunction with RAWX and SFRBX. I would appreciate if somebody could confirm that the current implementation is correct.
In getRXMSFRBX and getRXMRAWX respectively, there is a call to checkUbloxInternal(&packetCfg, UBX_CLASS_TIM, UBX_TIM_TM2);. This seems odd as I would have expected a call similar to checkUbloxInternal(&packetCfg, UBX_CLASS_RXM, UBX_RXM_RAWX);. This is also the case in other functions.
Can somebody confirm that the current implementation is correct?
Hi Ferdinand (@FerdinandvHagen ),
Thank you for raising this issue. You are correct. getRXMRAWX should be calling checkUbloxInternal(&packetCfg, UBX_CLASS_RXM, UBX_RXM_RAWX);. It is a copy-and-paste error...
I will release a new version of the library tomorrow which corrects this.
However, please be aware, this will correct getRXMRAWX but will probably have little or no effect on getRXMSFRBX. UBX-RXM-SFRBX is "output only". It cannot be polled. I will need to disable the part of getRXMSFRBX that attempts to poll the message.
I'm curious... What is your "use case" for these functions? Most people use the logging functions or callbacks to access RAWX and SFRBX. Do you have any code you can share?
Also, you say "issues reported in conjunction with RAWX and SFRBX". Please post links to any relevant issues here. Then I can check how many of them this fix resolves.
Thank you - and best wishes,
Paul
Hi Ferdinand (@FerdinandvHagen ),
Thanks again for reporting this. It is resolved in v2.2.20. Please see the Release Notes for more details.
Please do come back to me with: your use case; any issues that I might not be aware of.
Best wishes,
Paul
Hi Paul,
thank you so much! That was a super fast reply & fix.
Actually I haven't looked far about issues (and I didn't have any myself yet, the issue that caught my eye was #23). But I implemented the callback and parsing for MEASX messages - and while copying the code from RAWX this issue jumped at me.
Shall I open a pull request for MEASX messages or not needed atm?
Best,
Ferdinand