Re: [Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks?

[Michael Dickens]

Hi DL - One possible option that I think would handle both TDMA and FDMA and 2 streams of data: use a PFB with 2 channels (or 2 separate rotators / filters), to create 2 parallel paths each at baseband. Each path represents complex data that was modulated at some frequency and bandwidth & is now at baseband. For each path, detect the signal of interest, and once found package it as a tagged_stream. Each path leads into a different input of the tagged_stream_mux block as before (assuming that worked before, it should work now). In this manner, the mux will wait until it has 2 such tagged_streams. Maybe this would do what you want? Hope this is useful! - MLD

On Mon, Jul 22, 2019, at 2:25 PM, Lundberg, Daniel wrote:

Hi, thanks.  To elaborate a bit…

I need to be able to absolutely align the start of two signals and add them in an FDMA sense (so I will construct the signals in different parts of the band and just add them together as complex numbers).  The receiving system requires that I do the alignment for it.  It is also important that one of the two signals be created and transmitted in a timely manner (I have a requirement for the time between when the second signal is created and when it is transmitted, because it contains some real-time diagnostic information).

I have previously solved a similar problem, but instead of FDMA I was doing TDMA.  The basic code structure is:

Convert the first of the two signals to a tagged stream via stream to tagged stream block.  

Custom trigger block waits for the packet_len tag in this signal, and when it sees it, sends a message to trigger the creation of a PDU with the second signal within another custom block. 

PDU goes into PDU to tagged stream block

Combine two signals (now both tagged streams) in a tagged stream mux block. 

To the USRP and beyond!

Using one signal to trigger the other, combined with the tagged stream mux waiting until it has both signals in memory to proceed, means that the latency of the whole process is naturally controlled, because the first signal will not pass another packet_len tag through my custom trigger block until the first packet is clear of the tagged stream mux.  This did require explicit adjustment to minimum buffer sizes to accommodate the big packets, but things are stable and working on a pretty standard dell laptop, so I don’t have any performance worries at this point, even with a bunch of custom code written in python.

So back to FDMA:

I can do the same sort of thing, where I trigger the creation of the second signal off of the first, but I don’t have an explicit way to control the flow without the tagged stream mux introducing the (desirable!) bottleneck.  Without that backpressure, there is nothing to stop the first signal from triggering the second signal a large number of times until a non-tagged stream block’s buffer is filled up.  This is undesirable for me, because it means I will have a bunch of diagnostic signals generated right away, and then the system will eventually settle into some steady-state latency that is longer than my requirement.  So if I had an OOT “tagged stream add” block that does a simple complex add, but waits for both tagged stream packets to be present before proceeding, I think I would be more or less done.

Thank you for the OOT compiling tips, I’ll give it a go.  C++ is not my forte…

DL