gaping46and2

iTrader: (2)

Wow, this thread is pretty amazing. If by any chance, would this work as well on the 2nd Gen Navi screens?

angrycamel

Sounds good, Geekeng!

I'd imagine that it would, but you would need to check the ETM for the model to make sure that its all the same and where to tap into the IEBus pins.

Geekeng

AC: I wish minimum quantity was not a concern when buying electronic components from suppliers - I can understand where you are coming from!!!

angrycamel

Geekeng: Actually directly connecting to the 4 wire resistive touchscreen controller in the back of the screen is possible in the TSX as I would imagine it would be in any of the Honda/Acura navigation screens. Met152 did it quite a while back.

The reason that did not satisfy me was because it required technical expertise to take apart the dash as well as knowledge of soldering some wires onto the stock board... all of which would void the warranty. I am very much an advocate of a PnP solution across the board, thus I went out of my way to develop this circuit to interpret the IEBus to get touch events form it so that I would never have to crap open any stock component.

Plus there is the added benefit of gaining access to any event that is transmitted over the IEBus.... and thats a great benefit when trying to better integrate a carpc with the stock system, or replace the stock system all together with a carpc.


PS: Dave is helping me out with designing a switcher circuit which will allow for the module to switch the video source on Dom's unit by pressing a button or series of buttons on the dashboard. This is really going to be pretty cool!

Geekeng

AC: Way back, before I found your project, I was thinking about creating a new navi system (carputer) that could sit in the dash, replacing the stock system, but utilizing the stock dash components so it would appear stock. Your progress so far on detecting IEBus events has proven to be quite useful as your project focuses on leaving the stock unit in the dash and piggy-backing 3rd party stuff into it. -- I suppose that replacing it completing is next... although it seems like a uphill - 90degree vertical challenge as several things would have to be accomplished. I plan on finishing with my navi-mod first, then adding your system second, and finally - to design my own navi from a system similar to what Alpine uses now. (By the way, you will be surprised to note that the Navi ECU has several main components manufacturered by Mitsubishi on behalf of Alpine Japan - just a little tidbit) As we've both discovered, NEC is the mastermind behind the IEBus, so I will probably do some r&d with their stuff more into the future.

I realise you're strength is programming, so I must give you props for attempting a hardware related project. Hopefully I will have more time soon to actually help in some fashion. But I gotta finish one thing before the other... *sigh*

Until that day comes, keep up the great work, you're making progress in strides.


P.S. Where did you leave off with respect to the µPD72042B? I do recall you were having issues with master/slave config...

Geekeng

Wow... I didn't realize how poorly written that last post was... I should really think about reading what I'm typing before I click submit.

Hope everyone had a great Christmas.

yungwunn911

wow this is Amazing

angrycamel

With Dave's help, the video switcher relay circuit is setup and working. I have not yet hooked up the actual wires that control the video toggling on Dom's unit to the relay because its all pretty well installed in the car. I would do it tonight but its raining outside. For now (testing), the relay is hooked to an LED and will toggle on or off for each touch of the cancel button on the dashboard. That is working perfectly, so when the normal toggle switch for Dom's unit is removed and the two wires are instead hooked into the relay (replacing the led), I see no reason why it would not work to switch the video over.

Going forward, I am thinking of making the button that causes the relay to flip, programmable on the circuit. I could modify IEBus Studio to handle talking to the unit to program the button sequence and write it to the internal EEPROM. Maybe even putting in a couple more relays that are controlled the same way. So basically you would program a button sequence into the module that will flip a relay to do whatever you want.

Hopefully this nasty weather and the cold I caught from it will subside soon and I can move forward with some more testing. I need to get a working PCB, this breadboard is a huge pain in the ass to lug around.

Anyways, thats all I have for an update right now. I hope everyone is enjoying the holdays!

Reach

Awesome as always man. We're all jealous.

slden

Hello, AC!
http://forum.pccar.ru/showthread.php?p=45620#post45620

angrycamel

Slden,

