[USRP-users] x310 Master clock rate

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


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/35f531db/attachment-0002.html>


More information about the USRP-users mailing list