According to your diagram here:
http://gnuradio.org/trac/wiki/UsrpTxModifications
Maybe we should have a tx_usb_fifo, tx_usb_fifo_reader, tx_chan_fifo,
tx_chan_fifo reader, tx_cmd_fifo_reader (the tx_chan_fifo and
tx_cmd_fifo are essentially the same thing, but the tx_cmd_fifo_reader
should figure out I2C, SPI, and other settings that may go down the
command FIFO).
Putting all of this within an mblock_processing module would be nice.
A potential hierarchy:
- mblock_processing
- tx_usb_fifo
- tx_usb_fifo_reader
- tx_chan_fifo
- tx_chan_fifo_reader
- tx_cmd_fifo_reader
You currently have it where the FIFOs are sitting inside of the
readers, which I could be OK with - but would prefer if the FIFOs were
separate.
Ok, I move the FIFOs outside next time I refactor this.
On the input side of the interpolating CIC filter, we input samples at
a rate of 1/rate. On the output side of the interpolating CIC filter,
samples come out every clock cycle. It's just the rate at which the
samples are supposed to be fed into the interpolating CIC filters to
get upconverted.
In the current design, everything is set to a single interpolation
rate and a single decimation rate for all TX or RX channels. In the
mblock design, we want to be able to independently control the
bandwidth and rates of each of the complex channels. This allows for
all sorts of interesting and different schemes to work.
Does that make sense?
Yes, it makes much more sense. In the current design, the strobes are
generated by a separated block; would it be more logical to make the
strobes be generated by the tx_chan_fifo_reader, so they are generated
only when needed (i.e. when there are samples to feed into the transmit
chain)?
Brian
Thibaud
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
