modem_cellular: add RSRP &RSRQ to U-blox SARA-R5 modem

[emillindq]

This commit implements parsing of the CESQ extended signal quality AT command, extracting RSSI, RSRP and RSRQ, the latter two being relevant for LTE connections. It's used in the U-blox SARA-R5 modem instance. Furthermore, the IMEI and IMSI is extracted in the same modem.

A couple of comments:

• Not sure how to handle the "unknown" case, just returning without changing RSSI as done in modem_cellular_chat_on_csq feels wrong. Suggestions welcomed (maybe return -ENODATA if invalid?)
• Didn't add CESQ to periodic polling, which is done in the Quectel drivers. I don't see the point since you can't access RSSI/RSRP/RSRQ without calling the API, which runs them anyways

[emillindq]

I'd like to request some help from @jeffwelder-ellenbytech or @bjarki-trackunit regarding the failed pipeline. It fails because my added functions aren't used by the Quectel BG95 modem instance, which warning causes the sample "test" to fail.

It feels messy in the long run to ifdef all such parsing functions depending on which modem use them. I think modem_cellular.c is quite hard to navigate as it is due to the instantiation of the different modems, and now the API is added in the bottom where normally the device instantiation is. This feels like a larger discussion that should be taken elsewhere, because it feels like this structure of one giant .c file won't scale well when APIs are implemented, and more modems and AT commands are added. Do you agree?

I'm in the process of migrating from an out-of-tree mod of ublox-sara-r4.c to modem_cellular.c, and therefore would like to implement a lot of the missing APIs and things mentioned here. However I feel that such discussion would be appropriate before it all blows up completely. Thanks!

[bjarki-trackunit]

Hi, I know, I didn't look close enough to the actual API implementation that was added in modem_cellular.c and I'm looking into fixing it :) In short, API implementations will go into the struct device API pointers, and startup/periodic scripts will only be used if absolutely necessary, CESQ for example will to into its own script run synchronously when the API is called

[bjarki-trackunit]

See #67066

[emillindq]

Hi, I know, I didn't look close enough to the actual API implementation that was added in modem_cellular.c and I'm looking into fixing it :) In short, API implementations will go into the struct device API pointers, and startup/periodic scripts will only be used if absolutely necessary, CESQ for example will to into its own script run synchronously when the API is called

@bjarki-trackunit The PR looks fine, I guess, but it doesn't address the problem in this PR (if that was the purpose). The thing is that cesq_match usage is not compiled in if compiling for Quectel model, and csq_match usage is not compiled in if compiling for Ublox modem. How to handle the warning?

Thanks!

[bjarki-trackunit]

You should be able to rebase and add CESQ to the driver now that #67066 has been merged :)

[emillindq]

@bjarki-trackunit please take a look!

[bjarki-trackunit]

Looks good! I will test that it handles CESQ not being supported nicely as well (Quectel only supports CSQ)

[bjarki-trackunit]

Works as expected on the BG95, gets RSSI just fine, fails properly when trying to get RSRQ/RSRP (since it does not support AT+CESQ)

[00:00:22.941,131] <inf> modem_cellular: event script success
Signal RSSI -51
[00:00:23.980,895] <wrn> modem_chat: get_signal_cesq_chat_script: aborted
[00:00:23.980,957] <inf> modem_cellular: event script failed
Failed to get RSRP
[00:00:25.020,965] <wrn> modem_chat: get_signal_cesq_chat_script: aborted
[00:00:25.021,057] <inf> modem_cellular: event script failed
Failed to get RSRQ
[00:00:25.063,171] <inf> modem_cellular: event script success
Signal RSSI -51