Replacing the MiniTiouner

[SkyVision]

You're on the money Rob, Leandvb is already in Portsdown, but is it the lastest and greatest version, does Rpi5 help in any way here

Here's some quotes from the history of Leandvb:

"leandvb is a complete DVB-S and DVB-S2 receiver, but it's not based on GNU Radio. gr-dvbs2rx is
really just a showcase for the software LDPC decoder developed by xdsopl (also used by leandvb) is not even close to a complete receiver"

"Thx to f4hkw/f4exb integrating DVB-S receiver in SdrAngel. This plugin uses amazing leandvb project from Pascal F4DAV"

"It seems there has been progress concerning DVB-S2 on lean SDR probably motivated by QO-100 transponder
it seems that the DVBS2 engine used (Lean DVB) needs a high SNR"

"Pascal F4DAV says Time to make a decision poll, Should I:
- Invest in proper test equipment and try to fix these downconverters ?
- Learn microwave black magic and build my own coherent hardware ?
- Or give up and go back to the software world, e.g. finishing leandvb ?"
Troubleshoot and fix 12.7%
Design own hardware 72.7%
Go back to software 14.5%"

The guy that developed xdsopl has gone on to sending pictures over a Narrow Band form of Cofdm
Lobbying F4DAV might lead to improved leandvb

Cheers Roger VK5YYY

[SkyVision]

Pascal F4DAV said he's too busy at the moment and kindly suggested to check out
www.github.com/igorauad/gr-dvbs2rx
Which is GNU flavoured, works with USRP, bladeRF, ADALM-PLUTO and RTL-SDR
A fork of drmpeg's gr-dvbs2rx project
Including the BCH decoder from aicodix/code
SIMD-accelerated LDPC decoder from xdsopl/LDPC
Overview here:
https://www.youtube.com/watch?v=qcqvfElQUVk

leandvb 1.4 with DVB-S2 support or SDRangel is as good as it gets with this route, unless someone pimps one of them up

Cheers Roger VK5YYY

[G8GKQ]

A progress report (in case you thought that nothing was happening).

We may have found a source for the 3 ICs used in the existing tuner (the LNA, the tuner and the demodulator) and we are investigating how we might source suitable PCBs and get the boards assembled. There is lots of activity going on behind the scenes in these commercial negotiations - we'll pass on further news as soon as we need help or have something that can be publicised.

In case these efforts come to nothing, has anyone tested an SF8008 on QO-100 with the latest firmware? That would give us an idea of whether the tuner used in that system is an alternative option.

Lastly, has anyone done any rigourous performance comparisons between a MiniTiouner and a software solution such as SDRAngel? It would be useful to know exactly what the performance difference is.

Dave, G8GKQ

[M0LNG]

I have been making some progress with tweaking the SF8008.

It was a slow start, because of the need for a lot of reverse engineering, but I've now deciphered much of the relevant kernel module, and I'm able to make some functional changes by patching instructions in the compiled code.

I am working on modifying three aspects of the SF8008 firmware, as follows:

• Widening the supported tuning range. As standard the SF8008 only covers 950-2150MHz, but the datasheet for its RDA5815M tuner IC indicates that it should be capable of reaching down to 250MHz. Achieving this is not relevant to a potential MiniTiouner replacement, as we'd be using a different tuner IC, and indeed likely an additional frontend mixer. However, it would be very nice to be able to use the SF8008 directly in a QO-100 setup with a standard LNB output in the 741-749MHz range, and I wanted to have a go at making that possible. I've patched out software limits at 950 and 925MHz in two different layers of the code, and with some help from Mike MM0MZW (who figured out some of the I2C registers which relate to mapping frequencies to VCO/PLL configurations, and some clever rewriting of an awkward instruction sequence) also removed a third limit at 900MHz in the register settings. The result currently is that we can now successfully receive DVB-S2 signals as far down as 883MHz. So far this is about the same result achieved last year by Manfred DL1JM. We think we should be able to go down further though, using some trial and error to set the right dividers. We've put together a test setup using a near-field probe over the RDA5815M chip to watch for changes in the VCO and LO frequencies in response to I2C commands.

