Re: [Discuss-gnuradio] Timestamping baseband samples

2018-02-10 Thread Benny Alexandar 
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 
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] Connecting n210 via gigabit ethernet to usb3.0 connector to raspberry pi 3

2018-02-10 Thread Marcus Müller 
Hi Brandon,

As this isn't really a GNU Radio question, I'm including the usrp-users 
mailing list; if you could follow up there (you'll need to sign up
first[1]), that would help us keep the lists clean :)

So, there's a lot of things that might or might not be right here; I'm
picking my "most likely to help Brandon" top two:

1. If you want to talk to a device that's on 192.168.10.2, you need to
be on the same subnet. Please make sure you've set your network
interface to an IP from 192.168.10.X; for example, 192.168.10.1 would
do well.
2. The USRP *needs* Gigabit ethernet. Some USB devices only implement
Fast Ethernet (100 Mbit/s) or even just Ethernet (10 Mb/s. Yes, you can
still buy these). These won't work!

Best regards,
Marcus

[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On Sat, 2018-02-10 at 04:22 +, Brandon Dunn wrote:
> Hi i've read in past discussion board posts i found that a n210 could
> possibly be connected to a raspberry pi 3 via a gigabit ethernet to
> usb3.0 connector. I've recently purchased such a connector and wanted
> to try it out. When i did, the green light on the ethernet port of
> the n210 lite up however i seem to be unable to use uhd_find_devices
> or uhd_usrp_probe even with the args=usrp2 or serial=12345678 or the
> native ip address ip=192.168.10.2. Does anyone have any experience
> with this that can help me out?
> Thanks,
> Brandon
> ___
> 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

2018-02-10 Thread Marcus Müller 
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