Thread: Renault "Tuner List" Head Unit/CD changer hacking - Controls

Originally Posted by markcame

I'have read this interesting trhead and i will start to make an emulator for blaupunkt HU.But I need some advice, can i use the interface made for renault tuner list with my head unit ?

Warning though, the DISCLAIMER on the first post of this thread particularly applies for this post. Now you've been warned :-)
Clearly, don't just build the same interface, run the same software and hope it will work. According to information on http://www.mictronics.de/?page=cdc_proto#Blaupunkt (and assuming there is only one "Blaupunkt" protocol), there are similarities between the basic communication of Blaupunkt and the one described in this thread : asynchronous serial, and they seem to say it is compatible with a PC serial port.
Although, as you can see, the protocol itself is very different (changing speed, shorter messages, no acknowledge, etc.) so I think there's much reverse engineering and work involved. OTOH, the above page links to seemingly working code, although in assembly language... Obviously it has done before so it can be done again. Contact maybe the webmaster and see if he has more info or knows where to get some...
I would advise you to first search, both in these forums and on the web and also try to list compatible changers (maybe they share the protocol with other head units).
Then if you can't find anything, start maybe a similar thread and hope to get a few motivated people involved. This kind of project is a collaborative work and I really think you can't succeed alone... Hopefully youl'll find information or code here that you can reuse...

I sincerely wish you good luck.

Edit : The original page mentioned on the above site can be found thanks to the wayback machine and has subtle differences. The original author said the protocol is compatible with his microcontroller, not with a PC. PCs are limited to 8 bits of data while some microcontrollers allow 9 bit. This could be a HUGE problem. Sorry, can't help more...

Originally Posted by slimmegane

But at anyone interest the Support to Girder?

As I said, I only have interest in Girder as a last resort solution.
Plan A : I thought (and I still think) I can go without it. Monday, it was done at 90%, Tuesday it was done at 99% and today it's done at 99.9% but it still doesn't work and I'm beginning to pull my hair off (not that I have much hair left :-) ).
I've had great help on JNI by Mauro here and more help of Guino here but there's still a little bit missing somewhere so I'm gonna switch to plan B as I see you're impatient (and I'm sure you're not alone).
So instead of using native binding, I'm going to let Java execute a predefined command on the press of a button, as you suggest.

Bad news : I don't advise using Girder
Good news : I advise using Guino's direct equivalent

In the thread mentioned above, Guino gives the 10-line source code of a tool which sends a command to RR. So I think you can drop event.exe, RR.GML and girder altogether ! :-)

Here's a compiled copy of Guino's exec. Can you test it, see if it allows the same as girder and think of a good association of HU buttons > RR commands ?

On my part, I'll first code a simple executor plugin, to call anything on the press of a button (association will be in a config file)

Next, I'm thinking of a "router plugin", which could send different commands depending on the previous ones (e.g. NEXT when you're on Music skips to the next track, NEXT when you're on GPS zooms in, etc.), but that's for later.

I hope to have something running tomorrow...

Originally Posted by Vicne

I hope to have something running tomorrow...

Well, it's in CVS on sourceforge (ExecutorPlugin). I'll test and build the release tomorrow (well, Thursday night, I mean :-) ).

Thanks a lot Vicne and excuse me of impatience.

OK, as promised, here is the first version integrated with RoadRunner (or, to be precise, able to execute any program in response to button presses).
I know I said I wouldn't release zips here anymore, but the version is not sufficiently stable to call it a "release" on sourceforge, so let's call it 0.3 beta :-)

What's new ?
- New plugin (called ExecutorPlugin), allows execution of any command line to respond to a certain event. The new configuration file ExecutorPlugin.properties lists the mappings, so you can start Notepad when pressing NEXT and Word when pressing PREV. A much more useful way is to use either Girder's event.exe (which can do lots of things I guess) or directly RoadRunner's exec.exe. This tool (included in the latest RR releases and also in the zip below) just sends the given message to RR. For example, "exec.exe NEXT" causes RR to skip to next track. Simple, eh ? (Note that you may use Girder's event.exe instead if you like, or mix the 2).

- Reworked the way track change is handled when NEXT/PREV is pressed. I can't find back the bug report about sound being muted after a track change (was it you Slimmegane? Can you confirm the spdif was muted forever ?), but now, the emulator is behaving exactly like the CD changer (it responds with 4 frames : unload track 1 / busyA / busyB / load track 2). The result is that SPDIF is muted during a half a second or so. Annoying if you want to repurpose NEXT/PREV:-(. I'll try and see if I can get rid of the muting, or at least reduce it by removing some messages.

- Allowed GUI Plugin to kill emulator, after much debate with myself. This is not a clean exit but rather a kill.

Known issues :
- Buttons 1-6 aren't sent to the Plugins yet. Play/Pause/Next/Prev/Ffwd/Rew/Random are (or should be :-) )

- The emulator often gets the same frame twice since the switch to RxTx... Either the library calls up multiple time for the same frame, or the delay before the acknowledge is so long that the HU "retries" the message :-( I included a quick fix (don't process successive frames if they have the same ID) so it shouldn't be noticeable most of the time, but it's not clean at all.

- Displayed track number it often nonsense (although I worked on it), as is CD number (but I didn't even work on that :-))

I hope I'll be able to fix some of these glitches and release a 0.3 in the next few days.

In the meantime, let's make a contest on the most useful/practical mapping between HU events and RR commands (they are documented in 'Skin commands.txt' in the RoadRunner distribution).

Enjoy.

Mox,
Can you tell me what happens with the Connects2 I/F when you press PREV/NEXT ?
Is the sound muted for half a second or so, or does it continue to play without a glitch ?

Obviouslty if it's not muted it means there's a way to prevent the HU from muting on track change.

Thanks

Originally Posted by slimmegane

I think to keep Girder solution as primary because i think this is the faster and easy way to comunicate whit RR

In the end I think the direct solution is faster and easier than Girder, isn't it ?
However, I'm still hoping to make the DLL work because it could be bidirectional (to get back the track number from RR or Winamp and send it to the display). Moreover, it would be loaded once and for all instead of lauching a separate EXE on each keypress...