I'm mistaken. The data pin is indeed pin 6.

Hi iPocrates,

I am working on an interface based on the schematics in the service manuals for some of the older B&O products (mainly the ouverture service manual but some of the older CRT TVs with ML have very similar circuits). The more recent masterlink products used an ASIC (a purpose designed microchip) that replaced much of the discreet circuitry but obviously that is not an option if one wishes to create an interface based on off-the-shelf components.

I have very limited time available to work on this at present but I'm trying to make some progress whenever I have some free time. In the past couple of weeks I've got as far as re-creating the schematics in Eagle CAD, and creating a pad layout for the ML socket, in order that I can make a start on designing a PCB. The schematics may look complicated but in reality the whole design is based around a quad opamp plus a number of transistors and discreet components. I've concentrated entirely on the data side of masterlink and ignored completely the audio aspects for the time being (and in any case any audio circuits would probably be best kept to their own PCB to avoid interference issues as far as possible).

The B&O design in the ouverture utilised a 80C32 microcontroller which uses 5 volt logic levels, so modification would be required to interface directly to the 3.3V logic levels of the RPi but I'm not sure that would be the best option anyway - my intention is to interface to a 5V arduino on the basis that it is cheaper, lower power, and better suited to strict timing requirements than a microprocessor based system such as the RPi, and by doing so the Arduino would be programmed to deal with the low level details of communicating on the masterlink bus but could then be connected to a raspberry Pi (or other computer) which would could then concentrate purely on whatever higher level functionality the user wished to implement.

When I have completed my initial PCB design I will then need to order a small number of PCBs to populate and test and will obviously need some time to both reverse engineer the low level comms and to implement these in the Arduino. The main commitment I have outside of work at the moment is the ongoing renovations to our house and this is also what is preventing me from progressing with the reverse engineering aspects right now as all my main room B&O products are in storage whilst work progresses on our lounge. I do have an oscilloscope with basic logic analyser functionality and a masterlink gateway so once my masterlink setup is back in situ I don't envisage too many issues with reverse engineering the protocol itself, and in the meantime, if I have the opportunity, I may dump the 80C32 code from the EPROM on the ouverture ML board and see what clues I can glean from disassembling the code therein.

If there are others here who have any of the skills required for the various aspects involved and feel they would like to assist or contribute to any part of the project I am more than happy to discuss things in more detail as I am hopeful that the completed project could create the basis for quite a number of new and interesting projects.

Kind Regards,

Martin.

Hi Martin,

nice to hear this. Thanks for keeping us updated on this.
Was there any success with the MAX3280E ? 

Time is my biggest concern, too. But I could help with the audio part and the RPi integration. 
I really think that the final target should be designing a RPi HAT with integrated ML logic and audio.   

For reversengineering the Arduino might be fine but there are much more possibilities with a little machine running Linux...

BR,
BeoMotion. 

BeoMotion wrote:

Was there any success with the MAX3280E ? 

Because of the house renovations and most of my B&O setup being in storage I haven't had an opportunity to try it yet although from the specs I am optimistic it will work as a receiver on the ML data bus.

Even so, I chose the MAX3280E as it is a receiver only and would be reluctant to try adapting the output from an RS485 transmitter as there is the potential to cause some very expensive repair bills if I got it wrong. In fairness the ML circuit in the ouverture does have some protection incorporated by way of the diodes / zeners and I'd suspect there is a similar setup in other ML products but I'd still rather not tempt fate, and that is why I have chosen to use the ML schematics from the Ouverture as a starting point - my feeling was that if there was a simpler, reliable way of achieving the same result, then B&O would have used it in their designs (obviously the ML ASIC was their cheaper way of doing it in later products but that is not an option for us).

BeoMotion wrote:

Time is my biggest concern, too. But I could help with the audio part and the RPi integration. 

Any help would be appreciated and I'd be interested in what people might want to achieve with the finished design as that might influence the design - It would for example be pretty straightforward to incorporate some GPIO controlled audio switching in the design to allow for multiple audio sources and again the Ouverture schematics provide a pretty useful starting point for the ML balanced audio <> Line level conversion.

