物联网是个交叉学科,涉及通信技术、传感技术、网络技术以及RFID技术、嵌入式系统技术等多项知识,但想在本科阶段深入学习这些知识的难度很大,而且部分物联网研究院从事核心技术工作的职位都要求硕士学历,“LPWAN实验室”计划从收集、整理、翻译实用的物联网有关的知识着手,帮助各高校物联网专业学生利用这个实验室学习平台找准专业方向、夯实基础,同时增强实践与应用能力。虽然现在面临大学生毕业就业难的情况,但实际各行各业却急需物联网领域相关专业的人才,从目前情况来看,环保、安防、智能交通、农业、医疗推广的可能性最大,这也是成为高校热门专业的一个重要原因。从工信部以及各级政府所颁布的规划来看,物联网在未来十年之内必然会迎来其发展的高峰期。而物联网技术人才也势必将会“迎娶”属于它的一个美好时代。

LoRaWAN协议中文版 第17章 Class C – 持续接收的终端
前言 这是《LoRaWAN102》的译文,即LoRaWAN协议规范 V1.0.2 版本( 2016 年 7 月定稿)。 我正在陆续对协议的各个章节进行翻译,具体其他章节的译文,以及译文之外的代码解析,可点此查看帖子LoRa学习笔记_汇总。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ 翻译开始 第17章 持续接收的终端 具备Class C 能力的终端,通常应用于供电充足的场景,因此不必精简接收时间。 Class C 的终端不能执行 Class B 。 Class C 终端会尽可能地使用 RX2 窗口来监听。按照 Class A 的规定,终端是在 RX1 无数据收发才进行 RX2 接收。为了满足这个规定,终端会在上行发送结束和 RX1 接收窗口开启之间,打开一个短暂的 RX2 窗口,一旦 RX1 接收窗口关闭,终端会立即切换到 RX2 接收状态; RX2 接收窗口会程序打开,除非终端需要发送其他消息。 注意:没有规定节点必须要告诉服务端它是 Class C 节点。这完全取决于服务端的应用程序,它们可以在 join 流程通过协议交互来获知是否是 Class C 节点。 17.1 Class […] Read more.
LoRaWAN协议中文版 第2章 LoRaWAN Classes 类型介绍
前言 这是《LoRaWAN102》的译文,即LoRaWAN协议规范 V1.0.2 版本( 2016 年 7 月定稿)。 我正在陆续对协议的各个章节进行翻译,具体其他章节的译文,以及译文之外的代码解析,可点此查看帖子LoRa学习笔记_汇总。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ 翻译开始 第2章 LoRaWAN Classes 类型介绍 LoRa 是由Semtech面向长距离、低功耗、低速率应用而开发的无线调制技术。本文档中,将 Class A 基础上实现了更多功能的设备称为“更高 class 终端”。 2.1 LoRaWAN Classes LoRa网络包含基础LoRaWAN(称之为Class A)和可选功能(Class B,Class C): 图1.LoRaWAN Classes 双向传输终端(Class A): Class A 的终端在每次上行后都会紧跟两个短暂的下行接收窗口,以此实现双向传输。传输时隙是由终端在有传输需要时安排,附加一定的随机延时(即ALOHA协议)。这种Class A 操作是最省电的,要求应用在终端上行传输后的很短时间内进行服务器的下行传输。服务器在其他任何时间进行的下行传输都得等终端的下一次上行。 划定接收时隙的双向传输终端(Class B): Class B 的终端会有更多的接收时隙。除了Class A 的随机接收窗口,Class B 设备还会在指定时间打开别的接收窗口。为了让终端可以在指定时间打开接收窗口,终端需要从网关接收时间同步的信标 Beacon。这使得服务器可以知道终端正在监听。 最大化接收时隙的双向传输终端(Class C): Class C 的终端基本是一直打开着接收窗口,只在发送时短暂关闭。Class C 的终端会比 […] Read more.
LoRaWAN协议中文版 第1章 介绍
前言 这是《LoRaWAN102》的译文,即LoRaWAN协议规范 V1.0.2 版本( 2016 年 7 月定稿)。 我正在陆续对协议的各个章节进行翻译,具体其他章节的译文,以及译文之外的代码解析,可点此查看帖子LoRa学习笔记_汇总。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ 翻译开始 第1章 介绍 本文档描述了LoRaWAN网络协议,是针对电池供电的终端设备(不管移动还是固定位置)进行优化的一套网络协议。 LoRaWAN网络通常采用星型拓扑结构,由拓扑中的网关来转发终端与后台网络服务器间的消息。网关通过标准IP连接来接入网络服务器,而终端则通过单跳的 LoRa 或者 FSK 来和一个或多个网关通讯。虽然主要传输方式是终端上行传输给网络服务器,但所有的传输通常都是双向的。 终端和网关间的通讯被分散到不同的信道频点和数据速率上。数据速率的选择需要权衡距离和消息时长两个因素,使用不同数据速率的设备互不影响。LoRa的数据速率范围可以从 0.3kbps 到 50kbps。为了最大程度地延长终端的电池寿命和扩大网络容量,LoRa网络使用速率自适应(ADR)机制来独立管理每个终端的速率和RF输出。 虽然每个设备可以在任意信道,任意时间,发送任意数据,但需要注意遵守如下规定: 终端的每次传输都使用伪随机方式来改变信道。频率的多变使得系统具有更强的抗干扰能力。 终端要遵守相应频段和本地区的无线电规定中的发射占空比要求。 终端要遵守相应频段和本地区的无线电规定中的发射时长要求。 twowinter注:发射占空比,意思是发射时长占总时长的比例。按照无线电规定,每个设备不能疯狂发射霸占信道,总得给别人一点机会。 这份文档主要讲述协议细节,一些基于各地区规定的操作参数,例如发射占空比和发射时长等,在另一份文档[LoRaWAN地区参数]中做具体描述。将这份文档分开,是为了加入新地区参数时不影响基础的协议规范。 1.1 LoRaWAN Classes 所有的LoRaWAN设备都必须至少实现本文档描述的 Class A 功能。另外也可以实现本文档中描述的 Class B 和 Class C 及后续将定义的可选功能。不管怎么样,设备都必须兼容 Class A。 1.2 文档约定 MAC命令的格式写作 LinkCheckReq (粗斜体),位和位域的格式写作 FRMPayload (粗体),常量的格式写作 RECEIVE_DELAY1,变量的格式写作 N。 在本文档中, 所有多字节字段的字节序均采用小端模式 […] Read more.
LoRaWAN协议中文版 第3章 PHY帧格式
前言 这是《LoRaWAN102》的译文,即LoRaWAN协议规范 V1.0.2 版本( 2016 年 7 月定稿)。 我正在陆续对协议的各个章节进行翻译,具体其他章节的译文,以及译文之外的代码解析,可点此查看帖子LoRa学习笔记_汇总。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ 翻译开始 第3章 PHY 帧格式 LoRa 有上行消息和下行消息。 3.1 上行消息 上行消息是由终端发出,经过一个或多个网关转发给网络服务器。 上行消息使用 LoRa 射频帧的严格模式,消息中含有 PHDR 和 PHDR_CRC 。载荷有CRC校验来保证完整性。 PHDR,PHDR_CRC 及载荷 CRC 域都通过射频收发器加入。 上行 PHY: Preamble PHDR PHDR_CRC PHYPayload CRC 图2.上行PHY帧格式 3.2 下行消息 下行消息是由网络服务器发出,经过单个网关转发给单个终端。 下行消息使用射频帧的严格模式,消息中包含 PHDR 和 PHDR_CRC。 下行 PHY: Preamble PHDR PHDR_CRC PHYPayload 图3.下行PHY帧格式 3.3 接收窗口 每个上行传输后终端都要开两个短的接收窗口。接收窗口开始时间的规定,是以传输结束时间为参考。 […] Read more.
LoRaWAN协议V1.0.2中文版_配套文件 地区参数(物理层)
前言 这是《LoRaWAN102》的配套文档《LoRaWAN_Regional_Parameters_v1_0》(2016年7月定稿)的中文译文,在早期的LoRaWAN协议中它是以第7章 物理层的形式存在,由于LoRaWAN逐步应用过程中肯定会有很多新区域加进来,为了不影响旧有协议文档主体,所以从V1.0.2版本开始,联盟把这块内容单独出来。 该LoRaWAN官方源文件可点此下载。 我正在陆续对协议的各个章节进行翻译,具体其他章节的译文,以及译文之外的代码解析,可点此查看帖子LoRa学习笔记_汇总。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ 翻译开始 LoRaWAN地区参数 1 介绍 这份文档描述了全球不同地区的LoRaWAN具体参数。这份文档是对LoRaWAN协议文档(从版本V1.0.2开始)的配套补充文档。为了避免新区域的加入而导致文档的变动,因此将地区参数章节从协议规范中剥离出来。 2 LoRaWAN地区参数 2.1 欧洲 863-870MHz 免授权频段 待补充,计划3月份补足。 2.2 美国 902-928MHz 免授权频段 待补充,计划3月份补足。 2.3 中国 779-787MHz 免授权频段 待补充,计划3月份补足。 2.4 欧洲 433MHz 免授权频段 待补充 2.5 澳洲 915-928MHz 免授权频段 待补充 2.6 中国 470-510MHz 频段 2.6.1 中国 470-510MHz 前导码格式 要用如下的同步字: 调制方式 同步字 前导码长度 LoRa 0x34 8 symbols 2.6.2 […] Read more.
LoRaWAN协议解析 第6章 终端激活
1 前言 我正在陆续对《LoRaWAN102》即LoRaWAN协议规范 V1.0.2 版本(2016年7月定稿)协议的各个章节进行翻译。译文之外还对LoRaWAN协议和源码进行了解析,可点此查看帖子LoRa学习笔记_汇总。 欢迎同行朋友们留言交流。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ 2 梳理解析 LoRaWAN第6章,主要对节点加网做了描述,它有两种方式。如果要用一句话来总结的话,那就是这一句了,请看: 如果是空中激活,则需要准备 DevEUI,AppEUI,AppKey 这三个参数,即设备自身MAC地址和要使用的应用(应用ID和密钥)。 如果是ABP激活,则直接配置 DevAddr,NwkSKey,AppSKey 这三个LoRaWAN最终通讯的参数,不再需要join流程。在这种情况下,这个设备是可以直接发应用数据的。 这里插个题外话,商用的LoRaWAN网络一般都是走OTAA流程,这样安全性才得以保证。 (twowinter,你数数,这是一句话?) (如果是空中激活,则需要准备 DevEUI,AppEUI,AppKey来join。如果是ABP激活,则直接配置 DevAddr,NwkSKey,AppSKey。) 3 代码位置 3.1 激活处理 协议的第6章,相关的核心代码是这么几行,位于 \src\mac\main.c。 整个代码结构非常清晰,用一个宏(OVER_THE_AIR_ACTIVATION)分开两段,分别对应两种激活方式。 3.2 参数配置 关于参数部分,相关的默认值全部位于\src\apps\LoRaMac\classA\硬件平台\Comissioning.h 本尊有机会接触了几个LoRaWAN基站厂家,发现大家为了调试方便,一般也会支持这些默认值。 End Read more.
LoRaWAN协议解析 第5章 MAC命令
1 前言 我正在陆续对《LoRaWAN102》即LoRaWAN协议规范 V1.0.2 版本(2016年7月定稿)协议的各个章节进行翻译。译文之外还对LoRaWAN协议和源码进行了解析,可点此查看帖子LoRa学习笔记_汇总。 欢迎同行朋友们留言交流。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ 2 梳理解析 从LoRaWAN第4章的帧格式可以得到如下信息:MAC命令,要么使用FPort0来单独传输,要么使用非零的FPort来和数据一起传输。 LoRaWAN第5章,LoRaWAN出于网络管理需要,提出了9条MAC命令,这个章节是对9条命令进行具体的描述。 说个题外话,CLAA(中国LoRa应用联盟)在9条命令以外还扩充了一些MAC命令。现阶段协议还不能公开,所以我就不多说了。中兴目前作为LoRa联盟董事会成员,也许以后会把这些拓展MAC命令引入到LoRaWAN协议也说不准,大家暂且当个课外知识了解下就好。 3 代码位置 MAC命令枚举 MAC命令的接收处理 OnRadioRxDone()携带着MAC帧进来,经过层层筛选,最终到达ProcessMacCommands()来处理MAC命令。 这里代码中涉及的两种处理方式,可以跟协议对应起来:port = 0时,MAC命令放在FRMPayload中,需要先解密再处理;port非零时,MAC命令放在fopts中。 MAC命令的发送及回复 MAC命令的发送及回复处理都在这个函数中,AddMacCommand()。 协议栈对MAC命令发送的处理还是比较简单的,都是放在Fopts中来传输,都在这个15字节的MacCommandsBuffer中。 Read more.
LoRaWAN协议解析 第4章 MAC帧格式
1 前言 我正在陆续对《LoRaWAN102》即LoRaWAN协议规范 V1.0.2 版本(2016年7月定稿)协议的各个章节进行翻译。译文之外还对LoRaWAN协议和源码进行了解析,可点此查看帖子LoRa学习笔记_汇总。 欢迎同行朋友们留言交流。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ 2 梳理解析 LoRaWAN第4章,主要讲述了MAC帧格式,对所有涉及的字段都做了解释。 千言万语汇成一句话,哦不,汇成一个表。 数据帧头         DevAddr FCtrl FCnt FOpts         数据帧 Preamble PHDR PHDR_CRC MHDR FHDR FPort FRMPayload MIC CRC MAC层 Preamble PHDR PHDR_CRC MHDR MACPayload MIC CRC PHY层 Preamble PHDR PHDR_CRC PHYPayload CRC 好了,帧格式是大家随手都能看到的东西,本尊作为IoT小能手,如果不能提出一些稍有深度的信息增量,就对不起这个称号了。所以,有些协议设计层面的心得要分享下: 特别酷的ADR(速率自适应)机制 这个章节中最亮眼的莫过于速率自适应机制,简直是为LoRa网络量身定做的:一旦使能了FCtrl中的ADR位,距离近信号好的节点用高速率,距离远信号弱的节点用低速率,不小心被调高了速率,则自动降下来。这样,尽可能地提高了传输速率,也有效提高了网络容量。我已经见过不少厂家,拿这个协议的公知特点当产品卖点了。 可同时携带数据和命令的MAC帧 一般来说,应用除了数据,出于管理需要,肯定还会涉及命令。比如基站要查询节点状态,或者节点要请求变更信道等。所以LoRaWAN协议设计上利用FOpts把数据和命令揉在一个MAC帧里,这样可以提高交互效率,有效地降低功耗。这在寸土寸金,哦不,寸库仑(电量单位)寸金的物联网应用中,是一个很有必要的设计。 3 源码解析 […] Read more.
用于物联网无线传感器网络的低功耗长距离无线技术
作者:European Editors  来源:Digi-Key 低功耗广域网 (LPWAN) 已出现很长时间,但对物联网 (IoT) 低成本连接及功耗和成本改进的需求正引发对 LPWAN 越来越多的关注。 硅技术的改进已极大降低了功耗,可用于电池供电型无线传感器节点。 这些节点利用次 GHz 非调节式无线电频段进行长距离连接,比调节式蜂窝频带更具成本效益。 然而,推广这些 LPWAN 网络需要其自身的基础设施,后者至今仍然进展缓慢。 但如今已到了一个转折点。 使用次 GHz 频段意味着支持大量无线节点需要的基站更少。 物联网网络开发人员现有多种选择。 例如,Semtech 的 LoRa 技术可用于推出多个无线节点专用的私有 LPWAN 网络。 或者,诸如使用 SIGFOX 之类的公共 LPWAN 网络,则可省去安装、连接和管理基站。 同时人们也在通过新协议(如 Weightless)开发其他 LPWAN 网络。 LPWAN 网络的选择决定了物联网节点无线收发器的选择。 LoRaWAN 是一种低功耗广域网 (LPWAN) 规范,主要用于区域性、全国性或全球性网络中的无线电池供电型节点。 LoRaWAN 网络是一个典型的星型拓扑结构,网关是一个透明的桥接,在终端设备和后台中央网络服务器之间转送讯息。 网关通过标准 IP 连接与网络服务器连接,而终端设备使用单跳无线通信连接到一个或多个网关。 所有节点的通信一般都是双向的,但网络架构还支持诸如多播等工作 形式,可以实现软件无线升级或其他大量分发讯息以减少空中通信时间。 图 1: LoRaWAN 网络包含一个从物联网节点到网关的加密路由。   […] Read more.
LoRa联盟最新白皮书:LoRaWAN安全-可为IoT应用供应商提供完整的端对端加密
这是最近LoRa联盟官方发布的第6份白皮书,主题是安全,由GEMALTO、ACTILITY和SEMTECH一同提供,总体来说技术性较强,翻译难免有不妥之处,还请大家见谅。 介绍 LoRaWAN?是一种低功耗广域网络协议,可以为IoT、M2M、 智慧城市和工业应用等场景提供低功耗、可移动、安全的双向通信。LoRaWAN协议为低功耗进行了优化,并且为可支持数以百万计设备的大型网络结构进行了特别设计。LoRaWAN的特点是可以支持冗余操作、定位、低成本和低功耗等应用场景。 安全是所有应用场景的基本前提,所以从一开始在LoRaWAN协议中就对安全性进行了设计。然而安全包含众多方面,尤其是LoRaWAN的加密机制需要特殊的解释。所以此白皮书将会对当前LoRaWAN协议的安全性进行说明。首先会针对协议中的安全属性进行阐述,然后呈现具体的实现细节,最后对一些LoRaWAN安全性上的设计进行解释。 LoRaWAN?安全属性 LoRaWAN的安全性设计原则要符合LoRaWAN的标准初衷,即低功耗、低复杂度、低成本和大扩展性。由于设备在现场部署并持续的时间很长(往往是数年时间),所以安全考虑一定要全面并且有前瞻性。LoRaWAN安全设计遵循先进的原则:标准的采取,算法的审查,以及端到端的安全机制。接下来我们会对LoRaWAN安全性的基本特性进行描述:包括双向认证、完整性校验和保密机制。 双向认证作为网络连接的过程,发生在LoRaWAN终端节点与网络之间。这确保只有真正的和已授权的设备才能与真实的网络相连接。 LoRaWAN的MAC和应用消息是“生来”经过认证、完整性保护和加密的。这种保护和双向认证一同确保了网络流量没有改变,是来自一个合法的设备,而不是“窃听者”,或者“流氓”设备。 LoRaWAN安全性进一步为终端设备和服务器之间的数据交换提供了端对端的加密机制。LoRaWAN是为数不多的支持端对端加密的IoT网络技术。传统的蜂窝网络中,加密发生在空中接口处,但在运营商的核心网络中只是把它当做纯文本来传输的。因此,终端用户还要选择、部署和管理一个额外的安全层(通常通过某种类型的VPN或应用层加密如TLS来实现)。但这种方法并不适合应用在LPWAN技术中,因为这会额外地增加网络功耗、复杂性和成本。 安全策略 之前提到的安全机制依赖于经过完备测试和标准化的AES加密算法。加密社区已经对这些算法进行了多年的研究和分析,并且被美国国家标准技术研究所认定为适用于节点和网络之间最佳的安全算法。LoRaWAN使用AES加密语句,并结合多个操作模式:用于完整性保护的CMAC、用于加密的CTR。每一个LoRaWAN终端具有一个唯一识别的128位AES Key(称为AppKey)和另外一个唯一标识符(EUI-64-based DevEUI),二者都应用于设备识别过程。EUI – 64标识符的分配要求申请人从 IEEE 登记机关获得组织唯一标识符 (OUI)。同样地,LoRaWAN网络由LoRa 联盟分配的24位全球惟一标识符进行标定。 安全应用的负载 LoRaWAN? 应用负载的端对端加密发生在终端设备和服务器之间。完整性保护由跳频来实现: 空中跳频通过LoRaWAN提供的完整性保护,网络和服务器之间的跳频通过使用安全传输方案如HTTPS和VPNS来实现。 双向认证: 空中激活证明了终端设备和网络都具有AppKey的概念。这通过将一个AES-CMAC(使用AppKey)装载到设备的加入请求和后端接收器得到证明。两个会话秘钥接着进行相互认证,一个用来提供完整性保护和LoRaWAN MAC指令和应用程序负载(NwkSKey)的加密,另一个用来提供端对端应用负载(AppSKey)的加密。NwkSKey装载在LoRaWAN网络是为了验证数据包的真实性和完整性。从网络运营商的角度AppKey和AppSKey可以被隐藏,所以破解应用负载是不可能实现的。 数据完整性和隐私保护: LoRaWAN通信使用两个会话秘钥进行保护。每个负载由AES-CTR加密,并且携带一个帧计数器(为了避免数据包回放),一个消息完整性代码(MIC)和AES-CMAC(为了避免数据包被篡改)。下图是LoRaWAN包结构示意图。   安全性事实与谬论  LoRaWAN?设备的物理安全: AppKey和衍生而来的会话秘钥会持续的保存在LoRaWAN设备中,它们的安全性依赖于设备的物理安全。一旦设备受到物理损害,这些秘钥存在防篡改存储器中从而受到保护,并且很难提取。 密码学: 一些资料指出LoRaWAN?密码只使用了XOR而并非AES。事实上,如之前所提到的,AES用在了标准化CTR模式,这利用了XOR加密操作(还有CBC等许多其他模式)。这通过给每个分组密码分配一个惟一的AES码强化了AES算法。 会话秘钥分布: 由于AppSKey 和NwkSKey从同一个AppKey生成,可以说如果LoRaWAN运营商获得了AppKey,它能够推导出AppSKey从而解码网络。所以为了避免这种情况的发生,服务器要对AppKey的存储进行管理,双向认证和密钥推导的过程可以由运营商以外的实体进行操作。为了给运营商额外的灵活性,LoRaWAN接下来的新版本协议(1.1)会定义两个主秘钥,一个用于网络(NwkKey),一个用于应用(AppKey)。 后端接口安全: 后端接口包括网络和应用程序服务器之间控制和数据信号。HTTPS和VPN技术用于保护这些关键的基础设施元素之间沟通的安全性。 实现和部署安全: LoRa联盟一直在确保其协议和架构规范的安全性,但是解决方案的总体安全性还要依赖于具体的实现和部署方式。所以安全问题需要各个环节的配合,制造商、供应商、运营商都需要参与当中。 注解 1 AES – 一种高级加密标准。这是一个基于对称密钥的加密算法,允许消息加密和身份认证。 2 CMAC – 基于暗码的消息认证码。 3 CTR – 计数器模式加密标准。一种依赖于计数器的数据流加密AES算法的操作模式。 4 […] Read more.
LoRa天线电路设计四大要点
随着LoRa技术在业内的持续发热,加上其独特优越的传输性能,运用LoRa技术的群体正在爆发式的增长,由于很大部分群体对LoRa等射频技术均是初次接触,在做产品的过程中,通常会遇到棘手的射频电路设计问题,其实只要掌握几大要点,就基本可以发挥LoRa的最佳性能。 要点一、匹配电路设计 在原理图设计时,需要在天线接头与模块的天线引脚之间预留一个π型匹配电路。天线的阻抗是受到电路板的铺地、外壳和安装角度等因素影响的,预留这个π型匹配电路是为了当天线严重偏离50欧姆时,将其纠正到50欧姆。 默认情况下,天线阻抗是比较接近50欧姆的,在下图中的C17和C18不用焊接;而L2用220pF电容,或者1nH电感,再或者0欧电阻,三者均可。遇到特殊的情况时,比如天线安装模具内部、天线的体积很小或需要加强高次谐波抑制等,这三个匹配元件才需要进行匹配调整。 【图1】 LoRa模块应用的预留匹配电路 理论上,无论天线阻抗在任何值,都可以通过π型匹配电路将其匹配到50欧姆。然而实际上电感电容都是有内阻的,这个内阻会吸收能量,若天线阻抗太小(几欧姆)或大(上千欧姆)的话,通过匹配电路将其匹配到50欧姆去就失去了意义。原因在于大部分的能量已消耗在匹配元件的内阻上。 要点二、微带线走线规则 此处所说的微带线指的是LoRa模块的天线引脚到天线接头之间的PCB走线。下图是LoRa模块ZM470SX-M评估板上的微带线示例,由于模块内部阻抗以及天线阻抗都是以50欧姆标准来设计,因此当微带线特征阻抗也是50欧姆时,三者得到了最佳匹配。 【图2】 LoRa模块邮票孔式天线接口 为得到50欧姆左右的微带线,一方面可以向PCB生产厂家提阻抗加工要求,有能力的PCB厂家能够根据板材参数通过线线宽来控制走线阻抗;另一方面可以从PCB厂家获取板材参数后(主是介电常数)通过软件自己计算线宽,从而把阻抗控制在我们期望的范围。 【图3】LoRa学习评估板 根据经验,若用FR4的板材(介电常数在4.2~4.6之间),当线宽为微带线到参考层距离的2.2倍时,特征阻抗比较接近50欧姆。例如用双面板的情形,板厚为0.8mm时,可取线宽为1.7mm。但必须注意,微带线下面的铺地必须是完整的,微带线与铺铜间距根据阻抗计算软件计算结果来设定。模块天线引脚两侧的地焊盘必须良好接地。 【图4】 ZM470SX-M评估板微带线示例 由于470MHz电磁波的波长较长,如果这段微带线走线长度不超过20mm时,走线特征阻抗在25~75欧姆范围对性能影响不大,这种情况下建议使用25mil线宽即可。 要点三、PCB铺地要求 我们遇到过很多这样的情况:用户将我们的模块用到产品上,产品程序上使用与我们评估板一样的配置参数,并使用我们评估板上的天线,通信效果却明显比我们的评估板差很多。与通信距离相关的无非就发射功率、接收灵敏度和天线这三个关键参数,其中前面两个参数在我们模块出厂家时有测试过的,不合格的产品是当废品处理掉的,而天线是因用户的设计不同而不同。影响通信的距离主要就是天线这个参数,其它两个参数几乎不会因用户的板子不同而发生较大的变化。 【图5】 ZM470SX-M评估板PCB示例 在空气中,频率为470MHz的电磁波波长为63CM,若设计一款标准的半波偶极子天线,则这款天线至少为半个波长,即31.5CM。实际应用中,绝大部分的产品并没有给天线设计预留这么大的空间,所以普遍采用弹簧天线。使用这种弹簧天线时,天线接在不同的板子上,其性能参数是不一样的。这是因为这种类型的天线,弹簧只是整个天线的一部分,另一部分是电路板上的地,故在电路铺地的时候就得有讲究了,总原则就是:一是要尽可以使天线垂直电路板安装,二是要使铺地的铜块尽量大并且连续,并依靠密集的过孔来使正反两面的铺地连续也是可行的。 要点四、天线安装规范 在所有硬件参数调整好后,天线的安装也是关键一步,天线辐射是有方向性的,并不是每个方向辐射相等的能量,如同我们讲话一样,有的方向听到的声音强,有的方向弱。安装天线的时候,需要将天线辐射最强的方向对准接收的天线,接收天线才可能获得最强的接收信号,要做到这一点,必须先知道天线的辐射方向才行。 在没有暗室等专业天线测试实验室的情况下,那如何测试天线的辐射方向呢?我们可以在最终确定产品后,让其连续不断发送数据,并用频谱分析仪测试离产品一定距离的信号强度,旋转被测试的产品,并记录各个方向的信号强度,从而可以绘制出产品的天线辐射大致方向图。 【图6】辐射方向测试 靠近墙壁、门和金属面等反射面安装时,需要注意反射带来的影响,理论和测试结果都证明了以下的结论: 最佳位置: 最差位置: 最佳与最差位置相距λ/4交替出现; RX1优于RX2,例如470MHz时,离反射面16CM效果远优于32CM。 【图7】电磁波的反射   文章来源:ZLG致远电子 Read more.
LoRaWAN实战 LinkADR命令的源码分析
前言 LinkADR是LoRaWAN网络管理中相当重要的一个MAC命令,其解析占用了183行。索性专门写篇源码解析,记录下。 阅读此文前,最好再把第五章的这个命令好好翻一翻,代码和协议才能对应上。 我正在陆续对协议的各个章节进行翻译,具体其他章节的译文,以及译文之外的代码解析,可点此查看帖子LoRa学习笔记_汇总。 本文作者twowinter,转载请注明作者:http://blog.csdn.net/iotisan/ LinkADRReq 的源码解析 按照代码思路走一遍。 1.解析 DataRate_TXPower 字段 datarate = payload[macIndex++]; txPower = datarate & 0x0F; datarate = ( datarate >> 4 ) & 0x0F; if( ( AdrCtrlOn == false ) && ( ( LoRaMacParams.ChannelsDatarate != datarate ) || ( LoRaMacParams.ChannelsTxPower != txPower ) ) ) { // ADR disabled don't handle […] Read more.