Make parser more tolerant to spaces in responses URC

[mazgch]

Hi @PaulZC,

This is an attempt to make the AT parser more tolerant to spaces following the first : in URCs and responses.

In the past it searched for +CREG: <data> this is correct for many modems. but some variants of modems (like LENA-R8 in ES stage) do not strictly follow that format and sometimes omit the space between the : and the <data> following. this pull request tries to make the parser in this library more tolerant. The changes in the code involves searching for a shorter response code only until :and the either skip the spaces of let the %d in the following scanf handle that.

I must admit I have not tested with all the different examples or modems. But my code uses quite many commands and APIs already. I leave it up to you if you think this is useful for everybody. Maybe it would be good to give it a review from your side.

[PaulZC]

Hi Michael (@mazgch ),

Happy New Year!

Thanks for submitting this PR. I haven't yet had time to test it, but I will - hopefully in the next few days.

Very best wishes,
Paul

[PaulZC]

Hi Michael (@mazgch ),

Apologies for the very slow reply on this. I have been "putting it off" as I am slightly nervous about merging it as-is. I don't know if sscanf works the same way on all platforms and whether all platforms will automatically ignore the space in front of %d.

I have two options. I can either test it on many boards and make sure they all still work correctly. OR - probably safer - use this technique everywhere...

I think I will go with option 2.

Merging into release_candidate for testing.

Best wishes,
Paul

[mazgch]

OR - probably safer - use this technique everywhere...

You are right probably scanf has different behaviour on various compilers I have not thought about this. I think normaly ' ' in format string should even match no space. I was thinking akso to maje just a helper function that checks and skips the start string and following spaces and then does the scanf. Would you prefer this?

To my knowledge all conversion specifiers other than [, c, and n consume and discard all leading whitespace characters (determined as if by calling isspace) before attempting to parse the input. These consumed characters do not count towards the specified maximum field width.

What is this method that you refer to? It links to this PR for me.

[PaulZC]

Working on it now... Please see the latest commits:

https://github.com/sparkfun/SparkFun_u-blox_SARA-R5_Arduino_Library/commits/release_candidate

I use sscanf(foo, "%s", bar) in a few places (e.g. getCCID). That's not memory safe... I'll see if I can come up with a better way to do it.

[mazgch]

You can limit the length

char bar[20];
sscanf(foo, "%20s", bar);

[PaulZC]

Excellent - thank you. Stealing...!

[PaulZC]

Hi Michael (@mazgch ),

I think this is complete - but I can not test it as all of my Pay-As-You-Go SIMs have expired! I will need to get a new one.

If you have time, can you please test the code in the release_candidate branch?

Thank you,
Paul

[mazgch]

Hi Paul, my project is running from this branch I have tested LENA-R8 and LARA-R6. But I must admitt that I did not test a lot.

[PaulZC]

Hi Michael,
I got a new O2 (Telefonica) SIM and used it to re-test all of my Asset Tracker (SARA-R5) examples. All of the examples worked...
I will release the code changes in a few minutes.
Thank you - best wishes,
Paul