spezializten wrote:

Phil, what have happened to Linkplayer 2? I'm just curious about the status. I'm still using it with very good results.

/Björn

Björn, could you open a new thread for this please? There is already quite a lot of detailed discussion / information on this thread relating to a very specific topic and I'm keen that it does not end up wandering off topic as this will make it much more difficult to refer back to and find relevant information for those working on this project.

BeoMotion wrote:

riverstyx wrote:

I think it is probably just inverted high/low logic, with the byte boundaries being shifted around a little due to any inverted start or stop bits or gaps also being misinterpreted.

Yes, you are totally right.
Connected a logic analyzer today and immediately saw this.
Switched over to inverted mode and all values were like expected.

That's excellent news - it seems then we have a cheap and simple way to receive data from the ML bus which for some applications may be all that someone needs, and should in any case aid with the reverse engineering of the protocol.

PhilLondon wrote:

Oh and I forgot... the last byte before the last 00 is a checksum.

Phil, thank you for all of the information. It's much appreciated.

It has also enabled me to confirm that much of the MLGW protocol is, as I expected, pretty much unmodified ML data.

The MLGW protocol documentation can be found here:

http://mlgw.bang-olufsen.dk/source/documents/mlgw_2.24b/MlgwProto0240.pdf

Martin.

riverstyx wrote:

It has also enabled me to confirm that much of the MLGW protocol is, as I expected, pretty much unmodified ML data.

The MLGW protocol documentation can be found here:

http://mlgw.bang-olufsen.dk/source/documents/mlgw_2.24b/MlgwProto0240.pdf

I am also familiar with the MLGW protocol. They share the same codes for sources, keys, states, but the rest is totally different. The MLGW greatly simplify the messages.

PhilLondon wrote:

I am also familiar with the MLGW protocol. They share the same codes for sources, keys, states, but the rest is totally different. The MLGW greatly simplify the messages.

Sorry Phil, you're right of course - "unmodified" was a poor choice of word on my part, "repackaged" would probably have been closer, and as well as the MLGW only communicating a subset of the raw masterlink data there are obviously additional telegram types defined within the MLGW protocol to deal with MLGW <-> 3rd party communication which will be of no relevance when dealing with the masterlink comms directly, but the document should in any case prove a useful reference for the parts that are common to both protocols.

On a separate note, there was for some time a section/link for the beonet protocol on the beointegration site, which stated 'not yet published' - which I had hoped was an indication that B&O were intending to publish this at some stage, but this has now been removed and I've had a response from beocare when I asked about it stating:

"I'm sorry but the information on Beointegration is wrong. We will not release our beonet protocol. Instead we are working with control system partners and let them build a driver to control Bang & Olufsen products.

Currently we have drivers for Crestron, Control4 and Savant."

I don't currently own any beonet products but this is still disappointing as I had hoped to be able to write some code to provide control of beonet products without having to resort to further reverse engineering efforts first.

Martin.

PhilLondon wrote:

Oh and I forgot... the last byte before the last 00 is a checksum.

Again, thanks for all that info.

Today I built the inverting logic and connected it between the MAX and the Raspberry.
And viola - it works like a charm now :-) 

Now we can start to understand how the protocol works.
No need for EOL components like BeoPort etc. Just some simple standard components for little money.

See the attached schematic and feel free to use it on your very own risk. 
It is connected to a Raspberry Pi and now part of my setup. So I can use SSH to log and see all the ML data without touching a single wire. 

There is a lot to understand. Especially when selecting RADIO or CD from BS5 a lot of data is going through the bus. Might be due to meta data like station and track names in this case. I won't post this here since it is really "a lot" of data. I may upload it to e.g. pastebin and link it here for further analyzing later. Even when pressing standby it is much more data then a simple status sequence.

Here is a little cut out from my recent dump. Test setup is [ BV7 (OPT.2) ]  <->  [ BS5 (OPT.0) ]  

System is playing A.AUX. Beo4 - CURSOR UP:

c1 c0 01 0a (from v.master to a.master ?)
00 00 00 0d 03 01 97 1e 02 54 00  (the up command ?)
c1 c0 01 0a 00 00 00 0d 03 01 97 7e 02 b4 00 (the release command ?)

System is playing A.AUX. Beo4 - CURSOR DOWN:

c1 c0 01 0a 00 00 00 0d 03 01 97 1f 02 55 00
c1 c0 01 0a 00 00 00 0d 03 01 97 7e 02 b4 00

System is playing A.AUX. Beo4 - STOP:

c1 c0 01 0a 00 00 00 0d 03 01 97 36 02 6c 00
c1 c0 01 0a 00 00 00 0d 03 01 97 7e 02 b4 00 

System is playing A.AUX. Beo4 - PLAY:

c1 c0 01 0a 00 00 00 0d 03 01 97 35 02 6b 00
c1 c0 01 0a 00 00 00 0d 03 01 97 7e 02 b4 00 

Login to view image

One step volume up via BS5 wheel:

c0 c1 01 0a 
00 47 00 20 05 02 00 01 ff ff 60 59 00

One step volume down via BS5 wheel:

c0 c1 01 0a 
00 47 00 20 05 02 00 01 ff ff 64 5d 00 

BeoMotion wrote:

System is playing A.AUX. Beo4 - PLAY:

c1 c0 01 0a 
00 00 00 0d 03 01 97 35 02 6b 00 c1 c0 01 0a

Indeed these are simulated key presses (8th byte = 0D). Going from the Video system (C0) to the Audio system (C1).

The 11th  position is the source (97 = A,AUX), 

The 9th position is (i think) how long presses are handled (either sending repeated keypresses, or sending a KEY_RELEASE code when the key is released).

The 12th position is the key code. 35 = Play.

I posted another message earlier but it ended up in Moderation for some reason. I guess it will probably appear in due course but there was nothing of any real significance so doesn't matter if it doesn't.

Anyway, thanks for the schematic and the sample data. I'm going to start writing some code to translate some of the captured data into a more human readable form (based on the information provided by Phil and in the old post from psand) so that we can hopefully work out which attributes are already understood and which require further investigation. Whilst most of my system is still stacked up in the kitchen I do have an old avant and an ouverture still in use upstairs so I will reconfigure these as audio and video masters and try and capture some data from those - I would expect much less status related traffic from those given their age (and lack of MLGW compatibility) but a simpler data set might be good to start with anyway.

If you are able to upload the dumps you have taken somewhere that would be useful as it will give me some more data to test my code.

Cheers,

Martin.

PhilLondon wrote:

Indeed these are simulated key presses (8th byte = 0D). Going from the Video system (C0) to the Audio system (C1).

The 11th  position is the source (97 = A,AUX), 

The 9th position is (i think) how long presses are handled (either sending repeated keypresses, or sending a KEY_RELEASE code when the key is released).

The 12th position is the key code. 35 = Play.

Yes, this makes sense. Thanks.
Just re-formatted the codes above that it is more clear to see that we have two sequences on each key press. The second one being the release command. 

Here is what happens when pressing standby when the system is already in standby:

c2 c0 01 0a 47 00 00 11 04 02 00 00 01 02 ee 00
83 c0 01 14 00 0b 00 87 1f 04 0b 01 00 00 40 00 01 ff ff ff ff 06 ff 01 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 54 00
2b c0 01 14 00 29 00 87 1f 04 29 01 00 00 00 00 01 00 00 01 ff 00 02 02 ff ff 00 ff 00 00 ff ff 00 00 00 00 00 00 00 00 00 fd 00
83 c0 01 14 00 29 00 87 1f 04 29 01 00 00 00 00 01 00 00 01 ff 00 02 02 ff ff 00 ff 00 00 ff ff 00 00 00 00 00 00 00 00 00 55 00 

riverstyx wrote:

