Nissan Murano Forum banner

1 - 20 of 35 Posts

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #1 ·
I had an email asking for information to help someone develop a circuit to intercept data going to the monochrome LCD (the amber one) so that they could transfer this data to their car PC and totally replace the display.

Since I've taken some detailed pictures, I'll post them here. Time permitting I'll capture some data as well and post it.

My hope is this will be a successful project for the individual, and maybe they'll even share some of what they're doing on their Infiniti, here on the forum. (Or somewhere else and we can link to it.)

So for a start, Pictures....

The display is two boards. It's thought that it might make the most sense to intercept what's going on, at the ribbon cable that joins to the two boards.

Take out the display, remove the black plastic cover on the back and you see:
 

Attachments

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #2 ·
A closer look at that board...
 

Attachments

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #3 ·
Of course I have better pics, the forum restricts size...

The back of the board:
 

Attachments

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #4 ·
A closer look at the ribbon cable that connects the two boards:
 

Attachments

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #5 ·
And the board attached to the back of the display...

Perhaps the display could be replaced by an interface to the PC, sucking up and translating the data sent.
 

Attachments

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #6 ·
A closer look...
 

Attachments

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #7 ·
And to ensure there's no confusion.... I'm talking about this display!
 

Attachments

·
Registered
Joined
·
35 Posts
I have been DYING to figure this out! I have spent lots of time over the last few weeks thinking about a carpc, but that display always stops me dead. The best place for a carpc screen is obviously where the oem screen is, but, not having the nav package causes the only prob. I have no skills at working out this sort of problem, but I would seriously appreciate anyone that could lend a hand here.
BTW, thanks to Jaak for getting this started...
 

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #9 ·
Well, like any project it requires various talents and components to be successful.

I'm good at tearing apart how things work, but I'm more of a hardware guy, than firmware/software, so that has to come from somewhere else.

I was approached by someone from Taiwan who's got the same display in his FX and may have the capability to create an interface, if I can get the details out on how the display data is passed and decoded. His questions, motivated this to roll.

Then of course, an application has to written for the car pc to actually do something with it, so there's a fair bit to do.

So I'm cautiously optimistic that it's possible, but there's still a lot of "if"s to deal with.

For me, the journey's a great deal of the fun! So we'll see...
 

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #10 ·
More info... Let's talk about the IC's on the back of the display.

Made by Sanyo. The LC75874. http://service.semic.sanyo.co.jp/semi/ds_e/EN5800.pdf

Overview
The LC75874E and LC75874W are 1/4-duty general purpose
microprocessor-controlled LCD driver that can be used in applications such as frequency display in products with electronic tuning. In addition to being able to drive up to 264 segments directly, the LC75874E and LC75874W can also control up to 8 general-purpose output ports.
Since the LC75874E and LC75874W use separate power supply systems for the LCD drive block and the logic block, the LCD driver block power-supply voltage can be set to any voltage in the range 2.7 to 6.0 V, regardless of the logic block power-supply voltage.

Features
• Support for 1/4-duty 1/2-bias or 1/4-duty 1/3-bias drive techniques under serial data control (up to 264 segments)
• Serial data input supports CCB format communication with the system controller.
• Serial data control of the power-saving mode based backup function and the all segments forced off function.
• Serial data control of switching between the segment output port and general-purpose output port functions.
• High generality, since display data is displayed directly without the intervention of a decoder circuit.
• Independent VLCD for the LCD driver block (VLCD can be set to any voltage in the range 2.7 to 6.0 V, regardless of the logic block power-supply voltage.)
• The INH pin allows the display to be forced to the off state.
• RC oscillator circuit

The data sheet shows serial communication format. (Good start!)

LC75813
http://service.semic.sanyo.co.jp/semi/ds_e/ENN7159.pdf

Overview
The LC75813E and LC75813T are 1/3 duty and 1/4 duty general-purpose LCD drivers that can be used for frequency display in electronic tuners under the control of a microcontroller. The LC75813E and LC75813T can drive an LCD with up to 344 segments directly. The LC75813E and LC75813T can also control up to 8 general-purpose output ports. Since the LC75813E and LC75813T use separate power supply systems for the LCD drive block and the logic block, the LCD driver block power-supply voltage can be set to any voltage in the range 2.7 to 6.0 volts, regardless of the logic block power-supply voltage.

Features
• Switching between 1/3 duty and 1/4 duty drive techniques under serial data control.
• Switching between 1/2 bias and 1/3 bias drive techniques under serial data control.
• Up to 261 segments for 1/3 duty drive and 344 segments for 1/4 duty drive can be displayed.
• Serial data input supports CCB format communication with the system controller.
• Serial data control of the power-saving mode based backup function and all the segments forced off function.
• Serial data control of switching between the segment output port and the general-purpose output port functions.

The chips look pretty dumb. It appears all they do is turn on or off segments, based on the data clocked into them. I don't see any hardware, or intelligent feedback to the controlling board, it just seems to bark out commands, so potentially the display could be completely disconnected with no ill effects, and the data from the controlling board sucked into a PC application to be decoded, perhaps through a parallel port.

Serial data transfer inputs. These pins are connected to the control microprocessor.
CE: Chip enable
CL: Synchronization clock
DI: Transfer data

I haven't looked at the display close enough to determine if the serial lines are shared. I would suspect all four chips share CL and DI, but not Chip Enable.

Using the data sheet pinouts, it's easy to identify test points on the PCB for each chip and it's data input. Now to map that back to the connector...
 

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #11 ·
Where the display chips have a good talking to...
 

Attachments

·
Premium Member
Joined
·
7,136 Posts
jaak said:
More info... Let's talk about the IC's on the back of the display.

Made by Sanyo. The LC75874. http://service.semic.sanyo.co.jp/semi/ds_e/EN5800.pdf

Overview
The LC75874E and LC75874W are 1/4-duty general purpose
microprocessor-controlled LCD driver that can be used in applications such as frequency display in products with electronic tuning. In addition to being able to drive up to 264 segments directly, the LC75874E and LC75874W can also control up to 8 general-purpose output ports.
Since the LC75874E and LC75874W use separate power supply systems for the LCD drive block and the logic block, the LCD driver block power-supply voltage can be set to any voltage in the range 2.7 to 6.0 V, regardless of the logic block power-supply voltage.

Features
• Support for 1/4-duty 1/2-bias or 1/4-duty 1/3-bias drive techniques under serial data control (up to 264 segments)
• Serial data input supports CCB format communication with the system controller.
• Serial data control of the power-saving mode based backup function and the all segments forced off function.
• Serial data control of switching between the segment output port and general-purpose output port functions.
• High generality, since display data is displayed directly without the intervention of a decoder circuit.
• Independent VLCD for the LCD driver block (VLCD can be set to any voltage in the range 2.7 to 6.0 V, regardless of the logic block power-supply voltage.)
• The INH pin allows the display to be forced to the off state.
• RC oscillator circuit

The data sheet shows serial communication format. (Good start!)

LC75813
http://service.semic.sanyo.co.jp/semi/ds_e/ENN7159.pdf

Overview
The LC75813E and LC75813T are 1/3 duty and 1/4 duty general-purpose LCD drivers that can be used for frequency display in electronic tuners under the control of a microcontroller. The LC75813E and LC75813T can drive an LCD with up to 344 segments directly. The LC75813E and LC75813T can also control up to 8 general-purpose output ports. Since the LC75813E and LC75813T use separate power supply systems for the LCD drive block and the logic block, the LCD driver block power-supply voltage can be set to any voltage in the range 2.7 to 6.0 volts, regardless of the logic block power-supply voltage.

Features
• Switching between 1/3 duty and 1/4 duty drive techniques under serial data control.
• Switching between 1/2 bias and 1/3 bias drive techniques under serial data control.
• Up to 261 segments for 1/3 duty drive and 344 segments for 1/4 duty drive can be displayed.
• Serial data input supports CCB format communication with the system controller.
• Serial data control of the power-saving mode based backup function and all the segments forced off function.
• Serial data control of switching between the segment output port and the general-purpose output port functions.

The chips look pretty dumb. It appears all they do is turn on or off segments, based on the data clocked into them. I don't see any hardware, or intelligent feedback to the controlling board, it just seems to bark out commands, so potentially the display could be completely disconnected with no ill effects, and the data from the controlling board sucked into a PC application to be decoded, perhaps through a parallel port.

Serial data transfer inputs. These pins are connected to the control microprocessor.
CE: Chip enable
CL: Synchronization clock
DI: Transfer data

I haven't looked at the display close enough to determine if the serial lines are shared. I would suspect all four chips share CL and DI, but not Chip Enable.

Using the data sheet pinouts, it's easy to identify test points on the PCB for each chip and it's data input. Now to map that back to the connector...
I wonder how many people on this board actually understand this......I know I don't! :3:
 

·
Registered
Joined
·
1,076 Posts
zebelkhan,

