My bad. I was starting the streamer with .stream_now = true before setting the frequency:( Streamer started immediately gathering garbage in its buffers:( Sorry about the confusion:( Issue fixed:)
BR Nikos On Fri, Jul 11, 2025 at 5:23 AM Nikos Balkanas <nbalka...@gmail.com> wrote: > Further investigation showed that in my system: X310, Ubuntu 24.04, uhd > 4.6.0 > Minimum drop to get a proper spectrum is 1450 dropped samples:( > > On Thu, Jul 10, 2025 at 7:34 PM Nikos Balkanas <nbalka...@gmail.com> > wrote: > >> Forgot to mention that this must be a uhd issue. >> Immediately after uhd_rx_streamer_recv >> I use fprintf to print the sample to a file. >> These spectra are from this file:( >> >> Nikos >> >> On Thu, Jul 10, 2025 at 2:37 PM Nikos Balkanas <nbalka...@gmail.com> >> wrote: >> >>> Thank you Martin, >>> >>> For your fast reply. I am already using the sensor lo_locked to prevent >>> center frequency LO leakage. >>> I am using an X-310 with Ubuntu 24.01 over a 10 GBe line. >>> Still getting signal corruption when switching frequencies. This is >>> something else. >>> It is gone when using an offset in my input buffers to drop the first >>> initial samples. >>> This shouldn't happen since I am using exact buffers with the streamer >>> in mode UHD_STREAM_MODE_NUM_SAMPS_AND_DONE >>> Check out these spectra: >>> >>> 945.2_2 is the normal 945.2 Mhz spectrum 62.500 samples. >>> 945.2_2_16: is the same spectrum 16.384 samples with lo_locked sensor, >>> no offset. >>> 945.2_2_16x: is the same spectrum 16.384 samples with lo_locked sensor >>> and offset. >>> >>> What is going on? >>> >>> TΙΑ >>> Nikos >>> >>> >>> On Thu, Jul 10, 2025 at 1:08 PM Martin Braun <martin.br...@ettus.com> >>> wrote: >>> >>>> Nikos, >>>> >>>> there is no one answer for this, it depends on hardware used, which >>>> specific frequencies, how your signal is flowing... >>>> Another important thing is: are you using timed commands or not. If you >>>> are using timed commands (and the device supports timed-tuning), then you >>>> can wait exactly for the sample that should be the first sample after the >>>> tune request is processed, then wait a given, deterministic time depending >>>> on your hardware and frequencies (old and new). If your device does not >>>> support timed-tuning, or you're not using timed commands, then you must >>>> wait several milliseconds after submitting a tune request. >>>> >>>> If you are doing timed tunes, then I believe none of the hardware has >>>> an LO lock time that is worse than 100µs (many are better). >>>> >>>> --M >>>> >>>> On Thu, Jul 10, 2025 at 4:25 AM Nikos Balkanas <nbalka...@gmail.com> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> What is the minimum number of samples to drop to flush uhd buffers >>>>> when changing frequencies? >>>>> >>>>> TIA >>>>> Nikos >>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>> >>>>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
