How Most Bus Works Part 2 – How Most Control Messages Work

This is the second part to how Most Bus works, part 1s found here. This post is now going to cover how Most Bus control messages work, the data structure of control messages, how you can find the relevant data sheets for each function, and how to send your own messages.

Message Structure

We will start with the message identified from the first part of this series. Displayed below is a full dump and also the chosen message to disect in this article:

{"fBlockID":49,"instanceID":2,"fktID":513,"opType":12,"telId":0,"telLen":6,"data":[49,2,32,28,6,2,0,0,0,191,104,0,0,0,0,0,0],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":513,"opType":12,"telId":0,"telLen":6,"data":[49,2,32,28,6,2,0,0,0,199,56,0,0,0,0,0,0],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":513,"opType":12,"telId":0,"telLen":6,"data":[49,2,32,28,6,2,0,0,0,207,8,0,0,0,0,0,0],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":513,"opType":12,"telId":0,"telLen":6,"data":[49,2,32,28,6,2,0,0,0,210,240,0,0,0,0,0,0],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":513,"opType":12,"telId":0,"telLen":6,"data":[49,2,32,28,6,2,0,0,0,214,216,0,0,0,0,0,0],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":514,"opType":12,"telId":0,"telLen":2,"data":[49,2,32,44,2,0,6,0,0,0,0,0,0,0,0,0,0],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":1056,"opType":12,"telId":1,"telLen":12,"data":[49,2,66,12,28,0,6,0,1,82,101,115,116,108,101,115,115],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":3124,"opType":12,"telId":1,"telLen":12,"data":[49,2,195,76,28,0,0,6,0,0,22,0,6,0,6,1,82],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":3124,"opType":12,"telId":2,"telLen":12,"data":[49,2,195,76,44,2,0,1,0,1,0,1,0,0,0,218,192],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":513,"opType":12,"telId":0,"telLen":6,"data":[49,2,32,28,6,2,0,0,0,3,232,0,0,0,0,0,0],"sourceAddrHigh":1,"sourceAddrLow":128}

{"fBlockID":49,"instanceID":2,"fktID":514,"opType":12,"telId":0,"telLen":2,"data":[49,2,32,44,2,0,6,0,0,0,0,0,0,0,0,0,0],"sourceAddrHigh":1,"sourceAddrLow":128}

//converted to hex
{
  "fBlockID":0x31,
  "instanceID":0x02,
  "fktID":0x202,
  "opType":0x0C,
  "telId":0x00,
  "telLen":0x02,
  "data":[0x31,0x02,0x20,0x2C,0x02,0x00,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00],
  "sourceAddrHigh":0x01,
  "sourceAddrLow":0x80}

Let’s break this message down bit by bit, we will start with the FBlock ID, it has a hex value of 0x31 if we look into the Most Book at page 78 we can see a definition of all FBlock IDs

FBlockID

As shown above using this picture we can see the message has originated from an Audio Disk Player.

Instance ID

As discussed in part one, there can be multiple instances of the same FBlock, these can either be physical instances or “shadow” instance, the message we have received here is from instance ID 0x02

Function ID (FktID)

This is the function ID and displays what type of message is being sent, which in turn shows how to handle the data. If you go to the Most Cooperation website you can download a zip file of FBlock libraries, 2v5 is the version being used in this example, after downloading and extracting the FBlock library, you can navigate to MOST_2V5_FBlock_Library/3_Archived_FBlocks/FBlock_AudioDiskPlayer_2V4-0 and open the pdf. Now that we have this pdf, on page 4 there are a list of the functions available according to the Most specification, we are looking for 0x202 which we can see relates to TrackPosition on page 20.

OpType

OpType is the operation type, looking at page 20 from above we can see there are a few available OpTypes for TrackPosition(0x202), these include Set, Get, SetGet, Increment, Decrement, Status and finally Error. We have received an OpType of 0x0C, going back to Part 1 we can look up this OpType and we can see it relates to Status, so the Audio Disk Player is sending out a status message for the track position.

TelID / TelLength

TelId is set to 0, this means this is not a multi part message, telLength is set to 2, which shows in the data Buffer there are 2 bytes of data.

Data

Now for the important part, the data Buffer, when using the Most Explorer to take your Most Bus dumps, it will put the entire message into the data Buffer, this means there are duplicate bytes in here that form the above datatype which we have just covered. To remove the known data bytes we need to ignore the first 5 bytes, this results in the data buffer being stripped from this:

"data":[0x31,0x02,0x20,0x2C,0x02,0x00,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]

To this:

"data":[0x00,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]

We know that thanks to the TelLength data, this message contains just two bytes. Due to this can further strip this down to:

"data":[0x00,0x06]

So what does 0x00 0x06 actually mean? If we take a look back at page 20 of the Audio Disk Player FBlock datasheet, we can see that for TrackPosition(0x202) with a Status(0x0C) response, the parameter it supplies is a “Track”. Therefore using the parameter section just below on page 21, we can see a Track is an unsigned word. From the buffer we need to read an unsigned word, in Javascript this would look like the below

let data = Buffer.from([0x00, 0x06])
console.log(data.readUint16BE(0))

This will output the value of 6, so the premise of this entire message is to say that the track number has changed to track 6. Using this structure of the data sheets, standard Most blocks and messages can be decoded in this way.