Re: [Discuss-gnuradio] Late Packet Arrivals

[Marcus Müller]

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