[Avian] has been using STM32 ARM processors to sample RF for a variety of applications. At first, he was receiving relatively wide TV signals. Recently, though, he’s started dealing with very narrow signals and he found that his samples had a lot of spread in the frequency domain that he didn’t expect.
What followed was some detective work that resulted in a determination that phase noise was the culprit. But why? [Avian] took some measurements and noticed that the phase noise almost exactly matched the phase noise specification for the STM32’s phase locked loop (PLL).
Unfortunately, there didn’t seem to be a good way to avoid using the PLL without major changes to the rest of the circuit. However, it was quite the learning experience and something to be aware of when counting on built-in converters for high-accuracy measurements.
One of the best things about this post is the references to more information. There’s a great explanation of phase noise, as well as a specific application note about clock jitter and analog converters.
We’ve talked about phase noise in direct digital synthesis a few times. But usually, it is pretty obvious like when you are asking a CPU to double as an RF transmitter. [Avian’s] post was a bit more of a detective story.
Hey, small correction (by the way, how to reach out to the editors for those? Do it here? Feels a bit like spam. But there’s no email address to do it directly?):
He was not first receiving relatively wide TV signals – he was receiving _TV Whitespance signals, i.e. signals that reside within places where there used to be analog TV channels.
In particular, he mentions wireless mics – those seem to be “relatively wide” compared to what he “does for the institute”, but at maybe 75 kHz to 100 kHz, they are definitely still pretty narrow compared to 6 MHz to 8 MHz TV channels.
I find the radio platform that he has made really nifty, reusing a terrestrial TV receiver frontend. You could make your own portable little SDR.
I have looked at the chip from NXP, but their product datasheet has no I2C register definitions at all! Really irritating, had to google around to find the datasheet but come on. There are no nefarious purposes for such a device, but still they keep it a secret.
This is one the reasons Low-IF is used in good receivers vs. Zero-IF, but then you have to do the that final down conversion digitally and you loose some of your channel bandwidth. For a great narrow-band receiver, that is what you are going to do though. For a really wide signal like WiFi OFDM (802.11AGN), the sub-carriers located around zero are not even used and replaced with a null instead, so doesn’t really matter.
Well, I haven’t finished reading the article, I hope to do so when I have more time, but phase noise is a new concept to me…
For me the concept is well known, but I did not think of it in the context of CPUs. It played a major role in my diploma thesis project. But when I read about the PLL in the chip, all was clear.
If I recall from some STM32 Application notes (AN3988) to reduce PLL jitter you can calculate your dividers such that PLLVCO is close to 2MHz.
What chip is it if the PLL can’t be driven from HSE, that could go a long way to solving it as well.
Was an FFT window function applied to that first FFT plot? If so, which one?
Exactly what I thought. If he just used a rectangular window, the phase noise is not phase noise but leakage. But judging by his other articles, he sounds way more expirience to do this noob mistake…..
Just compared my simulation against that first FFT plot shown and it looks almost exactly like that with rectangular window. The actual ADC output is much better than that. I’d post some images comparing measured vs. simulated, but doesn’t look like this site supports posting images. That plot is almost certainly the result of using rectangular FFT window (no window at all) and thus much of the “phase noise” is spectral leakage in my estimation.
Did you try it with hamming (or similar) on actual data? Would love to see that.
If I recall from some STM32 Application notes (AN3988) to reduce PLL jitter you can calculate your dividers such that PLLVCO is close to 2MHz.
What chip is it if the PLL can’t be driven from HSE? If its possible that could go a long way to solving it as well.
Readers may be interested in this blog about jitter/phase noise:
http://www.edn.com/electronics-blogs/benchtalk/4430075/Jitter-and-SSN
Use a precision clock with an external S/H that leads the internal one. Or run your STM32 at 160MHz, if that lessens the PLL variation.