Check it out here. Is this something people are interested in? Do people even use their empegs any more?

If I were so inclined, how would I go about writing to the screen every so often to display current track data? Maybe be able to intercept button presses and send rewind/skip commands to the bluetooth source? This would all take place in AUX mode, and with the sled serial connector.

On a somewhat related note; can anyone tell me more about the tuner serial port? I'd like to be able to control the empeg from there like a wired remote as I'm using the other for the Bluetooth interface. I feel like I remember getting a bunch of garbage from the tuner serial port when I was trying to connect to it one day, though. Is it RS232 or TTL? Basically, I'm trying to bypass the tuner so I can have a wired remote.

Interested!

Right now I have a cheap third party A2DP interface plugged into the AUX port on my empeg. The idea is for when my girlfriend wants to play stuff from her phone in the car. It works, but it doesn't allow for the buttons on the face of the player to send play/pause/skip commands to the phone.

An integrated solution (with onscreen track data and rewind/skip controls on the player) would be amazing, if you can get that working. I would buy one if it worked. I'd be willing to help you test the software, though I can't help you write it.

Would there be a way so that your device could have an AUX passthrough, to mix the actual AUX plug audio with your bluetooth audio, so that I could have my free AUX jack back? The idea would be that you'd resistance-mix the two sources, i.e., it wouldn't matter whether audio is coming in from the passthrough aux jack or from the bluetooth interface, either one or both will play sound. (I like being able to have my AUX jack available for a portable CD player for those super-rare situations when I buy a CD and want to hear it right away before I rip it.)

Regarding how to get the programming done: You'd need to interface with the kernel somehow. If you were already planning on having a connection to the serial port, you could submit a change to the hijack kernel which outputted some "coded" information on the serial port when buttons on the face of the player were pressed. Then your interface could read the serial port. Commands could be like simple ASCII text output on the serial port:
#E2DP:AUXMODE_SELECTED
#E2DP:LEFTPRESS_DOWN
#E2DP:LEFTPRESS_UP
#E2DP:AUXMODE_DESELECTED
You'd also want to do the same thing for commands from the Rio remote control.

Unless... Does hijack already have a secret setting for outputting button press information on the serial console? If so then no hacking needed for that part, you'd just activate that feature.

The Hijack kernel could also be hacked to interpret incoming coded data from your interface, containing track information, and put that up on the screen. That *would* need to be a hijack hack. But I'll bet it's doable.

Oh by the way, did you like how I already suggested a name for your product in my message samples up there above? "E2DP"? Cute, huh?

I'm pretty sure I've read posts from Mark about the wonderful things Hijack can help me do with this little fellow, I'm just not exactly sure how to use them.

I don't really want to do anything complicated. I want to use the AUX-in for audio and the sled serial port for basic two way control. Only need skip/rewind and pause/play, really. The 8-pin Molex on this interface will receive a custom extension harness with the required RCA jacks, DB9 serial port and tuner connecter on the empeg end for power and tuner Rx/Tx. Current Track information is on the wish list and is fully possible. Just need to connect the dots. It's all done by sending ASCII commands to the RN52 to which it will respond with either a HEX value or an ASCII string, depending on what you asked of it. I would just need to write a little userland 'thingie' to parse that information and write it to the screen, hence the difficulty for me as a non-programmer. I'll be working on that this winter, I suspect. I ordered 6 of those boards to test with, but I have a feeling that I'll be revising it once or twice before I've got a 'final' product. For what it's worth, I had a working prototype on the breadboard. The RN52 is a pretty amazing little chip. It's $25, but it's pretty much fully self contained. All I added was an i2s DAC for better sound and a level shifter for comms.



I'm also working on a microcontroller as an ADC for the 'steering wheel control' buttons. It's supposed to emulate the controller used in the original tuner to add a steering wheel interface as well. That might be somewhat challenging. I'm working with an Arduino Nano as I'm somewhat familiar with the architecture. Anyway, the 4-pin Molex connecter carries 12V/GND and the tuner Rx/Tx wires for running to the remote panel. The remote panel is basically the empeg face without the screen. Basically, I want to mount an empeg face in my center console, but leave the screen on the dash. I have two sets of display extender boards, but I don't think they're applicable here.

Name's decent. Hah. I like it.

