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?
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.
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.
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)
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).
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…