Implement URC Handling. (IDFGH-8812)

[diplfranzhoepfinger]

also discussed in:

#156

#168

#179

[diplfranzhoepfinger]

@david-cermak

[franz-ms-muc]

also in the Modem Console URC might be helpful: see here:

issuing a extra cmd AT does not really look smart.

[david-cermak]

This could be implemented the same way as https://github.com/espressif/esp-protocols/pull/156, i.e. installing a permanent callback which would check for a global set of URC first and only after that for replies to requests. So we could still create a DCE class that's command-able (=could add commands) and at the same time handles the URCs.

I'll prepare a simple demo.

[franz-ms-muc]

Thanks so much.

Meisterschulen am Ostbahnhof Mühldorfstr. 6 81671 München

Tel.: 089 416002 - 0 Fax: 089 416002 - 111

Internet: www.meisterschulen-münchen.dehttp://www.meisterschulen-mchn.de

[franz-ms-muc]

I'll prepare a simple demo.

any Progress @david-cermak ?

[david-cermak]

Added as https://github.com/espressif/esp-protocols/pull/156/commits/c61fe1f5f915b2d39dda81ea8ce701660991194c

it's very simple and WIP. It only adds a user callback that could handle all received data. (needs to be removed before switching modes and applied again after)

The other option is to reuse CMUX mode for that, we already have two virtual terminals, so we could make another one for handling URC. Unfortunately the DTE/CMUX classes are not fully designed to support variable number of virtual terminals, but that would be an interesting addition.

[diplfranzhoepfinger]

i will test it. have a Good Test-case here:

a SIMCOM A7672E-FASE

we can send here a AT+CGNSSPWR=1 command, and it will answer with a URC of +CGNSSPWR: READY!

will test now...

[diplfranzhoepfinger]

your URC Handler works:

[franz-ms-muc]

Hi,

Question: (from Vasil Nikolov)

I understand the URC implementation following way:

1. You can switch on/off the reaction on URC a. This is nice
2. ESP Modem receives all of the URC a. For me it is important to understand how modem implementation differentiates between URCs and a normal response to AT commands i. There are commands which require longer time until a response is received. b. Can we receive URCs while we are waiting for a response to a certain AT Command? i. If yes then how can we be sure that responses to the AT Commands are forwarded to the URC handler instead to the command handler
3. In our user code we shall define one URC handler with a switch case based on the data and length of received URC a. This is a nice approach, we have full control over all URCs we are interested in

[VasilNikolovRilabs]

@david-cermak could you please provide some feedback about the last questions from Franz? We would like to really assure that the URC implementation wont impact the normal AT command request/response handling

Thank you!

[david-cermak]

Hi Franz and Vasil,

sorry for not responding earlier. The example of injecting a URC callback doesn't really change anything in the esp_modem layers, it just overrides the default command implementation using these two methods:

1. Traditional method for sending commands makes the class command-able, so it could be employed by the command library to run all/defined AT commands:

https://github.com/espressif/esp-protocols/blob/c61fe1f5f915b2d39dda81ea8ce701660991194c/components/esp_modem/examples/modem_console/main/my_module_dce.cpp#L51

2. The data callback that processes the replies

https://github.com/espressif/esp-protocols/blob/c61fe1f5f915b2d39dda81ea8ce701660991194c/components/esp_modem/examples/modem_console/main/my_module_dce.cpp#L70

This way, we're able to

• first call the user urc-callback (and after that)
• continue with processing the replies by the command library

---

a. For me it is important to understand how modem implementation differentiates between URCs and a normal response to AT commands

we process the user callback first

https://github.com/espressif/esp-protocols/blob/c61fe1f5f915b2d39dda81ea8ce701660991194c/components/esp_modem/examples/modem_console/main/my_module_dce.cpp#L73-L75

...and then let the command library to parse the same data.

https://github.com/espressif/esp-protocols/blob/c61fe1f5f915b2d39dda81ea8ce701660991194c/components/esp_modem/examples/modem_console/main/my_module_dce.cpp#L76-L87

i. There are commands which require longer time until a response is received.

You need to be aware that the urc handler would still received all the replies, including the ones that belong to unrelated commands issued by the command library (by user)

b. Can we receive URCs while we are waiting for a response to a certain AT Command?

Yes, the urc-handler gets always called (if enabled). The other part (lib-command processing) is called only if an AT command is in progress.

i. If yes then how can we be sure that responses to the AT Commands are forwarded to the URC handler instead to the command handler

This works like a fork (tee command in bash :-), we pass the same data to two handlers

The only trouble might be the time, physically spent on processing the urc responses, since it actually delays processing the simultaneously active AT command. This wouldn't delay data reception, but might influence timeouts of the defined commands. (for example, if we're sending AT+CGC\r with timeout of 500ms and spend 600ms on urc processing, then it would fail, but should still work if we spend like 450ms on urc-processing, as the actual reply would simply queue so the data handler should make it in time)

[VasilNikolovRilabs]

Hello David,

thank you for the detailed explanation, what you really describe is a very good approach for the URC and it really makes sure that the command handling will not be broken. As last takeout from your notes – we need to make sure that the URC handler is a very short and thus we will not impact the timeout handling of the AT commands.

Thank you again for the support!

Best Regards, Vasil Nikolov CEO and CO-Founder

Email: @.@.> Phone: +359 888 200510

Banat 1 1407 Sofia Bulgaria

@.***

www.rilabs.iohttp://www.rilabs.io/

From: david-cermak @.> Sent: Thursday, March 2, 2023 6:14 PM To: espressif/esp-protocols @.> Cc: Vasil Nikolov @.>; Comment @.> Subject: Re: [espressif/esp-protocols] Implement URC Handling. (IDFGH-8812) (Issue #180)

Hi Franz and Vasil,

sorry for not responding earlier. The example of injecting a URC callback doesn't really change anything in the esp_modem layers, it just overrides the default command implementation using these two methods:

1. Traditional method for sending commands makes the class command-able, so it could be employed by the command library to run all/defined AT commands:

https://github.com/espressif/esp-protocols/blob/c61fe1f5f915b2d39dda81ea8ce701660991194c/components/esp_modem/examples/modem_console/main/my_module_dce.cpp#L51

1. The data callback that processes the replies

https://github.com/espressif/esp-protocols/blob/c61fe1f5f915b2d39dda81ea8ce701660991194c/components/esp_modem/examples/modem_console/main/my_module_dce.cpp#L70

This way, we're able to

• first call the user urc-callback (and after that)
• continue with processing the replies by the command library

---

a. For me it is important to understand how modem implementation differentiates between URCs and a normal response to AT commands

we process the user callback first

https://github.com/espressif/esp-protocols/blob/c61fe1f5f915b2d39dda81ea8ce701660991194c/components/esp_modem/examples/modem_console/main/my_module_dce.cpp#L73-L75

...and then let the command library to parse the same data.

https://github.com/espressif/esp-protocols/blob/c61fe1f5f915b2d39dda81ea8ce701660991194c/components/esp_modem/examples/modem_console/main/my_module_dce.cpp#L76-L87

i. There are commands which require longer time until a response is received.

You need to be aware that the urc handler would still received all the replies, including the ones that belong to unrelated commands issued by the command library (by user)

b. Can we receive URCs while we are waiting for a response to a certain AT Command?

Yes, the urc-handler gets always called (if enabled). The other part (lib-command processing) is called only if an AT command is in progress.

i. If yes then how can we be sure that responses to the AT Commands are forwarded to the URC handler instead to the command handler

This works like a fork (tee command in bash :-), we pass the same data to two handlers

The only trouble might be the time, physically spent on processing the urc responses, since it actually delays processing the simultaneously active AT command. This wouldn't delay data reception, but might influence timeouts of the defined commands. (for example, if we're sending AT+CGC\r with timeout of 500ms and spend 600ms on urc processing, then it would fail, but should still work if we spend like 450ms on urc-processing, as the actual reply would simply queue so the data handler should make it in time)

— Reply to this email directly, view it on GitHubhttps://github.com/espressif/esp-protocols/issues/180#issuecomment-1452137962, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AISW2OROTO7EKPSAGUUAFNTW2DBNXANCNFSM6AAAAAASKKZCCY. You are receiving this because you commented.Message ID: @.@.>>

[franz-ms-muc]

https://gist.github.com/franz-ms-muc/b28a70d42a86bb2ed292e638a11fa152

i test the URC HAndler now in the CMUX Sample.
it is installed in this Line: https://gist.github.com/franz-ms-muc/b28a70d42a86bb2ed292e638a11fa152#file-gistfile1-txt-L257

but then never called. However, as i have extended Logging active, i see the URCs are coming in.

however when i was testing it with the Console Sample it was working.

think there is something to fix still.

[franz-ms-muc]

another Log with Net: https://gist.github.com/franz-ms-muc/454ecbf8fbbfabfaeb27f68b54ea98b3

[franz-ms-muc]

@david-cermak did you look into this ?

[david-cermak]

@franz-ms-muc Could you please also share the code where you install the handler? Note that the change has already been merged to master (and release as modem-v1.0.0), so you should be able to play with URC directly in the console example. Does it work for you in the default example?

[franz-ms-muc]

