Special URC handling in cellular interface

I’m facing an URC from my Telit ME310G1 modem can’t be handled by the library…

using sockets, the modem send URC like “SRING: 1” when data arrives…

i tryed lots of configuration without success.
After checking the code, i suspect the lib is not able to handle this URC at all… :sleepy:

is someone can help me for that ?

Thank a lot !

Can you try to use the generic URC callback - FreeRTOS-Cellular-Interface/source/include/cellular_api.h at main · FreeRTOS/FreeRTOS-Cellular-Interface · GitHub?

It looks like the SRING: x is being treated as an undefined message rather than a unsolicited message. What does your pCellularUrcTokenWoPrefixTable look like?

@rickou

It looks like SRING: x is the URC to indicate that data is ready to be received from the socket buffer.
Once SRING: x is received, you should call the callback function registered with Cellular_SocketRegisterDataReadyCallback to notify application to receive from the socket.

The problem is that the URC SRING: x doesn’t start with + leading char. This causes the library to regard this line as undefined response and delegate the handling of this line to the cellular modem port through undefined message callback. The cellular modem port can handle the undefined message in the callback.

You can reference the SARA-R4 +UUSORD URC handler implementation for your undefined message handler implementation.

1 Like

Hello !
i already take as a reference the SARA-R4 source :slight_smile:

i understood this URC is not handled by the lib and also seen i can use the undefined message callback but before writing code, i prefered asked here if there is other config to do for this case.
in the meantime, i tried with a homemade workaround… :smiley:
defining “S” as a leading prefix, and “RING” in the URC callback table…
That’s works like a charm… :smiley: but honestly, its not satisfying…

in fact i do not understand the behaviour of identifying an URC by the leading char… all modems have differents leading chars (and some not…) and for compatibilities, i think it could be better the library should not take care about this leading char but the whole frame header…
i haven’t understood the benefits of this…

i will implement the undefined message callback for my modem.

Hi again !

again with URC not handled…
here i do not understand why the URC (not really an URC) “NO CARRIER” is not handled in all cases… same for all errors frames…

This response comes always as AT UNDEFINED …
for sur the differents arrays defining URCs are well defined…

Honestly I’m a little bit frustrated with the behavior of the lib…
if i need to redefine all internal functions outside… :thinking: