Re: TBS 6903 tuner allocations
On Sat, Nov 13, 2021 at 10:35 PM, David J Taylor GM8ARV 🏴 🇪🇺 wrote:
the TBS6908 is twice the TBS6903. You certainly refer to the latter one as in the subject.
As I have never setup a TC receiver under Windows I might not be the right person to answer here. I try to explain once more the problem we had with PCIe cards (only) when HVS-2 started.
HVS-2 was very dynamic going from full throttle to almost zero bits/second for longer periods. Georgios Potiriadis at EUMETSAT finally found the reason for TC client timeouts and CrazyCat
said what HW, the PCIe bridge chip, was causing this. In the case of the TBS-6903 (and TBS-6908) the driver under GNU/Linux basically consists of three kernel modules loaded at boot up:
stv6120 This module is for the tuner chip including the matrix switch at the input. It has a parameter "rfsource" that you can set for single cable mode.
stv091x This module is for the demodulator chip. MODCODs are set here. It has a parameter to set it in single mode to double the bandwidth (never used for EUMETCast).
tbsecp3 This module is for the ECP3 PCIe bridge chip common to all TBS PCIe cards that have been produced after the (deprecated) TBS-6983.
ECP3 allows for up to 8 demodulators each having its own DMA buffer. This buffer accumulates a certain number of 188 Bytes MPE packets and then flushes the whole batch over the bus.
In early drivers IIRC this was hard coded to be 512 MPE packets. HVS-2 on T2 with long gaps of almost zero bits/second made the TC client loose time sync because some minimal heartbeat
was stuck in the DMA buffer that only slowly filled to 512 MPE packets. HVS-1 on T1 never had that problem because BAS always provided some minimal trafffic that kept the DMA buffer busy.
The problem was solved by two different approaches. I added a module parameter to tbsecp3 to choose the size of each of the 8 DMA buffers in units of MPE packets. So we could set
that e.g. to 256 packets for T1 but 32 packets for T2. Of course this increased the interrupt load of the receiver PC but that was no problem. CrazyCat streamlined my solution which is still
part of tbsecp3 and can easily be configured for all TBS cards. EUMETSAT resolved the problem later by always providing some minimal (invisible?) traffic on T2 so that even drivers with a
fixed DMA buffer size of 512 MPE packets should make TC happy. On T1 nothing was added which means that if you set MODCOD for HVS-1 only you have the "dejavue" problem of HVS-2.
On your site you describe the situation under Windows for "Single Cable operation"
You mention som SR-Test.exe that was used to set the input matrix switch right (module parameter "rfsource" under GNU/Linux).
You then have a note that makes me think that the PCIe bridge DMA buffer sizes are still fixed somehow in the Windows drivers.
Note: If you are using the beta TBS6903 driver (drivers dated 2017-07-07) you need to lock and receive HVS-1 with tuner-0
and HVS-2 with tuner 1, because they have different-sized packet buffers (64 packets for tuner 0, and 16 packets for tuner 1).
So, unless you have now some other means to set these DMA buffer sizes, those might depend on your Windows driver version :-( ??.
But don't worry there is still the EUMETSAT solution of the initial problem. All drivers should work now except for MODCODs HVS-1 only.
In othe words I do not think that having T1 on demod 0 and T2 on demod 1 should be a problem nowadays (with recent Windows drivers).
That all said the first thing I would try is to go to your Windows control panel and under "Netzbetrieb und Energiesparen" tell it
to never go to the energy saving mode if it is working unattended. I attach a German screenshot, this must look similar in English.
I also noted that CrazyCat has a new version of BDADataEx from 2021/10/27 (no idea what he has improved though)