0.序

最近半年的时间一直在从事这方面的开发工作，到目前为止对于Sigfox有一定想法和经验，同时目前国内对于该技术的使用和应用还处在刚刚起步的阶段，很多博客对Sigfox的讲解是一个浅尝辄止的介绍，因此在很多时候的入门是一个及其不方便的过程，因此在这里做一些总结和分享。

2018年1月，在法国总统马克龙访华期间，Sigfox曾联合中国联通、法国KRG智慧养老公司与成都高新区宣布共同建设运营成都国际智慧养老服务示范社区，发展老人监护应用方案。

如有不足，欢迎各位在评论区指出探讨。

1.低功耗物联网及Sigfox背景介绍

1.1 LPWAN介绍

随着5G的逐渐成为一个越来越热的通信方式，其“对立面”——低功耗广域网络（LPWAN）也逐渐被广泛的应用。5G意味着更大的带宽，更快的数据传输速率以及更大的数据吞吐量，但与之对应的就是更高的成本，更多的对频谱资源的占用，和对空中无线资源的占用。而在很多时候往往不需要如此高的数据传输量，尤其是不需要如此高的成本，以Sigfox为例，其一套成熟的通信模块的BOM成本大约在3——5美金左右，在5G应用中，光一个基带芯片的成本就远高于此。
例如在智慧城市，智慧道路，智慧医疗，智慧物流等很多领域，往往不需要音频、视频等数据的传输，其传输的往往是终端传感器中所采集的数据以及一些简单的对数据的分析（这并非意味着这种情况就无法做大数据的分析，这些简单的终端数据通过无线的方式传输到基站，最终到达系统端，而系统主站可以对这些数据进行及其详尽的大数据的分析）。
由此可见LPWAN和5G这两种无线通信类型将在物联网这个大的世界中扮演着各自的角色，并最终都将汇合在万物互联的尽头。

1.2 Sigfox背景简介

Sigfox是由Sigfox公司所提出的一种通信网络，2009年成立于法国，该技术是一种连接低功耗设备的无线网络，主要用于低功耗物联网，这类应用需要连续地发送少量的数据。Sigfox希望建立第一个仅供用于物联网的全球蜂窝连接的公司，其基础设施完全独立于现有的网络（如电信移动网络）。
由于物联网连接使用低数据速率，Sigfox网络利用了超窄带，UNB技术。传输功耗水平非常低，而仍然能维持一个稳定的数据连接。Sigfox无线链路使用免授权的ISM射频频段。Sigfox网络中单元的密度(基于平均距离)，在农村地区大约30-50km，在城市中常有更多的障碍物和噪声距离可能减少到3-10km之间。整个Sigfox网络拓扑是一个可扩展的、高容量的网络，具有非常低的能源消耗，同时保持简单和易于部署的基于星型单元的基础设施。
以上的关于Sigfox的介绍是目前国内最常见的对Sigfox的简介，事实上，目前Sigfox的最主要的优势在于基于Sigfox可以实现终端设备与云端的直接连接，而避免了终端用户与运营商过多的沟通，极大地降低了终端客户这一部分的成本。由Sigfox公司与各地运营商进行协调，同时Sigfox公司将终端的硬件设备与芯片供应商合作，由终端芯片商提供底层的软硬件研发并形成库，而最终的终端用户只需基于这些库进行二次开发。Sigfox则通过系统后台和云端运营，从而实现盈利。

2. Sigfox无线通信介绍

Sigfox是连接传感器和设备的低成本，可靠，低功耗的解决方案。
Sigfox协议着重于：
Autonomy：极低的能耗，可确保多年的电池寿命。
Simplicity：不需要配置、连接请求。终端设备在几分钟之内即可启动并运行。
Cost efficiency：从设备中使用的硬件到我们的网络，Sigfox公司对每个步骤进行优化，以尽可能提高成本效益。
Small messages：网络中不会发送大数据量的媒体数据（例如音频、视频等），只有小的payload：最多12个字节。
Complementarity：由于其低成本和易于配置，因此还可以将Sigfox用作任何其他类型网络的辅助解决方案，例如：Wi-Fi，蓝牙，GPRS等。

2.1 Sigfox不同 RC的介绍

