10khz DBSK decoder

Hi,

Incedible forum! I could really use some ideas for solving my last
development problem (I pray it's a simple task?). I don't want to get too
detailed and drawn out, but IMHO, it helps to be concise if any help is to
be expected?

The data transmitter is a DBPSK with a carrier of 10khz. The bit rate is
5kbs.  The signal sent through a 21,000ft, high-temperature (500 deg f)
wire-line cable. Wire line mechanical collector is of exceptional quality
and exhibits excellent low brush noise characteristics.  My received signal
is surprisingly clean with an average ~90mv p-p level. I believe my signal
conditioner design is ok (well, it looks good on the scope). The output is
a nice 0-5v TTL level waveform.

I'm using an AVR to try and "make sense"/decode the packet. From several
discussions in other posts, it seems the simplest approach is to use some
I/Q method to extract the 1s and 0s? Being a fairly strong AVR coder, the
code should not present a problem?  On the other hand, being the worlds
least informed DSP person is why I'm here!

Ant ideas on a simple (or at least not-too-complicated) algorithm would be
a life saver.

OAN, I've already paid one of the "experts" that frequents this forum
several $$$ to do this with a PC sound card. His code worked perfect! The
down-side was that it took two PCs. One to continuously collect the data,
send it to the serial port, and the other PC to run the data intensive
application (Realtime graphics display of 16 sensor values).  Note: most
developers would not attempt to use C# for such demanding processes. As
most coders know, C# can present some ugly cross-threading issues when GDI
is intense. Increasing the WaveIn buffers to a crazy number did not solve
the problem. Thus, The AVR (and most of all, YOU) is/are my last hope.
Well, I hope I've been clear enough? Thanks in advance for any help.

Kind Regards,
Jack

ijt wrote:

> Hi,
> 
> Incedible forum! I could really use some ideas for solving my last
> development problem (I pray it's a simple task?). I don't want to get too
> detailed and drawn out, but IMHO, it helps to be concise if any help is to
> be expected?
> 
> The data transmitter is a DBPSK with a carrier of 10khz. The bit rate is
> 5kbs.  The signal sent through a 21,000ft, high-temperature (500 deg f)
> wire-line cable. Wire line mechanical collector is of exceptional quality
> and exhibits excellent low brush noise characteristics.  My received signal
> is surprisingly clean with an average ~90mv p-p level. I believe my signal
> conditioner design is ok (well, it looks good on the scope). The output is
> a nice 0-5v TTL level waveform.
> 
> I'm using an AVR to try and "make sense"/decode the packet. From several
> discussions in other posts, it seems the simplest approach is to use some
> I/Q method to extract the 1s and 0s? Being a fairly strong AVR coder, the
> code should not present a problem?  On the other hand, being the worlds
> least informed DSP person is why I'm here!
> 
> Ant ideas on a simple (or at least not-too-complicated) algorithm would be
> a life saver.
> 
> OAN, I've already paid one of the "experts" that frequents this forum
> several $$$ to do this with a PC sound card. His code worked perfect! The
> down-side was that it took two PCs. One to continuously collect the data,
> send it to the serial port, and the other PC to run the data intensive
> application (Realtime graphics display of 16 sensor values).  Note: most
> developers would not attempt to use C# for such demanding processes. As
> most coders know, C# can present some ugly cross-threading issues when GDI
> is intense. Increasing the WaveIn buffers to a crazy number did not solve
> the problem. Thus, The AVR (and most of all, YOU) is/are my last hope.
> Well, I hope I've been clear enough? Thanks in advance for any help.
> 
> Kind Regards,
> Jack

And this is what Jack send to me:

> Vladimir,
> Here is your code back. You have cost me more than the $1500 USD I paid you in
> good faith. Several months wasted. I signed up as a dsprelated.com user, but
> have not posted anything yet. What really ticks me off is all the posts where
> you say "you do not have a clue" and "pay me to make it work". Sir, "you did not
> have a clue" about the C# threading characteristics that I told you I would be
> using.  Sure, the code works perfect when it is used stand-alone, but has such a
> high data loss when used in the application you convinced me it should work in.
> My thoughts are this: What good is having a program that sends data, and
> receives it message back. We probably should recommend you for a Nobel prize in
> the rip-off area.
> 
> Anyway, here is your code back, sell it again if you like. Learn some ethics. I
> promptly paid you without testing. This won't happen again. Also, stop being
> such a tormentor on the blogs, as people go there to ask. If you only want
> money, go somewhere else.
> Jack

I am sorry for the long quoting; however I think it is required so 
everybody can understand what is the deal.

I am so sorry that Jack couldn't include a perfectly working piece of 
C++ code into his C# program. I even provided a sample application to 
make that simple.

The only logical conclusion is that the real problem is not in C#, and 
not in my code, and it can hardly be resolved by AVRs, PICs or whatever 
other technical means. Mr Jack, please think about it before throwing 
unfair reproaches.

Many other people love software or hardware that I develop, and I 
constantly have more work then I can handle. Unfortunately, any 
consultant sometimes has to deal with the issues like above mentioned. 
So I don't lay it to my heart although there is some annoyance about the 
wasted effort sold at dumping price.


WBR,

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Vladimir Vassilevsky wrote:
> 
> 
> ijt wrote:
> 
>> Hi,
>>
>> Incedible forum! I could really use some ideas for solving my last
>> development problem (I pray it's a simple task?). I don't want to get too
>> detailed and drawn out, but IMHO, it helps to be concise if any help 
>> is to
>> be expected?
>>
>> The data transmitter is a DBPSK with a carrier of 10khz. The bit rate is
>> 5kbs.  The signal sent through a 21,000ft, high-temperature (500 deg f)
>> wire-line cable. Wire line mechanical collector is of exceptional quality
>> and exhibits excellent low brush noise characteristics.  My received 
>> signal
>> is surprisingly clean with an average ~90mv p-p level. I believe my 
>> signal
>> conditioner design is ok (well, it looks good on the scope). The 
>> output is
>> a nice 0-5v TTL level waveform.
>>
>> I'm using an AVR to try and "make sense"/decode the packet. From several
>> discussions in other posts, it seems the simplest approach is to use some
>> I/Q method to extract the 1s and 0s? Being a fairly strong AVR coder, the
>> code should not present a problem?  On the other hand, being the worlds
>> least informed DSP person is why I'm here!
>>
>> Ant ideas on a simple (or at least not-too-complicated) algorithm 
>> would be
>> a life saver.
>>
>> OAN, I've already paid one of the "experts" that frequents this forum
>> several $$$ to do this with a PC sound card. His code worked perfect! The
>> down-side was that it took two PCs. One to continuously collect the data,
>> send it to the serial port, and the other PC to run the data intensive
>> application (Realtime graphics display of 16 sensor values).  Note: most
>> developers would not attempt to use C# for such demanding processes. As
>> most coders know, C# can present some ugly cross-threading issues when 
>> GDI
>> is intense. Increasing the WaveIn buffers to a crazy number did not solve
>> the problem. Thus, The AVR (and most of all, YOU) is/are my last hope.
>> Well, I hope I've been clear enough? Thanks in advance for any help.
>>
>> Kind Regards,
>> Jack
> 
> And this is what Jack send to me:
> 
>> Vladimir,
>> Here is your code back. You have cost me more than the $1500 USD I 
>> paid you in
>> good faith. Several months wasted. I signed up as a dsprelated.com 
>> user, but
>> have not posted anything yet. What really ticks me off is all the 
>> posts where
>> you say "you do not have a clue" and "pay me to make it work". Sir, 
>> "you did not
>> have a clue" about the C# threading characteristics that I told you I 
>> would be
>> using.  Sure, the code works perfect when it is used stand-alone, but 
>> has such a
>> high data loss when used in the application you convinced me it should 
>> work in.
>> My thoughts are this: What good is having a program that sends data, and
>> receives it message back. We probably should recommend you for a Nobel 
>> prize in
>> the rip-off area.
>>
>> Anyway, here is your code back, sell it again if you like. Learn some 
>> ethics. I
>> promptly paid you without testing. This won't happen again. Also, stop 
>> being
>> such a tormentor on the blogs, as people go there to ask. If you only 
>> want
>> money, go somewhere else.
>> Jack
> 
> I am sorry for the long quoting; however I think it is required so 
> everybody can understand what is the deal.
> 
> I am so sorry that Jack couldn't include a perfectly working piece of 
> C++ code into his C# program. I even provided a sample application to 
> make that simple.
> 
> The only logical conclusion is that the real problem is not in C#, and 
> not in my code, and it can hardly be resolved by AVRs, PICs or whatever 
> other technical means. Mr Jack, please think about it before throwing 
> unfair reproaches.
> 
> Many other people love software or hardware that I develop, and I 
> constantly have more work then I can handle. Unfortunately, any 
> consultant sometimes has to deal with the issues like above mentioned. 
> So I don't lay it to my heart although there is some annoyance about the 
> wasted effort sold at dumping price.

Are you sure the problem isn't in C#? I thought C# used a garbage 
collector. Those things are the the death of anything approaching real 
time. Even adding lots of buffers won't work, when the code to fill the 
buffers is jammed. However, running the DSP as one task and streaming 
the results through a pipe to a C# program would eliminate that problem 
without adding significant overheads.

One rather negative comment about your working practices, though - it 
sounds like you work too cheaply. :-)

Regards,
Steve

My sincere apologies to this forum. I did not want to start any flames.
Personally speaking, I find it most distasteful to air laundry in public.
My dissatisfaction with the product was between me and the other guy. It
would be most un-professional to have dragged his/her "name" into the
subject. I saw no harm in stating my reasons for posting here, and why I
needed help, but this is where I found the author. I've made a mistake.
With the highest respect to other DSP gurus here, can any one direct me to
another forum that has expertise in this subject matter? I do not and will
not be part of any personal wars.

Sincere respect to this forum,
Jack

You are quite correct Steve. One can partialy manage the _gc, but only
force it to a point. AFAIK, we never know when the _gc is going to pick up
the garbage. ( no pun intended to big cities <Grin> ) As far as the $$$,
the code was sent to me in a couple of days. Most of the functions he used
are on WaveIO are posted on the web. Not many lines of code at all.

Steve,
Can you answer a quick question for me please? Can 10khz DBPSK be decoded
without FIR functionality?
Thanks,
Jack

ijt wrote:
> You are quite correct Steve. One can partialy manage the _gc, but only
> force it to a point. AFAIK, we never know when the _gc is going to pick up
> the garbage. ( no pun intended to big cities <Grin> ) As far as the $$$,
> the code was sent to me in a couple of days. Most of the functions he used
> are on WaveIO are posted on the web. Not many lines of code at all.
> 
> Steve,
> Can you answer a quick question for me please? Can 10khz DBPSK be decoded
> without FIR functionality?
> Thanks,
> Jack

You would normally have at least one filter in such a decoder, and it 
would normally be an FIR, for phase performance reasons. What else you 
have the decoder is open ended. There are multiple ways to approach the 
problem.

Steve

Steve Underwood wrote:


> Are you sure the problem isn't in C#? 

I guess I know what the problem is. In the example provided, the wave 
API was polled in for(;;) loop rather then processed by messages for the 
sake of avoiding the irrelevant clutter. He just copied the whole thing 
without any insight.

> I thought C# used a garbage 
> collector.

It is always possible to screw the things up, however I wouldn't expect 
any more difficulty in C# compared to the conventional interfacing to 
the Windows waveform IO in C.

> Those things are the the death of anything approaching real 
> time.

C# as well as Java were meant for the multimedia applications. They 
provide for the data streaming.

> Even adding lots of buffers won't work, when the code to fill the 
> buffers is jammed.

The "hot" side of the queues of the buffers is processed at the core level.

> However, running the DSP as one task and streaming 
> the results through a pipe to a C# program would eliminate that problem 
> without adding significant overheads.

This looks like an overcomplication; the conventional waveform I/O 
approach from MSDN should do.

> One rather negative comment about your working practices, though - it 
> sounds like you work too cheaply. :-)

I promise to work on that :-)


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

