Error Distribution

[Derrick]

My small multi focus dish with 28E/19E/13E seems to be a little out of focus. Maybe due to bad and windy weather conditions. I noticed that when watching a BBC program. From time to time I noticed video and audio errors. Apparently they were correlated to the melody of the gusting wind

 

To get to know more precisely what was going on, I started the analyzer of transedit. After a while when the errors were accumulating, I noticed that the distribution was not as expected. See for yourself

 

transponder: 28E, 10773H

 

 

[Griga]

It has to be considered that a sequence of 15 or 16 missing packets is not detected as a gap. This is more likely to happen in case of a video stream.

[Derrick]

IMHO that can't be the reason for the weird distribution. It's also a little more complex than it looks at a first glance.

 

We don't see the real error rate. The noise is bursty. That would affect a sequence of consecutive packets. To reduce this effect, an interleaving scheme is used (see EN 300 421, similar schemes are well known e.g. from dvd). With longer bursts, interleaving will fail because of the limited depth. Further the distribution inside the mux has to be considered.

 

You see, it is quite difficult to put that in a formula (which surely exists ). But I came up with a different theory. The error rate and distribution is related to my setup !

 

The shown picture is from the firedtv with an inserted irdeto module. After running the test a couple of times, there were statistics that fit much better with a normal distribution. After that I switched the coax cables and connected the pinnacle to the small multifeed dish. No errors at all ! In the meantime the wind had calmed down and the same test again with the firedtv showed only occasional errors. After pulling the CAM, the firedtv went down to zero errors as well. Reinserting the module produced again the errors. Another module produced no errors and funny enough, the error rate of the irdeto module went down to zero (no long_time_tests) after inserting a smart card.

 

The reason for this behaviour is totally unclear to me. If it is something inside the module, why does the card stop the errors. Hot pulling of the card doesn't bring back the errors. This happens only after reinitializing the firedtv.

 

The conclusion could be that the CI-tool/driver/DVBViewer creates some kind of race_condition by repeatedly trying to get the ca_status of the card, which at the end results in continuity errors and a messed-up video and audio.

 

..sorry for this rather lengthy posting

 

ps.

a debug.log for Lars showing this condition.

 

debug_1.log -> FireDTV, Irdeto_module without card; BB1 (FTA) -> continuity errors

 

debug_2.log -> as 1 but premiere card inserted -> no errors