上图所示的为Sigfox目前在全球的网络部署的情况，实际上可以看到，目前Sigfox的部署主要集中在欧美地区及太平洋地区，而亚洲则主要有印度、日本、中国台湾地区等。
（顺便说一句，Sigfox官网中的用户注册页面令人很舒适）

Sigfox目前基于不同地区对于无线电频段的要求分为6个频段（RC）：

RC1：奥地利，比利时，保加利亚，克罗地亚，捷克共和国，丹麦，爱沙尼亚，芬兰，法国，德国，匈牙利，爱尔兰，意大利，拉脱维亚，列支敦士登，立陶宛，卢森堡，马耳他，荷兰，挪威，波兰，葡萄牙，罗马尼亚，塞尔维亚，斯洛伐克，斯洛文尼亚，西班牙，瑞典，瑞士，英国，法属圭亚那，法属波利尼西亚，瓜德罗普岛，马提尼克岛，毛里求斯，马约特岛，新喀里多尼亚，留尼汪岛，博茨瓦纳，肯尼亚，尼日利亚，阿曼，南非，斯威士兰，突尼斯，阿拉伯联合酋长国。
RC2：巴西，加拿大，墨西哥，波多黎各，美国。
RC3：日本。
RC4：阿根廷，智利，哥伦比亚，哥斯达黎加，厄瓜多尔，萨尔瓦多，危地马拉，洪都拉斯，尼加拉瓜，巴拿马，秘鲁，特立尼达和多巴哥，乌拉圭。澳大利亚，香港，印度尼西亚，马来西亚，新西兰，新加坡，台湾，泰国。
RC5：韩国。
RC6：印度。

事实上，为了保证Sigfox在不同的地区中都能够进行无线通信，Sigfox需要遵守当地的无线电通信的标准和要求，例如在欧洲地区的无线电设备指令（The Radio Equipment Directive,Red)2014\53\EU认证标准，在美洲地区的FCC认证等等。
因此也就产生了对于不同地区不同频段、上下行波特率以及EIRP等的标准，如下表所示。

–	RC1	RC2	RC3	RC4	RC5	RC6
Uplink center frequency (MHz)	868.130	902.200	923.200	920.800	923.300	865.200
Downlink center frequency (MHz)	869.525	905.200	922.200	922.300	922.300	866.300
Uplink data rate (bit/s)	100	600	100	600	100	100
Downlink data rate (bit/s)	600	600	600	600	600	600
Sigfox recommended EIRP (dBm)	16	24	16	24	14	16

而除此之外，在不同的RC中，其上行的总带宽和下行的带宽事实上也是存在着很大的差异的，可能很多人都听说了Sigfox的超窄带技术，但是很多时候却没有对这个有明确的了解，事实上，如下表所示，在RC2和RC4中Sigfox的带宽是远大于192KHz的。

–	RC1	RC2	RC3	RC4	RC5	RC6
Uplink low boundary	868.030	902.100	923.100	920.700	923.200	865.100
Uplink high boundary	868.230	904.700	923.300	923.300	923.400	865.300
Downlink low boundary	869.425	905.100	922.100	922.200	922.200	866.200
Downlink high boundary	869.625	907.700	922.300	924.800	922.400	866.400

同时对于不同地区中还存在一些小的对于无线电通信的标准的要求，Sigfox也做出了对应的解决方案。
在RC1中对空中占空比的要求（占空比为每小时时间的1％，即为36秒。对于8到12字节的payload，这意味着每小时6条消息，每天140条。）
在RC3和RC5中的载波监听的机制（发射前，终端设备必选判断Sigfox要发送的这200 kHz信道中没有任何大于−80 dBm的信号。）
在RC2和RC4中的跳频机制（设备在3个不同的频率上广播每个消息3次。每个通道的最大开启时间为400毫秒。20 s之前没有新的发射）。对于RC2中跳频机制将在之后进行详细的讲解。
接下来将以RC2为例，对Sigfox的通信方式做详细的介绍。

2.2 调制方式

