Hi,
Most widebande receivers are using RX888 on HF, with 30Mhz bandwidth.
Max bandwidth is set by ADC capabilities AND connectivity.
If data samples transfered are through 1Gbits Ethernet, for example, we have a limit of bandwidth with :
1e9/(8bits*NbBytesPerSample*2) : if you have 16bits ADC (2 bytes for I and Q ): max bandwidth is
1e9/(8*2*2) = 31.25 Mhz. As there is generally some margin with theory , 30Mhz could be achieved.
Monitoring other band could be interesting like VHF/UHF.
Some PlutoSDR clone (pluto+/antsdr e200) could get from 50Mhz to 6Ghz central frequency.
ADC is 12 bit , which is transfered as 16bit by sample.
So result bandwith should also be around 30Mhz.
Due to CPU inside the Pluto itself used for transfering samples, only 20 Mhz is possible without sample lost.
If the target is wideband, we can use only 8 bits per sample instead of 16.
As this conversion requires some computation on the pluto itself (just a bit shift),it is not possible at high samplerate.
That's why I put this on FPGA side, resulting in a special firmware.
Of course, we loose a lot of dynamic (4 bit*6db)...but we win bandwidth over network.
For now, 46 Mhz bandwidth seems stable ! (Yes theory should be 1e9/(8*1*2)=61Mhz)
Result is on http://qra.f5oeo.fr:9002/ not already available as it is in development.
As there is less dynamic, it seems very poor, but you can still listen full aero band, 2m ham radio and more.
Hope that explain more what is the target and the drawbacks.
Let me know if you have any interest in it, or any question.
73
Evariste F5OEO
Ok, now I understand.
However, it's not 2 bytes for I/Q, but 16bits for both.
And that makes things worse.
But for the 8-bit output you make a mistake, it's not because you transfer 8 bits that the dynamic-range is 8-bits.
As you can clean the errors, calculate etc, making your Pluto 8bit ENOB.
This means the range is far greater then an 8bit RTL that is 7 ENOB at best.
Also you can vary the gain, making it even better, by making it change the noise-floor....and on top, big signals can be cut.
In FM this will not work, but in AM/SSB it does. Giving it a far better 8-bit performance then an 8bit RTL-dongle.
It all depends on the modulation-type....with FM and CW you are screwed on high range....with SSB/AM-phone, you are not.
With SSB you can have high range, even with limited bits, AM same....FM/CW...nope.
Let me explain....on 8 bit you have 0-256 values, but the receiver is 12 or even 16bits...what you can do on big signals is cutting the big hz-samples to maximize at 256, even is they calculated have 512 as value, just max them. It's only the peaks that hit this.
By maxing them, the don't go over, and you will not hear the difference. As such you can extent the range a lot.
Again it depends on the modulation....FM/CW doesn't have samples that are low/high, all levels are the same...as such it will not work, then you need more bits.
I did bit-peak-cutting, just removed them from processing....worked well...nobody noticed.
After rewriting complex 12 to complex 8bits with rounding, it seems much better. Should be interesting to have a WideFM button to listen FM broadcast instead of resize the bandwith of narrow FM.
Thanks for your feedbacks.
Works well, FM 3m band...but you need to reduce the gain in the TOML, I would say 20 points...
Other then that....NICE ;)
You can change the FM button in the code to do 100KHz wide....
I can't find spectrum gain in toml file ? Any link ?
In .toml file search for "brightness_offset=" and for s-meter "smeter_offset="