N210 has a master clock of 100 MHz. Sample rates are drived by dividing that with an integer. It is preferrable to use dividers that are even (even better, divisible by 4) due to how the anti-aliasing filters in N210 digital down-converters are implemented. You get the flattest frequency response with sample rates (25 MHz / n).
For more info see Ian Buckleys answer in USRP-users mailing list: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-February/018573.html All the best Laur 2016-03-26 21:09 GMT+02:00 tom x <tomx4...@gmail.com>: > 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.000000 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 <bloe...@ccs-labs.org> > wrote: > >> Hi, >> >> On 22 Mar 2016, at 21:58, tom x <tomx4...@gmail.com> 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 <bloe...@ccs-labs.org> >> wrote: >> >>> Hi, >>> >>> On 19 Mar 2016, at 12:08, tom x <tomx4...@gmail.com> 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 transmission. Can you give some >>> insight on how you picked the other MM Clock Recovery params? Is there any >>> other dependence in the PHY block? The papers and guides I looked at >>> explain what the MM params are but don't give much intuition for choosing >>> them. >>> >>> >>> I didn’t set them and am not an expert, but I think there is no >>> justification for this particular parameter set, i.e., there is no easy >>> formula for calculating ideal parameters. I guess someone started with an >>> educated guess and made simulations to find parameters that worked >>> reasonably well. >>> >>> Anyhow, I don’t think that the parameters of the MM block are the >>> problem (once you adapted omega of course). As far as I see >>> - the gain parameters are independent from the sample rate as the >>> error/feedback is calculated once per symbol >>> - mu is the initial phase and doesn’t matter >>> - omega relative limit could be cut in half (when using 8MHz). IIRC, >>> it’s the maximum frequency deviation normalised with the sample rate. >>> >>> >>> What you could try is to adapt alpha of the single pole IIR, to get the >>> same averaging with the increased sample rate. >>> >>> >>> Additionally, based on posts in this thread: >>> https://lists.gnu.org/archive/html/discuss-gnuradio/2015-07/msg00585.html >>> , >>> I thought it would be better to replace the MM CR block with a >>> polyphase clock sync block, as "M&M block isn't great in fading >>> environments", and I would like to receive possibly weak signals, >>> >>> >>> 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. >>> >>> >>> >>> Again, works for 4 MHz sample rate and 2 samples per symbol, but not 8 >>> MHz rate and 4 samples per signal. What do you think? >>> >>> >>> 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, for >>> example). >>> >>> Best, >>> Bastian >>> >> >> >> -- >> Dipl.-Inform. Bastian Bloessl >> Distributed Embedded Systems Group >> University of Paderborn, Germany >> http://www.ccs-labs.org/~bloessl/ >> >> > > _______________________________________________ > 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
