Re: [USRP-users] Bits per sampling and oversampling
Thanks for the response Ian, with packed you mean that when using the SC16, it also uses all of its bits? Considering the IC appears to always return 12 bits per sample, couldn't the FPGA increase the number of bits even further for higher dynamic range? I'm thinking maybe sampling at high an On Sat, Jun 2, 2018 at 5:46 PM, Ian Buckley wrote: > Miguel, > By default UHD will always move samples to/from the B200 over USB in the so > called SC16 format, which is a fixed point point representation with 1 sign > bit and 15 fractional bits (-1<=x<1). You can also use SC12 and SC8, which > have respectively 1 sign bit and 11/7 fractional bits if you are struggling > to get the sample rate you need across USB. These are all packed formats in > the sense there are no unused bits in the USB data stream. There is also an > FC32 format (single floating point), but the only benefit of using this is to > offload the integer to float conversion from your host to FPGA at the expense > of doubling the USB bitrate, so its rarely used. > > B200 always oversamples, the radio IC uses a 4bit sigma-delta ADC that runs > at an integer multiple of the sample rate, typically many hundreds of > megahertz. UHD calculates an optimal clock rate for the ADC/DAC based on your > requested sample rate to maximize the dynamic range and other benefits. The > interpolation/decimation occurs both in the radio IC and FPGA dependent on > configuration and the sample interface between them is always 12bits in size. > > -Ian > >> On Jun 2, 2018, at 11:50 AM, Miguel P via USRP-users >> wrote: >> >> Hello, >> >> I got a B200 and I'm wondering if data is sent with "unsed" bits when >> sending data from the sdr to the host. For instance in case of 12 bits >> per sample, would those 12 bits be sent in a 16 bit block? >> If that's the case, is there any reason not to transfer data more >> efficiently (specially considering that the USB has trouble keeping up >> with such fast transfer rate). >> I'm also wondering if the SDR oversamples when using low sampling >> rates in order to increase the number of bits? That is, for instance >> if host requests 1msps the SDR could behind the scenes sample at >> 32msps and increase the number of bits by 5 and send data to the host >> at 1msps but wtth 5 more bits per sample. Of course I could just do >> this in the host, but then I may choke the USB or host because I would >> have to process a 32msps stream. >> >> Thanks in advance >> >> ___ >> 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] Bits per sampling and oversampling
Miguel, By default UHD will always move samples to/from the B200 over USB in the so called SC16 format, which is a fixed point point representation with 1 sign bit and 15 fractional bits (-1<=x<1). You can also use SC12 and SC8, which have respectively 1 sign bit and 11/7 fractional bits if you are struggling to get the sample rate you need across USB. These are all packed formats in the sense there are no unused bits in the USB data stream. There is also an FC32 format (single floating point), but the only benefit of using this is to offload the integer to float conversion from your host to FPGA at the expense of doubling the USB bitrate, so its rarely used. B200 always oversamples, the radio IC uses a 4bit sigma-delta ADC that runs at an integer multiple of the sample rate, typically many hundreds of megahertz. UHD calculates an optimal clock rate for the ADC/DAC based on your requested sample rate to maximize the dynamic range and other benefits. The interpolation/decimation occurs both in the radio IC and FPGA dependent on configuration and the sample interface between them is always 12bits in size. -Ian > On Jun 2, 2018, at 11:50 AM, Miguel P via USRP-users > wrote: > > Hello, > > I got a B200 and I'm wondering if data is sent with "unsed" bits when > sending data from the sdr to the host. For instance in case of 12 bits > per sample, would those 12 bits be sent in a 16 bit block? > If that's the case, is there any reason not to transfer data more > efficiently (specially considering that the USB has trouble keeping up > with such fast transfer rate). > I'm also wondering if the SDR oversamples when using low sampling > rates in order to increase the number of bits? That is, for instance > if host requests 1msps the SDR could behind the scenes sample at > 32msps and increase the number of bits by 5 and send data to the host > at 1msps but wtth 5 more bits per sample. Of course I could just do > this in the host, but then I may choke the USB or host because I would > have to process a 32msps stream. > > Thanks in advance > > ___ > 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
[USRP-users] Bits per sampling and oversampling
Hello, I got a B200 and I'm wondering if data is sent with "unsed" bits when sending data from the sdr to the host. For instance in case of 12 bits per sample, would those 12 bits be sent in a 16 bit block? If that's the case, is there any reason not to transfer data more efficiently (specially considering that the USB has trouble keeping up with such fast transfer rate). I'm also wondering if the SDR oversamples when using low sampling rates in order to increase the number of bits? That is, for instance if host requests 1msps the SDR could behind the scenes sample at 32msps and increase the number of bits by 5 and send data to the host at 1msps but wtth 5 more bits per sample. Of course I could just do this in the host, but then I may choke the USB or host because I would have to process a 32msps stream. Thanks in advance ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