那么在学习和了解一种新的通信方式的时候，学习的顺序实际上我们应该按照由底层向上层逐渐熟悉的顺序。因此首先需要了解的是其物理层的特性：
Sigfox在RC2中的上行通信的调制方式为BPSK (Binary Phase Shift Keying)——二进制相移键控。那么对于BPSK在这里就不做过多的介绍了，你可以在任何一本通信原理的教材中找到对他详细的讲解。在这里附上Sigfox对BPSK的原理图的介绍。

其空中的波特率在600bps，那么按照其协议帧中所规定的其传输时间大概在350ms左右，其在时域的波形如下图所示，不过放大时间之后并没有在看到倒π的现象。

其下行的调制方式为GFSK(Gauss frequency Shift Keying)——高斯频移键控。
针对Sigfox的物理层的相关的更多信息，可以在ETSI GS LTN 001 V1.1.1、ETSI GS LTN 002 V1.1.1、ETSI GS LTN 003 V1.1.1有更多的了解。上述的三个标准文档详细的定义并介绍了有关Sigfox的物理层的信息。

2.3 发送及接收时序

在上图中可以很清楚的从时域的角度看到Sigfox的通信机制，首先终端模块在三个不同的频点发送上行帧，每帧的时长大概在350ms左右，每帧之间的间隔为500ms，在上行帧发送Tw后，将允许下行帧的发送。其中Tw的时间大约为20s左右，下行数据将在上行第一帧发送完成之后的20.1s至44.5s内发送。这也意味着终端模块需要在这个时间段内开窗，接收下行的数据帧。在44.5s结束之后的1.4s，终端模块将会再开启一个3.6s上报，在这中间将会上报之前下行帧中的例如RSSI等参数的OOB（Out Of Band，带外数据）。

带外数据(Out of Band, OOB) ，传输层协议使用带外数据来发送一些重要的数据，如果通信一方有重要的数据需要通知对方时，协议能够将这些数据快速地发送到对方。

事实上通过这种方式可以有效的使基站及云端知道是否模块已接收到信息，从而优化或调整其通信网络，在实际的通信网络中，每一个Sigfox终端模块上行时都将至少会被3个基站接收到数据，而据老严的介绍，其最大可以同时被10+个基站同时接收信息，这一点也保证了Sigfox协议中上行数据的有效发送。

在从宏观上了解Sigfox的通信时序之后，我们再从终端模块的角度进一步的熟悉并了解Sigfox的通信时序。

可以从图中清楚的看到，在除过测试帧的情况下，终端模块是一个很明显的Idle——Ready——Uplink——Downlink的过程，而这个过程也很明显的可以看到Sigfox的开窗的过程。

2.4 协议帧

现在应该已经对Sigfox的整个通信过程有一个大致的了解了，接下来将对其中的细节部分，即每一次的Sigfox上下行中到底发了什么，做一个更加详细的了解。
P.S. 如果各位想要更加详细的了解这一节的内容，可以在《Sigfox radio specifications v1.3 February 2019 (public)》中找到更加详细且官方的内容。

2.4.1 上行协议

上图所示的为按照不同的层级的分类，对整个协议做了一个详细的解析，可以看到协议被简单的分为了应用层，MAC层，物理层，当然这个分层与我们在TCP/IP中所谈到的7层协议还是有所区别的。
首先从最上层的应用层UpLink Message Content讲起，这里所指的实际上也就是PayLoad部分，也就是我们常说的有效负载，或者是用于所定义的上传的内容。Payload的部分实际上就是我们用户每次使用Sigfox协议上传时，所实际上传的数据。这里的长度是可变的，从0字节到12字节可变，而这个可变的PayLoad也会影响到协议中的其他部分。
接下来就是MAC层的几个标识部分了。

LI（Length Indicator）：2位，这实际上是一个长度的标识，在上表中可以看到该值会根据不同的PayLoad的长度而改变，Sigfox要求在协议中，针对不同长度的Message，LI的值必须严格按照表格中一一对应，UL-AUTH和最终整个UL-Content的长度都在上表中也一一对应。
BF（Bidirectional Flag）：1位，这个的值我没有太理解，Sigfox的官方给的解释是，姑且按照官方的解释听之吧。

0b0 in an UL-container carrying application message in a U-procedure,
0b1 in an UL-container carrying application message in a B-procedure.

