Re: [Discuss-gnuradio] Timestamping baseband samples
Hi Marcus, If USRP crystal has a ppm of +-25ppm, then its RF deviation, and the baseband decoder detects this drift and correct it by resampling till it gets the required number of samples. So my question is this input side drift is corrected by baseband synchronization, and this should not be seen at audio output side. 25ppm drift is corrected and the time stamp will be put after that. For example if 10% interpolation is done on RF samples, then the timestamp should be modified to add for 10 samples. Is that the correct way to timestamp for audio packets ? -ben From: Marcus Müller <marcus.muel...@ettus.com> Sent: Saturday, February 10, 2018 9:47 PM To: Benny Alexandar; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Timestamping baseband samples Hi ben, the Ettus USRP series of devices (N2x0, B2xx, E3xx, X3xx, N3xx) have RX sample time stamping that you can find as tags in your sample flow. That means they can annotate a sample buffer with the device time of the first contained sample. The device time can be set according to an external standard, if helpful (e.g. a GPS clock). You won't find anything surprising in there: The first received item will have a tag containing the device time at which that sample was received. From there on, you can use (sample number)/(sampling rate) to calculate the device time corresponding to each packet. Since absolute time doesn't matter to your application, you could just as well do without that tag and simply count samples. With the timestamps, you still count samples, and add the timestamp from the first sample. There's no additional information that helps you solve the two-clock problem to be gained here. Best regards, Marcus On Sat, 2018-02-10 at 07:06 +, Benny Alexandar wrote: > Hi All, > > In Broadcast receiver where the RF samples are received on AIR and > channel decoder does the demodulation of digital radio symbols, and > extracts the compressed audio data. This is then fed to an audio > decoder to decode the audio. After decoding the uncompressed audio > has to be played out. > I would like to implement the jitter buffer, by having time stamps. > So my question is where to do the timestamping, the timestamp put > after audio decoding will be jittery because of variable audio > content and compression effects. So the best place is to put at the > RF input when baseband samples are buffered using DMA, this then can > be corrected for clock recovery and use it while sending out audio. > > > Any suggestions on this approach. > > -ben > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timestamping baseband samples
Hi ben, the Ettus USRP series of devices (N2x0, B2xx, E3xx, X3xx, N3xx) have RX sample time stamping that you can find as tags in your sample flow. That means they can annotate a sample buffer with the device time of the first contained sample. The device time can be set according to an external standard, if helpful (e.g. a GPS clock). You won't find anything surprising in there: The first received item will have a tag containing the device time at which that sample was received. From there on, you can use (sample number)/(sampling rate) to calculate the device time corresponding to each packet. Since absolute time doesn't matter to your application, you could just as well do without that tag and simply count samples. With the timestamps, you still count samples, and add the timestamp from the first sample. There's no additional information that helps you solve the two-clock problem to be gained here. Best regards, Marcus On Sat, 2018-02-10 at 07:06 +, Benny Alexandar wrote: > Hi All, > > In Broadcast receiver where the RF samples are received on AIR and > channel decoder does the demodulation of digital radio symbols, and > extracts the compressed audio data. This is then fed to an audio > decoder to decode the audio. After decoding the uncompressed audio > has to be played out. > I would like to implement the jitter buffer, by having time stamps. > So my question is where to do the timestamping, the timestamp put > after audio decoding will be jittery because of variable audio > content and compression effects. So the best place is to put at the > RF input when baseband samples are buffered using DMA, this then can > be corrected for clock recovery and use it while sending out audio. > > > Any suggestions on this approach. > > -ben > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Timestamping baseband samples
Hi All, In Broadcast receiver where the RF samples are received on AIR and channel decoder does the demodulation of digital radio symbols, and extracts the compressed audio data. This is then fed to an audio decoder to decode the audio. After decoding the uncompressed audio has to be played out. I would like to implement the jitter buffer, by having time stamps. So my question is where to do the timestamping, the timestamp put after audio decoding will be jittery because of variable audio content and compression effects. So the best place is to put at the RF input when baseband samples are buffered using DMA, this then can be corrected for clock recovery and use it while sending out audio. Any suggestions on this approach. -ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
