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 of the DDC a bit. Then, I set this parameter back to zero and ran multiple consecutive runs without changing any params. My setup had a center freq of 2450MHz, DDC rate of 100 MHz, and I had a 2450MHz antenna connected directly to the X310/UBX160 input (dboard B, Tx/Rx). I was simply monitoring all the energy in the ISM band 2400-2480 MHz (this band has lots of energy in my environment, but outside this span it is pretty quiet). I ran 7 iterations (consecutive runs) without changing params and I expected to see energy from 2400-2480. In each run, I saw the energy, but the frequency shown often did not represent reality. Note: the "????" below denotes that the location was off-display (presumably 80 MHz from the other endpoint). - run 1: energy located (2475-???? MHz) - run 2: energy located (2400-2480 MHz) (as expected) - run 3: energy located (2435-???? MHz) - run 4: energy completely off-display (> 2500 MHz) - run 5: energy located (2400-2480 MHz) (as expected) - run 6: energy located (????-2467 MHz) - run 7: energy located (2400-2480 MHz) (as expected) I captured screenshots of each and would be glad to provide them to anyone interested. I also have the gnuradio rfnoc_foshphor python script if anyone is interested. I recognize that it is not easy to duplicate the above results because it requires an FPGA image with specific blocks that support fosphor. However, I want to mention that all of the blocks in the experiment above are non-modified "stock" blocks. The C++ program I attached to the original post provides a way to duplicate this issue with the standard FPGA image. Rob On Fri, Apr 19, 2019 at 2:45 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > 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 (clearly-worrying) "tuned frequency > appears bad when using offset tuning", without also considering the > timed-command aspect. > > > > On Fri, Apr 19, 2019 at 1:15 PM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> 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. I'm using uhd_fft to observe the spectrum at 950MHz. >> It's exactly where >> one would expect it to be, similarly at 2450MHz. >> >> >> >> >> >> On Thu, Apr 18, 2019 at 6:00 PM Marcus D. Leech <patchvonbr...@gmail.com> >> 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 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 behavior. Nevertheless, I >>> figured we could start with rx_samples_to_file which seems to be >>> consistent >>> (albeit wrong). >>> - Although I haven't tried rx_samples_to_file with other devices or >>> with Tx channels, I did see bad behavior with Tx channels and with the >>> N310 >>> device using my custom app >>> - I have no idea if this behavior is recent or not because I haven't >>> been looking at this kind of thing for a long time >>> - I am using the latest off master: UHD_3.15.0.git-89-gf93c5227 >>> >>> >>> Rob >>> >>> I will try to reproduce this in my lab in the morrow. In the mean-time, >>> if you revert to earlier UHD, do you see the same thing? >>> >>> >>> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
