DIY GVIF converter available?

Just signed up, (and just bought an '06 prius), and am starting to look into video input solutions to the MFD. From what I understand, there are two video inputs.

First input is standard analogue input at sub-VGA resolution used for the backup camera. Does the MFD overlay the warning message of "Check surroundings for safety" onto all video on this input channel?

Second would be the GVIF input used for nav. My Prius has the backup cam, but not nav. I have the car less than 48hrs now, so I havent ripped the dash apart (yet ) to look behind the screen at connections. Is it the same screen in all models, just different modules connected? So my non-nav will still have the GVIF input correct?

Also from my understanding GVIF is a medium/high speed digital signal over a twisted pair. So there should be some area for a 2 conductor connector somewhere correct? Are there any DIY schematics or resources available to make use of the GVIF video input port to feed a DVI/VGA signal in? Or at least a RGBs signal at 480i minimum? Preferrably it would be wise to keep a digital signal such as DVI/HDMI and just convert it straight over using a high speed micocontroller (probably have to look into the ARM family for speed/power since it is high speed digital video) into GVIF.

Before I go reinventing the wheel, just wondering what is available. I know there is a module available that takes a RGBs signal like svideo, and outputs it to the Prius (not sure if this is over the backup cam feed or the GVIF for the nav, maybe someone can clarify), but I would rather go DIY.

Love the Prius so far! Havent driven it very economically yet (85mph+ 2000mi across country), but even then it sure beat my other cars doing the same trip!

 

I am aware of some of the off-the-shelf solutions. However, I would prefer to make my own. I can't believe that in 5+ yrs nobody has tried to make their own except for the 2 companies selling it...

 

Well looking into the Sony chip, it actually looks pretty easy. Give it a clock and a video source, and it basically does everything for you. Hardest part will be to make a PCB that can accept the chip (famous last words I am sure )

 

I am pretty sure someone already tried this, and it doesnt work because the native resolutions are different. So the old LCDs are taking the input signal, scaling it to 1280x1024, overlaying (or not) their OSD, then converting to GVIF, to the display, and deconverting to raw RGBs again.

Since our screens are 800x480, the video controller after the GVIF receiver would become confused at the extra bits, and you would probably just get random scrolling colour lines as the mismatch continues.

As far as I can tell with these chips it is just a modulation scheme to save wiring. Essentially it takes the video and modulates it to a single differential pair connection. The mating demodulator which all of our cars have in the screen just takes that modulated signal and spits back out the unencoded video stream. Worst case scenario is to just bypass the GVIF altogether and direct drive the output pins of the Sony receiver chip with a custom RGBs video stream as if the chip were to have decoded it, but hadnt.

 

The touch input to PC input is easy peasy. Lessthan an hour of work to get a functioning prototype with todays microcontrollers.

I am sort of funny in that I am willing to spend $2000 on something that I could buy for $500 just so that I can have it custom and be done myself.

I posted the Elance project in hopes that someone would get the DVI to 24bit paralllel RGB interface working. Reason being that I have not done video layout before, and each of these GVIF encoder chips is around $20. I am sure by the time is done, the total cost for one unit will be around or over $100 at minimum. So making a few of them with a bad layout is not exactly cost effective! The two people that bid, I doubt they have the ability any more than I do, so I will more than likely do it myself. Like I said, the big hurdle is decoding the DVI signal into RGB with a clock. There has to be a chip, it would seem silly to have this done in firmware when every LCD would need pretty much the exact chip with only the resolution changing...

 

Thanks for the kind words!

I love tinkering and putting my engineering degrees to use!

I have seen those tv2go units, and the problem is they are completely analogue input which would be easy. Their total unit cost is probably less than $30, all they need is the single chip of doom, and then a sync controller which can be made with a few TTL chips even.

I am actually active in the CarPC community and my Honda Civic has a Core2Duo and of course a Fusion Brain My hope is to make something that people can connect to their Toyotas and have plug-n-play video control and touch feedback through a PC.

The benefit of going with DVI is for signal integrety over noisy car runs. Also I want to help kill VGA and move over to digital-DVI. So many itx motherboards are DVI/HDMI output, and it is a waste to have to make the video controller scale back to analogue output over DVI when all that digital encoding circuitry is going to waste.

SVideo/Composite/Component and even VGA is extremely easy to extract RGB from, you just need a clock source and a SIPO basically. I need to figure out the DVI standard, and I imagine there would be a decoder chip somewhere, just need to find it!

 

Well an A/B type switch is easy enough. I personally wasnt planning on having the two separate inputs. A PC running iGuidance has superior GPS functionality than OEM any day.

The 3D views and full TTS (Text To Speech) functionality from the PC makes the want for a separate nav switchable input small. But to switch between the signals it is a relatively simple process. If you did have nav, then you would need to block the touch signals from getting to the nav system when not on the display. This would be as simple as intercepting all messages destined to the nav with touch coordinates, and just not sending them out if the nav isnt what is on the screen.

 

Think I may have found a suitable decoder chip, and relatively cost effective. Just need a bit more research, and maybe I can draw up a prototype in the next month