接收7Bit二进制短信

我想通过一个7位编码的SMS接收二进制数据到我的PC/GPRS棒（来自4G系统的XS棒P14）。，原则上精细的工作，但如果我发送二进制<linefeed>个字符数字符（0x0A），GPRS的棒将其更改为：接收7Bit二进制短信

<carriage retrun> + <linefeed>（0x0D0A）

Examle：

如果我送这个二进制十六进制值：000102030405060708090A0

我得到一个字节更多：000102030405060708090D0A0

我不明白这个自动更换......是否可能不允许通过7位SMS发送<linefeed> -characters字符，还是必须通过特殊的at-commands命令配置调制解调器？

问候

安德烈亚斯

来源

2013-04-11 Andreas

如果您想通过7位ASCII通道发送二进制文件，那么最好将其编码为可打印的ASCII字符，例如， [UUENCODE]（https://en.wikipedia.org/wiki/Uuencoding）。这样你就不会遇到控制字符的问题，当然它会考虑到你错过了第7位的事实。 – 2013-04-11 09:25:14

谢谢你有趣的替代方法，但我想使用完整的SMS容量，没有任何开销如果可能 – Andreas 2013-04-11 09:48:08

所以，你正在阅读与AT命令AT+CMGL（或AT+CMGR）接收到的短信，对不对？我假设你正在以文本模式阅读它（AT+CMGF=1）。在返回的<data>参数内，如果有调制解调器，则在\n之前插入额外的\r。

关于AT+CMGL的信息文本响应为specified，其在消息内容周围具有"\r\n"，例如，在末端的单个\n

...<CR><LF><data>[<CR><LF>...

，也许实施者觉得不舒服，并决定丢弃（或者它是一个错误？）。插入\r是否发生在\n的任何位置？

有趣27.005不讨论如果<data>包含<CR><LF>会发生什么...... 在V.250以下是说：

5.7.3信息文本格式的测试命令

在一般情况下，由扩展语法命令返回的信息文本格式应在命令的定义中指定。 ...请注意，DCE 可能会在非常长的信息文本响应中插入中间字符，以避免超出DTE接收缓冲区。如果包含中间字符，则DCE不得包含字符序列“0”（3/0,0/13）或“OK”（4/15，4/11， 0/13），以便DTE可以避免这些信息文本响应结束的错误检测。

你的情况似乎不是太长响应文本，但有趣的是，DCE（又名调制解调器）似乎是相对自由插入<CR>时感觉。

无论如何，如果我假设你正在阅读文本模式是正确的，我会建议尝试将字符集更改为十六进制（AT+CSCS="HEX"）。这可能会使调制解调器的行为与插入\r（或者可能不会）有所不同。如果不是的话，你可以尝试UCS-2，它也强制执行十六进制响应（见this answer）。

如果这些都不起作用，您可以更改为以PDU模式读取消息（例如AT+CMGF=0）。这只是通过无线传输的每一位SMS消息的原始转储，如果调制解调器设法在其中插入任何额外的\r字符，我会惊讶地震惊。然后你最终必须在收到它之后解码（不是微不足道的，找一些已经写好的库），但至少它应该可以工作。

来源

2013-04-11 15:36:35 hlovdal

接收7Bit二进制短信

回答

相关问题