Okay, so to elaborate on the design options a little more... I see to primary topologies: packet push, and packet pull. Both designs have a slimmed down packet_builder for each channel. The multichannel multiplexing would be similar in either design.
### Packet Push: Packet buffers only, packets built on channel input. This design pushes preformed packets into a packet FIFO, simply to be to be read out via USB as is. Multiple rxclk ticks would be required while writing the header information to the FIFO, which limits our maximum sample speed. (I think) Without any channel buffering, the maximum sample rate would be 1/6 master clock, since we need 4 additional master cycles to push out the header before the first sample of a packet. Maybe that is an issue, maybe not. 1. New packet begins, I/Q samples waiting, save metadata, write headerH 2. Write headerL 3. Write timestampH 4. Write timestampL 5. write I 6. write Q ### Packet Pull: Channel buffering only, packets built on USB read. This design uses a separate FIFO/s for packet metadata (timestamp, etc) parallel to the channel FIFO. The actual packets are constructed via the USB read process. The metadata FIFO/s would be pretty shallow, as they are 1 write per packet. This design should theoretically be able to read samples at master_clock rates. While the USB/host couldn't stream that, if operated on short burst reads (less than the FIFO capacities), it could increase our maximum sampling speeds. Also, since the header isn't built until read, there is the possibility to include information in the header that is not available at the first sample. E.g.: * Packet size: don't need to know size in advance, read could be interrupted, and the size can be adjusted on USB read. * RSSI: e.g. peak, avg, last, etc. * Padding: padding would be virtual space, not FIFO space. Just send 0, don't store them. In general, it seems to me that the packet pull design offers more performance and flexibility. Unless someone points out some flaws in my reasoning, I will proceed on that path. --ets _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
