Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset
Hi, For those interested, these problems were partially solved by selecting a sample rate for the USRP more carefully. When setting the USRP N210 to sample at 8 MHz, I was getting a message like this: UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 8.00 MSps Actual sample rate: 7.692308 MSps To my detriment I assumed the 'Actual sample rate' would be OK, because even though it was not a nice number, it was a higher one. It breaks everything though. If anyone can quickly comment on why this happens, or how to get a list of my hardware's 'supported RX sample rates', it would be appreciated. Otherwise I can post to the USRP list. After some guessing, I found this warning disappears when I pick 10 MHz instead of 8 MHz. Additionally, the 802.15.4 PHY block can decode packets at this rate, and my 2 channel receiver works with the increased rate as well. Concerning Bastian's transceiver block: I ran a short experiment to compare the performance of the MM Clock Recovery block with the Polyphase clock sync block, but it turns out the MM block had a lower packet error rate. Details here: https://github.com/tomx4096/rf_experiments/blob/master/802phyblock/README Thanks for reading, Tom On Thu, Mar 24, 2016 at 6:12 PM, Bastian Bloessl wrote: > Hi, > > On 22 Mar 2016, at 21:58, tom x wrote: > > >What you could try is to adapt alpha of the single pole IIR, to get the > same averaging with the increased sample rate. > > I tried a variety of values without success but was not really sure what I > was doing. Can you expand on what you meant by > "get the same averaging with the increased sample rate", and how to check > this? I thought about the equation for the > single pole filter being subtracted from the original signal (that is, > x[n]-y[n], where y[n] = a*x[n] + (1-a)*y[n-1]), but I didn't > see the relationship between this and the sample rate. > > > Following your notation you would have to decrease ‘a'. Think of a moving > average, implemented with a FIR filter, which averages over a certain time > window. If you double the sample rate, you have to double the length of the > filter to average over the same time window. > > Another thing you could try is multiplying the output of the subtract > block by 2, when switching to 8MHz. This way, the input of the MM block > would have the same amplitude (and amplitude matters). > > Apart from that I don’t see any obvious problems. Unfortunately, I’m not > in the office to test your 8MHz flow graph :-/ > > > > Here is a picture of the RX chain (which works for 4M but not 8, even with > the omega adjustment) > > http://i.imgur.com/Kezk9Fq.jpg?1 > > I can put a scope after the USRP source and see some nice bursts; but I'm > having trouble inspecting the signal after this > block in the chain..what is a good way to visualize what's happening after > the quadrature demodulation? > > > After the subtract block you should have a signal that is centered around > 0 and the chip sequences should be clearly visible. (The problem is that > the trigger doesn’t work for the phase.) > > > > >When this transceiver was implemented, the polyphase clock sync block was > not available yet. You are right, it should improve performance. > > If you switch to that block and see performance improvements, it would > be great if you made a pull request. > > I made a pull request to parameterize the sample rate in the PHY block, so > it wouldn't be hard coded in. If we can figure out these issues > I'd be happy to do some tests to compare the two and then make another > pull request. > > > Thanks for the pull request. I just replied on github. In brief, I would > prefer to keep the transceiver as simple as possible to provide an easy to > use base that can be easily adapted to ones needs. > I think there are many aspects/paramters that can be studied, but I’m > afraid it would make the code much more complicated if we introduce options > for all of them. > > (Replacing the MM Clock Recovery with something more robust would, of > course, still be a good idea in my opinion.) > > Best, > Bastian > > > > >I think there is no reason why that shouldn’t work. It would be helpful > if you could upload your flow graph, maybe there is > > a mistake somewhere (the picture you posted did not show the USRP and > xlating filters > > here is my 2 channel receiver, showing the USRP and filters > > http://i.imgur.com/dZpIqUw.png?1 > > (the variable chan_width is 2M). > Can you see some other issue? Maybe getting this working depends on > increasing the samp_rate, which goes back to the first problem. > > Thanksagain, > Tom > > On Mon, Mar 21, 2016 at 3:42 AM, Bastian Bloessl > wrote: > >> Hi, >> >> On 19 Mar 2016, at 12:08, tom x wrote: >> >> I tried doubling both, the sample rate to 8MHz and Omega to 4, but still >> no progress. The setup is simply the 802.15.4 PHY block connected to a USRP >> source, listening for an over the air transmiss
Re: [Discuss-gnuradio] Ettus N210 GMSK 9600
Thanks. I'm climbing the learning curve. :) The radio I'm testing isn't AFSK, it's GMSK/FSK 9600. So I think it may be scrambled. I'm sending packets that are 255 bytes contains 0xA5 - and I have a ruby program that checks starting at every bit for A5, the inverse of A5, NRZ decode for A5, and NRZI decode for A5. Regardless of the corr_est, the MSK Timing Recovery does seem to recovery the timing and bits for most of the packet which should yield some strings of A5 is the bits. But I'm just not seeing that. I did see some references on the web about scrambling for FSK9600 - so that's the rabbit hole I went down. On Sat, Mar 26, 2016 at 11:20 AM, Tom McDermott wrote: > HI Tom - AX.25 is NRZI coded. What that means is that the > encoder toggles the state of a flip flop when the input data is zero > (i.e. a JK flip flop). The output of that flipflop is the NRZI encoded > data stream. > > AX.25 FM Radio AFSK audio is not scrambled. > Some 9600 baud FSK (not audio) links may be scrambled. > > To un-do the NRZI coding, send the NRZI data into one input of an > exclusive-or gate and the D input of a D flip flop at the same time. > The Q-bar output of the flipflop is exclusive-or'ed with the NRZI data > (XOR the D-in and Q-bar output of the FF). > > -- Tom, N5EG > > > > On Sat, Mar 26, 2016 at 9:13 AM, Tom Golden wrote: > >> Thanks - I'll give it a try. >> >> >> On Sat, Mar 26, 2016 at 10:09 AM, Andy Walls > > wrote: >> >>> Hi Tom, >>> >>> The corr_est block needs to match against the NRZI encoded symbols, so >>> yes I used 7 ones for the hdlc flag. >>> >>> The HDLC flag has two possible NRZI encodings depending on the initial >>> state: >>> >>> 0110 - HDLC flag byte >>> 1 0001 - NRZI encoded HDLC flag byte, initial state 1 >>> >>> 0110 - HDLC flag byte >>> 0 1110 - NRZI encoded HDLC flag byte, initial state 0 >>> >>> >>> So encoding your two byte sequence: >>> >>> 0110 0011 >>> 1 0001 01101011 >>> or >>> 0 1110 10010100 >>> >>> You should build your corr_est preamble samples based on one of these. >>> >>> Regards, >>> Andy >>> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus N210 GMSK 9600
Thanks - I'll give it a try. On Sat, Mar 26, 2016 at 10:09 AM, Andy Walls wrote: > Hi Tom, > > The corr_est block needs to match against the NRZI encoded symbols, so yes > I used 7 ones for the hdlc flag. > > The HDLC flag has two possible NRZI encodings depending on the initial > state: > > 0110 - HDLC flag byte > 1 0001 - NRZI encoded HDLC flag byte, initial state 1 > > 0110 - HDLC flag byte > 0 1110 - NRZI encoded HDLC flag byte, initial state 0 > > > So encoding your two byte sequence: > > 0110 0011 > 1 0001 01101011 > or > 0 1110 10010100 > > You should build your corr_est preamble samples based on one of these. > > Regards, > Andy > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus N210 GMSK 9600
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 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 > 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 >> > 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
Re: [Discuss-gnuradio] Ettus N210 GMSK 9600
Hi Tom, The corr_est block needs to match against the NRZI encoded symbols, so yes I used 7 ones for the hdlc flag. The HDLC flag has two possible NRZI encodings depending on the initial state: 0110 - HDLC flag byte 1 0001 - NRZI encoded HDLC flag byte, initial state 1 0110 - HDLC flag byte 0 1110 - NRZI encoded HDLC flag byte, initial state 0 So encoding your two byte sequence: 0110 0011 1 0001 01101011 or 0 1110 10010100 You should build your corr_est preamble samples based on one of these. Regards, Andy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft seg fault
On 03/26/2016 06:13 AM, Daniel R. Marlow wrote: On Mar 24, 2016, at 8:29 AM, Marcus D. Leech wrote: Hi Marcus, Thanks. That was very helpful. If there was an instruction to run the setup_env.sh script I missed it.I was flying a bit blind there, because the link to the PyBOMBS web page from the GNUradio TWiki---i.e., URL: http://gnuradio.org/pybombsfrom URL: http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource leads to a non-existent page. When I ran the setup_env.sh script, things started to work. That's a good thing!I am concerned, however, that I have a mixed installation. What is my best move? "rm"-ing all of the PyBOMBS stuff or just leaving well enough alone (I realize that this question may not have a "closed form" answer, but advice would appreciated nonetheless). Best regards, Dan Pybombs default behavior is to install everything under your own user directory, so that no sudo privileges are required, and setup_env.sh sets various environment variables to make this "work". The Gnu Radio website has undergone some changes lately, and Pybombs itself has been radically upgraded as well--so there are some dangling documentation pointers. The best thing to do since you have a "mixed" installation, and an apparently-working Pybombs-based install is to use your package tools to remove the installed-from-binary-packages stuff: sudo apt-get purge gnuradio gnuradio* sudo apt-get purge uhd uhd* libuhd* marlow@sdr3:~/21cm$ uhd_fft -1420M Segmentation fault (core dumped) marlow@sdr3:~/21cm$ gnuradio-companion Segmentation fault (core dumped) marlow@sdr3:~/21cm$ python top_block_ex.py Segmentation fault (core dumped) marlow@sdr3:~/21cm$ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus N210 GMSK 9600
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 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 > > 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
[Discuss-gnuradio] Generating a few NRZI bytes (Re: Ettus N210 GMSK 9600)
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 Hi Tom, The attached flowgraph might save you the hassle of working out the NRZI bit encoding by hand, for a few bytes anyway. I structured the input vector's tail to have a single 0 in it to alternate the starting state (0 or 1) of the NRZI encoding, so you get both possible NRZI encodings displayed for the bit sequence. The start of the vector is marked with the "sov" tag. Obviously this could be done in Octave or MatLab or Python or whatever as well. -Andy nrzi_test.grc Description: XML document ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft seg fault
On Mar 24, 2016, at 8:29 AM, Marcus D. Leech wrote: > On 03/24/2016 07:34 AM, Daniel R. Marlow wrote: >> >> >> Thanks Marcus. >> >> I did a "sudo ldconfig" but to no avail. >> >> I am wondering if the problem is destructive interference between the >> apt-get install of the binaries >> and my attempt to install using PyBOMBS? If so, is there anything I should >> do to get rid of the PyBOMBS >> other than an "rm" of the installation directories? >> >> --Dan > That is almost certainly the case. > > What installation prefix did you have PyBombs use?I think it will have > instructed you to use an env.sh, or setupenv.sh, which will > contain settings of LD_LIBRARY_PATH, PYTHONPATH, etc. If you simply log > out, and log back in, and don't run that setup script, > you may be OK, without having to uninstall the PyBombs-installed stuff. > > But I'll point out that GR+friends installed from packages are going to be > out-of-date, sometimes, spectacularly. > > Hi Marcus, Thanks. That was very helpful. If there was an instruction to run the setup_env.sh script I missed it.I was flying a bit blind there, because the link to the PyBOMBS web page from the GNUradio TWiki---i.e., URL: http://gnuradio.org/pybombsfrom URL: http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource leads to a non-existent page. When I ran the setup_env.sh script, things started to work. That's a good thing!I am concerned, however, that I have a mixed installation. What is my best move? "rm"-ing all of the PyBOMBS stuff or just leaving well enough alone (I realize that this question may not have a "closed form" answer, but advice would appreciated nonetheless). Best regards, Dan marlow@sdr3:~/21cm$ uhd_fft -1420M Segmentation fault (core dumped) marlow@sdr3:~/21cm$ gnuradio-companion Segmentation fault (core dumped) marlow@sdr3:~/21cm$ python top_block_ex.py Segmentation fault (core dumped) marlow@sdr3:~/21cm$ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listin >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
