|
|
6 years ago | |
|---|---|---|
| doc | 6 years ago | |
| osdep | 6 years ago | |
| README.md | 6 years ago | |
| SConscript | 6 years ago | |
| airkiss.c | 6 years ago | |
| airkiss.h | 6 years ago |
//rtconfig.h
#define PKG_USING_AIRKISS_OPEN
#define AIRKISS_OPEN_DEMO_ENABLE /* airkiss应用示例 */
本解析库进最大程度的优化了丢包问题,在常规解析方式进行的同时 还应用了容错算法。例如:发送“abcd”,由于丢包第一轮只收到了“abc”, 下一轮只收到了“bcd”则可以根据两次接收结果拼凑出正确的序列。 残缺数据所在位置,可以通过序号字段和80211帧序号推测出来。然而 80211帧序号并不是完全依次增加。例如:包头帧序号分别为0、1,收到 “a”的帧序号也可能为3。这时推测出“a”的位置是[1]实际上它错了, 不过观测发现帧序号不依次增加的概率不是太高,也就是说 在多轮接收中总能碰到正确的。到底“a”在0还是1位置可以通过 CRC校验测试出来。
帧序号不依次增加拼凑出来的组合就可能会有“aacd”和“abcd”。 当第二轮收到“b”时发现它也在位置1,这时就出现了位置冲突。 如此,解决位置冲突又需要一个处理方式。我采用的方法是将冲突的 数据和位置信息保存起来,然后把它们的组合都校验一遍。
最优的扫描方式是先看下当前有多少通道并只扫描这些通道, 但这样会稍微麻烦点。最简单的方式就是逐个扫描但浪费时间。 对此我们可以减少时间的浪费来加快扫描。先给每个通道分配一个 较短的时间并对接收进行计数统计,然后以计数的三次方(上限200ms) 设置这个通道的等待时间。每轮扫描后再对统计结果进行适当衰减, 这样既保证了目标通道快速提升等待时间,又减少了那些 只有突发数据的通道占用过多时间。
为致敬腾讯airkiss带给大家的方便,特此研究学习了它的 通讯方式并将学习所得开源于此。为了不辱没airkiss的 名声,虽不能做到宇宙第一强解析库,但力求能解析我周围 每一个路由,不轻易放过每一次失败。由于个人资源有限 所测试wifisoc不过w600,如果你使用的rt-thread,遇到无法解析 的情况可以finsh执行"airkiss c 9 o0"(c 9只捕获9通道) 抓取指定通道的数据发给我分析。