• Reducing the range of the automatic frequency correction on the Si2166D. This is the feature which I believe causes the SF8008 to jump to strong nearby signals, making it impractical to use on QO-100. Finding the right way to change this on the SF8008 has taken me a bit longer than the tuner work, because the demodulator configuration is a lot more complicated, and although we have the source for the SiLabs reference code, that code supports a lot of different compile-time options, and is not quite the same version used in the module. However, I've now finally found the right configuration to make the data structures make sense, and I can see where this option is being set. The module configures the Si2166D with a fixed automatic frequency correction range of 5MHz, which is obviously no good for RB work. I can now patch this value to something lower, and then if we run Dave's requested test with mixed-strength 333kS/s signals at 500kHz spacing I expect a much better result than in the past. Unfortunately I'm now away from the lab for a couple of weeks, so I can't run this test right away.

• Supporting frequency input to 1kHz resolution. This has caused some confusion, because at one point it was done, but the feature is not present in any current version of the firmware. As far as I can tell, what happened is that in 2019, Octagon produced a build of the OpenEight firmware that supported 1kHz input through the UI, at the request of OE7DBH. The change was not present in normal OpenEight builds. The special build circulated on forums for a while but all the links to it are now dead. Mike G0MJW has supplied me with a copy of this which he had retained, but it doesn't work on my unit; it installs OK, but when booted it gets nowhere and seems to wipe the whole flash including the recovery partition and other installed images! The change was not much help back in 2019 in any case because of the jumpy tuning behaviour, but now that I have a probable fix for that, it would be helpful to have a firmware supporting 1kHz input from the UI. However, as far as I'm aware this is purely a UI change, so should be easy to reproduce by modifying the relevant UI code, which is all fully open. I've confirmed now that the low-level kernel code all supports 1kHz resolution, so no changes should be needed there.

So to conclude: I'm still hopeful that the Si2166D will prove to be a viable demodulator option for a new board if the STV0910 doesn't work out, and I'm close to being able to demonstrate that, using the SF8008 as a testbed. And also tantalisingly close to making the SF8008 a viable QO-100 receiver on its own!

[G8GKQ]

Martin

Thanks for the progress report on the SF8008. Sounds really hopeful. There are a lot of these receivers around, so the work will be worthwhile even if we do come up with a reproduction of the current tuner.

Dave

[SkyVision]

Thanks for the update Dave, been thinking about how to perform a shoot out of Software, SDRs and methodology

First - Are Leandvb, Portsdown Leandvb, SDRangle and DVB-S gui all the same behind the curtain or is there differences, best/easiest wins?
Is gr-dvbs2rx worth a look, but that's not a windows thing yet as far as I can tell

Second - What devices do people have and should be tested, RTL dongles are common/Airspy/Lime/Hackrf or maybe a benchmark device

Third - What bands and symbol rates, fec and modulation should be used
10/6/2M/70cm/23cm/13cm
Low, middle and high symbol rate at what fec
QPSK and 8PSK

Forth - Test bench layout: Modulator->Attenuator or Noise Source->Splitter->Minitiouner/SDR...... or real world broadcasting/other
Outcome quoted: as Dbm to achieve stable pic, or Dbm to achieve Mer level, or just Minitiouner Xdb better than dongle

That's alot of variables and more questions than answers, but a shortlist or sticking to the original "mission" would be good
Minitiouner is going to beter, but SDRs and PCs are freely availble and are becoming staples of DATV
SDRs may have a band that shines, or with filtering and LNAs may get close to the mark
Above all if Rx SDRs allow more entrants into DATV it's a no brainer to at least investigate

If anyone could comment on the above that would be great and hope the higher level exploration gets somewhere positive

Cheers Roger VK5YYY

[g0mjw]

I have been making some progress with tweaking the SF8008.

It was a slow start, because of the need for a lot of reverse engineering, but I've now deciphered much of the relevant kernel module, and I'm able to make some functional changes by patching instructions in the compiled code.

So to conclude: I'm still hopeful that the Si2166D will prove to be a viable demodulator option for a new board if the STV0910 doesn't work out, and I'm close to being able to demonstrate that, using the SF8008 as a testbed. And also tantalisingly close to making the SF8008 a viable QO-100 receiver on its own!