I don't know if it'll be easier to write a userland program or to make changes to hijack. Certainly hijack already has a lot of the plumbing for what you need to do. Those who have written code in both areas would probably be able to answer that more definitively.

Unfortunately my empeg is not used in a car any more - this would have interested me back when I did.. This should work quite well. It shouldn't be too hard to get some button presses one way to it and track data from it on to the screen.

Have you tried it in a running car? Whilst experimenting with other interfaces I found they were a bit susceptible to ground loops etc and so alternator whine and other interference might be a problem.

Nice one.

Yeah that's a big deal. Takes a lot of work to get the whine out when you add stuff to Aux.

Hm. I wonder if you could make this "E2DP" unit an internal thing? Inline insert into the connector where the dock wires plug into the mainboard. Mount it in the slot where a second disk drive would go....

I'm not terrifically worried about ground loops as I'm using one of Stu's S/PDIF cards with digital coax running back through the car to my amps. Absolutely nothing I did when I installed the unit into this car would get rid of the terribly loud alternator whine that I had. Nothing. Except's the Eutronix card, that is. I suppose I could still induct noise on the analog AUX signal before going back to digital, but that's not likely to happen. Also, in this board I used a completely isolated i2s DAC chip [PCM5102A] external to the RN52 with it's own highly regulated 3v3 power supply, as I found that the internal audio processing is very poor and highly susceptible to noise, even from UART activity.

I absolutely could make this an internal thing, basically replacing the second hard drive. I suppose that I had never really considered that. The smaller analog/digital Molex connectors at the logic board for the docking connector are still available from Mouser/DigiKey, so I could fairly easily make this a plug and play sort of thing as all of the required connections are in those two harnesses.

I know that if it were an internal add-on to the Empeg, it'd end up installed quicker than if it were external. For me, it's easier to sit down at my desk and open up the player than it is to dig into the rat's nest in my car's dashboard.

Though that might not be the case for all folks.

I also like the idea that the module and a kernel upgrade would basically "make the player bluetooth capable" as if it were integrated. There's some awesomeness associated with that.

Tell you what. I've got a MendelMax 1.5 3D printer sitting on my desk that I've assembled, but not yet gotten working quite right. I could potentially make cases and boards for either application, should I sort that monster out. A board like I've already designed [or a future revision] with matching enclosure for external tuner-type connection and one for internal HDD tray mounting and direct Molex harness integration. Everything is fully open source and boards are/will be be available directly from OSHPark. All components are SMD save for the Molex connectors to save costs and shrink overall size. All is available from the usual suspects, i.e. Mouser, DigiKey, JameCo, etc. The discretes are all 0805 package, so; easily solderable. The RN52 and PCM5102A are a bit tighter pitch, but I managed to hand solder 5 of the latter for Raspberry Pi DACs back-to-back and didn't muck up a single pin. I have a Weller WESD51 iron with ETS 1/64" conical tips for the dirty work. They're wonderful for tight pitch soldering.

EDIT: I'm not sure if I mentioned this or not, but this RN52 piece is also capable of HFP and HSP profiles as well, so I could potentially add a microphone buffer into the next rev board to handle really bringing this little engineering miracle up to current standards.

Yeah, I'd totally buy that kit and source the components myself and do the soldering.

But the software would need to be mostly worked out (ie, to a testable/alpha point) before I went to all that trouble; I'd want to know I'd have something working on the other end of the journey.

I'm in the middle of a time-consuming project right now which I expect to take me until ~November 7th to finish, but after that I'll probably be dying for projects like this one to tinker with.

I am interested, but also realize this project is overkill for my needs. Yes, being able to control an external device from the empeg, but most of all I just need audio pass-through/override to accommodate sat-nav audio interrupting music as needed.

If it just resistance-mixed the existing Aux Input with the bluetooth Aux input, would that solve your needs?

It would have to include the override functionality (muting/pausing the music when the satnav tries to speak).

I came back to this thread now that I'm working on integrating the empeg into my new car that doesn't have an aux-in. When this thread was started it looked like something I'd totally want, but now, it looks like what I would really need is the opposite.

This project is, from what I can tell, about adding a bluetooth input to the empeg, but what I really need now, since my situation has changed, is a bluetooth output from the empeg to a factory car stereo, with controls integration.

I've already bought a bluetooth transmitter which seems like it will work for my needs: Empeg LR RCA output -> BT Transmitter -> Factory stereo. Took me three tries to find a model that would successfully pair with my stereo, but I have a working one now.

