modem_cellular: ability to launch chat script from application space.

[RomainPelletant]

Is there a way to execute a chat script directly on a modem interface based on modem cellular?

For example, sometimes I would initiate a QCSQ command to get network health status, from application space to a specific device and I didn't find a better way than add a specific command reachable from application space:
011_cellular_add_run_cmds.patch

Do you have a better idea?

[RomainPelletant]

@bjarki-trackunit It could require a generic function to get information on network signals.
If I correctly understand modem_cellular driver, we shall implement a specific chat script for each modem's models.
To avoid direct calls to the driver, a specific API shall be provided to request to commands like

net_mgmt(NET_REQUEST_WIFI_IFACE_STATUS, iface, &status,
		     sizeof(struct wifi_iface_status))

I don't know if net_mgmt is the right place for that or a new one shall be implemented (more cellular network specific)

Data could be:

• SINR
• RSRP
• RSRQ
• LAC
• CellID
• RSSI
• Operator code

Maybe a RFC could be more appropriate for that but I would have your opinion.
Thanks for your time :)

[bjarki-andreasen]

The modem_cellular driver is an MVP intended as a base implementation for other drivers. It demonstrates how the modem modules work, and provides network connectivity.

We do not have a proper cellular modem API in zephyr yet, so custom APIs must be implemented out-of-tree for now. this includes setting APN and other credentials, selecting radio access tech, sending sms'es etc. In short, copy paste modem_cellular.c out of tree, create an API that fits your needs out-of-tree, then implement it in your out-of-tree driver

This is taken from the modem_cellular driver line 1487:

DEVICE_DT_INST_DEFINE(inst, modem_cellular_init, PM_DEVICE_DT_INST_GET(inst),		\
			    &MODEM_CELLULAR_INST_NAME(data, inst),				\
			    &MODEM_CELLULAR_INST_NAME(config, inst), POST_KERNEL, 99, <your api here>);

This way you get full flexibility to implement exactly what you need using the device driver model. This is the intended purpose of the modem modules.

[RomainPelletant]

Thanks @bjarki-trackunit :)

[AndrewAWG97]

Hi @bjarki-trackunit, I want to use the same way you're using to communicate with the modem with scripts. I want to get a GPS signal.
I tried to add commands to the script, they work but as you know GPS signal may need to send command many times until it return location, but in our case we can't send the same command if it returns an error.
I thought to deal with the bg95 as 2 modems, one for connection and the other one for GPS, but I can't deal with it in the device tree.
I will be than thankful if you helped in this case. I opened a discussion about sending custom commands and triggering the script from the application layer. thanks in advance.

[bjarki-andreasen]

The plan is definitely to create two devices in devicetree, one for the cellular modem, implementing the experimental cellular API the other implementing the GNSS API.

These APIs (although handlers have not been created for syscalls yet) are meant to be called from user space/the application, it should not be necessary to send chat scripts manually from the application, the device driver APIs should take care of that :)

[AndrewAWG97]

thank you for your reply @bjarki-trackunit, I am using SDK 2.5.2 which doesn't have these GNSS API yet. so I want to try to make my own out-of-tree library. I just need a push to know how to launch my own script.

[AndrewAWG97]

@bjarki-andreasen Hi bjarki, is there any way to change the cmds sent to the modem in runtime?
for example if I want to change the mode from lte to gsm and vice versa ?

[bjarki-andreasen]

There are two separate ways of creating chat scripts, const and runtime.

const chat scripts or not modifiable, they are defined using macros like MODEM_CHAT_SCRIPT_CMDS_DEFINE() these can not be changed at runtime, and they need to be passed const data, like char strings, not a pointer to a non-const buffer, which is not known at compile time, hence the initializer element is not constant

runtime chat scripts use the same structs naturally, but they are not defined as const like the macros do, they are defined as "normal" mutable structs. Look into the struct quectel_lcx6g_data *data, there you will find the "raw" chat scripts, matches and requests, as normal structs, which are then initialized and modified at runtime using the modem_chat runtime APIs like modem_chat_script_chat_set_response_matches

[mxc42]

Ok, I think I'm following. I'm using the gnss_quectel_lcx6g driver, if I want to send say a $PAIR690 message do I have to fork my own version of gnss_quectel_lcx6g.c and then somehow add my custom function to the gnss_api? I get the flow of lines 782-798 you sent earlier but I'm not sure how to add that to my own gnss file as quectel_lcx6g_data is defined in gnss_quectel_lcx6g.c and not in a header file.

If it is possible to get an instance of data in my own file, do I follow this format for sending the $PAIR690?:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/gnss/gnss_quectel_lcx6g.c#L309-L350

[bjarki-andreasen]

You should copy the driver and keep it out-of-tree, then you can modify the data struct in your downstream version of the driver, and add a device driver specific header with the extra APIs you need out-of-tree as well.

[bjarki-andreasen]

custom device driver specific headers look like this ecc3031#diff-555328e57afc6cacd9d4390c16e518d4808f5a81b7301e5b861060d94cba19cd

[mxc42]

Ok, I'll give that a go. Thanks!