Hi JM,
in essence, you'll have to add them up in the end – but as you've
noticed,
- 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:
- 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
|
