drivers: cellular: add rssi / modem information

[ldenefle]

Hello, this PR is an effort to bring a method to pull things like RSSI or modem / SIM information from an app.
It leverages the new periodic script and the begining of the cellular API implemented by @bjarki-trackunit .
The PR right now is not in a mergeable state but I'd be keen for maintainers to have a look at it and start a conversation around the fundamentals of it:

• does it fit in the architecture ?
• are there shortcomings I'm not aware of ?
• is it too early for a PR like this ?

[bjarki-trackunit]

For a large list of const strings, I will suggest struct of const char *

struct cellular_modem_info {
        const char *imei;
        const char *model;
        ...

where the members point to char buffers initialized by the modem driver. Then when the modem has initialized the char buffers, we only need to copy pointers to the internal buffers

int cellular_get_modem_info(const struct device *dev, struct cellular_modem_info * modem_info);
{
        modem_info->imei = (const char *)data->imei;
}

This avoids a bunch of copying, and allows the driver to determine and manage the sizes of the members of struct cellular_modem_info

That said, I would prefer using a getter like int cellular_get_modem_info(enum modem_info_type type, char *info, size_t size); This is more flexible as we can add info to enum modem_info_type, without modifying the struct cellular_modem_info struct, and we can return -ENODATA if the modem does not provide said info.

[ldenefle]

makes perfect sense

[bjarki-trackunit]

I don't think bit error rate should be used here as defined by the 3GPP specification at least, given that it is often excluded (set to 99) and is terribly complicated to decode

We should find a good way to abstract this data to be useful to the user IMO, RSSI is quite useful and is AFAIK always available, but even this could be abstracted into a EXCELLENT, GOOD, BAD spectrum, or a percentage, like what has been attempted here https://usatcorp.com/faqs/understanding-lte-signal-strength-values/?__cf_chl_tk=S8.MOHvJvlqFnfSdCNbPHzD_fq9sPTvCtPyve0O8FzI-1700753956-0-gaNycGzNC1A#section-2-1

[ldenefle]

do you agree about the concept of having a separate API for static / pull once get_modem_info and for dynamic / pull several times get_signal ?

[bjarki-trackunit]

I'm not sure, static modem info is quite limited right? IMEI and model number is pretty much the only non changing property I can think of which we have to poll from the modem, others depend on network selection, sim card inserted etc. Even properties like firmware versions can change during runtime if the modem is updated :)

I think overall the modem driver should determine how often it needs to read the static data, and the API should not care if the value is static or not, so I'm leaning towards a single API

[emillindq]

I'd like to suggest to add RSRP and RSRQ, the latter potentially replacing BER. RSRP is a better measurement of signal strength (relevant signal strength anyways), and commonly used in LTE.

Obviously if a modem is using GSM or 3G this might not be available, which should be indicated for example by setting RSRP/Q to INT16_MIN. But at least it should be there since 4G is the current and probably most used technology

[bjarki-trackunit]

If all values are integers, we could create a getter like the one for modem_info, which allows us to define both RSSI, RSRP and RSRQ in an enum, and return -ENODATA if the value is not present. I really like to avoid reserved values if possible :)

[bjarki-trackunit]

RSSI and RSRP are both in dBm which is quite nice, RSRQ seems to be dB which makes it a bit less nice to include if we use a getter for signal strength

[naNEQ]

I'm not sure, static modem info is quite limited right? IMEI and model number is pretty much the only non changing property I can think of which we have to poll from the modem, others depend on network selection, sim card inserted etc. Even properties like firmware versions can change during runtime if the modem is updated :)

I think overall the modem driver should determine how often it needs to read the static data, and the API should not care if the value is static or not, so I'm leaning towards a single API

So far I also had in mind that there should be a separation between static (btw, I think these are IMEI, model number and manufacturer) and dynamic information. But @bjarki-trackunit has a good point. Things like the sim card and the fw version can change in runtime, so static information is very limited. It would be simpler to keep a single API for everything and in the end, it should be the application that decides what part of the data is static and what not.

On another note, is it actually the modem driver or the app that determines how often this info have to be read from the modem? Perhaps the time interval should be configurable?

[bjarki-trackunit]

I would expect the application to request RSSI etc. as often as it sees fit, I don't think we actually need to store it and poll periodically

[naNEQ]

I would expect the application to request RSSI etc. as often as it sees fit, I don't think we actually need to store it and poll periodically

Yes, that probably sounds the most rational thing to do.

[bjarki-trackunit]

@naNEQ This may be of interrest :)

[ldenefle]

@bjarki-trackunit what do you think of current API ? I can add some demo code in the sample too

[ldenefle]

Hello, addressed all the changes requested, I'm testing them and pushing soon.

[jukkar]

LGTM

[bjarki-trackunit]

Nice work!