Cable vendor slapped for unproven claims

Re: Error correction

> no one has yet mentioned the fact that error correction is not infallible.

Yes they have. That's why these digital links are described as "working" or "not working". The latter is when the signal contains uncorrected errors.

> the data that arrives will be plain simple wrong AND (at the digital level) NO ONE WILL KNOW.

No.

Whilst there is a mathematical probability of a random data corruption causing a valid packet hash, the chances are vanishingly small. You're never going to see that.

> I don't know if that happens in practice, but it's conceivable. Anybody know for sure?

In TV, for example, there are various "error covering" modes, but these usually involve just repeating a previous sample - this is why you get screen freeze when the signal goes very bad. This is generally unacceptable for audio because you get audio tics, which are very distracting.

What you do *not* do is to try to make up the data you have missed. There is insufficient information about it, so any guesses will be badly wrong.

> what does it actually do with an error that it has detected but not been able to correct?

Depends on the severity. If you're missing a couple of MBs, you typically display the picture anyway - it'll have a purple / green stripe in it, but most of the picture will be there. If you miss most of the picture, you start by freezing the display for a short while, and then blanking it if you don't get valid signal quite quickly.

For audio, you mute.

> Just ignore it (see link below) and rely on filtering/interpolation, hoping that no one will notice?

There is no such hope - if the data is missing, the user will notice. You make the best of a bad job, and hope the stream recovers.

> Are there counters anywhere that keep track of corrected and uncorrected errors on the link?

No. If the stream is degraded, it needs to be fixed. Carrying counts is fairly pointless.

> Your $20 DSL modem/router has the relevant counters

A DSL modem is carrying asynchronous data. An A/V link is carrying isochronous data. There is significantly less you can do about errors in the latter case. Additionally, a modem is dealing with WAN signals, where latency is expected. An A/V link is dealing with local signals, where latency is minimised. These situations add up to one system that can use retry protocols, and one that cannot.

> There is a whole load of junk talked on this subject

There certainly is.

> an error corrected digital link without commonly available tools to

> check whether it's working right or not is just stupid

Not so. It is appropriate for the medium.

> or someone in the designer/manufacturers is hiding something

Or, alternatively, yet another AC on an Internet forum doesn't actually know what he's talking about.

Vic.

Hows does ADSL work

OK - back to my physics days. The reason why ordinary phone cable can carry ADSL signals is that (from the exchange) it's a balanced pair - at least until you hit the household wiring when ring-line separation (at least in the UK) can be a problem as can some nasty home wiring kits. Both are easily dealt with.

Note that the pairs from the exchange are fairly loosely twisted, as they were designed for noise rejection at a fairly narrow range of audio frequencies. Nevertheless, it's good enough for ADSL. What essentially happens with ADSL is that it uses a relatively low raido frequency band (about that of MW/LW) up to about 2Mhz. That bandwidth is separated into a number of sub-channels of, I think, about 20Khz each. Each sub-channel is assigned a number of bits depending on how good the SNR ratio is as the receiving end. The higher the frequency, the more the signal is attentuated (largely due to skin effects with I did the calculation - at higher frequencies less of the copper is used, and at the characteristic impedance of phone lines, then the resultant increase in resistance seems to be the main cause of degradation). Anyway, the upshot of this is that the higher frequencies get attenuated more and can carry fewer bits.

Each sub-channel is modulate using an encoding system called QAM (from memory) which uses both amplitude and phase modulation. Indeed it's what modems used in the dial-up days before broadband, but confined to audio frequencies (and the reason it was confined to audio frequencies was simply because the signal had to pass through a digital exchange system than itself could only encode 64Kbps, in Europe, or 56Kbps, in the US). As ADSL signals only go as far as the DSLAM in the exchange (or streetbox), it never hits the exchange.

Anyway, really clever stuff is how the signal is how the signal is modulated and de-modulated. Back in the old days it was done using inductors and capacitors and analogue circuits and an ordinary phone line would be lucky to hit 9600baud and the modems were physically huge. However, these the modulation is essentiall created as a digital signal in the first place which is then put onto the phone line using a digital-to-analogue converter (DAC). As the far end, the very much attenuated signal (perhaps reduced in power by a factor of a million or 60dB) is converted back into a digital one using an analoge to digital converter. Then a bit of magic happens - the string of numbers representing the, buy now, heavily distorted modulate signal is def into some very clever mathematical algorithms which essentially reconstruct the relevant bit streams.

This bit of magic is called Digital Signal Processing (DSP) and is at the heart of all modern high speed communication and digital broadcasting. DSP is truly one of the wonders of the modern age, and is only hard-core mathemeticians.

So those that say that there is no such thing as a digital signal are right - well, at least over cabling of any length.

@AC

"I'm just aware of what "industry best practice" might be (as exemplified by $20 DSL modems with error counters as an architectural requirement)"

Erm, that'll be the wrong industry's best practice.

I suspect you'll find that the main reason for the quantity of low-level info presented by DSL modems relates to the amount of difficulty a very significant % of users have getting reliable high-speed connections. If you go out and ask your friends, assuming you have some, how many have link, latency, throughput or data loss problems with their broadband vs. their HDMI link from STB to TV, I think you'll understand why it would be a pointless exercise (and increase the cost to the end-user) to implement lots of low-level debug on every HDMI-equipped box.

Retrying...

> "one system that can use retry protocols, and one that cannot."

>

> Exactly my point.

then you haven't thought through what point you're trying to make.

Isochronous data is real-time. If you retry transmission, it is late. This would show up as pauses or drops in the displayed data - and remember that you will have do duplicate the artefact on both audio and video streams if they are to remain synchronised. This is not feasible for consumer equipment - if you really have lost the data, by far the least noticeable way of dealing with it is just to give up on that chunk and start again. Attempting to get a retransmission would make the error very much worse.

> Therefore you can tell the difference between an occasional burst of

> errors due to external factors, and a consistently degraded link due

> to marginal transmission quality.

I have absolutely no idea what you're trying to prove now. So what if we can detect trends in the error rate? We can't go back in time and make those errors not happen - which is what is needed to relay isochronous data on time.

> It appears there is no such option in these entertainment connections

Some equipment may hold historical data for debug purposes - but that is all. Kit generally doesn't offer up such debug info because it is of no use to a user.

>"the chances are vanishingly small. You're never going to see that."

>

> The chances of an error are indeed very small per frame/cell/packet

Have a look at *how* small.

> the number of frames/cell/packets/whatever is however outrageously high.

Not high enough.

> Therefore errors will happen from time to time

Random errors creating valid has checks are a mathematical possibility only. If I had a tenner for every time it had ever happened, I would have nothing.

> and could in principle be counted (as per DSL modem).

Now you're confusing two things: whether errors occur (they do), and whether that error creates a valid packet (they don't).

But counting errors serves no purpose: you can tell if the link isn't working because you can see or hear it. Attempting to do anything else means you are breaking the real-time nature of the signal - and that will cause far more problems than it solves (as well as being undesirable in the first place).

Vic.