Thanks Andy. I changed the hdlc_flag_nrzi to: [0]+[1]*6+[0]+[0,0,1,0,0,0,0,1]
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 <a...@silverblocksystems.net> 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 > correlate). > > > > > > 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!). > > -Regards, > Andy > > > > > 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
