MSK VLF spectrum

Hi All
i want to decode the MSK signals in VLF band using PC sound card.
i have got some information on VLF, MSK stations emitting at 17.2khz,
as MSK is a type of FSK with devation ratio=0.5 the problem is that
17.2khz is the only frequency mentioned. If it's F1 then F2 can be
calculated If it's carrier like FM signal then i have to demdulate first
then recover the f1 and f2 to get 1 or 0 can any one guide me on
recovering the information.

Regards
Masood

Masood wrote:

> Hi All
> i want to decode the MSK signals in VLF band using PC sound card.
> i have got some information on VLF, MSK stations emitting at 17.2khz,
> as MSK is a type of FSK with devation ratio=0.5 the problem is that
> 17.2khz is the only frequency mentioned. If it's F1 then F2 can be
> calculated If it's carrier like FM signal then i have to demdulate first
> then recover the f1 and f2 to get 1 or 0 can any one guide me on
> recovering the information.
> 
> Regards
> Masood

Intersepting the strategic communication to the submarines? Do you think 
it will help?

VLV

Hi VLV
i dont meant to Intercept the strategic communication.
I have no VLF transmitter of my own so to do some practical in dsp
programming i need to have some signal as strategic communication is
encrypted so i wont get the real information but 0's and 1's to verify
the msk/fsk detection algorithm, so it wont be any interception from me.
if you have any other vlf tx (non strategic) frequency information then
forward me   

Masood wrote:

> Hi VLV
> i dont meant to Intercept the strategic communication.
> I have no VLF transmitter of my own so to do some practical in dsp
> programming i need to have some signal as strategic communication is
> encrypted so i wont get the real information but 0's and 1's to verify
> the msk/fsk detection algorithm, so it wont be any interception from me.
> if you have any other vlf tx (non strategic) frequency information then
> forward me   
> 
> 
The US Coast Guard's differential GPS system data links are MSK.  Look 
for RTCM-104 for specifics (if you can find it -- I worked on this 
before there _was_ a spec, and just dug that name out of the Web). 
While GPS uses microwaves, the data links operate in the LF/MF region; 
you can build a pretty crappy radio and still have it's noise drowned 
out by atmospherics.

The nice thing, though, is that because it's a public standard, you can 
actually decode your bits down into real live packets, and make sure 
that they make sense, end-to-end.

There's even a book that tells the story of building one of these 
receivers.  It pretends to be my master's thesis, and there's a copy of 
it here: http://www.wescottdesign.com/articles/MSK/mskTop.html. 
According to my thesis adviser, mine was the second successful receiver 
design for this mode (he couldn't talk them into making more of the 
first, nor could he talk _me_ into making a copy).  It won't build into 
a complete data-link receiver, because the details of the FEC were still 
being worked out; at the time I did the work they weren't even sure what 
baud rate they wanted to use.

-- 

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

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

>Masood wrote:
>
>> Hi VLV
>> i dont meant to Intercept the strategic communication.
>> I have no VLF transmitter of my own so to do some practical in dsp
>> programming i need to have some signal as strategic communication is
>> encrypted so i wont get the real information but 0's and 1's to verify
>> the msk/fsk detection algorithm, so it wont be any interception from
me.
>> if you have any other vlf tx (non strategic) frequency information
then
>> forward me   
>> 
>> 
>The US Coast Guard's differential GPS system data links are MSK.  Look 
>for RTCM-104 for specifics (if you can find it -- I worked on this 
>before there _was_ a spec, and just dug that name out of the Web). 
>While GPS uses microwaves, the data links operate in the LF/MF region; 
>you can build a pretty crappy radio and still have it's noise drowned 
>out by atmospherics.
>
>The nice thing, though, is that because it's a public standard, you can 
>actually decode your bits down into real live packets, and make sure 
>that they make sense, end-to-end.
>
>There's even a book that tells the story of building one of these 
>receivers.  It pretends to be my master's thesis, and there's a copy of 
>it here: http://www.wescottdesign.com/articles/MSK/mskTop.html. 
>According to my thesis adviser, mine was the second successful receiver 
>design for this mode (he couldn't talk them into making more of the 
>first, nor could he talk _me_ into making a copy).  It won't build into 
>a complete data-link receiver, because the details of the FEC were still

>being worked out; at the time I did the work they weren't even sure what

>baud rate they wanted to use.
>
>-- 
>
>Tim Wescott
>Wescott Design Services
>http://www.wescottdesign.com
>
>Posting from Google?  See http://cfaj.freeshell.org/google/
>
>"Applied Control Theory for Embedded Systems" came out in April.
>See details at http://www.wescottdesign.com/actfes/actfes.html
>


