Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

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.  Seems to trigger but I had to lower the threshold down to .390.

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.

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