[TK]

Here’s short video sample of the latest iPhone MCP app working with BeoBabble.  MCP5000 and 5500 are both working, but I’ve only had time to finish the screen updating for the MCP5500.  Still a work in progress, but the exercise has greatly helped me flush out the BB protocol prior to release, so I’m happy I took the time to deep-dive into an end-user app.

 

 

[TK]

Just an alternate approach – if you purchased a used MCL2 2047 or an MCL2A and accompanying transceiver, you could hook it up to the 6500 and control it via the MCL2 link. It might set you back $150 on eBay for all the pieces. It’s not without a bit of additional trickery surrounding muting.  I’m working on software for my on edification which simplifies this process, but its primarily lab-grown tinkering software at this point, and is months away from being usable by others.

[TK]

IT definitely is datalink.  I’m writing a program which monitors and decodes datalink, and I can watch on my monitor as it is sent across the system, coinciding with all the buzzing.  Some system updates from a CD player transmit a bunch of data, while phono updates are infrequent. I don’t have a strategy for removing it yet, unfortunately.

[TK]

When you say “buzz” do you mean a low level “bzzz-bzz-bzz” type noise that may sound like someone is sending Morse code over your system?  If it is a low level bzz-bzz sound, does the length of the buzz vary depending which button you hit (advance vs selecting a new source, for example), or the component you use?   Does it also happen in between songs on it’s own?  If yes, then it’s likely your Pentas picking up the Datalink ’86 chatter being broadcast from the BM on Powerlink, used to update the Penta displays, as you surmise.  I’ve got a similar setup with the same symptoms, and I also have not fully worked out a filtering solution.

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

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

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

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.

 

 

[TK]

Also to note. The BM7000 is able to respond to commands irrespective of what source is given over MCL2.  You can actually send it a command intended for any of its sources, and it will ignore the source, and simply apply whatever command instruction is given to the currently selected source. Some commands will change the source (ie, the command that changes the source to “Phono”), which is what the Beoremote One appears to not be sending properly.

[TK]

I believe that Phono and N.Radio are both mapped to the Beo4 command 0x93, which the BM7000 will respond to by switching the source and sending a “play” signal to whatever Beogram/CD  is connected to the Phono hookup when it receives the appropriate command over the Aux channel. Is it possible that the BeoRemote One also has a different mapping of N.Radio? What happens if you map the BeoRemote One button to Phono, and try the same experiment?

[TK]

Yes, I’ve been experimenting with what few systems I have, and I’ve verified that the protocol is substantially more basic for the BeoCenter 7000, as an example. As I mentioned, this protoco document  is the ‘BM5000/Other” configuration setting (also seen as simply ‘Other’ in older MCL boxes) . A BM5000 is probably the richest component of the overall protocol, without migrating to MCL 2A, which I’m guessing is plain-and-simple straight DL86, making it incompatible with a BM5000.  Until I have a chance to experiment with more systems, I’d venture to say that MCL82 itself is primarily a kind of “communication  facilitator”, or “glorified IR extender” with an attached speaker switch, which is hard set in advance to the capabilities and IR protocols of whatever master system is specified.

That said,the 2-way MCL82 box does a great job of exposing the BM5000 speakerlink interface and control protocols, which I needed to document.  Armed with this syntax, I should be able to. test control of the BM5000 directly using an Arduino connected directly via the BM5000 speakerlink pin.  Unlike an MCL2A, the Arduino can speak and understand both MCL82 and DL86, and would facilitate a proper integration between A BM5000 and any DL86-enabled products. Stay tuned, I’m nearly there!

 

[TK]

Ok, here’s the data I’ve comprised that no one is asking for: a working copy of the MCL’82 syntax in ‘BM5000/Other’ mode.  It took me 2 or 3 days of pounding on the MCP 5000 to assemble this, and I can guarantee its not 100% accurate.  But it does work as a syntax, and it reveals an important data point- it’s rich enough and similar enough to Datalink ’86 that my goal of building a universal translator of old Datalink protocols is now within reach.

