Lukas,
Can you confirm the exact git hash for both UHD and the FPGA image you are
using? Perhaps the easiest way is to run uhd_usrp_probe.
Rob
On Fri, Mar 13, 2020 at 1:00 AM Lukas Haase <lukasha...@gmx.at> wrote:
> Dear Marcus, Dear Rob,
>
> Thank you very much for these tips with "Unknown PPS", stream 2 streams
> and the explanation of set_start_time. That makes sense.
>
> Since then I spent hours and hours every day on TX+RX but STILL no
> synchronized phase for dspfreq!
> Timed commands seem to work.
> Also, in general, synchronization.
> With this code, I get my long desired cohrent phase between TX+RX but ONLY
> if I do not touch dsp tuning (and only use the PLL in integer-N mode):
>
> tune_req_rx = uhd.tune_request()
> tune_req_rx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
> tune_req_rx.dsp_freq_policy = uhd.tune_request.POLICY_NONE #
> IMPORTANT!
> tune_req_rx.rf_freq = rf_freq
> tune_req_tx.dsp_freq = -dsp_freq
> tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer",
> "int_n_step=1000e3",]))
>
> tune_req_tx = uhd.tune_request()
> tune_req_tx.rf_freq_policy = uhd.tune_request.POLICY_MANUAL
> tune_req_tx.dsp_freq_policy = uhd.tune_request.POLICY_NONE #
> IMPORTANT!
> tune_req_tx.rf_freq = rf_freq
> tune_req_tx.dsp_freq = dsp_freq
> tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer",
> "int_n_step=1000e3",]))
>
> now = usrp_sink.get_time_now()
> when = now + uhd.time_spec(1.0)
> print("Clicked to switch R-T-X frf=" + str(rf_freq) + ", fdsp=" +
> str(dsp_freq) + " at " + str(now.get_full_secs()) + ":" +
> str(now.get_frac_secs()) + " for " + str(when.get_full_secs()) + ":" +
> str(when.get_frac_secs()))
>
> usrp_sink.set_command_time(when)
> usrp_source.set_command_time(when)
> res2 = usrp_sink.set_center_freq(tune_req_tx) # "TX/RX" of
> first UBX160 is transmitter
> res1 = usrp_source.set_center_freq(tune_req_rx, 1) # "RX2" of
> second UBX160 is receiver
> usrp_sink.clear_command_time()
> usrp_source.clear_command_time()
>
> With phase coherence I mean if I read out the received phase and I switch
> between f1 and f2, I always get the same phase for f1 and f2, respectively.
>
> But if I set dsp_freq_policy to MANUAL (or I add an LO offset which also
> required dsp retuning) I just don't get any coherent phase.
>
> I used the tricks you mentioned:
>
> - I use unknown PPS in both which makes USRP time start at zero (tested)
> - Both "USRP Source" and "USRP Sink" have 2 channels (and one of each
> connects to Null Source/Sink). This should ensure that stream start time is
> set! (tested)
> - Even if not, I also used explicitely
> tb.uhd_usrp_source_0.set_start_time(uhd.time_spec(10))
> tb.uhd_usrp_sink_0.set_start_time(uhd.time_spec(10))
> at the beginning of my flow graph. I see no signal until 10s, as expected
> - I experimented with "tx_time" and stream tags but for some reason many
> timed I get flooded with L's
>
>
> Can it be that there is another bug lurking somewhere deep in the USRP
> firmware?
>
> Thanks,
> Lukas
>
>
>
> Gesendet: Mittwoch, 04. März 2020 um 19:27 Uhr
> Von: "Marcus D Leech" <patchvonbr...@gmail.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
>
> When you select one of the PPS synch options in a GRC USRP block it will
> set the time to zero.
>
> Easy enough to modify the code to do something more sophisticated, but
> knowing that it will be set to zero helps you know how to proceed.
>
>
> Sent from my iPhone
> On Mar 4, 2020, at 12:43 PM, Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>
>
> Regarding #2)
> I don't think that what you want is a "command" tag, but rather a "time
> stamp tag" which I believe is "tx_time" based on the link you provided to
> the documentation. The documentation says, "The timestamp tag value is a
> PMT tuple of the following: (uint64 seconds, double fractional seconds)".
> If I am correct, perhaps the code snipped you provided will not come into
> play.
>
> Just to be clear, I don't think you should need to do both #1 and #2.
> But, I "believe" that either method should be possible to accomplish the
> goal of attaching a time stamp to the streaming.
>
> Also, keep in mind that the time stamp that you provide to the DUC block
> for the freq change is related to the time stamp you attach to the
> streaming samples. Let me explain with a few remarks:
>
> If you apply the time stamp of 0.5 to the streaming samples, then the
> first sample will have time 0.5 and then UHD will keep track of all
> subsequent samples to know the absolute time of any given sample. I am
> assuming that once you start transmitting you will keep transmitting
> continuously until the flow graph ends.If you then start hopping your DUC
> with time stamps such as 0.6, 0.7, 0.8, etc, then UHD should apply the hop
> at the correct part of the stream since it knows the time of each
> sample.But, be sure that you know for certain that the UHD time is truly
> set to zero at the start of the run. Otherwise, if it is at some arbitrary
> value at startup such as 9876.1 seconds, and you are using time stamps to
> set your DUC tuning such as "get_time_now()+0.5", then it will want to
> apply the tuning at 9876.6 seconds. Thus, if you time stamped your tx
> stream at 0.5 seconds, you will have a long time to wait before the tuning
> occurs.
> Rob
>
> On Wed, Mar 4, 2020 at 12:13 PM Rob Kossler <rkoss...@nd.edu[mailto:
> rkoss...@nd.edu]> wrote:
>
> Hi Lukas,
> Let me respond to #1 right away. The "set_start_time" function sets the
> time of the tx stream. It does not set the "clock time" on the usrp. If
> you are indeed correct that the "clock time" on the usrp is initialized to
> 0.0 at the start of the GR run, then you are lucky and all you should need
> to do is use the "set_start_time" function with a time spec of something
> like 0.2 or 0.5 (any time after 0.0 with perhaps a little delay built in).
> To see if it is working, you could set the time spec to something very
> large like 5.0 or 10.0 and then you should see the GR run start up but no
> Tx for the next 5 or 10 seconds. Then the Tx should start. Does that make
> sense?
> Rob
>
>
> On Wed, Mar 4, 2020 at 12:06 PM Lukas Haase <lukasha...@gmx.at[mailto:
> lukasha...@gmx.at]> wrote:Hi Rob,
>
> 1.) I do not really understand how "set_start_time" is related to my
> problem and why this is what I need. Based on my experiments, the time is
> automatically set to 0 when the flow diagram starts.
>
> I am also sure others must have used timed TX+RX but it does not seem so.
> No kidding, I am working on this since Dec and I still do not have it
> working. I left my traces various times on this and the gnuradio mailing
> list but I did not get help.
>
> 2.) I have played around using stream tags and was very happy that it
> worked but I found now that this is because gr-uhd does NOT attach a
> command time although the documentation says so.
>
>
> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html[https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html]
> :
> tx_command tag. The command is attached to a sample, and will executed
> before the sample is transmitted, and after the previous sample.
>
> However, in the code (usrp_sink_impl.cc:433, usrp_sink_impl::tag_work):
>
> else if (pmt::equal(key, COMMAND_KEY)) {
> if (my_tag_count != samp0_count) {
> max_count = my_tag_count;
> break;
> }
> // TODO set the command time from the sample time
> msg_handler_command(value);
> }
>
> 3.) So I am really back to the start. What is generally a bit annoying is
> that I have two objects for the same device (*one* USRP and "USRP
> Source"+"USRP Sink", both with their independent uhd::usrp::multi_usrp
> objects. My question is, is it possible to just use "USRP Source" (this is
> where timed commands work) to execute the retuning for *both* RX+TX?
>
> 3.a.) Given: X310 with 2xUBX-160. What is the subdev spec if I wanted to
> receive on all FOUR inputs??
> The problem is that both RX and TX frontends have the same name "0"
> (according to uhd_usrp_probe).
>
> Two receivers, receiving both from "TX/RX" input of each UBX-160 would be
> trivial: "A:0 B:0". However, how do I address "RX2"? Intuitively "A:0 A:1
> B:0 B:1" but as said, both "TX/RX" and "RX2" are named "0".
> What would I do if I wanted to transmit from "TX/RX" of the second UBX and
> receive on all other boards?
>
> On the USRP Sink: "B:0"
> On the USP Source intuitively: "A:0 A:1 B:1" but that's wrong.
>
> 3.b.) In gr, there will be two multi_usrp objects: One for the receiver
> (member variable of USRP Source) and one for the transmitter (member
> variable of USRP Sink).
> Can I set up a USRP Source that has two channels where the second one is
> actually a TX channel? (only used for retuning via timed commands)?
>
>
> Thanks,
> Lukas
>
>
>
>
>
> Gesendet: Dienstag, 03. März 2020 um 15:22 Uhr
> Von: "Rob Kossler" <rkoss...@nd.edu[mailto:rkoss...@nd.edu]>
> An: "Lukas Haase" <lukasha...@gmx.at[mailto:lukasha...@gmx.at]>
> Cc: "Sam Reiter" <sam.rei...@ettus.com[mailto:sam.rei...@ettus.com]>, "
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com]"; <
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]>
> Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using
> a timed command
>
> I did a quick google search using "gnuradio uhd timed tx streaming". I
> found that the GR usrp_sink[
> https://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html[https://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html]]
> has the function "set_start_time" which seems to be what you need. The
> question is: what time do you set? Probably just something like
> "get_time_now() + 0.1". It may be a bit tricky since this value is to be
> set before starting the flow graph. Maybe you could set it to some fixed
> constant like 0.5 and then when the flow graph starts you could execute a
> command to set_time_now() to 0.0. Anyway, if this advice doesn't pan out,
> perhaps just search around a bit in GR archives. I'm sure others have
> successfully streamed with timed Tx commands.
> Rob
>
> On Tue, Mar 3, 2020 at 3:00 PM Lukas Haase <lukasha...@gmx.at[mailto:
> lukasha...@gmx.at][mailto:lukasha...@gmx.at[mailto:lukasha...@gmx.at]]>
> wrote:
>
> Hi Sam, Hi Rob,
>
> This makes so much sense!
> I think you are right.
> And indeed, the issue I found only with TX, not RX.
>
>
> Could you think of a possible hack sending a "dummy command" to the RF
> board along with the timed tuning request?
>
>
> Regarding the sending of time stamps in the TX in gr-uhd, I am confused
> though. I do think this IS happening. I reproduce the work function of
> "USRP Sink" here:
>
> int usrp_sink_impl::work(int noutput_items,
> gr_vector_const_void_star& input_items,
> gr_vector_void_star& output_items)
> {
> int ninput_items = noutput_items; // cuz it's a sync block
>
> // default to send a mid-burst packet
> _metadata.start_of_burst = false;
> _metadata.end_of_burst = false;
>
> // collect tags in this work()
> const uint64_t samp0_count = nitems_read(0);
> get_tags_in_range(_tags, 0, samp0_count, samp0_count + ninput_items);
> if (not _tags.empty())
> this->tag_work(ninput_items);
>
> if (not pmt::is_null(_length_tag_key)) {
> // check if there is data left to send from a burst tagged with
> length_tag
> // If a burst is started during this call to work(), tag_work()
> should have
> // been called and we should have _nitems_to_send > 0.
> if (_nitems_to_send > 0) {
> ninput_items = std::min<long>(_nitems_to_send, ninput_items);
> // if we run out of items to send, it's the end of the burst
> if (_nitems_to_send - long(ninput_items) == 0)
> _metadata.end_of_burst = true;
> } else {
> // There is a tag gap since no length_tag was found
> immediately following
> // the last sample of the previous burst. Drop samples until
> the next
> // length_tag is found. Notify the user of the tag gap.
> std::cerr << "tG" << std::flush;
> // increment the timespec by the number of samples dropped
> _metadata.time_spec += ::uhd::time_spec_t(0, ninput_items,
> _sample_rate);
> return ninput_items;
> }
> }
>
> boost::this_thread::disable_interruption disable_interrupt;
> #ifdef GR_UHD_USE_STREAM_API
> // send all ninput_items with metadata
> const size_t num_sent = _tx_stream->send(input_items, ninput_items,
> _metadata, 1.0);
> #else
> const size_t num_sent = _dev->get_device()->send(input_items,
> ninput_items,
> _metadata,
> *_type,
>
> ::uhd::device::SEND_MODE_FULL_BUFF,
> 1.0);
> #endif
> boost::this_thread::restore_interruption
> restore_interrupt(disable_interrupt);
>
> // if using length_tags, decrement items left to send by the number of
> samples sent
> if (not pmt::is_null(_length_tag_key) && _nitems_to_send > 0) {
> _nitems_to_send -= long(num_sent);
> }
>
> // increment the timespec by the number of samples sent
> _metadata.time_spec += ::uhd::time_spec_t(0, num_sent, _sample_rate);
>
> // Some post-processing tasks if we actually transmitted the entire
> burst
> if (not _pending_cmds.empty() && num_sent == size_t(ninput_items)) {
> GR_LOG_DEBUG(d_debug_logger,
> boost::format("Executing %d pending commands.") %
> _pending_cmds.size());
> BOOST_FOREACH (const pmt::pmt_t& cmd_pmt, _pending_cmds) {
> msg_handler_command(cmd_pmt);
> }
> _pending_cmds.clear();
> }
>
> return num_sent;
> }
>
> From this code, it can be seen that the data is transmitted including
> _metadata:
>
> const size_t num_sent = _tx_stream->send(input_items, ninput_items,
> _metadata, 1.0);
>
> The "time_spec" is updated for each block that is sent out:
>
> _metadata.time_spec += ::uhd::time_spec_t(0, num_sent, _sample_rate);
>
> Now you mentioned "has_time_spec" below. I extended to code in the
> following way:
>
> // increment the timespec by the number of samples sent
> _metadata.time_spec += ::uhd::time_spec_t(0, num_sent, _sample_rate);
> GR_LOG_DEBUG(d_debug_logger, boost::format("Setting metadata
> time_spec: %d:%f") % _metadata.time_spec.get_full_secs() %
> _metadata.time_spec.get_frac_secs());
> _metadata.has_time_spec = true;
>
>
> To my understanding, gr-uhd now passes the correct timestamps on to UHD.
> However, the timed command is still ignored.
>
>
> Thanks,
> Lukas
>
>
> PS: I will attempt to use the tagged stream ... but then I will have the
> issue that I need to tune TX *plus* RX at the same time! Furthermore, the
> streaming tags API is super rudimentary. Also, skimming the source code for
> the tag processing, I am not sure if this would change anything.
>
>
>
>
>
>
>
>
> Gesendet: Dienstag, 03. März 2020 um 13:25 Uhr
> Von: "Sam Reiter" <sam.rei...@ettus.com[mailto:sam.rei...@ettus.com
> ][mailto:sam.rei...@ettus.com[mailto:sam.rei...@ettus.com]]>
> An: "Rob Kossler" <rkoss...@nd.edu[mailto:rkoss...@nd.edu][mailto:
> rkoss...@nd.edu[mailto:rkoss...@nd.edu]]>
> Cc: "Lukas Haase" <lukasha...@gmx.at[mailto:lukasha...@gmx.at][mailto:
> lukasha...@gmx.at[mailto:lukasha...@gmx.at]]>, "USRP-users@lists.ettus.com
> [mailto:USRP-users@lists.ettus.com][mailto:USRP-users@lists.ettus.com
> [mailto:USRP-users@lists.ettus.com]]"; <usrp-users@lists.ettus.com[mailto:
> usrp-users@lists.ettus.com][mailto:usrp-users@lists.ettus.com[mailto:
> usrp-users@lists.ettus.com]]>
> Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using
> a timed command
>
> 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[https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Clocking_and_Timekeeping_in_the_USRP][https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Clocking_and_Timekeeping_in_the_USRP[https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD%23Clocking_and_Timekeeping_in_the_USRP]]
> <https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Clocking_and_Timekeeping_in_the_USRP[https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD%23Clocking_and_Timekeeping_in_the_USRP][https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD%23Clocking_and_Timekeeping_in_the_USRP[https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD%23Clocking_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[https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html][https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5D][https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5D%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5D%5D]
> <https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5D%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5D%5D%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5D%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5Bhttps://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html%5D%5D%5D>
>
> 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[mailto:
> rkoss...@nd.edu][mailto:rkoss...@nd.edu[mailto:rkoss...@nd.edu]][mailto:
> rkoss...@nd.edu[mailto:rkoss...@nd.edu][mailto:rkoss...@nd.edu[mailto:
> 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[mailto:
> rkoss...@nd.edu][mailto:rkoss...@nd.edu[mailto:rkoss...@nd.edu]][mailto:
> rkoss...@nd.edu[mailto:rkoss...@nd.edu][mailto:rkoss...@nd.edu[mailto:
> 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[mailto:
> lukasha...@gmx.at][mailto:lukasha...@gmx.at[mailto:lukasha...@gmx.at
> ]][mailto:lukasha...@gmx.at[mailto:lukasha...@gmx.at][mailto:
> lukasha...@gmx.at[mailto: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[mailto:sam.rei...@ettus.com
> ][mailto:sam.rei...@ettus.com[mailto:sam.rei...@ettus.com]][mailto:
> sam.rei...@ettus.com[mailto:sam.rei...@ettus.com][mailto:
> sam.rei...@ettus.com[mailto:sam.rei...@ettus.com]]]>
> An: "Rob Kossler" <rkoss...@nd.edu[mailto:rkoss...@nd.edu][mailto:
> rkoss...@nd.edu[mailto:rkoss...@nd.edu]][mailto:rkoss...@nd.edu[mailto:
> rkoss...@nd.edu][mailto:rkoss...@nd.edu[mailto:rkoss...@nd.edu]]]>
> Cc: "Lukas Haase" <lukasha...@gmx.at[mailto:lukasha...@gmx.at][mailto:
> lukasha...@gmx.at[mailto:lukasha...@gmx.at]][mailto:lukasha...@gmx.at
> [mailto:lukasha...@gmx.at][mailto:lukasha...@gmx.at[mailto:
> lukasha...@gmx.at]]]>, "USRP-users@lists.ettus.com[mailto:
> USRP-users@lists.ettus.com][mailto:USRP-users@lists.ettus.com[mailto:
> USRP-users@lists.ettus.com]][mailto:USRP-users@lists.ettus.com[mailto:
> USRP-users@lists.ettus.com][mailto:USRP-users@lists.ettus.com[mailto:
> USRP-users@lists.ettus.com]]]" <usrp-users@lists.ettus.com[mailto:
> usrp-users@lists.ettus.com][mailto:usrp-users@lists.ettus.com[mailto:
> usrp-users@lists.ettus.com]][mailto:usrp-users@lists.ettus.com[mailto:
> usrp-users@lists.ettus.com][mailto:usrp-users@lists.ettus.com[mailto:
> 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][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]]][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com][mailto:
> 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][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]]][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]][mailto:
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com][mailto:
> 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][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com]][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com]]][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com]][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com][mailto:
> 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][http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5D][http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5D%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5D%5D]
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5D%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5D%5D%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5D%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________USRP-users%5D%5D%5D>
> mailing list
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com]][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com]]][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com]][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com][mailto:
> USRP-users@lists.ettus.com[mailto:USRP-users@lists.ettus.com]]]]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com[http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com][http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5D][http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5D%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5D%5D]_______________________________________________
> USRP-users
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5D%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5D%5D%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5D%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5Bhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com%5D%5D%5D_______________________________________________USRP-users>
> mailing list
> USRP-users@lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/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