ijt wrote:
> My sincere apologies to this forum. I did not want to start any flames.
> Personally speaking, I find it most distasteful to air laundry in public.
> My dissatisfaction with the product was between me and the other guy. It
> would be most un-professional to have dragged his/her "name" into the
> subject. I saw no harm in stating my reasons for posting here, and why I
> needed help, but this is where I found the author. I've made a mistake.
> With the highest respect to other DSP gurus here, can any one direct me to
> another forum that has expertise in this subject matter? I do not and will
> not be part of any personal wars.
> 
> Sincere respect to this forum,
> Jack
> 
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.

-- 

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

ijt wrote:
> Hi,
> 
> Incedible forum! I could really use some ideas for solving my last
> development problem (I pray it's a simple task?). I don't want to get too
> detailed and drawn out, but IMHO, it helps to be concise if any help is to
> be expected?
> 
> The data transmitter is a DBPSK with a carrier of 10khz. The bit rate is
> 5kbs.  The signal sent through a 21,000ft, high-temperature (500 deg f)
> wire-line cable. Wire line mechanical collector is of exceptional quality
> and exhibits excellent low brush noise characteristics.  My received signal
> is surprisingly clean with an average ~90mv p-p level. I believe my signal
> conditioner design is ok (well, it looks good on the scope). The output is
> a nice 0-5v TTL level waveform.
> 
> I'm using an AVR to try and "make sense"/decode the packet. From several
> discussions in other posts, it seems the simplest approach is to use some
> I/Q method to extract the 1s and 0s? Being a fairly strong AVR coder, the
> code should not present a problem?  On the other hand, being the worlds
> least informed DSP person is why I'm here!
> 
> Ant ideas on a simple (or at least not-too-complicated) algorithm would be
> a life saver.
> 
(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.

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.

-- 

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

>ijt wrote:
>> My sincere apologies to this forum. I did not want to start any
flames.
>> Personally speaking, I find it most distasteful to air laundry in
public.
>> My dissatisfaction with the product was between me and the other guy.
It
>> would be most un-professional to have dragged his/her "name" into the
>> subject. I saw no harm in stating my reasons for posting here, and why
I
>> needed help, but this is where I found the author. I've made a
mistake.
>> With the highest respect to other DSP gurus here, can any one direct me
to
>> another forum that has expertise in this subject matter? I do not and
will
>> not be part of any personal wars.
>> 
>> Sincere respect to this forum,
>> Jack
>> 
>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?

>-- 

R.
Jack