Controlling a Beomaster 6500 via the TV/Aux Datalink’86 pin

[Gspaltenhorn]

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”)

As a code basis I`m using this GitHub Project.

I actually don´t need the additional MCL Sensor in my day to day use. I´m using it to identify commands from the Datalink protocol. I know about the Datalink manual and with this I´m already able to send and receive signals via the Arduino.

But unfortunately the commands only startup the BM in muted state and I can´t get it to unmute (See my post here). I´m aware this is expected behavior, but I was wondering if there really is no command for unmuting speaker 1/Powerlink.

I also tried out the changes suggested by B3OHACK3R:

B3OHACK3R wrote:

Gspaltenhorn wrote:

But unfortunately the commands only startup the BM in muted state and I can´t get it to unmute

Hi! Maybe I can jump in here. Was busy with ML lately and haven’t had a deep dive in the DL’86 protocol yet. What I would try first is just sending it a virtual volume or mute key stroke. So similar to this 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 he described by himself earlier today.

This leaves me with the following question: Was it not intended to connect a B&O TV to the TV/Aux port of the BM and play the sound over the connected speakers? If so, it should have sent matching Datalink commands (like Madskp suggested here). Or is it perhaps a question of BM settings after all (like I asumed here)?

To be honest, I probably don’t have a deep enough understanding when it comes to the structure/composition of Datalink commands at the moment.

I would therefore be very happy to receive any hints, tips and tricks or any documentation to be able to learn more about Datalink and maybe solve the puzzle!

Thank you all in advance!

[B3OHACK3R]

Gspaltenhorn wrote:

Was it not intended to connect a B&O TV to the TV/Aux port of the BM and play the sound over the connected speakers?

It was intended indeed. In an option 0 (TV) / 2 (music system) setup. In that case the TV would not receive any IR commands but only the music system (where also the speakers are connected). So the music system would power up by it’s regular IR commands and then forward everything TV related over the DL / aux port to the TV. So this setup cannot be used for “spying” on a special command.

What pilatomic does in the other thread is simulating a tape deck or a CD player. They have those separate connectors and are speaking the older DL protocol. So when pressing the play button on the CD player it sends a command to the master device which then switches on. Without muting its output. The downside is that using this port you only have limited functionality available.

I think the MCL and the TV/AUX connector do carry the same data signal. So when the enable signal comes in through the MCL port it makes perfectly sense to not enable the local output. I’m just curious if this can somehow be overruled with a special command.

Easiest fix would probably be just simulating an activation from the CD player or the tape deck using the DL80 port. Once the system started (unmuted) just use the DL86 protocol on the other connector to switch to the actual source you want.

[Gspaltenhorn]

B3OHACK3R wrote:

It was intended indeed. In an option 0 (TV) / 2 (music system) setup. In that case the TV would not receive any IR commands but only the music system (where also the speakers are connected). So the music system would power up by it’s regular IR commands and then forward everything TV related over the DL / aux port to the TV. So this setup cannot be used for “spying” on a special command.
[…]
I think the MCL and the TV/AUX connector do carry the same data signal. So when the enable signal comes in through the MCL port it makes perfectly sense to not enable the local output. I’m just curious if this can somehow be overruled with a special command.

Thanks for clearing things up! I also checked the BM 6500 schematics again and like you mentioned the Datalink pin of the TV/AUX port is directly connected to the MCL and Powerlink Datalink Pins. I can imagine that B&O has left the door open to control or mute the system via a future iteration of innovative speakers like the Penta series. So maybe there is this special command. But that’s crystal ball gazing… 😀

B3OHACK3R wrote:

What pilatomic does in the other thread is simulating a tape deck or a CD player. They have those separate connectors and are speaking the older DL protocol. So when pressing the play button on the CD player it sends a command to the master device which then switches on. Without muting its output. The downside is that using this port you only have limited functionality available.
[…]
Easiest fix would probably be just simulating an activation from the CD player or the tape deck using the DL80 port. Once the system started (unmuted) just use the DL86 protocol on the other connector to switch to the actual source you want.

I get how pilatomic is achieving control and I also understand your solution approach. I guess for my personal project this would be just fine, as I could connect another pin of the Arduino to a DL80 port, just for sending the “missing” commands. Many thanks for the inspiration!
Having your “MasterDataTool” project and the use of DL86 in mind , this would unfortunately compromise the elegant plug-and-play solution…

[B3OHACK3R]

Gspaltenhorn wrote:

I can imagine that B&O has left the door open to control or mute the system

As the messages are short enough one could set up an automated test and just iterate through every possible command.

Gspaltenhorn wrote:

Having your “MasterDataTool” project and the use of DL86 in mind , this would unfortunately compromise the elegant plug-and-play solution

Not that bad after all. The good thing is that the DL80 port ignores DL86 and vice versa. So in theory it should be possible joining them together and sending DL80 and DL86 on the same wire. Then it’s just about a simple cable splitter. Still have to properly test that.

[Gspaltenhorn]

I also want to comment on your previous post from another thread:

B3OHACK3R wrote:

What I would try first is just sending it a virtual volume or mute key stroke.

So similar to this
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:

• Start
• Header
  • Format [4 Bits]
  • Address (to) [5 Bits]
  • Address (from) [5 Bits]
• Data [“… may be commands or ASCII codes”]
• Stop

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:

1. Following your suggestion: S 0000 00001 00001 100000 E
   No response by the BM.
2. Following the DL86 documentation (sending 0x60 as data): S 0000 00001 00001 1100000 E
   No response by the BM.
3. 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.

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 ?

[B3OHACK3R]

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. https://github.com/christianlykke9/Beomote/blob/master/Commands.h

So sending a 0 0000 0001 0110 0000 is a volume up key to the radio source. Leading 0 plus 0x01 (radio) plus 0x60 (vol-up). This is actually what I meant with replacing the 0x09 with the 0x60 from the linked file.

[Gspaltenhorn]

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:

B3OHACK3R wrote:

As the messages are short enough one could set up an automated test and just iterate through every possible command.

And success! I found the “secret” commands to unmute/mute the Powerlink speaker:

• unmute – 0x1C
• mute – 0x1D

Prerequisite is an already running Beomaster.

[Madskp]

Gspaltenhorn wrote:

And success! I found the “secret” commands to unmute/mute the Powerlink speaker: unmute – 0x1C mute – 0x1D Prerequisite is an already running Beomaster.

Just to understand this correctly. You can then activate the Beomaster in a muted state via the datalink’86, and then afterwards unmute it also with datalink’86. Is that correct?

Location: Denmark

[B3OHACK3R]

Gspaltenhorn wrote:

And success! I found the “secret” commands to unmute/mute the Powerlink speaker: unmute – 0x1C mute – 0x1D

Really cool!! Thanks a lot for sharing that! Could reproduce it on a BC9500. Works!

Madskp wrote:

You can then activate the Beomaster in a muted state via the datalink’86, and then afterwards unmute it also with datalink’86. Is that correct?

Yes, all through the AAL / AUX connector. So that brings some really nice remote control capabilities. 🙂

BTW some time ago I made two little helper python tools for Linux & DL. As bit-banging from userspace is something you should avoid you can instead use LIRC in raw mode for that.

This tool converts a DL86 command to a lirc.conf snippet for raw mode (there is also a full lirc.conf example file).
For example python3 dl-lirc-gen.py 011c will generate the unmute command.

https://gitlab.com/masterdatatool/software/dl-tools/-/blob/main/dl-lirc-conf/dl-lirc-gen.py

The other one uses lirc’s mode2 tool to decode incoming DL86 messages on-to-fly and will print out hex values.

https://gitlab.com/masterdatatool/software/dl-tools/-/blob/main/dl-receive/dl-receive.py

Still pretty much work-in-progress but they are functional so far. I made them for the MasterDataTool project but can be used stand-alone of course.  Just don’t forget the level shifter.

[TK]

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!

 

[TK]

BTW the DL80 serial stream Im working on is printed as below (Work in progress – not everything is decoded properly).  Id like to eventually have something similar for the DL86 channel, so I can parse the output stream from a real-time monitor.

Tape.Status.CassetteInfo->:Side-Top:Dolby-B:Side-Top
Tape.Status.Playing
Tape.DataErr?
Tape.Status.TrackNumber->8
Tape.Status.CassetteInfo->:Side-Top:Dolby-C:Side-Top
Tape.FF->>
Tape.Status.CassetteInfo->:Side-Top:Dolby-C:Side-Top
Tape.Status.Adv->
Tape.Status.TrackNumber->9
Tape.Stop
Tape.Status.CassetteInfo->:Dolby-C
Tape.AutoRev?
Tape.Status.Stopped
Tape.Status.TrackNumber->9
Sys.ShowStatus
Tape.Status.CassetteInfo->Tape.AutoRev?:Dolby-C:Tape.AutoRev?
Tape.ShowStatus
Tape.Status.Stopped
Tape.Status.TrackNumber->9
Tape.Status.SoundLevel->00
Tape.Status.SoundLevel->00

Tape.Display-Select
Tape.Status.CassetteInfo->Tape.AutoRev?
Tape.ShowStatus
Tape.Status.Stopped
Sys.ShowStatus
Tape.Status.CassetteInfo->Tape.AutoRev?:Dolby-C:Tape.AutoRev?
Tape.ShowStatus
Tape.Status.Stopped
Tape.Status.TrackNumber->9
Tape.Status.Counter->08080

 

[TK]

Well, since I’m here talking to myself, I’ll post an update for my own edification.  After attaching a cheap logic analyzer to the DL80 pins, I realized that I was getting some of the right answers by mistake.  There’s a series of timing issues when using the toresbe method which caused transcription errors in multi-byte status commands, but you wouldn’t know it, because it was always incorrectly transcribing in the same predictable way, about 95% of the time.  The other 5% I was not understanding the data.  After some fiddling and looking at logic traces, it looks like some multibyte data with respect to numbers is transmitted as shown below.  I’m in the process of updating the code to work based on my current understanding, and will post it at some point when I’m satisfied for the two or three of you globally who might care about such things.

Multi-byte numbers: ‘0 + 4-bit-number + 111’ with the leading 0 being the start byte

That’s as far as I’ve gotten for the time I’ve had this afternoon to work on it. I’ll check to see if ‘sound level’ display is sent the same way tomorrow.

As an example, a request to For showing Tape Status from the MCP would be (using my nomenclature):

DL80-1.EF Sys.ShowStatus  (Active Low: 00010000 )

DL80-1.F8 Tape.Status.CassetteInfo+  (Active Low: 00000111 )

DL80-1.A0 :Side-Top  (Active Low: 01011111 )

DL80-1.D8 :Dolby-C  (Active Low: 00100111 )

DL80-1.A0 :Side-Top  (Active Low: 01011111 )

DL80-1.BE Tape.ShowStatus  (Active Low: 01000001 )

DL80-1.B7 Tape.Status.Playing  (Active Low: 01001000 )

DL80-1.F4 Tape.Status.TrackNumber+  (Active Low: 00001011 )

DL80-1.F8 UNKN  (Active Low: 00000111 )

DL80-1.F8 UNKN  (Active Low: 00000111 )

DL80-1.F8 UNKN (Active Low: 00000111 )

DL80-1.F8 UNKN (Active Low: 00000111 )

DL80-1.D0 "10"  (Active Low: 00101111 )

DL80-1.FA Tape.Status.Counter+  (Active Low: 00000101 )

DL80-1.80 "0"  (Active Low: 01111111 )

DL80-1.B8 "7"  (Active Low: 01000111 )

DL80-1.90 "2"  (Active Low: 01101111 )

DL80-1.B8 "7"  (Active Low: 01000111 )

DL80-1.80 "0"  (Active Low: 01111111 )

[Madskp]

Great that you are sharring your findings here although I think a lot of the members here including myself does not understand the “language” of datalink (or programming code for that matter).

I do however encourage this kind of works as it can sometimes bring great things to the community like the Beotooth 5500 bluetooth streaming device with datalink control that was developed by the user Pilatomic https://forum.beoworld.org/forums/topic/beotooth-5500-a-datalink-bluetooth-receiver/

And speaking of that where many other threads about understanding datalink has been about the datalink 86 protocol, Pilatomic is for sure one member here who has been working with the datalink 80 protocol that you are also looking at, so it might be worth to try and contract him.

One curious question to the above. More of the codes you have listed has been named UNKN. Is that because you see some activity on the datalink bus without issuing a command to the system?

Location: Denmark

[TK]

Yes, I have one of his BeoTooth devices, and it’s very well made.

I’ll explain it this way: The beocord is able to transmit lots of information about it’s current state over datalink: what track it’s on, what side of the tape it’s playing, how many seconds it’s been running, how loud the recording is, etc. It’s a very “chatty” component.  In the example above, it’s transmitting CassetteInfo, TrackNumber, and Counter over Datalink for the Beomaster to display. Most Datalink 80 messages are 1 byte in length (eight 1’s and/or 0’s in sequence, in specific combinations) , but a few status messages are longer, because more information needs to be passed then can be done in a single byte.  Fore example, when the Beomaster sees the incoming. code for “TrackNumber” it knows that the next 5 bytes it receives will include which track it should display on the remote. HOWEVER! of the next five bytes it is expecting, only the last byte received is ever used (AFAIK) for this particular status command, and of that last byte, only a portion of it is used. So the first four bytes of the message could have been jibberish, but the original writers of Datalink 80 apparently decided to send “00000111”, which is translated as either “UNKN” or “14+” on your B&O display. But in practice it really doesn’t matter what is sent – the first 4 bytes of data is not used for anything, AFAIK.  They could have chosen to send something else if they’d wanted to.

The ‘UNKN’ label is basically the English label Ive assigned for the sequence of bits ‘1111’, or the Hex letter ‘F’.  which also represents the number 15 in computer-speak.  It’s the largest number that can be represented using 4 bits.  This is the primary reason why most older B&O systems only count tracks up to 14. On any higher numbered track, it will show as “14+” which is signifies “Track 15 or higher”, and also “Unknown Track Number”.  AKA “I can’t count any higher than that, because I’ve run out of digits”.

IF the last byte is also sent as “UNKN” (i.e five “UNKN” in a row), then the Beomaster knows that the beocord either does not know what track it’s. on, or the current track number is 15 or greater. The Beomaster  subsequently relays that information to a 2-way remote IR or the console panel, so the appropriate number is lit up. In the example above, the last number translates to a “10”, so solely the information in his last byte will cause the “10” to flash on an MCP panel.

Ironically,  the system already has a means to describe any track number between “0” and. “99999” easily, using the tape counter to transmit current track info.  In the example above, the Counter returns “07270”, which will display as “0727” on the MCP (I think- it might display “7270”, I’ll check later). Pilatomic has implemented this feature using the Status counter in his excellent adaptation.

[Madskp]

TK wrote:

Yes, I have one of his BeoTooth devices, and it’s very well made.

I’ll explain it this way: The beocord is able to transmit lots of information about it’s current state over datalink: what track it’s on, what side of the tape it’s playing, how many seconds it’s been running, how loud the recording is, etc. It’s a very “chatty” component.  In the example above, it’s transmitting CassetteInfo, TrackNumber, and Counter over Datalink for the Beomaster to display. Most Datalink 80 messages are 1 byte in length (eight 1’s and/or 0’s in sequence, in specific combinations) , but a few status messages are longer, because more information needs to be passed then can be done in a single byte.  Fore example, when the Beomaster sees the incoming. code for “TrackNumber” it knows that the next 5 bytes it receives will include which track it should display on the remote. HOWEVER! of the next five bytes it is expecting, only the last byte received is ever used (AFAIK) for this particular status command, and of that last byte, only a portion of it is used. So the first four bytes of the message could have been jibberish, but the original writers of Datalink 80 apparently decided to send “00000111”, which is translated as either “UNKN” or “14+” on your B&O display. But in practice it really doesn’t matter what is sent – the first 4 bytes of data is not used for anything, AFAIK.  They could have chosen to send something else if they’d wanted to.

The ‘UNKN’ label is basically the English label Ive assigned for the sequence of bits ‘1111’, or the Hex letter ‘F’.  which also represents the number 15 in computer-speak.  It’s the largest number that can be represented using 4 bits.  This is the primary reason why most older B&O systems only count tracks up to 14. On any higher numbered track, it will show as “14+” which is signifies “Track 15 or higher”, and also “Unknown Track Number”.  AKA “I can’t count any higher than that, because I’ve run out of digits”.

IF the last byte is also sent as “UNKN” (i.e five “UNKN” in a row), then the Beomaster knows that the beocord either does not know what track it’s. on, or the current track number is 15 or greater. The Beomaster  subsequently relays that information to a 2-way remote IR or the console panel, so the appropriate number is lit up. In the example above, the last number translates to a “10”, so solely the information in his last byte will cause the “10” to flash on an MCP panel.

Ironically,  the system already has a means to describe any track number between “0” and. “99999” easily, using the tape counter to transmit current track info.  In the example above, the Counter returns “07270”, which will display as “0727” on the MCP (I think- it might display “7270”, I’ll check later). Pilatomic has implemented this feature using the Status counter in his excellent adaptation.

Thanks for the explanation although I do not understand all of it I can see the logic in some it. Also interesting to see that there is some kind of reason for showing only 14+ tracks on many B&O products 🙂

Location: Denmark

[TK]

LOL it was a bit long winded a post. One takeaway to note is that with a little effort, it appears to be entirely possible to make a cheap translation dongle which allows any vintage B&O component to interface with any other vintage B&O component (something one or two people have already worked on).   So one could,  for example, easily make a dongle which would allow a Beomaster 5000 or BM8000 to work with more modern datalink protocols that the 5500-7000 know how to translate. The only limits are the capabilities of the least-capable component.

[Author]

Posts