pavel-demin / red-pitaya-notes

Notes on the Red Pitaya Open Source Instrument
http://pavel-demin.github.io/red-pitaya-notes/
MIT License
339 stars 212 forks source link

Stemlab 128.88-16 Origin of TX spurs in 3rd Nyquist Zone and possible remedy? #1059

Open hb9ewy opened 2 years ago

hb9ewy commented 2 years ago

Description of the setup:

Description of the problem:

a) 192kHz I/Q data rate TX_RP16_192kHz_Spurs_IMG_5249

Steps to reproduce the problem:

Stemlab powered from analog DC power supply.

  1. tx a constant carrier in the 2m band. e.g. fundamental about 21.41.46MHz -> 144.34MHz in 3rd NQZ, level below fs.
  2. observe an measure surious emissions close to carrier. 145MHz bandbassfilter on output 1 or 2 followed by the SA. 10 dB attenuator directly on output did no change the relative spur level.
  3. vary the I/Q data rate: 48, 96, 192, 384 kHz.

I wonder what causes these spurs and why do they vary with the I/Q data rate (I assume this to be the rate of the the rx data stream). Is my assumption correct, that the tx I/Q data rate is always 48kHz?

Thank you.

pavel-demin commented 2 years ago

Thank you for the tests. I will try to reproduce this effect.

Is my assumption correct, that the tx I/Q data rate is always 48kHz?

Yes, the TX I/Q rate is fixed and it is always 48k.

hb9ewy commented 2 years ago

Thanks Pavel. With the TX I/Q rate always being 48 kHz I really wonder what makes the observed spurs to depend on the RX I/Q rate. May be crosstalk in the processing chain of the DAC clock in the HW or FPGA? Measurments of the signal are difficult, but I may try.

BTW, the fundamental signal has these spurs at better than -80dBc, measured at 10.7 MHz with a notch filter supressing the carrier. Yesterday night I measured TX in the 3rd NQZ on a modified Red Pitaya 14 Bit - spurs are stronger and there are more. The 122.88-16 is definitely cleaner.

For my application I consider to take the fundamental tx signal and upconvert it by the 122.88 MHz clock (using an older transverter which used an external 130MHZ LO).

hb9ewy commented 2 years ago

Hi Pavel, I had been in contact with DC9OE, and he experienced similar spurs, caused probably by an on board SMPS. BTW: the discussion with DC9OE is there: https://saure.org/phpBB_04/viewtopic.php?f=35&t=536&p=3168#p3168

SMPS Noise

FW Dependency

Because Edwin did not observed die dependency of Spurs on the RX I/Q data rate I tested the behavior with the oldest FW I found: red-pitaya-alpine-3.12-armv7-20200628.zip

So there may have been a FW change responsible for the new spurs. And because it increases the spurs (more and up to 10 stronger) it would be useful to fix, even if the presumably SMPS generated spurs still persist.

pavel-demin commented 2 years ago

Thank you for testing different versions.

Looking at the changes between 20200628 and 20210427, I think only the following changes could affect this SDR application:

hb9ewy commented 2 years ago

Hi Pavel, I looked already at these changes, but have too few knowledge about FPGA programming to understand them. For now I will use the oldest 3.12 FW and reduce the power supply voltage to reduce the SMPS spurs. The main issue for tx is high DAC clock noise. In the 3rd NQZ naturally it gets worse, I only measured about -110dBc at +/- 100kHz. I need at least 20dB better for 144MHz. NO chance with this HW. I hope the future releases of the HW will improve. Once HW has improved (which I hope it will) these spurs may need attention again.

Thanks for looking into this issue. For me it could be moved into the backlog or even closed.