Re: TCP/QT FREQ SINK Problems

To my knowledge to get the same output you would have to divide the fft output with fft size. Meelis T, 26. november 2019 17:38 rear1019 kirjutas: > On Wed, 20 Nov 2019 at 07:39:04 -0500, Antoine Nguyen wrote: > > […] > > Is there a setting I am missing or a step that I have not included > > th

Re: [Discuss-gnuradio] rx_time tag after drop

t 7:32 PM, Martin Braun wrote: > On 12/05/2016 04:24 AM, Meelis Nõmm wrote: > > Now to what Martin told > > > > > 3. I would expect that the offset is incremented by the number of > > > dropped samples. So that the combination of t_0 and offset still >

Re: [Discuss-gnuradio] rx_time tag after drop

ed to the GnuRadio stream or 2. sample number related to the USRP stream? In case of 1. offset knows nothing of dropped samples and in case of 2. it takes them into account. Things are starting to clear up Meelis On Sat, Dec 3, 2016 at 2:05 AM, Martin Braun wrote: > On 12/02/2016 05:08 AM

Re: [Discuss-gnuradio] rx_time tag after drop

correct. > > What version of UHD are you running? What USRP are you connected to? Are > you setting or changing the sample rate after starting the flowgraph? Would > you be able to try using the latest UHD maint code? > https://github.com/EttusResearch/uhd/tree/maint > > Thanks,

[Discuss-gnuradio] rx_time tag after drop

Hello everyone We have been wondering about rx_time tags after drop. In [1] it is stated that "Then, if a dropped packet or overflow are detected, it sends a new rx_time tag." The tag debugger output is shown below. Initially we thought that in the tag the time and the offset are bound together.

Re: [Discuss-gnuradio] Timed USRP source commands and tags

Thank you for the prompt reply. Meelis On Wed, Nov 23, 2016 at 6:35 PM, Marcus Müller wrote: > Dear Meelis, > > On 23.11.2016 16:28, Meelis Nõmm wrote: > > Hello > > We are building a frequency scanner. As suggested in many posts, like in > [1], one should use timed c

[Discuss-gnuradio] Timed USRP source commands and tags

Hello We are building a frequency scanner. As suggested in many posts, like in [1], one should use timed command messages. Now my questions are: 1. Do I understand it correctly that the gnuradio USRP Source block does not add a tag when the center frequency changes? 2. If that is correct then we

Re: [Discuss-gnuradio] Syncronization issues, using a GPSDO

@Nick No this effect I see after the GPSDO already has a lock and is running (is powered) for more than 30min. @Andy Interesting. I agree, I also plan to use the hack, but would really like to try to find the root cause. Also, maybe I stumbled on something useful that the Ettus guys can use to imp

[Discuss-gnuradio] Questions about USRP source retune via messages

Hello everyone, I have been testing USRP (N200) source retuning via messages. The idea was to see how fast the USRP can retune reliably. Also looked at the usrp_spectrum_sense but as Marcus pointed out in [1] that example

Re: [Discuss-gnuradio] Enabling GR_LOG messages

Thank you Tom for the reply. The problem came from pybombs. Seems that in the pybombs version I had, the recipe for gnuradio had -DENABLE_GR_LOG=Off. So a clean build with the ...GR_LOG=On fixed it. Plus in the latest pybombs version the recipe has been updated and most of the var config_opt's have

[Discuss-gnuradio] Enabling GR_LOG messages

Hello everyone, I'm writing a (test python) block for usrp_source frequency retune. Marcus gave a pretty good base line for the solution in [1] . I figured I can use the message passing to solve this, by using the "time" an