User Tools

Site Tools


melbus

This is an old revision of the document!


Pinout:

Ok the dreaded MELBUS.

After days of research and poking around with logic analyzer here is what we have. There are three wires as seen on the pinout DATA, CLOCK, and BUSY. Lets start with the easy part.

BUSY line is only used for devices to announce themselves on the bus. The line is pulled low for 1 second as soon as the device gets power. The HU in my case HU-613 then proceeds to use the CLOCK and DATA line for any further communication.

CLOCK is provided by the HU for communication to and from devices so there is nothing really to do on the clock line except to listen to the cycles and use them accordingly. Whenever the HU wants to say something on the bus the CLOCK starts ticking for 8 cycles until it is done sending the information. However if the HU is expecting a response it will keep cycling the clock for 8 cycles for each byte that it expects in return without doing anything on the DATA line.

DATA line is read by the devices like CD-Changer on a rising clock pulse. So at the beginning of a byte that the HU sends clock goes from HIGH to LOW and then the device reads the DATA line on every RISING clock edge. After the last bit the CLOCK remains HIGH until the next byte of information. Then the sequence repeats.

Init Sequence

So lets go through the basic init sequence that happens when a CD-Changer gets power.

  1. The CD-C pulls the BUSY low for 1 second
  2. The HU responds by sending 3 Init bytes (0x07, 0x1A, 0xEE).
  3. Then HU proceeds sending device ids followed by an empty 0xFF byte each.
  4. The CD-C waits until it reads its id on the bus (0xE8) and fills the next byte with the same byte 0xE8
  5. The HU keeps going through the rest of ids in case there are other devices on the bus

After Init the HU then addresses each device for basic information preceding each request with a unit id of the device it is talking to. In case of the CD-Changer the first byte will be 0xE8 and then the request. 0x1E 0xEF is the request that comes in for the CD-Changer asking it to provide CD cartridge info. Then it keeps cycling the clock until it got the information from the CD-C unit. Then the bus goes idle and the CD-CHANGER appears on the screen of the HU. No more communication goes on until CD-Changer is selected as source on the HU.

Example of init sequence: text (beware of shell escape sequences, best viewed in color-capable terminal): traces.txt

Update

After sniffing the bus for a while here is what was observed:

Looks like HU will allow devices to communicate to it provided device will send start condition.

Start condition :

  1. Busy and Data LOW.
  2. HU releases Busy and Data line.
  3. While keeping busy LOW generate clock and send data to HU

Stop condition :

Release Busy line right after the last bit has transmitted HU then regains control of CLK and DATA.

So far it looks like transmitting data to HU will look something like this: To transmit data to HU

  1. Check Busy if HIGH proceed if LOW wait.
  2. Data LOW
  3. After 320us Busy LOW
  4. After 1.72ms Data HIGH
  5. After 5.88ms Clock START with 10us duty cycle
  6. Busy HIGH as soon as the last clock pulse is over.

Some further investigation

This is the init on the HU with nothing attached to it.

07 1A EE 08 FF 10 FF 20 FF 28
FF 30 FF 38 FF 40 FF 48 FF 50
FF 58 FF 60 FF 68 FF 70 FF 78
FF 80 86 88 FF 90 FF 98 FF A0
FF A9 FF B0 FF B8 FF C0 FF C8
FF D0 FF D8 FF E0 FF E8 FF F0 FF

80 - Is unit id for the built in CD module which apparently also shares melbus with the rest of the units. Response to id request is 86 ??? Possibly different CD modules have different capabilities although trying different id within range did not unveil any difference in HU requests

CD module to HU communication

00 1A EC 87 87 18 84 E1 88 01 01 00

Right after INIT CD module has sent this info to the HU

00 1A EC - some kind of address / command combo

87 87 18 84 E1 88 01 01 00 - Data payload. This encodes several things. So far last three bytes are time that is displayed on the HU when fast forwarding. The rest is playback status, etc etc. In this particular case CD is not playing yet.

HU to CD module communication

81 1B E0 01 08 10 88 01 01 80 03 00 02 22

Next transmission on the bus is coming from the HU.

81 1B E0 01 08 - Address command combo 81 - addresses CD module 1B E0 01 08 is command

10 88 01 01 80 03 00 02 22 - Data payload. Here the CD module is filling the bytes requested by the HU. Last 3 Bytes are playback time. Byte before that is track number. Byte before that is track number as well. First byte is 10 ?? Second byte indicates playback 88. Third byte is 01 in playback,…

I'm still a little confused to where this is going so bare with me please there is some ranting here ;)

Conclusion or not so much

it looks like the HU pings the module for updates every once in a while but the CD unit is sending updates as soon as something changes. Like time seconds or track change or cd eject etc etc.

Here is an example from communication log.

81 1B E0 01 08 10 88 01 01 80 03 00 02 22 - Ping
00 1A EC 87 87 F8 85 E2 80 03 00 02 23 - Time updated to 23 seconds
81 1B E0 01 08 10 88 01 01 80 03 00 02 23 - Ping - time is still the same
81 1B E0 01 08 10 88 01 01 80 03 00 02 23 - Ping
00 1A EC 87 87 F8 85 E2 80 03 00 02 24 - Time updated to 24 seconds
81 1B E0 01 08 10 88 01 01 80 03 00 02 24 - Ping
81 1B E0 01 08 10 88 01 01 80 03 00 02 24 - Ping
00 1A EC 87 87 F8 85 E2 80 03 00 02 25 - Time updated to 25 seconds
81 1B E0 01 08 10 88 01 01 80 03 00 02 25 - Ping
81 1B E0 01 08 10 88 01 01 80 03 00 02 25 - Ping
00 1A EC 87 87 F8 85 E2 80 03 00 02 26 - Time updated to 26 seconds

This goes on for entire playback.

However if FF button is pressed the CD module floods the bus with status updates and the HU stays silent until the CD releases the bus

Also the addresses are somewhat similar.

HU ping starts with 81 1B E0
CD update starts with 00 1A EC

Quite similar. I'm guessing 00 is Device ID of the HU.

melbus.1398744854.txt.gz · Last modified: 2018/03/17 16:03 (external edit)