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

台湾清华大学黄能富教授《LoRaLAN 私有物联网网路技术与应用实习》课程介绍
文字资料看累了?那让小萝拉带你来看看台湾清华大学黄能富教授《LoRaLAN 私有物联网网路技术与应用实习》课程的视频吧,其中关于LoRa应用的案例介绍更加直观和印象深刻。 【如果您的浏览器不支持直接播放下列视频,可以点击此处下载播放】 Read more.
唯传LoRa网关路由器测试结果惊人,稳定传输可达21.5公里
近日,唯传科技应客户需求,对GW5000网关路由器(城市级)进行了长距离测试。因客户所处区域在戈壁滩上,准备在20 公里范围内安装1200个探测设备,选用基站进行远距离数据监测和传输。考虑到客户实际需求,唯传决定在深圳区域寻找大范围空旷地带模拟客户需求环境进行现场测试。此前半年,唯传也已经多次进行LoRa最大空空通讯距离的测试,测试结果得到了Semtech公司的高度认可。 7月29日,唯传公司将GW5000网关路由器部署在南山高山上空旷的观景台,此处海拔约287米。节点随车在广深沿江高速上从前海往东莞虎门方向移动进行空空地距离测试。 Semtech公司称:在最佳环境下,LoRa的最大空空通信距离可达15公里。这次测试中,唯传的测试使用LoRaWAN的参数(带宽=125kHz,编码率=4/5,扩频因子=12,约300bps),因为470M频段有使用限制,网关发射功率选择17dBm。 图为唯传公司研发的GW5000网关路由器(城市级) 1、测试地区概貌 如图所示,本次LoRa空空平行可视距离测试区域的概貌。首先将发射模块放置在起点位置,在平行可视距离范围内,测试人员坐车从前海向宝安西乡出发,分别在坪洲新村附近(8.5公里)、福永码头附近(15.1公里)、广深沿江高速S3(21.5公里)、东宝河大桥(31.5公里)等进行通讯测试。测试起点位于深圳南山的观景台上,其他测试点和起点之间很空旷,有少量建筑物。 测试人员从南山观景台出发,走广深沿江高速往虎门方向进行测试 2、测试方法 我们使用公司研发的无线通信模块。网关和节点的通信数据为LoRaWAN的数据,节点入网时候是23个字节,正常通信时是13个字节,设置节点LoRaWAN确认信息为true,入网后每隔5秒发送一个数据包,节点收到确认帧后,红色LED闪烁,同时还接串口线,查看当时收到数据包的信号强度;网关使用8dBm的天线,频率476.5M,发射功率设置17dBm。 我们把发射器放置在南山观景台上。如下图所示,拿接收器沿广深沿江高速朝西乡方向前行,通过接口观看设备的数据,可以看出有没有接收到数据。 测试人员手拿接收器来查看信号强度 3、测试结果 坪洲新村附近(8.5公里):此时,接收模块的测试人员随车前行,离发射的南山观景台约8.5公里。网关、节点正常收发,接收成功率高,信号稳定,无丢包,中间穿过路基旁边低矮的树丛等障碍物时,不影响任何接收信号。 福永码头附近(15.1公里):此时,接收模块的测试人员离发射观景台约15.1公里,在实际环境中,与Semtech公司所称LoRa的最大空空通信距离接近,和理论值基本接近。这时,网关、节点正常收发,非常稳定。 广深沿江高速S3(21.5公里):此时,接收模块的测试人员离发射观景台已经很远,超出LoRa理论最大空空通讯距离,网关、节点偶有丢包。因客户所在环境很空旷,无障碍物,不会对人类生活区造成影响,按照客户需求提高网关的发射功率到20dBm,则无丢包。 东宝河大桥(31.5公里):为了测试LoRa最远信号距离,测试人员继续前行,直到离发射观景台约31.5公里,进入东莞地区,丢包严重。此时,将发射功率调整到27dBm后,继续测试,偶尔仍能收到通信数据。 工作人员沿途选取不同距离进行数据传输稳定性测试 4、测试总结 通过此次测试,首先证明了LoRa无线超长的通信距离,这对于物联网建设将是一个很大的应用场景。其次,唯传公司产品已接近LoRa的最大空空通信距离,在无障碍物的最佳环境下,发射功率为17dBm时,可达15公里;发射功率为20dBm时,可达20公里,进一步验证了LoRa技术的优势。 Read more.
花费200欧元打造自己的LoRa网关
本文来源 https://github.com/isiot/diy_LoRa_gateway 本教程介绍一个便宜的LoRa网关的制作步骤,然后让节点、网关和云在一起运行。 注:本文仅翻译自github,并未亲测 part1硬件选择 我要介绍的LoRa网关,运行在sx1301之上,该芯片不能单独出售,只出售给符合条件的客户。唯一的办法就是购买一个成品的网关板。 目前市场基于sx1301的LoRa网关板有: Semtech LoRa物联网入门套件,只出售给符合条件的客户 IMST iC880A,约189欧元: Multitech mCard-LoRa, 约156欧元: Link Labs LoRaWAN Raspberry Pi(树莓蒎) Gateway Board, 225美元: Cisco LoRa card, sold with Cisco IR900 router only(思科LoRa板卡,只提供思科IR900路由器): 只有Multitech mCard-LoRa符合我们的预算,而剩下的其他硬件就很便宜了。 mCard LoRa是一个为Multitech MultiConnect Conduit router定制的插件板,这个Mini-PCIe card没有使用文档可以提供,因为它是即插即用的。但是如果我们想把用它在其他的硬件环境下,我们应该对它进行逆向拆解。 余下的硬件则需要一个嵌入式Linux主机像Raspberry Pi,25欧元: 以及一个 USB to Mini-PCIe转换器, 5欧元: 对了,别忘了还有电源适配器、电缆和天线。 进入第2部分我们将探讨对mCard LoRa硬件上的修改。 part2硬件改造 mCard LoRa是一个Mini-PCIe规格的板卡。包含有一个sx1301基带芯片和两个sx1257 I/Q调制收发器(1 TX 2 […] Read more.
LoRaWAN协议(七)–完整数据流程
以下的GW指Gateway 所用指令: tcpdump -i lo -nn -x ‘length>100’ 入网流程 OTAA入网流程,ABP方式入网则不需要 NS -> AS AS -> NS NS -> AS AS -> CS NS->GW Join_accept message GW -> NS 数据通讯流程 GW->NS NS -> AS AS -> NC AS ->CS app.userdata.payload base64+aes 解密,得到: \x01 \x02 \x03 \x04 \x05 \x06 \x07 \x08 \x09 \x0a \x0b \x0c \x0d \x0e […] Read more.
LoRaWAN协议(六)–OTAA KEY生成过程
前言 通过OTAA方式入网的设备,通讯时使用的KEY需要通过服务器获得,在入网之间,设备无法通讯。 相关的OTAA入网流程已经在上一章中讲解过了,有兴趣的可以去看看**LoRaWAN协议(五)__OTAA入网方式详述** 这一章讲解的是OTAA中的密钥生成过程。 其中使用到的库函数都是从semtech的官方库中来的,官方库代码链接:LoRaMac-node。 详解 设备在通讯时,会使用的密钥有NwkSKey 和AppSKey。 生成的公式如下: NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16) 可以看到相关的参数一共有四个: 1.AppNonce 2.NetID 3.DevNonce 4.pad16 其中AppNonce、NetID、pad16 是产生于服务器的,DevNonce产生于node设备本身。 还是使用LoRaWAN协议(五)这篇文章中使用的包数据来进行分析。 这里,我们调用官方库的接口,因为我们这里只是熟悉协议,并不是要研究Key的生成算法。 如果不明白数据协议的,可以去看LoRaWAN协议(五)这篇文章 提取DevNonce 1.GW->NS JSON包,从中提取出来DevNonce, data为MAC层数据,为join_request message,其数据包格式为 MHDR APPEUI DevEUI DevNonce MIC 1字节 8字节 […] Read more.
LoRaWAN协议(五)–OTAA入网方式详述
前言 OTAA(Over-The-Air Activation),是LoRaWAN的一种空中入网方式。当node在上电的时候处于非入网状态时,需要先入网才能和服务器进行通信。其操作就是node发送join_request message,请求入网,然后服务器同意入网,并且返回Join-accept message,node再对信息进行解析,获取通信参数,之后就可以和服务器通信了。 顺便分享几个工具网站给大家: HEX/字符串转换 JSON校验 BASE64编码/解码 OTAA方式入网步骤 准备工作 node端在做OTAA入网之前,需要先具备三个参数: APPEUI node自定义的8字节长地址 APPKEY 服务器和node端都事先存好,用于对Join_acept message 做加解密处理 DevNonce 2字节的随机数,用于生成随机的AppSKey和NwkSKey 这些参数可以通过程序固话在里面,或者通过串口或其他方式在入网操作前告诉node。 当这些准备工作都做好了之后,node设备就能够入网了。 第一步 1.node发起入网请求,也就是发送join_request message, 根据LoRaWAN specification 可知,join_request message的格式如下: MHDR APPEUI DevEUI DevNonce MIC 1字节 8字节 8字节 2字节 4字节 其中 字段 描述 MHDR 数据包头,其中包含了数据包的类型,也就是说从这个包头可以知道,这是一个join_request message APPEUI 应用EUI DevEUI node的长地址,由node自己定义 DevNonce 一个随机数,用来生成密码 MIC 4字节的校验 需要注意的是Join_request message是未加密的 […] Read more.
LoRaWAN协议(四)–入网方式概述
前言 在LoRaWAN中,node最终和服务器能够正常数据交互,需要先入网,入网的本质,也就是获得一些通信相关的参数,有以下几个: NwkSKey AppSKey DevAddr DevEui 其中 NwkSKey用于数据的校验,也就是说在MIC校验时会用到 AppSKey用于负载的AES加密,也就是说在加密解密时会使用到 DevAddr是node的短地址,在数据通讯时,使用的是node的短地址 DevEUI 在ABP入网方式的通讯中不会使用,在OTAA方式中会使用到,是由设备在入网前就产生了。在入网时,node将DevEUI上传,然后服务器会将此DevEUI注册并返回一个DevAddr,也就是说DevAddr此时和DevEUI就建立了映射关系,在node后续的通讯中,使用DevAddr。 LoRaWAN入网方式有两种: ABP (Activation By Personalization) OTAA(Over-The-Air Activation) 下面就讲述一下这两种方式。 ABP 概述 ABP方式是事先将入网信息烧写在设备上,也就是说设备上电已经入网了,无需再特意去请求入网。 这种方式就不再多说了。 OTAA 概述 OTAA方式入网的node,在刚上电的时候,是不处于入网状态的,此时就需要进行入网操作。 如果我们简单的把服务器看做一个整体,那么入网操作的流程是这样的: node 发送入网请求,即join_request message GW 收到 node 的数据,上传给服务器 服务器收到入网请求,同意入网,并且将设备在服务器注册,建立长地址与短地址之间的联系,生成通讯密钥,将通讯密钥的参数打包下发给GW,即 Join-accept message GW 收到服务器的数据,下发给 node node 根据下发的数据包,得到 DevAddr、APPSKEY、NWKSKEY 这篇文章先大概的描述一下两种入网方式 详细的关于OTAA的入网方式见下一篇文章,会有OTAA的抓包分析,以及APPSKEY/NWKSKEY的生成过程,并且有C语言的Example。 本期的LoRaWAN协议分析就到这里了,如果本文有什么错误,或者对LoRaWAN有什么不理解的,欢迎联系我,邮箱(454626653@qq.com),在左边也有链接,谢谢大家。 Read more.
LoRaWAN协议(三)–Server端数据协议
LoRaWAN Server 端架构 LoRaWAN 的server包括 NS(Network server)、AS(application server)、CS(Custom server)…. 其中NS和AS是必不可少的,是完成LoRaWAN协议的重要组成部分 NS 职责 NS是直接与GW通信的服务器,也是AS和GW之间的桥梁 我所知道的工作有如下几点: 验证数据的合法性(校验MIC) 从GW的信息中提取数据,整理成NS 的JSON数据包 将校验合法的数据打包成新的JSON包上传至AS OTAA入网时向AS发送请求入网消息,然后再将入网信息告诉AS,当获取AS传来的入网的信息,告诉GW GW 和 AS之间的数据通道 有几点需要注意的是NS端的数据不进行AES解密工作。 AS 职责 AS是server端的数据处理中心 它的工作有如下几点: 上行数据的解密 下行数据的加密 OTAA入网请求的处理(同意入网/生成APPSKEY/NWKSKEY) CS 职责 CS负责将AS给的数据处理成用户自定义的数据协议格式,也就是说,CS端必须是用户来完成的,因为上面运行的是用户的协议。这里也就不再多说了。 抓包分析 以下是我在本地服务器端通过抓到得来的数据,我们通过分析数据包来理解数据的走向已及现有的server端处理流程。抓包使用的是tcpdump。 1.NS->AS数据 这是一帧从NS->AS的数据,使用的是TCP方式,AS的数据端口为4000。从data部分我们可以看出来,这是一个未解密的数据。 提取其中的数据部分为: 再把app.userdata.payload 做base64解码之后,得到的payload内容是这个: 此时看到的payload因为是加密的,所以完全看不出来数据内容是什么。 不过在这里,我们可以看到,NS已经将GW上传的数据做了一定的解析,封装成了另外一种JSON格式,由此,我们不难得出,NS做的工作包括–base64解码/MIC校验/GW数据包的重新组包 2.AS->CS数据 这是一帧从AS->CS的数据,使用的是TCP方式,CS的数据端口为5000。从data部分我们可以看出来,这是一个已经解密完成的数据了。 提取其中的数据部分为: 再把app.userdata.payload 做base64解码之后,得到的payload内容是这个: 而此时,数据已经完全解密了,可以看到数据就是在AS解密的,解密完再发送给CS,CS再做进一步用户协议的处理。 在这里,我们可以看到,AS已经将NS传输过来的JSON包的payload部分做了解密,然后再传给了CS。所以解密工作是在AS完成的。 邮箱地址:454626653@qq.com 欢迎咨询搭讪 Read more.
LoRaWAN协议(二)–LoRaWAN MAC数据包格式
名词解析 上行:终端的数据发送经过一个或多个网关中转到达网络服务器。 下行:由网络服务器发送给终端设备,每条消息对应的终端设备是唯一确定的,而且只通过一个网关中转。 LoRaWAN Classes LoRaWAN Classes 一共分为3类:Class A,Class B,Class C Class A:终端先发送,在发送后开启一段时间的接收窗口,终端只有在发送后才可以接收。也就是说上行没有限制,下行的数据只有在上行包发送上来的时候终端才可以接收到。(功耗最低) Class B:终端和服务器协商好接收的窗口开启的时间以及何时开启,然后再约定的时间进行接收,可以一次接收多个包。(功耗次低) Class C:终端在发送以外的其他时间都开启接收窗口。更耗能,但通讯延时最低。(功耗最高) PHY/MAC 层数据链路 总的数据包结构: 注意preamble、PHDR、PHDR_CRC、CRC都是硬件生成,无需软件参与,需要软件参与的就是PHYPayload部分 PHY层数据 上行链路消息: 下行链路消息: 其中上行最后还有CRC校验,而下行没有CRC校验。其中PHDR PHDR_CRC CRC都是射频芯片用于校准数据的完整新和一致性用的,并非用户生成的数据。 MAC 层数据 由上图可以看到,MAC数据是是作为PHYPayload存在的 其中MAC 层的包有三个部分组成: MHDR(MAC层帧头) MACPayload(MAC层负载) MIC(4字节的校验) 而MACPayload又由三个部分组成: FHDR (MAC层负载头) FPORT(MAC 层数据的通道号) FRMPayload(MAC层负载,加密) 而FHDR又由由四个部分组成: DevAddr(终端的ID 4字节) FCtrl(帧的控制字 1个字节) FCnt (帧的序号 2个字节) FOpts(帧配置,字节数不定,大部分情况0个字节) 所以,由协议可知,一个上行包或者下行包中的数据内容有哪些,抛开控制命令不说,主要有终端的ID、包的序号、用户的加密负载。 例如我抓到的一个数据包: \x40 \x7f \xf8 […] Read more.
LoRaWAN协议(一)–架构解析
LoRaWAN 分层 总体架构一共分为4部分: LoRaWAN从底层到最后用户拿到数据的通讯过程通讯大致可分为三段: MOTE <—> GW (MAC层) GW <—> server server <—> 用户 LoRa联盟 规定了 MAC层的通讯协议,只有在设备(GW、MOTE)共同遵守的MAC层协议的前提下,不同硬件厂商的设备才能互相接入。 而GW <—> Server以及Server <—> 用户这两层的协议虽然LoRa联盟有所规范,但不同厂商之间可能会存在不同。 Mote/Node Mote/Node 就是节点,在LoRaWAN中,节点一般与传感器连接,负责的就是收集传感数据,然后通过LoRaMAC 协议传输给Gateway。 Gateway Gateway也就是网关,主要负责将节点的数据传输给服务器,也就是完成数据从LoRa方式到网络方式的转换,其中Gateway并不对数据做处理,只是负责将数据打包封装,然后传输给server(服务器)。 Server 按照LoRaWAN的规定,Server又分为四部分–NS(Network server)、AS(Application server)、CS(Customer server)、NC(Network controller) 其中每个部分的分工和职能各不相同。相应的我会在后续的文章中讲到。 用户 用户一般只的是直观使用这个数据的人,一般是APP或者其他客户端方式,从服务器获取数据。 应用分析 在这里我以LoRaWAN 方式实现农场的土壤湿度检测来具体说明这各个部分的区别: 实现农场的土壤湿度的检测主要分为几个步骤: 实现传感器采集土壤湿度(sensor层) 将采集到的土壤湿度通过MOTE发送给GW(LoRaMac 层) GW将收到的数据发送给NS(GW<—>Server) NS再将数据发送给用户(Server<—>Customer) 用户通过APP或者其他方式可以看到土壤的湿度状态。(Display) 通过以上的几个步骤,就可以实现远程监控农场土壤湿度。 邮箱地址:454626653@qq.com 欢迎咨询搭讪 Read more.
LoRaWAN stack移植笔记(六)_调试2
前言 调试的过程中碰到的问题基本都是以前没有遇到过的,而且需要对整个协议栈及射频方面的工作流程较熟悉才能找到问题的原因,需要多读SX1276的数据手册以及与射频芯片的物理层通信例程和MAC层通信例程进行对比相结合。 正文 发送失败 LoRa 模块在进行 模式切换时,比如TX 切换到RX模式,需要先将设备切换到standby模式 CRC 校验失败,然后程序陷入死循环 按逻辑来讲,CRC校验失败,应该进行的操作是吧校验失败的这个数据包丢弃,然后重启接收机(芯片每次接收完成都应该重启SX1276) 但是,程序一旦接收CRC校验失败就陷入循环,通过调试发现,原来是开启了一个定时器,定时时间为0,然后定时器的处理函数中又开启了此定时器,定时时间依旧没0,所以陷入了死循环。 这个定时器就是: 在接收处理函数void SX1276OnDio0Irq( void ) 中的CRC校验失败分支的处理代码中,以及定时器对应的处理函数void SX1276OnTimeoutIrq( void )中都开启了这个定时器。 如果是单个接收模式下,开启这个定时器并没有什么问题,但是在我调试的代码中,我开始的是连续接收模式,此模式根本没有同步字接收超时继续开着接收模式就可以了,并不需要特别的处理,可以不需要处理, 而官方SDK中: 这两处代码有着类似的才做,但是RxTimeoutSyncWord这个定时器会进入void SX1276OnTimeoutIrq( void )这个函数,而这个函数中又会重新开启RxTimeoutSyncWord这个定时器,导致死循环,所以在这里,应该讲两处的开启定时器的操作去掉(TimerStart( &RxTimeoutSyncWord );),这样程序逻辑才正常。 CRC 校验失败,然后在单步模式下,CRC一直失败 这个问题不是程序的问题,原因是因为我在单步模式下看CRC做接收,然后我的单步调试打断了射频芯片的正常工作。嗯、、就是这样,这个故事告诉我们,不要手贱。 邮箱地址:454626653@qq.com 欢迎咨询搭讪 Read more.
LoRaWAN stack移植笔记(五)__调试1
先废话一小段 在将LoRaWAN的程序移植的过程中,调试发现了很多的问题。 做好记录工作,防止以后再踩坑 移植使用的是LoRaMac-node库,使用的是STM32L151CBT6 MCU,需要要移植到STM32L051C8T6 这个MCU上面。 开始正文 JLink的配置 由于第一次使用JLink(SWD方式),在一开始使用时,踩了几处坑: KEIL选择JLINK之后,点击设置进入,会出现一个对话框,要选择NO KEIL里面JLINK的 方式要选择SW,不然认不到芯片 Flash download要选择对应大小的芯片,注意Flash的大小要选择正确 程序无法进入main,甚至一个函数都没有跑 当配置完JLink之后,程序可以正常烧写调试了,但是问题又出现了,无法跑进main函数,再进一步调试,发现来一个函数都没有执行,直接就进入进入死循环了(通过单步调试看上面的汇编代码)。这个现象就很奇怪了,以前也没有碰到过。 因为3.3V和GND是正常的,这样就算晶振有问题,也会执行程序到配置晶振才会出问题,而不是一句函数都没有执行。 后来顿悟,大概是BOOT0没接,仔细一看原理图,果然BOOT0是悬空的,飞线焊上之后,问题终于得到了解决。 NOTE:画原理图时一定要主要,BOOT0一定要接地,这样程序才能正常从FLASH启动 RTC定时链表的配置 官方的库中使用了RTC来作为定时器来处理一些定时的事件,这也是库中唯一的任务调度机制。所以保证这个机制的正常运行非常重要。 但是,当我把一切参数都配置完成之后,却发现,RTC的定时器不听使唤,经常不进入中断,初步诊断是写入寄存器的定时时间出了问题,但是却找不到出问题的原因。 这个问题也是非常的诡异,至今还未发现原因。 但是在一次偶然的调试中,我将原本处于 static void RtcStartWakeUpAlarm( uint32_t timeoutValue ) 这个函数中的 RtcCalendar_t now; RtcCalendar_t alarmTimer; RTC_AlarmTypeDef alarmStructure; 这三个变量由局部变量改为了全局变量,问题就得到了解决。 但是原因还未发现。原本以为是变量未赋初值就使用,但是程序中都有在使用前赋初值,具体原因不明。 程序进入Default_handler 在调试程序的时候,程序又出现跑死的情况,然后单步调试发现程序进入了Default_handler这里,始终无法跑出来。 然后通过搜索得知,进入这里的情况应该是发生了中断但是没有处理,然后程序一直进入中断。 后来查看代码发现,由于Cotex-M3和cotex-M0的核,对GPIO的中断的入口是不一样的,在移植时需要做修改,在做了修改之后,程序终于跑正常了。 无法点对点通信 需要注意的是,点对点通信中,能够建立条件需要两个点的通信参数配置成相同。 特别注意的是iqInverted preamble SYNCWORD note: 1. 如果发射方使能了iqInverted,那么接收方也要使能iqInverted 2. 接收方的preambleLen必须设置大于发射方,否则有很大可能接收不到(偶尔可以收到,但是接收成功率很低) 3. 发射方和接收方的SYNCWORD必须设置一样(同步字一样),否则认为是不同网络 […] Read more.