For the two or three of you holding on to your orphaned BM5000 series, this is a significant milestone, because it means that it is possible to Datalink’86-enable your precious heirlooms via a cheap, home-made Arduino box, unlocking all the riches afforded only those select users of newer (but still very old) B&O equipment.  You can have access to a new DL’86 Aux channel, and (gulp) Powerlink!  Yes, you’ll be able to hook up a Penta MkII, and actually have the display work for a change. Imagine your joy in replacing your 40-year-old speakers with more modern 35-year-old speakers! Savor this moment, it happens but once in a blue moon.

 

 

Attachments:

You must be logged in to view attached files.

[TK]

I had a few extra minutes today to transcribe the Datalink’78 (Is there another name for it?) protocols into spreadsheet format.  It can basically piggy back off of some code I’ve already written to send and receive Datalink’80 codes, so it was pretty simple to implement.  Assuming that this document represents what was actually programmed, of course.

As we surmised, a fair number of commands are only available via IR.  That said, I’d be able to test it out with a Beocord 800X to validate the instruction set and protocol, as produced.  If I can find a decent one for $150 or so, I just might pick it up to see if I can interface it with more modern equipment.

“DL’78” Protocol, as described by TJE, attached. (sorry, two files – the second file ‘-1’ contains some edits to differentiate between the original protocol text, and my interpretation.

 

Attachments:

You must be logged in to view attached files.

[TK]

@Madskp Thanks much for your offer! There may be a specific version of the MCL82 box that I could use for engineering purposes, and it would be most helpful to have one.  I will return with a model number in short order – perhaps you have one available.

With reference to controlling the BM8000 without IR- as it turns out, it may be as simple as attaching a 7-Din Y-splitter to the BM8000 Tape output, and intercepting/inserting all the Datalink traffic that way. I’ve successfully managed to do this using the BM7000 architecture, which affords me near-complete knowledge of all the I/O between all the system components. Based on these proposal drawings posted by @cklit, I’d expect the same can be achieved with the 8000 series – I’m now “just another component on the Datalink bus with a 5V pullup”.  For the DL80/86 in the BM7000 at least- there appears to be no error checking of actual data content sent between components, so I am already able do things like turn components on and off, spoof the track count, and directly control the component function as if I was the BM itself. So far all the components are happy to oblige, with my rouge inputs being dutifully accepted as authentic commands and status messages. I’m imagining the BM8000 will allow for the same – worth investigating!

Your thoughts on the BM5000 are exactly what I have in mind for my science project.  The BM5000 uses DL80 protocols for it’s internal component architecture (from what I’ve tested), so that part works already with my current codebase.  Where I’m currently stuck is in finding the external command-set where I can control the BM5000 itself via the eensy-weensy teeny-tiny single DL I/O pin that connects it to a MCL network.  If the MCL82 command-set is rich enough, I’d be able to add the feature you describe, and even more. Given that I already monitor both internal DL80 busses, I can also properly intercept all component status messages, and emulate a DL86 interface for the BM5000, allowing for advanced integration with other B&O components.  (for the 3 people globally who may care to do do, LOL!)

It would also be straightforward to have a BM8000 control a CD7000, for example.  It’s just a matter of creating a macro which monitors for the BM8000 “Play” command, and injects the DL80 “Play” command on the DL. There’s a bit more to it than that, but that is the general idea.

[TK]

Excellent stuff!  I had forgotten about that site, with so much great archival data.  This is a proposal on the Datalink protocol to be used by a Beomaster 8000 to communicate with a Beocord 800X and a Beogram 800X. Looks like a 6-bit protocol with flanking low-bits. If this is how they implemented it, it would allow me to add an interface from DL80/DL86 with an 8000 series with minimal effort, without needing the special box that B&O sold for that purpose.  It would only be as capable as the supported commands, but its a start.  Lovely!

Still looking for info similar to this for MCL82, so if you find anything related to that, I’m happy to receive it.

[TK]

I’ll soon start a new thread covering some of the stuff I’ve been doing, but I thought I’d post one last time in this thread with respect to using the BeoLink protocol to control a BM.  I’ve finally started to experiment a bit with BeoLink thanks to a few programmers who came before me, and I’ve also encountered the “Power Up On Mute” behavior.  In thinking a bit about it, this makes a bit of sense, as a BeoLink request over Datalink is most likely coming from another room where the request is being made via MCL, so if we consider the main room “Zone 1” in the system, and a request comes in from another “Zone”, it makes sense to power up the BM, select the source, and pipe the music output through the aux port while keeping the main room muted. This is remedied by sending an “Unmute” command in succession.

With this in mind, I looked into the BeoLink protocol to see if I could flip a bit in the BeoLink message to cause the system to turn on with “Zone 1” in Unmute mode.  As far as I could tell, the 17-bit BeoLink protocol looks like this:

XXXX – Local/Address

XXXXX – Source (One of the already defined DL80/86 sources – ex 00001=Radio, 10010=CD, etc.)

XXXXXXXX – Command (corresponding to a keypress on the BL1000 or Beo4 – ex 0x01=KB1, 0x1E=Up, etc)

“Source” seems to be subservient to command, because a command by itself be a request to play another source, which sets a new source in the BM.

I focused on seeing if there was a pattern in the first 4 bits which would allow the system to power on unmuted.  After cycling through all 16 possible combinations (0000 thru 1111), I failed to find a pattern which generated the desired effect. I have not yet analyzed the Source or Command settings to see if there’s a single source/command combination that will start the BM in an unmuted state.

With that said, I did learn a few things.  Of the 4 address bits, setting bits 1 and/or 2 (1100 or 1000, for example) will cause the BM to respond to the request, as will setting none of the bits (oooo).  Setting either bit 3 or 4 (0010 or 0001 or 0011) will cause the BM to ignore the request, even if it’s a command that it is expected to respond to. There were some data combinations that caused the BM to re-propagate the signal when the command was not able to be processed locally by the BM, but it stopped behaving that way after some code changes, so I’m not clear how to duplicate that behavior.

I’m guessing that setting the BM to a specific “option” will cause these first 4 bits to make more sense as to how they can be used.  That will have to wait for another day.

 

 

[TK]

Im still learning about Masterlink, but if I understand what you are asking about RE the 1611, I would think it would be possible to convert a DL86 signal from a 1611 into something a BM8000 could deal with.  That said, it may only be possible to have maximum control via the BM8000 IR input. In this instance, the Powerlink cable from the 1611 would go to an Arduino which in turn sent the control signals through an IR emitter, and the line audio output (or input) went through Tape2.  From what little I know about the BM8000, I’ve read that the TP2 jack is fully functional, apart from Datalknk.  But it is IR-selectable, so perhaps it plus the IR receiver can function as a sort of DL86 Aux. What this example cant do in it’s current arrangement is send a command signal back to the 1611, so a bit more thinking would need to be done on how to listen in on the internal DL signals.

[TK]

Just my thoughts –

One of the benefits to buying a Beogram 6500 or 7000 is that those two turntables will integrate seamlessly with your system, and be controllable via the remote. I think there are a few other options that will work as well.  Some turntables u may need to provide RIAA as a typical BM7000 will not have one. installed.  If your father had a turntable hooked up to it at one point, you’ll might need to check to see if your BM7000 has a built in RIAA card already.

RE: Bluetooth – look into the Beotooth offering, as it also integrates seamlessly with the 7000. I have one, and it was an excellent purchase. A generic bluetooth dongle will likely also work, but wont integrate as well.

Remote- consider spending the money to purchase a 2-way remote, such as the Beolink 5000, MCP 5500, or Beolink 7000.  They are specifically designed to work with two-way IR systems like the BM7000.  Of those three options, the MCP 5500 will likely be the least expensive option.

The 7000 has both passive and active speaker hookups, so you have a choice for your speaker system.  A Beolab 8000 is a reasonably priced option that will work well. “Period hard core” would be something like a Penta. Shop carefully, as some of these older speaker systems require some TLC/reworking to get back to their original condition.

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

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

[Author]

Posts