REP（Repeated Flag）：1位，重复标识，该值一般情况下默认为0
MC（Message Counter）：12位，数据计数标识，该值在实际的应用中是比较好用的，可以通过该值判断是否存在丢包等情况，因为其每一次发送都会计数，且计数依次增加，当到4096之后则又归为0。
ID（Identifier）：32位，终端模块的ID号，在协议中需要有一个大小端的转置。
UL-AUTH（Uplink Authentication）：这个实际上是对前面的6个部分在填充了Roc位之后，进行CBC模式下的AES128加密，最后将经过加密之后的结果按照如上表中的UL-AUTH的长度规范，填充到UL-AUTH。

最后就是PHY层的几个部分了：
CRC校验：16位，多项式为X16 + X12 + X5 + 1，因子为0xFFFF，将校验之后的结果放在协议的最后。
FT（Uplink frame type）：13位，实际上这一帧是按照之前我们所描述的Sigfox的上行帧共计有4帧，包括3个在不同频点的应用数据和最后的带外数据，而FT这13位则是对不同的帧和不同的长度做一个标识，如果有想详细了解不同情况下FT的具体值是多少的可以查阅Sigfox radio specifications v1.3 February 2019 (public)的地17——18页。
UL-Pr（Uplink preamble）：19位，上行前导，默认设置为0b1010101010101010101。
至此，上行协议中的所有位我们都已详细了解完成，最后可以通过如下表做一个回顾。

2.4.2 下行协议

上下行协议中MAC层的区别主要是在DL-AUTH中的不同以及校验方式的不同
DL-AUTH：这里的区别主要在部分的转置的区别，DL-AUTH对MAC层中的几个参数有了比较不同的转置。具体的转置方式见下图

当转置完成之后，同样会使用AES128对所有的MAC层做加密，并填充到DL-AUTH上。
CRC校验：CRC校验的多项式为X8 + X5 + X3 + X2 + X + 1。
在物理层中，下行协议中还增加了ECC和whitening两个模块。
ECC（Downlink error correction）：这里的主要目的是下发纠错码，纠错码的主要实现方式见下图：
whitening（Downlink whitening function）：在Sigfox的官方文档中给出了其实现步骤：
1、Evaluate the initialization value of the whitening function as (End-Point Identifier x MC) mod512, where MC value is from the uplink frame of the corresponding bidirectional sequence.
2、If (End-Point Identifier x MC) mod512 equals 0, set the initialization value to 51110.
3、XOR the concatenation of ECC, DL-CONTAINER and DL-CRC fields, in order, with the pseudo-random bit stream generated by the PN9 polynomial: R=X9+X4+1 initiated with the above initialization value.
其实现方式相对来说不是很复杂，但是没有搞清楚为什么要加这一步。

最后同样地通过如下表做一个回顾。

3 选型及认证

3.1 选型介绍

Sigfox公司提供了相对来说比较开放的选型和硬件设备供应，详细的选型及合作方可在https://partners.sigfox.com/看到详细的介绍。在这里分为几个部分对Sigfox的选型做一个介绍

3.1.1 芯片

这里的芯片介绍分为两个部分，一个部分为射频芯片的介绍，另一个部分为SOC的介绍。
射频芯片目前来说主要有如下几个厂商的芯片，包括ST的S2-LP，TI的CC1120和CC1125，Silicon Labs的Si446x，和安森美的AX5043这几款射频芯片，目前常用的主要为ST的S2-LP。
S2-LP的不同型号可以用于413-479 MHz (S2-LPQTR)、452-527 MHz (S2-LPCBQTR)、826-958 MHz (S2-LPQTR)、904-1055 MHz (S2-LPCBQTR)，这些都很好的适应了Sigfox所处的频段，即各个地区的非授权频段。同时S2-LP可以提供16dBm的输出功率和-130dBm的接收灵敏度，空中波特率为0.1到500kbps，接收功耗为7mA左右，在标准方面可以完全兼容IEEE 802.15.4，ETSI EN 300 220，ETSI EN 303 131，FCC part 15 and part 90。同时用该芯片搭配STM8或STM32实现一整套解决方案也是不错的选择，这一部分ST实际上已经有成熟的模块，稍后会讲到。

