Distortion above around 10 MS/s

Discussions related to schematic capture, PCB layout, signal integrity, and RF development

Moderator: robert.ghilduta

Post Reply
spcutler
Posts: 28
Joined: Fri Mar 01, 2013 3:12 am

Distortion above around 10 MS/s

Post by spcutler » Sun Mar 08, 2015 11:11 pm

I'm seeing some odd-looking distortion when I get much past 10 MS/s, and even at 10 I think there may be some. 8 MS/s is very clean.

Some illustrations of what's happening:
8 MS/s. Note the signals at ~932 MHz. They look pretty sharp and clean.
10 MS/s. Still looks pretty good, though the signals look a bit "wider" than before.
11 MS/s. Getting some very obvious (and problematic) distortion here. The signal is very spread out in frequency.
12 MS/s. It's really bad now. You can see lots of harmonic (?) peaks spreading out from the central peak.

Past that, it gets no worse (or better). But it's not usable at these rates.

I don't think it's any kind of bug in my visualization or anything. I see the same harmonics when I dump the raw samples and view them in Audacity. For instance:
16 MS/s in Audacity spectrum tool

Any thoughts? Thanks.

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Distortion above around 10 MS/s

Post by jynik » Mon Mar 09, 2015 6:26 am

Are you on USB 2.0? If so, 8-10 Msps is right about where the USB Hi-Speed bandwidth caps out (in reality), so it makes sense that you'd see artifacts due to discontinuities and dropped samples. Remember, the 24-bits of I and Q are packed into a 32-bit word.

If you look at samples in the time domain, I suspect you'd see discontinuities.

This wiki page might be helpful.

spcutler
Posts: 28
Joined: Fri Mar 01, 2013 3:12 am

Re: Distortion above around 10 MS/s

Post by spcutler » Mon Mar 09, 2015 1:16 pm

Ahh! That's gotta be it--thanks. I was indeed on USB 2.0. I didn't realize that the data was packed into a 32-bit word instead of 24 (I know the data gets to me that way, but that's not necessarily how its transmitted across the bus...).

Offhand, do you know if the timestamp field accompanying the BLADERF_FORMAT_SC16_Q11_META mode is effectively a sample count? That would allow me to detect if I'm getting dropped samples.

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Distortion above around 10 MS/s

Post by jynik » Tue Mar 10, 2015 7:31 am

spcutler wrote:Offhand, do you know if the timestamp field accompanying the BLADERF_FORMAT_SC16_Q11_META mode is effectively a sample count? That would allow me to detect if I'm getting dropped samples.
That's exactly what it is -- a counter that monotonically increases at the sample rate. When using that _META mode, the "overrun" flag should be set if such a discontinuity is detected, per a jump in the expected timestamp value.

spcutler
Posts: 28
Joined: Fri Mar 01, 2013 3:12 am

Re: Distortion above around 10 MS/s

Post by spcutler » Tue Mar 10, 2015 1:51 pm

Thanks. I took a look at this last night and I do see that the counter works, but I noticed that the docs say that the metadata is only decoded automatically in synchronous mode, not async (like I'm using). Well, that's no problem, I can deal with that.

The bigger concern though is that the header docs say that the first four samples out of every 1024 are overwritten with the metadata. Is that right in that the samples are lost completely? I certainly observe that out of the 32768 samples in a packet, each block of 1024 has the metadata at the beginning. It doesn't write a metadata block and then another 1024 samples; it writes the metadata and then 1020 samples.

So am I really just losing the samples? If so, that seems to be unacceptable. If instead the samples are just skipped, and I get slightly more packets per second than before, then that's fine by me. But that doesn't seem to be what the docs say (and I can't tell given my current software setup).

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Distortion above around 10 MS/s

Post by jynik » Tue Mar 10, 2015 4:48 pm

Hi there,

I think the documentation is just poorly worded here. If you wouldn't mind and have time, could you file a bug report and apply the "documentation defect" tag. I was hoping to spend some time with the Doxygen docs to add some more sample snippets, and I'll touch up the wording there.

So no, the metadata is not clobbering samples; no samples are being overwritten or lost.

On the RX side, the FPGA is just stuffing that metadata into a FIFO ahead of the associated block of samples. Similarly, on the TX side, it extracts the metadata, and then the samples that follow.

This file, from the cockles of libbladeRF should be helpful to you: metadata.h

Best of luck!
Jon

Post Reply