Great progress. I wonder if there are different hardware versions and my firmware was for my older version and newer firmware works with both? That's quite common if things like flash chips change. If it is just a UI limit, then that's great. The UI we have is not suitable anyway, we need something more flexible for amateur use. The AFC range explains the hopping. Setting that to something low would be a solution. As the RX only seems to work down to 150kS or so, 100kHz might be a useful setting, as long as we know the LO offsets are less than this.

I can test, but it might be better to send my SF8008 to Dave as work dictates I won't be able to do anything before Christmas.

Mike

[g0mjw]

Thanks for the update Dave, been thinking about how to perform a shoot out of Software, SDRs and methodology

First - Are Leandvb, Portsdown Leandvb, SDRangle and DVB-S gui all the same behind the curtain or is there differences, best/easiest wins?
Is gr-dvbs2rx worth a look, but that's not a windows thing yet as far as I can tell

Second - What devices do people have and should be tested, RTL dongles are common/Airspy/Lime/Hackrf or maybe a benchmark device

Third - What bands and symbol rates, fec and modulation should be used
10/6/2M/70cm/23cm/13cm
Low, middle and high symbol rate at what fec
QPSK and 8PSK

Forth - Test bench layout: Modulator->Attenuator or Noise Source->Splitter->Minitiouner/SDR...... or real world broadcasting/other
Outcome quoted: as Dbm to achieve stable pic, or Dbm to achieve Mer level, or just Minitiouner Xdb better than dongle

That's alot of variables and more questions than answers, but a shortlist or sticking to the original "mission" would be good
Minitiouner is going to beter, but SDRs and PCs are freely availble and are becoming staples of DATV
SDRs may have a band that shines, or with filtering and LNAs may get close to the mark
Above all if Rx SDRs allow more entrants into DATV it's a no brainer to at least investigate

If anyone could comment on the above that would be great and hope the higher level exploration gets somewhere positive

Cheers Roger VK5YYY

Simplfy. DVB-S2 333ks QPSK 1/2 or 1/4 will probably tell us what we need to know. The high FEC will be the most challenging for software and sync. Forget the 8 bit RTL dongles and HackRF, we wouldn't know what was limiting the performance. I would use something like a Pluto or Lime or ideally an ETTUS USRP. However, for these tests, there is no need for an SDR at all. All the RF side could all be simulated in GNUradio. This would also allow you to speed up or slow down time and to run multiple receivers at the same time with the same channel sample and thereby compare each with exactly the same signal.

Mike

[G8GKQ]

Hi Roger

Portsdown LeanDVB is a very early version that only works for DVB-S. There is no point in including it in the comparisons; I would attempt (CPU requirements permitting) to replace it with the preferred version when investigations are complete.

As Mike says, the testing should ideally be done with one of the better SDRs. LimeSDR, Pluto, Airspy, SDRplay, HackRf or USRP would all be suitable as long as they were operating in the sweet spot of their dynamic range. However, given that we are dealing with a noisy signal, I would not expect the eventual performance to be that much worse with an RTL-SDR - it would just be more difficult to make accurate measurements.

The tests should focus on DVB-S2, 333 kS FEC 1/2 QPSK at low MERs. This is in the middle of the most common use-cases.

Mike's idea of initial testing using a GNU-radio generated signal is valid, but I would also want to see the results when the frequency and signal level uncertainty often involved in real-life reception is present. Further testing would also need to be conducted with equal or stronger level signals at 500 kHz spacing either side of the desired signal.

I hope that reduces the number of variables for you.

Dave G8GKQ

[g0mjw]

Mike's idea of initial testing using a GNU-radio generated signal is valid, but I would also want to see the results when the frequency and signal level uncertainty often involved in real-life reception is present. Further testing would also need to be conducted with equal or stronger level signals at 500 kHz spacing either side of the desired signal.
Dave G8GKQ

This was my point - it might have been better to say work on recorded channel sample so that is it the same for each implementation. We can perhaps generate some test signals, satellite and terrestrial, representative of what would be received in practice.