Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-22 Thread Marcus D. Leech via USRP-users
On 04/22/2019 11:37 AM, Rob Kossler wrote: Marcus & Ettus folks, I just experienced a similar issue using gnuradio with the example rfnoc_fosphor program (the issue being that the frequency I request is not what I get). This seems to me to be a pretty significant bug. While playing with

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-22 Thread Rob Kossler via USRP-users
Marcus & Ettus folks, I just experienced a similar issue using gnuradio with the example rfnoc_fosphor program (the issue being that the frequency I request is not what I get). This seems to me to be a pretty significant bug. While playing with rfnoc_fosphor, I fiddled with the Cordic Freq param

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-19 Thread Marcus D. Leech via USRP-users
On 04/19/2019 02:37 PM, Rob Kossler wrote: Not sure about uhd_fft. I know that with rx_samples_to_file, it behaved fine until I added the timed commands. That's why I sent the source code attachment so that the problem could be easily duplicated. Rob Doh! Sorry. I got distracted by the

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-19 Thread Rob Kossler via USRP-users
Not sure about uhd_fft. I know that with rx_samples_to_file, it behaved fine until I added the timed commands. That's why I sent the source code attachment so that the problem could be easily duplicated. Rob On Fri, Apr 19, 2019 at 1:15 PM Marcus D. Leech wrote: > On 04/19/2019 09:44 AM, Rob

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-19 Thread Marcus D. Leech via USRP-users
On 04/19/2019 09:44 AM, Rob Kossler wrote: I had started with a mid-January version of master and that's where I noticed the issue. I am using: UHD_3.14.0.HEAD-0-gf6cacec8 With an X310, using a UBX-160 V1 I'm running with the default clock rate, and getting 25Msps, using a 10MHz lo offset.

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-19 Thread Rob Kossler via USRP-users
I had started with a mid-January version of master and that's where I noticed the issue. On Thu, Apr 18, 2019 at 6:00 PM Marcus D. Leech wrote: > On 04/18/2019 05:09 PM, Rob Kossler wrote: > > OK, so what happens if you use a *positive* LO offset? >> > > It moves in the opposite direction. A

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-18 Thread Marcus D. Leech via USRP-users
On 04/18/2019 05:09 PM, Rob Kossler wrote: OK, so what happens if you use a *positive* LO offset? It moves in the opposite direction. A few remarks: * I should mention that the behavior I'm seeing with rx_samples_to_file is not identical to the behavior I'm seeing in my own

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-18 Thread Rob Kossler via USRP-users
> OK, so what happens if you use a *positive* LO offset? > It moves in the opposite direction. A few remarks: - I should mention that the behavior I'm seeing with rx_samples_to_file is not identical to the behavior I'm seeing in my own custom app. In my app, I see unpredictable

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-18 Thread Marcus D. Leech via USRP-users
On 04/18/2019 04:02 PM, Rob Kossler wrote: Ok. I couldn't seem to duplicate with the stock "rx_samples_to_file", but with the following minor mods, I see some of the bad behavior. This sure looks like a UHD bug to me. I simply added timed commands around the set_rx_freq() function (see

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-18 Thread Rob Kossler via USRP-users
Ok. I couldn't seem to duplicate with the stock "rx_samples_to_file", but with the following minor mods, I see some of the bad behavior. This sure looks like a UHD bug to me. I simply added timed commands around the set_rx_freq() function (see snippet below as well as attached source code). Is

Re: [USRP-users] x310/ubx multi_usrp->set_rx_freq() issues

2019-04-18 Thread Rob Kossler via USRP-users
I do see in the documentation that the tune result "target_rf_freq" will match the tune request "rf_freq", which it does in my example below. So, I suppose the output shown is as expected for my request. Unfortunately, this doesn't solve my problem of the actual spectrum being wrong. I may have