The "CD43 Face on a JVC HU" Thread - Work in Progress

[bmwman91]

Some of you saw my brainstorming thread about putting a CD43 faceplate onto a newer, somewhat more capable head unit.

http://www.r3vlimited.com/board/showthread.php?t=188611

Well, I have selected a HU and am actually working on the technical aspects of this now. I'll be posting progress in here, as I make it. The HU is a JVC KD-HDR60.

Right now, I have figured out one half of the electrical / programming side. It took some snooping around to get the data sheets for the LCD controller in the JVC HU, but once I did that it was a fairly simple matter of figuring out which data bit corresponded to which LCD segment (195 segments, 195 1's or 0's to turn each one on/off). I did this with my favorite microcontroller in the world, the PIC12F683. The windows UI was done in Visual Basic.

Pictures are more fun, so I'll toss some in. Here's the setup I was working with to debug this. The LCD was being manipulated through this simple little guy...a PIC12F683 uC, a 5V regulator & a DS275+ RS232-TTL level converter (so the PIC can talk to the PC). The LCD controller just uses a simple 3-wire SPI interface.


I soldered leads onto EVERY pin of the faceplate connector just in case I needed to check power-on timing or anything. Really though, I just needed the 3 SPI pins & a ground.


Just in case anyone wants "proof" of my nefarious plan to hack crappy car electronics for purposes of world domination...:p


As glamorous as that may seem, it took a solid 90 minutes of hitting the space bar & some arrow keys, and clicking the same button in a windows app to get enough information to do that. I printed out part of the service manual with the LCD section displayed (how convenient!) and checked every single segment. "But bmwman91, why are you messing with the JVC LCD? You wanted to put the CD43 LCD on there right?" Correct. I need to have the display data that comes from the JVC motherboard 100% understood first so I can translate it for the CD43.


This is a screenshot of the UI I made to debug the LCD.


A gratuitous scope shot...
This is the data packet my PIC sent the HDR60 to display "iAM BMWMAN91". The top trace is the chip select line (set it high when you want to tell the LCD controller, "hey I am sending info"), the middle is the clock & the bottom is the data line (the clock signals the controller to read a 1 or 0 at that time). The controller takes 256 bits in, 204 of which are for switching LCD segments and the rest are either for control purposes or unused. It is done in 4 64b sections with an address byte in between. Why? Who knows. It seems a little more complicated than necessary to me.


I'll do my very best not to get more technical than this since it won't really add anything to the story. If anyone wants more of the gory details, I'll be happy to post them (time permitting). My turkey day break is over tomorrow, so progress will probably slow down a bit since I'll be back at work.

[Jalves619]

Uhhmmm Wat? But theoretically now that you've deciphered the face plate you could create a little bluetooth interface that would allow you to control every aspect of your deck via a smartphone app, right? That'd be :pimp:Pimpin :pimp:

[pegase747]

I don't understand at all how you do that, but I am impressed !
Wish you good luck with that project and hope to see it work.

One question though, if you succeed into basically make the JVC work with the CD43 face, how will you mount it on the JVC unit itself ?
Or will you tranpose the guts of the JVC into the CD43 shell ??

Cheers Pierre

[accident]

badass

[Dirtboy]

I'm in for this! Hope it works out!

[harv]

Wow!

John

[Schnitzer318is]

Wow... I need to go back to school. Nice work, hope this comes to an end product for you. I'm just a bit sad because I know it won't be offered up to the rest of us. ;)

[bmwman91]

Uhhmmm Wat? But theoretically now that you've deciphered the face plate you could create a little bluetooth interface that would allow you to control every aspect of your deck via a smartphone app, right? That'd be :pimp:Pimpin :pimp:

It might be possible to do that via BT. It looks like the BT input goes straight to the deck's microcontroller, so I'd have to make a "leach" board that sits on the signal lines & looks for specific data patterns from the phone, that the HU would ignore. This HU doesn't have BT built-in though. It uses an external receiver, which would probably make things even more difficult.

I don't understand at all how you do that, but I am impressed !
Wish you good luck with that project and hope to see it work.

One question though, if you succeed into basically make the JVC work with the CD43 face, how will you mount it on the JVC unit itself ?
Or will you tranpose the guts of the JVC into the CD43 shell ??

Cheers Pierre

I will see if the JVC mobo can fit into the CD43 cage, but that seems unlikely. I want to avoid hacking up the sheetmetal since it also serves as an EMI shield. I will most likely do some custom machining to adapt the CD43 to the JVC assembly. It might be possible to modify the plastic front cover on the JVC (behind the faceplate) to hold the adapter PCB and CD43 faceplate.

badass

I'm in for this! Hope it works out!

Wow!
Thanks guys. Knowing that people want to see results helps me stay motivated lol. Every time the sun pops out I just want to run out & go climbing, but I need to a)keep my job, and b)do this project.

John

Wow... I need to go back to school. Nice work, hope this comes to an end product for you. I'm just a bit sad because I know it won't be offered up to the rest of us. ;)

Haha I see what you are doing here. Well, if I can get a few people interested in this, I might be able to make additional conversions. PBCs are cheaper when ordered in quantities larger than 1. People will need to be willing to commit to buying an (overpriced) CD43, this specific JVC HU (possibly the Arsenal version, it seems to be identical in terms of interface) & whatever parts I make for the conversion.

School might be helpful, but with stuff like this it can really vary. I studied mechanical engineering & hated programming & electronics at the time. I learned all of this E.E./C.E. stuff on my own after I finished school, mostly all as a result of car projects (hell, cars were the reason I chose M.E. over graphic design in college). The internet & used textbooks can be useful, although I will admit not nearly as helpful as a teacher in a classroom environment.

[kronus]

