Yes, but only if you demodulate the full bandwidth.
It simply means: Don’t assume anything that is not explicitly given by the API. It’s not guaranteed to be there in the future.
Absolutely. If you want to decimate the stream and keep the center frequency tuned at the same time, you should also frequency-translate the real baseband data. This is what the IQ conversion routine in libairspy does for you (translate => decimate by 2).
The formula you gave me yesterday results in a frequency of 1092400000 but that seems to result in fewer decoded messages.
Right now, averaging the magnitude of 5 samples instead of keeping 1 of 5 samples gives me the best result with just simple math. I’m still exploring liquid-dsp, fftw, and a few others that have both x86 and arm accelerated code for filters, demod, decimation, etc.
This means you are not doing any decimation and the formula does not apply.
Sorry, I wasn’t clear. Using the formula, I was setting the frequency to 1092400000 and doing simple decimation by keeping 1 in 5. The other alternative was not using the formula and setting the frequency to 1090000000 and keeping the average of the magnitude of the 5 samples.
@prog Hardware question… Do either of the 2 ADC IN connectors happen to be bridged with ADCHS channel 0? I’m guessing “no” so if not, to which ADC and channel are they routed? Is there any place the IF appears that can be probed? I think the answer to that is “no” based on looking at the pinout but I just wanted to make sure.
Yes. If you think you need this information, you are probably in the wrong path.
I only wanted it so I could examine what I’m trying to process and understand a little more about its characteristics.
@gtj0 I applaud you taking this on against the current. This is how things mature, if it were easy, everyone would do it. It also shows just how much work has gone into what we use behind the scenes.
I was able to look at the IF on an rtl-sdr v3 dongle. I just needed to see for myself…
@prog
This is a little out of bounds for what’s being discussed here admittedly, but wondering since the Airspy R2 uses the si5351 (got into that a few posts prior), if signal drive strength was ever reviewed?
I ask because I use the si5351 for another project thats noise intolerant and noticed some pretty gnarly spurs as the drive level is cranked up on these chips (no, that’s not probe overshoot either):
So what? They can experiment and publish all they want. Some day they will figure it out. Business as usual.
Science >>>> Engineering >>>>>>>>>>> Hacking.
Get the book @obj suggested and read it to the end. We all went thru that very same book.
Understand what you are doing. “Community thinking” will only get you so far.
Practice with GNU Radio or any other framework (which incidentally all support Airspy and RTLSDRs)
Rince, Repeat
I’ve got the book but sometimes you just have to observe something in its natural habitat for it to sink in. Well, I do anyway. That’s why we have signal analyzers, oscilloscopes, spectrum analyzers and vector network analyzers. 
You also have a device that gives you the sampled IF without resorting to hacks… The SDR itself.
@prog You never answered my question about where the 2 ADC IN connectors are routed. Are they going to the other channels on the 12-bit ADC or one of the 10-bit ADCs, etc?
I also have a suggestion about the pinout diagram…
I have no clue what your response means or what it has to do with what I wrote. Maybe you need to read my post again?
To put another way - I was asking if you looked into the clock drive levels when building the firmware. The scope shots are mine from my own tests, was simply illustrating that higher drive levels create noise. I assume you don’t want noise in your products, I could be wrong. If left unchecked it defaults 8ma and you should be just fine with 2ma and lower noise if you aren’t already doing so. Trying to help man. I don’t see drive level being set in your firmware, perhaps I missed it.
EDIT: I think I did miss it previously, is this correct? It’s tabled, so tougher to dig up outside of remarks:
/* Respective value for register 0 to register 180
The registers are generated using a custom program that optimizes the phase noise by using the integer mode.
SI5351C Configuration details (XTAL 25MHz):
PLL_A = Unused
PLL_B = 25 MHz * 32 = 800 MHz
Channel 0 = 25MHz (Direct TCXO) R820T (Drive Strength 2mA)
Channel 1 to 6 = Disabled/Not Used
Channel 7 = 20MHz (PLL_B / 40) LPC4370 (Drive Strength 2mA)
*/
I’d be interested in the name of that application outside of using Si5351ClockBuilder
Nevermind. Yes it was obvious but I just glossed over it.
There is a tradeoff here because a lower drive level typically mean slower rise times and possibly more jitter. If that clock is going direct to the ADC then more jitter = more noise.
Look at AN619 if you haven’t come across it already. If you’ve got a simple set of constraints (e.g. only one or a small number of outputs) then it’s pretty straightforward to roll your own calculation from there.
Getting closer. Using a FIR before decimation is expensive though.
Time to look at a demodulator I think.
My latest code is here… https://github.com/gtjoseph/dump1090/tree/dev-airspy
If you want to test, here are the device-specific options I used…
--sample-rate 12000000 --enable-packing --linearity-gain 21 --sample-setup int16_real
airspy_adsb
Tot: 64 Vis: 64 RSSI: Max 0.0+ Mean -3.9 Min -14.1- MaxD: 211.7nm+
dump1090-fa w/ native airspy
Tot: 62 Vis: 62 RSSI: Max -10.0+ Mean -25.5 Min -33.9- MaxD: 211.7nm+
EDIT: One note about the results… airspy_adsb is running natively at 12ms/s where dump1090-fa is sampling at 12ms/s but decimating to 2.4ms/s.
Here’s another set of results with a NESDR Smart in the mix
airspy_adsb gain 21 12ms/s
Tot: 59 Vis: 59 RSSI: Max 0.0+ Mean -4.0 Min -13.0- MaxD: 241.5nm+
dump1090-fa w/ airspy_native support gain 21 12ms/s decimated to 2.4ms/s
Tot: 58 Vis: 58 RSSI: Max -11.4+ Mean -25.5 Min -34.6- MaxD: 241.5nm+
dump1090-fa rtl-sdr NESDR Smart gain 43
Tot: 58 Vis: 58 RSSI: Max -3.5+ Mean -19.1 Min -29.1- MaxD: 241.6nm+
