MSM7 CFGRTCM not being respected on LG290P after a restore unless it's done again

[epigramx]

So if I restore the module settings with $PQTMRESTOREPAR*13 and then do $PQTMCFGRTCM,W,7,0,-90,07,06,1,0*26 it appears that after a $PQTMSAVEPAR*5A and a $PQTMSRR*4B it gives the MSM4 unless I do the MSM7 command AGAIN and then save and reset.

Is this documented behavior anywhere or just bugged?

[bamarcant]

Here the same…

LC29H (EA) RTCM3 out?

@george.gao @Raphael-Q (@ any other Quectel staffers), @rtklibexplorer brings up a good point in his blog post linked above. On an LC29H(EA) running version LC29HEANR11A03S_RSA,2023/10/31,16:52:14 when I set the RTCM output to MSM7 using the $PAIR432,1 command, it works as intended. However the $PAIR513 and/or $PQTMSAVEPAR commands seem to be saving the configuration to output MSM4 messages rather than MSM7 after a power cycle. Is this a known bug? Is there fixed firmware? Is there a work aroun…

howewer try to stop gnss engine$PQTMGNSSSTOP*09 before the apply.

[splee]

@epigramx

…it appears that after a $PQTMSAVEPAR*5A and a $PQTMSRR*4B

I have found the $PQTMSRR*4B command to be inconsistent, with the same results as you. I find that powering off the module works better.

[epigramx]

to splee: forcefubly turning off and on the module is unacceptable here because it’s for a project that must be used automatically on the field.

@bamarcant

try to stop gnss engine$PQTMGNSSSTOP*09 before the apply

Hah that seems to work indeed thanks. It’s kinda helptful because SSR causes it to hang for a few seconds so it would need an ugly sleep at the operating system side before setting the second half of commands.

[epigramx]

Apparently the workaround doesn’t work on base mode, but maybe it’s on the right track, and the GNSSSTOP has to be put somewhere else there.

[epigramx]

Apparently the bug is bigger than I thought so scrap the last two replies when it goes to the solution. If you change CFGRCVRMODE: then the workaround goes out the window, so currently the workaround is first do CFGRCVRMODE/save/reset and THEN do your settings/save/reset again after you wait for a few settings (ugly but it works every time)

[bamarcant]

[epigramx]

I do that already. The problem is that if you turn on MSM7 messages (with CFGRTCM) after a CFGRCVRMODE and then save both and then reset the MSM7 setting is ignored and it goes back to MSM4. It appears to work with a workaround of first setting up the module to base or rover mode and then saving and resetting and then doing the MSM7 settings and then saving and resetting (main problem is you have to wait for 6 seconds for the first reset to complete which isn’t the most robust).

[splee]

Yes, based on my own experience, anytime you execute a receiver change mode command, any subsequent commands won’t get saved until it has performed a reset. It’s not a problem for applications that don’t change modes, but if your application depends on changing receiver modes dynamically, then having to perform two resets to fully configure it could be a bit of a pain…