That's the audio part taken care of, but then it means that my steering wheel controls, which normally successfully change tracks on my phone when bluetooth-paired, wouldn't change tracks on the empeg. So now I itch for a way to do that via a direct interface module in the empeg. Of course at the moment I don't have the skill or time to do that.

Wishes are great aren't they?

So.. for integration with other in-car controls, the question is always.. what electrical/wireless interfaces does the car head unit support for such, and is there documentation for the protocols it expects?

EDIT:
In this case, there appears to be some kind of bluetooth thingie.. so I guess you're looking for a suitable transceiver for the empeg end, and then some kind of support for whatever protocol it uses. A problem with iFruit stuff, is that it does tend towards the non-standard/proprietary/highly-profitable side of things.

I think you'll find it quite difficult to get your car to receive A2DP (audio) from one device but also be paired with another device so it can send AVRCP commands (play/pause/next etC).

Maybe try looking for a CAN BUS monitor that can pick up button presses. There's no USB host on the empeg though right (it's been so long)?

Either way is a long road I think you'll find.

Agreed, the type of thing that I'm describing would be really complex to make, and I don't see it happening any time soon unless I learn how to do it myself.

Though I want to clarify that I'm not talking about two different device pairings. I mean a single A2DP+AVRCP module added to the empeg. That doesn't make it an easy thing to create, but at least I'm not talking about pairing two different devices.

Being in the same boat, I took a look and found the BC127 module which might do both the A2DP and the AVRCP. This, coupled with a simple arduino translating the AVRCP commands to empeg commands for the serial port, we might be on to something.


I'll try to find some time soon to dig into the datasheet and the example programs.

Wow, that looks like just the ticket. Connect that chip to an Arduino chip with an RS-232 output, and that might just work. Wow. All it would need is the software to send the serial commands to the empeg for next track (I think it's "n <cr>" for example), previous track, and play/pause (I forget which one is "p <cr>" and which one is something else).

You could either implement it internally to the empeg (soldering to the serial pins and to the aux output pins inside the player), or, if you could condense the whole thing to a single PCB that was small enough, make it a single flat module that plugs into the lower back portion of the player on the outside, connecting to the external serial port and aux plugs, tucking in just beneath the dock connector. If it were just the right size and shape, it could still fit even when docked. I think there's a pretty good amount of space in that area between the player and the dock.

Super interesting idea. This takes it from a realm of "this is out of my league" to "within my grasp if I only had the time". I've created Arduino interface circuits before, including all the PCB design and prototyping, and found the process fascinating and fun.

Why do you need an Arduino? Just connect module serial port to empeg serial port (need level shifter) and run code on empeg.

Admittedly Arduino would probably be easier programming wise to get going.

Be aware noise, ground loops etc might be an issue. Looks like it should do I2S which might be cool to get running keeping it digital all the way through to the car headunit.

Current status of project:
- Sparkfun Purpletooth Jamboree board acquired after a bit of a wait for it to come back into stock (thanks, elperepat!).
- Purpletooth board tested, successfully pairs with my Honda stereo and survives power cycles and re-pairs automatically afterward. Empeg's output into the bluetooth into the car stereo sounds good.
- Confirmed that it accepts bluetooth commands from my factory car stereo. At least I think it does. It should. Though the empeg doesn't yet accept serial commands from the sparkfun board, I can at least press "pause" on my car stereo touchscreen and the sparkfun board mutes its output. I'm pretty sure that's what it's doing at least, since the pause button on the board itself also does the same thing.

To do:
- Figure out how to get the serial output of the Sparkfun board to change tracks and play/pause on the empeg itself.
- Options are: (a) Additional arduino piggyback board to translate sparkfun board's output into empeg-serial-input-compatible commands, or (b) Hijack kernel patch as Shonky suggested.
- Since I know how to do (a) but not (b), I might go that route.
- I need to learn the stuff in the undertanding the BC127 guide to do either of the above.

You shouldn't need to patch the kernel. So the Sparkfun board has a USB from the photo. That will probably just give you a virtual COM port if you plug it into a PC. I would expect from that you would/could/should get the skip/play/pause type messages. You can probably test and do that with some fairly simple (AT?) commands.

Now the empeg doesn't have a USB host port but does have a regular serial port. I'm assuming the white square in the middle of the red board is the actual BT module doing all the work. It will likely have a regular serial port on which with some level shifting should talk to the empeg serial port.

Then it's a case of an application or script that sits on the empeg talking to the BT module via the empeg serial port for commands and also talking to the player software (or kernel) to control the empeg player software. Passing the track info back to the car is likely even possible.

Or an Arduino that can do the USB host to the sparkfun board and then convert it to empeg serial commands. Arduino just seems a bit superfluous to me although is likely and easier method to program if low level stuff isn't your thing.

I wasn't going to look at details but I just did. The BC127 has both USB and serial interfaces, so there's no interface module on the red board to do that. If you can get access to that serial port, with a level shifter, it should connect direct to the empeg.

I've currently got the Sparkfun Jamboree board successfully getting its power from, and outputting its serial output to, an Arduino Uno that I had lying around, but I think I need to get a different Arduino board that includes two serial ports.

What I think I need is:

Sparkfun serial ->
Arduino serial input 1 ->
Arduino code to translate sparkfun messages into Empeg serial commands ->
Arduino serial output 2 ->
Arduino RS-232 Add-on board ->
Empeg RS-232 input.

Any particular reason to not just join the two serial interfaces together and do the work on the empeg?

A few reasons:

- Programming on the empeg itself is something I never ended up doing, so I don't even have the necessary compilers and toolchains installed, and now with Riocar,org down, there's not a lot of online help documentation for learning that anew. I know I could bug y'all here on the forum, but it'd be pretty slow going.

- I am comfortable with Arduino programming, having done some of it before, and the tools and online support is strong. I could get things done much more quickly that way.

- I like the idea that I might be able to make a module that is entirely external to the empeg and just plugs in. At that point, I could put it all together in a kit for anyone who wants to do the same thing.

In the end I might find my current method too limited and have to go the on-the-empeg route later anyway.

By the way, anyone have any docs of all the serial commands you can send to the empeg player to control playback?

For instance I know that "n" <cr> will go to the next track. But what about play/pause and previous track? Are there any others, like for FF/REW that sort of thing?

I would look in the FAQ but it's down.

No idea if current but Google found me this at Roger's blog, http://blog.differentpla.net/blog/2003/04/02/empeg-serial-port-commands :

2003-04-02 10:29:00 +0000

You can send the empeg player commands using the serial port. This is a list.

Case is ignored. Some commands do different things, depending on state. Each command usually needs to see LF afterwards.

Menu Navigation
Command Action
M Open menu/select menu item
* Cancel menu
N Next menu item
P Previous menu item

Track Navigation
Command Action
Space Play
C Play
W Pause
N Track Forward
P Track Back
F Start Fast Forward
B Start Rewind
A Cancel FFWD/REW

Visuals/Info
Command Action
V Next Visual
S Next Info
D Next Info
Quitting/Restarting
Command Action
Q Quit the player.
R Restart the player.

Volume Control
Command Action
+ CONTROL_VOLUMEUP
- CONTROL_VOLUMEDOWN
K CONTROL_LOUDNESSDOWN
L CONTROL_LOUDNESSUP

Input Selector
Command Action
[ CONTROL_EMPEG
] CONTROL_TUNER
= CONTROL_AUX

Tuner
Command Action
] CONTROL_TUNER
` CONTROL_RADIO_STORE
; CONTROL_TUNEUP
. CONTROL_TUNEDOWN

Miscellaneous
Command Action
* Mark Track
0-9 CONTROL_NUMBER0-CONTROL_NUMBER9
\ CONTROL_SLUMBER
| M_COMMAND_CACHE_NOW
#_fid_ REPLACE
#_fid_- ENQUEUE
#_fid_+ APPEND
#_fid_! INSERT
~ SuggestDiskSpinning
@ EnsureDiskSpinning
% CONTROL_SHUFFLE

Sure, just seems rather complex to put something inline in the serial port. You wouldn't necessarily need to compile code on the empeg. A script should be able to do it.

You could probably bitbang a suitable UART with your Arduino that you already have couldn't you? I'm not much of an Arduino guy, but I'm pretty sure it's feasible particularly for a reasonably dedicated device.

Yeah, all Arduino chips have "Software Serial" that enables multiple additional serial ports, in addition to the usual "hardware" port. So all that's needed is just a simple Atmega-328p chip, and a MAX RS232 interface chip.