另一个方面则是采用SOC，SOC相对来说就实现了Sigfox最开始所说的轻量级协议，可搭载其他类似于ZigBee，蓝牙，WiFi等不同的通信方式。
其主要厂家集中在安森美、MicroChip和NXP等公司，其中安森美有相对来说较为丰富的型号，如有需要可以在前面所说的https://partners.sigfox.com/网站内查询。

3.1.2 设备工具包

设备工具包，Device Kits，和芯片厂商一样，同样是Sigfox开放合作的一种方式，目前主要包括如下厂家的产品。

可以看到设备工具包目前有很多家公司都有相对来说比较成熟的产品，从硬件的角度来说，其实只要支持Sub-1GHz的模块都可以支持该产品，当然，Sigfox对电源和晶振的选型有相对来说比较严苛的要求，但目前来说这些开发套件都是较为成熟和完善的终端产品解决方案。主要包括了Arduino，树莓派，安森美以及Wisol公司的EVBSFM20R1。
Wisol公司的这款开发板上集成了Sigfox+WiFi+BLE+GPS+Accelerometer+NFC，几乎包括了常见的物联网通信方式！！

3.1.3 模块

事实上，如果不想自己实现Sigfox底层的开发，而只是想通过Sigfox实现数据的发送，目前来说很多公司都生产了Sigfox模块，而你只需要保证基于别人的模块能够进行二次开发即可，很多的模块开发相对来说极其简单，例如使用AT指令控制Sigfox模块，一天的时间就可以实现数据的传输。这些模块一般都是Sigfox合作伙伴开发的模块，同时已经通过了无线电认证的认证（Sigfox Verified），而你只需要完成并实现一些简单关于天线的认证（Sigfox Ready），就可以使用Sigfox进行通信了。
Sigfox在其官网上推荐的Sigfox module多达70+种，在这里就不做过多的推荐，大家可以去https://partners.sigfox.com/products/module依次仔细查看他们的性能和报价以及配合程度。

3.1.4运营商及系统软件

前面提过，Sigfox的一大优势就是运营商这一部分实际上已经是由Sigfox和各个运营商之间达成了协议，相对来说大大减少了终端模块在使用其Sigfox网络时的麻烦。
因此在这里只是做一个运营商的简单介绍，便于在真正使用时，最起码能够知道是和谁协调当地的网络。
https://partners.sigfox.com/search/companies?or[type][0]=so&q=&limit=12&page=0

系统软件，当你不想自己开发系统软件时，Sigfox的合作方们实际上已经开发出了很多的系统软件，一下是一些简单的截图。

3.2 认证相关标准和要求

这一部分将随着认证的过程，持续完善
Sigfox的认证分为两个部分的认证。
“Sigfox Verified”认证是授予Sigfox合作伙伴开发的模块，这些模块已经通过了无线电认证。
“Sigfox Ready”认证是授予Sigfox合作伙伴开发的已通过天线认证的设备。
同时很多地区还要求要符合当地的认证标准。

3.2.1 认证介绍

这一部分的测试认证主要测试如下两个部分，Sigfox射频和协议测试（证明协议符合性）以及Sigfox辐射性能测试证据。
Sigfox Verified 分为如下三种认证，不同的认证之间报价也不同
• Similarity offer
适用于基于Sigfox ReadyTM设备（即参考设备）的设备，其改变不会影响设备的RF通信部分（RF示意图、RF布局、RF固件、设备电源、天线、机械外壳……），在这种情况下只需提交build.sigfox.com中提供的设备相似性清单文档，并提交类似的设备文档供sigfox分析。
• Derived offer
这种情况适用于从一个RC到另外的RC中的情况，只要射频通信部分通符合Sigfox射频和协议规范，则授权对其进行设计变更。也可更换天线，但不可更换外壳、电池和传感器。
• Upgrade offer
它适用于Sigfox ReadyTM认证的设备，在保持相同型号名称（参考）和相同RC的情况下应用了重大更改。通常，由于产品改进、老旧过时管理等原因而导致的产品升级。主要变化包括天线、外壳、PCB布局、电池或电源、Sigfox库、振荡器和调制解调器设计的变化。

Sigfox认证流程图

