Re: [Discuss-gnuradio] Late Packet Arrivals

[Marcus Müller]

Hi Alex,

right, so that's the approach of calculating tx_time based on the time of samples coming in; so if you set the start_time to that time plus a little more delay, you might be able to solve the "L" issue. I don't know how the actual calculation of your set_start_time(value) is, but chances are the program is not adding enough to the receive time, and because your computer takes more than infinitesimately little time to process RX data, the TX streamer gets its data too late.

Regarding getting the current time: The rx_time/sample counting approach is definitely the right one; every other approach is inherently out of sync with the samples.

Command list: You can use message passing [1] with the commands listed in [2]. The stream tags that the sink understands are documented in [3].

Best regards,
Marcus

[1] https://gnuradio.org/doc/doxygen/page_msg_passing.html
[2] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
[3] https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html#uhd_tx_tagging

On 23.11.2015 16:03, Alexander Levedahl wrote:

Hi Marcus,

It appears to me on the first set of samples received from the USRP, there are tags with keys: 'rx_time', 'rx_rate', and 'rx_freq'.  The work function inside the python block uses the value associated with 'rx_time' to set the start time of the first packet.  There after, it counts the number of samples to keep track of time amount of time that has passed.  I am simultaneously RX'ing and TX'ing with the USRP (though at different rates). 

How do I get the USRP to continuously tell me what time it is at or ping it for its time?  I looked into using the get_time_now function, but it appears that I need access to the usrp object.  I do not inside the python block.

Also is there a list somewhere of commands that can be sent to the USRP?  I tried looking at the code itself, but did not see anything.

Thanks,

Alex

On Mon, Nov 23, 2015 at 4:46 AM, Marcus Müller <address@hidden> wrote:

Hi Alexander,

ha! good catch:

I have one block (in python) that sends (via asyncronous message) a command that has the following fields:
tx_time, tx_freq, data to transmit.  This message is received by a c++ block. 

tx_time internally uses these command.

I suspect that processor loading may be an issue because when I run a simpler (but less capable) version of this flowgraph, I do not get the late packet issue.

That sounds very reasonable.
How does your system calculate the tx_time value? To explain:
The PC and the USRP have two completely different notions of time; hence, if the PC wants the USRP to do something at a specific point in time, e.g. in two seconds, then it either has to ask the USRP what time it is now, or explicitly set the device time of the USRP. Of course, if you know the time of the first sample, and you stream continously, then then the device time at the Nth samples is the first sample time + N / f_sample. However, the first sample time somehow has to be known.

Since you didn't find anything that sets the time, I'd assume the program figures out what time the USRP has; this can either be done asynchronously via get_time_now, get_time_last_pps, or extracted from the packets coming from the USRP (that only makes sense if you're simultaneously RX'ing with the USRP).
Based on that time, the host then calculates tx_time; probably something like rx_time = USRP_time + some_delay. If your flow graph gets too complex, the delay might need to increase.

Best regards,
Marcus

On 22.11.2015 20:44, Alexander Levedahl wrote:

Marcus,

The USRP type is an X310.  The UHD release is 3.8.4.  The USRP does not have a GPSDO.  I grep'ed the code for 'set_command_time', 'tx_metadata_t', 'set_time_now', 'set_time_next_pps', and 'set_time_unknown_pps' and got nothing.

I have one block (in python) that sends (via asyncronous message) a command that has the following fields:

tx_time, tx_freq, data to transmit.  This message is received by a c++ block. 

The c++ block modulates the data by prepending some data to the beginning of the data to transmit.  The first time a new command is received from the python block, the C++ block copies the frequency and time to transmit to the C++ block's output.  The actual data to output is large enough that it must be written out in multiple calls to the work function. 

Timing sync is maintained between the USRP clock and the flowgraph by counting the number of samples received from the USRP. 

I suspect that processor loading may be an issue because when I run a simpler (but less capable) version of this flowgraph, I do not get the late packet issue.

Thanks,

Alex

On Sun, Nov 22, 2015 at 2:16 PM, Marcus Müller <address@hidden> wrote:

Hi Alex,

what's your USRP type?

look for lines that are uspr->set_command_time, or where you have a uhd::tx_metadata_t and set a time_spec in that.

Also, timed commands imply that you set a sensible time on the USRP, so look for any place that calls "set_time_now", "set_time_next_pps" or "set_time_unknown_pps".

Which version of UHD are you currently using? Is your USRP equipped with a GPSDO?

Best regards,
Marcus

On 22.11.2015 19:56, Alexander Levedahl wrote:

Hello,

I have an application that is spewing up 'L's indicating late packet arrival at the destination.  How can I go about investigating this problem (e.g., how do I determine what the time of transmission is in the packet and the time it is received by the ettus box)?

I have not done much work in gnuradio before and am taking over an application from someone previous. 

Thanks,

Alex

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio