Re: 10khz DBSK decoder

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
.

Relevant Pages

  • Re: Security and EOL issues
    ... OS software resources are designed that reserved ram and disk space among other resources, to reflect what current hardware size is available. ... (There was a security patch a few years ago that could not be applied to NT4 as it required more resources then NT4 could provide. ... Installing air bags requires that the automobile manufacturer design, test, ... Computer Emergency Response Teams, and Digital Investigations. ...
    (Security-Basics)
  • Staff HW Engineer ~ Lead Us to ATCA & Beyond in Your End-to-End Board-Level HW Desig
    ... The senior level hardware engineer looking for the product realization ... and true ownership that comes with full end-to-end board-level hardware ... help us retain dominance in the design of high performance switching ...
    (comp.arch.embedded)
  • Re: For loop synthesis and repeated structures, any examples?
    ... I meant that the for loop IS an innefficient constuct ... in the sense that it would paralellise the hardware... ... has almost nothing to do with that design compromise. ... the multiplier, and capturing its output into the right ...
    (comp.lang.verilog)
  • Re: FPGA with 5V and PLCC package
    ... Their job will be to design software and not hardware systems. ... _graphical representation_ is the only appropriate way to do low level ... examples as gates. ...
    (comp.arch.fpga)
  • Re: Help for MCU/DSP selection
    ... I have a project where I need to upgrade an existing design. ... external communications. ... ATM leaning toward TI or STM32 with external ADC but ... rather out of date on embedded control devices so please bear with my ...
    (comp.arch.embedded)
Loading