Hi all, I'd really like to help with this. I've been pouring over the design (usrp_inband_usb), so my brain is a little mushy at the moment, hopefully I'm not totally off track here.
1. Is it true that there are N RX Sample FIFOs? It seems that the channels are already muxed by the time they get to the packet_builder, no? 2. Can we just subtract the FIFO size (usedw?) from the timestamp in the packet builder? 3. When checking timestamps for expired command/data packets, is an overflow/wraparound on the timestamp_clock handled? (ref cmd_reader.v:107, chan_fifo_reader.v:145) 4. I wholeheartedly agree that it would be nice to have a "read N samples at time T command". --ets -----Original Message----- From: Brian Padalino [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2008 5:12 PM To: Steve Peters Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] inband timestamp issues On Wed, Aug 20, 2008 at 6:45 PM, Steve Peters <[EMAIL PROTECTED]> wrote: >> As a non-hardware person, I was thinking that a simple solution is to not >> really use the clock on the RX directly, but timestamp packets indirectly. >> You have a signal when the sample buffer is empty, when that signal is >> de-asserted for the first time, read the clock and take this as your initial >> RX clock time. >> >> Now, you go by the fact that you're sampling at a constant rate and >> timestamp packets based on that. The next packet gets timestamped at >> last_timestamp + 126samples_per_packet * decimation_rate. >> >> That way you're not timestamp on packet building, but logically the time the >> first sample of the packet arrived at the RX buffer. > > Correct me if I misunderstand, but you're not actually clocking > anything this way. Theoretically it should work, but there's nothing > telling me there weren't actually a million clock cycles between two > packets. There should definitely be a timestamp clock tied to the > master clock, in my opinion. > > Ketan and I discussed a couple possibilities earlier today. One might > be to have a timestamp buffer in parallel with the RX FIFO. Although > problems arise with making sure the timestamp changes at the border of > packets, unless there is one timestamp per sample, which is almost > certainly too excessive. > > Another idea is to move the FIFO to the other side of the packet > builder, as long as the packet builder can keep up with the > ADC/decimator output. It then outputs to the buffer. This was > Ketan's idea, so I apologize if I'm communicating it incorrectly. The current inband RX chain looks like: N RX Sample Streams -> N RX Sample FIFOs -> 1 Packet Builder -> 1 USB FIFO -> FX2 USB Interface What it should look like (in my opinion): N RX Sample Streams -> N Packet Builders -> N Packet FIFOs -> N:1 FIFO MUX -> FX2 USB Interface I believe the TX chain looks more like this, except with the arrows going in the opposite direction. On a side note, it might be interesting to have a command that can turn on the receiver and receive a specific number of inband packets. For example, if you know you may be receiving a transmission that is only 2ms long in a specific slot, it might be beneficial to only schedule 2ms (+/- a guard time) worth of samples to be delivered to the host, freeing up more CPU cycles for signal processing and using the USB bandwidth a little more efficiently. Comments or suggestions? Brian _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
