discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LimeSDR | Sinewave test | Glitchy behavior


From: Jeff Long
Subject: Re: LimeSDR | Sinewave test | Glitchy behavior
Date: Thu, 18 Mar 2021 10:31:14 -0400

Then it's most likely a performance thing. Check the processor utilization (top with threads mode). The RR is probably maxed out trying to upsample. There's a FIR at 12 MS/s implied there.

On Thu, Mar 18, 2021 at 9:43 AM Christophe Seguinot <christophe.seguinot@orange.fr> wrote:

Hi all

There is something wrong in this simulation.

Attached is a flowgraph with a selectable Lime SDR Source, and a RTL-SDR dongle as receiver. I tested this with a Lime SDR Mini.

  • I was suspecting a Lime SDR issue, however this is not so clear.
  • As Anish I also tested a const source.
  • The flowgraph is running fluently and I dont' see any error message about transmission to Lime SDR

Conclusion of my simulations :

  • with a const source (=1) at Lime input : everything is OK, the received signal is frequency shifted (normal) and the SNR is correct if LimeSDR Gain is sufficient
  • Using ratioanal resampler followed by WBFM Transmit Same reslt, everything is OK
  • First source+ WBFM + Rational resampler (this is a sample file found on LimeSDR website
    • the spectrum is not correct (look like  a modulated signal
    • the received signal magnitude is not constant
    • BUT the send signal on the Time Sink look like correct. ( I.E =1+j0 as for others sources, whitout any glicht)

How can we further investigate this?


On 18/03/2021 13:13, Anish Mangal wrote:
And, if I try the attach gnuradio file, which is just a constant source of value '1' going to the limesdr sink block, I actually see a sine-ish wave without the glitchy behavior.

On Thu, Mar 18, 2021 at 5:31 PM Anish Mangal <anishmg@umich.edu> wrote:
I tried your grc and got the same result.

See the waveform's envelope in this oscilloscope capture. Note the timebase.

This isn't happening in SDRAngel.

On Thu, Mar 18, 2021 at 3:49 AM Cinaed Simson <cinaed.simson@gmail.com> wrote:
I moved the rational resampler block from the output side to the input side of the WBFM.

The output of WBFM block needs to match the input of your LimeSDR.

I don't have the LimeSDR software installed so I couldn't look inside the sink block.

-- Cinaed

P.S - yes, you can post GRC's on the mailing list  - they're text based.


On 3/17/21 4:14 AM, Anish Mangal wrote:
I linked the grc file in the original email. Attaching it here as well. (Don't know if the mailing list allows attachments)



On Wed, Mar 17, 2021 at 1:40 PM Cinaed Simson <cinaed.simson@gmail.com> wrote:

Hi Anish - since this is a gnuradio mailing list, the starting point would be to post your GRC - which is an yaml or text file.

-- Cinaed
 
On 3/16/21 11:19 PM, Anish Mangal wrote:
Hi! Any pointers to where I can start debugging this?

Maybe run gnuradio-companion in debug mode?
Do more simpler tests?
Any other suggestions?

I have a HackRF One and will try the exact same comparison there too ... SDRAngel & grc

On Mon, Mar 15, 2021 at 7:32 PM Anish Mangal <anishmg@umich.edu> wrote:
Hi,

To properly explain the issue I'm facing, I recorded a video showing Oscilloscope waveforms. 


The gnuradio flowgraph is here:

The various versions of the software/hardware involved are the following.

gnuradio-companion: 3.8.2.0 (Python 3.6.9)
gr-limesdr: branch gr-3.8 (last commit 47511dd58de1695b70e1028366411bada85eb60f)
sdrangel: 4.12.1
OS: Linux Mint 19.1
CPU: Intel© Core™ i7-4900MQ CPU @ 2.80GHz × 4
RAM: 16GB
H/w: Thinkpad T440p

tl;dr
I'm trying a simple test to create a sinewave output from a WFM modulator block. If there is no audio input, its WFM modulated signal should be a simple sinewave. If I test this with SDRAngel, I see a clean-ish actual sinewave in time domain on the oscilloscope. But if I try to do the same with gnuradio, it seems to produce a glitchy signal.

Could I have any advice on what I might be doing wrong?

Thanks,
Anish // VU2TVE



reply via email to

[Prev in Thread] Current Thread [Next in Thread]