AVR-Chat

--- In AVR-Chat@yahoogroups.com, Don Jackson <ae5k.radio@g...> wrote:
> Here's a problem I have that maybe some of the gurus on this list can
> help with...
> 
> I'm just starting on a project which requires decoding of a rather
> unusual AFSK bitstream and am seeking some ideas/opinions on the best
> way to do it with an AVR chip (most likely ATMega88 or 168).
> 
> Each bit is equal length of 2100 microseconds (usec.) and consists of
> either 4 cycles each 525 usec. long (for a 1 bit) or 3 cycles each 700
> usec. long (for a 0 bit).  Frequencywise, this figures out to be
> approximately 1904.8 Hz and 1428.6 Hz.  This is a synchronous format
> with no start/stop bits to the 8 bit bytes being sent.  There are no
> provisions or restrictions on the number of same bits in a row which may
> be sent.  Some (a fairly good number of them) sync bytes are sent
> initially.  The total data string could be several hundred bytes long,
> so while the 2100 usec. bit length is pretty accurate, care must be
> taken to account for slight inaccuracy without depending on further sync
> pulses in the message.
> 
> To further complicate matters, unfortunately noise free operation cannot
> be assumed as there may be some unexpected glitches come through. This
> is not a format I'd chose for transferring data, but I'm stuck with it.
> 
> My initial thoughts are to try to time each pulse (cycle) to determine
> the bit ( 1 or 0 ) and to count the number of cycles so to figure out
> where one bit starts and ends.  In case of noise impulses, the length of
> the pulse/cycle will be less than anticipated value and could probably
> be discounted as long as there was another timer going which would
> anticipate the end of the bit time.  Not sure I'm making myself clear on
> this.
> 
> I'm certainly open to other thoughts on the matter.  Maybe this is not
> too unlike trying to decode barcode stuff (Dave VH?) and I should see
> what goes on there.
> 
> Anyone?
> 
> Regards,
> Don

There are a lot of questions unanswered.  Such as is this for use on
HF, VHF, landline or somekind of recording media?  As this is a
synchronous format what determines the sync? (normally a special
character or sequence of such). Can you live with errors or is there
forward error correction built in?  If you are using HF SSB you cannot
guarantee the received frequencies will be correct, although the
frequency shift will be the same.

What I would suggest is using an AFSK receiver chip (XR2211) followed
by a low pass filter and a squarer circuit to get the basic data
stream.  Both these will "tend" to help with noisy impulses but if you
are on HF there may be a lot of noise anyway.

Feed the data stream into the AVR and look initially for the preamble
stream (I'm presuming alternate 1s and 0s are sent first - quite
common) to determine that data is coming.  Then look for the specific
sync pattern (again presuming that there is one and you know what it
is).  

Use an edge in the preamble/sync phase to determine your clock
starting point then just rely on using a high speed clock with a large
divisor (16 bit) to get accurate timing. You can trim the divisor to
get the right timing.  If you want to be really clever use multiple
samples of each bit (say three samples at 3/8, 1/2 and 5/8 bit time)
and majority vote for the bit value.  Hint - use a timer in
auto-reload mode then it doesn't matter what else you are doing in
code it won't upset the timing.

If you have a spare pin on the micro use it to generate a "strobe"
pulse in the middle of the received data bit.  Then you can watch the
data and the strobe on a scope and see if there are any timing
discrepancies.

HTH
Alan