[USRP-users] x310 Master clock rate

Marcus Müller marcus.mueller at ettus.com
Wed Apr 22 10:38:27 EDT 2015

Excellent! You'll need that, because 50MS/s with 16 bit samples on both
I and Q mean that you end up with a bit rate of 1.6Gbit/s -- which
nicely illustrates why JSON might be a performance killer here:
When you save your samples in raw int16 on your permanent storage, it
"only" needs to provide you with 1.6Gbit/s; JSON stores numbers in
textual format.
Now, assuming the case where you save values as unsigned integers, each
integer in the 16 bit range will have 5 digits (on average 4.83,
actually if the values have a constant PDF, 5.16 if you're using signed
integers), plus one value-separating comma, so that's 6 digits; now,
assuming the standard case with 1B/character, this means a complex value
consisting of two integers needs 12B, or 96bit, which is three times
what your raw int16 storage would need; now, since you're actually
seeing small amounts of "U", I'd recommend doing optimizations like these.
The other aspect is that you need to parse JSON to get transmitable
samples, whereas raw storage just gives you the numbers you would hand
over to UHD directly as "bytes in memory", without any conversion,
parsing overhead.

Best regards,

On 04/22/2015 04:24 PM, Taariqa Maharaj wrote:
> Hi
> Yes I am referring to the 10 Gigabit Ethernet.
> Regards,
> Taariqa
> On 22 Apr 2015 4:20 PM, "Marcus Müller" <marcus.mueller at ettus.com
> <mailto:marcus.mueller at ettus.com>> wrote:
>     Hi Taariqa,
>     "L" is for Late packet, i.e. you did something that had a command
>     time, but the command time was already in the past -- without
>     knowing what your transmission application does, I can't really
>     say what effects that has on transmission continuity. It does,
>     however, either point to a lack of performance in your PC, or a
>     bug in your application, so it's not an "OK" thing.
>     JSON sounds like a bad choice to transport 50 Million complex
>     samples per second, really.
>     Try writing the samples as short (int16) values to a raw file
>     (e.g. using matlab's fwrite() ) and try transmitting that with the
>     UHD example
>     tx_samples_from_file
>     which should be installed.
>     You say you are connecting using Ethernet; are you referring to 10
>     Gigabit Ethernet?
>     Best regards,
>     Marcus Müller
>     On 04/22/2015 04:15 PM, Taariqa Maharaj wrote:
>>     Hi Marcus
>>     Just to confirm the "L" would not cause the "holes" in the
>>     transmission?
>>     We are connecting the x310 via Ethernet to the PC. The baseband
>>     signal is generated in matlab and written to a json file. We read
>>     this file and feed it into the buffer and transmit.
>>     Regards,
>>     Taariqa
>>     On Wed, Apr 22, 2015 at 3:49 PM, Marcus Müller
>>     <marcus.mueller at ettus.com <mailto:marcus.mueller at ettus.com>> wrote:
>>         Hi Taariqa,
>>         oh, yes, sorry, "O" is for Overflow, i.e. when your computer
>>         doesn't take samples fast enough from the receiving streamer
>>         of the USRP;
>>         "U" is Underflow, which is the equivalent thing on TX, so
>>         yes, that's probably why you are seeing "holes" in your
>>         transmission.
>>         If you'd like to transmit a 50 MHz pulse, then you need to
>>         use at least a 50MS/s sampling rate, which does solve the
>>         "odd decimation" warning, but introduces a heavier
>>         computational load on your PC, so it makes the "U" problem worse.
>>         How do you connect your X310 to your computer, and how do you
>>         generate your transmit signal?
>>         Best regards,
>>         Marcus
>>         On 04/22/2015 03:45 PM, Taariqa Maharaj wrote:
>>>         Hi Marcus
>>>         We would Ideally like to transmit a 50Mhz (bandwidth) pulse.
>>>         The UHD did not print out an "O". It did however print out
>>>         "L" and "U", would this cause the same effect?
>>>         Regards,
>>>         Taariqa
>>>         On Wed, Apr 22, 2015 at 11:44 AM, Marcus Müller
>>>         <marcus.mueller at ettus.com <mailto:marcus.mueller at ettus.com>>
>>>         wrote:
>>>             Hi!
>>>             Thanks for following up on this.
>>>>             With the master clock set at 200Mhz and a sampling rate
>>>>             of 40Msps the following warning appears:
>>>>             UHD Warning:
>>>>             The requested interpolation is odd; the user should
>>>>             expect CIC rolloff.
>>>>             Select an even interpolation to ensure that a halfband
>>>>             filter is enabled.
>>>>             interpolation = dsp_rate/samp_rate -> 5 = (200.000000
>>>>             MHz)/(40.000000 MHz)
>>>             To explain the warning:
>>>             The FPGA decimates the RX samples down, coming in at the
>>>             master clock rate from the ADC, to the sampling rate you
>>>             select.
>>>             To do that without introducing aliasing, it has to
>>>             low-pass filter them.
>>>             The FPGA filter chain has multiple stages; if I remember
>>>             correctly, the filters are in this order:
>>>             1. 1x CIC filter for odd factors in decimation
>>>             2. 3x 31-tap half band filters that each implement a
>>>             good decimation for factors of 2 each.
>>>             Now, if you use an odd decimation (200MHz/40MHz==5),
>>>             there's no factor of 2 in your decimation, and hence you
>>>             only use the "not-as-good" CIC filter, and are likely to
>>>             see effects of filter roll-of at the edges of your band.
>>>             In TX direction, it's quite the same problem:
>>>             1. 1x 17-tap half band interpolators
>>>             2. 1x 5-tap half band interpolators
>>>             3. 1x CIC
>>>             Therefore: if your measurements show that your signal is
>>>             OK for your application, just ignore the warning (it's
>>>             just a warning, not an error); if you think this is bad
>>>             for the signal you want to work with, I'd recommend
>>>             using a 50MS/s sampling rate -- that would have a
>>>             decimation of 4 and should work beautifully. Of course,
>>>             this means that your host computer would have to
>>>             implement the interpolation.
>>>             How wide is the signal you're planning to transmit
>>>             spectrally? Is it significantly less than 40MHz wide?
>>>>             When we increase the sampling rate to anything above
>>>>             40Msps, the following discrepancy is seen in the data.
>>>>             If you look at the above image there seems to be some
>>>>             missing data.
>>>             I can only guess here, but is it possible UHD printed an
>>>             "O" when you tried to transmit this?
>>>             That would imply that your computer was too slow to
>>>             supply the samples in real time, and since the USRP did
>>>             not have anything to transmit, there is a "pause".
>>>             Best regards,
>>>             Marcus Müller

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/5edb7a88/attachment-0002.html>

More information about the USRP-users mailing list