Cellular Library - Need Help Implementing Multiline Binary SocketRecv Data

Hello All,

I am using Thales (Telit now) Cinterion PLS63 Modem.
I am having issues modeling how to parse and receive data while using sockets.
The response is in the following from:
c - Channel
n - Number of Bytes
// Request
\r\nAT^SISR,0,n\r\n
// Response
\r\n^SISR,0,n\r\n(n bytes of data)\r\nOK\r\n

I tried to model this issue with CELLULAR_AT_MULTI_DATA_WO_PREFIX because the second line doesn’t have any prefix just data.
However, \r or \n characters on the binary data are also considered as new lines and the response linked list skips them over just getting other characters in the stream.

Can someone help me figure out how I can model this type of read with the library?

Thank you,
Tuna

Where is your binary data?

I put it inside < > and it didn’t seem to show up. Markdown didn’t like that. Edited the post to indicate the data with ()

I managed to implement something from looking at the other modems but It would be nice to understand which error codes to return on the prefix function.
Is that covered on the porting guide?

It took some trial and error to understand how prefix function should work especially when receiving a non matching line.

I am basically in the same boat as you. I am trying to adapt library to a different modem and struggling with some of the the details so I’m probably not able to be of much help. I saw your question when I was about to post one but my issue is a little different. Regarding yours I think CELLULAR_AT_MULTI_DATA_WO_PREFIX is the only type you can use because I think it’s the only one that works for binary data. If the \r\n around the data is an issue you can probably use lenght+2 and then discard them later. In any case I would say your modem conforms to the library assumptions so it should work or can be made to work.

That is exactly what I ended up doing.

To help other people that might find this thread the steps I took are:

Add a prefix function for socket receive:

  1. Check for prefix with either string functions or StartsWith function from the Cellular lib. If there is no match still return success since you got a URC.
  2. Parse the length from tokens. (GetTok functions change the original buffer so either make a copy or parse without changing pLine).
  3. Check that length is positive and less than max size. For my case negative is actually normal and returned to indicate connection has been closed so I only check for max value and return modem error on negative length.
  4. Point data start to first byte on pLine that would point to the binary data(after comma or \r\n on my case) and set the length from received length field on AT Command.

Then on the regular parse function the AT response will be on the first line and second line will have binary data. Parse the same way and memcpy the binary data to the output buffer.

As mentioned before CELLULAR_AT_MULTI_DATA_WO_PREFIX option is used together with
_Cellular_TimeoutAtcmdDataRecvRequestWithCallback function of the library.

Hope this helps someone that is going through the same issue :slight_smile:

1 Like

Thanks for that information it will be helpful to me. I’m currently evaluating the library so I’m not doing a thorough adaptation in case I don’t use and will have to revisit these details if I do.

Hi All,

@tbicim Thank you for your feedback. Your reply looks great to me.

I share more information about the data prefix callback function.

The purpose of this callback function is to indicate the start and length of the binary data. The prefix callback function in the input parameters of _Cellular_TimeoutAtcmdDataRecvRequestWithCallback can returns the following value to cellular lib:

  • CELLULAR_PKT_STATUS_OK without setting pDataStart and pDataLength - The cellular modem will continue to process this line.
  • CELLULAR_PKT_STATUS_OK and set pDataSTart, pDataLength -
    The is the case the data prefix is received correctly. The cellular lib will continue to process this line. The data after pDataStart won’t be parsed and will be stored in the response.
^SISR,0,n\r\n
(n bytes of data)\r\n  // pStartData should point to the position of the first byte of binary data in pLine and pDataLength is n
OK\r\n
  • CELLULAR_PKT_STATUS_SIZE_MISMATCH - This is the case the prefix function needs more data to figure out the pDataStart and pDataLength. Returning this value can stop the cellular lib from further processing this line. The callback function will be called again when more data received. The following is an example.
^SISR,0, // "n\r\n" is not received yet. Prefix callback can't decide the length of the binary data.
  • Other return value to indicate errors.

Thank you again for your response in this thread.

1 Like