BeoMotion wrote:

I really think that the final target should be designing a RPi HAT with integrated ML logic and audio.

Yes, my intention was for a RPi hat (at least in form factor even if not adopting/complying with the full hat specifications/requirement) for the ML data side of things whilst also extending the headers to allow for a separate ML audio PCB to be stacked on top. As well as an ML audio device I can see the design being used as an alternative to the MLGW so keeping the two PCBs seperate provides multiple benefits, namely reducing the risk of crosstalk and interference between the data circuits and the audio, and allowing for MLGW style control applications where the audio interface may not be needed at all.

BeoMotion wrote:

For reversengineering the Arduino might be fine but there are much more possibilities with a little machine running Linux...

I agree, the arduino alone would be quite limited, but the Raspberry Pi GPIO lines are far from ideal for dealing with the ML communications as you'd need to be running a kernel with the PREEMPT_RT (real time patches) compiled in to stand any chance of communicating successfully with a bit-banging interface and even then I'm not sure it would be straighforward to get the timing right. That is why I am looking to incorporate an arduino into the design such that the arduino can deal with the low level ML comms leaving the RPi (or whatever else you decided to connect it to) to deal with the higher level functionality. The two would then communicate with each other via RS232 (or perhaps I2C or SPI).

Martin.

riverstyx wrote:

I'd be interested in what people might want to achieve with the finished design

1) distribution of multiple audio/airplay sources to multiple rooms
Would be great to have an ML input and an ML output connection with some switching logic. This way you could connect one of those devices to each link room without loosing the standard ML connectivity. 

2) MLGW replacement

riverstyx wrote:

the arduino can deal with the low level ML comms

Okay, I hear what you are saying. Let's see whether bit-banging is really required. I still hope that the uart interface can be used...
If implementing a separate MCU for the ML interface you should also think about energy saving. So that the MCU can pull the BOOT pin low if there is incomming ML data to that specific address or send a command for powering down.
Maybe the ATM328 is not the best choice. There are much faster and cheaper solutions out there (e.g. STM32F/L with great community support).

riverstyx wrote:

a separate ML audio PCB

Good idea. This might bring the cost down for the ML board if someone wishes a MLGW replacement only.

BR,
BeoMotion. 

BeoMotion wrote:

1) distribution of multiple audio/airplay sources to multiple rooms
Would be great to have an ML input and an ML output connection with some switching logic. This way you could connect one of those devices to each link room without loosing the standard ML connectivity. 

Do you mean distribution of audio over ethernet between (or to) these devices, such that they would isolate themselves from the audio on the wider ML audio bus, and instead inject new audio to that 'local' segment of the ML network? The associated control logic on the data bus would certainly require some thought but I love the idea if that is what you have in mind. I'll give some more thought to that control logic when I'm not so tired - trying to do so after a long and hectic week at work just makes my brain hurt 😕