Ah, thanks, i will look into the new master. Cool.

Von: david-cermak @.> Gesendet: Dienstag, 21. März 2023 17:57 An: espressif/esp-protocols @.> Cc: Franz Höpfinger @.>; Mention @.> Betreff: Re: [espressif/esp-protocols] Implement URC Handling. (IDFGH-8812) (Issue #180)

@franz-ms-muchttps://github.com/franz-ms-muc Could you please also share the code where you install the handler? Note that the change has already been merged to master (and release as modem-v1.0.0https://github.com/espressif/esp-protocols/releases/tag/modem-v1.0.0), so you should be able to play with URC directly in the console example. Does it work for you in the default examplehttps://github.com/espressif/esp-protocols/tree/master/components/esp_modem/examples/modem_console?

— Reply to this email directly, view it on GitHubhttps://github.com/espressif/esp-protocols/issues/180#issuecomment-1478253793, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQSZUH2UNRFN3WNLQAD346DW5HMUHANCNFSM6AAAAAASKKZCCY. You are receiving this because you were mentioned.Message ID: @.@.>>

[https://www.meisterschulen-mchn.de/images/meisterschulen/allgemein/4-logos/logofc.jpg]

Meisterschulen am Ostbahnhof Mühldorfstr. 6 81671 München

Tel.: 089 416002 - 0 Fax: 089 416002 - 111

Internet: www.meisterschulen-münchen.dehttp://www.meisterschulen-mchn.de

[david-cermak]

Could you please close this issue if it work for you? Or comment and share the details if URC handling doesn't work as expected.

[diplfranzhoepfinger]

hi,

i tested like this:

use this Commit: https://github.com/diplfranzhoepfinger/esp-protocols/commit/0a33ce531c5543391e32cf2296423709ae660b32

and the Outcome is this Log: https://gist.github.com/diplfranzhoepfinger/73da3e69cbee3edbaaa61def2f50eba1

+CGNSSPWR: READY!

is a URC. it is not handeled by the URC Handler.

[diplfranzhoepfinger]

making another Try:

https://gist.github.com/diplfranzhoepfinger/6a3062d8861535f2b3927cdc6e5d299f

there the URC Handler works.

it seems the URC HAndler only works on "cmd xx" and not on "build in" commands.

pls look into this. Thanks ! Franz

[diplfranzhoepfinger]

@david-cermak can you have a look into this ?

Thanks!

[diplfranzhoepfinger]

so, Test also URC Handling with latest Sample:

https://github.com/diplfranzhoepfinger/esp-protocols-tree-master-components-esp_modem-examples-simple_cmux_client

[diplfranzhoepfinger]

at least seems working:

https://github.com/diplfranzhoepfinger/esp-protocols-tree-master-components-esp_modem-examples-simple_cmux_client/tree/feature/URC_Handling

[diplfranzhoepfinger]

https://gist.github.com/diplfranzhoepfinger/359e821d89635118333169d75226fe55

[diplfranzhoepfinger]

with the A7672 it does not work:

see https://github.com/diplfranzhoepfinger/esp-protocols-tree-master-components-esp_modem-examples-simple_cmux_client/tree/feature/A7672_gnss

[diplfranzhoepfinger]

Try to switch to "Shiny" again:

https://github.com/diplfranzhoepfinger/esp-protocols-tree-master-components-esp_modem-examples-simple_cmux_client/tree/feature/shiny_again

[diplfranzhoepfinger]

so we have:

URC Handler working:

https://github.com/diplfranzhoepfinger/esp-protocols-tree-master-components-esp_modem-examples-simple_cmux_client/tree/feature/shiny_again

URC Handler not working:

https://github.com/diplfranzhoepfinger/esp-protocols-tree-master-components-esp_modem-examples-simple_cmux_client/tree/feature/A7672_gnss

[diplfranzhoepfinger]

@david-cermak can you have a Look into this:

maybe the Inheritance is core of this Problem. 

esp_modem::GenericModule --> MyShinyModem

versus

esp_modem::GenericModule --> esp_modem::A7600 --> A7672_gnss

is the 3-stage Design avoid the URC Handler to work ?

[diplfranzhoepfinger]

diplfranzhoepfinger/esp-protocols-tree-master-components-esp_modem-examples-simple_cmux_client@b018980

[diplfranzhoepfinger]

Hi, 

https://gist.github.com/diplfranzhoepfinger/780f68da1da1e73565d3a63bccdf9836

removing the URC Handler before switching modes did help to get it running also in CMUX Mode. 

see Commit: diplfranzhoepfinger/esp-protocols-tree-master-components-esp_modem-examples-simple_cmux_client@b018980