Strong Artefacts - Questionable SNR and high BER

[cody]

at least now one thing is for sure - it's not fault of your previous 6985 card, because the new one experiences the exact same trouble and before that for months 6985 was working good for you. of course, there is always an option that currently something in your setup just immediately damages the 6985 card, but that's really the worst case scenario and let's assume it's not that for the time being.

so, the obvious conclusion from the above is that something else changed in your setup. i doubt changing the Ubuntu version has anything to do with it. also, i'm not sure if your charts are any helpful for understanding the problem, because i have no details how you collect them - they look pretty odd and off to me - basically on normal work BER is always "0" - it's really extremely rare event BER go over 0. however, if we trust them and after we're assuming the new 6985 card is not already damaged by something, then that suggests problem in the signal path - cables, LNB, power supply, etc.

unfortunately, if we consider 6985 card is now excluded as root cause of the problem, the options are a lot: unstable LNB, especially when the LNB gets hot with work more time, some problems with power supply of your computer, i won't exclude even unstable power in your outlets for which just your computer power supply cannot compensate and as result there are some rapid changes in the voltage. i really don't know - those are just ideas - more or less everything is in your hands to investigate from your side.

[dpdpkpcom]

Thanks for your help Constantine !!

Really appreciate it.

Is there a way of logging pcie data throughput / 6985 temperature ?

Anything that may aid in troubleshooting ?

Thanks

dp

[BeMax]

What type on LNB do you have ? I have a Quad output LNB and the isolation between the different "ports" is not good enough. If you have one receiver using one port, the other ports will get some "glitches" if you change polarization/LO etc...

or do you have this problem ?

viewtopic.php?f=142&t=8745

If not you are maybe the only one that don't have...

[dpdpkpcom]

What type on LNB do you have ? I have a Quad output LNB and the isolation between the different "ports" is not good enough. If you have one receiver using one port, the other ports will get some "glitches" if you change polarization/LO etc...

Hi BeMax

Thanks for responding. I have a eight-output LNB. I changed this over the weekend for another (different) 8-output LNB and it's too early to tell if it's made any difference yet, but I should know in the next few weeks.

or do you have this problem ?

viewtopic.php?f=142&t=8745

If not you are maybe the only one that don't have...

I saw that post before I posted my original post but I don't have any Continuity errors listed in the logs, but the picture of the artefact is VERY similar to what I'm experiencing !

I had a further email reply from Constantine at TBS - here it is.......

hi David,

there is no way to check 6985 temperature - there is no sensor about that on the card, but i doubt it's related to overheating of 6985 - i haven't had case of 6985 overheating and we have users using several 6985 cards installed next to each other in the same system to build IPTV servers. so, if there are problems with 6985 overheating putting several cards next to each other would definitely make such problem very obvious, but that's not the case.

there are 2 ways that come to mind for monitoring the data throughput:

a) lock the signal with 'szap-s2' (that has advantage that you get statistics like BER, etc in real time) and then keeping 'szap-s2' working run 'dvbtraffic' - it gives real-time statistics of the data-rate and PIDs in the stream - if there is some data corruption, then data-rate will go down compared to the expected one. however, if the data corruption is low it's hard to spot it on 'dvbtraffic' output, i mean notice the total is not as much as it should be, but in case of significant corruption it's obvious on such test. actually, for this test, please, read remark *)

b) use 'dvblast' - if you setup stream one channel from a transponder with 'dvblast' it performs real-time analysis of the TS stream and outputs as debug messages there is corruption in the stream. that's good way to confirm the corruption and see how often it occurs

*) something else that you can try is lower the demand on PCIe bus the card puts - assuming something changes in your system that compromised the normal PCIe bus performance. so, if you run 'dvbtraffic' with default driver, even when there is no signal lock, you will see that the output is:

1fff 42877 p/s 7871 kb/s 64487 kbit
2000 66039 p/s 12124 kb/s 99323 kbit

