Hello, What is the minimum number of samples to drop to flush uhd buffers when changing frequencies? TIA Nikos

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 <nbalkanas@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-leave@lists.ettus.com >

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.braun@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 <nbalkanas@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-leave@lists.ettus.com >> >

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 <nbalkanas@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.braun@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 <nbalkanas@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-leave@lists.ettus.com >>> >>

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 <nbalkanas@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 <nbalkanas@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.braun@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 <nbalkanas@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-leave@lists.ettus.com >>>> >>>

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 <nbalkanas@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 <nbalkanas@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 <nbalkanas@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.braun@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 <nbalkanas@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-leave@lists.ettus.com >>>>> >>>>