Congradulations, it looks like you have made a lot of progress! Is that VGA I see working? Please share some more information. It sounds like you have started on a video switcher as well (like I posted above). Let me know if you have run into any problems with it.

We should talk (through a translator) soon.

Email me when you get a chance. robbienewton@gmail.com. I don't recal ever receiving the email from you the last time you posted here.

Keep us all posted on your progress,
AC

Geekeng

Angrycamel:

I'm not sure if you ever answered my question....
"P.S. Where did you leave off with respect to the µPD72042B? I do recall you were having issues with master/slave config..."

I noticed that you developed a library for this on your website for Eagle CAD recently... so I must ask again. Where exactly did you leave off? I ask because I am working on interfacing this IC with the IEBus and a NEC 78K0R microcontroller and wanted to know where you had issues. I would like to trade ideas if you like.

J

angrycamel

A few pages back is the link to Marcin's site if you would like to get something immediately to start with, however my firmware is not ready for the public just yet, sorry.


I never did anything with the NEC chip. So I have nothing to share at the moment. I recently have decided to pursue it a bit more now that I have a better understanding of everything. I started with the schematic a couple of weeks ago which you noticed from my blog post at angrycamel.com, however I have been very busy lately and have yet to make it any further than that. I will let you know when I get some more accomplished as I trust you will do as well.

As a side note, is there any reason why you are using an NEC IC? Also, were you able to get some use out of the Eagle Cad part I posted?

Geekeng

Ok that sounds good.

I chose the NEC IC for several reasons, but I think it becomes obvious when you actually look at the 78K0R datasheet. The two biggest reasons were the cost and capabilities. NEC has a demo kit for roughly $29.99 which minimizes my time for development and once again, doesn't cost too much. Considering the V850 chip costs >$1000 for a demo kit (with built-in IEBus support), the 78K0R + PD72042B is a fairly inexpensive compromise for a system that can connect to the IEBus effectively. If you take a peek at the datasheet, you'll notice it supports direct connection to the PD72042B with CSI (3-wire serial) and it has alot of the features I want for my project (16-bit-wide databus and ALU plus all flash memory, just to name a few) -- I welcome your thoughts on my choice.

As for the EagleCAD part you posted, I honestly didn't find too much use as I've been developing my PCB with OrCad Capture. I just used a standard 16-pin SOP library for my layout so far as I haven't been able to find/import the part with pin labels. I haven't even tried to see if OrCAD will take EagleCAD libraries... maybe thats what I'll do next....

hmmm...

angrycamel

In all honesty, I do not know enough about microcontrollers to really have an educated opinion at this point, but I can speak for my experience with the ATMEGA8.

I get my ATMEGA8's (28 pin thru hole) from digikey.com for like $3 and there is no development kit needed, really. You can compile from C with the GCC compiler and development environments, such as winavr, are free too and work to make development a snap.

As you know, I am new to all of this and it has really helped that everything with the AVR is pretty simple and easy to get into for a novice... and with such low investment needed to start development its a no brainer. Of course you will need some kind of development breadboard but you probly already have that. I got one for $5 on ebay.


Hope this helps. Have fun!
AC

Geekeng

Yeah... I already have loads of electronics from my school days... I can see how a $3 pricetag would be tempting and to be honest, I have purchased all the parts to follow along with your design once I get around to it.

The NEC µC demo kit I have comes with all the debugging software and supports C as well. If you take a look at: http://www.necel.com/nesdis/image/S13990EJ3V0DS00.pdf (page 27), you'll notice NEC suggests the 75XL & 78K series microcontrollers. I didn't realize this until after I bought the demo kit, but it has made my life easier when interfacing the PD72042B. This means I can spend more time on actual development and less time on figuring out how to get the IEBus layers 1 and 2 processed and passed to a microcontroller.

Like you said though, to each his own - I just don't have as much time as I'd like.

GE

KN_TL

iTrader: (3)

AC,

I emailed you but then read this thread several times so ignore my basic questions.

When you mention the firmware, are you talking about IEBus Studio?

Since I am a non-navi owner with a carputer project in the works, I am looking for something to capture events and then develop something to display the contents of the display that has to be relocated to install a touchscreen lcd.

