Re: [USRP-users] B210 -- various questions on sampling/clock rates

2017-10-25 Thread Rob Heig via USRP-users 
Hi,

Thanks a lot for your answer! The link you gave me is also full of very
very interesting material :)
Have a nice day!
Rob

On 25 October 2017 at 22:16, Anon Lister  wrote:

> Try specrec to record data.
>
> https://github.com/garverp/gr-analysis
>
> As to why it works better see this presentation:
> http://www.trondeau.com/grcon15-presentations#
> wednesday_Lincoln_Synchronized
> (The link is down at the time of writing, perhaps it will be up again soon)
>
> With it I am able to do 50Msample w/o overruns.
>
> Search for master_clock_rate in the uhd documentation. Setting that will
> allow you to manually set the master clock rate for the b2xx and e3xx
> devices. As to why I believe oversampling has some benefits a more dsp
> focused individual will be able to elaborate on. I believe the logic for
> automatic choice is something like the highest multiple of the desired
> sample rate that is less than the maximum clock rate.
>
> -Anon
>
> On Oct 25, 2017 12:12 PM, "Rob Heig via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
>
> Hi,
>
> I am experimenting a bit with the B210 board and I have a couple of
> questions concerning sampling/clock rates:
>
> - is it normal that, on a decent modern PC with plenty of cores, memory,
> and working on a SSD, a simple program that dumps I/Q data on file gives
> more often than not overflows ("" messages from UHD) starting at around
> 40Msps (sometimes, with a very lightweight charge of the CPU, even at
> 10-20)? I have been monitoring USB traffic using vUSBAnalyzer to see if
> anything's wrong, and it seems that from time to time the transmission
> simply stops and gets reset after a few seconds (meaning that the board's
> buffers overflowed, I guess), but I couldn't find a reason why this
> happens. I have asked a colleague to increase the size of the buffers on
> the FPGA, but that improved the situation only slightly... Is there any
> architectural documentation explaining the behavior of UHD with a USB
> device to see where the bottleneck could be (without having to delve into
> the UHD code)?
>
> - playing with filters I saw that, when the sampling rate is set below
> 16Msps, the clock rate is set at a multiple of the desired sampling rate
> (for instance, 32MHz for 2Msps, 40MHz for 5Msps, ...). Actually, I realized
> it only after having spent a whole morning wondering why a custom FIR
> filter that was supposed to work nicely at 8Msps was not filtering at all
> (I guess the messages printed on the console are there for a reason
> ;)). What is the reason behind this choice? Is it imposed by the RFIC (I
> couldn't find anything on the reference manual, but I might be
> mistaken) or by the board design? What is the rule that governs the
> choice of the clock rate? Is there any documentation about it?
>
> Thanks a lot in advance and have a nice day!
> Rob
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 -- various questions on sampling/clock rates

2017-10-25 Thread Anon Lister via USRP-users 
Try specrec to record data.

https://github.com/garverp/gr-analysis

As to why it works better see this presentation:
http://www.trondeau.com/grcon15-presentations#wednesday_Lincoln_Synchronized
(The link is down at the time of writing, perhaps it will be up again soon)

With it I am able to do 50Msample w/o overruns.

Search for master_clock_rate in the uhd documentation. Setting that will
allow you to manually set the master clock rate for the b2xx and e3xx
devices. As to why I believe oversampling has some benefits a more dsp
focused individual will be able to elaborate on. I believe the logic for
automatic choice is something like the highest multiple of the desired
sample rate that is less than the maximum clock rate.

-Anon

On Oct 25, 2017 12:12 PM, "Rob Heig via USRP-users" <
usrp-users@lists.ettus.com> wrote:

Hi,

I am experimenting a bit with the B210 board and I have a couple of
questions concerning sampling/clock rates:

- is it normal that, on a decent modern PC with plenty of cores, memory,
and working on a SSD, a simple program that dumps I/Q data on file gives
more often than not overflows ("" messages from UHD) starting at around
40Msps (sometimes, with a very lightweight charge of the CPU, even at
10-20)? I have been monitoring USB traffic using vUSBAnalyzer to see if
anything's wrong, and it seems that from time to time the transmission
simply stops and gets reset after a few seconds (meaning that the board's
buffers overflowed, I guess), but I couldn't find a reason why this
happens. I have asked a colleague to increase the size of the buffers on
the FPGA, but that improved the situation only slightly... Is there any
architectural documentation explaining the behavior of UHD with a USB
device to see where the bottleneck could be (without having to delve into
the UHD code)?

- playing with filters I saw that, when the sampling rate is set below
16Msps, the clock rate is set at a multiple of the desired sampling rate
(for instance, 32MHz for 2Msps, 40MHz for 5Msps, ...). Actually, I realized
it only after having spent a whole morning wondering why a custom FIR
filter that was supposed to work nicely at 8Msps was not filtering at all
(I guess the messages printed on the console are there for a reason
;)). What is the reason behind this choice? Is it imposed by the RFIC (I
couldn't find anything on the reference manual, but I might be
mistaken) or by the board design? What is the rule that governs the
choice of the clock rate? Is there any documentation about it?

Thanks a lot in advance and have a nice day!
Rob

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com