人的反应时间可以认为是0.1s（你可以打开手机计时器，看看双击按钮的间隔计时），即100ms，即无线命令系统需要在100ms内完成一次命令通讯（忽略单片机执行其它代码消耗的时间）。一次命令通讯至少需要两个数据包，发送方发送命令数据包，接收方接收到数据包后回复一个ack数据包。考虑到WOR（Wake-on-Radio）是间歇性的打开收发，考虑命令执行方，即接收方的情况（发送方肯定是发送的时候才开启TX啊），时间间隔如下图:
WoR时间片图例
Xtal是系统晶振，一般是高频的，比如说12Mhz，16Mhz，此晶振开动的时候耗电比较大，RC Osc是内部时钟晶振，一般是32.768khz，专门用来计时的，GIO1是一个用来指示内部状态的管脚。为了省电，启动了WOR模式，系统高频时钟Xtal停止了震荡，系统进入低功耗模式（睡眠模式），此时，为了自动唤醒系统，低频的时钟一直运行，因为频率低，所以省电，一定时间后，高频时钟被唤醒，运行RX模式，查看有无命令数据包收到。睡眠模式的时间占一个周期的时间，就是剩下的功耗比例。比如说100ms睡眠90ms，接收状态只有10ms，则功耗是原来的1/10。
初一看是这么回事，但是这个模式带来了两个问题：一，发送命令方，时间变长，实时性下降，功耗变大，第二，同样字节数的命令包，速率变大，导致通讯距离变近。第三，如果通讯双方都是用WoR，那将是一个非常复杂的时间逻辑。
RX方，100ms内90ms睡眠，因为TX方不知道RX方能否接收到10ms内的命令，只有发送100ms时间长度，并且命令数据包（假定不考虑唤醒包，syn等）要在5ms内完成（否则10ms的命令时间窗口会错位）。相当于RX方省电，但是耗电重担都抛给TX放了，是一种责任转移，RX睡眠，则TX就得多发，平衡的。如果系统的TX方是不使用电池供电的，则要考虑的是对信道的占用时间，导致整个系统的实时性，系统节点容量数下降——无论如何，系统参数都要做出牺牲。
这些并不是致命的，最致命的在于通讯的速度与通讯距离成反比，即通讯速度越慢，通讯距离越长。长距离低频通讯中，数据一般只有10kbps内，比如说lora宣称通讯距离十多公里，但是这个结果是在通讯波特率300bps，天线良好的情况下计算的，实际上基本无法使用。数据包必须包括同步位，id位，加密位，命令位，crc位，300bps无法保证0.1s内完成一次交互，并且留有足够的容错，所以lora等等只能用于低频的应用——非重要的非高价值的应用。假定数据包一包10byte，则5ms要完成10byte需要的速度为10*8*（1000/5）=16000=16kbps。初看这个数据不大，但是当使用DSSS时，其占用的带宽是*8=128khz，0.1s实时性，占用信道128khz是一个很大的数，假定有10个信道则需要1280khz=1.28Mhz。实际上一般的陶瓷天线根本提供不了如此宽的带宽特性。
既然如此，为什么WOR还被认为是一种重要的节能技术呢？答案是，当不考虑通讯距离，使用高频率通讯，比如说广泛使用的2.4Ghz时，优势就会显明，因为其速度较大，所以完全可以使用10ms一个周期，9ms睡眠，1ms接收这种模式来实现，而因为其带宽一般比较大，所以信道、带宽也不是问题。所以基于2.4Ghz的众多无线网络技术都支持WOR这项功能。当然，在远距离，窄带宽，低速率高实时，低功耗的要求下，这种矛盾转移的方法就没法用了。
注：我们正在开发远距离无线命令摩块。探讨可以发邮件给我：
seacer@protonmail.com
作者： 用户3895730， 来源：面包板社区
链接： https://mbb.eet-china.com/blog/uid-me-3895730.html
版权声明：本文为博主原创，未经本人允许，禁止转载！
EE直播间
更多
-
第三代功率半导体器件测试解决方案 直播时间： 03月06日 10:00
关闭
站长推荐
/3 
/3
文章评论（0条评论）
登录后参与讨论