[TK]

Getting volume status:

There are several methods to do this.  Indeed, the system will typically send out a MCL2 status message broadcast when the state of the system is changed via either a Beo4 command, or someone hitting a button on the component, or a status update provided to the Beomaster over Datalink ’80 from one of the components. Some examples of these are the bitstreams you see in the Github output you referenced.  There is a wide variety of status messages, but the ones I’ve found to be the most useful are the ones that are sent as responses to commands that are sent by an MCP (Master Control Panel), which has a FrADR address of ‘11110’.  This makes sense, because the MCP is charged with updating the user of the full system status, so the messages it receives will have the most information on system status.

This is where it’s nice to send commands using the ‘AAC’ format instead of the ‘AC’ format, in order to make the Beomaster believe it is talking to an MCP. I pretty-much only send commands using AAC (which is why I messed up my original post to you, confusing ‘AAC’ with ‘AC’).  While AC is effectively sending messages “in the blind”, AAC is the basis for 2-way communication, where an FrADR sends a command, and typically expects a response or confirmation directed specifically to it.  Incidentally, If an MCP gets no response in a timely manner, it displays the dreaded “NO CONTACT” message that many of us are familiar with, even if the command was received but not responded to.

Here is an example handshake between an MCP and a BM:

:STX:00:10:00001:11110:01011101:ETX: -> ‘AAC’ Send Radio from MCP: “ShowStatus”

BM responds that it is playing Radio P3 out of 6 programs, volume 20, unmuted, loudness on, stereo, 97.3FM. All of this is encoded in the messages below:

00.1100.11110.0010.0001.0001.0100 -> ‘AND’, 3 nibbles of data

00.1100.11110.0010.0000.0001.0011 -> ‘AND’, 3 nibbles

00.1110.11110.00001.0100.1000.0110.1000.0001.0100 -> ‘AAND’, 5

00.1100.11110.0101.1111.1100.0000.0000.0000.0011 -> ‘AND’, 6

00.1100.11110.0111.0000.0000.1111.1111.1001.0111.0011.0001 -> ‘AND’, 8

Here you can see now digits 3-6 have changed from the more simple ‘AC’ and ‘AAC’ formats. These new messages comprise of ‘AND’ and ‘AAND’ formats, which can vary in length, depending on the ‘N’ (N-count – more on that at a later date).  There are now 4 digits instead of 2 that make up the message format.  We can also see that the AND format has a single ToADR of ‘MCP’ (11110) , and the other AAND format contains a ToADR and a FrADR.  I can go into more detail on all the possible permutations in a bit, but this can serve to help you better understand how you will need to setup your receiver to collect incoming messages.  total message lengths will vary based on format and ‘N-count’, as will message structure. Some bit patterns within the message you are looking for will probably be unique, and you can probably just seek those patterns when you are hunting for data.  In this case, the volume data you are looking for appears in 2 messages – the very first AND message, and the single AAND message.  Looking at the AAND message, if you just parse for “0011101111000001010010” at the start of the message, you’ll likely get what you need for volume. The remaining part of the message: 00.0110.1000.0001.0100 has volume information stored as a number between 0-70, in the last 8 bits.  in this example the stored number is ’20’.

Fair warning, this AAND message format is also used to send track count, in which case the message will begin with “0011101111000001010000” *next to last digit is now ‘0’.  Also fair warning, it’s been a while since I reviewed this, so I may be totally wrong in my recollection.

• This reply was modified 2 hours, 13 minutes ago by TK.
• This reply was modified 1 hour, 46 minutes ago by TK.

[TK]

Just an FYI, some of my lexicon and definitions is based on my own MCL code I call BeoBabble, so if the nomenclature doesn’t match what you read elsewhere, then it’s because I made it up, lol.   My plan has always been to release it in Github, and it will convert maybe 95% of all MCL2 traffic into english, but I realized that I need to stabilize the output protocol a bit prior to releasing it, if only for pride.

Source:

The “Source” you refer to are the 5-bit component addresses, which I refer to as simply “Address”.  So there are 31 of them, plus 1 (‘11111’) for future expansion. They play an important role in 2-way communication, because the code tells the listening ToADR the component-type that the FrADR is. This way, the ToADR can cater a message response based on the FrADR’s capabilities.  (This will be important to understand in the next post, which is why I’m discussing it first) Every component B&O made was assigned a unique address type to identify what it was.  Further, B&O also foresaw the need to be able to communicate with multiple components with the same address type (for example, 2 CD players on one MCL). This gave rise to the ‘AUC’ command set, where you are required to send a Unit number 0-6 as well as the ToADR:

:STX:S:T:01:ToADR:UNI:DATA_CMD:ETX: -> ‘AUC’ designated by the format ’01’

:STX:00:00:10010:00110101:ETX -> ‘AC’: “Send the CD a ‘Play’ command”

