Sms 接收7Bit二进制短信

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

+

（0x0D0A）

例如：

如果我发送此二进制十六进制值：

000102030405060708090A0

我又得到一个字节：

000102030405060708090

D0

A0

我不明白这个自动替换。。。是否可能不允许通过7位SMS发送

-字符，或者我必须通过特殊at命令配置调制解调器

致意

---

安德烈亚斯

那么你是在用AT命令

AT+CMGL

（或

AT+CMGR

）阅读收到的短信，对吗？我假设您正在以文本模式阅读它（

AT+CMGF=1

）。在返回的

参数中，调制解调器会在

\n

前面插入一个额外的

\r

，如果有的话

AT+CMGL

的信息文本响应在消息内容周围有

“\r\n”

，例如

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

…[。。。

，可能实现者对最后只有一个

\n

感到不舒服，决定放弃它（或者可能是一个bug？）。插入

\r

是否会发生在

\n

的任何位置

有趣的是，27.005没有讨论如果

包含

。。。 下面是这样说的：

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

通常，扩展语法命令返回的信息文本格式应为 请注意，DCE 可以在很长的信息文本中插入中间字符 响应，以避免DTE接收缓冲区溢出。如果 包括中间字符，DCE不应包括 字符序列“0”（3/0，0/13）或“OK”（4/15，4/11， 0/13），这样DTE就可以避免错误检测到这些端点 信息文本回应

您的场景似乎不是太长的响应文本，但是 有趣的是，DCE（又称调制解调器）似乎相对简单 可以在需要时自由插入

无论如何，如果我认为您在文本模式下阅读是正确的，我建议您尝试将字符集更改为十六进制（

AT+CSCS=“hex”

）。这可能会使调制解调器在插入方面表现出不同的行为（或者可能没有）。如果没有，您可以尝试UCS-2，它也会强制十六进制响应（请参阅）

---

如果这些都没有帮助，您可以更改为在PDU模式下阅读邮件（例如，

AT+CMGF=0

）。这只是通过无线传输的每一位的SMS消息的原始转储，如果调制解调器设法在其中插入任何额外的

\r

字符，我会感到震惊。然后，在收到它后，你必须解码它（不是很小，找一些已经编写的库），但至少它应该可以工作。

如果您想通过7位ASCII通道发送二进制文件，那么最好将其编码为可打印的ASCII字符，例如，这样您就不会遇到控制字符的问题，当然它会考虑到您缺少第7位的事实。感谢您有趣的替代方法，但我ant可以使用完整的SMS容量，如果可能，不需要任何开销