Re: Transmitting on both channels on USRP X300

[Sunny Sam]

Marcus, 

Thank you for your response. 

I am trying to understand how the tagged-streams allow the scheduler to call the USRP Sink block work function when it receives data on any of the two input lines. The tagged stream blocks document says the work function for tagged-streams is input-driven, which is what I need the USRP Sink work function to be.  Please help me understand this. 

I don't have any other problem using the modified tunnel.py program. I can send and receive on each channels using subdev spec A and B settings between two X300s. The problem is when I enable USRP Sink block with two channels and transmit on both channels. Even then, if I provide the same data length at the same time to both channels, it works. I am trying to make it work so that it can transmit when it receives different data length at different times on any of the two input lines. 

Thanks again in advance for your help. 

On Wed, Jan 22, 2020 at 10:08 PM Marcus D. Leech <address@hidden> wrote:

On 01/22/2020 07:26 PM, Sunny Sam wrote:
> Hi everyone,
>
> I am trying to transmit data from two UDP sockets using the two USRP
> X300 TX lines. I modified the tunnel.py example to do this. The
> modulated signals from the two UDP sockets are connected to the UHD
> USRP Sink block input 0 and 1. What I have noticed is, the work
> function for the USRP Sink block does not get called until there is
> data on both UHD USRP sink input lines. And, it only transmit when it
> receives the same number of data on both input lines at the same time.
> Is there a way to make the USRP Sink block transmit the received data
> on any input line without waiting for data on the other input line?
> I also noticed if I just start the top block, tb.start(), I get a lot
> of late packets (LLLLL).  If I start, stop, and start the top block
> again as shown below, I don't get the late packets print. I feel like
> this is related to the USRP Sink block not initializing both input
> lines with the first tb.start() call. Is my assumption correct? Is
> there a better way to do this? Please advise.
>
> tb.start()
> time.sleep(0.25)
> tb.stop()
> time.sleep(0.25)
> tb.start()
>
>
> Thank you in advance.
>
Gnu Radio is fundamentally a *streaming* architecture.  So, it naturally
needs all streams to be running at the same time.

There are mechanisms, using tagged-streams to do "burst" transmissions,
but I'm not really an expert on how to make those work.

I'll observe that tunnel.py is, as far as I know, woefully out-of-date
with respect to underlying Gnu Radio mechanisms, etc.

You might be better off starting with a clean sheet of paper, so to speak.