*Thanks for all the comments on this video. I clearly made a couple of mistakes here, but then again this was quite experimental for me too. It's great to see how you guys are replying, explaining what I did wrong when probing the signals without being... (can't think of the word but I know what I mean)... about it. Same with a couple assumptions I made given what I was seeing but you know what, let's have a followup video to try some measurements again after the weekend and look into some of the various suggestions in the comments. There are at least a couple of things I want to add myself about the design of this PCB and how I think it could be easily improved. Well maybe it's an improvement but what do I know 🤐 lol I'm sure Detlef will have a few things to say too. So keep the comments and suggestions coming*
Hi Rich, personally from my point of view there needs to be a ground plane and try to keep all the signal traces the same length and on the same side of the board to reduce the noise to a minimum. Also the chip you use for clock recovery needs to have very sharp rise and fall times or you'll get issues. This might work for 1080p30 but as you get to higher resolutions you'll get cross talk, inductive loading and it'll fail to work. There should also be an ESD chip in the mix too to prevent you damaging the output and input chips at either end, TI make them that match the HDMI connector pinout almost exactly for the above reasons. As always though, for testing (not production use) it's worth a go. You don't learn anything without trying so I take my hat of to you!
Richard, I think you need to look at the signals again but this time compare D0+ to D0- and not D0+ to D1-. I believe you will find that the two data lines are not always out of phase by 180 degrees and that you cannot "reconstruct" a data channel from just one signal line as you have proposed. Another way to look at differential signals without a special probe is to use A plus B channels with B inverted or A minus B if your scope has that math capability. You can then see the "original" data. Regards, David
On the practicalities of recovering a missing signal, I do not know enough to comment. Watching the Code3r channel repairing PS4 and the like, it appears that all the signal lines have a very tight tolerance for there physical length. When the lengths get out of balance, the signals get out of synch due to the high frequency. Therefore, I think Deft needs to add some squiggles in the paths. Secondly, if mounting this inside a 'tin', it may be good to get PcbWay to add some mounting holes as using 'snotty hot glue' would let the project down. Last point, as a teaching aid or a break out board making it easier to probe the paths, It stands up anyway.
Hi Richard, in regards to your first point with regards as to have the data still work if one of the lines are dead. I worked with CAN a number of years ago, and though I am not sure if all the CAN-drivers are like it, the CAN-drivers that I used, functioned like that. If one of the lines are faulty, the receiver could recover the data from that single line, albeit with lower noise immunity.
Interesting project. CEC messages are also very interesting. If you could touch on it, how to maybe decode them or even better send them over to either end.
Richard, sorry to pop your balloon, but you are confusing dotclock and TMDS/LVDS/bit clock here. A dotclock is the actual pixel clock, whereby each clock pulse is a new, whole, pixel. These days pixels are usually 24 or 30bits, 3 times 8 or 10bits, or 8 or 10 bits per channel (RGB or even YUV). In the olden days of analog colour values (like with VGA), you really had all data in parallel, and the dotclock was the one and only clock. And many smaller panels for embedded boards (unless you go SPI) are actually driven with 16/18/24 data lines and the clock is indeed the dotclock or pixel clock. But with TMDS, unlike with direct LVDS as used in many LCD panels, you do not have one differential pair per pixel-bit, you have one differential pair per colour channel. TMDS has a special encoding, encapsulating 8 bits in 10 bits. These are sent serially, and differentially, over 4 twisted pairs of wires, one pair carrying the clock, the other three pairs carrying the three separate colour channels. For the original HDMI 1.0, which was mostly DVI with some use for the blanking and HDCP added in, the maximum dotclock is 165MHz, and the actual clocking of the LVDS signal is max 1650MHz, or 1.65GHz. So you are not dealing with 165MHz signals here, you are dealing with an order of magnitude more, and then you not only need a suitable scope, you also need to keep the signal paths equal length, and you need logic capable of handling such bandwidths. So while your idea has some limited merit (i feel that perhaps if you are missing the clock signal, you perhaps should fix the tmds transmitter or the signal path in between), it is not practical due to the bandwidths we are dealing with here. -- your open source display driver developing subscriber.
Thanks for the information, if this project serves no other purpose then at the very least it is an education into why this can't be done, and that I think is a good thing in itself 🙂
Hi Richard, greetings from Australia :-} . What I had in mind (perhaps as an addition to your ideas), to check an integrity of a single HDMI cable. You could connect it in the loop (one end to the input, the other to the output) and see if all wires have continuity and they are not crossed. Say, even using LEDs for each "channel". Sometimes I have to repair or extend the HDMI cable and it would be good way to see what wire connects (or should connect) with what on the other side. So far I am using multi-meter, but this is very laborious way. Regards, Jerry.
Yes that is how I tested I had the HDMI sockets soldered correctly when I built the board - I looped one to the other with a HDMI cable. At first I thought I had a problem but could not see where it is until I realised the cable I had picked up was actually faulty
Yes, you could probably bodge something up to regen signals, but economically, you just replace the board or faulty component quicker/cheaper than trying to engineer something.
Unless the signal is the same on all 3 TMDS lines/channels, this isn't the correct pair. Shouldn't it be D0+ and D0-? I'm reading the specs right now, might edit this later@@andymouse
It happens. As they say, the only way not to make a mistake is to not do anything. Look for example at 10:00 mark, pins you are measuring from are next to one another, but on the same TMDS channel, there's a shield pin between them. As I understand from reading HDMI specs, the 3 TMDS channels are for red, green and blue, and I was wondering why the scope signals are not as symmetric as they should be. While similar, which can happen if you're sending gray color, there are differences that are not due to noise. Anyways, great video, I've learned a lot from you. Keep it up!👍 @@LearnElectronicsRepair
Does somebody have more information about the 'no data' with a static image? Because that’s new to me. Also, what scope were you using? To my understanding the bit stream frequency is 7 times the clock frequency - at least for LVDS/FPD-Link. Look up VESA encoding for more information. To my understanding there is also a small difference between HDMI and FPD-Link, otherwise you wouldn’t need HDMI/DVI to FPD-Link converter ICs. But don’t ask me what the actual differences are. Would also not fit to the scope of this video.
@@LearnElectronicsRepair I see. Your DS1052E might not be fast enough here. Assuming Full HD (1920x1080x60Hz) you are at minimum 125 MHz pixel clock (ignoring front and back porchfor the moment) for the HDMI clock signal. If HDMI encoding is similar to LVDS then the differential pair data rate will be around 870 MHz (7x) each. This frequency might be an issue for your active electronic manipulation. 1 GHz is 1 ns so your goal likely is a jitter/propagation delay of 100 ps or so. Last time I checked a 74HC gate wasn’t that fast. Edit: Just saw that @luc_libv_verhaegen already mentioned the clock vs. data rate point with LVDS/TDMS.
@@ThePetaaaaa It could be a limiting factor. On another video I did have the Rigol connected to an RF signal generator and it was able to clearly display and correctly identify the frequency of a signal at over 220MHz which is way beyond it's spec.
@@LearnElectronicsRepair I see, good to know! I would be expect something like 3 dB attenuation but aren’t a RF expert. Now I’m intrigued and want to test my 1054Z. But from 220 MHz there is still some way to about 1 GHz.
Would it not have been better if the middle row was connected by default via PCB jumpers that can be cut if need be, since usually you would want to only monitor the signals? Secondly, you are probably seeing a lot more noise than necessary due to ground loops using the oscilloscope ground leads, I would have brought out a ground pin right next to each signal pin so you could connect the oscilloscope probes with that "springy thingy" that comes with the probes and removing the ground lead? Finally, this is really something for a logic analyzer rather than a cheap oscilloscope I think, Salea logic (I think that is how it is spelled) has PC software that has an analyzer for HDMI/CEC and it works with their and several third party logic analyzer devices.
HI Tech-Relief I have one of the Saleae Logic 16 analyzers here - you have to bear in mind this is video is all very experimental and trying to push the boundaries a bit yeah? But I believe with the skills and input we have here we can do something a bit special so keep on inputting your knowledge and who knows where it may go 🙂
If this is a full HD monitor then the data bandwidth might be around 1 GHz. I don’t think my cheap clone of a Salea 24 MHz logic analyzer would be fast for that. With everything else I fully agree.
@@ThePetaaaaa Indeed but the sales logic people sell expensive units that would work. There may be cheaper logic analyzers that can handle it. My 350 Mhz oscilloscope has an LA function that will do it but it does not have a feature to analyze the signals...
Strange. It's 22C here at night. Well at least it was at 11pm tonight while we were our foe a meal and some drinks outdoors but it will probably drop to about 16C just before dawn. It can't really get much below that as the ocean is at 16C in winter, we live about 1 mile from the coast but the furthest you can get away from the ocean on the island is 12 miles. The lowest ever recorded here at night was 12.5C, something I hope doesn't happen again any time soon
It is -29 °C (-20.2 °F) at my place at the moment. The overnight low is supposed to be -37 °C (-34.6 °F), which is an improvement on the -39 °C that was forecast a couple of days ago."Wind chill" tonight is forecast to be around -48 °C, -54 °F (that'basically means that exposed human skin would perceive the temperature to be the equivalent of -48 °C still air - exposed skin won't feel anything after a few minutes).
@@budgetmerch "that is cold." Uhhh, no. Cold is when you have to build a fire under your propane tank to get the propane to vaporize fast enough to supply your furnace. It's a tad risky, but not as bad as it sounds.
I think that recovering a clock signal from the data is possible, since it is similar to a tracking oscillator to recover a local oscillator for signals from space craft that I once heard about. The idea, as I vaguely remember it, is to feed the noisy signal and the output of a voltage controlled oscillator into a phase comparator and use feedback from the output of the phase comparator to control the frequency of the VCO. This will effectively average the phase difference over some number of cycles of the signal to control the phase and frequency of the VCO. I believe that with digital signals an exclusive or chip can be used as a cheap and fast phase comparator, but that memory is old and fuzzy.
Great video as always Richard :) I actually got a idea for a addon board for this thing 🤣😂 why dont we make a addon board that jumpers the connections but has small SMD leds for each line(Probably needs , transistors to boost voltages to show the data on all outputs) then u can see the leds actually flashing and transferring data , ofc the noise will probably trigger the LEDS. fun visual concept at least :P I will rig up a small test board :D for 1 data pair Have a nice one Richard
*Thanks for all the comments on this video. I clearly made a couple of mistakes here, but then again this was quite experimental for me too. It's great to see how you guys are replying, explaining what I did wrong when probing the signals without being... (can't think of the word but I know what I mean)... about it. Same with a couple assumptions I made given what I was seeing but you know what, let's have a followup video to try some measurements again after the weekend and look into some of the various suggestions in the comments. There are at least a couple of things I want to add myself about the design of this PCB and how I think it could be easily improved. Well maybe it's an improvement but what do I know 🤐 lol I'm sure Detlef will have a few things to say too. So keep the comments and suggestions coming*
Hi Richard, Thank you, I now understand LVDS its been bugging me for a ages.
Hi Rich, personally from my point of view there needs to be a ground plane and try to keep all the signal traces the same length and on the same side of the board to reduce the noise to a minimum. Also the chip you use for clock recovery needs to have very sharp rise and fall times or you'll get issues. This might work for 1080p30 but as you get to higher resolutions you'll get cross talk, inductive loading and it'll fail to work. There should also be an ESD chip in the mix too to prevent you damaging the output and input chips at either end, TI make them that match the HDMI connector pinout almost exactly for the above reasons.
As always though, for testing (not production use) it's worth a go. You don't learn anything without trying so I take my hat of to you!
Richard, I think you need to look at the signals again but this time compare D0+ to D0- and not D0+ to D1-. I believe you will find that the two data lines are not always out of phase by 180 degrees and that you cannot "reconstruct" a data channel from just one signal line as you have proposed. Another way to look at differential signals without a special probe is to use A plus B channels with B inverted or A minus B if your scope has that math capability. You can then see the "original" data. Regards, David
On the practicalities of recovering a missing signal, I do not know enough to comment. Watching the Code3r channel repairing PS4 and the like, it appears that all the signal lines have a very tight tolerance for there physical length. When the lengths get out of balance, the signals get out of synch due to the high frequency. Therefore, I think Deft needs to add some squiggles in the paths. Secondly, if mounting this inside a 'tin', it may be good to get PcbWay to add some mounting holes as using 'snotty hot glue' would let the project down. Last point, as a teaching aid or a break out board making it easier to probe the paths, It stands up anyway.
Hi Richard, in regards to your first point with regards as to have the data still work if one of the lines are dead. I worked with CAN a number of years ago, and though I am not sure if all the CAN-drivers are like it, the CAN-drivers that I used, functioned like that. If one of the lines are faulty, the receiver could recover the data from that single line, albeit with lower noise immunity.
What about a cable tester? To determine if the cable is good and the highest bandwith or resolution a cable could reliably support.
Heya, this all is new stuff for me so I'm only learning more and more thanks
Interesting project. CEC messages are also very interesting. If you could touch on it, how to maybe decode them or even better send them over to either end.
Thanks for the suggestion 🙂
Richard, sorry to pop your balloon, but you are confusing dotclock and TMDS/LVDS/bit clock here.
A dotclock is the actual pixel clock, whereby each clock pulse is a new, whole, pixel. These days pixels are usually 24 or 30bits, 3 times 8 or 10bits, or 8 or 10 bits per channel (RGB or even YUV). In the olden days of analog colour values (like with VGA), you really had all data in parallel, and the dotclock was the one and only clock. And many smaller panels for embedded boards (unless you go SPI) are actually driven with 16/18/24 data lines and the clock is indeed the dotclock or pixel clock.
But with TMDS, unlike with direct LVDS as used in many LCD panels, you do not have one differential pair per pixel-bit, you have one differential pair per colour channel. TMDS has a special encoding, encapsulating 8 bits in 10 bits. These are sent serially, and differentially, over 4 twisted pairs of wires, one pair carrying the clock, the other three pairs carrying the three separate colour channels.
For the original HDMI 1.0, which was mostly DVI with some use for the blanking and HDCP added in, the maximum dotclock is 165MHz, and the actual clocking of the LVDS signal is max 1650MHz, or 1.65GHz.
So you are not dealing with 165MHz signals here, you are dealing with an order of magnitude more, and then you not only need a suitable scope, you also need to keep the signal paths equal length, and you need logic capable of handling such bandwidths. So while your idea has some limited merit (i feel that perhaps if you are missing the clock signal, you perhaps should fix the tmds transmitter or the signal path in between), it is not practical due to the bandwidths we are dealing with here.
-- your open source display driver developing subscriber.
I'm actually surprised any usable signal makes it through such a crude breakout board.
@@d614gakadoug9 Well it id give a picture which I guess is what LVDS is designed to do 😉
Thanks for the information, if this project serves no other purpose then at the very least it is an education into why this can't be done, and that I think is a good thing in itself 🙂
Hi Richard, greetings from Australia :-} . What I had in mind (perhaps as an addition to your ideas), to check an integrity of a single HDMI cable. You could connect it in the loop (one end to the input, the other to the output) and see if all wires have continuity and they are not crossed. Say, even using LEDs for each "channel". Sometimes I have to repair or extend the HDMI cable and it would be good way to see what wire connects (or should connect) with what on the other side. So far I am using multi-meter, but this is very laborious way. Regards, Jerry.
Yes that is how I tested I had the HDMI sockets soldered correctly when I built the board - I looped one to the other with a HDMI cable. At first I thought I had a problem but could not see where it is until I realised the cable I had picked up was actually faulty
Yes, you could probably bodge something up to regen signals, but economically, you just replace the board or faulty component quicker/cheaper than trying to engineer something.
That could be true but then there is the f**k me we actually did it *fun* factor yeah?
Wait a sec, aren't you measuring/capturing D0+ and D1- on the scope?
Whats your thoughts ?
Unless the signal is the same on all 3 TMDS lines/channels, this isn't the correct pair. Shouldn't it be D0+ and D0-? I'm reading the specs right now, might edit this later@@andymouse
I'm looking too. Cheers for the reply@@chikaBurton
If so I messed up!
It happens. As they say, the only way not to make a mistake is to not do anything. Look for example at 10:00 mark, pins you are measuring from are next to one another, but on the same TMDS channel, there's a shield pin between them. As I understand from reading HDMI specs, the 3 TMDS channels are for red, green and blue, and I was wondering why the scope signals are not as symmetric as they should be. While similar, which can happen if you're sending gray color, there are differences that are not due to noise. Anyways, great video, I've learned a lot from you. Keep it up!👍 @@LearnElectronicsRepair
10:29 is there a way to have 2 of these setup to restart each other? This way they would run forever?
Does somebody have more information about the 'no data' with a static image? Because that’s new to me.
Also, what scope were you using? To my understanding the bit stream frequency is 7 times the clock frequency - at least for LVDS/FPD-Link. Look up VESA encoding for more information.
To my understanding there is also a small difference between HDMI and FPD-Link, otherwise you wouldn’t need HDMI/DVI to FPD-Link converter ICs. But don’t ask me what the actual differences are. Would also not fit to the scope of this video.
Its a Rigol
@@LearnElectronicsRepair I see. Your DS1052E might not be fast enough here.
Assuming Full HD (1920x1080x60Hz) you are at minimum 125 MHz pixel clock (ignoring front and back porchfor the moment) for the HDMI clock signal. If HDMI encoding is similar to LVDS then the differential pair data rate will be around 870 MHz (7x) each.
This frequency might be an issue for your active electronic manipulation. 1 GHz is 1 ns so your goal likely is a jitter/propagation delay of 100 ps or so. Last time I checked a 74HC gate wasn’t that fast.
Edit: Just saw that @luc_libv_verhaegen already mentioned the clock vs. data rate point with LVDS/TDMS.
@@ThePetaaaaa It could be a limiting factor. On another video I did have the Rigol connected to an RF signal generator and it was able to clearly display and correctly identify the frequency of a signal at over 220MHz which is way beyond it's spec.
@@LearnElectronicsRepair I see, good to know! I would be expect something like 3 dB attenuation but aren’t a RF expert. Now I’m intrigued and want to test my 1054Z.
But from 220 MHz there is still some way to about 1 GHz.
Would it not have been better if the middle row was connected by default via PCB jumpers that can be cut if need be, since usually you would want to only monitor the signals? Secondly, you are probably seeing a lot more noise than necessary due to ground loops using the oscilloscope ground leads, I would have brought out a ground pin right next to each signal pin so you could connect the oscilloscope probes with that "springy thingy" that comes with the probes and removing the ground lead? Finally, this is really something for a logic analyzer rather than a cheap oscilloscope I think, Salea logic (I think that is how it is spelled) has PC software that has an analyzer for HDMI/CEC and it works with their and several third party logic analyzer devices.
>logic analyzer
Why many word when less work too! I'll agree when you buy me one;)
HI Tech-Relief
I have one of the Saleae Logic 16 analyzers here - you have to bear in mind this is video is all very experimental and trying to push the boundaries a bit yeah? But I believe with the skills and input we have here we can do something a bit special so keep on inputting your knowledge and who knows where it may go 🙂
If this is a full HD monitor then the data bandwidth might be around 1 GHz.
I don’t think my cheap clone of a Salea 24 MHz logic analyzer would be fast for that. With everything else I fully agree.
@@ThePetaaaaa Indeed but the sales logic people sell expensive units that would work. There may be cheaper logic analyzers that can handle it. My 350 Mhz oscilloscope has an LA function that will do it but it does not have a feature to analyze the signals...
Sweet!!!
I need to make stuff.
I'm stuck in my house because the temp dropped to 7 degrees Fahrenheit...
First go and grab a couple of wool blankets and buy a Chinese diesel heater, or something - Jesus Wept, that is cold.
Strange. It's 22C here at night. Well at least it was at 11pm tonight while we were our foe a meal and some drinks outdoors but it will probably drop to about 16C just before dawn. It can't really get much below that as the ocean is at 16C in winter, we live about 1 mile from the coast but the furthest you can get away from the ocean on the island is 12 miles. The lowest ever recorded here at night was 12.5C, something I hope doesn't happen again any time soon
It is -29 °C (-20.2 °F) at my place at the moment. The overnight low is supposed to be -37 °C (-34.6 °F), which is an improvement on the -39 °C that was forecast a couple of days ago."Wind chill" tonight is forecast to be around -48 °C, -54 °F (that'basically means that exposed human skin would perceive the temperature to be the equivalent of -48 °C still air - exposed skin won't feel anything after a few minutes).
@@budgetmerch
"that is cold."
Uhhh, no.
Cold is when you have to build a fire under your propane tank to get the propane to vaporize fast enough to supply your furnace. It's a tad risky, but not as bad as it sounds.
@@d614gakadoug9 Touché! Couldn't even imagine -29°C.
Look at how you’re connected .. i.e. need the two channels to (i.e.) D0+ and D0- .. the shields are ground.
I think that recovering a clock signal from the data is possible, since it is similar to a tracking oscillator to recover a local oscillator for signals from space craft that I once heard about. The idea, as I vaguely remember it, is to feed the noisy signal and the output of a voltage controlled oscillator into a phase comparator and use feedback from the output of the phase comparator to control the frequency of the VCO. This will effectively average the phase difference over some number of cycles of the signal to control the phase and frequency of the VCO. I believe that with digital signals an exclusive or chip can be used as a cheap and fast phase comparator, but that memory is old and fuzzy.
Great video as always Richard :)
I actually got a idea for a addon board for this thing 🤣😂
why dont we make a addon board that jumpers the connections but has small SMD leds for each line(Probably needs , transistors to boost voltages to show the data on all outputs) then u can see the leds actually flashing and transferring data , ofc the noise will probably trigger the LEDS. fun visual concept at least :P I will rig up a small test board :D for 1 data pair
Have a nice one Richard
Hi Richard... youcare a little bit slipped at your measure points .
Great Video and explaination 👍👍👍