I'd be interested in both the pcb and iebus studio software that you've developed so far. You've done some amazing work so far.

angrycamel

The firmware is the program that runs on the circuit board's microcontroller. It handles interpreting the IEBus datastream and sending it over a serial connection for the PC to act upon.

I am going to work on getting a prototype built soon, but I have been working too hard at my day job lately to get to it. I'll keep everyone updated when I make progress, and I apologize if it is not as fast as we all hoped it would be.

KN_TL

iTrader: (3)

No need to apologize. You are doing us all a great service and I for one appreciate and are in awe of what you've done so far.

You are working on a solution (firmware) that will replace IEBus Studio and send the data already converted for use by the pc?

If my intent is to use IEBus Studio to capture events and then try and interpret those events graphically, can I use the hardware listed in this thread?

I am basically trying to emulate the stock non-navigation display so that based on the bus events, will show me volume levels, temperature display, etc.

This is all new territory for me, but could you suggest a development platform that could take your exported dll's, interpret and display them as graphical information?

Thanks again for all your efforts!

ashtray

I know that this was mentioned on an earlier post, but the Car2PC interface sold by indashpc.org does tap into the GA-NET and does capture 'some' packets.

I asked their support email if they have the capability to capture all the traffic and the reply was:

"We have ability to capture all packets from GA-NET. We did not get many requests for such a version of firmware though."

The downside to their interface vs. the one AC is working on is 'where' it taps in. You have to disassemble your dash to plug in the Car2PC device to the back of the stereo (and through a Y cable if you have OEM XM). AC's, if I understand correctly, plugs in at the back of the OEM Navi DVD player in the trunk. If you're not careful, you can mar your dash in the disassembly process.

In any case, I think it would be great if the folks at indashpc.org would collaborate with AC so that they may share what they've learned about GA-NET and IEBus. Perhaps they have some insite on the last remaining hurdle which is to prevent the OEM system from receiving touchscreen events while controlling the PC.

Just as an FYI in case it causes inspiration.. to make the Car2PC work after it is installed, you have to click CD/Aux (or CD/XM) until CD-C appears on your display. The Car2PC emulates a CD Changer and, once in that mode, it captures and responds to traffic sent to that device. The downside is that the OEM Navi screen does have a generic display while on the CD-C. Although I haven't made it work correctly just yet, supposedly, you can get song related info to scroll on the upper display like it does for XM. Yes, my dash is still partially disasembled in the photo.



Point is.. although screen touches are addressed to CD-C on GA-NET, the CD-C does have some items to click on rather than a blank screen. Of course.. I could have some fundamental misunderstandings about how IEBus works.

It would be great to get the IEBus giants together for collaboration.. we could stand to benefit from your labors.

Osmodious

I guess one question would be what the actual 'active areas' on that CD-C screen control...if it is the actual in-dash changer, then it *will* be a problem. If it is some ethereal separate changer (intended for a trunk mounted unit or something), then there are no worries unless it is connected (well, apart from it intercepting stereo commands and screwing you up that way).

I don't know, it's definitely a conundrum. For my part, I have used every single search and meta-search site on the 'net for IEBus (or GA-net) stuff and looked at every result and have seen no reference to anything that might be helpful for this.

I still think the only way to do this is to 'fool' the car into thinking the screen is off (there is a command for turning it off, so if that can be passed to the car whenever you enable the carputer display...). Somebody had pointed out a downside to this, but the only one I can think of is that you really couldn't 're-address' any of the dash buttons to control the carputer...but if you have a good touchscreen, THAT would be the interface (so it's not much of a problem, to me).

Os.

voidtrance

Granted, I just read 11 pages of this thread in a short time so I might be missing something fundamental, but could you arrange for you carPC to be a separate device address?

This way, it won't have to intercept signals to the nav computer and, effectively, hi-jack them but rather, it would appear as a separate devce on the bug. I am pretty sure that this is possible from the carPC side, since you can get the microcontroller to construct the packets with any data you want. The important part is whether you can get the electronics at the dash to construct packets with your device address in them.

