AVR-Chat

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

On Thu, 2005-08-18 at 14:10 -0500, Don Jackson wrote:
> Here's a problem I have that maybe some of the gurus on this list can
> help with...

   Well, perhpas a little extra hardware is in order, since the noise
problem could lead to loss of synchronization.

   You can obtain single chip filters that could be easily ruend using
external R-C va;ues to your two frequencies, then use Schmidt Trigger on
the output of thefilter to generate a trigger pulse everytime the signal
is at that frequency.  Just run those to a pair of interrupt enabled
inputs on your AVR, and count the pulses.  Since you know what the bit
timing is, it should be fairly easy to distinguish noise, and to
identify mutliple bits of the same freqency.

  Granted, external hardware may not be the ideal solution either, but
it occurs to me off the top of my head to be a way around the problem of
losing sync.

Tom

On 18 Aug 2005 at 21:05, Thomas Keller wrote:

>    You can obtain single chip filters that could be easily ruend using
> external R-C values to your two frequencies, then use Schmidt Trigger on
> the output of thefilter to generate a trigger pulse everytime the signal
> is at that frequency.  Just run those to a pair of interrupt enabled
> inputs on your AVR, and count the pulses.  Since you know what the bit
> timing is, it should be fairly easy to distinguish noise, and to
> identify mutliple bits of the same freqency.


	The two filter approach can be done in software by the AVR.  
	Take a look at this document:

	http://www.baycom.org/~tom/ham/da95/d_dspmod.pdf

	I designed a radio modem for a client using exactly that modem.
	The C routines need to be translated to assembly for speed and 
the math can be done in 16-bit fixed point.
	After demodulation the remaining task is straightforward.

	Mark

On Fri, 2005-08-19 at 00:37 -0300, Mark Jordan wrote:
> http://www.baycom.org/~tom/ham/da95/d_dspmod.pdf

   I'm afraid I am still unenlightened...my German is still what it
never was.  *grin*

  Though I know it is possible to do the filtering in software, I am not
siufficiently familiar with the specifics of the techniques to know if
thew AVR is either A) fast enough, or B) powerful enough to accomplish
this is in realtime.  By no means am I suggesting that it is not, I
simply don't know.

Tom

On 19 Aug 2005 at 11:13, Thomas Keller wrote:

> On Fri, 2005-08-19 at 00:37 -0300, Mark Jordan wrote:
> > http://www.baycom.org/~tom/ham/da95/d_dspmod.pdf
> 
>    I'm afraid I am still unenlightened...my German is still what it
> never was.  *grin*
> 
>   Though I know it is possible to do the filtering in software, I am not
> siufficiently familiar with the specifics of the techniques to know if
> thew AVR is either A) fast enough, or B) powerful enough to accomplish
> this is in realtime.  By no means am I suggesting that it is not, I
> simply don't know.
> 
> Tom
> 

	My german is below zero... But those C routines are in english.

	BTW, I designed that 1200bps modem using an ATMEGA8 running
at 6.144MHz. Lots of time...

	You just have to sample the ADC at 8 times the bit rate.
	At every sample you have to do that math as in the article.
	The rest is bit sync and byte sync.

	Mark Jordan

Mark Jordan wrote:
> On 19 Aug 2005 at 11:13, Thomas Keller wrote:
> 
> 
>>On Fri, 2005-08-19 at 00:37 -0300, Mark Jordan wrote:
>>
>>>http://www.baycom.org/~tom/ham/da95/d_dspmod.pdf
>>
>>   I'm afraid I am still unenlightened...my German is still what it
>>never was.  *grin*
>>
>>  Though I know it is possible to do the filtering in software, I am not
>>siufficiently familiar with the specifics of the techniques to know if
>>thew AVR is either A) fast enough, or B) powerful enough to accomplish
>>this is in realtime.  By no means am I suggesting that it is not, I
>>simply don't know.
>>
>>Tom
>>
> 
> 
> 	My german is below zero... But those C routines are in english.
> 
> 	BTW, I designed that 1200bps modem using an ATMEGA8 running
> at 6.144MHz. Lots of time...
> 
> 	You just have to sample the ADC at 8 times the bit rate.
> 	At every sample you have to do that math as in the article.
> 	The rest is bit sync and byte sync.
> 
> 	Mark Jordan

Thanks Tom and Mark for your responses and ideas on this matter.  I'd
seen that pdf file before but had not thought about it in reference to
my problem.  My mindset was more in the mode of measuring actual times
since the bitstream timing was so "neat"; but it appears I need to do
some breadboarding and experimenting with the DSP possibilities.

My German is poor, although from memory with the help of Babel Fish (
http://world.altavista.com/tr ) I managed to struggle through most words
in both the presentation text and the comments in the pseudo-C code
shown.  I'm also not an expert with DSP stuff, but know enough to try
coding in assembly to see what I can come up with. Should be good
experience anyway.

Any alternate ideas and suggestions are always welcome.  I'll report my
results eventually to the reflector here ... this is not a high priority
project so it may be a while.

Don

>
>
>Thanks Tom and Mark for your responses and ideas on this matter.  I'd
>seen that pdf file before but had not thought about it in reference to
>my problem.  My mindset was more in the mode of measuring actual times
>since the bitstream timing was so "neat"; but it appears I need to do
>some breadboarding and experimenting with the DSP possibilities.
>
>Don

  A few people have made fsk modems based on measuring the zero cross of 
the audio signal. Generate an interrupt and use the capture mode on one of 
the timers to determine period.

  Most of the examples I've seen (because that's what i was interested in) 
are 1200 bps bell 202. But it may be similar enough to what you are 
attempting to give you some ideas.

  A lot of the projects are pic based , but some are avr. Also the method 
is generic enough to learn a lot from looking at the pic approaches (a 
minor sacrilege). Try googling 'avr fsk modem'.

Some links.
http://www.vfx.hu/proj/fskmodem/fskmodem_eng.html  scroll down
http://www.avrfreaks.net/index.php?module=FreaksTools&func=viewItem&item_type=tool&item_id=317
http://www.analogservices.com/vhdlmod.htm

Sorry if this is too far away from what you are looking for.

-carl

--- 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