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
