As already described in some other threads, I am trying to gain "full"
control of a Beomaster 6500 by sending datalink commands via TV/Aux port.
My initial setup looks the following:
- Beolab 8000 connected to Beolab 2 connected to Power Link 1
- MCL Sensor – data (White) connected to BM6500 TV/Aux – Datalink
- MCL Sensor – ground connected to BM6500 Aux – ground
- MCL Sensor – 5V connected to external power supply
- MCL Sensor in option 1 (Standby – while keeping the timer button on MCL Sensor depressed, press “AV” button on Beolink 1000)
- Ardunio Uno R4 - ground connected to BM6500 Aux – ground
- Arduino Uno R4 - Pin 2 connected BM6500 TV/Aux – Datalink
- BM6500 in option 2 (Standby – press “sound”, “2”, “store”)
https://github.com/toresbe/datalink/blob/main/datalink86-captures-new.txt#L26 But instead of the 0x09 at the end (digit-9) give it a try with 0x60 (volume up) or 0x0d (mute toggle). Maybe it will then leave the muted state it started up with.
Unfortunately, this also did not do the trick, like ). Or is it perhaps a question of BM settings after all (
I also want to comment on your previous post from another thread:https://github.com/toresbe/datalink/blob/main/datalink86-captures-new.txt#L26 But instead of the 0x09 at the end (digit-9) give it a try with 0x60 (volume up) or 0x0d (mute toggle). Maybe it will then leave the muted state it started up with. So as mentioned I also tested your suggestions without success (no unmuting of Powerlink Ports). And while I tested, I also compared them to the Datalink'86 documentation: The Datalink'86 document states, the transmitted commands can be split into 4 blocks. And following Figure "Fig. 2045-4 gives an example of a complete data transmission" I assumed the Header is always 14 bits long:Assuming that 0x60 is the usual command for "increase volume" and following your suggestion to start with the input from the Github link: S 0000 00001 00001 001 E. Then replacing 0x09 with 0x60 already leads to an interference with the address information of the header. Maybe I misunderstood you here? However, confused by this, I tested several options:
- Start
- Header
- Format [4 Bits]
- Address (to) [5 Bits]
- Address (from) [5 Bits]
- Data ["... may be commands or ASCII codes"]
- Stop
So I can't help but notice that 0x60 is part of the option 3 command and also the length of the command is the same as those from the Github Link, but it seems to be filled from the back, overwriting parts of the header. This left me completely confused about the DL86 protocol and unfortunately, I can't figure it out. Or maybe I'm misunderstanding something from the documentation... Anyway, I'm curious what your take is on this ?
- Following your suggestion: S 0000 00001 00001 100000 E No response by the BM.
- Following the DL86 documentation (sending 0x60 as data): S 0000 00001 00001 1100000 E No response by the BM.
- Sending a command from my own findings when testing the MCL Sensor: S 0000 00001 01100 000 E Success - BM is increasing the Volume by 2.
Yes, it is a bit confusing. There are full and short messages. The full messages are described in the DL86 pdf. So far I could only read them but sending didn't do anything. Sniffing data between a 1611 converter and a BC9500 I found out that there are also short messages transmitted that are very similar to the Beo4 IR codes. The 1611 sends out such a command e.g. for activating the radio source or for next/prev commands. Those short messages just contain the "to address" and the command. The command can be any Beo4 command.Thank you very much for the explanation of the "short" messages!! I noticed the same behavior for "long" messages while testing with the MCL Sensor. I could imagine the "long" messages are the response from the BM, providing the status after receiving the "short" command? However that may be... With the understanding of the "short" messages, I did what you suggested:The other one uses lirc's mode2 tool to decode incoming DL86 messages on-to-fly and will print out hex values.Hi all, I'm new to B&O, and I've been working a bit on the side trying to do much of the same thing, but with detailed status. In essence, I'm looking to create an IoT MCP, so I can control - and equally important to me -query system status on my BM7000. My first thought was to graft an Arduino into an old MCP that I purchased. Button-press implementation appeared straightforward, but it seemed a bit daunting to decipher the incoming IR without a suitable logic probe, so I largely went the route as described in this thread - monitoring the DL80 and DL86 channels for messages, and mapping them to a status matrix. It's been a bit of a learning curve on the DL80 ports, but now that I have that work largely complete, I've turned my attention to DL86 piece, broadcast on the Aux channel. As described above, there are at least two types of DL86 command structures - one for things like incoming short Beo4 commands which don't monitor return status, and another is the longer outbound messages containing status. What I'm seeing on the outbound packets differs somewhat from what I'd expected, as shown below. I'm using the DL86 packet example as shown in the 9-page DL86 manual to count the bits as 4-bit localAddr, 5-bit toAddr, 5-bit fromAddr, rest is data. Source Data Radio: DL86.Local:0011 toAddr:10111 fromAddr:10000 Tape: DL86.Local:0011 toAddr:10111 fromAddr:10100 Phono: DL86.Local:0011 toAddr:10111 fromAddr:10100 (same as tape?) Tape-2: DL86.Local:0011 toAddr:10111 fromAddr:10101 CD: DL86.Local:0011 toAddr:10111 fromAddr:10100 (Same as Tape & Phono) So unless I'm counting bits wrong, it looks like the source-status-info must be in the data field, in order for it to appear on a Penta display (for example). Before I go too far down the rabbit hole and, I'd like to ask if anyone already has deciphered outbound DL86 status data and has posted it somewhere. If not, I'll do my best with decoding it and post results. Any guidance would be a time saver, and greatly appreciated. I'll of course post what I come up with on GitHub as my contribution to the solution. Thanks in advance!Please Log In to Reply
You must be logged in as a BeoWorld member to post replies to forum threads.
or
Join BeoWorld
Register to access the forums, reference material, and exclusive member benefits — including our monthly prize draw.
Become a MemberDecember 2026 Prize Draw
Gold Members OnlyAs a Gold member you're automatically entered into our exclusive prize draw — your chance to win iconic Bang & Olufsen products. A unique benefit of BeoWorld Gold membership, every draw brings a new opportunity to win something special.
1st Prize
2nd Prize
3rd Prize