Closed wrh-dev closed 1 year ago
Thanks for this, very useful ideas.
The MQTT code, in particular, is a bit of a rats-nest of ifs and buts as it tries to cope with our many and varied MQTT AT command interfaces, so I kind of lost confidence in making it more complex, if you see what I mean, when it was originally written. However it was coded quite a long time ago now and so making a relatively small, discrete, change, as you suggest would probably be fine and, should it not work out, it could easily/obviously be reversed in a subsequent commit.
On the registration one, as you say that's likely more complex - when is an error a "final, I'm not gonna do anything" error, versus just a whiney module. Let me consult with application engineering on this one.
I think you're right about my logic with the keepGoing
flag though: problem with his kind of code is that it's quite difficult to check the condition reliably and across all modules without taking more time than I usually like our regression tests to take; my fault.
So I will address this in two parts - the MQTT one and then the registerNetwork()
one (including the logic around the keepGoing
flag) in discussion with AE (@philwareublox).
I've been through the registerNetwork()
case again and you're right about needing the device error part but I now think the check that follows to do the abort was correct, though admittedly confusing. I have made a fix for both the MQTT cases and the registerNetwork()
case and pushed a preview branch with those fixes here:
https://github.com/u-blox/ubxlib/tree/preview_cell_fix_err_rmea
These changes have passed our internal testing but, as I said, we probably don't cover such scenarios very well so could you take a look and confirm that the changes are what you expect? If you can confirm that I will merge the fixes to master
and push that out here properly and then delete the preview_cell_fix_err_rmea
branch.
Thanks for making these changes! After some testing, I think they seem appropriate. For the registerNetwork()
case, for example, I've seen the code catch CME ERROR: No network service
errors and then use the registration URCs to correctly timeout or wait for registration to succeed.
I now follow the abort command logic after reading through the changes.
Feel free to close out this issue when the preview branch is merged!
Great: the changes have been submitted for review internally, should be there in a few days.
Fixes now pushed here in commits cf61c1beed87f6e30f66a14c70fb70009f82c8fc and e7851e0070bc6dfca8050ad2f15ea2b8fee25e6a, will delete the preview branch now, thanks again for raising these very useful issues.
Some routines ignore AT device errors, such as
registerNetwork()
inu_cell_net.c
andconnect()
inu_cell_mqtt.c
. This results in the code waiting for a timeout even though I believe the module has already given up on the command.To get around this, does it make sense to add checks for device errors in these and similar routines?
For example, does updating the
connect()
routine as shown below make sense?Does this make sense for the
registerNetwork
routine? I feel less confident in this change because I do occasionally seeCME ERROR: No network service
issued about 10-20 seconds after attempting a manual registration which results in the connection attempt failing. Not sure if the module would recover gracefully if given more time...Also, is the logic for the
abortCommand
check backwards? Should this:be changed to: