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 From: Michael Dickens <michael.dick...@ettus.com> Sent: Monday, July 22, 2019 1:52 PM To: Lundberg, Daniel <daniel.lundb...@gtri.gatech.edu>; Discuss GNURadio <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Can't create Out of Tree Tagged Stream Blocks? Hi DL - 2 primary thoughts: 1) To "create" a tagged stream block in your OOT using gr_modtool (if it doesn't do that as you desire), find an already existing tagged_stream block that you understand the programming of. Use gr_modtool to create a new "sync" block, then copy/paste from the existing tagged_stream block into your new one: 3 files: include/OOT/NAME.h ; lib/NAME_impl.h ; lib/NAME_impl.cc . The CMakeLists.txt will already be setup for compiling, assuming you don't need any special definitions or linkage or whatever. Then, edit those files to do what you want. 2) 1 million data points is a lot of points to do using a data stream! And even more if you used a tagged stream for all 1e6 samples! Do you need them all at the same time, or are the offsets small enough that you just need a small number of data samples stored before you can alight them? Alternative implementations might include using PDUs ... but much depends on what exactly you're trying to accomplish beyond what you wrote (what the actual algorithm is you're trying to implement). Hope this is useful! - MLD On Mon, Jul 22, 2019, at 11:28 AM, Lundberg, Daniel via Discuss-gnuradio wrote: I am working within Gnuradio version 3.7.13.4. As far as I can tell, gr_modtool does not support tagged stream blocks for either python or C++. Trying to make a new tagged stream block in C++ will create QA code, but does not make files for the actual block. For python it will throw a hard error. This appears to be a known issue: https://github.com/gnuradio/gnuradio/issues/2489 Can someone point me to some documentation on how to implement an out of tree module without gr_modtool? If this is a non-starter, then here is my problem description. I am open to suggestions on how to solve the problem without an OOT tagged stream block: I need to implement a block that takes two generated signals with defined, very large (~ million sample) packet lengths that are produced at different times, align them on a sample-by-sample basis, and adds them. I know how to do this within a tagged stream block. I am open to ideas on how to do this without tagged streams, but I’m not sure how to do sample alignment of large packets without having them contained in a tagged stream block work function. Thank you, DL _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
