MOST Bus – Media Oriented Systems Transport, it is a communication layer present in a lot of European cars. It’s mostly found on the higher end models. This article will assume the reader understands CAN bus as a lot of comparisons will be made between the two. Hopefully this gives an insight into how MOST Bus works.

Screenshot-2023-06-30-at-22.18.55-1024x506 How Most Bus Works Part 1

Reason For Most Bus

Let’s start off looking at Can Bus. Canbus sends a message of 8 bytes in length (technically theres a few extra bytes, but the data part is 8 bytes) this message can contain all sorts of different data, there may be certain bits in a byte to communicate discrete on off signal, or 4 bytes may be used to make a large number such as engine RPM.

If we wanted to we could send some media data on the Can Bus. To look into it, let’s take a 44khz 16 bit audio stream. The format of this stream is 2 bytes (equals 16 bits) per left and right channel, so if the stream is in stereo, this is a total of 4 bytes per audio packet. This works out around 1.4Mbps, standard Can at maximum speed is 1Mbps, from this it is clearly evident that Can is not suitable to media.

Enter Most Bus!

Most Bus solves the above by providing much more bandwith, it is mainly a synchronous system, set packets are sent out at regular intervals. Each packet is 64 bytes in total length, typical network speed is either 44100hz or 48000hz, this means a packet is sent out at either 44100 times a second or 48000, performing the maths, this equates to around 25Mbits per second opposed to canbus of 1Mbits per second.

Most Bus Network

Most Bus is a ring based system, all devices receive the fibre optic signal and transmit the fibre optic signal. Messages are sent in Blocks, which then make up a Frame. The timing of these frames are driven by one device, this device is called the network master, and has unique functionality on the Most network. Each device on the network has a couple of ways of being addressed, these are:

  • Logical Address – This is set in the device itself and is the most common way a device is communicated to, valid logical addresses are 0x0001 through 0x02FF, and 0x0500 through 0xFFFF. You may well find there’s a common range for the devices, for JLR cars, they are all 0x161 – 0x200.
  • Physical Address – Each device has a physical address which is the position of the device in the ring in reference to the Network Master. These are in address ranges 0x400 – 0x4FF, the master always takes address 0x400, the next device on the ring is 0x401 etc etc
  • Group Addressing – Each device can be part of a group, this is written to the OS8104 IC. Devices can then broadcast a message to all devices that are part of this group. Valid group addresses are from 0x0300 to 0x03C7.
  • Broadcasting – Devices can send a message to every device on the network, this is done using address 0x03C8. Examples of such messages are a shutdown request.


The frames are are made up of 64 bytes, 2 bytes are for admin and sync, another 2 bytes are for control data, the remaining bytes are for synchronous multimedia data, or for asynchronous control data (more on this later). A block is 16 frames, this then gives a total of 32 bytes of control data, this is important to note for the sections below.

Message Structure – Control

When a complete block is sent, there are 32 bytes available for control. Unlike Canbus, there are a few different message types, and messages can be sent to specific devices. The 32 Bytes are broken out into the below structure:

  • Bytes 0,1 – Device ID, this is either the logical address, or the physical address of the device.
  • Byte 2 – FBlockID this is the FBlock that the message relates to, FBlocks are explained further below.
  • Byte 3 – InstanceID this is the Instance ID of the message, Instances are explained further below.
  • Byte 4,5 (bits 0-3) – FktID this is the Function ID of the message, this is a total of 12bits in length, Functions are described further below.
  • Byte 5 bits 4-7 – OPType, this is the Operation Type, this is explained further below.
  • Byte 6 bits 0-3 – Message length, this is the amount of data that the message contains.
  • Byte 6 bits 4-7 – TelID This is the telegram ID, this is explained in more detail below
  • Bytes 8,20 – Message data


Function Blocks (Fblocks) are part of the core communication functionality within Most. FBlocks identify the device type, for a list of FBlocks see pages 77-79 of the Most Book, this list is not exhaustive, and also the manufacturers have the freedom to create their own, but by using this byte you can identify the type of device that is on the network.

Instance ID

Due to the way the application layer works, there can be multiple instances of each FBlock on the network, taking the amplifier as an example, on a freelander 2 a network scan shows 4 Amplifiers on the network. In reality there is only a single physical amplifier, however each device that wishes to communicate with the amplifier also has the amplifier FBlock present, this is to allow device shadowing, and a tidy way to store the state of the physical amplifier in each device that needs it. Each message is addressed to an FBlock and also the instance of the FBlock.


Each standard FBlock also has a set of Functions. These functions can be found via the Most Cooperation website, where each FBlock has a list of all of it’s assosciated functions. It’s important to note a subset of standard Functions are available, which can be implemented by every FBlock, in this link to the Most Cooperation site, you can download the revelant standards for the required version of Most, the “General FBlock” pdf contains a list of functions that any FBlock can implement.


Each message has an OpType, this is the operation type, and there are two different categories for these, one is Property, the other is Method. The Property is accessing details within the FBlock, Method is activating functionality in the FBlock. The value for OpType is an Enum, the values of which are below:

Property Request:

  • 0x00 – Set – Sets a Value
  • 0x01 – Get – Gets a value
  • 0x02 – SetGet – Sets the value and requests the new value in response
  • 0x03 – Increment – Increment the value
  • 0x04 – Decrement – Decrements the value
  • 0x05 – Get Interface – Return the interface of the Function

Property Responses:

  • 0x09 – Error Ack
  • 0x0C – Status – This is the usual response for a get
  • 0x0E – Interface – Response containing the interface
  • 0x0F – Error – Error response, the data contains a sub code to give more information

Method Requests

  • 0x00 – Start – Start the method
  • 0x01 – Abort – Abort the method
  • 0x02 – StartResult – Start the Method and send the result
  • 0x05 – Get Interface – Return the interface of the function
  • 0x06 – Start Result Ack – Start the method and send an Acknowledgement and result
  • 0x07 – Abort Ack – Abort the method and send an Acknowledgement and result
  • 0x08 – Start Ack – Start the method and send an Acknowledgement

Method Responses

  • 0x09 – Error Ack – Error Acknowledgement
  • 0x0A – Processing Acknowledgement
  • 0x0B – Processing
  • 0x0C – Result
  • 0x0D – Result Acknowledgement
  • 0x0E – Interface
  • 0x0F – Error

Message Length

This is a 4bit number specifying the message length of the data

Tel ID

This is the telegram ID. As we learnt above, each control message is 32 bytes in length, however Most has the ability to send much larger control messages, it does this by sending them in multiple chunks, here the TelID values helps us out, if the data is greater than 12 bytes (we lose 4 bytes to arbitration, and a further 6 to CRC and an various other admin data) then it chunks the messages. A value for tel ID greater than 0 means it is a multipart message, if the ID is 1, then its the first message, and the first byte of the message is 0. All other messages then have an ID of 2, and the first byte of each message is a counter that increments. The final message has an ID of 3 to signify then end of the message.


Here is a Most dump of a freelander 2











Let’s pick the below message


//converted to hex

You can see the details here of the entire message, and the elements that make it up. The data part is the raw data that has been received, the other values are parsed value from the data Buffer that has been received. The next part will go into greater detail on the message.

Hopefully this has been a useful introduction into how Most Bus works, the further sections will go into more detail on the message functionality, how to route audio data on the bus, and how to decode OEM specific functions.