Everything Rob is saying is dead on - the "sense of time" for the radio is a 64-bit counter within the radio core that other blocks (like the DDC and DUC) don't have access to. Those blocks need to derive a sense of time from the timestamps of CHDR packets passing through them. I just wrapped up a new app note that covers this (among other synchronization-related topics):
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Clocking_and_Timekeeping_in_the_USRP Lukas, I would doubt that this is an undiscovered bug as much as it is an issue with implementation. If this were in C++, you'd want to set the 'has_time_spec' and 'time_spec' fields of your TX metadata for at least 1 packet to impart a sense of time on the DUC: https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html I just spoke with someone on my end who said you need to use stream tags to do this, but again, I don't currently have much direction for how that would be implemented in your code. Sam Reiter On Tue, Mar 3, 2020 at 11:48 AM Rob Kossler <rkoss...@nd.edu> wrote: > 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
