sparkfun/SparkFun_u-blox_GNSS_Arduino_Library

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