3.2.2 需要做的准备

认证的主要内容是在
《Be prepared for Sigfox RF & protocol tests》
《Be prepared for Sigfox radiated performance tests》
上述两个文档中体现的，最终需要提供除模块外的，还需要提供内部和外部照片，数据表，物料清单、示意图和印刷电路板布局等…

P.S.
1、ID和秘钥应以非易失方式存储，同时这两个值不得被修改；
2、提供射频振荡器的数据表，包括老化值（5年）和温度公差（随温度范围）。

4.Dongle及RSA的使用

关于这一部分的使用主要的参考资料包括如下文档，如下文档大家可以在Sigfox的官方网站上下载，官方网站的地址为https://build.sigfox.com/。

《att19658091-SIGFOX SDR dongle -DATASHEET.pdf》
《Sigfox USB Dongle Downlink User Guide_doenlink_20181107.pdf》
《Sigfox+USB+Dongle+User+Guide20181102.pdf》
《att19643734-SIGFOX Network Emulator.pdf》
《47453347-RSA_userguide.pdf》》

Dongle实际上是一个连接到笔记本电脑的u盘，通过SMA连接器发送信号，兼容Sigfox网络仿真器和无线电信号分析仪软件包。可以把Dongle当做一个小的基站，用作研发时的调试。在拿到Dongle之后，我们首先打开他的Datasheet，可以看到Dongle的接收灵敏度和发送功率实际上是相比于基站而言有所衰减。

4.1 Sigfox网络仿真器（SNE）

Sigfox网络仿真器是在Sigfox SDR Dongle上运行的软件，专用于测试设备与应用程序之间的端到端和双向数据传输服务。通过Dongle上的SNE，可以测试从设备到应用程序的端到端数据服务，反之亦然，同时还可以连接主站，传输具有详细信息内容的调试应用程序。
如果想收到一个模块的上行数据，其实在SNE中，只需要配置好CONFIGURATION中的Radio部分就可以了，选好RC，其他的参数都是根据Sigfox协议中已经订好了特波特率和上下行中心频点。
然后在配置Device中的模块的ID号，配置好之后就可以在Message中收到终端模块发送上来的数据了。
配置好了之后就可以在SNR中看到一行数据。

那么分别对看到的数据给大家做一个简单的介绍，Device ID即为模块的ID号，该号码是由Sigfox公司唯一赋值的一个4字节的十六进制数据，具体的可以在前面协议中详细了解。Time即为Dongle接收到上行数据的时间，Sequence Number即为之前协议中所描述的Message Count，Data/Deconding即为上行数据中所真正发送的Payload数据，LQI即为信号强度的表示，Callbacks表示信号的上行数据和下行应答等是否成功。
Callbacks中的上行箭头和下行箭头分别表示的意思如下：

箭头方向	箭头颜色	表示含义
上行	灰	没有回调
上行	橙	在等待接收时的表示
上行	红	回调返回了错误代码
上行	绿	回调返回OK
下行	橙	过渡状态，等待响应的传输
下行	红	响应传输失败，失败的原因在ACKNOWLEDGE变量中
下行	绿	响应通过SNR已经发送了

上图中的绿色则表示Sigfox收到下行数据之后，返回的OOB数据，那么问题来了，如何配置下行数据呢。

在Configuration中的Callback中，右上角选择New之后，在Downlink data界面中配置不同的模式。
No Downlink： 表示不下发Downlink数据，即没有下行
Direct： 配置成该模式之后可以直接在Downlink mode下方的Downlink data in hexadecimal中填写要下发的十六进制的Hex数据即可。同时这里还提供了可以通过{time}、{RSSI}等方式下发刚刚收到的链路层的相关数参数。注意，配置完成之后需要在下方的url 中填写一个url地址（如果没有就随便填一个符合url格式的即可）。
Callback ：Callback模式中则将接收数据的url地址填在Callbacks-DATA中的url-pattern中，然后选好要配置的Post或Get模式，之后将格式改为json格式，将body部分配置好即可完成。

4.2 Sigfox无线电分析仪（RSA）

