Porting Alpine M-Bus emulator from Arduino Pro Mini to Esp32 dev

[dadoc22]

Hi everybody,
I’m new to this forum. Being neither an engineer nor a programmer, I’ve started some years ago with some homebrew modules for home automation (eq3 and others). I can handle a soldering iron, modify code written by somebody who knows writing code, and I succeed normally with compiling and flashing etc.
But as a non-programmer I have clear limits when it comes to understanding and applying software/hardware issues, and this is the point where I am with my latest project.

My latest project is to create a AUX input for the original radio of my youngtimer car (a 1995 Jaguar XJS). It’s an Alpine head unit (HU) with a CD changer in the trunk, and Alpine’s M-Bus, used for communication between the HU and the CD changer, is the clue for the AUX input.

The HU only opens the audio signal coming in throug the CD line when it’s able to „talk“ to the changer via the M-Bus. So you would need a kind of M-Bus emulator to make the HU think that it was actually talking to a CD changer.

Fortunately, there was now need to reinvent the wheel, as this task has been adressed by several guys more familiar with coding and hardware than I am. The „mother of all M-Bus back-engineering“ would be http://www.hohensohn.info/mbus/

I successfully use Olystyle’s M-Bus library for Arduino with a Pro Mini (https://github.com/Olstyle/MBus); Picohar's approach with an AT128 also worked for me (https://github.com/picohari/atmega128_a ... s-emulator). For both, I am using Picohari’s hardware suggestion to split up the bus signal with a couple of transistors and resistors (https://raw.githubusercontent.com/picoh ... dapter.png). Interestingly, this is working fine without connecting to a 5 V source (or 12 Volt as in Jörg Hohensohn's suggestion).

Now I would like to go one step further, integrating A2DP bluetooth into the M-Bus dongle. This way, the original buttons of the HU (for example the buttons for selection of CD 1 to 6) could be used e.g. for sending play/pause/fwd/stop etc. commands to the connected smart phone.

This is when I decided to give the Esp32 a try, as it comes with integrated Bluetooth and there are nice libraries for a non-professional like me. I have the „ESP32 NodeMCU Dev Kit C with CP2102“. I was hoping to be able to use Olstyle’s library and sample code for the Esp32 (via Arduino IDE). The sample code (working, as said, with a Pro Mini), is https://github.com/Olstyle/MBus/blob/ma ... uttons.ino

Compiling and upload are working, but once connected to the HU, the bus doesn’t seem to enter into conversation.

I’ve changed the pin definitions for IN and OUT from 10 and 12 (Olstyle’s Pro Mini sample script) to pins 4 and 5 for the Esp32. I didn’t change the definition

Code: Select all

pinMode(_in, INPUT);
pinMode(_out,OUTPUT);

in Mbus.cpp, as I understood that it was ok for the Esp32, too.

But I’m afraid that there is more need for changes to have the ino running on the Esp32.
I would be very thankful if sb. could help me to achieve this.

Thanks & best regards
Martin

[wllm3000]

Interesting! I'm currently working on a similar project. I have a Honda Prelude form 1994. Recently installed it's OEM HU and wanted to add some functionality. I'm going a bit further

I ordered a CSR8675 bluetooth board (good for ad2p with aac/aptX codecs and handsfree for telephone )

What i want to achieve is using the ESP as M-Bus proxy between the cd-changer (yes I want to keep it installed). I have some basic communication functioning at the moment though not very stable. I think to get the best results, the send and receive functions need to be rewritten with timers and interrupts to reliable send messages over the bus, however if you delete the changer all together it might be just enough.

I basically used the same sources as you found, I'm mainly using the code written by Oliver Mueller. eventhough the code is horrid and basically a proof of concept, I'm willing to share it if I get it in slightly better shape

[dadoc22]

Very interesting! I also want to keep the changer, but I'm thinking to use a switch (relay) to change between the emulator and the changer. Fot changing from emulator to changer, you could even use a button of the HU. The other way round would require a switch connected to the emulator board, I believe.
Keep me posted!
Martin

[dadoc22]

Hi Wllm3000,

I have some basic communication functioning at the moment though not very stable.

Can you give me a hint whats needs to be done to have Oliver's code working on an ESP32? I use the "hardware" suggested by picohari which is working fine with Oliver's code on a Pro Mini, but wasn't able to get it to work on an ESP32, even having some external support by ESP32 pros...

[wllm3000]

Hi Dadoc22,

Hi Wllm3000,

I have some basic communication functioning at the moment though not very stable.

Can you give me a hint whats needs to be done to have Oliver's code working on an ESP32? I use the "hardware" suggested by picohari which is working fine with Oliver's code on a Pro Mini, but wasn't able to get it to work on an ESP32, even having some external support by ESP32 pros...

It's been a while

It basically comes down to using hardware timers and interrupts. I ditched the arduino IDE because it was a little limited and now I'm using ESP-IDF with Visual Studio Code and I'm figuring it all out as I make progress

My setup is like this: Honda radio (Panasonic), an Alpine CHA-S614 changer and an ESP Wrover devkit.

I have two "M-Bus interfaces"; one to communicate with the radio and another to communicate to the cd-changer, though this complicates things a bit I was able to hack together some code that has a "pass through" mode, this is mostly done with interrupts and timers. I'm able to make the radio and cd-changer play nicely together while I'm still able to decode the messages. Recently I've coded a function to intercept the repeat commands from the radio and go into "some emulation" mode which kind of works. I've also discovered that both the "emulators" from Oliver and from picohari aren't complex enough to fool my Honda radio, it seems some radio's are more "strict" regarding the M-Bus protocol also timing is something to keep in mind.

I'm currently trying to port most of the commands and structures from picohari as the code seems more advanced and was written with timers/interrupts to begin with.

The basic idea I'm currently working on:
when the RX goes high it will trigger an interrupt function. The function starts a timer for 0.8ms from now. if the pin is still high this is a bit 1 otherwise it's a bit 0. At the same time it will reset a timer which is 4ms. if the 4ms timer triggers the packet is "complete" and it starts the decoding functions.

While sending a bit I disable the interrupt first otherwise the ESP thinks a packet is incoming.

The code I currently have would be a disgrace to humanity however after I clean it up more and have some of the basics working I'll definitely share it.

[dadoc22]

Thanks for your reply. Meanwhile, I've got Olstyle's Code running on an Esp32 (with Jörg Hohensohn's "Hardware").
Are you using https://github.com/kjanesch/pseudochanger ?
As far as I understand, the Panasonic version of the M-Bus protocol differs from the Alpine version.

[wllm3000]

Thanks for your reply. Meanwhile, I've got Olstyle's Code running on an Esp32 (with Jörg Hohensohn's "Hardware").
Are you using https://github.com/kjanesch/pseudochanger ?
As far as I understand, the Panasonic version of the M-Bus protocol differs from the Alpine version.

Nice! Is your radio working nicely with the code?

I've read that too however it seems my radio uses the alpine set (ping/ack commands are alpine, not panasonic style). Honda had their oem radios manufactured by Alpine, Panasonic, Pioneer and Clarion. They had their "own" cd-changer (changed one pin left and audio gnd) but it was basically a a rebranded alpine changer. Because of this I think they decided to go

I'm working with the code from picohari. The protocol is mostly rewritten to use esp32 timers and interrupts. And of course the current libraries work with only one "mbus interface" where as my code can handle two at the same time.

[wllm3000]

Thanks for your reply. Meanwhile, I've got Olstyle's Code running on an Esp32 (with Jörg Hohensohn's "Hardware").
Are you using https://github.com/kjanesch/pseudochanger ?
As far as I understand, the Panasonic version of the M-Bus protocol differs from the Alpine version.

I'm using the code and hardware design from Harald W. Leschner https://github.com/picohari/atmega128_a ... dapter.png as I had the components already laying around.

I'm quite sure my radio uses the Alpine protocol because the ping commands are not like Panasonic. I got it to work mostly though sometimes it fails a bit and needs a reset. Some finetuning and optimization is still required.

[wllm3000]

Alright, It seems to be working "a little".

Passthrough mode usually works without too much trouble, emulation mode needs more enhancements and tuning. The rest of the code needs a decent cleanup and restructuring but still, the code quality is pre-alpha stage.

The idea here is that when you enable "Emulator" mode, by pressing repeat button 6times within 1.5seconds the display shows CD7 where this model only has a 6CD changer option. CD7,8,9 are for the "special" modes; 7=BT, 8=IndashCD, 9=aux. There is a webserver running on the ESP with a few debug commands to fiddle with the mbus replies ans so on. SSID=test Password=password

The code is able to go to emulation mode and back to CDC mode and resume cdc playback where it left off.

Here is the source and in the folder flash are some binaries. It's built for an ESP32 Wrover with 4MByte flash.
https://pw12.nu/STATIC/prelude/mbus0.0.1.zip

[dadoc22]

Hmm, somehow I missed the alert about your recent posts :/
Thanks a lot for sharing your WIP, I'll certainly try to get it working. At the moment, I only have ESP32-WROOM 32 modules at hand, not a Wrover. Do you think it might work anyhow?