... The problem right now may be that the total swing is a bit too large if driven all the way from 0V to 3.3V and this could possibly affect the CML receivers. The operating DC differential signal at the sink itself is meant to be kept under 1.2V, which for each single ended signal I think means seeing voltages no less than 600mV below the 3.3V termination bias voltage at the receiver. Another part of the DVI spec I read mentions the maximum differential swing is 1.56V for AC signals.
Combining those two, 600mV into 50 ohms, is 12mA and 12mA into 20 ohms is 240mV, and the series R needed is ((3.3-50*12m)-(20*12m))/12m = 205 Ohms
So a series coupling resistor of 180 ohms should be about right. ( for DC coupled HDMI)
That may work too if the DAC method is not possible at the HDMI bitrates - the series resistance offers some extra protection too which is an advantage.
Perhaps you could also look at driving with 75 ohms but adding a 150 ohm resistor to 3v3, to give an effective 50 ohm source impedance. This would have a slight voltage divider effect on the dac
Yes that would help keep impedances matched to reduce reflections, but on top of that voltage divider effect you'd now need to select (8/16) of the maximum DAC voltage as the "logic low" DAC level and keep 3.3V as the high level point. When applied to the (3.3V-1.1V=2.2V) scaled+offset source voltage range due to the 150 ohm parallel resistor, I think that brings the single ended voltage across the termination close to 600mV at the sink. (8/16)*3.3V*(2/3)*(50/100) =550mV.
Update: Tubular/Chip, a P2-Eval HDMI breakout board could probably be reworked to test this 150 ohm pullup approach out. Right now it is just a pass through board. 8 small SMD pullup resistors could be soldered underneath the connector to a common 3.3V, though the holes need to be clear of solder so it may be a bit tricky to do cleanly.
Perhaps you could also look at driving with 75 ohms but adding a 150 ohm resistor to 3v3, to give an effective 50 ohm source impedance. This would have a slight voltage divider effect on the dac
3ns is fairly slow, at the pixel speeds involved.
The DACs also have range limits and I'm not sure how the impedance changes with DAC value, or how the lower impedance ones react with a pullup to Vcc loading...
Usually, they drive a load to GND.
eg Data says this :
%VV = PinA DAC config
00: 990 ohm, 3.3 volt range
01: 600 ohm, 2.0 volt range
10: 123.75 ohm, 3.3 volt range
11: 75 ohm, 2.0 volt range
123.75 ohm, 3.3 volt range DAC may be able to be set to sink the desired 12mA ?
I did some tests and the BIT_DAC drive mode that translates bit OUT states to 4-bit-resolution DAC levels works for HDMI.
My HDMI TV needs to see only a 1-step-level difference in 123-ohm DAC mode to receive the HDMI data, while a 3-step-level difference is needed in 990-ohm DAC mode.
Any of the following lines can be inserted into the setup section of the HDMI code above to used DAC levels, instead of fast digital outputs:
I also found that the 1.5K-ohm digital drive works fine, though 15k-ohm does not. Also, the 1mA digital drive works, but the 100uA does not.
So, I think there are lots of ways to meet the HDMI impedance requirements. Certainly, BIT_DAC mode with an appropriate resistor between pin pairs would do the job. It would be better to use the 3.3V DAC modes, even though they are higher-impedance than the 2.0V DAC modes, since the external resistor between pin pairs could take the heat, instead of the internal pull-down resistor used for 2.0V DAC modes.
Sounds pretty good Chip, interesting to see even 990 ohms had the strength to drive HDMI.
Yes, the test HDMI platform Chip uses here seems quite tolerant really.
The 1mA test pass suggests the end signal level can be as low as +/- 50mV and still work (typically). Just 1 LSB delta on 123 ohm DAC, suggests even lower signal limits.
5~10mA sound like it would be ok.
This is also a very good demo/example of underlying DAC speed.
Today I got HDTV 1080P component video working. This uses just three pins (Y, Pb, Pr). No jitter. Everything's running at 148.5MHz. I will try other clock combos next.
Here is the code:
'***************************************************
'* HDTV 1080P component Y-Pb-Pr, 16bpp 5:6:5 RGB *
'***************************************************
CON
s = 60 'scales DAC output (s = 0..128)
sync_color1 = $000000_00
sync_color2 = (-105*s/128) & $FF 'sync- on all three outputs
sync_color3 = (+105*s/128) & $FF 'sync+ on all three outputs
DAT org
'
'
' Setup
'
hubset clkinit1 'set clock to 148.5MHz
waitx clkwait
hubset clkinit2
rdfast ##640*350*2/64,##$1000 'set rdfast to wrap on bitmap
setxfrq ##$8000_0000 'set transfer frequency to clk rate
setcy cy_ 'Y set colorspace for Y-Pb-Pr
setci ci_ 'Pb
setcq cq_ 'Pr
setcmod #%01_1_111_0 'enable colorspace conversion
wrpin dacmode_rgb,#2<<6 + 1 'enable dac modes in pins 3,2,1 for Y,Pb,Pr
drvl #2<<6 + 1 'enable dac outputs
'
'
' Field loop
'
field mov x,#35 'top blanks
call #blank
mov x,##1080 -30 'set visible lines
line call #hsync 'do horizontal sync
xcont m_60,#sync_color1 'porch
xcont m_1920v,#1 'visible line
djnz x,#line 'another line?
mov x,#4 +30 'bottom blanks
call #blank
mov x,#10 'low vertical syncs
.vsync1 call #hsync
xcont m_880,#sync_color2
djnz x,#.vsync1
mov x,#10 'high vertical syncs
.vsync2 call #hsync
xcont m_880,#sync_color1
djnz x,#.vsync2
jmp #field 'loop
'
'
' Subroutines
'
blank call #hsync 'blank lines
xcont m_1980,#sync_color1
_ret_ djnz x,#blank
hsync xcont m_44,#sync_color1 'horizontal sync
xcont m_44,#sync_color2
xcont m_44,#sync_color3
_ret_ xzero m_88,#sync_color1
'
'
' Initialized data
'
clkinit1 long %1_100111_0100101000_1111_10_00 '20MHz / 40 * 297 * 1 = 148.5MHz
clkinit2 long %1_100111_0100101000_1111_10_11
clkwait long 20_000_000 / 200
dacmode_rgb long %0000_0000_000_1011100000000_01_00000_0 '75-ohm 2.0V
cy_ long ((+27*s/128) & $FF) << 24 + ((+92*s/128) & $FF) << 16 + (( +9*s/128) & $FF) << 8 + 80
ci_ long ((-15*s/128) & $FF) << 24 + ((-49*s/128) & $FF) << 16 + ((+64*s/128) & $FF) << 8 + 128
cq_ long ((+64*s/128) & $FF) << 24 + ((-58*s/128) & $FF) << 16 + (( -6*s/128) & $FF) << 8 + 128
m_44 long $7F010000+44 'syncs/blanks
m_88 long $7F010000+88
m_60 long $7F010000+60
m_880 long $7F010000+880
m_1920 long $7F010000+1920
m_1980 long $7F010000+1980
m_1920v long $BF050000+1920 'visible rfword rgb16 (5:6:5)
x res 1
'
'
' Bitmap
'
orgh $1000 - 70 'justify pixels at $1000
file "birds_16bpp.bmp" 'rayman's picture (640 x 350)
Excellent news Chip. That was the clock mode that gave me the jitter on the ES chip.
Yes. I'm dividing the 20MHz crystal by 40, then multiplying it by 297. No visible jitter. I just changed the main clock frequency to 250MHz and I'm now running the streamer at 148.5MHz. Looks fine.
Now I want to see if it's possible to signal modes higher-resolution than 1920x1080p using Y-Pb-Pr. Sure would be nice if they had compact 4-wire connectors for this component video (Y, Pb, Pr, GND).
I think Parallax sells products with a "Mini TRRS audio/video jack".
I believe this is also what my relatively new OLED TV uses for component input...
I.e., there is no more RCA jacks for component on the best TVs now, just a hole for a 4-conductor jack.
Fortunately, mine came with the little cable adapter needed.
My 2018 model 4K TV doesn't even have component inputs at all, just HDMI and AV (composite + audio as 3 RCAs).
Component input is going away for the most part.
Using a TRRS for YPbPr has been fairly common for a while. Altough why they need to save space on the back of a giant TV is beyond me. You'd think that making the PCB bigger is cheaper than including all these adapters.
With the previous P2ES, I tried to get a 4k monitor to display 2560 x (various combos) but without success. It only seemed happy to go to 1920 x (1440? 1280?). But it would be good to try with other monitors.
Look forward to you checking out the front end analog cap changes too. Curious were the cutoff frequency is
Of course it's possible. But whether the display can handle it is another story. 2048x1536 is a common max. resolution of VGA outputs, YPbPr should be capable of that, too.
Of course it's possible. But whether the display can handle it is another story. 2048x1536 is a common max. resolution of VGA outputs, YPbPr should be capable of that, too.
The only way I could figure out how to do 1080p via Y-Pb-Pr was from this obscure document (see attached). Google searches seem completely fruitless for figuring this stuff out.
If I remember, HDTV's are picky about signal timing. It has to be pretty exact for them to respond, at all. I know we have the bandwidth to signal 1440p, or even 2160i, if such a format exists.
Rogloh and I both have a dell monitor that supports 1920 x 1200 and takes component amongst other things, would your test code work with the prior P2ES chip for component video output? If so we could try this and see whether 1920x1200 is attainable
The movie companies did not want to allow even 1080p over component analog.
People can capture it as easily as we can stream it. That was the argument.
Many displays do 1080p anyway, but the top was supposed to be 1080i.
I suspect no higher resolutions are rooted in politics, nothing technical. The higher definition streams favor YCbCr color space anyway. It is larger than RGB and allows for some operations to be performed cheaply.
There are protocols used by security cameras to transmit 1080p30 and 4k15 over a single coax line. e.g. AHD. Converter boxes to convert AHD to HDMI are available starting at $50. It's questionable whether some of these converter boxes can output HDMI above 1080p.
The specs are probably not available so we would need to reverse engineer it.
The maximum component resolution may be limited by the sample rate of the ADCs. It might be possible to reduce the frame rate while increasing resolution, so the dotclock stays the same.
There are protocols used by security cameras to transmit 1080p30 and 4k15 over a single coax line. e.g. AHD. Converter boxes to convert AHD to HDMI are available starting at $50. It's questionable whether some of these converter boxes can output HDMI above 1080p.
The specs are probably not available so we would need to reverse engineer it.
The maximum component resolution may be limited by the sample rate of the ADCs. It might be possible to reduce the frame rate while increasing resolution, so the dotclock stays the same.
I doubt there is much influence being placed on the manufacturers. It certainly doesn't take much coaxing to ditch support for anything other than mainstream. I just had a look at the latest TVs at a local shop. The cheap ones mostly still had component and composite, not many had VGA.
The large expensive models had nothing but a bundle of HDMIs and two (satellite and terrestrial) digital aerial inputs. And Wifi, Ethernet and USB of course. Some even have nothing but one special slim plug with a separate interface box but still not a single component or VGA on those ones either.
There are protocols used by security cameras to transmit 1080p30 and 4k15 over a single coax line. e.g. AHD. Converter boxes to convert AHD to HDMI are available starting at $50. It's questionable whether some of these converter boxes can output HDMI above 1080p.
The specs are probably not available so we would need to reverse engineer it.
The maximum component resolution may be limited by the sample rate of the ADCs. It might be possible to reduce the frame rate while increasing resolution, so the dotclock stays the same.
No, no, no, no, please no! Now that we use LCDs, it should be fine to output 30p, 24p, or even 15p. I'm hoping we can do 720p30 over HDMI.
720p60 signals at 74.25MHz. Half that would be 37.125MHz, which would need 371.25 MHz for HDMI. That would barely work.
Ok then, 720p24 at 29.7MHz. Or 720p15 at 18.5625MHz. I should be able to get that on my P2ES board. I might have to try just to see how many displays will handle it.
Comments
Combining those two, 600mV into 50 ohms, is 12mA and 12mA into 20 ohms is 240mV, and the series R needed is ((3.3-50*12m)-(20*12m))/12m = 205 Ohms
So a series coupling resistor of 180 ohms should be about right. ( for DC coupled HDMI)
What was the settling time on these DACs again, Chip? Were they 3ns?
[edit: found it, yes they are 3nsec] - https://forums.parallax.com/discussion/comment/1364259/#Comment_1364259
Update: Tubular/Chip, a P2-Eval HDMI breakout board could probably be reworked to test this 150 ohm pullup approach out. Right now it is just a pass through board. 8 small SMD pullup resistors could be soldered underneath the connector to a common 3.3V, though the holes need to be clear of solder so it may be a bit tricky to do cleanly.
3ns is fairly slow, at the pixel speeds involved.
The DACs also have range limits and I'm not sure how the impedance changes with DAC value, or how the lower impedance ones react with a pullup to Vcc loading...
Usually, they drive a load to GND.
eg Data says this :
%VV = PinA DAC config
00: 990 ohm, 3.3 volt range
01: 600 ohm, 2.0 volt range
10: 123.75 ohm, 3.3 volt range
11: 75 ohm, 2.0 volt range
123.75 ohm, 3.3 volt range DAC may be able to be set to sink the desired 12mA ?
My HDMI TV needs to see only a 1-step-level difference in 123-ohm DAC mode to receive the HDMI data, while a 3-step-level difference is needed in 990-ohm DAC mode.
Any of the following lines can be inserted into the setup section of the HDMI code above to used DAC levels, instead of fast digital outputs:
I also found that the 1.5K-ohm digital drive works fine, though 15k-ohm does not. Also, the 1mA digital drive works, but the 100uA does not.
So, I think there are lots of ways to meet the HDMI impedance requirements. Certainly, BIT_DAC mode with an appropriate resistor between pin pairs would do the job. It would be better to use the 3.3V DAC modes, even though they are higher-impedance than the 2.0V DAC modes, since the external resistor between pin pairs could take the heat, instead of the internal pull-down resistor used for 2.0V DAC modes.
Sounds like you're on a roll! Congratulations!
Yes. It needed three 4-bit DAC steps to get sufficient Vdiff, but the 1mA digital drive mode worked, too. That might be the most power-economical.
Yes, the test HDMI platform Chip uses here seems quite tolerant really.
The 1mA test pass suggests the end signal level can be as low as +/- 50mV and still work (typically). Just 1 LSB delta on 123 ohm DAC, suggests even lower signal limits.
5~10mA sound like it would be ok.
This is also a very good demo/example of underlying DAC speed.
Here is the code:
'*************************************************** '* HDTV 1080P component Y-Pb-Pr, 16bpp 5:6:5 RGB * '*************************************************** CON s = 60 'scales DAC output (s = 0..128) sync_color1 = $000000_00 sync_color2 = (-105*s/128) & $FF 'sync- on all three outputs sync_color3 = (+105*s/128) & $FF 'sync+ on all three outputs DAT org ' ' ' Setup ' hubset clkinit1 'set clock to 148.5MHz waitx clkwait hubset clkinit2 rdfast ##640*350*2/64,##$1000 'set rdfast to wrap on bitmap setxfrq ##$8000_0000 'set transfer frequency to clk rate setcy cy_ 'Y set colorspace for Y-Pb-Pr setci ci_ 'Pb setcq cq_ 'Pr setcmod #%01_1_111_0 'enable colorspace conversion wrpin dacmode_rgb,#2<<6 + 1 'enable dac modes in pins 3,2,1 for Y,Pb,Pr drvl #2<<6 + 1 'enable dac outputs ' ' ' Field loop ' field mov x,#35 'top blanks call #blank mov x,##1080 -30 'set visible lines line call #hsync 'do horizontal sync xcont m_60,#sync_color1 'porch xcont m_1920v,#1 'visible line djnz x,#line 'another line? mov x,#4 +30 'bottom blanks call #blank mov x,#10 'low vertical syncs .vsync1 call #hsync xcont m_880,#sync_color2 djnz x,#.vsync1 mov x,#10 'high vertical syncs .vsync2 call #hsync xcont m_880,#sync_color1 djnz x,#.vsync2 jmp #field 'loop ' ' ' Subroutines ' blank call #hsync 'blank lines xcont m_1980,#sync_color1 _ret_ djnz x,#blank hsync xcont m_44,#sync_color1 'horizontal sync xcont m_44,#sync_color2 xcont m_44,#sync_color3 _ret_ xzero m_88,#sync_color1 ' ' ' Initialized data ' clkinit1 long %1_100111_0100101000_1111_10_00 '20MHz / 40 * 297 * 1 = 148.5MHz clkinit2 long %1_100111_0100101000_1111_10_11 clkwait long 20_000_000 / 200 dacmode_rgb long %0000_0000_000_1011100000000_01_00000_0 '75-ohm 2.0V cy_ long ((+27*s/128) & $FF) << 24 + ((+92*s/128) & $FF) << 16 + (( +9*s/128) & $FF) << 8 + 80 ci_ long ((-15*s/128) & $FF) << 24 + ((-49*s/128) & $FF) << 16 + ((+64*s/128) & $FF) << 8 + 128 cq_ long ((+64*s/128) & $FF) << 24 + ((-58*s/128) & $FF) << 16 + (( -6*s/128) & $FF) << 8 + 128 m_44 long $7F010000+44 'syncs/blanks m_88 long $7F010000+88 m_60 long $7F010000+60 m_880 long $7F010000+880 m_1920 long $7F010000+1920 m_1980 long $7F010000+1980 m_1920v long $BF050000+1920 'visible rfword rgb16 (5:6:5) x res 1 ' ' ' Bitmap ' orgh $1000 - 70 'justify pixels at $1000 file "birds_16bpp.bmp" 'rayman's picture (640 x 350)Yes. I'm dividing the 20MHz crystal by 40, then multiplying it by 297. No visible jitter. I just changed the main clock frequency to 250MHz and I'm now running the streamer at 148.5MHz. Looks fine.
Now I want to see if it's possible to signal modes higher-resolution than 1920x1080p using Y-Pb-Pr. Sure would be nice if they had compact 4-wire connectors for this component video (Y, Pb, Pr, GND).
There are 3.5mm 4 Pole Male Plug To 3 RCA out there ? Maybe those are good enough ?
This one has male plugs https://www.aliexpress.com/item/32960694301.html
or this ? - more $, but choice of 2.5mm and 3.5mm and better quality looking gold connectors
https://www.ebay.com/itm/4-Pole-3-5-2-5mm-Male-to-3RCA-Male-Connector-Cable-Cord-Composite-AV-Audio-Video/302733969586
Or there is this
https://www.ebay.com/itm/HDMI-Male-to-3RCA-AV-Composite-Male-M-M-Connector-Adapter-Cable-Cord-Transmitter/222916772161
Not one i had seen before, but given P2's flexible pins, this could allow one PCB design to include Component video via cable ?
and this as a no-cable adapter, tho might stress a PCB a bit...
https://www.ebay.com/itm/HDMI-Male-to-3-RCA-Female-Composite-AV-Audio-Video-Adapter-Converter-for-TV-Cool/143330462432
it gets better, here is 5 lead one - allowing Component and Audio
https://www.ebay.com/itm/C98E9B7-1-5M-HDMI-Male-to-5RCA-Audio-Video-AV-Component-RGB-Composit-Cable-Lead/283549121387
and an even stranger but useful one is HDMI -> 3 x RCA and 1 x HD15 VGA, which allows VGA with Audio?, or HDMI to VGA
https://www.ebay.com/itm/1-8m-6ft-Pure-Copper-HDMI-to-VGA-3-RCA-Composite-RGB-Adapter-Cable-M-M-A2M3/264325896587
and a more direct no-audio choice for HDMI -> just HD15 VGA
https://www.ebay.com/itm/1-8-M-HDMI-Cable-To-VGA-1080P-HD-With-Audio-Adapter-Cable-hdmi-rca-converter/192933151351
Shame none of these are clear on the pin-mappings in the cables..
I believe this is also what my relatively new OLED TV uses for component input...
I.e., there is no more RCA jacks for component on the best TVs now, just a hole for a 4-conductor jack.
Fortunately, mine came with the little cable adapter needed.
Component input is going away for the most part.
With the previous P2ES, I tried to get a 4k monitor to display 2560 x (various combos) but without success. It only seemed happy to go to 1920 x (1440? 1280?). But it would be good to try with other monitors.
Look forward to you checking out the front end analog cap changes too. Curious were the cutoff frequency is
The only way I could figure out how to do 1080p via Y-Pb-Pr was from this obscure document (see attached). Google searches seem completely fruitless for figuring this stuff out.
If I remember, HDTV's are picky about signal timing. It has to be pretty exact for them to respond, at all. I know we have the bandwidth to signal 1440p, or even 2160i, if such a format exists.
This is a 2560 pixel wide LCD controller that lists all the resolutions it supports on each input interface, and it stops at 1080 on component, despite supporting higher resolutions on digital interfaces.
https://www.digitalview.com/downloads/manuals/SVX-2560-manual-v3_02.pdf
Rogloh and I both have a dell monitor that supports 1920 x 1200 and takes component amongst other things, would your test code work with the prior P2ES chip for component video output? If so we could try this and see whether 1920x1200 is attainable
The new streamer has different commands, but same principles as before.
I wish they would have just allowed analog input, as we could nicely generate it.
People can capture it as easily as we can stream it. That was the argument.
Many displays do 1080p anyway, but the top was supposed to be 1080i.
I suspect no higher resolutions are rooted in politics, nothing technical. The higher definition streams favor YCbCr color space anyway. It is larger than RGB and allows for some operations to be performed cheaply.
The specs are probably not available so we would need to reverse engineer it.
The maximum component resolution may be limited by the sample rate of the ADCs. It might be possible to reduce the frame rate while increasing resolution, so the dotclock stays the same.
No, no, no, no, please no! Now that we use LCDs, it should be fine to output 30p, 24p, or even 15p. I'm hoping we can do 720p30 over HDMI.
720p60 signals at 74.25MHz. Half that would be 37.125MHz, which would need 371.25 MHz for HDMI. That would barely work.
The large expensive models had nothing but a bundle of HDMIs and two (satellite and terrestrial) digital aerial inputs. And Wifi, Ethernet and USB of course. Some even have nothing but one special slim plug with a separate interface box but still not a single component or VGA on those ones either.
EDIT: Removed some unfinished muttering.
Ok then, 720p24 at 29.7MHz. Or 720p15 at 18.5625MHz. I should be able to get that on my P2ES board. I might have to try just to see how many displays will handle it.