Hi JM, in essence, you'll have to add them up in the end – but as you've noticed,
On 18.05.2016 14:32, redsals...@openmailbox.org wrote: > - Adder : (http://i.imgur.com/1V7nroZ.png) > Of course, it's not working because the adder waits for one > sample on each input to produce one sample, so I may code a custom > block to output null samples when there is no input sample .. which is > dirty because it would not be burst tx anymore. And, to add things up, they would have to have the same sampling rate – so you'll need a resampler after any of those. Frankly, that's probably more CPU-intense than if you'd just used the same sampling rate in all your three VCOs, or just used one VCO, and fed it with differently scaled signals. You'd have a problem if two channels would happen to be active at the same time. That's an interesting point: do you want two signals on two different streams to be sent one after the other, or simultaneously? > > - Multiple USRP sink : (http://i.imgur.com/Hr8EiyG.png) > Simply put one USRP sink for each channel, but there may be > collisions. If you have three USRPs, that would work, but you can't use the same USRP with three different usrp_sinks. > > - Complex to Message to Complex : (http://i.imgur.com/40lxtWR.png) > Seems like it will solve the collision problem, but the > packet_len tag is altered during the modulation chain and I can't > figure out how to recalculate it. > > > I think this "problem" can be resolved by many ways due to the options > offered with tags, custom blocks and uhd command interface but i > haven't figured out a correct one yet ! Well you found the problem's core: due to how GNU Radio asks (non-sink) blocks whether they can do something with the input that's present: 1. It's waiting for a notice that there's new space in the output buffer(s) of a block, or there's new items in the input buffer(s) 2. GNU Radio asks the block (via the//forecast method) how much input it would need on the individual input buffers to produce <min_n(amount of free space in output buffer n)> items 3. if the answer is higher than any of the input buffer's contents, the questioning is repeated with half the output items, typically. 1. if the block can't output a single item, it's put to sleep until new input arrives, then go back to 2. 2. if the block signals possibility to produce, it's general_work method is called with noutput_items=min_n(amount of free space in output buffer n). 4. the block is asked again whether it can do something with the amount of items left in the input buffers and the amount of space left in the output buffer. 1. if yes, go to 3.2 2. if not, go to 1 you can't have a block that says something like "Ok, to produce one out item, I'll need input on EITHER input0, OR input1, OR input2"; you can only say: Ok, with this amount per input buffer, I can definitely work, or I definitely can't work. Otherwise, your block will be put to sleep. meh. So, the quickest way to go is probably converting the tagged stream back to a PDU, and connecting the resulting three message ports to a single pdu-to-tagged stream. That of course only works if you can live with simultaneously active channels being "sequentialized" randomly. Other than that: your zeropadding approach isn't bad – have a look at gr-eventstream! Best regards Marcus
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