From reading the posts about Car2PC, it sounds like that's exactly what they did, so may be they will be willing to share how it's done.

Geekeng

Voidtrance;

While your suggestion is a good one in theory, it might not be as easy or *cheap* as one would want. I have been working on this project for some time now, and have both the IEBus controller and NEC uC to do it, it is still a challenge because the system is programmed to support only certain types of devices. Good luck reverse engineering the software to accept "pc input" mode or something of the like.

The system would have to have a video splitter & a IEBus capable controller to fully realize the buttons on the head unit as well as displaying your pc screen on the display. So far, looks like AC has managed to get the splitter working, now for the buttons... :o)

CLuis

Hi... Im one of the programmers who worked with Angrycamel on IEBus Studio. The Car2PC device appears to emulate the CD Changer on the IEBus. AC could easily sniff the packets it sends on the network and reverse engineer it to make a software clone of it. Now that has it advantages like not having the commands interfere with any other device on the net but there are only a limited number of commands associated with that cd changer. AC can recognize the buttons on the dash and any other command sent on the net, the only problem hes having is that the commands are producing 2 results, one from the slave device, and one from his program...

On a side note.. I dont own a vehicle with the IEBus, mine has a CAN Bus which once I get the proper hardware, IEBus could also support that...

angrycamel

All good ideas, really. Let me see if I can offer any insight on any of them...be warned, this post may be long and very boring, so sit back and grab a drink.

The car2pc module is working by acting as the CD changer on the IEBus and most likely does this with the NEC chip much like this module: http://www.nuxx.net/wiki/Honda_/_Acura_Music_Link_(Technical) (Some photos I posted of the inside of the music link can be seen on the IEBus wikipedia page too: http://en.wikipedia.org/wiki/Iebus) The CD-C screen is simply the regular CD player screen but I'd imagine that they just didn't provide it with a disc number or maybe the Headunit supports alpha characters being passed as the disc number to get the C. Without more testing its only educated guesses, but what I can say for sure is that the touchscreen behavior has nothing to do with the fact that the screen is displaying the CD-C screen. So this really isn't a solution to the whole preventing "CarPC" touches from going to the navigation subsequently preventing you from "touching" something that you are unaware of. It would still be touching the track buttons and such on the CD-C screen.

Really the best solution to preventing the touches from reaching thier destination is to cut off the link to the navigation computer while in CarPC mode. However, this presents an obsticle that will require changes to the firmware. In order to understand why this can be problematic one needs to better understand how the IEBus communication works. Let me explain a bit..

The slave in this case (the navi computer) now has the data or instruction from the touchscreen telling it to create a click event at the x,y coordinates of the screen. This is precisely what we do with the mouse control test software that moves the mouse to a particular location and clicks on the CarPC. However as I stated earlier, the firmware in my circuit is not having that direct communication with the headunit to get the touch event data. It's merely listening to the conversation and getting the data that way. So as you can see, the navigation computer is still getting the information from the IEBus then it is acting on it because it doesn't know any differently. It thinks you're clicking on the button that it's displaying. It has no knowledge that you have replaced the video signal with something else. This is the predicament that we are in now. We need a way to switch over to PC mode and prevent packets from sending to the navigation computer while we are in that mode.

So what are our options? Well first we could simply cut off the connection of the IEBus to the navigation computer while we are working with the PC. That would prevent ALL IEBus communications from being able to reach the navi comp, but there is one other important fact. If we cut off the line to the navicomputer then the acknowledgement of each transmission will need to be handled by the firmware or else the master would simply think that there is a communication problem and abandon the message. (meaning it would never make it past the header of the packet so we would never get to the data portion that holds the x and y coordinates)

The problem lies in timing. All that I described above about the communications needs to happen in a very timely manner. The ACK's have a very small window to be performed before the master will give up, and from my current knowledge of the ATMEGA8 microcontroller, I do not think that it is fast enough to handle that. How could we handle full speed communications with the IEBus while ACK'ing messages ourselves on the circuit? Well, maybe we could use the NEC chip and do a FULL emulation of the navi computer. It would be exactly the same hardware (the chip is the same) and we could program it to have the same device id. Since the NEC chip handles the protocol layer it will handle the ACK'ing for us so we do not have to rely on the microcontroller being fast enough to do it.

