Signal emulation using microprocessor (to powerup a display)

**mJrO** · 08-20-2009, 07:10 PM

Hi all,

I have my carpc running for a few years now (very very stable). Now I wan't to change something on the project.
I want to remove the 7" touchscreen from the center console and feed a rgb signal to the OEM nav screen.
The problem is that the OEM nav screen needs a "command signal" sent by the nav dvd player to powerup (and then receive the RGB input).

Thanks to a German fellow I have a bunch of information regarding this signal.
It is a 2400bps signal that repeats itself every 100ms.

The thing is I'm no electronic genious, I mean, I can do simple circuits and such but thats it.

The idea here is that when power is feed to a microprocessor/microcontroller, it starts sending the signal continuously, therefore powering up the screen.

The screen has a 10 pin connector, and such signal must be sent to the 4th pin.

I'll post the signal specification and OEM nav screen pinout. If someone could help me out on this one i would be gratefull (and pay for it).

Specs sent by the German fellow:

Signal sent to the OEM nav screen (monitor an):
http://img199.imageshack.us/img199/9748/bitmuster.jpg

OEM NAV screen Pinout (2X5 pin connector):

1 - Red drive 0.714V p-p
2 - Green drive
3 -
4 - serial bus control (2400 bps)
5 - remote signal
6 - blue screen
7 - drive signal ground
8 - composite sync 0-5V
9 -
10 - Composite Video

ok, now about the serial interface. i have used an Renesas developers board with an M16C28 microcontroller on it. that's just because i already had this one at home. basically you schould be able with almost every microcontroller to drive the display. what you need is an serial connection to PIN 4 from the 10 pin Herose connector. the baude rate is 2400. in theory this is a duplex communication, but the monitor will never reply.
the protocoll for commands can be seen in the 3 other attached pictures. basically it is a data word which is repeated every 100ms. the content of this word will lead to an action on the screen.
the data word consists of 5 x 10 bit which are seperated by one low bit.
bit nr. 10 is the parity bit which brings the parity to even.
the first byte are something like a start bit. everything in between will set the screen. you can see in Auswertung_3.jpg that the 3rd byte is used for dimming. there are 10 stated for 10 dimming states. within the same byte there is one bit which is always the same except at the first state (Nach Schlüssel AN). with this bit you can suspend the monitor. it will stay open, but is black.

the 2nd byte is for poping up/down the screen. if you just stop sending any commands, the monitor will close after 30 sec or something."

The pics the citation refers to:
http://img31.imageshack.us/img31/7391/auswertung3.jpg
http://img11.imageshack.us/img11/7591/imag0066k.jpg
http://img39.imageshack.us/img39/883...toscarbild.jpg

I don't have interest in control the dimming or anything else, i just want to be able to power up the screen (emulate the monitor an signal).

Thanks,

Manuel

**Chainu127** · 08-25-2009, 01:29 PM

I spent a while looking at these diagrams, confused because the description listed did not match what I saw in the diagrams. I believe the information is slightly incorrect:

the data word consists of 5 x 10 bit which are seperated by one low bit.
bit nr. 10 is the parity bit which brings the parity to even.

It looks to me like this is actually a standard serial communications protocol.

When he says the words (?) are "separated by one low bit" this is actually the start bit (space) for the byte.
Then you send one byte, and then the 9th bit, not 10th, is the parity bit.
I guess this is the 10th bit overall if you count the start bit which may be where that came from, but the start bit should not be counted, as it does not participate towards calculating parity. It just so happens that this system uses even parity and since the start bit is a '0', it will never effect it.
The last bit, bit 11, is the stop bit (mark).

So technically, if you count the start and stop bits, it would be 5 x 11 bits, more simply known as sending 5 bytes with even parity over serial. Your diagrams should have two more '1's, or filled in boxes at the end to complete the parity and stop bit of the last byte sent. This probably got lost since the idle state of a TX line is high.

This can implemented VERY easily on an 8-bit Microchip PIC microcontroller with only the UART and 16-bit timer peripherals and an internal oscillator to keep it cheap with less parts. Do you have any PIC's available to you?

**Chainu127** · 09-02-2009, 05:21 PM

Originally Posted by mJrO

Hi there,

Thank you for your input on the signal emulation topic.

You asked if I had any pic available. Well, I don't. I meen, i can program them myself, but if I had a schematic with the necessary components to run (after programmed) the pic and code to program it, I could find someone that did program it, and then assemble all the parts.

Can you be of help (more than you already were)?

Best regards,

Manuel

Manuel,

Here is something I came up with very quickly. I picked to use a PIC16F688 since you said you did not have any just lying around. I picked the 688 because it is the smallest pincount we make with a UART. It is 14 pins, but really only about 4 pins will be used after it is programmed. I would have liked to use an 8 or even 6-pin device, but we currently do not have any on the market with a UART.

I've included the original schematic and source code in case you want to make any changes. The schematic was made in ExpressSCH and the source code is in assembly and can be opened with our MPLAB software. The .hex file is also included if you just want to program the part without making any changes.

The circuitry for voltage regulation I have used in my own projects with no problems. I'm not sure if the TVS diodes are absolutely required, but it's a good idea to have them on there to survive voltage spikes and battery cranking.

Hopefully this will work for you,

~Chainu