They "should" return signal to rail.
Most do not.

Note: this has nothing to do with timing or actually quality of "eye" pattern, just the voltage swing.


This is true.
Note: "more expensive".
It is not until you break the $1000 price point that there is any margin for doing this.



There is (+/-), but there are specs for a lot of things related to HDMI.
Build of Materials and design time costs limit what can be done in the real world.
Personally I can tell you that you cannot build a true 10.2g cable that supports ALL four high speed data channels, 5 volts (easy to drop this one) and DDC correctly cheap.
But I see cables listed as such (claiming HDMI cert.) and sold cheap all over the place.
HDMI LLC is not set up to be a police force and we on more than one occasion have seen a certified product drop in quality without penilty from HDMI.
This is one of the reasons that we (and other mfgr's) support the DPL program ( http://www.dpllabs.com/ ).

They provide a no bullshit product verification of performance (that is spot checked in the field).
You should note that DPL tested/certified products WILL cost more than other like spec'ed products.
The difference is that DPL rated products do what they claim, also the cost the administer the DPL program is by no means cheap, the recent upgrading of test gear for 1.4A (cables & electronics) was over $500,000.

What this means is if you want product performance that you can count on look for the DPL label.

As Brent said, restoring the signal to 5 volts doesn’t fix other problems in a circuit which I already mentioned. All because the data is re-transmitted doesn’t mean you will get a picture. Devices like the signal restorers could be added into devices but the cost is not cheap. It probably cost less than $2 in parts in big volumes, but it is not the parts that add to the cost of the products. It is the design, re-tooling and testing which cost money. One dollar in parts could easily be $100 or more retail price and that is just not going to happen in inexpensive devices.

The TMDS channels are one way so there is no communication between them. Communication would have to be on the DDC channel and if there are problems on the DDC channel then we wouldn’t get authentication and no picture. The encryption key comes from the source and used throughout. The KSV are part of authentication and its answer I used for encryption. It works like this.

A key is nothing more than an algorithm/ equation. The source uses one of its 40 keys and generates a random number and it then calculates a public key to transmit called the KSV. For simplicity let’s say the source uses key #1 and its equation is X+65. The random number is X. We’ll say X=60, so the answer is 125. The source transmits its KSV derived from key #1 and random number 65. The receiver calculates the answer of 125 from the KSV. But, it doesn’t transmit the answer back to the source directly because you never want to transmit the answer or the algorithm used.

Instead it uses one of its own key numbers lets say key #20 and a calculates the number to be used with it. Key #20 is subtract 50 from this number. So that that number becomes 175. So when the source receives the KSV that was derived from key# 20 and the number. The answer is the same 125 and the data stream will now be sent. That answer of 125 is the stream cipher encryption as a simple binary XOR operation. If you don’t know what XOR is look it up. So in reality the transmitter (source) sets the encryption and the receiver confirms it. All part of the authentication process which happen ~ every 2 seconds. I think repeaters transmitter have to use the same encryption as the source or authentication would not be valid. I don’t believe it generates its own KSV that would not be a repeater then. The repeater does re-transmit it effectively making a separate communication with the display but authentication/ encryption is set by the source.

Next Post

All this information is under it is nice to know but how does it help the installer or home owner diagnose a problem with their system? It doesn’t! We need to discuss some troubleshooting techniques that help us in the real world. I try to keep it simple and get it down to two areas, signal problems or equipment. To test the signal here is what I do.

Get all the components next to each other and connect the system with DPL rated cables all under 2 meters or less. There are many inexpensive brands of cables that have passed DPL certification and worth it for an installer to have some at least for troubleshooting. Plus I’ll give a shameless plug for Brent’s Ethereal cables for all his help on the forum. I’m sure Brent and Jeff can tell you there are some short cables that are poorly made and can cause problems, so don’t assume any short cable will be fine.

If the system works with certified short cables but not with longer cables than it is a signal problem plain and simple. Do whatever you need to do to fix the signal, ie. Balun, signal restorer, etc.

If it doesn’t work with the certified short cables is where it gets interesting. Now, we have to figure out which device is causing the problem. First check and try all the device settings for each device. Simple things like turning off CEC, monitor check functions, set one resolution, make sure it is sending 8 bit by turning off deep color, Use video levels instead of RGB, etc. If this doesn’t fix the problem than it is time to swap equipment. I can tell you there is a big variance of cable/sat boxes even of the same model so changing sometimes solves the problem. I could check the voltage coming out of a device with my multi-meter but this might not be the problem but easy to do. I rarely take my oscilloscope to the field, and just not practical as I can only look at one channel at a time and don’t have the money to upgrade my equipment to do eye patterns. Even if done in the shop (my house) you won’t believe how much time you can use testing equipment. Like I said just not practical.

If you have a DAD or signal restorer put it at the output of a device. It will give some information like if the voltage and hot plug are OK. It also gives indications that data is moving between devices if placed in the middle but it can be difficult to know which device is causing the problem if you don’t get these indications. So it is not the best diagnostic tool. Hopefully, something will come out that we can test input and output of devices to diagnose the problem. I know Jeff is working on something like that. Quantum Data has a unit that will help and is ~$1500 which I have thought about buying. But still doesn’t do everything I would like, like number of device keys a source has. Also, I’d like something that can do HDMI 1.4 or I will be buying a another device in the near future.

Luckily we haven’t had many HDMI problems (knock on wood) but we use equipment we are familiar with and keep cables <20 feet unless it has corrective circuitry (ie restorer or balun). I’d love to hear what other people do to diagnose problems.

Bob

Thank you, Phil. You clearly understand the argument, whether right or wrong, and have done an excellent job summing up both the conclusion and its significance to CI's. (BTW, I've tried finding spec info on AVRs to come at this another way, but no luck so far.)