So if we used an NEC chip with the same device id as the navigation computer, flipped a relay on the circuit to close the real navigation computer off from the IEBus, then the rest of the devices would be none the wiser. The touch events would be directly handled by this module before being sent to the carpc. The navigation computer would sit idle in the dark just thinking that no one is clicking anything. Then when we switch back to navigation mode we flip the relay again, disconnecting the carpc from the bus but re-enabling the navigation computer. (of course, we would also be switching the video source each time too)



I hope this helps everyone better understand how everything works as well as the challenges we all face in getting this working. Bottom line is that I am at a turning point. I need to either continue the development of a new circuit that will include the NEC chip to handle bus comm or I need to start working hard on trying to get the ATMEGA8 firmware lean enough to handle the speed needed for ACK'ing on the bus.

If you read all this, you're crazy!
AC

Geekeng

I guess I'm one of the crazy ones!

AC, you summed up what I had mentioned earlier extremely well. While the video splitting is solved, we are still confronted with the issue of button presses. More specifically, ensuring the button presses (on-screen & physical) are not sent where they shouldn't go.

I have been working on a device that talk on the net, which should eliminate the need for any other special hardware. I fail to see any reason why you couldn't program a function to send the navigation system into the touchscreen test and keep it there while the carpc is in control. Seems to me like this would be the easiest way to keep the navigation system from doing undesirable things while blindly pushing touchscreen buttons from your carpc. Anyone want to comment on this thought?

ashtray

There are a lot of crazy people.. count me in.

The CarPC emulating the CD disk changer is an elegant trick for making the Head Unit buttons work if you don't really have a CD Disk changer in your trunk. But, really the only buttons I'll get out of this on my 04 Accord are >> and << on the HU and the steering wheel.. and hopefully the scrolling text. They are sending me a new unit because mine had the wrong firmware. But, I can see from AC's post where this trick does not extend to the touchscreen.

In the end, my dream would be able to hit a certain combination of buttons on the OEM console that automatically takes it into Carputer mode (i.e. triple click Cancel to toggle back and forth). The combination could trigger the relay that AC mentioned to shut off the IEBus signals to the Navi unit so no physical switches are required or move the OEM touchscreen to the test screen as Geekeng mentioned while also toggling the video. Also, a key element to the dream is that I do not have to cut any OEM wires... A bonus would be to be able to reprogram any/all of my HU buttons to work as I want. The first button that would be reprogrammed would be that damn voice command button. You know the one where you punch the button and say "What time is it?" and 14 seconds later it says "Tempterature 48 degrees".

Hey.. I know I may not be adding value, but I'll stay to cheer you all on anyway. Go IEBus team!!

BTW.. I bought both of AC's DIY harnesses from Angrycamel dot com and the shipment was VERY fast. DIY because I don't have a TVtoNAV module and I needed to customize; I'm using a Scan Do 800 but I didn't want to cut into the OEM cables. I don't want to divert the topic at hand but I must tell you though that the extra money for the pre-made versions AC sells are well worth it if you have a TVtoNAV module. It takes a lot of time and patience to put it together.

CCColtsicehockey

hope this works out well cause I would like to pick up a navi headunit and use it to control a standalone car pc with no acura navi since I dont really want to spend the time to do the conversion.

voidtrance

Yes, I am crazy! But then again, you are not telling me anything I didn't already know


I am prefacing everything that follows with the statement that I don't know nearly enough about the NEC chip or the ATMega8 controller.