I also think it would be worth having some local switching of multiple inputs (using one or more GPIO controlled audio switching ICs) so that you can have a number of line level inputs to the device and switch between them based on source selection commands eg one input for A.AUX, another for A.MEM, another for CD etc (source names as examples only, as you'd be free to map source names in software as desired). Obviously the audio out of the RPi would be routed to one of these inputs.

BeoMotion wrote:

Okay, I hear what you are saying. Let's see whether bit-banging is really required. I still hope that the uart interface can be used...

Actually, having looked at the ML microcomputer schematics again in conjuction with the 80c32 datasheet I am pretty sure that we may be able to utilise the uart rather than having to resort to bit banging for the ML data - the ML_RX and ML_TX are routed to the uart capable pins of the 80c32, with ML_RX also routed so as to trigger an interrupt on receipt of data (I've added the pin designations to the schematic below to illustrate what I'm talking about).

Tthinking back I believe the reason I overlooked and/or dismissed this option previously was that at the time I was concentrating on the datalink comms direct to my beogram and that is a 5V signal, logic '1' = 0V, same 8 bits sent twice in succession, with timing equating to roughly 320bps, and that was going to be easier to achieve with bit banging than by trying to configure a uart to achieve what I needed and having made that decision I didn't stop to reconsider it when looking at the ML data bus.

Indeed looking at Beoaffinity's posts in this thread would seem to confirm that the output of the circuit is standard serial data. One of the beovision service manuals (I forget which one) shows an almost identical circuit to the one in the Ouverture service manual but also states that later versions of the same television use the ML-ASIC instead so I don't anticipate any difference in output between the two.

It may be a fewf weeks before I find time to do any more on this project as I want to concentrate on getting my lounge finished this weekend and over the Easter weekend but at least that will enable me to set up my ML products again 🙂

Thanks again for your input, it's really useful to be able to thrash out these ideas collaboratively.

Regards,

Martin.

what could be done with a smart device like this?

status displays:
- active source
- when you listen to N.Music or N.Radio it could display the current track, artist info or the current station

infrared two-way-ML-communication:
regarding the "hype" for home automation one of the greatest things would be the possibility to receive and send infrared commands- not only from the Beo 4 over the ML system. Then we not only could send and receive e.g. LIGHT commands from everywhere to everything but only control 3rd party devices via infrared.

infrared-to-RF or zigbee etc. converters

... I guess there are endless possibilities for such a device. :)

riverstyx wrote:

Do you mean distribution of audio over ethernet

Yes. So that you are able to listen to a local streaming source like airplay independent from other rooms. But if you wish to listen to a "normal" ML source (triggered e.g. by "RADIO" on Beo4)  in this room this should be possible, too.

TWG wrote:

status displays

I would not recommend to include a display or a connector to this PCB. ML cabels are not that much flexible and the place you have access to the bus is normally not the right position for a display. For this case a second RPi with only a display attached and connected via a REST API would be a much better attempt.

BeoMotion wrote:

Yes. So that you are able to listen to a local streaming source like airplay independent from other rooms. But if you wish to listen to a "normal" ML source (triggered e.g. by "RADIO" on Beo4)  in this room this should be possible, too.

I've been thinking some more about this but haven't yet come up with a simple way to achieve this.

The options as far as I can tell would be:

1. Leave the data lines intact but split the audio lines (ML commands still propagate across entire ML bus, but substitute audio is injected into the local ML segment.
2. Split both the ML data and audio buses on an ad-hoc basis as required, injecting new audio and preventing data from propagating outside of the local segment whilst the local streaming source is in use.
3. Split the entire ML bus (data and audio) into 2 seperate ML systems, relay commands and audio between both ML buses as required.

Option 1 would work, but commands will likely cause unwanted behaviour elsewhere in the masterlink network (products elsewhere in the ML network responding to commands that were not intended for them).

Option 2 would almost certainly cause problems with ML device address conflicts, with disappearing audio & video masters and associated loss of power to the ML data bus.

Option 3 seems the most practical solution, you'd basically end up with a number of completely independent masterlink setups each with their own audio and video masters if desired (the interface + RPi could act as Audio master if needed). It would just be a case then of determining and configuring which commands are relayed across to the other ML networks. Effectively if you had a RPi+interface in each room, then each room would be a main room setup and no longer a link room - this would also allow a video master and an audio master in that room with speakers connected to only one of them (products in option 2 and option 0 respectively) as opposed to each product requiring their own speakers as is usually the case in a link room.

The downside to this option is that two independent interfaces would be required, and that creates a new issue as the RPi only has one UART header. I2C or SPI might be a workaround but that would mean going back to having a microcontroller embedded into the ML interface and at that stage it might make more sense to instead have one microcontroller with multiple UARTs aggregating the serial data from multiple ML interfaces into a single serial communication stream with the RPi.

I do want to come up with a design the incorporates enough flexibility to allow for the more interesting projects - especially those that are not currently possible with existing products (the MLGW for example), but at the same time I don't wish to reach a stage where the complexity means the design becomes unachievable in the limited amount of time I have available to dedicate to this project.

Martin.