Brent and Audible Solutions - you keep asserting that the conclusion of the argument (i.e. that all AVRs capable of handling HDMI audio produce a new video stream to the display) is wrong.  However, you are letting what you think you know about this to get in the way of even considering very simply logic that suggests otherwise.

Perhaps you will put aside what you think you know just for a moment, and consider this:

The TMDS stream sent to the AVR is encrypted with the AVR's key, such that only the AVR can decrypt it.  Now, if the AVR does not produce a new TMDS stream for the display, then how can the display decrypt that stream?

Just tell me where this is wrong, and I will happily lay the argument to rest.

I believe you are mistaken here about the encryption being set by the source. In the transmission from the AVR to the display, it is set by the AVR (or more precisely, the encryption key is derived from the KSV of the AVR along with the key sets of the AVR and/or the display.)

This is discussed in the HDCP white paper that you previously referred me to:

[Link: crestron.com]


I tried explaining this in post 71 and elsewhere. Perhaps you would find Phil's example of this more compelling from post 89:

I see what you are trying to say that each repeating device is a receiver and transmitter. Each transmitter and receiver has its own set of keys, this is true but the encryption is not set to a key and each device generates its own KSV because the keys themselves are not transmitted.

It clearly states all the KSVs of downstream devices are passed back to the source for authentication. The source uses an XOR of a calculation of the KSVs to encrypt the data. This would be Ks the secret session key and all devices have to come up with this calculation and they must match. The encryption is not set to a given key by any device but the whole process is started and controlled by the source. A repeater (AVR) cannot act independently without the sources permission which is what your examples about separate authentication/encryption keys (KSVs) would allow.

Bob

I believe you are confusing elements of the authentication process with the encryption process.

It is true that in the authentication process, the display's keys are passed back to the source by the AVR for verification.

However, this has nothing to do with the encrytion key used by the AVR when encrypting the TMDS stream for transmission out to the display.

Here is what I believe you are missing: The key used by the AVR when encrypting the data for transmission to the display is produced by using a new shared key - one that exists between the AVR and display only. The key is produced by using the KSV of the AVR along with the private key sets of the AVR and/or Display.

Note in the below excerpt from a DCP white paper that the encrypted data "can only be decrypted by the receiver." That means the stream sent by the source can only be decrypted by the AVR. That stream could not be decrypted by the display. A new stream must be created/encrypted by the AVR using a shared key with the display, so that the display can decrypt the stream.

[Link: digital-cp.com]
Page 8
After authentication, the transmitter uses its HDCP cipher engine and the shared session key to create a stream of encrypted data that can only be decrypted by the receiver. The receiver uses its HDCP cipher engine and its copy of the session key to decrypt the content.

To elaborate on the above, Authentication Part 1 (from page 6 the DCP white paper above) is where the AVR and Display agree on the new encryption key used in the stream between the AVR and Display.

Authentication Part 2 - which is what you are referring to - is where the AVR sends the Display's key back to the Source so the Source may verify that the Display is authentic. However, this verification has nothing to do with the encryption key used between the AVR and Display. The key used for encryption between the AVR and Display is determined in Authentication Part 1 between the AVR and Display, which has nothing to do with the Source.

This has become a stupid debate that only serves the purpose of stroking crosen's ego. Does it help to diagnose issues with HDMI? Does it help to fix issues with HDMI? Does it help anyone figure out how to get a working system? Does it in any reasonable way enhance any one's practical comprehension of HDMI?

Aside from ego does it matter to a CI trying to get a working HDMI system how the data is encrypted? If we would all agree crosen is the smartest person on this board would it stop this thread? If we all agree he is right will it stop? Does it benefit any one save crosen's ego for this thread to continue? Is anything of use being learned? Does the method of encryption/decryption matter? It might to the cryptanalyst, to a hacker and it surely must to Hollywood. It might be of academic interest to some on this board but does it enhance any one's knowledge in any material way that matters?

Frank White used to begin his CEDIA courses by asking everyone attending why they were there. After taking all the usual answers he supplied the one every one missed but which mattered most. " You are here to learn how to use the knowledge learned here to go back home and make more money."

Does this debate meet the profit test?

Why would I go on and on with respect to poor Ed's JAP product? Because as crosen tendentiously has pointed out with quote upon quote source must authenticate sink. His product doesn't. In theory HDMI products can later be invalidated. To date none have but the threat of invalidation exists. The point is that legality in a product that can later be turned off is an issue of risk a CI needs to decide before committing to sell it into one of his systems.

crosen is stuck proving a tautology. For what reason? To what end? To demonstrate what? To prove he's the smartest guy in the room? He is the smartest guy in the room. There, it is said. Will it be enough? Will this endless, useless debate come to an end?

Would cosen deign to at least shed some light as to why he has gone on and on and on and on and on and on and on and on and on and on and on about a question that has is only of academic interest, that will make no money for the CI and for which the answer, as far as I can determine, sheds no light upon any issue he will need to solve to get a working system? Other than proving you're right, what is the purpose of this?

Alan

I don't know about the first part of your message, but this last question is useful and important. It's been asked several times, and I tried to answer it several times. But, I'll try to do so again.

Let's go back to the OP, and use that as an example. Here we have, among other things, the following pieces of info:

1. DVD through short HDMI to AVR through 50' HDMI to display has sparkles
2. DVD through 50' HDMI to TV does not have sparkles

The conclusions we can draw from this are very different depending on whether a) the AVR is "passing through" the signal without creating new timing and voltage, or b) the AVR is creating a fresh new signal.

If the AVR is creating a fresh new signal, then we can surmise one of two things are true. Either the the short HDMI from case 1. is the problem, or the problem is with the AVR's ability to generate a strong and clean enough signal to get through the 50' cable.

However, if the AVR is passing through the signal, then the signal loss issues through the short cable, AVR and 50' cable are all additive. We, therefore, cannot assume the issue is either with the short cable or the AVR, as we can in the other case.

So, making sure that we as CIs have a proper understanding of whether the AVR is passing through the signal or creating a new signal is important for us to apply the correct troubleshooting logic. (The discussion about encryption is in support of resolving which of these two possibilities is the case.)