Hello 
Mr. Tim Wescott
your thesis is excellent for MSK theory and detection, i already have 
studied it but i am stuck in the assembly code listing(it's 68hc11 based),
can you provide me with C source code for (software) msk receiver or in
8051 assembly, also in your receiver design carrier frequency was from 275
to 325 khz so does it mean that msk signal i.e(two tones f1 and f2) are
frequency or amplitude modulated on carrier.i have understanding of MSK
but unable to understand why can't we
send  f1 and f2 directly without embedding them on carrier as ususally f1
and f2 are in VLF rage, also i have found on web VLF MSK tx frequency
like
172 khz 18.2 khz so is it carrier frequency or one of f1 or f2

Regards
Masood Alam Abbasi

  wrote:

   ...

> Hello 
> Mr. Tim Wescott
> your thesis is excellent for MSK theory and detection, i already have 
> studied it but i am stuck in the assembly code listing(it's 68hc11 based),
> can you provide me with C source code for (software) msk receiver or in
> 8051 assembly, also in your receiver design carrier frequency was from 275
> to 325 khz so does it mean that msk signal i.e(two tones f1 and f2) are
> frequency or amplitude modulated on carrier.i have understanding of MSK
> but unable to understand why can't we
> send  f1 and f2 directly without embedding them on carrier as ususally f1
> and f2 are in VLF rage, also i have found on web VLF MSK tx frequency
> like 172 khz 18.2 khz so is it carrier frequency or one of f1 or f2

Masood,

I know that Tim can speak for himself, but you seem to be in a hurry for 
an answer.

Having just looked at some of the receiver code, I'm confident that it 
is not the output of a compiler, but was written directly in assembly. 
To understand the code, you will need to learn 69HC11 assembly code. It 
is about as simple as many other 8-bit machines, certainly easier than 
the 8051 if you are learning to code in it from scratch.

Signals are encoded onto carriers to provide separate channels for 
separate transmissions, and so that only one receiver needs to be built 
for each receiving station.

Jerry
-- 
        "The rights of the best of men are secured only as the
        rights of the vilest and most abhorrent are protected."
            - Chief Justice Charles Evans Hughes, 1927
���������������������������������������������������������������������

Masood wrote:
>>Masood wrote:
-- snip --
> 
> 
> Hello 
> Mr. Tim Wescott
> your thesis is excellent for MSK theory and detection, i already have 
> studied it but i am stuck in the assembly code listing(it's 68hc11 based),
> can you provide me with C source code for (software) msk receiver or in
> 8051 assembly,

I don't have anything like that, unfortunately.  As Jerry mentioned in 
another thread it was written directly in assembly code (and needed to 
be -- that's one busy processor at 400 baud).  You'll need to work 
forward from the block diagrams, and backward from the assembly code, to 
make the actual detector.

I wouldn't recommend using the exact algorithm that's embodied in that 
code: the processor was originally planned just to run the front panel. 
  It was severe overkill for that task, but my thesis adviser had an 
evaluation kit in his office, so that's what I used.  It was fortunate 
that we _did_ use that, because it proved capable of decoding MSK.

But it did so just barely.  The processor spends 98% of it's time in the 
decoding algorithm, which leaves an absurdly small 2% of headroom.  In 
order to get the algorithm to execute in the available time I had to do 
many serious hacks (such as taking the absolute value of the thing 
instead of squaring, and only multiplying by -1, +1 and 0).  I wouldn't 
use such a small processor for such a big job again, unless the planned 
product had a very large production run over which to amortize the 
engineering expense.

> also in your receiver design carrier frequency was from 275
> to 325 khz so does it mean that msk signal i.e(two tones f1 and f2) are
> frequency or amplitude modulated on carrier.

That's not the case.  "Carrier" in this case simply means the center 
frequency between the two tones, e.g. at 400 baud with a 300kHz carrier 
you would have tones at 300.1kHz and 299.9kHz.

> i have understanding of MSK
> but unable to understand why can't we
> send  f1 and f2 directly without embedding them on carrier as ususally f1
> and f2 are in VLF rage, also i have found on web VLF MSK tx frequency
> like
> 172 khz 18.2 khz so is it carrier frequency or one of f1 or f2
> 
I suspect that those services use 'carrier' in the same sense that I 
have: it's the center frequency between the two tones, not an actual 
carrier in the sense of AM or FM modulation.

This terminology survives because (a) it is traditional, (b) it makes 
sense if you think about it (the signal spectrum is concentrated around 
the carrier frequency), and (c) even in this day and age one nearly 
always uses _some_ form of superheterodyne receiver for decoding, even 
if it's just to use an absurdly high IF feeding into A/D converters 
after down conversion from a _really_ absurdly high RF.

In your case you could probably just do some prefiltering and go 
straight into a high-speed ADC, but that's for you to decide.

-- 

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

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:

   ...

> I wouldn't recommend using the exact algorithm that's embodied in that 
> code: the processor was originally planned just to run the front panel. 
>  It was severe overkill for that task, but my thesis adviser had an 
> evaluation kit in his office, so that's what I used.  It was fortunate 
> that we _did_ use that, because it proved capable of decoding MSK.
> 
> But it did so just barely.  The processor spends 98% of it's time in the 
> decoding algorithm, which leaves an absurdly small 2% of headroom.  In 
> order to get the algorithm to execute in the available time I had to do 
> many serious hacks (such as taking the absolute value of the thing 
> instead of squaring, and only multiplying by -1, +1 and 0).  I wouldn't 
> use such a small processor for such a big job again, unless the planned 
> product had a very large production run over which to amortize the 
> engineering expense.

Modern versions and extensions run faster. Both the 68HC12 will run 
'HC11 code nearly intact, has many new instructions with which to 
optimize the code, and uses a faster clock. The 68HC16 is faster yet, 
but not quite as code compatible, IIRC.

Tim: what clock speed did you run your '11 at?

Jerry
-- 
        "The rights of the best of men are secured only as the
        rights of the vilest and most abhorrent are protected."
            - Chief Justice Charles Evans Hughes, 1927
���������������������������������������������������������������������

Jerry Avins wrote:

> Tim Wescott wrote:
> 
>   ...
> 
>> I wouldn't recommend using the exact algorithm that's embodied in that 
>> code: the processor was originally planned just to run the front 
>> panel.  It was severe overkill for that task, but my thesis adviser 
>> had an evaluation kit in his office, so that's what I used.  It was 
>> fortunate that we _did_ use that, because it proved capable of 
>> decoding MSK.
>>
>> But it did so just barely.  The processor spends 98% of it's time in 
>> the decoding algorithm, which leaves an absurdly small 2% of 
>> headroom.  In order to get the algorithm to execute in the available 
>> time I had to do many serious hacks (such as taking the absolute value 
>> of the thing instead of squaring, and only multiplying by -1, +1 and 
>> 0).  I wouldn't use such a small processor for such a big job again, 
>> unless the planned product had a very large production run over which 
>> to amortize the engineering expense.
> 
> 
> Modern versions and extensions run faster. Both the 68HC12 will run 
> 'HC11 code nearly intact, has many new instructions with which to 
> optimize the code, and uses a faster clock. The 68HC16 is faster yet, 
> but not quite as code compatible, IIRC.
> 
> Tim: what clock speed did you run your '11 at?
> 
Modern processors are amazing.  I am working on a classroom 
demonstration that levitates a Christmas bell beneath an electromagnet. 
  It samples at 1kHz, runs a PID controller with some moderately 
sophisticated bells and whistles, and only uses about 25% of the 
available processing power.  This is all on a TI MSP430 that's being 
clocked at 8MHz.

That 'HC11 was running an 8MHz clock, too, but with a built-in 
divide-by-four that gave it an absolute upper limit of 1/2 MIPS, with 
more like 1/4 or 1/8 MIPS if you took all the multi-cycle instructions 
into account.  Were I given a more modern variant you'd see code that 
was closer to theory, for understandability if nothing else.

-- 

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

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:

   ...

> Modern processors are amazing.  I am working on a classroom 
> demonstration that levitates a Christmas bell beneath an electromagnet. 
>  It samples at 1kHz, runs a PID controller with some moderately 
> sophisticated bells and whistles, and only uses about 25% of the 
> available processing power.  This is all on a TI MSP430 that's being 
> clocked at 8MHz.
> 
> That 'HC11 was running an 8MHz clock, too, but with a built-in 
> divide-by-four that gave it an absolute upper limit of 1/2 MIPS, with 
> more like 1/4 or 1/8 MIPS if you took all the multi-cycle instructions 
> into account.  Were I given a more modern variant you'd see code that 
> was closer to theory, for understandability if nothing else.

Tim.

I have an 'HC12 board from NewMicros Inc. sSomewhere around -- I think I 
lent it to a friend who isn't using it. You can play with it if you 
like. http://www.newmicros.com/ There's an interesting summary of 
improvements at 
http://www.seattlerobotics.org/encoder/oct97/68hc12.html. The 68HC16 is 
a 16-bit machine.

Jerry
-- 
        "The rights of the best of men are secured only as the
        rights of the vilest and most abhorrent are protected."
            - Chief Justice Charles Evans Hughes, 1927
���������������������������������������������������������������������