10khz DBSK decoder

>(snip)
>
>My Master's Thesis has an ancient, student-written, all-assembly 
>algorithm for MSK in it.  But there's a block diagram that applies.  You

>may be interested in taking a look: 
>http://www.wescottdesign.com/articles/MSK/mskTop.html.
>
>The hardware way to do this would have been to lock on to the suppressed

>carrier using a square-and-PLL or a Costas loop, then extract the data 
>clock with another PLL, then use the PLL outputs to drive a demodulate, 
>integrate and dump.
>
>A more "DSPish" thing to do would probably be to bring your signal in, 
>multiply it by a 10kHz sine wave and it's quadrature (so, sine and 
>cosine), integrate each channel with a 200 microsecond long boxcar 
>filter, and look for phase changes.  You'll still need to extract the 
>data clock.
>
>In an AVR, you may want to come closer to the 'hardwareish' thing: run 
>the whole thing as a Costas loop or as a signal-square-and-PLL, and do 
>integrate-and-dump.  This will allow you to reduce the number of signals

>running around, and the integrate-and-dump will reduce the computational

>load and storage requirement over an alway-updating FIR.
>
>-- 
>
>Tim Wescott
>Wescott Design Services
>http://www.wescottdesign.com
>
>Do you need to implement control loops in software?
>"Applied Control Theory for Embedded Systems" gives you just what it
says.
>See details at http://www.wescottdesign.com/actfes/actfes.html
>

Thanks for taking the time to reply Tim.  I used the 6800 device back in
the 1970s. Your code was easy to follow. Would be nice to examine it in
.txt or .asm text document format. As far as your apology for the
"spaghetti code" style, I remember instructing my students on the two
unforgivable sins of coding for others to view:

1) Excesive Cryptic defines scattered over multiple source files that only
have meaning to the original author.
2) Unnecessary & unstructured module crafting. (spaghetti code patially
fits fits here?)

Time critical requirements can cancel out rule #2 within reasonable
limits.

>
>You may also be able to reduce clock cycles by 'multiplying' by a 10kHz 
>square wave -- whether you need to do this depends on the cost of a 
>multiply in your AVR.  I know that the demodulator in my thesis radio 
>worked on 400 baud data being sampled at 6800Hz or so, and it was with a

>processor (68HC11) that's more than 10 times less capable than an AVR 
>running at full speed.

I'm running an AVR with 20mhz capability and HW MUL in the core. Not bad
for a $2.00 part.  If I read your code correctly, you are using 8bits A/D?
The SAR in the AVR can generally perform a convertion in ~13 clock cycles
(~25 cycles for the first sample-read).

I noticed you used 15 samples per cycle scan. My signal has relatively low
noise. Could I get away fewer samples with sacrificing end results? I ask
this only out of curiosity. Far be it from me to question your design
motives!

The ADC can be programmed to perform an ISR after each convertion, but
this timing is dependent on the ADC pre-scaler and probably no where near
the input sample needs? I'll probably use your concept where the ADC is
read during a scheduled TMOVF isr and start a new conversion within the
scope of this module.

If anything I've assumed here is incorrect Tim, please let me know. I have
no ego to bruise when someone with your talent is trying to help.

I'll give it a go. Thanks for the useful link and pointers Tim.
B.R.
Jack

On Mon, 14 Jul 2008 06:04:51 -0500, "ijt" <ijackt@sbcglobal.net>
wrote:

>>It's a USENET group, ergo it has flame wars.  It gets aliased from at 
>>least one web site (DSPrelated), but it's still USENET.
>>
>>So, do the USENET thing:  stay above 'em or dive in.  Just don't expect 
>>them to go away.
>>
>
>Point well taken Tim. Uhm...On this one, I'll try to stay above 'em.
>Whether he goes away from this or not depends on his charater?

Hmmm...you said you'll stay above 'em and then in the next sentence
make unfavorable implications about the individual.

FWIW, he's been posting here for a while, and while his style can be a
bit abrasive I've found his technical input to be highly competent and
generally reliable.   I he left I'd consider it a substantial loss to
the newsgroup.

Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org

Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php

