[B3OHACK3R]

Madskp wrote:

Although I have a hard time figuring out how you interpetered all that data from my screenshots ?

If you know how the data is transmitted you can easily find out just by looking at it.
Data is determined by the spaces (signal at 5V) between pulses (signal at 0V).

There are a few different space timings possible:
3.125 ms = logic 0
6.250 ms = “repeat” – same bit value as before
9.375 ms = logic 1
12.500 ms = start bit
15.625 ms = stop bit

The three pulses in the beginning can be ignored. Then there is the long start bit and afterwards you can start interpreting the data.

[B3OHACK3R]

Madskp wrote:

Would it be helpfull if I export the data to some binary files and upload them in a post?

I have my doubts that the saleae software has a built-in decoder for such pulse/space length encoded protocols. It is not really commonly used.

[B3OHACK3R]

Ah, forget the last 1 bit on each message. It’s the stop bit (should be a little longer than a normal 1 bit)

[B3OHACK3R]

Nice and now we know what’s the difference between the BW1 and a normal PL output.

I see following in your BW1 capture (second screenshot equals the previous message):
0011 0001 1110 0111 1111 0000 0000 1001
0011 0011 0100 1100 1011 0000 0000 0101 0000 0000 0001

which equals those hex values:
31 E7 F0 09
33 4C B0 05 00 1

 

The Active kit sends the following:
0011 1011 1100 0000 0100 1000 0110 0100 0001 1000 1
0011 1011 1101 0001 0100 0000 0000 0000 0000 0000 1

which equals those hex values:
77 80 90 C8 31
77 A2 80 00 01

 

At least that “33 4C” data block I think I have seen before on AAL/MCL communication.

[B3OHACK3R]

Created a little documentation website over here. Still in early stage but already covers the most important things. https://mdt.polyvection.com/
Also there here a few software examples. https://gitlab.com/masterdatatool/software

 

[B3OHACK3R]

pilatomic wrote:

Exactly ! Although I have the bit values inverted in my notes, since the bus is pulled to 5V through a resistor, and actively pulled low by the end devices, so I use ‘1’ when the bus level is 0V.

Interesting. It totally makes sense by just looking at it.
Nevertheless if you are coming from DL86 where data is determined by the pulse length its a bit different and still makes sense somehow.

Your capture is an ATAPE activation command. In the MCL world (and ML as well) that is the 0x91 command. 1001 0001 in binary.
Similar commands are CD (0x92) and PHONO (0x93). So the first four bits are likely some kind of a category (audio in that case) and the last four are the actual source.
So if you just look at the last 4 bits and take the DL86 pulse length decoding it matches the DL80 ones just fine.

So going back to your example again. With that pulse length decoding strategy you’ll have 3x short pulse and 1x long pulse. Resulting in 0001.

For PHONO activation I have seen the one below and interpreted it as 0011 which then would match the last 4 bits of DL86 for that source (0x93 = 1001 0011). My conclusion from this was that DL80 does not send a “space” between “1”s like DL86 does. It just ties them together resulting in that long low period for the two sequential “1” bits.

Of course I was really biased with the DL86 stuff and you weren’t. So I could be completely wrong.

Yes, building all that must have been “interesting” back in those days.

[B3OHACK3R]

pilatomic wrote:

B3OHACK3R : Don’t reason with the pulse length for the DL-80, it’s simply made of 8 bits packets with 3.125ms bit duration.

Ah, interesting. You probably have more insight into the DL80 stuff than I currently have.
How are you counting those 8 bits?
So in your capture from above – are you seeing two bytes each being 01010100?
From my experience with DL86 (and IR as well) there a logic 0 is a 3.125 ms pulse. Logic 1 is a 9.375 ms one while “same bit” is a 6.250 ms pulse.

[B3OHACK3R]

Nice, that’s looking good to me. You captured a DL80 message. They are pretty short and I think there is no public documentation about it so far. The shorter pulse is a logic 0, the longer one a logic 1. That’s all you need I guess. The two longer pulses right in the beginning might be some kind of message header or wake up mechanism.
FYI – DL86 also implements a third value “same bit as before”. This pulse then is a bit longer than a logic 0 but shorter than a logic 1. I think DL80 doesn’t have that.

How I understood it, for a source activation DL80 will send out 2x 4 bits with the same value. For PHONO I have seen 0011 + 0011 and what you are seeing is likely 0001 + 0001 for A.TAPE. I think that does only partly correlate with DL86 / MCL. There e.g. 0x91 is the A.TAPE source which is 1001 0001 in binary. So the last 4 bits are still matching. Same is true for the PHONO source.
So for CD activation on DL80 I would expect seeing 0010 + 0010.

[B3OHACK3R]

Still work-in-progress but:

https://www.youtube.com/watch?v=t-M0dlEqlTk

[B3OHACK3R]

B3OHACK3R wrote:

Remote commands / key strokes you can read out via ML

Just implemented this with the Masterlink adapter.

So when using MDT in that mode it can receive all remote key strokes via ML – otherwise you are limited to “light” and “control” commands. Practical example: LG OLED connected to BSys3 via S/PDIF and you want to control everything via Beo4. The BS3 “TV” source is set up for BeoMaster 5 control. MDT is set up for emulating a BeoMaster5 and translating all ML input to LG IP commands. You can simply press TV on the Beo4 – the LG switches on and you can control all functions of it via Beo4.

