> 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. > - George Steve _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio