[TK]

That is a shame! Try this: remove the MMC cartridge and set it carefully aside, then remove the black cover to the platter drive wheel- it should just lift off.  Leave the belt in place, so it turns the bottom platter pully. Place your finger to put a bit of pressure on the central disc to hold it down, and hit “play”.  After the system starts spinning, you can remove your finger off the disc.  All the while, point the camera at the exposed gearset.  Try moving the arm left and right.  Then hit stop, and post that video next.

There is a bit of good news with respect to spare parts.  Most of the 7000 internals are shared with the TX-2, including all of the mechanical parts (AFAIK), so with the current cost of a BG7000 in the stratosphere, you should easily be able to find a complete donor parts machine for 50 pounds or less, which a skilled technician can use to carefully transfer over the needed parts into the 7000 case with relative ease.

[TK]

A tired belt may not be your exact cause, but I’ve solved the wow problem before by simply using a slightly tighter/new belt.  Consider also removing the platter and check for anything which may be rubbing against the pulley – wires, gears, etc.  If you remove the belt and spin the platter clockwise it should spin freely without any rubbing noise for a considerable length of time.

If none of that works, I’d imagine that you’ll have to start looking at the PCB voltages. There are probably others more seasoned than myself who can advise.

[TK]

Using your example above, given my understanding of MCL2 and the MCL2AV, I think what is happening might look more like described below.  I’m going to ignore for the moment the IR piece, which I think can be viewed as another way to send and receive MCL2:

Beo4: MCL2 (One way) Sends wireless MCL2

BM5500: MCL2 (One and two-way) wired MCL2 through Speakerlink. Also has its own wireless MCL2 gateway, which you can turn “on” or “off”, depending on your setup.

MLC2AV: MCL2 wired Gateway (One and two-way); sniffs out a few select MCL2 commands to act on, such as Mute and Play. Can send and receive MCL2 to the BM, or towards the Sensor.

Sensor: MCL2 wired-to-wireless Gateway (one and two-way); converts wired MCL2 into wireless MCL2, and vice-versa. Collects IR data from whatever remote is sending in the room, and passes it to the MCL2AV.  Can also receive wired MCL2, convert it to IR protocol, and broadcast to the room. Has a few physical buttons used to inject pre-programmed MCL2 commands onto the wired network towards the MCL2AV gateway, such as “Mute” and “Standby”.

This is just the MCL2 piece.  Then there’s an ML piece, of which there’s a Gateway which can convert MCL2 into ML, and vice-versa.  From what I recall, these components were in constant development, so it’s important to get one that has the absolute latest firmware release, which can correctly translate the most messages correctly.

• This reply was modified 1 week, 1 day ago by TK.

[TK]

I’ve done a fair amount of documenting on all things MCL/MCL2, and almost nothing on ML. Here’s what I can add to the conversation.  This is all probably not exactly 100% accurate, but IMHO it’s probably reasonably accurate for the purpose of this discussion.  Here’s a primer:

• Beo4, Beolink 1000, Master Control Panels, Beolink 7000, MCL2AV + sensors, Pentas, several other Beolabs, and BeoMaster 5500-9300 – any peripheral with a Powerlink plug, as well as some of the all-in-one tabletop boxes, all can communicate with one-another using Datalink ’86, or MCL2 for short.
• Some newer components have both a Powerlink and a MasterLink connection, in which case they broadcast/receive both ML and MCL2.
• Newer-still components dropped the Powerlink connection, in favor of just ML. To attach an MCL2 system to it, you’d need buy some B&O converter to add inter-connectivity.
• The Beo4 and Beolink 1000 use the simplest MCL2 format, designed for 1-way communication, which I call “AC” format (“Address-Command”). A Slew of B&O systems can understand and act on these commands.  Anything which can be directly controlled using a Beo4 can effectively decipher one-way MCL2.
• The MCP and the BeoMaster 5500-7000, and the 9500 use a myriad of 2-way communications formats of various types and data lengths.  Only systems designed to handle 2-way communication protocols can act on these messages. These formats are all part of the MCL2 protocol, and are defined as MCL2.  Only some B&O systems are designed to decipher these more advanced 2-way protocols.
• The MCL2AV appears to be primarily an MCL2 Gateway between the BM and a sensor.  It will pass through most of the data it sees on the bus in a 2-way fashion, regardless of whether it’s a simple or advanced MCL2 message.  If it’s identified as being an MCL2 structure, it will send it onwards. When it sees a few select commands come from the sensor that it understands, like a source selection, Play/Mute/Standby, it turns it’s own speaker pair on or off, and plays whatever is on L&R channel, or it’s own inputs, depending on how it’s set up. One might say it’s kinda/sorta like a limited-function BeoMaster.
• The BL7000 uses the most sophisticated variant of MCL2, which AFAIK only it and a BM7000 can encode/decode into meaningful messages (although it is backwards compatible for message transport purposes, and can still be seamlessly passed through any of the attached linked systems, including an MCL2AV, as far as I’ve been able to test).
• For the sake of completeness, there is also an earlier protocol called MCL’82 that predates Datalink ’86 (I personally refer to it as just “MCL”, which is not really accurate), which AFAIK is only used on the BM5000 and its BM5000 Link peripherals, with some limited cross-compatibility with the BC7000.

Based on my research, MCL2 is a very robust and flexible/extendable system, with one major drawback – It ran at 320 baud.  This meant it can take up to a second or two to send a full complement of system status messages. IMHO this was a bonafide revelation in the mid 80’s but totally antiquated by the mid 90’s.  For example, implementing RDS on the BL7000 involved sending three messages at .5 seconds each, and takes almost 2 seconds to send just 10 characters of data, with header/control information in tow.  Imagine if you had to send a CD’s worth song names over MCL2 – it could take a minute or more, and clog up all the transmission/control lines in the mean time.

I have not yet dug into ML and its underpinnings, but at some point I’ll look into it.  I can only assume they solved all of these speed issues.

• This reply was modified 1 week, 1 day ago by TK.

[TK]

Thanks for the research!  Just based on my own minimal experimentation with Datalink Links, I’ve not seen anything within Datalink to monitor and keep track of the number of currently active/playing link zones in the system, so your experiments are of interest to me.

Most of my monitoring has been on the “Primary” Datalink bus (by that, I mean any component connected directly to the BM, such as an Aux unit or MCL2A). I’ve yet to monitor and document Datalink traffic between an MCL2A and the IR sensor – this appears to also just be Datalink protocol, but perhaps it is formatted a but differently. As a guess, I imagine that B&O does it somewhat as follows: The MCL2A interprets a “Mute” signal from the Sensor as “Zone Off” (sent via a short button press) and interprets a “Standby” signal (from a remote, or long button-press) as “System Off”.  That being said, this alone would not be enough to cause the last active Zone in a multi-zone system to know to forward a “Standby” command to the BM when it is Muted.  If I ever get a second zone put up for testing, I’ll be able to definitively see how this handshake works.

 

[TK]

Courtesy of some input from Madskp offline, I’ve considered a few more design alternatives.  Instead of a specific TP2/AUX splitter, it could be made into a TP/BG/AUX-TV selector, configurable to be selectable using any of the 32 B&O sources.  This would make the dongle more useful in other environments.  There’s a bit more management and tracking of state that has to happen, software-wise. And if we swap out the SENSOR input for a USB charging port and external power, and instead rely on DL86 for system state for Powerlink, the dongle should work in  other environments.  If I’m thinking about this correctly, its similar to a software-configurable MCL2AV device, tied to and controlled by outputs from the Master.

[TK]

TP2/AUX pins 1 & 3 are line-level, from what I know.  Those pins are directly connected to the 5500 line-out L&R pre-volume control, so the RCA outputs would be another place to hookup if need be.  I’d probably prefer to just use the Din-7 plug for minimal # of connections (2, at this point: TP2/AUX, and SENSOR), unless there’s a stumbling block I hadn’t considered.

A cursory look at the schematic indicates that SENSOR also carries a DL86 bus, so that’s another connection option.  It also might make sense to have a SENSOR pass-thru on the dongle, so all function is retained.  I wonder if I can just power off of this plug? There’s no dedicated ground pin – only the casing – so that’s something to consider.

[TK]

Meanwhile, in a poorer part of the world not littered with free Beolab 5s, a Beogram 5500 is rescued from (apparently) a family of drywall tapers.  Or potentially cocaine dealers who had a shipment explode on them, I’m not sure.

Attachments:

You must be logged in to view attached files.

[TK]

The “Buzz-Buzz”ing you hear during during song and system changes is most likely the Datalink messages being sent by the BM to update the Penta displays.  You’d be able to confirm this if you disconnect the Datalink wires in the terminals and the buzzing stops.

Just strategizing – a potential inexpensive fix is to run data in a separate 2-wire shielded cable alongside the Powerlink cable, and reconnecting them at the two Din-8 fixtures, or by using the separate 4-pin speaker connections to just run data from the BM to the Penta, and keep the Powerlink for just audio sigmal. I have not tried either method, so I can’t speak to how well either method will work, including whether there might be other modifications needed to the Pentas to use method two. Good luck!

Just an afterthought – there is probably a straightforward way to have DL signal broadcast wirelessly around the house from the BM via a DIY contraption – it’s a very low baud rate.  A real Rube Goldberg solution.

[TK]

Very much looking forward to trying this out.  Any thoughts on the required pre-condition of the BM5?  For example, are you required to start with a known good HDD image, or is that no longer needed?

I don’t have any of the hardware at present. I recall some threads at an earlier date that there were some issues with some of the computer components used in the Beomaster 5. You mention that not all of the hardware in the original box is used, so I’ve not researched your project enough to see if some of the components that typically tended to fail is in the list of removed pieces.

 

[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 3 weeks, 5 days ago by TK.
• This reply was modified 3 weeks, 5 days 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 3 weeks, 5 days 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 3 weeks, 5 days ago by TK.
• This reply was modified 3 weeks, 5 days 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 3 weeks, 5 days 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.

[Author]

Posts