Since we (and by "we", I mean "you" because besides half-baked idea, I haven't contributed anything to this project) can't reprogram the entire system with a brand new device ID (the carPC), the next idea that I would suggest is have the sniffer (NEC chip or ATMega controller) be inline with the communication lines to the Navi computer and act either as a "cave" or a "tunnel" depending whether carPC is on or off, respectively.

Let me explain: in both cases (whether the carPC is on or off), all packets going to the Navi computer hit the sniffer. If the carPC is on, the packets get sent to the carPC and the sniffer responds with the appropriate protocol message, just as if the packets hit the Navi computer.
On the other hand, if the carPC is off, the the sniffer just passes the packet through (in both directions) and lets the Navi computer take care of the protocol messages.

This way, when the carPC is on, all packets will be intercepted and to the Navi computer, it would look like the user is not making any inputs, but when the carPC is off, the Navi computer would think everything is normal.

Granted, I don't know to what extent the NEC chip is programmable to do this or if the ATMega controller is fast enough to handle the complete protocol but may be a combination of the two could do the trick (NEC chip takes care of the protocol and the ATMega takes care of deciding whether to pass the packet through or send it to the carPC).

Geekeng

AC... or anyone else that has experience with their navigation system....

How long does it take for a new device to initialize on the IEBus... AND are we sure all devices connected to the navigation system are plug-n-play? That would infintely suck if we have to reboot the system every time we switch from one device to the other.

On another note, I've made some headway with the uPD72042BGT... gotta figure out how I'm gonna seal this baby from moisture though. Seems to be kinda flakey right now. I mentioned to AC earlier that I'm using the NEC 78K0R series as the microcontroller for my IEBus project, so I'm not sure if anyone wants to shift the focus - but either way, I'll keep you informed with my progress. I shall comment more when I can be sure I've successfully interfaced the receiver/microcontroller on the chain...

Geekeng

...busy busy...

angrycamel

Hey, sorry. I forgot to reply to this one...

Each device registers itself on the bus at startup. I am not really sure what you mean by something being plug-n-play, but you can add a new device to the bus and register as long as the device id is unique. The concept of having to "reboot" the bus is not accurate. Each device on the bus registers itself with everyone else on the bus, but just like a bittorrent network, there is no central server, just a network of clients where one client can address any other client in the network.

The documentation covers all of this in much greater detail and is surely more accurate than I am.



By the way...
I finally got a small prototype board working. I don't know what the problem is with my schematics but I must have something wrong there that is not wrong on my breadboard. I made this new prototype by hand by looking at the breadboard rather than pringing a board form the schematic. All attempts to print were failed.

I hope to find some time this weekend again to get back to it and test the new dual relay setup

KN_TL

iTrader: (3)

If your desire is to simply use the oem touchscreen to control a carpc, you don't need to mess with this stuff. All you'd need is a scan converter and touchscreen interface. But I think you could get off much cheaper by just getting a aftermarket touchscreen.

I'm not sure if you can do what Rob is doing without a fully functional navigation system.

I'm plugging along myself and have done the following:

I've got the sniffer on a breadboard, but the cheap approach I took trying to use a parallel connection to program the ATMEGA8 didn't work out very well. So I am waiting for the programmer to arrive from SparkFun.

I created a cable using the connector from a spare non-navi display and a old civic harness so I can simply plug and unplug the sniffer for my experiments and event collection. It's cold up here so I don't want to leave this stuff in the garage.

Another member bought a smashed display for the framework and sold me the electronics and I made up a cable to go from the navi display electronics to the navi sub-display. So I have the HVAC info showing up there.

The events I need to capture is for the HU (CD/DVD Player/Changer, Volume, XM, etc). Then I'll attempt to use Visual C# to create a display of this data using the sniffer attached to the carpc.

I'm not planning on using the oem navi display and already have an 8" WS touchscreen, so my use is simply sniffing, interpret the data and display the event.

ashtray

KN_TL,

I'm not sure what kind of car you have but the OEM touchscreen does far more than just navigation. I wouldn't be able to control my AC, XM or Radio without it so I can't just replace it unless I can transfer existing functions to the new touchscreen .

Also, I have a 4-wire resistive touchscreen USB interface but my Honda Accord Navi screen doesn't have the obvious 4 wires sticking out of it like the Acura. It has a teeeny ribbon cable coming out of it with about 30 wires in it. You can see pictures of the same model here:
https://acurazine.com/forums/showthr...6&page=9&pp=25

I finally got in touch with the folks at SHARP that provide technical specs on their screens and they said that they don't even have the info for this screen which is typical when the screen is made custom for a customer. They said that my only hope is to go to Honda to get the pinouts of the screen. Anyone know who I can contact at Honda?

I'm hoping AC can figure something out to get me going. Seeing the PC display on the naviscreen would just make me angry without the ability to control it somehow. The only down side to AC's solution if he can get it working right is that the touchscreen will not have the same resolution as a direct tap into the touchscreen controls. This isn't a big deal though as the Carputer front end typically has large buttons.

Keep it going AC!

Thanks,
Ash

KN_TL

iTrader: (3)

ashtray,

I'm really not sure what your point is.

I've got an 06TL non-navi and have been looking at schematics for months and recently experimented with navi sub-display and the electronics from the navi display.

The OEM touchscreen is just a monitor with a 4 wire touch surface. If you want to simply interface it to a PC, then all you need is a relay, a touch interface and a scan converter. Others have already done this.

What AC is doing right now is capturing the IEBus events so that the PC understands it and the debate/work right now is how to switch seamlessly from embedded navi to carpc and back.

What my original intent was to simply sniff the bus and display on the PC what I would normally see on my non-navi displays. I've got the HVAC info on the navi sub-display so right now just the headunit info needs to go there.

I've recently stumbled upon a remanufactured navi control unit (dvd drive) for dirt cheap from a dealer. So I've changed my plans a bit. I'm not quite sure what the direction is at the moment, but it varies as I find deals.

angrycamel

Congrats on finding the remanufactured navi unit. What price did you get?

By the way. As I type this the soldering iron is heating up so I can put together the latest attempt at defeating the last problem of cutting off the touch events from reaching the navi computer.

I will update you guys when I get a chance to test it. Its been a pain being able to test because everytime I turn around the wife is taking the Acura out shopping again! I think I finally secured it for tomorrow, so we'll see.

Ashtray, I don't know anything about your model so I am not sure I would be much help for getting into the 4 wire resistive interface but you will likely be able to use this device with the lower IEBus touch resolution once its working.

KN_TL

iTrader: (3)

I got it for under $100 shipped.

Thanks for the reply. The reason I asked is that I remember you saying that you hadn't set the fuse bits, but in the default setting, it should work shouldn't it?

I had problems with the programming, but when I took it out of the sniffer circuit and only connected Vcc/Gnd and the serial programmer then it worked like a champ with the default fuse settings. The only thing I changed after programming was the SUx and CKSELx to power up immediately and run with the fastest internal clock.

I programmed the flash and assume the EEPROM and bootloader isn't being used?

Anxiously awaiting your results!

angrycamel

Wow that is a great price! I would have sprung for that just to have it on my workbench! Enjoy it.

You need to set the fuse bits for 8mhz if thats what you are going to run yours at. See the command I use to set the bits below:

As for a regular project update, this is the latest from my site:
I just finished putting together the prototype board with the relays all working as they should be. Its a nasty looking beast of a prototype board but its working. I will be testing out the features of switching the video and disabling the IEBus signal from reaching the navigation computer while in “PC” mode tomorrow afternoon. For now I have posted some pictures of the board on my site (add dot com to my name).


Enjoy!

Jonesi

AngryCamel we have a board room where I work. If you need any hard to find components or have any questions I have Alot of resources at my fingertips. I just lack the knowledge as I'm more mechanical then electrical.

Awesome job so far. Totally amazed so far..

angrycamel

Thanks Jonesi. I will keep that in mind. At this point though, I don't need anything really off the wall and I have everything that I need.

I just hung up my hat for today prob. I am getting very frustrated. The new prototype board stopped working and the breadboard stopped working. I cannot determine what the problem is and if it is in the software or the hardware. After about 3 hours of constant troubleshooting I am putting it down for now. I haven't even eaten yet today.

Sorry I wasnt able to post good news everyone.

Until next time,
AC