Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

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

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

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

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

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

Hi, Thanks for your response, >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

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

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 transmission. Can you give some

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

What's your sampling rate? The further you go towards the edge of your Nyquist zone, the more the anti-aliasing filter might be kicking in. Cheers, Martin On 03/17/2016 10:23 AM, tom x wrote: > Hi, > > My setup is a USRP N210 receiving from a transmitter sending a few > packets a second. (The

[Discuss-gnuradio] diminishing returns with increasing frequency offset

Hi, My setup is a USRP N210 receiving from a transmitter sending a few packets a second. (The packets are decoded with Bloessl's 802.15.4 PHY block if it matters) Let's say the transmitter is sending data on frequency f_t. I set the USRP to receive on f_t plus an offset f_o. The next block is a

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

Hi, This previous post by me should give more info: https://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00286.html I've replaced the polyphase channelizer with one Frequency Xlating FIR filter for each channel. The first problem (described above) is that centering the filter too far

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

Hi, Bastian, 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

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

It's strange but the only sampling rate that works is 4 MHz; Packets are not decoded when the sampling rate is set above this rate. Thanks, Tom On Thu, Mar 17, 2016 at 7:33 PM, Martin Braun wrote: > What's your sampling rate? The further you go towards the edge of your

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

Tom, you'll need to tell us more about what you're doing and what you've tried. Cheers, Martin On 03/17/2016 03:36 PM, tom x wrote: > It's strange but the only sampling rate that works is 4 MHz; Packets are > not decoded when the sampling rate is set above this rate. > > Thanks, > Tom > > On

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

Hi, > On 18 Mar 2016, at 20:01, tom x wrote: > > > Maybe there is an implicit dependence on 4MHz, in the parameters set by the > Clock Recovery block? I am not sure. > If there's any other relevant info I can give, let me know. The omega parameter of the MM Clock