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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