>On Mon, 14 Jul 2008 06:04:51 -0500, "ijt" <ijackt@sbcglobal.net>
>wrote:
>
>>>It's a USENET group, ergo it has flame wars.  It gets aliased from at 
>>>least one web site (DSPrelated), but it's still USENET.
>>>
>>>So, do the USENET thing:  stay above 'em or dive in.  Just don't expect

>>>them to go away.
>>>
>>
>>Point well taken Tim. Uhm...On this one, I'll try to stay above 'em.
>>Whether he goes away from this or not depends on his charater?
>
>Hmmm...you said you'll stay above 'em and then in the next sentence
>make unfavorable implications about the individual.
>
>FWIW, he's been posting here for a while, and while his style can be a
>bit abrasive I've found his technical input to be highly competent and
>generally reliable.   I he left I'd consider it a substantial loss to
>the newsgroup.
>
>Eric Jacobsen
>Minister of Algorithms
>Abineau Communications
>http://www.ericjacobsen.org
>
>Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php
>

Eric,

He is fortunate to have such favorable attitudes from his peers. I
probably should not reply to this. But for HIS sake, and to show my
hind-quaters are not made of cobalt, please let me clarify.

>If he left I'd consider it a substantial loss to
>the newsgroup.

Agree totally! Re-read my initial post. "His code sample worked PERFECT".

I did a lot of research to find a highly skilled individual to help with
my problem.  From my googling, HE is probably as good as it gets w/DSP!!!


It has been over 2000 years since any human knew every detail about ever
subject. If he was an expert in every field, he could have cautioned me
using C# and the special steps would have to be taken to use his code, or
at least written the code in C# (which I first asked for). Just because the
worlds finest Geologist can answer 99.999... percent of questions regarding
formations does not qualify him as the best choice for space travel to
other planets. This takes nothing away from an individuals  gifts and
talents, but most of all, there hard work to become a specific area
expert.

Next point.
I stand by statement. It never entered my mind to be offensive or
inflamitory, just an accurate reply to an earlier post. Sorry you took it
as a challenge. In retrospect, the "Uhm...On this one, I'll try to stay
above 'em." was probably improper. The second part was very pertinent to
the post reply.

Last point.
He should have never replied, as none would have known the source. I only
mentioned the incident to display my frustration. Even the best of us get
in over our head. In this area, I'm sure he has a good track record. Wow,
this getting too personal.

I hope you view this in another way Eric. Let's stay technical and not let
this become an unnecessary tragedy (almost silly?).

Jack

ijt wrote:
>> (snip)
>>
>> My Master's Thesis has an ancient, student-written, all-assembly 
>> algorithm for MSK in it.  But there's a block diagram that applies.  You
> 
>> may be interested in taking a look: 
>> http://www.wescottdesign.com/articles/MSK/mskTop.html.
>>
>> The hardware way to do this would have been to lock on to the suppressed
> 
>> carrier using a square-and-PLL or a Costas loop, then extract the data 
>> clock with another PLL, then use the PLL outputs to drive a demodulate, 
>> integrate and dump.
>>
>> A more "DSPish" thing to do would probably be to bring your signal in, 
>> multiply it by a 10kHz sine wave and it's quadrature (so, sine and 
>> cosine), integrate each channel with a 200 microsecond long boxcar 
>> filter, and look for phase changes.  You'll still need to extract the 
>> data clock.
>>
>> In an AVR, you may want to come closer to the 'hardwareish' thing: run 
>> the whole thing as a Costas loop or as a signal-square-and-PLL, and do 
>> integrate-and-dump.  This will allow you to reduce the number of signals
> 
>> running around, and the integrate-and-dump will reduce the computational
> 
>> load and storage requirement over an alway-updating FIR.
>>
>> -- 
>>
>> Tim Wescott
>> Wescott Design Services
>> http://www.wescottdesign.com
>>
>> Do you need to implement control loops in software?
>> "Applied Control Theory for Embedded Systems" gives you just what it
> says.
>> See details at http://www.wescottdesign.com/actfes/actfes.html
>>
> 
> Thanks for taking the time to reply Tim.  I used the 6800 device back in
> the 1970s. Your code was easy to follow. Would be nice to examine it in
> .txt or .asm text document format. As far as your apology for the
> "spaghetti code" style, I remember instructing my students on the two
> unforgivable sins of coding for others to view:
> 
> 1) Excesive Cryptic defines scattered over multiple source files that only
> have meaning to the original author.
> 2) Unnecessary & unstructured module crafting. (spaghetti code patially
> fits fits here?)
> 
> Time critical requirements can cancel out rule #2 within reasonable
> limits.

The part that is really unacceptable for production code is the bloated 
ISR and the non-existent main loop.  I mean, that ISR is _designed_ to 
interrupt itself.

In retrospect, the ISR should have just taken ADC samples and shoved 
them into a queue, then set a flag.  Then the main loop should have 
spent (nearly all) of it's time chewing through the queue.

But I had never seen that design pattern, so it just ran with that big 
bloated ISR...

>> You may also be able to reduce clock cycles by 'multiplying' by a 10kHz 
>> square wave -- whether you need to do this depends on the cost of a 
>> multiply in your AVR.  I know that the demodulator in my thesis radio 
>> worked on 400 baud data being sampled at 6800Hz or so, and it was with a
> 
>> processor (68HC11) that's more than 10 times less capable than an AVR 
>> running at full speed.
> 
> I'm running an AVR with 20mhz capability and HW MUL in the core. Not bad
> for a $2.00 part.  If I read your code correctly, you are using 8bits A/D?
> The SAR in the AVR can generally perform a convertion in ~13 clock cycles
> (~25 cycles for the first sample-read).
> 
> I noticed you used 15 samples per cycle scan. My signal has relatively low
> noise. Could I get away fewer samples with sacrificing end results? I ask
> this only out of curiosity. Far be it from me to question your design
> motives!

Oh, question away.  For one thing, I'm not perfect.  For another, that 
design is just about 20 years old by now.  While I was astonishingly 
capable for a Master's candidate (at least my thesis adviser claims to 
have been astonished that the radio worked) I was still a zit-faced kid 
doing his very first DSP project, and without a lot of formal DSP 
background.

That sample rate was 'designed' by trying the algorithm out, then 
throwing out functionality and reducing the sample rate until the thing 
actually ran in the time available.  Once my processor usage was below 
unity (98% is the number that I recall) I stopped trimming meat from the 
algorithm (the fat was long gone) and I thanked the DSP gods that I 
wasn't trimming bone.

To capture a good portion of the bandwidth of your signal you probably 
want to sample at 40kHz.  If you're not shaping the pulses BPSK has a 
very broad spread, so a somewhat bone-headed reading of theory would put 
your sampling rate much higher.  But you're already 'aliasing' it by 
riding it on a carrier that's only 2x the baud rate, so you probably 
won't lose too much at 40kHz (note that I'm not doing any math here, I 
could be completely cracked).  If your SNR is particularly good you 
could perhaps get away with something as low as 15kHz sampling, but I'd 
have to crank on the math to promise that you'd be able to synchronize 
to your signal at that low rate.

> The ADC can be programmed to perform an ISR after each convertion, but
> this timing is dependent on the ADC pre-scaler and probably no where near
> the input sample needs? I'll probably use your concept where the ADC is
> read during a scheduled TMOVF isr and start a new conversion within the
> scope of this module.

You'll get more consistent timing if you can trigger your ADC from 
hardware and interrupt on the end of conversion pulse.  If you have the 
freedom to set the ADC to an arbitrary rate this is the way to go.  Most 
of the modern chips that I have worked with let you trigger the ADC off 
of a timer, which in turn you can set to pretty much whatever you want.

Were I doing this, and if the timer hardware allowed it, I would 
consider driving the timer rate from my carrier recovery PLL, to 
synchronize the ADC samples to my carrier.  This _really_ simplifies the 
processing software, at the expense of making the overall application a 
bit more arcane.

> If anything I've assumed here is incorrect Tim, please let me know. I have
> no ego to bruise when someone with your talent is trying to help.
> 
> I'll give it a go. Thanks for the useful link and pointers Tim.
> B.R.
> Jack
> 


-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html