Transmit spurious signals

[laurencebarker]

Hi Pavel

Firstly, this is largely for my education and isn't going to be a problem to me I can't solve! I'm keen to understand if I can.

I have been looking at the transmit spurious signal level for the sdr_transceiver and sdr_transceiver_hpsdr projects. For the HPSDR one, I used pihpsdr and power_sdr_mrx in "tune" mode to generate a TX signal; for the sdr_transceiver project I used gnuradio and your trx_ssb project and replaced the audio source with a sinusoidal signal generator. I have a Rigol spectrum analyser.

I expected to find harmonics and image signals from the Fs=125MHz sampling process. I had found some additional spurious signals in the HPSDR project, and speculated that these might be artefacts of the sample-rate-converting filters. So I've now run the sdr_transceiver project (which doesn't have those filters) and found the exact same spurious.

For a wanted signal at frequency Fc: I'm also getting spurious at Fc+17.85MHz and Fc-17.85MHz at about -49dBc. (the exact frequency would need more careful measurement than I could easily do tonight). That's consistent for a wide range of wanted signal frequencies. 17.85MHz corresponds to Fs/7, which is a weird number to get.

Can you think of any reason why there would be artefacts related to Fs/7? that's a really unusual multiple to come across.

Obviously I can easily filter these out with a bandpass filter; they won't cause me a problem. I had expected that there would be something related to those sample rate converting filters, and I was thinking of experimenting with a "hybrid" project with the sdr_transceiver FPGA DSP and a 122.88MHz externally provided clock; my reason to be doing this at all is to learn FPGA development. But I like to understand problems before diving in, and I can't see anything in the xilinx documentation suggesting processing at 1/7 of the clock rate.

By the way - your code is great; thank you for writing it and providing it. Anyone that wants to experiment with HF radio algorithms in gnuradio will find your code + Red Pitaya a great environment. My wife is impressed that the Redpitaya only cost 25dB£.

Laurence Barker G8NJJ

[pavel-demin]

Hi Laurence,

It's great that you can check the TX part of the transceiver projects with a spectrum analyzer. It's something what I always wanted to test but I didn't have the necessary equipment.

Since sdr_transceiver and sdr_transceiver_hpsdr produce similar spurious signals, I'd suspect that the problem is located somewhere near the DDS module.

As a starting step in debugging this, I'd propose to make a very basic FPGA configuration with just the DDS module outputting a fixed frequency sine waveform directly to OUT1 and check the signal with a spectrum analyzer. What do you think?

Best regards,

Pavel

[pavel-demin]

Looks like I have already a project with all the necessary components:

https://github.com/pavel-demin/red-pitaya-notes/tree/master/projects/dac_test

I've just built a couple of FPGA configurations with the different noise shaping configurations.

Here are the commands to download them and to configure the FPGA:

wget https://www.dropbox.com/sh/5fy49wae6xwxa8a/AAAs7iQHtnse8a1eBWvHRdEJa/dac_test/dac_test_taylor_series_corrected.bit?dl=1 -O dac_test_taylor_series_corrected.bit
cat dac_test_taylor_series_corrected.bit > /dev/xdevcfg

wget https://www.dropbox.com/sh/5fy49wae6xwxa8a/AAAW35s5W3aYMKvxs9x0gdDba/dac_test/dac_test_phase_dithering.bit?dl=1 -O dac_test_phase_dithering.bit
cat dac_test_phase_dithering.bit > /dev/xdevcfg

The output frequency is set to 14 MHz.

[laurencebarker]

That sounds like a good idea. It will probably take me a couple of days, but I will try that. I think something is going wrong with every 7th sample, as if the output word is being multiplied by a value related to the 8th bit (eg 11111011111111).

Thank you!

Laurence Barker

[pavel-demin]

A couple of observations...

I've just checked the spurious signals using sdr_transceiver_hpsdr and PowerSDR mRX PS.

The frequency of the tune signal is 21.2000 MHz.

The frequency of the spurious signal is 39.0527 MHz.

(39.0527 - 21.2000) 7 = 124.9689 MHz (39.0527 - 21.2000) 8 = 142.8216 MHz

I'd say that 124.9689 significantly differs from 125. Normally, the frequency deviation of the on-board 125 MHz oscillator is within 2-3 ppm.

However, 142.8 MHz is also present in the sdr_transceiver_hpsdr configuration. This frequency is generated by the ZYNQ PS PLL and is used to clock most of the FPGA logic.

Here is how ZYNQ PS PLL generates 142.8 MHz:

33.333 * 30 / 7 = 142.8557 MHz

I don't know what is the frequency deviation of the on-board 33.333 MHz oscillator. I'll try to measure it.

[pavel-demin]

I've built a modified FPGA configuration for sdr_transceiver with all the FPGA logic clocked from the 125 MHz oscillator. The TX signal is much cleaner now.

sdr_transceiver before the modification:

sdr_transceiver after the modification:

Here is a link to the new FPGA configuration:

https://www.dropbox.com/sh/5fy49wae6xwxa8a/AADoCQp9SvGXvEssxuA6uUeJa/dac_test/sdr_transceiver_test.bit?dl=1

[laurencebarker]

