Difference in waterfall display using osmocom_fft

Discussions related to embedded firmware, driver, and user mode application software development

Moderator: robert.ghilduta

Post Reply
wpats
Posts: 9
Joined: Tue Aug 18, 2015 8:13 pm

Difference in waterfall display using osmocom_fft

Post by wpats » Thu Sep 17, 2015 8:06 pm

Hi,

I used my bladeRF x40 to observe a signal using osmocom_fft in waterfall displat mode. The signal of interest is spread almost evenly between around 746MHz and 756MHz and turns on and off intermittently. I see a difference in the waterfall display between using 24Ms/sec and 28Ms/sec sample rates. The former shows a nice blocked pattern in time. The latter does not show this clear structure and is diffused. This is the screenshot of the 24Ms/sec display https://www.dropbox.com/s/hqkv0hmmqlfhz ... 1.png?dl=0 and this is the screentshot of the 28Ms/sec displayhttps://www.dropbox.com/s/to6t7wkpiz8xt ... 2.png?dl=0 What is the reason for this difference ? The only parameter different is the sample rate. The time scale is the same. With the sample rate set to 20Ms/sec I see the same diffuse pattern. Only 24Ms/sec shows the accurate display. What is special about this ?

I would appreciate any explanation/help.

Thanks,

--Patrick

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

Re: Difference in waterfall display using osmocom_fft

Post by jynik » Fri Sep 18, 2015 7:41 am

I might recommend recording samples and looking at them in the time domain, as well as perhaps looking at them "offline" using baudline (or MATLAB/Octave). Essentially, I'd first try to determine if this just some behavior (aliasing?) that's isolated to the particular widget. (There are some instructions here regarding looking at samples recorded via the bladeRF-CLI in Baudline. Heck, you could also try a GPU accelerated waterfall like fosphor (video).

Another important thing to consider is whether you're encountering underruns. If your machine isn't keeping up with the sample stream (perhaps due to GUI widgets or DSP operations not keeping up). If you add 'verbosity=debug' to your Osmocom Source device arguments, you'll see a debug message if and when underruns occur.

Sorry this might not be terribly useful, but questions in the form of "this FFT doesn't look right" (which is a reasonably normal reaction) tends to be rather nebulous without being able to analyze and work with the baseband samples.

Best regards,
Jon

Post Reply