LoraWAN论坛
标题:
LoRaWan终端如何处理通信碰撞?
[打印本页]
作者:
dreamchaser
时间:
2017-10-17 23:11
标题:
LoRaWan终端如何处理通信碰撞?
如题,LoRaWan终端该如何处理通信碰撞?
作者:
BeyondDream
时间:
2017-10-22 15:02
本帖最后由 BeyondDream 于 2024-1-4 09:42 编辑
[attach]562[/attach]
请参考《扩展 LoRa 容量_降低冲突丢包》
http://www.rimelink.com/nd.jsp?fromColId=107&id=48#_np=107_316
作者:
BeyondDream
时间:
2017-10-22 15:03
本帖最后由 BeyondDream 于 2023-8-10 07:51 编辑
在中国,仅有一个“
单次发射持续时间:不超过
1
秒
”的限制,这很可能会导致“信道拥塞”的问题。
作者:
BeyondDream
时间:
2017-10-22 15:04
所幸的是,LoRa 信号是正交设计,即不同 SF 的信号互不干扰。因为 LoRaWAN 支持 SF7-12,这 6 个“不同速率”的信号不会冲突。
作者:
BeyondDream
时间:
2017-10-22 15:10
另外,无线电信号在空中传播随着距离的延伸会衰减,即使是“同频同速”的 LoRa 信号,只要“强信号”比“弱信号”大于 6dB,那么,接收器能正常解码。
换一句话说,“弱信号”(低于 6dB )不会干扰“强信号”的接收解码。
更多详情,请参考《an1200.22 LoRa Modulation Basics》
http://www.rimelink.com/nd.jsp?id=32#_np=107_316
作者:
BeyondDream
时间:
2018-9-18 08:43
本帖最后由 BeyondDream 于 2024-5-14 09:54 编辑
无线通信,当有多个设备同时发射时会冲突,解决办法有:FDMA(频分复用),CSMA(载波侦听),CDMA(码分多址),TDMA(时分复用),SDMA(空分复用)
一般,使用的方法是:
FDMA(频分复用),LoRaWAN就是,SX130x 有 8 信道,节点随机选择通道,避免冲突(实例=LoRaWAN)
CSMA(载波侦听),从节点侦听信道空闲,立即发射,如失败(没有ACK)随机延时重传(实例=Wi-Fi)
CDMA(码分多址),收发设备采用相同的“伪随机码”进行扩频通信,通过“编码”差异化避免冲突(实例=3G、4G)
TDMA(时分复用),从节点,按时隙,一个接一个来,避免冲突(实例=2G)
SDMA(空分复用),电信的蜂窝就采用该技术,功率不相干扰的无线电物理区域,可以使用相同频率(实例=蜂窝无线)
作者:
VectorLi
时间:
2018-10-10 09:49
都是干货啊
作者:
BeyondDream
时间:
2019-9-4 14:41
[attach]282[/attach]
[attach]283[/attach]
[attach]284[/attach]
作者:
BeyondDream
时间:
2019-9-19 11:52
应用层上做“冲突避让”也有价值。
如表计集抄,让各表计错开上报时间,部署时通过服务器进行配置,开发起来耦合度比较大,而且配置周期很长,也不能完全保证统一,所以一般都是在应用上做容错,如果实在需要可靠,就牺牲用一下确认帧。
如智慧消防,设备做一下边缘处理,不要紧消息不要求可靠,同时可以做成包含历史数据上报(以防应用错过数据块),二如果涉及到需要可靠情况,比如温度突然上升,疑似火灾,切换为确认帧上报,并重试。
缺点:在工程部署上需要能够对整个群体进行初始化配置。
作者:
GAGA
时间:
2019-11-28 13:29
BeyondDream 发表于 2019-9-4 14:41
[attach]306[/attach]
你好,我关于ADR的测试效果是,比如二环的位置正常扩频因子是10,但是由于一些因素(天气,人流,车流等),节点发送的扩频因子在ADR的作用下会调整,有时调整到7,网络不稳导致丢包。
经过一番调整,降到10又可用。但是由于各类因素的存在,节点可能会持续经历此类调整过程,这类调整过程势必影响数据传递,请问这个该如何考虑?
作者:
BeyondDream
时间:
2019-11-28 14:01
“节点可能会持续经历此类调整过程“ --- ADR 打开后,节点速率根据信号质量变化,这本来就符合设计初衷。
”这类调整过程势必影响数据传递” --- 没有明白什么叫“数据传递”??
欢迎光临 LoraWAN论坛 (http://lora.timeddd.com/)
Powered by Discuz! X3.3