Also, note that there is no corresponding issue on receive because the Rx radio always inserts the time stamp in the sample stream. So, I guess you would not see this with the DDC. Rob
On Tue, Mar 3, 2020 at 12:43 PM Rob Kossler <rkoss...@nd.edu> wrote: > 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
