Re: [Discuss-gnuradio] Help using simple_framer and simple_correlator

[Eric Blossom]

On Thu, Nov 17, 2005 at 04:16:55PM -0500, address@hidden wrote:
> I am also in the process of studying this part of the software to see if I
> can use it to recreate my data from the demodulated signal.

Let me start by saying that you'd be *much* better off studying the
packet framing / deframing and clock recovery code that is used in the
new gmsk2.py and gmsk2_pkt.py files in 
gnuradio-core/src/python/gnuradio/blksimpl
and the corresponding examples in gnuradio-examples/python/gmsk2

The new code is much cleaner and faster, and since it tracks symbol
timing, works for long packets.

As Bob pointed out, the so called GMSK receiver will receive pretty
much any kind of FSK data.

> Can anyone provide information on what are sync field, seq number and
> command field that are added to the payload?

The sync code is a 64-bit pattern that is used to establish bit and
frame alignment.  gr_simple_correlator contains a state machine that
looks for the sync code in the 8x oversampled input stream, and when
it finds it, it knows that it has found the beginning of a packet.
[In reality, it's a bit more complicated than this, since the input
data is 8x oversampled, and it's looking for the best symbol-alignment
at the same time.]

> I need to recreate this in my transmitter which is not usrp/gnuradio
> based.  It's just a simple micro controller.  So far I have not been
> able to understand what the gr_simple_framer does.

Don't use it.  Look at the new code.

> Does the framer convert digital data stream to self-synchronizing code?

The framer adds the sync pattern to the beginning so that the receiver
can establish frame and bit synchronization.  You need some way to
figure out how your data is aligned.  We used one technique; there are
others...

> My transmitter clock rate is not a multiple of 64 MS/s and therefore so is
> my data rate.  Will this cause difficulty?  I am using very low data rate
> and with short retransmission time.

Not with the new code ;)  

With the new code you specify the nominal samples/baud (spb), which
needn't be an integer, and it recovers the clock, resamples the
incoming data so that we're sampling in the middle of a bit, and then
passes the properly timed data off to the packet sink.  The packet
sink correlates for the sync pattern in a similar fashion to
gr_simple_correlator, but is simpler, since it's not dealing with
oversampled data.  The clock recovery code take a parameter that
specifies the maximum relative frequency error that it will track out.
The default value is 200 parts per million (ppm), which should be
plenty loose for anything with a xtal oscillator in it.

Trust me, you really want to be studying the new code...

Eric