RSA用于测试无线电是否符合Sigfox在射频方面的基本要求。通过提供分析和自动结果，它提供了验证输出，为模块和参考设计的Sigfox经过验证的认证做准备。那么RSA实际上是用于Sigfox验证的认证要求测试无线电合规性，同时还可以当做一个小的频谱仪使用。
这一部分的安装过程请参考https://build.sigfox.com/sdr-dongle#rsa-getting-started中的RSA Getting Started部分

5. 系统开发集成

因为我本身不是做系统软件，但是在整个项目的调试过程中，对系统软件部分有一定的熟悉和了解。

后端可以使用 “callback” 系统自动转发某些事件。回调是一个自定义的http请求，其中包含发送到给定服务器/平台的设备数据以及其他变量。例如，当收到新设备消息，计算位置或检测到设备通信丢失时，将触发回调。回调的配置在设备类型页面中完成。

在这里分享几个网址和文档。
https://backend.sigfox.com/apidocs/callback
如果有熟悉这一部分的同行欢迎留言交流。

LPWAN——Sigfox实战经验介绍相关推荐

2018 年将打响 AI 战争，7 条实战经验帮你战胜恐惧
来源:36氪概要:不管是对科技巨头还是对创业公司,人工智能可以说是移动互联网时代以来最大的一个机遇.但是,人工智能同时也是让大多数人感到非常困惑的一项新技术,对它的发展现状和未来都非常迷惑. 不管是 ...
工业视觉智能实战经验之IVI算法框架2.0
简介: 工业视觉智能团队在交付了多个工业视觉智能质检项目后,发现了工业视觉智能的共性问题和解法,打造了工业视觉智能平台,通过平台的方式积累和提升工业视觉的通用能力.在平台建设上最核心的能力是算法能力. ...
RabbitMQ实战经验分享
RabbitMQ实战经验分享原文:RabbitMQ实战经验分享前言最近在忙一个高考项目,看着系统顺利完成了这次高考,终于可以松口气了.看到那些即将参加高考的学生,也想起当年高三的自己. 下面分享 ...
实战经验：从内存故障到CPU过高诊断-直播预告
主题摘要本次主题结合分享者多年来在主管运维工作中的故障处理实战经验,通过5个独立且有代表性的Oracle故障案例,深入浅出地解读故障分析思路并挖出故障背后的真相,继而抛砖引玉介绍Oracle故障分析 ...
客户端性能优化实战经验分享
合理的架构设计,对客户端后期优化至关重要暴风影音播放器一直因为"慢",而引发用户诸多抱怨.新发布的暴风影音5在启动速度上较暴风影音3提升了3倍.暴风影音播放研发总监黄森堂以暴风影 ...
未明学院：量化金融训练营开始报名，成为兼具数据分析技能+项目实战经验的复合型人才！
想进金融行业却不懂数据?你正在失去机会吴军在<硅谷之谜>一书中说,"大数据的本质,就是通过信息消除不确定性",而不确定性,在金融领域,就意味着收益和风险. 金融行业天 ...
C++软件异常的常见原因分析与总结（实战经验分享）
目录 1.概述 2.引发软件异常的常见原因 2.1.变量未初始化 2.2.死循环 2.3.内存越界 2.4.内存泄漏 2.5.空指针与野指针 2.6.内存访问违例 2.7.栈内存被当成堆内存去释放 2 ...
IT实施计划实战经验分享：避免失败
我们在之前文章<IT实施计划实战经验分享:如何制定>中描述了如何针对企业新的业务项目制定高质量的IT实施计划,例如首先针对新应用的设计和发布开发成熟的模式和方法论来实施标准化的流程等等.本 ...
Mybatis-Plus 通用枚举及前后端交互实战经验
Mybatis-Plus 通用枚举及前后端交互实战经验一.前言二.使用示例 1.全局配置 2.枚举类 3.实体类三.后端返回结果给前端(以jackson为例) 1.@JsonValue 2.@J ...
普元微服务架构封闭式开发实战经验
微服务(Microservice)架构目前受欢迎的程度已无需赘述.CSDN之前的文章解释了微服务是如何演变的,又为什么重要?然而微服务架构的迁移不可能一帆风顺,也会面临很多挑战,CSDN将通过已经投入 ...

LPWAN——Sigfox实战经验介绍

0.序