Interesting, please go into more detail, bit bashing is good stuff.

Another thing you could have done is found the LCD's serial and looked up the datasheet for its serial->display converter ;)

[kronus]

Also, tell me more about how you're interfacing pic<->PC. I've always had to use an expensive, unreliable programmer, didn't know you could go straight in. That would make a few of my projects simpler...

[blalor]

Nice work, William! I frankly expected a little more abstraction in the display data -- maybe something character-based -- rather than just lighting individual segments. Are the button presses carried back to the main board via SPI, as well?

Also, tell me more about how you're interfacing pic<->PC. I've always had to use an expensive, unreliable programmer, didn't know you could go straight in. That would make a few of my projects simpler...

Most microcontrollers can talk serial. Depending on the chip, if the µC has a bootloader installed you can even reprogram it via serial; this is how the Arduino (Atmel ATmega168 or '328) works. I have a very compact USB<->serial cable with a 6-pin female header that you can just plop onto a breadboard. Works really well. Makes sending data back to the host as simple as

Serial.print("foo")

.

[bmwman91]

Interesting, please go into more detail, bit bashing is good stuff.

Another thing you could have done is found the LCD's serial and looked up the datasheet for its serial->display converter ;)

I did find the LCD driver IC's PN & got the datasheet, and that saved me a TON of time. The protocol isn't too complex, but there were a few control bits that could have resulted in an "oops" if I had unknowingly set them.

Also, tell me more about how you're interfacing pic<->PC. I've always had to use an expensive, unreliable programmer, didn't know you could go straight in. That would make a few of my projects simpler...

I program the PICs using a PICKit2 programmer (there's a PICKit3 out now, it is a little nicer & still only ~$40 I think). The included PCB w/ DIP socket works for most PICs. Some have different programming pins, and you just need to solder wires onto the needed pins on an external DIP socket & plug the other ends into the PICKit PCB's socket.

Talking to the PIC via serial port is fairly easy. The 9-pin serial port used on most computers (& USB serial adapters) uses RS232 voltage levels...anything from -3 to +3V, to -12 to +12V. That isn't too friendly to PICs that usually run somewhere from 2.5-5V. The negative voltage is a data "1" and the positive voltage is a data "0".

Many serial ports, I have found, can work with 0-5V inputs from a PIC. Just put a resistor in-line to protect the PIC from the higher voltages. In cases where this won't work, you need a TTL-RS232 level converter chip. I really like the DS275+, but they are not in production any more. The MAX232 family of chips is the most popular, but they require external capacitors & stuff.(but are also more versatile, the DS275 really only works with 5V PICs).

I have used PICs with built-in UARTs for serial comm & it has worked fine. Usually though, I use smaller devices with no UART & bit-bang the data in program code. This is advantageous in that it allows better control of data timing and I almost always operate at 115,200 baud. I'd go higher (and with baud rates that work divide nicely with an 8MHz clock), but many serial ports don't seem to support it. I can share the assembly code for the 115,200 baud RS232 Rx/Tx routines I am using if you want, and maybe draw a cheesy wiring schematic if needed.

Look around online for RS232 protocol & timing stuff, it is all out there. I learned it all on the web. An oscilloscope really is necessary to get it all figured out though, otherwise it is all a big guess in the dark! Another member here pointed me to the Link MSO-19 USB scope. For $250, you really can't do any better. If you can spare the cash, go for the MSO-9212. I am going to pick one up someday, but for now I have access to the stuff seen in the pictures above (for free).

[bmwman91]

Nice work, William! I frankly expected a little more abstraction in the display data -- maybe something character-based -- rather than just lighting individual segments. Are the button presses carried back to the main board via SPI, as well?

Most microcontrollers can talk serial. Depending on the chip, if the µC has a bootloader installed you can even reprogram it via serial; this is how the Arduino (Atmel ATmega168 or '328) works. I have a very compact USB<->serial cable with a 6-pin female header that you can just plop onto a breadboard. Works really well. Makes sending data back to the host as simple as

Serial.print("foo")

.

Yeah, I was a little bummed to see that I will have to decode 195 LCD segments into text data. There are a few angles I think I might try to attack this from...we'll see once I decode the CD43 protocol. The translator will definitely be a 16 bit PIC device since each full LCD character has 13 segments.

The ease at which serial comm is done really depends on the programming environment. I am still most comfortable using assembly with the low/mid-range PICS (only like 18 instructions). Using C with pre-made libraries would be nice & I'll probably be doing that with higher-end devices that have built-in UARTs. For timing-critical stuff, assembly is where it is at, and since 115,200 baud is like 6% of my instruction clock speed, it has to be tightly controlled. I don't NEED to do this at 115200, but I usually try to eat as few clock cycles & bytes of program memory as possible when I have to manually do serial comm. I also happen to have a very nice, compact 115200 assembly routine that I came up with & I can just #include the source. :D

I really should spend some time to set up a bootloader & make my life easier. Using C is something I aspire to do as well. Assembly code can be pit in-line with it. I'll see about doing that when I work with larger chips with more IOs & self-write capability. My beloved PIC12F683 is 8 pins & can't self write haha. I can't spare a single IO in most cases.

[blalor]

Ah, now I understand why you're doing so much stuff low-level. I haven't yet worked with an AVR with fewer than 28 pins (and 20 available GPIOs!). :) I picked up a handful of 8-pin ATtiny85s with my last Mouser order but haven't had a chance to do anything with them, yet.

[bmwman91]

There's something about 8-pin uCs that has serious appeal. I think it is along the same lines as liking an E30 318iS...underpowered, but super light & nimble, and it does exactly what you want it to as long as your requests are within-reason! Holy shit, I am a gigantic nerd lol.