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 <tgolden...@gmail.com> wrote: > 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