:STX:00:01:10010:000:00110101:ETX -> ‘AUC’: “Send the CD:Unit ‘0’ a ‘Play’ command”

Based on my limited testing, these two calls are essentially equivalent on a single-CD MCL. I have not tried all the permutations of commands, but I suspect based on my limited experience that an ‘AC’ command can be viewed as a shorthand for an ‘AUC’ command where the unit ‘U’ defaults to ‘000’. It’s been a while since I experimented with this, so I may be way off base.  This is how I remember it being, though.

• This reply was modified 1 hour, 55 minutes ago by TK.

[TK]

Whoops, I just realized that a Beo4 command is an ‘AC’ command (Address-To, Command), and is formatted like this:

:STX:00:00:ToADR:DATA_CMD:ETX:

Examples of both styles of command —

:STX:00:00:00001:00001100:ETX -> ‘AC’ “Send the Radio a Standby command”

:STX:00:10:00001:00001:00001100:ETX -> ‘AAC’ “Send the Radio from the Radio a Standby command”

Both AC and AAC commands will work for your implementation, and should yield the same result.  But there’s no need to complicate matters, so you might as well stick with the slightly simpler ‘AC’ protocol.  But since I made the error, now is a good time to point out some of the nuances.  An AC command is ’00’, which tells the receiver that a 5-bit address and an 8-bit command follow.  if the receiver sees ’10’, it knows to expect a 5-bit address, followed by another 5-bit address, followed by an 8-bit command.

• This reply was modified 14 hours, 6 minutes ago by TK.
• This reply was modified 14 hours, 4 minutes ago by TK.

[TK]

Sounds like a great project.  Datalink ’86 is a very extendable protocol for its time, that is intended to handle multi-component 2-way communications.  If all you are looking to accomplish is emulate the function of a Beo4 (sending one-way commands using MCL2 over the Aux port), then you need not worry too much about the various message formats and permutations of MCL2.

A standard Beo4 command is implemented via an MCL2 ‘AAC’ command (Address-To, Address-From, Command) through the MCL network. [EDIT: whoops, no it’s not, but the illustrated command structure will still work. See next post for a clarification] This is accomplished by sending a fixed-length command of 22 bits, and looks as follows:

:STX:00:10:ToADR:FrADR:DATA_CMD:ETX:

In this message, the preceding ’00’ is what you will usually send to start message for what you are doing, and the ’10’ tells the listening component the structure of the message.  Namely, that the following message contains a 5-bit destination address, a 5-bit sender address, and an 8-bit single instruction. There are many other message formats and combinations, which allow for messages of different structures and lengths. However, since you are not doing anything overly complicated, you’ll likely only need to use the AAC format of ’10’ and most of your commands will look like this:

:STX:00:10:00001:00001:DATA_CMD:ETX:

This is basically sending an 8-bit command from the “Radio” (00001) to itself “Radio” (00001).  DATA_CMD is a number from 0 to 255, and is a singular function, such as “STANDBY” ( 00001100 ) or “UNMUTE” ( 00011100), for example.   You can use the already published list of commands, which has many of the most commonly-used ones, to have the 6500 do your bidding.

Here are some commands you will likely need:

:STX:00:10:00001:00001:10000011:ETX: -> Set source to A-Aux (Powers on)

:STX:00:10:00001:00001:00011100:ETX: -> UnMute (needed when sending MCL)

:STX:00:10:00001:00001:00001100:ETX: -> Standby

Some of the data you are looking at from your example from Toresbe is Beomaster OUTPUT – i.e. what the Beomaster is updating the other components on the system on. These longer messages contain things like system volume, track number, RDS data, etc.  Once you are ready to start listening for status updates, you can begin to process and act on Beomaster messages as well.  I’ll refrain from posting more about that protocol so as not to confuse you. The entire protocol is very rich, and has many quirks.  Much of the protocol basics are defined in the TJE 1985 document, but the entire protocol syntax has advanced well beyond that point until its final iteration in the mid 90’s.

Feel free to ask any follow-up questions you may have.

• This reply was modified 14 hours, 2 minutes ago by TK.

[TK]

Keep up the good work.  Looking forward to seeing the finished product.

 

[TK]

I hope to hear more of your project, @type81.  Perhaps we can collaborate on some protocol work in the future.

It took months  to find a Beolink 7000 within the realm of “affordable”, and a few more weeks to figure out how to recap it.  It’s kinda-sorta working now, but still a bit twitchy.

Now that I’ve cleared that hurdle, I’m finally getting my first look at B&O’s Datalink ’86 RDS protocol implementation.  Lots of BeoBabble “Invalid Message” warnings and several never-before-seen conditions yet to be coded for, and all of it yet left to decipher. I’ll hopefully make some strides in getting a rough protocol update and update the documentation within a few weeks.

I’ll be able to add RDS to the MCP iPhone app, but beyond that, its use case will be fairly limited, primarily for anyone who uses a BM7000 and still has an interest in listening to over-the-air radio.  That said, the journey of discovery keeps it fun.

