BeoBabble – a B&O multi-protocol interpreter

[TK]

I’ve spent (wasted, perhaps?) much of my free time over the past few months writing an interpreter for some of the old B&O protocols, mostly for my own education.  The software needs a few more weeks of vetting some of the crap code for clarity and maintainability (it’ll likely still be crap even when I’m done) before I upload it to GitHub. Included in this version 1.0 are relatively complete protocol syntaxes for Datalink ’86, Datalink ’80, Master Control Link ’82, and Datalink ’78.  Most of the translations are working, with plenty of memory leaks and syntax discrepancies left to chase down.

BeoBabble also has its own syntax which allows anyone to send commands and data via the Serial port, and direct it to the appropriate Datalink channel.  Everything is still very-much a work in progress, and I expect some of the rougher edges to be smoothed out as I start to look into expanding the system capabilities. In the future I hope to have something net-enabled, but for now I’m just using a serial interface.

Of interest to BM5000 enthusiasts is the inclusion of the ‘BM5000/Other’ version of MCL82.  By enabling this protocol, aspiring programmers can begin to integrate their systems with some components that use later protocols by adding a DL86 interface to their home systems.  This for example also opens up the possibility to use a Beo4 remote to control the BM5000 with just an Arduino.  There is some more coding and an IR interface that needs to be finished prior to it working seamlessly.  Hopefully there will be a few folks who find that appealing.

I’m including some screen shots below to show a bit about how the system works, as well as a make-shift user guide for the few of you who may be interested to learn more.

BeoBabble v1.0 User Guide

 

[TK]

Finally a bit of progress.  I’ve added some fun DL86 MCP updating commands, and am working on a rudimentary macro system, in order to allow BeoBabble to auto-trigger macros based on stream inputs and user request.  Here are links to two examples – the first manipulates the level meter, and the second makes a crude attempt at spelling “BeoBabble” on the 5-segment display – more like “B3O-BABBL”.  I was a bit lucky to find the “L” as a supported letter, so I’ll take that as a good omen.

User Guide is updated with the latest capabilities as I code them, and I’ll hope to have a releasable version soon.

 

 

[cklit]

Really cool, looking forward to see how far you take this!

Thanks for being so thorough, documenting everything and sharing. 🫡

[pl212]

Wow, this is really great! I’d be glad to test or assist in any way I can after it’s released.

One particular use case I’m curious about would be a “smart” interposer device, for units such as the BeoCenter 2300 with only one AUX port. In theory this could intercept a start signal from either a BeoGram or a BeoTooth, and allow just that device to switch the 2300 on to that source. (A kind of automated version of the old four-port AUX Expander.)

Is there any equipment you would like to see it tested on? I have a MCP6500 and BL7000 for example…

[Madskp]

pl212 wrote:

One particular use case I’m curious about would be a “smart” interposer device, for units such as the BeoCenter 2300 with only one AUX port. In theory this could intercept a start signal from either a BeoGram or a BeoTooth, and allow just that device to switch the 2300 on to that source. (A kind of automated version of the old four-port AUX Expander.)

I was wondering of something of the same kind for BS Ouverture and BC9300 in this thread https://forum.beoworld.org/forums/topic/beosound-ouverture-2-external-sources-y-cable/ as they can detect/send both PHONO and TAPE2 commands for the same AUX connection. The conclusion in that topic was that some switching circiut between the 2 audio lines might be needed depending on which source is detected, so that would have to be part of such solution.

 

Location: Denmark

[silou]

Nice work. Very interesting, I look forward to seeing more! Well done!👍

[TK]

Thx pl212 for your offer, I’ll gladly accept.  I’ve been slow to release the software for GA because I wanted to make sure that I got the syntax mostly usable, and I’m also suffering a bit from feature creep.  More on that in a following post.

This following solution is not really a good final solution, but I’ll mention it anyways as a thought exercise: at a minimum what would work with little effort is if you had 2 sources that you connected via a Y-cable to BeoBabble, and connected the BB DL86 output to an ML/MCL converter, which then connected to the BC2300. On a start signal from either source, the BB can be easily modified using a macro to send a DL86 “System-on, switch to Aux” to the BC23000 through the ML/MCL when BB detects a “Playing” Status from one or the other source, and also send a “Pause” signal to the other source, much in the same way a BeoMaster does when you switch sources.  So that part would work already, but I think it would be a bit of a kludge, and likely introduce some unwanted noise interference.  There would also be some wiring needed to bridge the audio pins, which I currently have not spent much time on.

So the BB Setup would look like this:

2 BB Macros: On DL80 Trigger “Beogram.Playing”, Send DL80 “BeoTooth.Pause”; Send DL86 “BC23000.Src=>Aux”;  On DL80 Trigger “BeoTooth.Playing”, Send DL80 “Beogram.Pause”; Send DL86 “BC23000.Src=>Aux” (Which I assume would power the BC2300 on as most B&O conventions allow for)  In theory (THEORY!) that would kinda-sorta work out of the box with just a couple of Y cables, but AFAIK it’s not really the best idea to have two sources sharing a common output channel without having a proper MUX that can isolate each source’s audio signal from the other, and switch cleanly between them.  What we are doing in this example is sharing an audio L+R, and shutting one system off if the other starts playing – probably not recommended.

Getting into the weeds here, so indulge me and feel free to ask questions or offer a clarification if I’m off-base: with respect to the BC2300, I think that it speaks ML, and not MCL2, which would mean for the moment that there would be a bit more hardware to acquire in the form of an ML/MCL converter just to get the communications working (I’ll get to ML support at some point in the future, but probably it will be a while), and then also an additional piece of hardware in the form of an Audio MUX that has, say, 2-4 input channels and an output channel for the BC2300 Aux connection, and the channel selection would have to be settable via a logic signal that BeoBabble can send out.

So, what am I saying? I think it <could> work out of the box, but I don’t know that the result would be great without a proper audio MUX. It’s clearly worth exploring what it would take to put a MUX like you would need on-board, but my experience is not in audio engineering, so my hope would be that someone resourceful could help design one, or offer another hardware audio MUX solution to with an API/Interface.

Keep those product extension ideas coming!

 

[TK]

Over the past week, I started stress testing the design to see how malleable it was to feature expansion – and it fared pretty poorly.  So I decided to add a few features that I knew I would need in order to make the system work for me the way I wanted it to, and see what that did to my design.  I purchased a $30 Ethernet add-on to the Mega, and added a rudimentary telnet server to BB.  This forced me to retrofit a bunch of code, because I had never considered what it would mean to read and write I/O to and from several clients.   My current solution is incomplete and sloppy, but it did allow me to prototype something else: an iOS console that connects via TCP/IP to BB and can send and receive Datalink in parallel with the Serial port.

From there, it was a very short hop to writing an iOS MCP-Style remote control.  In reality, this is a real stretch for me from a programming standpoint.  I know next to nothing about how Swift works, but thanks to Claude.ai, I just got it working sending commands tonight by pressing MCP buttons.  The tougher part is next- translating all the MCP update status commands into LED readouts on the status screen.  This has yet to be coded in Swift, but I’m elated to know that it’s actually going to work as I imagined.  Prototyping screenshots attached.  When I get the LEDs programmed so that it behaves like a real honest-to-goodness MCP, I’ll upload a video.

Shout out to all you BM5000 users out there.  There’s an MCP in there for you too!

 

Attachments:

You must be logged in to view attached files.

[Madskp]

TK wrote:

: with respect to the BC2300, I think that it speaks ML, and not MCL2, which would mean for the moment that there would be a bit more hardware to acquire in the form of an ML/MCL converter just to get the communications working (I’ll get to ML support at some point in the future, but probably it will be a while)

Actually the BC2300 does not have ML but instead both DL80 and DL86 in the same AUX connector on pin 7 and pin 6 respectivly

But as mentioned for BS Ouverture and BC9300 I guess that the DL80 dataline responds to both the TAPE2 and the PHONO command

Location: Denmark

[Madskp]

Oh an btw if it was from ML I would suspect that a Beolink Converter type 1611/1612 could be used just as well since that tranlates between ML and DL86

Location: Denmark

[TK]

Madskp, thanks for the clarification – I’ve read your thread, and it looks like all that would be required to make this work is to place a BB to monitor the DL80 connection (and possibly the DL86 connection, as a command-sending interface to the 2300). It would be great to test out my proposed kludge on the workbench, but the 2300 I have is code locked, and waiting for me to write a brute-force algorithm to free it from its hibernation.  What I’m not entirely sure of is the logic and safety of having two sources share a single audio channel without some form of protection circuitry, so I’ll leave that to others.

In my mind, I can see this working, because BB can behave as a surrogate BeoMaster, a surrogate component, and an end-user remote. It can be programmed to monitor the state of the connected devices and insert any missing status or commands via triggered macros, programmed as needed to achieve the desired effect (example as given above- monitor that only one source is reporting playing; tell the other source to stop playing; tell the 2300 that a source is playing, if needed).  I have a working 4000 – does it share the same Aux Dual-DL pin-outs as the 2300? If so, I could test and see how it behaves with this setup.

[Madskp]

TK wrote:

I have a working 4000 – does it share the same Aux Dual-DL pin-outs as the 2300? If so, I could test and see how it behaves with this setup.

The 4000 is the same as an Ouverture in Europe, so it has Masterlink, and therefore not DL86. The AUX connector does have DL80 that responds to both TAPE2 and PHONO commands like the BC2300

TK wrote:

What I’m not entirely sure of is the logic and safety of having two sources share a single audio channel without some form of protection circuitry, so I’ll leave that to others.

That part can probaly be reverse engienered from how that part of the circitry is made in a Beomaster/Beocenter with separete TAPE2 and PHONO connections, but will need some interfacing with the BB part to switch between the audiosignals for the two sources

Location: Denmark

[Author]

Posts