Starting out, Digital Devices issues
yes my Core2 Duos are E8600. When I retired in 2014 I took 16 of those with me. The teachers wanted them replaced because they couldn't "teach" the keyboard with such old PCs anymore. About 6 of them are still working. All others died with a PSU problem that could be a 50 cent capacitor. For the MTG aerea to come I have 2 XEON WS with 24GB RAM.
Congratulation for fixing the DD driver! This sounds similar to my fix for the TBS ECP3 code including the variable size DMA buffers when HVS-2 caused a big problem to begin with. I never had a broad understanding of Linux driver programming and played at the edge of my C knowledge. But I finally got it working by looking at the source of other device drivers.
Why don't you ask DD for a free sample of their latest version that can handle 8 transponders using the Oxford chip similar to the TBS-6909X and make this EUMETCast ready ;-) ?
- Is your setup a graphic system or headless CLI only?
- Do you use some version of szap-s2 for tuning?
- How do you get the SNR values you mentionned?
- Can you set the SIDs to the EUMETSAT value 1?
- Is there a DD way to set MODCOD filters?
Best regards,
Ernst
Amazing stuff to run that on an old Core 2 Duo! I presume it's an E8600?
I appear to have fixed the driver and I am most pleased with it. Slipped back in the nosync code, reintroduced the change to use dvb_dmx_swfilter not swfilter_packets (the TBS driver finds the sync and fixes it before feeding to swfilter_packets, which requires it synced, the DD driver detects misalignment and just then selects swfilter_... and... found that changing the tsspeed value from 0x20 to 0x28 (there is a hardware detection routine in there to select the latter value, guess mine didn't fall under that from what I could work out) magically got everything going. Over the moon to say the least, especially as I barely know what I'm looking at! CC errors gone bye-bye and TelliCast happy.
Charlie
By the way, I've been using your pytroll starter kit for the data I have been able to get on BAS - huge help, thanks for making that!Charlie (and others),
just to show you what you can do with GNU/Linux on
a stone age Intel Core2 Duo with 8GB of DDR2 RAM:
http://5.153.116.86:83
I assembled this just to see the hard limits. It's not
extreemly responsive anymore but I have other PCs
too. You should be able to do such things with your
low power HP Elite Desk 800 G1, I5 with 8GB RAM.
I used my latest PyTROLL/Satpy scripts. I'll probably
publish those after we get an update of PyCoast 1.5.0.
Regards,
Ernst
P.S.
I'll leave that open for a day or two until I get too much script kiddies ...
Yup - did a make clean before recompiling. And it threw its toys out the pram as I had initially missed defining the u8 integer... *whistles*
It was struggling to even get the announcement channels! I changed the code in the input_write_dvb routine in ddbridge-core.c that passes the data to the dvb_core demux, where it detects if the buffer is unaligned or not - the former case uses dvb_demux_swfilter that will sync itself, whereas the latter case uses dvb_dmx_swfilter_packets that expects alignment. Matching that section between those two parts of the code made it behave a lot better, although still lost more packets than otherwise!
I guess the problem with using the TS nosync option may lie in how DMA is handled in ddbridge-core.c full stop - it is (of course) radically different to the TBS code. There is a line in there to give a debug output for buffer overflow, I guess I should try getting dynamic debug going and seeing if it spits that error out.
By the way, I've been using your pytroll starter kit for the data I have been able to get on BAS - huge help, thanks for making that!
Charlie
If you have not added this "u8 reg" bit in your test I propose you try to add and test the CrazyCat trick once more!... and to double check. In the case you really have forgotten this "u8 reg" before I wonder how you could compile the driver at all.
So just to make sure: You have to recompile your driver with the CrazyCat trick and install the modules again. You certainly have
some make file for that. Without a "make clean" (?) before it will probably just recompile stv0910.c. There should be no errors ...
Good luck,
Ernst
IIRC TBS can use up to 8 ring buffers (there is one per DVB adapter).Charlie,
on the bridge there is of course one DMA ring buffer per transponder. The OS has ring buffers per adapter to sort PIDs. My brain is getting worse ...
I come back to the CrazyCat FIFO minimum lattency stuff. Below I attach both routines from stv0910.c (DD) and stv091x.c (TBS). As you see there are other differencies beside the " /* Check MATYPE flags*/" sequence I attached before. But most important you have to define "u8 reg" in the case of stv09x.c (I have not posted that as this is further up in the code).
If you have not added this "u8 reg" bit in your test I propose you try to add and test the CrazyCat trick once more!
Cheers,
Ernst
the packet counter errors looked indeed like the FIFO problem. But you said you entered the CrazyCat stuff and then recompiled and reinstalled the stv0910 module to no avail :-\?!
I had a look at
https://digitaldevices.de/produkte/dvb-komponenten/octopus-mini-pcie-bridge/
and see that it has a Lattice ECP3 bridge. Thats what TBS uses too. In the early days we had a problem that for some reason the TBS driver did not service all DMA transfer interrupts and ring buffers got overfull and MPE packet data lost. Actually I fixed that with CrazyCat. IIRC TBS can use up to 8 ring buffers (there is one per DVB adapter).
Looking at ddbridge
https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/ddbridge-core.c
reveals a bunch of module parameters. As this has been written by the Metzler brothers I think they certainly knew what the did.
I also had a look at
https://digitaldevices.de/en/products/dvb-components/duoflex-s2/
Not sure what "VCM --- yes, 1 Stream" means. Is BAS/HVS-1 two Streams?
- Is your setup a graphic system or headless CLI only?
- Do you use some version of szap-s2 for tuning?
- Can you set the SIDs to the EUMETSAT value 1?
- Is there a DD way to set MODCOD filters?
Indeed be interesting to see what DD come up with.
Best regards,
Ernst
Hi Ernst,
You're not wrong about the mount on the dish... loosen the elevation bolts off just enough to move it and you get azimuth movement! The USDT machine is definitely very limiting but after finding the cheap mPCIe adaptors on Amazon are actually dangerous and angrily returning it - not much other option to use the Octopus Mini v2 in much else. I have even tried it in a Dell-Wyse Z90D7 thin client, only other hardware I have with such a slot! Identical issues there of course. At least the power consumption is very low - the machine before DVB hardware (haven't checked since) idled at around 12 watts. It seems to have no complaints about filesystem performance - the disk is RAM cached at both ends after all.
I did find your previous thread there amongst much searching, had me looking in the driver before although I'm no software developer by any means. The driver comes from https://github.com/DigitalDevices/dddvb (there is an older version in the mainline kernel too).
Done some more poking this evening including lifting the code you've shown there out of CrazyCat's files and dropping it into the equivalent place in the Digital Devices drivers... made it worse! Had a play around with some of the other bits around the output to dvb_dmx_swfilter and reduced CC errors from the worst point, but yeah... given up there and gone back tail between legs to the DD provided version. At least I can get BAS fine for now.
The modules that get loaded are ddbridge, stv0910 and stv6111. Modinfo reveals only parameters for ddbridge, and the ones relevant to my hardware/interesting here are alt_dma, dma_buf_num, dma_buf_size, and msi
Have tried them all in various combinations to no avail - it seems the default buffer size is 672 packets (!), the lowest you can get it to go is 32 (dma_buf_size=1, in ddbridge-core.c you find "dma->size = dma_buf_size * 128 * 47;"
Be interesting to see what DD come up with.
Charlie
welcome to MSG-1. You may have noted that most users are on Windows 10 or even 11. It's therefore a great pleasure for me to welcome another member of these few geeks that use GNU/Linux. I must admit that I have never used a DD card and IIRC you are the first person I heard of that tries to use these DVB-S2 receivers for EUMETCast. Your description of the system is full of brave decisions. This ultra small HP PC probably has no room for a big 3.5'' HD. That's why your filesystem is on a NAS via iSCSI (network) access. I wouldn't dare to do something like this but given the fact that the TelliCast client can even do (undocumented) similar things with FTP it might work just fine. But your current important problem is rather the DD frontend. As far as the dish is concerned I think it's pointed well especially given the fact that this TRIAX has a terrible elevation mount. That said a 1.2m dish would certainly be a much better choice but let's go with the TRIAX for now. An SNR=11.1 dB *should* allow for acceptable HVS-1 reception to begin with.
<cite>
I am aware most on the group are either using the TBS cards or Ayecka routers, but trying to get this going on a budget and a card that has the feature support at a fair amount less was too tempting, considering it uses most of the same hardware as the TBS 6903.
</cite>
If we have learnt something in the past then that hardware is 50% and the rest is drivers (or maybe firmware in the case of the SR1). I had the same HW on the TBS-6925 card as in the Ayecka SR1 in 2014. But I went through months of frustration before I finally got the first working EUMETCast DVB-S2 VCM PCIe card receiver on the planet under GNU/Linux.
https://groups.io/g/MSG-1/message/18219
The single BIT I set in a STV0900 register puts the FIFO in minimum lattency mode that is necessary for the special VCM Basic/HVS-1 signal. It later came as module parameter issy=0 (Konstantin) and finally ts_nosync=1 (CrazyCat) for the TBS distributed stv090x module. The TBS stv091x driver module used for the highly recommended TBS-6903 recognizes the EUMETCast signal and has an automatic FIFO setting built in (see code attached below). The same kind of code was part of a TBS-6909X driver module until recently. The latest version has again a module parameter that must be set ts_nosync=1. This can easily be done in /etc/modprobe.d as you probably know. I faintly remember that the DD drivers or part of those (ddbridge?) have not been open source in the past and made it hard to do your own stuff with STV registers or bridge DMA buffers. No idea what the current situation is. Do you download your drivers from some github repo and compile the source on your PC? Anyway my first advice is to get a list of modules ("lsmod") that are loaded for your DD frontend. Then (as root) make a "modinfo" for these DD driver modules and see what module parameter they have. You can also ask DD whether they are aware of the special FIFO setting for EUMETCast.
CrazyCat's trick for EUMETCast reception in TBS distributed stv091x.c (automatic minimum lattency setting)
...
/* Check MATYPE flags*/
read_reg(state, RSTV0910_P2_MATSTR1 + state->regoff, &tmp);
read_reg(state, RSTV0910_P2_TSSTATEM + state->regoff, ®);
if ( tmp & 0x18 )
reg &= ~1;
else
reg |= 1; /* Disable TS FIFO sync if ACM without ISSYI */
write_reg(state, RSTV0910_P2_TSSTATEM + state->regoff, reg);
/*pr_info("stv0910: %d TSSTATEM=0x%02x\n", state->regoff, reg);*/
read_reg(state, RSTV0910_P2_TSSYNC + state->regoff, ®);
if ( tmp & 0x18 )
reg &= ~0x18;
else
{
reg &= ~0x18;
reg |= 0x10;
}
write_reg(state, RSTV0910_P2_TSSYNC + state->regoff, reg);
/*pr_info("stv0910: %d TSSYNC=0x%02x\n", state->regoff, reg);*/
...
Cheers,
Ernst
Hi all,
Been scouring the posts on this group for a bit now, some very helpful folk and resources it seems! I'm just starting out with receiving EUMETCast and been having some trouble.
My present setup is as follows:
HP EliteDesk 800 G1 USDT, i5-4590S 8GB PC3L-12800S, Debian Buster
Digital Devices Octopus Mini v2 + DuoFlex S2 V4A, dddvb driver (0.9.38 latest)
Triax TDS 80A + Inverto Ultra Black PLL (new version), very short run of Doncaster RG6 up to the splitter & receiver
Storage on TrueNAS Core over iSCSI
I am aware most on the group are either using the TBS cards or Ayecka routers, but trying to get this going on a budget and a card that has the feature support at a fair amount less was too tempting, considering it uses most of the same hardware as the TBS 6903.
I have a C/N of around 11.1 dB on C4 and 10.6 dB on C10. I know we're after more, but not the end of the world if I get whacked with rain fade (am looking at maybe a bigger dish if this would cure the situation though...). The frontend reports a pre-correction BER of 0 most of the time, and only just popping above that when it doesn't. Yet,I am getting dropped packets out the wazoo in Tellicast. BAS is fine, get the occasional and FEC catches it. HVS-1 is the worst, it is unusable for me, HVS-2 gets some errors but nowhere near as many.
I get TS continuity counter errors, see the following dmesg output with dvb_demux_tscheck enabled:
[ 1204.617931] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0x6 got 0x7
[ 1204.617935] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0x8 got 0x9
[ 1204.617938] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0xa got 0xb
[ 1204.617940] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0xc got 0xd
[ 1204.617952] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0xf got 0x0
[ 1204.617954] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0x1 got 0x2
[ 1204.617956] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0x3 got 0x4
[ 1204.617958] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0x5 got 0x6
[ 1204.617967] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0x8 got 0x9
[ 1204.617969] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x258 expected 0xa got 0xb
PID matches up with HVS-1 where I am seeing the issue. I have tried using TSDuck's tsp utility with the continuity fix option on instead of dvb-eumetcast's package and the results look very similar, so I think I am losing packets somewhere between the demod output and the driver! I have tried ddbridge's params for the alternate DMA modes and buffer sizes with no change, tried setting C-states, low latency kernel when I was using Ubuntu 20.04, loading up the CPU (no change), a different TAB input on the bridge card, different dddvb versions, all the tricks I can think of. Have run to the local SSD rather than iSCSI to check that it is not the CPU loading from that causing hoo has either. The errors are all CC and not TE - that flag isn't being set (I can induce that mind by blocking the dish partially).
I am still wondering if this is a dish size issue - the "80cm" TDS80A is really a 70 across which is a bit small... it is pointed the best I can get it, set skew, focus etc all tweaked until I got the highest 0.1 of a dB I could find. Is the C/N I've seen about what we'd expect for that dish size in London, UK? I have tried using excess coax to bring down the signal level a bit as well in case it was an overload with the massive gain of that LNB but seemed to make zero difference other than reduce the input level a bit. Tried without the splitter etc and throwing a fresh bit of cable out the window to check all that. The fact the BER looks so clean makes me think no, but the card is happy happy on other services not using 16APSK? The BFBS service on C1 11221V comes in at like 12dB and I get no CC errors at all despite a comparable symbol/data rate (okay, QPSK 5/6 is vastly more forgiving). That and the BAS service is absolutely happy even without MODCOD filtering (ddbridge driver doesn't support it and the CrazyCat69 drivers don't rework ddbridge to call stv091x instead) - is it possible for the C/N to be too low for happy 16APSK decoding, yet have no interaction with BAS' 8PSK and have next to no BER (and less errors on the lower strength HVS-2?!)?
Driving me round the bend. I've provided this info over to Digital Devices themselves and waiting for a response, but wanted to see if anyone here had similar experiences or possibly some info that would shine some light.