aprs实际的数据帧是啥呢 [复制链接]

求教下各位高手，aprs实际的数据帧是啥呢，比如tt，接收了gps数据，组合成具体的哪种格式的数据帧，调制成哪种音调的afsk再发射呢

这个好像aprs手册上应该会有，还有个办法，就是装个aprs的软件，在电台上发射一下就知道了

aprs使用的依旧是ax25协议.

http://www.tapr.org/pub_ax25.html

搞不清aprs发送的数据协议，下了个所谓ax.25协议，看了半天，感觉不知哪位老大写的哥德巴赫猜想 。搞到半夜3点，做了2件事：
1、猜想拼凑出一条参考协议格式“bh4tdv>apsprs,dstar*:!3636.14n/11428.78e>253/00532m 09x 19s 4.16v”
调制成txd=1,1200hz；txd=0,2200hz，1200bps速率的afsk,用agwpe+agwtracker，解调不出，用0906通讯器倒是很顺利解调出数据,估计还是协议格式问题。

2、找出来一个tt1.6,连接gps，直接接入pc声卡，用agwpe+agwtracker，同样解调不出。何故

呵呵，留贴备忘
agwtracker监控窗口显示
1:fm bh4tdv to apagw <ui pid=f0 len=29 >[1236]
=3134.01n/12020.12e>china ham

串口监测到的数据
c0 00
82 a0 82 8e ae 40 60 84 90 68 a8 88 ac 61
03 f0
3d 33 31 33 34 2e 30 31 4e 2f 31 32 30 32 30 2e 31 32 45 3e 43 48 49 4e 41 20 68 61 6d c0

拜读ax25协议手册,p10页

hex   82 a0 82 8e ae 40   60   84   90   68   a8   88   ac   61

asc   a p   a g w   (space) 0   b   h   4   t     d   v   (ssid)    

a1-a14要转换下才能正确（理解为相当于加密）

如：82(hex)=10000010(bin),右移一位，=01000001（bin）=(hex)=a(ascii)

留贴备忘 :d

mark一下，支持。
找个tnc源码看看应该就看明白了

马克一个看看

'

呵呵，留贴备忘
agwtracker监控窗口显示
1:fm bh4tdv to apagw <ui pid=f0 len=29 >[12[表情]36]
=3134.01n/12020.12e>china ham
串口监测到的数据
c0 00
82 a0 82 8e ae 40 60 84 90 68 a8 88 ac 61
03 f0
3d 33 31 33 34 2e 30 31 4e 2f 31 32 30 32 30 2e 31 32 45 3e 43 48 49 4e 41 20 68 61 6d c0
拜读ax25协议手册,p10页
hex   82 a0 82 8e ae 40   60   84   90   68   a8   88   ac   61
asc   a p   a g w   (space) 0   b   h   4   t     d   v   (ssid)    
a1-a14要转换下才能正确（理解为相当于加密）
如：82(hex)=10000010(bin),右移一位，=01000001（bin）=(hex)=a(ascii)
留贴备忘 :d

'



研究了一下您提到的问题，想重建ax.25数据帧不能完全根据上面的串口监测数据，这个数据不是一个最终封装好的调制数据，而是计算机跟tnc之间的kiss接口数据，跟最终的tnc输出的调制数据并不完全一样，这可能是您重建不成功的原因吧。

在重建ax.25数据帧的时候需要注意下面的要求：

第一，必须开始使用7e(hex)的标志段作为一个帧起始和结束，而不是使用上面的c0(hex)开始和结束，上面说了c0是kiss接口协议的帧结束标志，只限于pc跟tnc之间的交流用途。

第二，a1-a14并非加密，因为hdlc的扩展需要以及呼号asc-ii码只使用7bits的原因，每个字节的最低位作为hdlc的扩展位使用，换言之最后一位不是给呼号用的。

第三，根据v2版的ax.25要求，在aprs ui帧中a14的第7位设置为1，例如上面的a7为60而a14为61.

第四，注意处理可能出现的连续5个1跟7e标志段的冲突。

第五，监测一下同一个ui帧连续发送时的控制段是否一致，有可能需要序号累加。

第六，别忘了重建的最后要提供crc校验段。

感冒头疼中，先想到这些，希望能对您有帮助！

'

研究了一下您提到的问题，想重建ax.25数据帧不能完全根据上面的串口监测数据，这个数据不是一个最终封装好的调制数据，而是计算机跟tnc之间的kiss接口数据，跟最终的tnc输出的调制数据并不完全一样，这可能是您重建不成功的原因吧。
在重建ax.25数据帧的时候需要注意下面的要求：
第一，必须开始使用7e(hex)的标志段作为一个帧起始和结束，而不是使用上面的c0(hex)开始和结束，上面说了c0是kiss接口协议的帧结束标志，只限于pc跟tnc之间的交流用途。
第二，a1-a14并非加密，因为hdlc的扩展需要以及呼号asc-ii码只使用7bits的原因，每个字节的最低位作为hdlc的扩展位使用，换言之最后一位不是给呼号用的。
第三，根据v2版的ax.25要求，在aprs ui帧中a14的第7位设置为1，例如上面的a7为60而a14为61.
第四，注意处理可能出现的连续5个1跟7e标志段的冲突。
第五，监测一下同一个ui帧连续发送时的控制段是否一致，有可能需要序号累加。
第六，别忘了重建的最后要提供crc校验段。
感冒头疼中，先想到这些，希望能对您有帮助！

'

拜读！学习了 。。。

how to send ax.25 ui frames using inexpensive pic microprocessors

abstract: this paper provides step by step documentation of how to implement ax.25 ui frames using inexpensive pic microcontrollers. it is designed primarily for those who wish to implement packet radio ui beacons for point to multipoint communications. the article assumes some knowledge of programming concepts and pic microprocessors. it also discusses the limitations that must be overcome in order to build a completely pic based terminal node controller.

keywords: ax.25, ui frames, pic microprocessors


what you see above is the packet as it would appear on your tnc. there is actually somewhat more to it than this. the ax.25 protocol divides the packet into seven sections as follows:

1. flag (s)
2. address
3. control
4. protocol identifier (pid)
5. information
6. frame check sequence
7. flag (s)

-------------
附件中的这个文章应该对楼主有用，还没仔细看，但abstract说的比较诱人。虽然是针对pic的，但算法却是通用的。