Hi again Rob, Yes, I confirm:
1.) Finally I get the commands to execute at the same time (TX and RX individually and both at the same time) 2.) Yes, the phase is random after each retune, even when I retune back to the same frequency 3.) (2) is only true if it includes *DSP* retuning. With naalog retuning (+integer-N retuning) I get phase coherence, as expected. I actually expected the PLL retuning much more challenging than the DSP retuning but for some reason it seems to be the opposite... Thanks, Lukas Gesendet: Freitag, 13. März 2020 um 10:07 Uhr Von: "Rob Kossler" <rkoss...@nd.edu> An: "Lukas Haase" <lukasha...@gmx.at> Cc: "Marcus D Leech" <patchvonbr...@gmail.com>, "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 Also, is it true that now you can successfully tune both RF and DSP at the desired command time (but the remaining problem is that the Rx phase is not consistent when after you tune to a new frequency and then tune back to the original)? If this is not correct, please explain again. Rob On Fri, Mar 13, 2020 at 9:53 AM Rob Kossler <rkoss...@nd.edu[mailto:rkoss...@nd.edu]> wrote: 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[mailto: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[mailto:patchvonbr...@gmail.com]> An: "Rob Kossler" <rkoss...@nd.edu[mailto:rkoss...@nd.edu]> Cc: "Lukas Haase" <lukasha...@gmx.at[mailto:lukasha...@gmx.at]>, "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 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[mailto: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][mailto: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][mailto: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][https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html%5Bhttps://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html%5D]: 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][mailto:rkoss...@nd.edu[mailto:rkoss...@nd.edu]]> An: "Lukas Haase" <lukasha...@gmx.at[mailto:lukasha...@gmx.at][mailto:lukasha...@gmx.at[mailto:lukasha...@gmx.at]]> Cc: "Sam Reiter" <sam.rei...@ettus.com[mailto:sam.rei...@ettus.com][mailto:sam.rei...@ettus.com[mailto:sam.rei...@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]]"; <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 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][https://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html%5Bhttps://www.gnuradio.org/doc/sphinx-3.7.7/uhd.html%5D]] 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]][mailto: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]][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 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]]][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[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]]][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[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]]][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[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]]][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[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]]][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[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]]][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[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]]][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]]]]"; <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]]]]> 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]]]][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[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]]]][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[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]]]][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[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]]]][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[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[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] _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