Attachments:

You must be logged in to view attached files.

[TK]

First things first – does the TX-2, in fact, ship with Datalink enabled?

Early answer: yes, it appears so. But more testing is required to verify the entire instruction set.

I’ve been postulating on this for the past month, trying to find a definitive “it does” or “yes, but there’s a catch…” post, but I figured I’d have to do my own testing anyways.  So before changing out the RCA output cable, I thought I’d run a quickee test of the Datalink channel on the main board, to see what signals were being sent, if any.  I attached a signal analyzer to the board output (going from CPU pin 19 through some circuitry to pin 1 of the white connector) and measured the results.  Presto: Datalink. I received both a “No Media” signal and a “Status Playing” signal, depending on whether I held the record sensor down. With this experiment done, I’m quite confident I’ll be able to attach a Din-7 cable to the output board, and use the Datalink features on a Beomaster 5500, at least.  For the later units, I’ll still need to find or create an RIAA card.

Attachments:

You must be logged in to view attached files.

[TK]

Just my observation – I’ve been following the 400x market for about a year now.  Although they are very iconic and insanely cool, they are actually readily available in all states of condition, which helps keep prices in check.  I’ve probably counted 20-30 for sale this year on eBay alone of the various types.  4002 late models probably trend as the least expensive of the original design, with premiums paid for the 4004 and 4000 models. I’d add that you frequently see several for sale asking over $1500, but not many sell at this price point in the open “as-is” market.  More frequently, they’ll sell in the high $600 range for working models with serviceable cartridges.   Known restorers can of course get more for their units privately.

The best news of all is that there is a steady supply of 3rd party support, which helps keep many of the units working (which also helps keep prices on the low side, because there’s almost always a way to get a glitchy unit working well again). RIAA boards range from $150-$400, depending on who you buy from. Cartridges are $150 for as-is (depending on the cartridge type), and plenty more for re-tipped ones. You’ll usually save a bunch of money if these are already on the unit you are buying, relative to the costs of acquiring the pieces individually. We have to pay more in the States than enthusiasts do in Europe – I’d say up to 50-75% more for the same-condition merchandise. There are simply fewer units available, and they cost a lot of money to ship overseas.

As to the future – who knows, records have seen a mini renaissance, but I don’t see this generation of kids forking over thousands for 50-to-70-year-old equipment anytime in the next two decades.  I’d venture to say that If you spent top dollar and paid $2000+ for a super cherry restored one with all the bits you describe, you’d probably be unable to make any return selling it at any point in the future.  Just one person’s opinion.

 

[TK]

Nice build, adyan!

Just for my knowledge: you added a Din-7 cable to your TX-2 and soldered pin 7 (or pin 6, depending on your RIAA setup with your receiver) directly to pad 6 on board 11, and Datalink started working without further modification? This would be what I’d surmise was a possible outcome, I just haven’t seen anyone post that it worked and was this straightforward.  Can you also share which version if TX-2 main board you were using?  There are at least 2 iterations, as shown below.  Early board types have no transistor in the data path, and later boards added the transistor.

Best!

 

 

Attachments:

You must be logged in to view attached files.

[TK]

I’ve been sidetracked the past few months on pressing projects, so I’ve made little progress on decoding 100% of MCL 82 (Which I now call MCL1 for simplicity). Here’s the latest protocol reverse-engineering effort.   My longer term goal is to facilitate a compatibility layer between MCL1 and MCL2 using BeoBabble, so that a Beosystem 5000 works seamlessly with MCL2, and the associated MCP 5500 series of remotes.

Many of the components that were shipped with the Beosystem 5000 are quite capable of receiving and providing most the data that an MCP 5500 can send and display, with small protocol tweaks.  The weak link in the system which prevented access to this featureset originally is the Beomaster 5000 IR implementation.  I already bypass this IR layer by monitoring the internal Datalink channels between the various components directly, so tapping into them and creating a bridge mode within BeoBabble, I’ll be able to control them and the BM5000 from an MCP 5500.  This implementation will hopefully lift the BM5000 from the “Orphaned” category, and provide greater utilization of its components.

After tinkering around with various system setups, I admit I’m a bit smitten with the large LCD digits of the 5000 design – there’s something a bit magical about their character that the later systems lack, IMHO.

 

Attachments:

You must be logged in to view attached files.

[TK]

I’ve just finished repairing one of these with a similar issue – starts playing as normal, but slides around as the record is played, as if there is not enough weight on the stylus.  The problem I found was a broken bracket, shown as 1107 in the photo below.  Apparently this is a common issue with these players.  Getting to it in order to repair it was a fiddly exercise, but not impossible. If this is indeed the same problem that you have, the player will not play properly until the bracket is repaired.

 

Attachments:

You must be logged in to view attached files.

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

[Author]

Posts