分享一下近日我学习APRS硬件解决方案和软件算法的几点收获 [复制链接]

近一段时间，使用业余时间，稍仔细地学习了一下aprs相关设备的硬件解决方案和软件算法，有一点点心得体会，写出来和大家分享一下。下文所述观点并不一定是完全正确的，会受得本人理解问题的能力、观察问题的角度等原因，而有所不足甚至错误，还请各位老师指点，也欢迎各位喜欢aprs的朋友共同讨论。

1、硬解还是软解。
不可否认的是，从目前大家的体会来看，硬解的稳定性是明显优于软解的。这基本上是自然的，因为软解与硬解相比，必然需要耗费更多的mcu资源。但我想说的是，如果在硬件方案和软件算法上仔细优化，软解的效果将比现在的软解效果要好一些。

2、“发送延迟”是什么？只是发送的延迟么？
“发送延迟”这种参数会在所有有音频编码发送功能的aprs设备中出现，之前我所理解的“发送延迟”，以为是指“ptt信号有效后，多长时间开始送编码好的音频”。不过通过近一段的时间的学习，我发现我原来这种观点可能是错误的。

现在我认为，“发送延迟”是指信道上空闲了多长时间后，本机才可以转为发送ax.25音频调制信号的状态。

另外要说的是，按我的理解，不论是在kiss tnc、digi，还是在tracker中，“固定时间”的“发送延迟”参数，都是一种不是最好的选择。虽然软件上实现起来，固定时间方便很多。但固定时间的发送延迟，将非常有可能引发“包碰撞”（就是指两个以上的设备在同区域内同时发送信号，造成互相干扰或压制），这种情况更可能发生在同一种设备在同一地区使用的情形之下。kiss协议中，明确规定了这种“随时发送延迟时间”的算法，虽然只是kiss协议中的规定，但我认为即使在在digi和tracker中，这种算法也可以尽量的减少包碰撞的可能性，所以我本人强烈推荐所有的aprs发送设备都应使用kiss协议中这种算法。

3、tnc软件的单工、双工、半双工
说到这里，可能有朋友会先笑我了，在现在的使用单工电台的情况下，有必要设计半双工或双工的软件形式么？

回答是，我认为非常有必要。虽然电台的确是单工工作的，但我们可以设想一下，如果单方向有一个连续的信号（可以是vhf信道的ax.25信号，或是pc送给kiss tnc串口的kiss协议串口数据流），如果软件设计成单工工作的，接收到一整句后转发向另一端的端口，那么向另一端发送时，原来这端的接收工作就停止掉了，造成转换数据的丢失。

现在的mcu，完全有能力，使单方向的协议转换与传输，连续进行。

当然，串口kiss协议数据送往ax.25编码端，会受到两端协议传输速率的不同，而产生溢出情况，但软件上的双工设计，将可以使转换尽量少丢失数据，甚至于使转换与传输的速率，接近于低速端的速率。

回头再说之前所说的“软解”，很多朋友喜欢用“解码率”来描述它的性能，但大家想想，这种“解码率”性能，真的完全是“软解”造成的么？

4、路径
路径设计是ax.25协议的一种精华。路径平衡了传递消息与减少信道繁忙度两者之间的冲突。kiss tnc并不需要设置路径，因为kiss协议是个“透明协议”。但在digi和tracker中，都是需要进行相关设置的(本处将digi的别名也纳入到路径的范畴中了)。正是路径很重要，所以我们需要尽量设置完善的路径配置，在tracker中，可以根据自己所处的aprs网络环境特点来进行设置。在digi中，良好和正确的别名设置与处理方法，可以使其他人的消息得到尽量好的传递，同时还能尽量减小信道的繁忙度。

个人认为diy的aprs设备，对软件的设计要求要远高于硬件。

哈哈，这显然只是个笑话

大师，ic味，学习了，求电路图。

记号 不错

顶~~~~~~好久没再研究这东西了

'

1、硬解还是软解。
不可否认的是，从目前大家的体会来看，硬解的稳定性是明显优于软解的。这基本上是自然的，因为软解与硬解相比，必然需要耗费更多的mcu资源。但我想说的是，如果在硬件方案和软件算法上仔细优化，软解的效果将比现在的软解效果要好一些。

'

确实如此，高端的tnc解码全部都转向了dsp，也就是软解。
我们平时讨论的软解是基于原始的过零检测判断机理配合简单算法，性能难以大幅提高，效果自然不敢恭维，而采用高速dsp和优化算法的解码器应该完全超越传统的硬解。

'

2、“发送延迟”是什么？只是发送的延迟么？
“发送延迟”这种参数会在所有有音频编码发送功能的aprs设备中出现，之前我所理解的“发送延迟”，以为是指“ptt信号有效后，多长时间开始送编码好的音频”。不过通过近一段的时间的学习，我发现我原来这种观点可能是错误的。
现在我认为，“发送延迟”是指信道上空闲了多长时间后，本机才可以转为发送ax.25音频调制信号的状态。

'

ax.25协议的延时计时器多达13种，每种计时器功用不一，上面提及的“发送延迟”可能是指“txdealy”也就是t103计时器，这确实为发射机键控后的准备时间，您先前的理解应该是正确的。

在ax.25协议中为防止几个电台同时急着上车打架特别设置了一个单独的看门人（时隙计时器t102：p-persistence），t102这个看门人在信道空闲之后大家都争着要跑的时候以随机方式延迟电台的发送时隙。也就是说即使大家同时检测到信道空闲，也不会同时开始发送，因为每个台站产生的延迟时隙是随机的而不是固定的，所以每次总是随机抽到好签的那个家伙先走（类似我们的领导先走）。

走运的那个家伙发完之后看门人t102又重新计时看看下一个谁能踩到狗屎，不用担心某个倒霉蛋一直轮不上，因为他们每次都是重新抽签而不是一个签拿到最后的，这要比打扑克拿到一副烂牌要公平的多。

不过ax.25世界里有些家伙确实比较特殊，他们就像我们的领导子女要考公务员一样，在所有人抽签前预留了好几个位置，如果他们想先走，后面的那些排队的傻帽就白等了，这些领导子女一般头上带有一些特殊标签（rr），好像那些特权车一样上面挂了一个警灯，可以不用像p民一样等绿灯，这就是t101优先时隙计时器（priack）。

'

另外要说的是，按我的理解，不论是在kiss tnc、digi，还是在tracker中，“固定时间”的“发送延迟”参数，都是一种不是最好的选择。虽然软件上实现起来，固定时间方便很多。但固定时间的发送延迟，将非常有可能引发“包碰撞”（就是指两个以上的设备在同区域内同时发送信号，造成互相干扰或压制），这种情况更可能发生在同一种设备在同一地区使用的情形之下。kiss协议中，明确规定了这种“随时发送延迟时间”的算法，虽然只是kiss协议中的规定，但我认为即使在在digi和tracker中，这种算法也可以尽量的减少包碰撞的可能性，所以我本人强烈推荐所有的aprs发送设备都应使用kiss协议中这种算法。

'

概念好像有些混淆，kisstnc或者kiss interface只对应着ax.25的第一层和第二层（部分），digi则是第三层的协议，所以他们之间没法比较，不过上面担心的避免包碰撞的算法大都具备，有的是tnc的链路层实现的，有的是计算机程序实现的。

kiss的最大好处是硬件成本比较低，终端或者计算机程序可以直接跟底层打交道所以灵活性比较高（便于开发新协议），而且不会碰到各个tnc版本的链路层兼容性问题，其缺点是很多该由tnc处理的事情都推给计算机了，不过现在硬件固件化和软件化是趋势。

差距啊，看一次打击一次 都有不在玩aprs的心了。。。。啥时候能跟上bd4os老大的水平呢。。。

'

差距啊，看一次打击一次 都有不在玩aprs的心了。。。。啥时候能跟上bd4os老大的水平呢。。。

'

vbcode兄谦虚了，有机会还要试用一下您的aprs程序呢！好像听说您存放程序代码的设备丢失了？现在还在做吗？