I was hoping that you were the only other member that would understand this.....I know I don't - with the exception of "Made by Sanyo".
 

·
Premium Member
Joined
·
7,136 Posts
biggun said:
zebelkhan,

I was hoping that you were the only other member that would understand this.....I know I don't - with the exception of "Made by Sanyo".
LOL.....I missed even that one......!
 

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #15 ·
It's like Geek bait... I'm hoping those that do understand will be curious and maybe even contribute!

To summarise where this is at, it's potentially feasible to create an interface to send data to a car pc, about what's on this display.

Which, would be cool...

I could do this without posting what I figure out, but then it would likely never get done. So this time, wide open and maybe someone will grab it and run with it.

After all, this display is in more than just the Murano!
 

·
Premium Member
Joined
·
7,136 Posts
jaak said:
It's like Geek bait... I'm hoping those that do understand will be curious and maybe even contribute!
I hope so too....

Come on folks....I am sure we have a lot more brains out there who can help out......
 

·
Registered
Joined
·
1,076 Posts
I'm hoping someone will figure this out too.

I wish I had the expertise to figure it out myself, but I am a civil engineer (that wishes he went into electrical engineering).

I was searching the web and found a site where someone was looking to do the same thing. They may even be one of our members.

Anyway, below is the info he had on the website. It probably says exactly what Jaak said previously in this post, but in simpler terms. :32:


How to replace a not so slick 7 segment LED display in one's Murano with a slick navigation computer.

