[aprssig] Understanding packet

[scott at opentrac.org]

I wrote up some of this at http://n1vg.net/packet.

As someone pointed out to me recently, it doesn't actually seem to be NRZI as commonly documented, but maybe more properly NRZ-S.  That is, a change in tones encodes a zero, and no change encodes a one.

The bit stuffing is there to ensure enough transitions to keep from losing sync.  Your transmitter and receiver usually don't have exactly the same idea of how long one bit period is, and if you go too long with no transitions then they can drift apart.  The way it works is that the sender inserts a zero (transition) every time there's a run of 5 ones, except in the case of the 0x7e flag.

0x7e marks the start and end of the frame.  You're better off sending zeros (alternating tones) in the txdelay time to get faster receiver lock.

The frame check sequence is a CRC-CCITT16.

Scott
N1VG
  _____  

From: Andrew Rich [mailto:vk4tec at people.net.au]
To: Aprssig [mailto:aprssig at lists.tapr.org]
Cc: ozaprs [mailto:ozaprs at aprs.net.au]
Sent: Thu, 03 May 2007 13:32:03 -0700
Subject: [aprssig] Understanding packet

  
Gudday  
   
I have a few   questions concerning packet radio.  
   
+ I think from   memory that packet does not simply use 1200 = high or 2200 =   low.  
   
+ Does it keep   flicking between tones to "keep the energy up" in the detector   ?  
   
+ And a non flick is   a state change ?  
   
+ From what I have   been reading 0x7e or 011111110 is the start or txdelay ?  
   
+ What is the bit   stuffing i hear about ? why is that so ?  
   
+ I have noticed an   MX614 does tone changes at the zero point, what are the distanvantages then of   using xr2206 xr2211 that do not do this ?  
   
+ Does packet use a   CRC method ? is that what the passall command is in a tnc ? show now crc   chucksum valid packets ?  
   
+ From what I can   see on my bench testing, one cycle of 1200 Hz and two cycles of 2200 Hz fits   nicley into 1200 baud ? coincidence ?   
   
Regards  
   
Andrew     
   
VK4TEC  
   
   
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20070503/5871950c/attachment.html>