Hi Lukas, The FPGA image on the USRP is divided into blocks such as the DUC block and the Radio block. The latter controls the RF daughterboard and has access to the device clock. So, when you provide a timed command to the Radio block (such as for tuning the RF) it can implement the command at the specified time by comparing to the device clock. The DUC block does not have access to the MB clock and so when you give it a timed command, it monitors the incoming sample stream to extract the time. If the sample stream does not include a time stamp, the command never executes. Don't think of this as a bug, but rather as a design limitation.
When I work directly with UHD from C++, I use the function rx_streamer::issue_stream_command() which has options to stream data with no time stamp or with a time stamp. When using timed commands with DUC or DDC, I must include the time stamp or else the command will never be executed. But, with GR, I don't know how to specify the corresponding options. Rob On Tue, Mar 3, 2020 at 12:29 PM Lukas Haase <lukasha...@gmx.at> wrote: > Hi Sam, Hi Rob, > > Thanks for following up on this! > I am very happy you were able to reproduce this ... which means that at > least an issue exists :) > > What Sam suggests makes sense even though hard to believe for me: > > 1. How could something like that go unnoticed for so long? (I am sure I am > not the first performing digital tuning) > 2. In the past I got successful phase coherence using automatic tuning > (passing center frequency + offset to tune_request_t and using integer-N > tuning) using timed commands. This did not work reliably and only for > certain frequencies but in my opinion this should have INCLUDED the DUC > tuning. If the DUC retune wouldn't have been executed as part of this > automatic tuning, I could not have gotten phase coherence (and actually, > not even the desired frequency). > > The reason why I am only doing DUC tuning now is to avoid all the hassle > with integer-N tuning, PLL retuning and settling time. > > Sam, what is the "radio block" you were talking about? > > Anyway, would it be worthwile to attempt debugging this is absence of gr? > The only reason this prevented me from doing is that I would need to > manually create the baseband samples and continuously stream them out while > in parallel do the retuning. > I am not too familiar with UHD on its own but I assume this would be very > complicated, require multithreading etc. > Do you have any demo code that could be easily modified for this scenario? > > Best, > Lukas > > > Gesendet: Dienstag, 03. März 2020 um 12:08 Uhr > Von: "Sam Reiter" <sam.rei...@ettus.com> > An: "Rob Kossler" <rkoss...@nd.edu> > Cc: "Lukas Haase" <lukasha...@gmx.at>, "USRP-users@lists.ettus.com" < > usrp-users@lists.ettus.com> > Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using > a timed command > > For what it's worth, I was able to reproduce the behavior described here, > but didn't get to dig into it much. My leading suspicion would be what Rob > mentioned about timestamping. Lukas' code sets a command time, but I'm not > clear on how timestamp metadata for packets being sent to the radio are > handled. Might be a good question to loop the discuss-gnuradio mailing list > in on? > > > > Sam Reiter > > On Tue, Mar 3, 2020 at 10:59 AM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote: > I wonder if the issue is related to a missing time stamp on the baseband > samples going from GR to UHD. If the stream does not have a time stamp, > the DUC is unable to apply the timed command because the DUC does not > really know the time - it must pull the time from the streaming samples. > This is in contrast to the radio block which does have access to time and > can apply timed commands by referring to the motherboard clock. > > I am not too familiar with GR so I'm not sure how to know if GR is putting > a time stamp on the streaming samples. > Rob > > On Mon, Mar 2, 2020 at 10:04 AM Lukas Haase via USRP-users < > usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote:Hi > Marcus, > > Thank you that would be amazing! > > I followed the tutorial and built everything from source: > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 18.04.4 LTS > Release: 18.04 > Codename: bionic > $ uname -a > Linux sdr 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC > 2020 x86_64 x86_64 x86_64 GNU/Linux > $ cd uhd > $ git status > HEAD detached at v3.15.0.0 > $ cd ../gnuradio > $ git status > HEAD detached at v3.7.14.0 > > > Thank you! > > Lukas > > > > PS: For some reason I sometimes do not get responses from this list. I > just saw it looking at the mailman archives. Hence I cannot respond (to > keep headers intact) but need to create a new message and manually "quote". > I hope that still preserves the context somehow. > > > > Marcus Leech wrote: > > On 02/28/2020 01:01 PM, Lukas Haase via USRP-users wrote: > >> Hi again, > >> > >> I created a minimum example (gnuradio) that shows the issue described > below. > >> To summarize: Retuning to a different dsp frequency on an USRP X310 > (+UBX160) does not work (command ignored) ONLY if a timed command (in > future is used). > >> The code shows it in a simple manner. Commenting out the single line > with set_command_time makes the example work. > >> > >> I am absolutely out of ideas and would appreciate any input! > >> > >> Best, > >> Lukas > > Lukas. > > > > Thanks for sticking with this. I'll have a discussion with Ettus R&D to > > see if this is a known issue and/or if there's a workaround. > > > > Remind me which version of UHD you're using? > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com] > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________ > USRP-users > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users> > mailing list > USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
