|
From: | Michael Dickens |
Subject: | Re: [Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks? |
Date: | Mon, 22 Jul 2019 14:42:52 -0400 |
User-agent: | Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |