No one along the line really cared, and consumer feedback hasn't been strong enough to force a change would be my guess.

Ford recently sent out USB thumb drives to all of their customers with a newer Sync enabled car with an upgrade on it. They did this because their overall car satisfaction ratings were taking a hit due to how bad the new system was. They wanted to get the changes out quickly instead of having people do it manually, or waiting till their next service appointment.

In car entertainment is still an area that could use a lot of improvement. We here all were spoiled with such a great product in 1999. My experience with the CarPC showed me that even the enthusiast market isn't really in it to make something great.

The cubby in front of the gear lever looks promising, maybe the lighter socket can be relocated to inside the armrest? How wide is that hole?

Yeah, that sounds about right. I'm actually finding that it does start some MP3s at the beginning, but others start late. Looks like it might be an issue with encoding of some of my older MP3s, though they play fine on my Squeezebox and in Google Music.



That would be a bit low to be able to easily view the display, but it would be something. I took apart the dash last night and it looked like it could fit, but it'd probably have to be at an angle.

But then I did some more googling this morning, and found this:


It replaces the factory climate controls and nixes the volume/tuner knobs so that a DIN unit can fit in. I'm pretty sure this means I'd lose the SD and CD/DVD drives, but maybe with the help of a display extender, I could come up with something where the disembodied empeg display tilts up to reveal those slots underneath.

Only problem is, I can't tell if the silver fascia area needs to be cut to fit that unit in. Checking with a local installer to see what the deal is -- there doesn't look like a lot of space between the video screen cutout and the climate controls, which makes me think this might require more dash cutting than I was hoping for.

Some clarity from the support staff at Metra: that kit is for factory systems with a smaller touchscreen. So I guess the cubbyhole under the climate controls is my only option.

That is exactly where Im now looking to stash my Empeg in my 2010 Santa Fe. Same basic spot. Going to tear into it this weekend and see. Oh, and the factory unit in that has the same set of issues yours does - doesnt deal well with some MP3s, tags are sometimes used and sometimes file names. what a POS. I want to look more closely into the SERIAL display extender that V99 talked about on here a few years back. That could be built in a smaller size than stock too, and fit more places.

Since discovering this project, my install plans have gotten a bit simpler, but also a lot more complicated. Simpler in the sense that I might not have to worry about finding a physical location for the empeg display panel, but more complicated in that it involves adding some more components, doing some hardware hacking, and a lot of additional software bits.

Attached is a rough picture of what I'm considering doing:


My first cut is going to be with the empeg as an aux-in device using the Lockpick C8 to add an auxiliary video input. The empeg display buffer will be sent to a RaspberryPi as per the project linked above, with the RPi pushing the empeg display (possibly along with some other stuff) to the aux video input on the Lockpick.

For empeg input, I'm looking at hacking together a custom switch panel that will be placed in the cubbyhole underneath the climate controls. The input will be read by an Arduino board with a CAN bus shield, which will also monitor the CAN bus for relevant activities in the factory A/V system (so it pauses the empeg when switching to another input, responds to steering wheel remote presses for next/previous track, etc.)

(I looked into trying to do all of the input and CAN stuff on the RPi so there are fewer moving parts, but CAN support on the RPi seems to be somewhere between totally absent and experimental at this point, whereas the Arduino CAN shield purports to be pretty much plug-and-play with a pretty robust set of library calls and some easy-to-follow example code.)

Of course, with such an ambitious project, there's many a slip 'twixt the cup and the lip, so I'll probably do everything in stages, starting with getting the Lockpick installed and feeding in the empeg as an aux device. If I hit any dead ends, I can always try to go the "conventional" display extender route instead.

I'll post updates here when/if I make any progress on any of this.

I admire your determination and will enjoy watching your progress.

EDIT: Personal preference, but I would ditch the button panel and just use an empeg remote with an IR extender and the steering wheel buttons. Much cleaner. If you REALLY need to get to the buttons on the empeg, you could always pull over and get in the glove box.

In my Blazer, my empeg was installed in a low position that was hard to reach, and I used my remote all the time. I got very good at using it by feel alone without taking my eyes off the road.

This CAN interface is supposed to be verified to work with Raspberry Pi: PEAK-System.