Ok, I'm still not convinced it's going to be possible. Well, OK, anything is possible, but I'm still tackling the biggest issues which are below.
Questions
· How does one keep the existing display? I have a Sat kit installed, and I want to see what's playing. It would also be nice to see the maintenance notes and such.
· What type of computer is best for this job?
· If I install a computer in my car, then what other fun things can it do besides show me maps?
Features
· GPS navigation. What good would it be not to do this?
· Bluetooth handsfree. How cool would it be to have the display pop up caller id info and have a big old button to push to answer your phone? This one is trickier for me though, as I don't think I'll get all the fun bits like a mute function or playback through the speakers. Maybe, but I haven't thought that far ahead yet.
· MP3 player. Again, because I have a sat installed, I can't get one of the really cool PAC kits. There are other ways to do this though.
· Get online using a GPRS phone while driving. This is mostly for things like a weather update as you're traveling, or traffic maps. That sort of thing. No web surfing while the car is moving!
Those are some of the questions and interesting features (there will be more features). Below are some answers and details. Think of this page as a design and detail page. Software and images will be on other pages.
First, can I get keep the existing display? Well, it turns out that's a really tough question to answer. There are three data pathways going to the existing display. One is known, it's a CAN bus which is a generic network used in the auto industry because it's versatile, and good at having many dissimilar nodes that just relay info about themselves. I'm not too sure what information comes over the CAN bus at this time, but I suspect not knowing this won't keep me from doing the job. I'm assuming it's everything but climate control and radio data. A second bus seems to be an RS422 serial bus, but I'm still working on that. This bus comes off the climate control interface and supplies the all of the climate control details you see on the bottom of the display. Finally, the third bus kinda looks like a simple RS232 serial connection (but could be some offshoot of an I2C bus or somesuch). This is what provides the radio information to the display. Time is kept by the display itself, so I don't really care (you can get really accurate time from a GPS receiver). Making sure I have the radio and CC display is the big challenge. Without that, I lose a big portion of what I like about having the display. That, and I want to say I did it I guess. Nothing beats a good challenge. I'm getting a lot of useful advice about this from a couple of smart hardware guys too, so it's definitely feasible.
Hardware
Ok, lets say I get all that figured out. Then what? Well, time to hook up a computer. What kind? I've thought a lot about this, and have come to the conclusion that a big old carputer that you see on a bunch of different websites is overkill. I'm an embedded engineer by trade, and I like to keep things in perspective. This unit won't be playing games, movies, or doing any number crunching, so a CPU is really simple. It's gotta be low power and cool. Passive cooling only. The computer itself has to work in a very wide temp range. For these reasons, I've decided to use a single board computer (an SBC) designed to be embedded in more extreme environments. You can get these fairly cheap with a bunch of USB and serial ports for the variety of attachements one would need. They also run quite well off of 12V DC and usually require less than 10 A fully loaded. Plus, I get the ability to put the unit to sleep so it would then consume less than 200 milliwatts of power, hence not killing the battery. That's a big plus because you don't have to worry about booting it everytime. Instant on unless you disconnect from the battery. I've also decided not to use a real hard disk drive. Mostly because they require more power, and in a car, they are a very real potential source of failure. Instead, I'll drive this whole thing from a 1Gig compact flash card. Well, I hope, the maps may change that to a 2gig card, but I'm still working on the platform parts. The music can then come from a USB flash drive. Easy to change day to day, and those things can store a gig. Who is going to need more than a gig for a car trip?. When I finally settle on the specific board, I'll post it here, but the specs I'm working towards are the following.
· Ultra low voltage or low voltage pentium chip in the 400 to 700 Mhz range
· 256 Mb RAM
· 4 USB ports
· 4 serial ports (if I do have an RS422 bus in the car, then one of those ports has to do RS422)
· Compact flash slot
· PC/104 compatibility. This wold be for a CAN upgrade to listen to the CAN bus in the car
· Watchdog capability. If the system hangs, it would be tough to reboot. A watchdog can reset the system for you.
· Some sort of usable display capabilities (LVDS would be best). Several of the boards I'm looking at have an AGP bus.
· Roughly 6x4 inches big
The display will be chosen to replace the existing unit without dash modification (if possible) the existing 7 segment display. This is proving to be difficult. Most of the LCD displays out there are just a little too big height wise. I did find the perfect unit in terms of size, and it's resolution can't be beat (1024 x 600), and it turns out it's not too expensive, but I'm concerned about how it will look when the sun's shining on it. If anyone knows what display the NAV enabled Murano's use, then let me know, I can shop for that. Basically, I want this to look OEM if possible. It's also got to be a touchscreen obviously, as I have exactly no idea how to get at the little joystick in the console. When I finally choose the display, I'll post that here as well. Note that the exisinting display size is 177mm x 110mm. There is a little bit of room above and below, but almost none on the sides, so it's possible I could use one of the 6.4in displays which are roughly the same width, but about 15mm taller. That detail still needs working out.
Software
The platform will run Linux and QT embedded if I can get it to build. Since it's x86, I'm using slackware 10.1 as a base, and will trim it down quite a bit. I want to use QTE because it's slick, and I've got lots of QT programming experience for embedded platforms. But it's very hard to build the way I want it, so I'm having issues. XWindows takes too much resource wise, so that's really not an option. Microwindows (I think it's actually Nanowin now?) is a distinct possibility, and it's easy enough to build and get going, but I'm not sure about how to write for it, so that's really plan B. Because of how this is all setup, I don't have any swap on purpose, so memory usage is pretty crucial (hence not using X). Actually, plan A.5 might be Microwin with QT (no KDE, again, too bloated). We'll see, more to come on that later. GPS maps will come from one of the many map programs out there already. Just need to port it. The bluetooth handsfree hasn't been done yet that I'm aware of, but it shouldn't be too tough. I have a caller id app that lets you get messages from the phone, and I know people have gotten audio off the phone, so it's a matter of putting some pieces together. And how cool would it be if an SMS popped up on the screen without touching your phone? An MP3 player will be super simple with the 10,000 existing projects I can mooch off of. Nice thing here is that I can make it play any audio code I want to, so Ogg, FLAC, mp3, wav, whatever will work.
 

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #18 ·
Yeah, that confirms that he wants to do it too, but there's a few things to overcome.

There's two ways to approach this. Attack each of the data connections to the display, decode the data and simulate the responses, if any, for each of the data connections.

There's 6 things to do, right there.

The other way is to monitor the data sent to the display memory from the controller and decode it.

That's one thing to do.

Given a choice, the first is more elegant but not likely to happen because it's more work than most people would want.

The second? Might be able to do this with a parallel port and some software.

I hope to capture info this weekend, if the gods are smiling upon me.
 

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #19 ·
Finally, I found my Round Tuit and got some captures, as I've already mentioned in other threads.

If you download this...

TLA VU OFFLINE DATA VIEWER

from www.tek.com, or http://www.tek.com/site/sw/detail/1,1059,3379,00.html

and then PM me with your email address, I'll email you the capture files so you can see how it communicates.
 

Attachments

·
Moderator
Joined
·
4,601 Posts
Discussion Starter · #20 ·
It appears the top three active lines, or maybe even top six, control the intensity of the backlight.

Further down, you can see four lines that are used to communicate data to the display. This is what has to be captured and decoded to determine what's being shown.

The connections are shown in the same order as the connector on the board from top to bottom.
 

Attachments

1 - 20 of 35 Posts
Top