@Rayman said:
So it’s working? That’s great!
Being able to send HD video over coax with just one pin is really great.
It is basically working yeah. I'll have to try it out with my memory driver too now given it will require 2MB or RAM for a frame buffer at 1920x1080x8bpp. It should work fine but I just haven't tried that yet. Should hook up some PSRAM or HyperRAM. Maybe I'll fire up knivd's board again.
Do also consider that you'll need an AHD-HDMI converter in order to display on a regular monitor (which is what I did), or feed into some other AHD compatible display device like a car head unit's video input that can take signals from AHD cameras, or some other CCTV monitoring device. The HDMI converter I used was cheap though, something around AUD$27 I think and seems to work okay. You can switch it to output in 720p instead of 1080p too if you want which is nice.
I wonder how good the support for regular NTSC signals on these whacky HD inputs is... I guess roger could try running NeoYume or smth through the HDMI converter. Regular non-HD cheapo analog to HDMI converters are usually in that middle category where it can handle off-spec signals, but not really well at all. With these ones, could go either way.
Wondering if P2 would need an external line driver to drive a 50/75 Ohm coaxial cable...
Also wondering how safe it would be to directly connect P2 to a long coax cable in EMI environment... Probably would at least need something like a TVS diode to be safe...
@Wuerfel_21 said:
I wonder how good the support for regular NTSC signals on these whacky HD inputs is... I guess roger could try running NeoYume or smth through the HDMI converter.
Just tried this converter with Chip's more accurate NTSC/PAL colour frequency calculations in CVBS mode. Picture was overly bright and you would need to fiddle with the output levels to try to somehow compensate. It did sync up to the usual 4 combinations of input types, PAL vs NTSC, & interlaced vs non-interlaced, with Chip's timing.
Regular non-HD cheapo analog to HDMI converters are usually in that middle category where it can handle off-spec signals, but not really well at all. With these ones, could go either way.
Yes the levels seem wrong here for CVBS. Weird.
UPDATE: I found brightness can be reduced by increasing the black level which increases the sync tip size. Doubling it seems to improve the brightness level significantly. It seems to be related to the fact that we can't get the correct signal levels from a P2 with CVBS once chroma is included on top of luma and Chip's code is reducing those sync tips down too much in proportion to compensate. This device strictly prefers them to be in the correct ratio by the looks of things. This comes at the expense of luma/chroma signal granularity however as more of the DAC's total voltage range is dedicated to the sync tip.
@Rayman said:
Wondering if P2 would need an external line driver to drive a 50/75 Ohm coaxial cable...
P2 DAC is designed for driving 2Vp-p using a 75 ohm source resistance so it should deliver a volt a the end of a properly terminated 75 ohm coax without a line driver IMO. Of course if the coax is not ideal and/or very long, it will affect things.
@Rayman said:
@rogloh I have a 2bpp tiled driver for 1080p that might work out well for this... Doesn't need external memory with small footprint...
Yeah reading 4K UHD images only from hub RAM is a challenge isn't it - even at 1bpp it still needs about a megabyte of RAM for a frame buffer, so tiles are the only way to go.
I would expect if we can get 1080p60 at 8bpp from a P2 from external RAM we should be able to get 2160p15 at the same colour depth (in theory).
The Carplay head unit device I ordered arrived a couple of days ago, and I've been messing around with it. Good news is it works and should also fit into my car once I have my way with it. I was able to get Chip's NTSC demo going and it displays an image - of course it's a little soft as it's only NTSC scaled onto a 1024x600 panel but still looks clean. This unit is quite fast to switch back and forth between rear-camera input and the regular display and doesn't glitch during the transitions which I really like. The main unit takes a few extra seconds to start up to its regular menu, but the video input appears in about 3-4 seconds from power-up if active by then.
I tried my old 1920x1080p25 AHD code but it didn't sync (just displayed blank). I'll keep trying with other settings like 720p and 60Hz etc to see if it accept AHD, and who knows what state I even left the test code in a few weeks back, it might well have had a bug. I could also try that AHD security camera source input as well and that lets me try a range of other formats. At least I know that SDTV will be a fallback and could still display gauges, etc from CAN information decoded by a P2 should I even want that one day but I'm hoping for displaying AHD sources if possible. These Carpuride guys seem to sell a wireless camera accessory that mentions a 1080p camera but I'm not sure if that is bogus and it's just downscaled to NTSC at the source or at the receiver.
Here's a pic of it working with NTSC. Still has the glossy protector on until I install it in the car so it's not the best photo...plus the glare from lights and some Moire is showing too. It looks better in real life.
Well I tried out all the 1080p formats this camera supports (AHD, TVI, CVI at both 25/30Hz) and none synced to the head unit. All remained black. Looks like this unit might just not take a 1080 analog HD type of camera signal or works with something else entirely. Perhaps 720p might work but not betting on it. Also the supplied camera cable I'm using is 6m long and doesn't appear to be coax. Probably not good either.
Oh well, at least I figured some of this stuff out and we got something new working on the P2 once I merge it into my video driver, and I can still use NTSC instead which thankfully works okay.
Comments
So it’s working? That’s great!
Being able to send HD video over coax with just one pin is really great.
It is basically working yeah. I'll have to try it out with my memory driver too now given it will require 2MB or RAM for a frame buffer at 1920x1080x8bpp. It should work fine but I just haven't tried that yet. Should hook up some PSRAM or HyperRAM. Maybe I'll fire up knivd's board again.
Do also consider that you'll need an AHD-HDMI converter in order to display on a regular monitor (which is what I did), or feed into some other AHD compatible display device like a car head unit's video input that can take signals from AHD cameras, or some other CCTV monitoring device. The HDMI converter I used was cheap though, something around AUD$27 I think and seems to work okay. You can switch it to output in 720p instead of 1080p too if you want which is nice.
I'm seeing some relatively low cost regular looking monitors that can take AHD input on coax like this one:
https://www.bhphotovideo.com/c/product/1559813-REG/orion_images_27rdhy_27_16_19_hybrid_hd.html
I wonder how good the support for regular NTSC signals on these whacky HD inputs is... I guess roger could try running NeoYume or smth through the HDMI converter. Regular non-HD cheapo analog to HDMI converters are usually in that middle category where it can handle off-spec signals, but not really well at all. With these ones, could go either way.
Wondering if P2 would need an external line driver to drive a 50/75 Ohm coaxial cable...
Also wondering how safe it would be to directly connect P2 to a long coax cable in EMI environment... Probably would at least need something like a TVS diode to be safe...
@SaucySoliton Good to hear your NTSC capture program works with this.
@rogloh I have a 2bpp tiled driver for 1080p that might work out well for this... Doesn't need external memory with small footprint...
Just tried this converter with Chip's more accurate NTSC/PAL colour frequency calculations in CVBS mode. Picture was overly bright and you would need to fiddle with the output levels to try to somehow compensate. It did sync up to the usual 4 combinations of input types, PAL vs NTSC, & interlaced vs non-interlaced, with Chip's timing.
Yes the levels seem wrong here for CVBS. Weird.
UPDATE: I found brightness can be reduced by increasing the black level which increases the sync tip size. Doubling it seems to improve the brightness level significantly. It seems to be related to the fact that we can't get the correct signal levels from a P2 with CVBS once chroma is included on top of luma and Chip's code is reducing those sync tips down too much in proportion to compensate. This device strictly prefers them to be in the correct ratio by the looks of things. This comes at the expense of luma/chroma signal granularity however as more of the DAC's total voltage range is dedicated to the sync tip.
P2 DAC is designed for driving 2Vp-p using a 75 ohm source resistance so it should deliver a volt a the end of a properly terminated 75 ohm coax without a line driver IMO. Of course if the coax is not ideal and/or very long, it will affect things.
Yeah reading 4K UHD images only from hub RAM is a challenge isn't it
- even at 1bpp it still needs about a megabyte of RAM for a frame buffer, so tiles are the only way to go.
I would expect if we can get 1080p60 at 8bpp from a P2 from external RAM we should be able to get 2160p15 at the same colour depth (in theory).
The Carplay head unit device I ordered arrived a couple of days ago, and I've been messing around with it. Good news is it works and should also fit into my car once I have my way with it. I was able to get Chip's NTSC demo going and it displays an image - of course it's a little soft as it's only NTSC scaled onto a 1024x600 panel but still looks clean. This unit is quite fast to switch back and forth between rear-camera input and the regular display and doesn't glitch during the transitions which I really like. The main unit takes a few extra seconds to start up to its regular menu, but the video input appears in about 3-4 seconds from power-up if active by then.
I tried my old 1920x1080p25 AHD code but it didn't sync (just displayed blank). I'll keep trying with other settings like 720p and 60Hz etc to see if it accept AHD, and who knows what state I even left the test code in a few weeks back, it might well have had a bug. I could also try that AHD security camera source input as well and that lets me try a range of other formats. At least I know that SDTV will be a fallback and could still display gauges, etc from CAN information decoded by a P2 should I even want that one day but I'm hoping for displaying AHD sources if possible. These Carpuride guys seem to sell a wireless camera accessory that mentions a 1080p camera but I'm not sure if that is bogus and it's just downscaled to NTSC at the source or at the receiver.
Here's a pic of it working with NTSC. Still has the glossy protector on until I install it in the car so it's not the best photo...plus the glare from lights and some Moire is showing too. It looks better in real life.
Well I tried out all the 1080p formats this camera supports (AHD, TVI, CVI at both 25/30Hz) and none synced to the head unit. All remained black.
Looks like this unit might just not take a 1080 analog HD type of camera signal or works with something else entirely. Perhaps 720p might work but not betting on it. Also the supplied camera cable I'm using is 6m long and doesn't appear to be coax. Probably not good either.
Oh well, at least I figured some of this stuff out and we got something new working on the P2 once I merge it into my video driver, and I can still use NTSC instead which thankfully works okay.