[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

From: Tom Golden
Subject: Re: [Discuss-gnuradio] Ettus N210 GMSK 9600
Date: Sat, 26 Mar 2016 10:12:18 -0600

I've been staring at the de-modulator and I really think it's correct.  Unfortunately amateur packet radio isn't well documented (at least for me).

I think there's a scambler I'm not taking into account.  Does anyone know the specifics of this?  Or can point me to how to what the parameters of the descrambler block mean and/or how to determine their settings (my best guess is it's a 17-bit LFSR with a polynomial of 1+x^12+x^17)?

On Sat, Mar 26, 2016 at 8:31 AM, Tom Golden <address@hidden> wrote:
Thanks Andy.  I changed the hdlc_flag_nrzi to:


The frame byte is 0x7E and 0x84 (LSB first) is the first address byte.  I'm not sure if you used 7 ones instead of 6 on purpose.

On Fri, Mar 25, 2016 at 4:25 PM, Andy Walls <address@hidden> wrote:
On Fri, 2016-03-25 at 11:07 -0600, Tom Golden wrote:

> AX.25 data is NRZI encoded (so inverse bits and then NRZ).  I hand
> calculated the HDLC frame start byte and first few address bytes so
> the corr_est only triggers at the start of the packet.

I've added NRZI decoding and encoding and adjusted the correlation
pattern for the HDLC flag in the attached.

>   Seems to trigger but I had to lower the threshold down to .390.

Something seems wrong.  Look at how a build the preamble samples in my
flowgraph.  Since I use the GMSK Modulator to build the preamble
samples, it has a bit of a delay, and I have to discard the first 1.5
symbols or so of samples.  (GMSK with L=4).

Also note, that unlike PSK, which will correlate to both the normal and
inverted preamble (since it's just a 180 phase shift), for FSK the
corr_est block will only correlate to the version of the preamble you
specify, and not the inverted one (different frequencies don't

> I have a separate program I'm using to check for the bit pattern I'm
> sending (0xA5, 0xA5, ...).  It checks against raw, nrz, and nrzi to
> see if the pattern is present.  It's present in 2 bytes and the data
> after those 2 bytes is wrong but consistent - which I think points to
> a timing issue.
> I think the fact that I had to reduce the threshold down to 0.390
> points to the same issue as the bits not coming out correctly.

I'm not sure.  I added the HDLC deframer in the flowgraph to decode the
packet bytes for you.  It won't spit out anything though, if the CRC
check fails.  You may want to hack the block to output data even when
the CRC fails; just to see if things look sane.

The HDLC deframer was originally used for AIS, but it will generically
deframe any HDLC (hopefully!).


> On Fri, Mar 25, 2016 at 10:51 AM, Andy Walls
> <address@hidden> wrote:
>         On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
>         > On Fri, 2016-03-25 at 12:00 -0400,
>         address@hidden
>         > wrote:
>         > FWIW, I couldn't get the attached flowgraph (which looks to
>         correlate to
>         > the HDLC flag) to crash.  I was probably just lucky.
>         I forgot to mention, in the flowgraphs I winged up:
>         a) I might have the sense of 0 and 1 symbols reversed.  Right
>         now I have
>         0 symbols as the low frequency and 1 symbols as the high
>         frequency, but
>         that guess could be wrong.  (The convention for AFSK systems
>         is usually
>         the reverse of what I have, for example.)
>         b) I'm assuming the data bits are not differentially encoded
>         or NRZI
>         encoded.  That could be wrong.  AIS uses NRZI, for example.
>         -Regards,
>         Andy

reply via email to

[Prev in Thread] Current Thread [Next in Thread]