This is just one example. I'm sure that together we could come up with many more.

I just read HDCP's paper.
[Link: digital-cp.com]

It works the way you describe. It definitely makes sense why there are so many HDMI problems. Too many devices trying to re-authenticate every 2 seconds.

BTW, I wasn't confusing authentication and encryption as the shared key is used in both as stated in the Crestron link.

HDCP wasn't part of 8b/10b when I was dealing with it and I'm glad it wasn't:-).


Regards,

Bob

I think that resolving whether the AVRs we use in our jobs just pass through HDMI or create a new signal is very important. I would be surprised if you honestly did not believe so, as well.

Several times in the past, I tried to resolve this through forum discussion, but was unable to overcome inconsistencies in the conclusions that were being reached. Each of those times, I let the issue ride.

When I saw an opportunity in this thread to try and resolve this for once and for all, I went for it. I may have pushed it too far. I don't know. I feel very close to having an answer. It's not worth alienating myself from this community, however, which I very much value participating in. I'll leave this alone for awhile.

Brent and Bob - thank you very much for your good natured and good faith contributions.

If anyone has new information on the topic, I'd appreciate a PM. Thanks.

There is so much wrong in your analysis and your trouble shooting technique that I haven't the patience to point it out.


It has been stated more times than I can count that the system does not work as you surmise. HDMI repeaters to not function as network repeaters taking in a signal and regenerating it bit for bit. In some cases, the AVR may regenerate 5v signal. In very few does it re-clock.

You theorize that there is no signal loss when the signal is run through a AVR. Wrong. Every connection point and every device extracts some signal loss. As in everything, simplify. You think you understand but you don't. You bring in keys but the keys don't matter? Not to the way the high speed data is transmitted. Taken to it's logical limits your argument would suggest that 127 different data streams would be sent if a source supported all 127 keys and a matrix existed that could send source to 127 sinks. The presence of the repeater in this system serves to obfuscate the data.

HDMI is a system. If you have a system that is on the borderline of working and add one more variable you push it into failure. It has zero to do with your theories. The best description of this is to use DPL ratings. If you need a 3 to have a working system and you have a product that is a 4 and one that is a 2 you have a working system. What if you add an other device that is a 2 to the system? You've introduced failure to the system and none of your musings on encryption will be of any help. Your short cable, the AVR itself may be introducing the failure and it may have zero to do with "signal retransmission."


What if your system is on the edge of working because you are using 50' cable with a 1080i source. Adding one more variable -cable, or device will brings you into failure? Secondly, there will be issues caused by heat that will end add capacitance to the system and cause failure. What of other types of repeaters? HDMI splitters, HDMI switches? Do these KSVs "retransmit" the signal too? But what is "retransmission?" Brent has informed us that in many cases it's restoring only the voltage and this by it self will not fix loss issues.

See sparkles? The issue is probably on the high speed data bus. Keep a restorer in your tool bag and add it to the system. Try it after the AVR. Try it before the AVR. Try putting 2 into the system, before and after the AVR. Does the system work? Where it works may tell you what is causing your problem, as if a CI will care much having finally fixed it.

Bob has already pointed out that many AVRs demand the full specification of 5v ( 4.7 -5v ) where displays are more tolerant. The problem is really the source and the fact that the AVR's designers took the specification seriously and designed their HDMI input around this fact. So running the cable directly from source to display may only tell you that the display will tolerate the badly designed source device whereas the AVR will not. Putting the restorer between source and AVR will fix this. Mightn't this explain the issue without resorting to the nonsense of how the data is encrypted or if it's retransmitted?

What would happen if the issue is really bad HDMI circuit design in the display? Again, you were in the standard deviation at 50 ft but adding 50.5 ft introduces issues; adding one more connector to the system introduces that much more capacitance to the system. An other display and it works fine. It has zero to do with what the AVR does or does not do.

