1

我想通过 7 位编码的 SMS 将二进制数据接收到我的 PC/GPRS-Stick（来自 4G 系统的 XS Stick P14）。这在原则上可以正常工作，但如果我发送一个二进制<linefeed>字符（0x0A），GPRS-stick 会将其更改为：

<carriage retrun>+ <linefeed>(0x0D0A)

示例：

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

我多得到一个字节：000102030405060708090D0A0

我不明白这种自动替换......是否可能不允许<linefeed>通过 7 位 SMS 发送 -characters，或者我是否必须通过特殊的命令配置调制解调器？

最好的祝福

安德烈亚斯

4

1 回答 1

2

AT+CMGL因此，您正在使用 AT 命令（或AT+CMGR）读取收到的短信，对吗？我假设您正在以文本模式 ( AT+CMGF=1) 阅读它。在返回的参数中，如果有的话，您的调制解调器会在前面<data>插入一个额外的。\r\n

信息文本响应AT+CMGL被指定为"\r\n"围绕消息内容，例如

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

，也许实现\n者对最后一个单曲感到不舒服，并决定放弃它（或者它可能是一个错误？）。的插入是否\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，它也会强制执行十六进制响应（请参阅此答案）。

如果这些都没有帮助，您可以更改为在 PDU 模式下阅读消息（例如AT+CMGF=0）。这只是通过空中传输的每一位 SMS 消息的原始转储，如果调制解调器设法在其中插入任何额外的\r字符，我会感到非常震惊。然后，您最终不得不在收到它之后对其进行解码（这不是微不足道的，寻找一些已经编写好的库），但至少它应该可以工作。

于 2013-04-11T15:36:35.693 回答