有项目需要一主多从单向接收？可以试试这个！
前言
由于博主自身之前也只有一对一的LoRa模块使用经验，以下内容也是边做边学所记录的内容。仅供参考。
TIP
部分内容摘自「トランジスタ技術2019年6月号」。
关于LoRa
它的优势是什么？
LoRa调制是扩频通信的另一种形式。与常规的伪随机噪声码（PN码）不同，LoRa使用的是啁啾扩频的方式。
这种方式既能提高单位频带内的能量密度，还能利用较宽的频带。
这会带来两个明显的好处：
1、更高的功率密度=更好的信噪比；
2、更宽的频带=更强的抗衰能力及抗多普勒能力。
这种技术在雷达中的应用要更早。正如上文所述，啁啾信号可以提高单位频率的能量密度，所以即便信号微弱，也可以提高信噪比，这种特性使其十分适合作为地下探测雷达。
同样的，为了提高毫米波雷达在时间方向的分辨率，也同样会使用啁啾信号。
它的劣势是什么？
作为更远通信距离与更强抗衰的代价，它也有着以下缺点：
1、原始传输速率通常只有几十kbps，难以满足音视频信号的传输要求。
2、会受到占空比限制（取决于当地频段及法规）。
3、抗干扰能力不是绝对的，在某些情况下依然会失效。
所以，它更适合应用在较小数据量、且对延迟不敏感的项目上。
LoRa的扩频
对于LoRa信号的扩频，SF（扩频因子）是很重要的概念，取值为7至12。
当 SF=7 时，代表着一个符号可以表示128种数值。简单的说，LoRa把一个符号时间分成128个可能的位置。
根据频率从高频跳回低频的那个时刻不同，所代表的数据值也就不同。即：数据值是由啁啾信号的跳变时机来表示的。
在此之上，如果BW是扫频宽度，
那核心关系就是：
例如，跳的早时，可能表示数据0，跳在中间，可能表示64，跳的很晚，可能表示127。
当SF=7，BW=500kHz时，
当SF=12,BW=7.8kHz时，
所以，SF越大→单个符号能表示的信息就越多→抗干扰能力更强→符号时间
BW越大→扫频越快→一个符号时间越短→符号时间
因此，在了解这个原理的前提下，根据具体需求使用不同参数配置LoRa模块才会达到最好的效果。
为什么很弱的LoRa信号也能被正确接收？
前面提到，LoRa是通过SF与BW来决定一个符号的持续时间。
实际上这也就意味着符号时间越长，接收端就有更多时间去“观察”这个信号。
类似于用频谱仪看信号。如果把RBW调窄，再多做几次平均，虽然刷新速度会变慢，但原本埋在噪声里的小信号，反而可能慢慢从噪声底里自己冒出来。
LoRa在接收过程也有类似的情形。
接收端会把收到的啁啾信号和本地生成的参考啁啾信号做处理，再通过类似FFT的方式找出频率峰值。
这样一来，只要参数匹配，真正的数据位置就会表现为一个明显的峰。
综上所述，LoRa不是单纯靠“强信号”来通信，而是通过扩频、解扩和较长的符号时间，把原本很弱的信号从噪声中分辨出来。
这也是为什么SF越大，通信距离就相对更远，但作为代价速度也会变慢。
因为SF变大后，符号时间变长，接收端有更多时间去处理这个符号，代价就是单位时间内能传的数据变少。
同一个频段中的多个LoRa信号为什么能分离？
LoRa还有一个特性。即不同SF或不同BW的信号，在一些条件下可以互不干扰，或者说干扰较小。
原因是它们的啁啾信号扫频方式不一样。
当接收端在解调时，只会用自己预设的SF和BW去匹配信号。
当收到的信号参数和本机设置不匹配时，经过解扩和FFT之后，它就不会形成一个稳定且明显的峰。
简单地说：
参数匹配的信号，会被接收端“看见”；
参数不匹配的信号，在一定条件下会被当成背景干扰忽略掉。
这种现象通常会用正交性来描述。
它可以理解成：虽然你我都在同一个频段里发射，但由于扩频参数不同，接收端仍然有机会把它想要的那一路信号分离出来。
但是，不同 SF/BW 并不代表一定完全互不干扰。
特别是当某些SF和BW的组合刚好让啁啾信号的频率变化斜率接近，此时接收端在FFT时仍然可能产生假的峰值。
而这个假峰值会让接收端误以为收到了有效数据，从而造成干扰。
所以，在做一主多从、多个节点同时发送的设计时，不能简简单单地认为“只要我给每个从机分配不同的SF就可以”。
最终效果还需要看SF、BW、频点、发送时间、距离远近以及模块自身的接收能力。
这对一对多接收有什么意义？
对于一主多从的LoRa项目来说，如果所有从机都只是偶尔上传一点小数据，那么LoRa确实很适合这种工作。
在这种需求下，主机只需要一直监听，收到谁的数据就解析谁的数据。
但如果多个从机都在同一时间发送，主机就可能会出错。
常规单通道LoRa模块在某个时刻只能按照当前设置的SF、BW、频点去接收一路信号。
如果你希望主机同时接收不同SF或不同频点的多个从机数据，那么主机端通常需要使用多个接收通道，或者类似LoRaWAN网关的多通道方案。
当然，如果节点数量不多，数据量也不多，那么也可以考虑单通道LoRa+时分的方案，但是这部分内容并不在这篇博文的讨论范围内。