Anyway, thanks for the schematic and the sample data. I'm going to start writing some code to translate some of the captured data into a more human readable form (based on the information provided by Phil and in the old post from psand) so that we can hopefully work out which attributes are already understood and which require further investigation. Whilst most of my system is still stacked up in the kitchen I do have an old avant and an ouverture still in use upstairs so I will reconfigure these as audio and video masters and try and capture some data from those - I would expect much less status related traffic from those given their age (and lack of MLGW compatibility) but a simpler data set might be good to start with anyway.

Okay, sounds great.

riverstyx wrote:

If you are able to upload the dumps you have taken somewhere that would be useful as it will give me some more data to test my code.

I will do some additional dumps over the next days and upload them elsewhere but here is a first start. Very curious about how the addressing stuff works...

BR,
BeoMotion.

System was Playing N.Radio and then pressed CD:

c1 c0 01 0b 00 00 00 04 03 04 02 01 00 9b 00 c0 c1 01 14 00 00 00 04 03 04 01 01 01 a4 00 c1 c0 01 0b 00 00 00 45 0d 01 02 8d 00 02 01 00 01 00 00 00 03 02 00 78 00 c0 c1 01 14 00 00 00 44 0d 07 02 6f 00 02 01 00 02 00 00 00 00 00 8d f1 00 c1 c0 01 0a 00 00 00 10 03 03 01 00 02 a5 00 83 c1 01 14 00 8d 00 87 1f 04 8d 01 00 00 1f be 01 00 00 00 ff 02 01 00 03 01 01 01 03 00 02 00 00 00 00 01 00 00 00 00 00 0a 00 c0 c1 01 14 00 00 00 44 08 05 02 8d 00 02 01 00 00 00 79 00 c0 c1 01 14 00 00 00 82 0a 01 06 8d 00 02 00 00 00 00 00 01 b9 00 83 c1 01 2c 00 8d 00 06 11 00 03 01 01 00 00 43 44 20 20 20 20 20 20 20 20 20 20 e1 00 83 c1 01 2c 00 8d 00 0b 11 00 01 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 50 6f 70 ca 00 83 c1 01 2c 00 8d 00 0b 1c 00 02 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 20 2d 20 53 69 6e 67 6c 65 5d 00 83 c1 01 2c 00 8d 00 0b 12 00 03 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6b 6f 6e 27 00 83 c1 01 2c 00 8d 00 0b 13 00 04 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 87 00 83 c1 01 2c 00 8d 00 0b 13 00 05 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 4b 45 49 4e 45 0d 00 83 c1 01 2c 00 8d 00 0b 15 00 06 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 55 6e 6b 6e 6f 77 6e 94 00 83 c1 01 2c 00 8d 00 06 11 00 03 01 01 00 00 43 44 20 20 20 20 20 20 20 20 20 20 e1 00 83 c1 01 2c 00 8d 00 0b 11 00 01 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 50 6f 70 ca 00 83 c1 01 2c 00 8d 00 0b 1c 00 02 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 20 2d 20 53 69 6e 67 6c 65 5d 00 83 c1 01 2c 00 8d 00 0b 12 00 03 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6b 6f 6e 27 00 83 c1 01 2c 00 8d 00 0b 13 00 04 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 87 00 83 c1 01 2c 00 8d 00 0b 13 00 05 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 4b 45 49 4e 45 0d 00 83 c1 01 2c 00 8d 00 0b 15 00 06 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 55 6e 6b 6e 6f 77 6e 94 00 83 c1 01 2c 00 8d 00 06 11 00 03 01 01 00 00 43 44 20 20 20 20 20 20 20 20 20 20 e1 00 83 c1 01 2c 00 8d 00 0b 11 00 01 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 50 6f 70 ca 00 83 c1 01 2c 00 8d 00 0b 1c 00 02 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 20 2d 20 53 69 6e 67 6c 65 5d 00 83 c1 01 2c 00 8d 00 0b 12 00 03 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6b 6f 6e 27 00 83 c1 01 2c 00 8d 00 0b 13 00 04 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 87 00 83 c1 01 2c 00 8d 00 0b 13 00 05 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 4b 45 49 4e 45 0d 00 83 c1 01 2c 00 8d 00 0b 15 00 06 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 55 6e 6b 6e 6f 77 6e 94 00