OK, I've been able to run all of the new configurations. (I assumed I'd have to edit and build them, which would have taken longer).

The first two, with just the DDS: no evidence of the +/- 17.85MHz spurious signal. there are some minor line spurious on the first build; reduced in level on the second one. Here are some screen shots.

The first FPGA build:

The second FPGA build - cleaner near to the noise floor:

Finally the new sdr_transceiver build, also generating a 14MHz signal from gnuradio:

I'd say making the whole FPGA synchronous to the 125MHz clock has fully solved that problem. I never liked asynchronous code!

The spurious signal levels are now comparable with those I had from my hpsdr "Penelope" board. The noise floor may be very slightly higher but I'd have to go back and re-measure carefully to be sure of a measurable difference; if there is a difference it may be because of the 14 bit DAC, or possibly clock quality. But the unexpected line spurious are completely gone.

Thank you Pavel for a very rapid fix!

Can the HPSDR have the same change too - or does than need the higher clock rate?

[laurencebarker]

Sorry, should have added - the "large" spurious signal present are harmonics. They are comparable with the level of the harmonics in the HPSDR product.

[pavel-demin]

Many thanks for testing all the new FPGA configurations. It's good to know that the DDS module works fine and that clocking the FPGA logic from the 125 MHz oscillator completely solves the problem of the spurious signals.

The next step for me will be properly coding the changes that I've done for sdr_transceiver.

The same solution should also work for sdr_transceiver_hpsdr. All other projects should be also updated.

[pavel-demin]

Here are two commits that I think should replace the 143 MHz FCLK_CLK0 clock with the 125 MHz ADC clock in sdr_transceiver and sdr_transceiver_hpsdr:

https://github.com/pavel-demin/red-pitaya-notes/commit/d3f671f5ce98b6923af6090856037d69a851a087 https://github.com/pavel-demin/red-pitaya-notes/commit/269fd947ea3d06e0e41338c35bd1be1fee0a3c17

And here are the corresponding .bit files:

https://www.dropbox.com/sh/5fy49wae6xwxa8a/AADXn1_E3c9Wai3RDJOrgxgLa/dac_test/sdr_transceiver_new.bit?dl=1 https://www.dropbox.com/sh/5fy49wae6xwxa8a/AADY8WF2n3sn8yhqBSEp09m6a/dac_test/sdr_transceiver_hpsdr_new.bit?dl=1

Currently, I don't have my Red Pitaya around to test these new versions. I'll test them in about two weeks.

[ka6s]

Pavel - I will try to give them a try this weekend - I'm not set up to observe any spurs - but I can at least tell you whether the hpsdr.bit file is working...

Steve

[laurencebarker]

Pavel

I've been able to test the transmit RF performance. I'd class them both as "fully fixed". Here are some plots from my spectrum analyser:

sdr_transceiver_sdr.bit, pihpsdr "tune" 7MHz band:

sdr_transceiver_sdr.bit, pihpsdr "tune" 21MHz band:

sdr_transceiver.bit, gnuradio:

On all plots there are harmonics: I assume these are from the buffer amplifier on the RedPitaya after the DAC itself. But the other spurious signals are fully gone. This is now what I'd regard as a "clean" one. thank you Pavel!

Steve: I'm unable to test the other I/O signals, which I think you have connected up.

Laurence Barker G8NJJ

[ka6s]

I'll give it a go this weekend.

Steve

[kraum]

Dear Pavel,

Getting rid of the spurs in the output signal would be a great improvement of your application. Unfortunately it seems that the fix does not work with hpsdr. I tried to run the sdr_transceiver_hpsdr. bit file provided above but it does not work with openHPSDR (v3.4.1). It is possible to connect to the redpitay but no valid receive data is received. When I use the tune button the connection to redpitaya is lost and no signal appears at the output. Afterwards it is not possible to reconnect to the redpitaya without rebooting the redpitaya. After trying the provided .bit file I created a new bit file and server application with the modifications shown in 269fd94 but observed the same with these files.

With best regards

Klaus

[pavel-demin]

Dear Klaus,

Thank you for your tests.

I can confirm that the sdr_transceiver_hpsdr_new.bit file from my previous comment doesn't work. As promised, I tested it a few days ago and obtained the same symptoms as you describe.

The good news are that the latest version of the sdr_transceiver_hpsdr code in the master branch works. I'll update the SD card .zip file soon.

Best regards,

Pavel

[ka6s]

Pavel,

We DO know that in PiHPSDR we have a call to start metis twice - and with that if we comment out the second start - your code works.

This has something to do with the start sequence specifically.

Steve

[pavel-demin]

I've just updated ecosystem-0.95-1-6deb253-sdr-transceiver-hpsdr.zip.

The main improvements are

• fixed the transmit spurious signals
• better interaction with the PureSignal algorithm (it now works with the default SetPk value)
• updated board ID as suggested in #501

[pavel-demin]

We DO know that in PiHPSDR we have a call to start metis twice - and with that if we comment out the second start - your code works.

The sdr_transceiver_hpsdr_new.bit file from one of my previous comments didn't work with PowerSDR mRX PS. The problem was in the FPGA configuration. This is now fixed in the latest version.