Disclaimer: saw the link while browsing for something else. Didn't read it.

EDIT: Holy Outrageous Price, Batman!

I do suppose the IR extender route would be less work, but I always found navigating menus with the remote to be more awkward than using the front panel with its D-pad-esque button arrangement. I also tend to drop or lose the remote in my car. I could always mount it semi-permanently, but I think I'm going to at least play around with the input panel idea, even if it just turns out to be an educational project rather than anything practical.

Yeah, the other good thing about the Arduino CAN board that I didn't mention is that it's pretty cheap. I did run into that PCAN-USB module on the RPi forums, and once I saw how much it cost, I realized Arduino was the ticket for now.

...Velcro

I'm on the "remote love's team"

Love to press #2 to pop in another song from the playing artist.

Yeah, I did say "I could always mount it semi-permanently."



Right, hence my motivation for a keypad on the input panel. I can't live without the ability to do order tweaking or keypad searches. As a matter of fact, those two features might make up a majority of my motivation for doing this rather expensive and time-consuming project.

Anyone know how difficult it would be to carve up a spare Kenwood KCA-R6A credit card remote to serve as a hard-wired keypad? I don't know anything about the internals of the remote, but I'm wondering if I could just connect to a few contacts inside and be able to process the key presses without dealing with powering it or interpreting the infrared signal. It's just a matrix of microswitches like any other keypad, right?

There's gotta be an easier way. What would be the advantage of that over something like this?

The screen-printed buttons that match the actual functions, mainly. I already ordered a 12-button keypad I can use, but I wanted it to look half decent, not just like a telephone keypad that happens to control an empeg.

Just a little bit of progress to report so far.

I received my Arduino kit and some controls the other day, and put together a quick mock-up of the code to handle the control input and send it over the serial interface to the empeg. I've got the knob left/right/press and the keypad input working with some cheap controls that I won't be using in the final input panel (if I get that far.)

Thinking about it more, I'm coming around to the notion that hard-wiring a Kenwood/RioCar remote will probably look lame, so I'm going to give that mini keypad a shot. I will still need to find some buttons small enough for it, or some sort of plastic membrane style thing to put over the switches, but assuming I can figure that out, that'll probably be a nicer looking install. Another option is to do my own matrix of square pushbuttons, which opens the possibility of using LED-illuminated buttons, but the ones I've found on Digikey and Mouser are all pretty pricey.

With all of the inputs, I'm out of pins on the Arduino, so I'll have to do some muxing. It looks like this guy is a cheap and easy way to get as many as I'll need.

For the input panel itself, I found a reference to this site in an old thread here, and it looks like getting a panel in anodized aluminum will run me somewhere in the $30-$40 range depending on how many drill holes/cutouts there are. Seems reasonable, but it's the kind of thing I'll really need to get right the first time, as they won't do proofs for a one-off project. I'll probably just be using wood and epoxy on the back of the input panel to mount the controls in, as a full enclosure would just end up being bulkier and would be hidden from view anyway.

The CAN bus Arduino shield should be here early next week, and I look forward to playing with that to see how much control I can get over the factory system and Lockpick, which should also be here next week. I also ordered one of those quickconnect harness jobs so I don't have to hack up the factory or Lockpick harnesses.

Search for "I/O Expander" chips on digikey. These connect over SPI (best) or I2C (fine, but slower) and add another 8 or 16 GPIO ports per chip you add.

Cheers

.. or just add more Arduino chips. The bare chips cost under $4/each, are easily programmed with the Arduino bootloader via a parallel port cable or another Arduino, and don't need much external circuitry.

What's the benefit of those options over the 74xx165 solution?

Cheap, less bulky, and bi-directional. The board you linked to says it is input-only, not output.

Cheers

Also note that if it's mainly push-buttons that are chewing up your I/O pins, there are a few easy ways to mitigate that.

(1) Arrange them (electrically) in a grid, like a keypad. Then you only need enough pins for x-y coordinates. Eg. 8 pins instead of 16 for a 16-button array.

(2) Use resistors, assigning a different resistance value to each of several buttons, and then wire them all to a single analog input on the Arduino. The exact button pressed can be determined from the value returned by the analogRead() function.

The empeg/Kenwood steering wheel remote uses strategy (2).

Cheers

OK, cool. I had seen some Arduino library code for the MCP23008 IO expander, but the shift register solution seemed simpler. Can you daisy-chain these IO expanders the way you can with the shift register boards?

EDIT: Looks like the I2C version can handle multiple chips on the same bus, but the SPI version can't.

EDIT 2: I didn't see your second reply when I posted mine... I'll look into those strategies as well.

SPI is fine with multiple devices per bus, but does suffer from the need to dedicate an I/O pin per device for "device select".

I2C of course has device "address" as part of the protocol, so there it's just a matter of how many different device addresses any particular type of chip can do.

But either way, a pair of 16-bit expanders give a LOT of extra I/O. But if one really needs tons of I/O, then perhaps the solution is to start with a larger microcontroller. There are Arduino boards with bigger chips ("Mega 2560" board), and then there's the Wiring-S board (very, very similar to Arduino), both of which offer 54 I/O pins.

Cheers

Note that there are tons of MUCH cheaper "Arduino" boards and accessory boards on eBay, if you can wait a month to receive them from China.

Typically 1/3 the cost of the "Arduino" branded ones.

A bit more forward progress. I got the CAN bus shield working, and though the libraries sample code are a bit lacking, I was able to do the basic "detect RPMs, accelerator pedal position, etc." thing over the OBD-II CAN bus connection. I'm probably going to have to do some proper library routines to make things manageable as I add more stuff, but it all seems doable.

I also received and installed the Lockpick last night. I'm hoping that it responds to CAN commands so I can make the task of switching inputs easier -- right now the only way to switch to its AUX A/V input (where the empeg display and sound will be going) is to hit the "Back" steering wheel button 4 times, then select the input from a menu. There's enough lag that this would be a real hassle. I was also hoping to be able to rig things so it switches away from the empeg input when calls come in, and without a dedicated CAN message I can send to the Lockpick, that's going to be difficult or impossible. If I can't find any dedicated commands, I'll have to settle for sending steering wheel presses. The Lockpick itself does some CAN mangling, so I'm thinking about monitoring the messages going into and out of it to see what it's doing for some ideas.

I have a Raspberry Pi arriving tomorrow, so I'll probably start playing around with that next. I'll need to check in with John to see if his code for writing to the RPi frame buffer is in good shape. Once I know how the RPi is going to fit in, the actual empeg install is next -- there's not enough room in my glove box for a sled, so I'm going to have to go the sledless route with Hijack's force car mode and/or force DC functions. For the time being, this rules out using the empeg as a head unit, but I think there are too many missing pieces for that now, anyway. Maybe some day.

Sorry to hijack, but where'd you get your RPi from? I need to order one and have it delivered by the 15th, but am reticent to pay $60 on Amazon when I could possibly get it much cheaper.

I ordered from Newark / element14, which is one of the two resellers linked from the RPi homepage. It was back-ordered for a few days, but it shipped out on Monday.

Last night I got the RPi up and running, built a toolchain, and did a quick "hello world" test of the cross-compiler. The frame buffer interface in Raspbian seems pretty standard, so I shouldn't have any problem driving it, though making it fast might take a couple of iterations.

One unexpected snag: it appears the RPi GPIO pins are 3.3V, while the pins on the Arduino are 5V. There are some ways to work around this, but it does give me more motivation to find a way to factor the Arduino out of the architecture and do everything I can on the RPi

The other option would be something like this, which is a stackable Arduino that's basically plug-and-play with the RPi. It's only in beta, but if they're close to production, that might be the simplest way to get things going until CAN on the RPI is farther along.

Sparkfun has 3.3V Arduino boards -- nice and tiny ones like the "Pro Mini" and "Pro Micro".

Cheers

Right, but I don't think they'd be compatible with the CAN bus shield I'm going to be using. Plus, I rather like the idea of powering the Arduino board off of the RPi, and having the boards stacked together for a cleaner install. Unless those "a la mode" boards are really expensive or end up getting delayed by months, I think I'll at least give it a shot, as it seems to fit the exact requirements I have for this project.