|
|
@@ -33,6 +33,16 @@
|
|
|
# 测试结果
|
|
|
- [报告](doc/test-report.md)
|
|
|
|
|
|
+# 锁定优化
|
|
|
+在办公环境中周围可能存在较多其它也在发送广播的应用，而锁定通道前
|
|
|
+我们不知道哪个地址(路由+手机)的是目标帧，所以就得把它们都
|
|
|
+缓存起来等收到两个以上再做判决。然而空间有限，缓存所有地址的
|
|
|
+长度信息并不可行。我们知道在这些海量的信息中符合要求的也就1或2个，
|
|
|
+让符合要求的长期用一个缓冲区不符合的共用一个会是一种不错的选择。
|
|
|
+所以我们可以对缓冲区设置权重，越符合规律的权值越高就越不容易被替换。
|
|
|
+本库为锁定阶段设置了3个长度信息缓冲区，对于会同时发出两个，地址不同
|
|
|
+数据相同的路由，有2个缓冲区供其占用，剩下一个留给其他所有帧。
|
|
|
+这样既让曙光不会溜走又让游荡的灵魂有所安放，皆大欢喜。
|
|
|
|
|
|
# 容错方法
|
|
|
本解析库进最大程度的优化了丢包问题，在常规解析方式进行的同时
|
|
|
@@ -49,6 +59,7 @@ CRC校验测试出来。
|
|
|
当第二轮收到“b”时发现它也在位置1，这时就出现了位置冲突。
|
|
|
如此，解决位置冲突又需要一个处理方式。我采用的方法是将冲突的
|
|
|
数据和位置信息保存起来，然后把它们的组合都校验一遍。
|
|
|
+由于空间以及时间复杂度的限制，当前可记录12个冲突信息。
|
|
|
|
|
|
# 扫描优化
|
|
|
最优的扫描方式是先看下当前有多少通道并只扫描这些通道，
|
|
|
@@ -66,4 +77,7 @@ CRC校验测试出来。
|
|
|
每一个路由，不轻易放过每一次失败。由于个人资源有限
|
|
|
所测试wifisoc不过w600,如果你使用的rt-thread，遇到无法解析
|
|
|
的情况可以finsh执行"airkiss c 9 o0"(c 9只捕获9通道)
|
|
|
-抓取指定通道的数据发给我分析。
|
|
|
+抓取指定通道的数据发给我分析。如果你要问这个库到底有多快，
|
|
|
+我可以毫不负责任的靠诉你比我吹牛逼的速度还快：某一个巧合
|
|
|
+的瞬间我正在想“你一定要快如闪电”当这句话在我脑海中还没
|
|
|
+想完的时候已经解析完成了。
|
heyuanjie87