我希望通过7位编码短信接收二进制数据到我的PC / GPRS-Stick（来自4G Systems的XS Stick P14）。
这在原则上很好，但是如果我发送二进制<linefeed> - 字符（0x0A），GPRS-stick会将其更改为：
<carriage retrun> + <linefeed>（0x0D0A）
考试：
如果我发送此二进制十六进制值：000102030405060708090A0
我多了一个字节：000102030405060708090 D0 A0
我不明白这种自动替换...是否可能不允许通过7-bit SMS发送<linefeed>字符，或者我是否必须通过特殊的命令配置调制解调器？
最好的问候
安德烈亚斯
答案 0 :(得分：2)
所以你正在用AT命令AT+CMGL（或AT+CMGR）阅读收到的短信，对吧？我假设您正在以文本模式（AT+CMGF=1）阅读它。在返回的<data>参数中，您的调制解调器会在\r前面插入额外的\n。
AT+CMGL的信息文本回复specified围绕邮件内容"\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，它也会强制执行十六进制响应（参见this answer）。
如果这些都没有帮助，您可以更改为以PDU模式读取消息（例如AT+CMGF=0）。这只是通过空中传输的每个比特的SMS消息的原始转储，如果调制解调器设法在那里插入任何额外的\r字符，我会感到震惊。然后你最终必须在收到它之后解码它（不是很简单，找一些已经写好的库），但至少它应该有用。