In that setup also a BC2 is connected to the ML. At the same time MDT will act as a “source center” (n.radio / n.music server) in parallel. You can send an AirPlay / Bluetooth / Spotify steam to it from your phone. The BC2 is automatically switches on and showing the song metadata. Sound is coming through speakers that are connected to the BS3. You can use the Beo4 for controlling playback. Stop the stream from your phone and everything turns off automatically.

I think that ticks pretty much ticks every box you’d expect from a modern system.

[B3OHACK3R]

Guy wrote:

Quick question: If the device is set up as an audiomaster and connected to an ML equipped B&O TV in V.OPT 2, will the TV show audio metadata if the screen is unmuted/turned on?

No, I don’t think so.
I mean, you could connect it via HDMI as well and use the PC source for that. Like it was done with BeoMedia 1 / BeoMaster 5. Remote commands / key strokes you can read out via ML – then it’s just about a matching UI.

[B3OHACK3R]

XavierItzmann wrote:

@Madskp: from my Linkplayer experience: • BS3000 displayed, on activation, that the source was either N.RADIO or N.MUSIC. It then displayed the song and the author via horizontally scrolling displayed; or, the radio station and the song. • BL3500 only displayed N.MUSIC or N.RADIO; no additional data was displayed. The scrolling abilities of BS3000 avoided the cut-off titles shown on the BeoCenter 2 video included above.

Great, thanks for sharing that info! That’ also what I’m seeing here. I thought the laster versions of BL3500 might have introduced metadata – but probably not.

BTW the version of my metadata code I was using for the video would limit the string to 15 letters before sending it to ML. Still have to remove that.
I think BC2 also supports scrolling. At least I have seen that while experimenting.

[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.

[B3OHACK3R]

pestria wrote:

From a practical point of view, how do you connect into the ML network – I assume instead of ML plug you wire into a connector box?

I made this little ML RJ45 adapter you can see on this picture here. You can directly plug it directly into an ML device and then use a standard RJ45 cable for connecting it to the interface board. If you have a ML system with several linkrooms connected then either solder an ethernet cable onto the bus at a convenient location or if you are lucky to have one of those old ML distribution boxes just plug in the little adapter from the picture above. Alternatively you can also wire everything with RJ45 – I made a passive RJ45 hub for joining 6 ML devices.

pestria wrote:

In terms of signal input I’d ideally use (an old unused) iMac – would that work?

The title of this thread is not exactly matching anymore. While it still relies on a USB connection for the ML communication, it was later made compatible with a Raspberry Pi single board computer. You just attach the ML interface board to it. You can then run any software you’d like. There are some very well working community implementations for AirPlay, Spotify Connect, etc. available.

pestria wrote:

I have a Beosound 9000 version 1 master, which doesn’t support N.Music or N.Radio – is there any other way that these type of services can be accessed off the music source (ie iMAc in this case)?

For those units the theory is setting it to Option 2 (TV speakers connected to BS9000) and let the ML interface board act as a video master. So you can then use TV/SAT/DTV/etc. for streaming through the BS9000. It should work but haven’t tested it yet.

pestria wrote:

If all the above works, I’d order one tomorrow!

Not yet available! Should have some stock in around 2 weeks. Also please be prepared to fiddle a bit with the software. I’m using it daily and it works really reliable but the initial setup requires some very basic software “tinkering” skills. Already wrote an nice documentation for it but it’s not the typical plug-n-play product.

[B3OHACK3R]

pestria wrote:

Can this device serve as an audio master in a ML circuit?

Yes, it can. Audio master, video master, masterlink gateway, source center or slave device. So pretty much anything.

pestria wrote:

I ask as it seems a far more elegant solution that an Airport Express plugged into the Aux-In socket of an Audio Master (eg Beosound 9000).

Exactly. It feels a lot more mature than a simple streamer connected to the aux port.

A BS9000 with a recent enough firmware can handle N.Music / N.Radio sources. When activated from the BS9000 it will request those sources on the ML bus (“source center” application). The source center device will receive all commands from the BS9000 and can also control the BS9000. Like switching it on or off once your started/stopped the audio stream and also provide metadata which is then shown on the BS9000 display.

[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.

[B3OHACK3R]

Hi,

there aren’t many possibilities for the music system to find out if speakers are plugged in out not. I haven’t tested it but your guess doesn’t sound wrong. Put a tiny load on the ON/OFF signal pin and it will probably work. Something like 100k to ground might be worth a try.

[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.

[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.

[B3OHACK3R]

Gspaltenhorn wrote:

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

B3OHACK3R wrote:

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.

Did a quick test run today. I wasn’t able to get it out of the initial muted state as well when started through DL’86 commands. By commands on the Audio Aux Link connector I mean.

As soon as you touch a key on the remote or on the device directly it will unmute.

Sending virtual volume keys works and you can see the volume on the device is changing. Nevertheless it stays muted. The 0x0d mute command is ignored and does nothing. Maybe there is some kind of hidden command somewhere to enable the output but I couldn’t find that yet.

So if you want to stay with the cabled version maybe just try shorting the DL80 and the DL86 pins together. Then you can send a DL80 “switch on” command (which doesn’t mute the unit by default) and then switch over to DL86 for having the convenience of a more advanced protocol. Looking like sending DL86 commands into one of the DL80 connectors does trigger nothing. So any additional unit connected there might just happily ignore it. At least worth a try.

[Author]

Posts