Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/heyuanjie87/airkissOpen
腾讯airkiss协议解析库
https://github.com/heyuanjie87/airkissOpen
airkiss iot wifi
Last synced: about 5 hours ago
JSON representation
腾讯airkiss协议解析库
- Host: GitHub
- URL: https://github.com/heyuanjie87/airkissOpen
- Owner: heyuanjie87
- Created: 2019-05-16T06:09:25.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2020-04-11T01:38:01.000Z (almost 5 years ago)
- Last Synced: 2023-04-05T14:25:49.888Z (almost 2 years ago)
- Topics: airkiss, iot, wifi
- Language: C
- Homepage:
- Size: 51.8 KB
- Stars: 34
- Watchers: 6
- Forks: 10
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- awesome-rt-thread - airkissOpen - Tencent Airkiss Protocol parse library. (Packages / IoT)
- awesome-rt-thread - airkissOpen - Tencent Airkiss Protocol parse library. (Packages / IoT)
README
## 腾讯 WiFi设备一键配网协议(wifi SSID&PWD config protocol)
# 特性
- 提供上位机辅助调试工具,可加载wifi的抓包文件做改进分析
- 前导码阶段可同时接受两个路由的相同输入(参见 doc/cap1.txt)
- 数据阶段以两种方式接收:
1. 以收帧的先后顺序识别数据
2. 以帧序号为参考放置数据并拼接残缺的序列
# 启用(in rt-thread)
```
//rtconfig.h
#define PKG_USING_AIRKISS_OPEN
#define AIRKISS_OPEN_DEMO_ENABLE /* airkiss应用示例 */
```
# 示例
- [在rt-thread中应用](osdep/rtthread/airkiss_demo.c)
- [电脑模拟测试](osdep/qt/akWorker.cpp)
# 参考
- [博客文章](https://blog.csdn.net/lb5761311/article/details/77945848)
- [同时收到相同长度.记录](doc/cap1.txt)
- [数据序列丢包.记录](doc/cap2.txt)
- [完全无完整序列.记录](doc/cap3.txt)
- [时间特征.记录](doc/时间特征.txt)
# 发送工具
- [airkissDebugger](https://iot.weixin.qq.com/wiki/document-0_6.html)
- 微信打开: http://wx.ai-thinker.com/api/old/wifi/config?from=singlemessage
# 测试结果
- [报告](doc/test-report.md)
# 锁定优化
在办公环境中周围可能存在较多其它也在发送广播的应用，而锁定通道前
我们不知道哪个地址(路由+手机)的是目标帧，所以就得把它们都
缓存起来等收到两个以上再做判决。然而空间有限，缓存所有地址的
长度信息并不可行。我们知道在这些海量的信息中符合要求的也就1或2个，
让符合要求的长期用一个缓冲区不符合的共用一个会是一种不错的选择。
所以我们可以对缓冲区设置权重，越符合规律的权值越高就越不容易被替换。
本库为锁定阶段设置了3个长度信息缓冲区，对于会同时发出两个，地址不同
数据相同的路由，有2个缓冲区供其占用，剩下一个留给其他所有帧。
这样既让曙光不会溜走又让游荡的灵魂有所安放，皆大欢喜。
# 容错方法
本解析库进最大程度的优化了丢包问题，在常规解析方式进行的同时
还应用了容错算法。例如:发送“abcd”,由于丢包第一轮只收到了“abc”,
下一轮只收到了“bcd”则可以根据两次接收结果拼凑出正确的序列。
残缺数据所在位置，可以通过序号字段和80211帧序号推测出来。然而
80211帧序号并不是完全依次增加。例如:包头帧序号分别为0、1，收到
“a”的帧序号也可能为3。这时推测出“a”的位置是[1]实际上它错了，
不过观测发现帧序号不依次增加的概率不是太高，也就是说
在多轮接收中总能碰到正确的。到底“a”在0还是1位置可以通过
CRC校验测试出来。
帧序号不依次增加拼凑出来的组合就可能会有“aacd”和“abcd”。
当第二轮收到“b”时发现它也在位置1，这时就出现了位置冲突。
如此，解决位置冲突又需要一个处理方式。我采用的方法是将冲突的
数据和位置信息保存起来，然后把它们的组合都校验一遍。
由于空间以及时间复杂度的限制，当前可记录12个冲突信息。
# 扫描优化
最优的扫描方式是先看下当前有多少通道并只扫描这些通道，
但这样会稍微麻烦点。最简单的方式就是逐个扫描但浪费时间。
对此我们可以减少时间的浪费来加快扫描。先给每个通道分配一个
较短的时间并对接收进行计数统计，然后以计数的三次方（上限200ms）
设置这个通道的等待时间。每轮扫描后再对统计结果进行适当衰减，
这样既保证了目标通道快速提升等待时间，又减少了那些
只有突发数据的通道占用过多时间。
# 后记
为致敬腾讯airkiss带给大家的方便，特此研究学习了它的
通讯方式并将学习所得开源于此。为了不辱没airkiss的
名声，虽不能做到宇宙第一强解析库，但力求能解析我周围
每一个路由，不轻易放过每一次失败。由于个人资源有限
所测试wifisoc不过w600,如果你使用的rt-thread，遇到无法解析
的情况可以finsh执行"airkiss c 9 o0"(c 9只捕获9通道)
抓取指定通道的数据发给我分析。如果你要问这个库到底有多快，
我可以毫不负责任的靠诉你比我吹牛逼的速度还快：某一个巧合
的瞬间我正在想“你一定要快如闪电”当这句话在我脑海中还没
想完的时候已经解析完成了。