Brent has suggested that no passive HDMI cable over 6m ever be used. Then there is the amount of data being carried over that cable. There is a lot less data in a cable box outputting a 480P signal so see what happens if you send a lower resolution signal down that cable . Does the system work? The amount of data/distance matters. Again, your eye pattern might just work at 50' for 1080P but not at 50.1 ft. Reduce the amount of data and voila, the system works.

If your argument had any weight and a repeater regenerating the signal was the critical factor, would not the AVR being in the system solve these problem rather than exacerbate it? Haven't you passed so much gas arguing that the presence of the KSVs prove the AVR regenerates the signal? Thus the AVR ought to be a solution to the high speed data bus issues much as signal restorers would be? But the OP is telling us that he has sparkles. The AVR hasn't fixed them but you've "proven" that AVRs will regenerate the signal. Is the only thing that matters is a solid positive and negative voltage? What of skew or timing issues? What of clock issues?

The best way to deal with HDMI is with the system analogy. Signal loss is added by connectors, by distance, by heat and by the number and type of devices in the system. If you only sell products with DPL ratings and keep them to devices with ratings of 4 or better you're lowering failure factors. Any time your system has a DPL value lower than 3 you should expect failure. Second, you never use a passive cable with a length greater than 6m. If you have to exceed 25-30 ft you use an active solution. Then there is the problem,(thank you, Bob ) of out of specification HDMI circuitry, particularly cable boxes that the AVR will not accept.

What we can be fairly certain of is that the problem has nothing to do with how the KSVs are being used, their used in encrypting/decrypting the high speed data stream, or if the AVR "retransmits" the signal.

Capacitance, inductance and resistance will create issues and these are cumulative in the system. Devices themselves create issues, particularly the design of the HDMI circuit. The amount of data being transmitted makes a difference. The way the cable was run makes a difference. The amount and severity of the cable bends makes a difference.

Edit: removed unnecessary and unhelpful comments

Alan

What kind of fool would try to argue how HDMI works with a person who's job is HDMI products?

Once again, I think you are confused about my argument, which is actually the opposite of what you assert. My argument is that the AVR does NOT regenerate the signal bit for bit. It couldn't repeat it bit for bit, because it needs to create new bits for transmission to the display using a new encryption key that the display can decrypt. So, it regenerates the signal using DIFFERENT bits (i.e. bits that can be decrypted by the display.)

I tried to explain this several times. It is the basis of my argument that you refute, yet you do not seem to have taken in this basic point.


If you agree that the AVR is sending a new stream of bits because of the nature of the encryption scheme, it may then seem clear that it MUST be generating new voltage and new timing. (Note, however, I am referring to timing only within a given channel of the TMDS stream. Timing between channels is another issue.)


If you accept that the AVR is generating a new stream of bits, you may then accept the notion of signal loss doesn't apply.


Actually, there would be more than 127 different streams. Specifically, there would be one unique stream for every HDMI transmitter/receiver pair in the configuration. This is fundamental to how HDCP encryption works. The encryption applied is different between every HDCP transmitter and receiver (ART not withstanding, but that does not apply here.) Bob has explained this as well. I'm not sure why you still do not understand this.


If I felt you truly were considering my argument, then I would be more receptive to your charge. Merely asserting it is not correct over and over does not really advance the discussion.


It depends. If the device is decrypting and then ecrypting the stream, then yes, it is creating a new outbound stream. If it does not engage in decryption, it is not necessarily creating a new stream. Are you starting to get it now? The act of decyrption and encryption requires the act of creating a new stream. That's the only way the next device in the chain can have the required key to decrypt the data.


Actually, not at all, and this shows a basic misconeption. If the AVR creates a new signal, there is no guarantee that this signal is as good as the signal it received. It could be better. It could be the same. It could be worse. The BD player may be generating a better signal (meaning a cleaner mask) than the AVR. That would explain why the BD player could send an image through the 50' cable when the AVR can not.

It's also possible that the AVR is sending the signal to spec and the BD player is not. In some cases, that could explain why the video locks in one case and not the other.


But, it is not added by a component in the chain that is creating a new signal.