Differences

This shows you the differences between two versions of the page.

--- melbus [2014/04/29 07:14]
alex
+++ melbus [2018/03/17 16:03] (current)
@@ Line 3: / Line 3: @@
 {{::melbus:dinmodification.png?200|}}
-Ok the dreaded **MELBUS**.
+The misterious **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.
+==== Physical Interface ====
-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.
+Melbus physical interface consists of 3 lines:
-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.
+  - MSCK - the clock signal
+  - MDATA - the data signal which carries information
+  - MBUSY - indicates whether the data signal is busy or not
+These lines are in HIGH idle state.
+The communications on Melbus are implemented on NEC microcontrollers.
+HU-850 uses **uPD70F3035AYGC** MCU clocked at 12MHz - {{:nec-upd70f3035aygc-datasheet-manual.pdf|Datasheet}}
+Internal CD module in HU-613 uses **uPD78013FGCE03** MCU clocked at 10MHz - {{:nec-upd78013fgce03-datasheet-manual.pdf|Datasheet}}
-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.
-  - The CD-C pulls the BUSY low for 1 second
-  - The HU responds by sending 3 Init bytes (0x07, 0x1A, 0xEE).
-  - Then HU proceeds sending device ids followed by an empty 0xFF byte each.
-  - The CD-C waits until it reads its id on the bus (0xE8) and fills the next byte with the same byte 0xE8
-  - 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: {{::melbus:traces.jpg?direct&200|}} text (beware of shell escape sequences, best viewed in color-capable terminal): {{::melbus:traces.txt|}}
+=== Main Init ===
+To initiate main init request from the HU-xxxx newly connected device must pull the MBUSY line low for about a second.
+Main init request from HU (HEX):
+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
+Init command provided by the HU:
+1A EE
+The rest of the bytes are unit ids of devices that could possibly be connected. If any of the devices reads its id it should fill in the FF with its id.
-==== Update ====
+In the init request above there is a response from internal CD module located inside the HU which illustrates the concept. The CD module read the device id of 80h and responded with its id of 86h:
-After sniffing the bus for a while here is what was observed:
+86
-Looks like HU will allow devices to communicate to it provided device will send start condition.
+=== Secondary Init ===
-Start condition :
+The secondary init or init at ignition is a bit different from main init. When the ignition is turned on in the car the HU sends out a request to all devices that it remembers were identified during the main init. Here is what it looks like:
-  - Busy and Data LOW.
+00 1C ED 80 86 E8 EE
-  - HU releases Busy and Data line.
-  - While keeping busy LOW generate clock and send data to HU
-Stop condition :
+Here it basically asks if the CD module and CD-C module are still present on the bus. If one of the units does not respond to this message the corresponding intput will not light up on the screen such as CD-CHGR and will no longer be selectable via source select dial.
-Release Busy line right after the last bit has transmitted
+==== Protocol ====
-HU then regains control of CLK and DATA.
-So far it looks like transmitting data to HU will look something like this:
+Melbus actually looks very similar to a half-duplex SPI communication where the data utilizes only 1 bi-directional line. The master sends address of the device, then one or more commands and then sends empty FFh bytes keeping the data line in input mode so that slave devices can send out the data using the clock provided by the master.
-To transmit data to HU
-  - Check Busy if HIGH proceed if LOW wait.
+All the nasty details of this protocol have not beed identified yet but here is what some frames look like:
-  - Data LOW
-  - After 320us Busy LOW
-  - After 1.72ms Data HIGH
-  - After 5.88ms Clock START with 10us duty cycle
-  - Busy HIGH as soon as the last clock pulse is over.
-==== Some further investigation ====
+  | Address | Command | Response from device |
-This is the init on the HU with nothing attached to it.
+  |   E8    |  1E EF  |  00 08 01 4A 0C CC   |
-1A EE 08 FF 10 FF 20 FF 28\\
+This is just an example where HU initiates communication by selecting a slave device by sending a device id E8h, then sends a command 1Eh EFh. Device then processes the command and responds with appropriate data.
-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
-- 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
+Some data bytes that come as response from devices are in fact just data like when CD-C sends information about what CD# is playing or Track# or time is just sent as numbers. For example:
-== CD module to HU communication ==
+CD# range is 01 - 10 where 0A - 0F is invalid range.
-1A EC 87 87 18 84 E1 88 01 01 00
-Right after INIT CD module has sent this info to the HU
+So in other words just plain text. Other bytes are some kind of bitfields or switches or flags if you will that either identify the state of the CD-C or indicate some other functions. Not all of them have been identified.
-1A EC - some kind of address / command combo
+Devices that communicate over Melbus have 2 modes of operation. By default they are all in slave mode. But they can also operate in master mode as well. Master mode is again very similar to SPI protocol, however it is very different. When a device wants to become master all it has to do is pull the data line low for a very short period of time (around 2ms). The HU then will send a broadcast message including ids of all devices that were identified during the main init sequence. Whichever device wants to become master has to respond to its device id just like in the init except the id will be a little different. In the case of internal CD module the id it provides during main init is 86h, when it responds to the broadcast message when CD wants to be master the id becomes 87h. To help visualize:
-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.
+ 1A EC 87 FF - This is the message that comes from the HU when CD module notifies it about going into master mode. FFh is where the CD module going to put its ID. Basically if there is more than 1 unit on melbus and depending on priority there will be more than 1 unit id here and once the unit requesting master mode populates the response the HU stops the clock and releases data line. The requesting module then generates its own clock and sends the message to HU.
-== HU to CD module communication ==
+   | Master request broadcast | id | response | data sent by CD module to HU |
-1B E0 01 08 10 88 01 01 80 03 00 02 22
+   |        00 1A EC          | 87 |    87    |     18 84 e1 8d 01 01 00     |
-Next transmission on the bus is coming from the HU.
+Data that the CD module sends to HU probably follows the following format:\\
+bytes - command, the rest is data.
-1B E0 01 08 - Address command combo 81 - addresses CD module 1B E0 01 08 is command
+The HU and the internal CD module communicate in a very straight forward way. The HU requests playback status and the CD responds with the appropriate data. When something changes like time updated, track changed, etc. the CD module requests master mode and sends updated information to the HU. Here is an example log of such communication:
-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,...
+1B E0 01 08 10 88 01 01 80 03 00 02 22 - HU request update
+1A EC 87 87 F8 85 E2 80 03 00 02 23    - CD module updates HU with fresh data
+1B E0 01 08 10 88 01 01 80 03 00 02 23 - HU request update
+1B E0 01 08 10 88 01 01 80 03 00 02 23 - HU request update
+1A EC 87 87 F8 85 E2 80 03 00 02 24    - CD module updates HU with fresh data
+1B E0 01 08 10 88 01 01 80 03 00 02 24 - HU request update
+1B E0 01 08 10 88 01 01 80 03 00 02 24 - HU request update
+1A EC 87 87 F8 85 E2 80 03 00 02 25    - CD module updates HU with fresh data
+1B E0 01 08 10 88 01 01 80 03 00 02 25 - HU request update
+1B E0 01 08 10 88 01 01 80 03 00 02 25 - HU request update
+1A EC 87 87 F8 85 E2 80 03 00 02 26    - CD module updates HU with fresh data
-I'm still a little confused to where this is going so bare with me please there is some ranting here ;)
+Also here are some low resolution scope images of this communication details are not very visible but it captures the whole frame:
-== Conclusion or not so much ==
+HU -> CD
-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.
+{{:hu-to-cd-data.png?200|}}
-Here is an example from communication log.
+It is also obvious on the image below that the slave in master mode clocks out data significantly slower than HU.
-1B E0 01 08 10 88 01 01 80 03 00 02 22 - Ping\\
+CD -> HU
-1A EC 87 87 F8 85 E2 80 03 00 02 23    - Time updated to 23 seconds\\
+{{:cd-to-hu-data.png?200|}}
-1B E0 01 08 10 88 01 01 80 03 00 02 23 - Ping - time is still the same\\
-1B E0 01 08 10 88 01 01 80 03 00 02 23 - Ping\\
-1A EC 87 87 F8 85 E2 80 03 00 02 24    - Time updated to 24 seconds\\
-1B E0 01 08 10 88 01 01 80 03 00 02 24 - Ping\\
-1B E0 01 08 10 88 01 01 80 03 00 02 24 - Ping\\
-1A EC 87 87 F8 85 E2 80 03 00 02 25    - Time updated to 25 seconds\\
-1B E0 01 08 10 88 01 01 80 03 00 02 25 - Ping\\
-1B E0 01 08 10 88 01 01 80 03 00 02 25 - Ping\\
-1A EC 87 87 F8 85 E2 80 03 00 02 26    - Time updated to 26 seconds
-This goes on for entire playback.
+==== Appendix ====
-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
+=== Known IDs ====
-Also the addresses are somewhat similar.
+^      Unit       ^ ID Main Init ^ ID Response ^ ID Master Mode ^ ID When addressed by HU ^
+| MD (Internal)   |      70      |      76     |       77       |        70 or 71         |
+| CD (Internal)   |      80      |      86     |       87       |        80 or 71         |
+| TV (External)   |      A9      |      AE     |       AF       |        A8 or A9         |
+| DAB (External)  |      B8      |      BE     |       BF       |        B8 or B9         |
+| SAT (External)  |      C0      |      C6     |       C7       |        C0 or C1         |
+| MD-C (External) |      D8      |      DE     |       DF       |        D8 or D9         |
+| CD-C (External) |      E8      |      EE     |       EF       |        E8 or E9         |
-HU ping starts with    81 1B E0\\
+=== Known Commands ===
-CD update starts with  00 1A EC\\
-Quite similar. I'm guessing 00 is Device ID of the HU.
+^ Origin ^ Destination  ^       Command         ^       Meaning         ^  Response expected  ^
+|   HU   | CD-C or MD-C | 1E EF                 | Cartridge Information | Yes - 6 Bytes       |
+|   HU   | CD-C or MD-C | 1B E0 01 08           | Track Information     | Yes - 9 Bytes       |
+|   HU   | CD-C or MD-C | 1B 2D 40 01           | Next Track            | No                  |
+|   HU   | CD-C or MD-C | 1B 2D 00 01           | Previous Track        | No                  |
+|   HU   | CD-C or MD-C | 1A 50 41              | Next CD               | No                  |
+|   HU   | CD-C or MD-C | 1A 50 01              | Previous CD           | No                  |
+|   HU   | CD-C or MD-C | 19 2F                 | Power Up              | Yes - 1 Byte (ack)  |
+|   HU   | CD-C or MD-C | 19 22                 | Power Down            | Yes - 1 Byte (ack)  |
+|   HU   | CD-C or MD-C | 19 29                 | Fast Forward          | Yes - 1 Byte (ack)  |
+|   HU   | CD-C or MD-C | 19 26                 | Fast Rewind           | Yes - 1 Byte (ack)  |
+|   HU   | CD-C or MD-C | 19 2E                 | Scan Mode             | Yes - 1 Byte (ack)  |
+|   HU   | CD-C or MD-C | 19 52                 | Random Mode           | Yes - 1 Byte (ack)  |

Open-source Volvo Infotainment system

User Tools

Site Tools

Differences

Page Tools