Roger, those devices look interesting but it all depends what can be made to work with RB signals in practice.
I just skimmed the M88RS6060 Linux driver code, and although the driver declares a 1MS/s minimum symbol rate, it might be that if you simply dropped that declared limit, the driver would happily feed the necessary parameters to the chip and go lower. The only way to know for sure would be to get the hardware, tweak the code, and try it. Neither the driver author nor the sales team are likely to know the actual constraints, simply because there is no demand for low symbol rates in commercial use.
Similarly it may be the case that the tuning range could be pushed too. In fact looking at these lines in the driver, there are divider values and other settings included for frequencies down to 375MHz and below! So it may be that the hardware can go lower, but they probably wouldn't see any value in advertising, or officially supporting, anything more than the standard L-band range for a DVB-S part.
I think this is the situation for pretty much all DVB hardware: almost any chip might turn out to be usable for amateurs, if someone puts in the work to tweak the code and test it. This is what I am working on doing with the SF8008.
Replacing the MiniTiouner
Forum rules
This forum is run by the BATC (British Amateur Television Club), it is service made freely available to all interested parties, please do not abuse this privilege.
Thank you
This forum is run by the BATC (British Amateur Television Club), it is service made freely available to all interested parties, please do not abuse this privilege.
Thank you
Re: Replacing the MiniTiouner
Update from me on the Si2166D and the SF8008. First, some good news:
1kHz resolution
I've succeeded in changing the UI on the SF8008 to deal with frequencies in kHz rather than MHz resolution.
My current patch against the enigma2 code to do this is here:
https://github.com/openatv/enigma2/comp ... ma2:master
This is not a complete conversion yet, there are some further places that still use MHz. But it's sufficient to use the "Signal Finder" and "Manual Scan" screens with 1kHz input available, and to save the channels it finds with 1kHz resolution.
It's not easy to apply these changes to a running unit because the Python source files are not installed by default - only the compiled .pyc versions. However if there is interest in having this, then I can see about distributing some packages or a prebuilt image with this change.
Adjacent signal test setup
I now have a good test setup for examining the behaviour of a receiver in the presence of closely spaced signals. This took a bit of effort to get right, so to save anyone else the trouble in future, I've cleaned it up and published it with instructions on GitHub here:
https://github.com/martinling/dvbs2-rx-testbench
This uses either a HackRF or Pluto to generate three simultaneous 333kS signals at 500kHz spacing, at a level suitable to feed directly into a receiver in place of the LNB feed. By tweaking settings in the flowgraph and the Makefile, the same setup can also be used with the modulation/coding/bitrate parameters of your choice. You can also adjust the relative levels of the three signals whilst it's running to see how the receiver responds:
Automatic frequency correction range
Now the bad news.
I have patched the SF8008's hi-dvb kernel module to reduce the Si2166D's frequency correction range from 5 MHz to 100 kHz.
However, I still see the receiver jumping around by up to about 3.5 MHz from the target frequency if it does not find a signal there.
I am not certain yet if my change was correct: it may be that the place I have patched the value is not the only setting, and it's being overwritten by another value somewhere else that I have missed. I may need to have a sniff at the I2C to see what's actually being sent on the wire.
But I've now tried the "easy" fix I wanted to make and it didn't solve the issue, so currently the Si2166D is not looking like a ready solution for the demodulator side of things.
1kHz resolution
I've succeeded in changing the UI on the SF8008 to deal with frequencies in kHz rather than MHz resolution.
My current patch against the enigma2 code to do this is here:
https://github.com/openatv/enigma2/comp ... ma2:master
This is not a complete conversion yet, there are some further places that still use MHz. But it's sufficient to use the "Signal Finder" and "Manual Scan" screens with 1kHz input available, and to save the channels it finds with 1kHz resolution.
It's not easy to apply these changes to a running unit because the Python source files are not installed by default - only the compiled .pyc versions. However if there is interest in having this, then I can see about distributing some packages or a prebuilt image with this change.
Adjacent signal test setup
I now have a good test setup for examining the behaviour of a receiver in the presence of closely spaced signals. This took a bit of effort to get right, so to save anyone else the trouble in future, I've cleaned it up and published it with instructions on GitHub here:
https://github.com/martinling/dvbs2-rx-testbench
This uses either a HackRF or Pluto to generate three simultaneous 333kS signals at 500kHz spacing, at a level suitable to feed directly into a receiver in place of the LNB feed. By tweaking settings in the flowgraph and the Makefile, the same setup can also be used with the modulation/coding/bitrate parameters of your choice. You can also adjust the relative levels of the three signals whilst it's running to see how the receiver responds:
Automatic frequency correction range
Now the bad news.
I have patched the SF8008's hi-dvb kernel module to reduce the Si2166D's frequency correction range from 5 MHz to 100 kHz.
However, I still see the receiver jumping around by up to about 3.5 MHz from the target frequency if it does not find a signal there.
I am not certain yet if my change was correct: it may be that the place I have patched the value is not the only setting, and it's being overwritten by another value somewhere else that I have missed. I may need to have a sniff at the I2C to see what's actually being sent on the wire.
But I've now tried the "easy" fix I wanted to make and it didn't solve the issue, so currently the Si2166D is not looking like a ready solution for the demodulator side of things.