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 <a...@silverblocksystems.net>
wrote:

> On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
> > On Fri, 2016-03-25 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> > 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
>
>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to