For mini the website states support for 10, 6 and 3 MSPS IQ output with a “6 MHz panoramic spectrum view” (that’s IMO a non-technical term). Firmware declaration stops at 6MSPS.
For R2 is 10 MSPS IQ output, but with a “10 MHz panoramic spectrum view with up to 9MHz alias/image free”. And is more confusing with “Up to 80 MSPS when using custom firmware”.
Wasn’t obvious to me and probably wasn’t to other people. I said “It can only use the 20 and 24 samples rates with the non-IQ output formats however.” and @prog said in reply “The IQ output works for all the native sample rates in both 16bit and float formats.”
I feel like I need to stop asking questions about the AirSpy because I only get incomplete answers.
The sample rate listing API reflects whatever sample type is set. By default, it lists IQ sample rates.
Note also that some sample rates are accepted but not listed because they have spurs. These can still be used in digital modes without problems, like ModeS/ADSB.
I was a bit surprised that the airspy wouldn’t do arbitrary sample rates, tbh. Is there a hardware limitation there (beyond spurs)? I kinda assumed at least on the R2 that you were using the si5351 to generate the ADC clock and that can certainly do arbitrary rates.
The Airspy radios are primarily designed for narrow band reception with high dynamic range scenarios in mind. In the VHF/UHF bands, the reciprocal mixing is the limiting factor, so the ADC and tuner reference clocks are derived either directly from the TCXO or have an integer ratio with the TCXO frequency. Even when it’s an integer ratio, not all ratios give the same spectral purity. For example, powers of 2 give better results than power of odd factors.
More specifically, in the case of the Airspy R2, the 20MHz ADC clock is generated directly in the Si5351 with the PLL configured in integer mode and a narrow bandwidth, followed by a cascade of power of 2 dividers. The clock signal is then routed directly to the ADC without passing through the noisy PLL in the MCU. To generate a lower rate (5MHz), this same 20MHz clock signal is divided with a programmable clock divider within the MCU. The other unlisted rates use the internal (noisy) PLL in the MCU and do not give the same level of performance. That’s why they are not listed in the first place. Finally, to generate the clock of the tuner itself, the Si5351 acts like a clock buffer and no PLL is involved. This means the same 25MHz TCXO clock is routed to the tuner to avoid introducing any unnecessary phase noise.
For the Mini, a single 24 MHz TCXO is used to provide the reference clock for the tuner and the MCU. This clock is then divided by 2 or 4 to give the supported sample rates.
Note that the clock division by a power of two not only doesn’t deteriorate the signal, but also reduces the phase noise by 3 dB every time you divide by 2, which is a desirable property.
Of course, for ModeS/ADSB these spectral purity specs are largely overkill by many orders of magnitudes than what is needed. So, I can imagine that generating 2.4 MSPS (4.8MHz ADC clock) should still give some useful results.
Ok. Not really familiar with the internals of the MCU you use. Given that it sounds like it’ll accept an external ADC clock from the 5351 on the R2, is generating arbitrary sample rates as simple as programming the 5351 to generate that rate? That would be a nice feature to expose in the host lib. (I’m familiar with the 5351 so I’m aware of the integer/fractional tradeoff there)
It’s always going to be a bit ugly dealing with digital modes if you can’t set arbitrary sample rates. for example, for UAT (dump978-fa) support, that’s probably always going to want a multiple of the UAT bitrate, which is the rather awkward 1.041666MHz (25/24 MHz). Yes I guess you could sample at some other rate and do a rational resampler in software but… ow…
It’s not easy. The same input clock also generates the core, bus and USB clocks using different PLLs. The procedure to change the input clock while everything is “live” is not easy and may require a reset.
With my experience from digital audio, a software resampler can be done cleaner (and less costly) than a hardware one.
Probably here is the same.
How about something like this: Signal Conditioner - GNSS-SDR
Back to the decoder subject. I think it’s way easier to use the current sample rates because they are nice multiples of 2 MSPS. Extracting the right phase should be straightforward.
Yes; the current sample rates are fine for 1090MHz in the medium term. It doesn’t help gtj0 immediately though since such a demodulator doesn’t exist yet, unless you’re willing to release the airspy_adsb demodulator under an open source license. The original 2MHz demodulator that dump1090 uses performs a lot worse than the current 2.4MHz one. I do have a bunch of new demodulator work in progress for higher sample rates that is looking promising but it’s not in a releasable state yet.
(keep in mind the original scope AIUI was “add airspy support to the existing dump1090-fa SDR infrastructure” not “implement a new demodulator to account for the airspy’s quirks”)