that's because the card is doing padding to about 100Mbps with Null (empty) TS data packet. you can disable that with replacing in the drivers the attached 2 files and then rebuild and reinstall them. so, after doing that, running 'dvbtraffic' without signal lock must give empty output, because there is no longer TS generator active on the card and all data pass to the PCIe are the one that are received from the transponder, i.e. padding to fixed data-rate is disabled. that can be useful for test like a) too.

in any way, considering the history of your case, i.e. that 6985 was working good for you, i doubt any of the above will give solution - it more can give some idea what else broke in your setup. in cases like yours at least my usual suspect is the LNB.

best regards,
constantine

i forgot to add on *) that after you build and install the modified driver to disable the TS generator you need to create text file in "/etc/modprobe.d/" called for example "tbs.conf" and it with following content:

cat /etc/modprobe.d/tbs.conf
options saa716x_tbs-dvb int_type=1
options saa716x_tbs-dvb enable_gts=0

I tried the int_type setting (on its own) (without rebuilding the driver) but the result of that was inconclusive and the new LNB arrived, so I took Constantine's thoughts and replaced that as the first priority.

If I still get artefacts, I will be trying his modprobe suggestions.

I'm not convinced the LNB was at fault, as my Humax box has no issues at all. My gut is telling me it is a driver issue or some sort of motherboard pcie bandwidth restriction as it seems to only be a problem with HD recordings, although I did have 1 issue once with a SD recording, but that could have been because an HD recording was happening at the same time !? With HD, it's reliably unreliable But the LNB sounds like a quick (and cheap) thing to rule out, so I'm doing that first, then it'll be modprobe settings.

A driver issue or PCIE bandwidth issue feels like where the problem is (to me). And the fact that others have managed to run the TBS6985 fine under windows, but using the same hardware have had no problems under windows, backs this up.

If I can get too sick, I'll sell the TBS card and try another make. But, to be fair, the TBS people have been great and very helpful, so I'm keen to stick with TBS if I can.

dp

[dpdpkpcom]

oh dear.

The problem persists.

I had to say, for a while, I thought it was sorted. I had watched a couple of programs without any issues, but then 10 minutes before the end of a program the artefacts were back. It was HD. Dancing on Ice and at 8.45/8.50pm, 15 minutes before the end, it was very corrupted.

It was recorded on adapter0 and the attached graph shows no problem with signal and SNR (as reported by femon). It drops off at 9pm when (presumably) the tuner no longer locked onto the frequency.

Next thing to try is constantine's patches. Interestingly, there were 3 programs recording at the time, which lends me to think it's a PCI-E bus speed issue and/or driver-related.

Will report back if the recompiled driver (with Constantine's patches) helps in due course.

dp

[jandenouden]

Hi,

Thanks for the update. Yes, I think we've all been there, making a change and then thinking that was the magic fix, only to find out later it wasn't. Please let us now how you get on with those patches - I'm still hoping the problem can be fixed eventually.

Thanks,
Jan

[dpdpkpcom]

Hi,

Thanks for the update. Yes, I think we've all been there, making a change and then thinking that was the magic fix, only to find out later it wasn't. Please let us now how you get on with those patches - I'm still hoping the problem can be fixed eventually.

Thanks,
Jan

Will do Jan

Unfortunately, I haven't got much free time for a while, and I've just realised I didn't include the files in the post from Constantine, so I have attached them to this post. Hopefully this will allow others to see if it helps them. And I will report back in due course, when I've had a chance to test it too.

For instructions, see Constantine's post that references these files earlier in this topic.

dp

[jandenouden]

If I interpret the patch correctly, it disables the dummy TS packet generator that is used to pad the TS to 100 Mbit/sec. I've tried this before and it didn't make any difference, but perhaps it works for others.

Jan

[ebogdan]

That patch didn't work for me either, I have strong artefacts on 3 x 6985 cards. These artefacts seem to be directly proportional with how complex the streams are, and do not seem to be related to the format of the channels (SD/HD) or encryption etc.

[jandenouden]

Constantine (TBS support), if you are reading this?

Given that so many people have this problem, it shouldn't be hard to reproduce. Perhaps the author of the Linux driver can have a long hard look to see what is going on??

Thanks,
Jan