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, address@hidden wrote:
- Adder : (http://i.imgur.com/1V7nroZ.png [1])
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 [2])
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
[3])
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:
* 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)
* 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
* if the answer is higher than any of the input buffer's contents,
the questioning is repeated with half the output items, typically.
* if the block can't output a single item, it's put to sleep until
new input arrives, then go back to 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).
* 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.
* if yes, go to 3.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
Links:
------
[1] http://i.imgur.com/1V7nroZ.png
[2] http://i.imgur.com/Hr8EiyG.png
[3] http://i.imgur.com/40lxtWR.png
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio