I working with a BGS2-W modem. I have a C app writing AT commands to the modem. The responses of the modem look something like \r\n OK or \r\n\n OK. Anytime I receive a \r or a \n, I consider that the end of the modem at response.
Issue is I am attempting to download a binary file through HTTP GET and the binary file can and does contain '\r' and '\n'. This is causing issues when I try to parse the modem responses.
Anyone ever experience this problem? Thanks.
On
I found something from this file, page 237, there is a HTTP download example.
When using AT^SISR=4,[reqLength], from 1st line of response there is the length of data available. From here, you should use this data length, but not \r or \n as end mark.
From page 208, there is more explanation of ^SISR.
On
Generally most of the modems have a command mode and a data mode (source: https://en.wikipedia.org/wiki/Command_and_Data_modes_(modem)). When host sends a command to invoke data mode, modem sends a "CONNECT" response and then you are supposed to interpret data as it is. Please use the same concept while writing your C code. It's good to write your own code but may I suggest that you find a open source library which takes care of most of this stuff.
You should not consider \r or \n as a modem answer, since those characters might come as legitimate data exchange both in binary files, ascii files or just the header of an http message.
The AT+RECV or whatever similar command that your modem uses to receive data must have a field that specify the amount of data received, then comes the data and then the OK string.
Focus on parsing the field as a whole, so that you ignore those special characters within the expected data.