ARCHIVED FORUM -- March 2012 to February 2022READ ONLY FORUM
This is the second Archived Forum which was active between 1st March 2012 and 23rd February 2022
Hi all,
anybody out there who has successfully revers-engineered the MasterLink protocol?I think that there was already an attempt by a Beoworlder in the old forum but did he ever continued his work? http://archivedarchivedforum2.beoworld.org/forums/t/28687.aspx
Just had an old ML modul from a BeoMedia in my hands and thought about whether somebody could build something compatible.A ML transceiver without all the BeoLink PC and BeoPort stuff...
You know, just a little PCB that could be attached on and controlled by e.g. a Raspberry Pi. The engineering part shouldn't be too hard. Just a couple of OP amps, two MUXing ICs and a good DAC with symmetrical output. But a very time consuming project indeed...Wouldn't that be cool? A diy MLGW + BeoSound system that is highly customizable and opensource for little money...
BR,BeoMotion.
-------------------------------------------------------------------------------------------------------------------------------------------
Current state:
Jun 10 2015 - Inverted logic at the output of the RS485 converter. Need to add a logic inverter.Jun 7 2015 - RS485 to RS232 converter MAX3280E can be used to read data directly from ML busSep 20 2015 - Tried to send data using a RS485 transceiver. Unsuccessful.
--------------------------------------------------------------------------------------------------------------------------------------------
Cheat sheet:
1) Link to old post hooking up a logic analyzer to internal UART of BeoPort: LINK2) Link to old post where member "psand" describes some details of the telegram: LINK
I kinda have reversed engineered part of the ML protocol. Not directly on the ML as you're suggesting, but on the USB between Beoport and the PC, or between that board and the Beomedia (it's the same).
The BeoPort has a protocol containing 2 kind of messages, some messages are addressed to the box directly (turn speaker on, etc) and some are passed through the ML.
P.
Beoworld app with direct photo upload and emoticons.
Okay, but then you would still need the BeoPort that "translates" USB to ML.
Would be nice to have a more "efficient" solution.A small PCB with UART and I2S input and a RJ45 ML output.
What's in the Beoport is probably exactly that board you're talking about. But I am happy to help anyone whose got a serious project with what I know from the protocol.
Have been looking at this in the past whether there is a possibiluty to revers engineer the ML or to pull the PCI card which is used in the BeoMedia. Making use of Rpi2 might be a interesting idea since it would be possible to add additional hw modules to for example improve audio quality from the Rpi. Question is if the pin layout on the Rpi is enough and would work out:
Happy to support with gathreing information, testing, hosting and documentation. But, have limited coding skills. Here are some additional links on the same topic:
- Connecting Beomaster to RaspberryPi and or PC
- Reverse Engineering of B&O drivers (BeoPort) and software (BeoPlayer)
Yes, but the problem is that most of the ICs used in the BeoPort aren't available any more as well as the BeoPort itself.
So it would be a complete new design with new components.The core in the BeoPort seams to be an USB->Serial converter IC and an 8bit MCU that translates the commands to ML language.Both components could be replaced by a well programmed linux kernel modul or a normal C/C++ program and some gpio bitbanging.
Unfortunately I have not really the time for something like this at the moment.I just had the idea and maybe some others with more spare time will read this and get inspired... :-)
kimhav:Have been looking at this in the past whether there is a possibiluty to revers engineer the ML or to pull the PCI card which is used in the BeoMedia. Making use of Rpi2 might be a interesting idea since it would be possible to add additional hw modules to for example improve audio quality from the Rpi. Question is if the pin layout on the Rpi is enough and would work out:
The "PCI" card isn't really PCI. It is connected to internal USB and SPDIF. PCI is only used for power supply in this case.
Yes, we definitively need somebody who designs a MasterLink Raspberry Pi HAT and somebody that writes a dedicated driver software for it.
Any volunteers? :-)
BeoMotion:The "PCI" card isn't really PCI. It is connected to internal USB and SPDIF. PCI is only used for power supply in this case. Yes, we definitively need somebody who designs a MasterLink Raspberry Pi HAT and somebody that writes a dedicated driver software for it.
Ah. Wasn't aware of this which would make it easier due to the facts that one doesn't need to make use of a PCI-bus.
Forgot to mention, but there is at least this SourceForge project still available which controls the BeoPort:
http://sourceforge.net/projects/kpc2/
Yes, I am aware of this project. The problem is that it depends on the BeoPort hardware, too. We need a more simple solution.
Just hooked up a scope on ML DATA. Found out that the data seams to be transmitted by just +-300 mV. Expected a much higher voltage...
Maybe I will put some more effort into this and create a little arduino library that can read the raw data from the ML bus with few external components.This would be a good start to build upon...
BeoMotion:Just hooked up a scope on ML DATA. Found out that the data seams to be transmitted by just +-300 mV. Expected a much higher voltage...
Yes, I looked at this a while ago, but didn't have much spare time available at the time and I then ended up buying a MLGW which removed much of the incentive to investigate further.
I believe the spec is 0.5V peak to peak (+/- 250mV balanced signal) - presumably this low voltage was chosen at least in part to reduce the risk of crosstalk between the data and audio signals. Some negotiation occurs when masterlink is powered up as to which device will be responsible for driving the data bus, with the audiomaster or videomaster then being responsible for providing the power. Devices then pull these lines to ground to transmit. Since this is a bus arrangement, I would assume there is also some mechanism for avoiding and/or dealing with collisions (when more than one device attempts to transmit simultaneously).
I understand you wanting to interface to Masterlink directly, but since all these details will not be trivial to implement, and are already handled by the Beoport PC2 (which whilst no longer available new are frequently available used on ebay for not much money), if you wish to transmit data, the simplest option is likely to be to interface to masterlink via a Beolink PC2. What I'm not certain of is how much manipulation of the masterlink data occurs within the PC2 - ie whether it blindly passes all the masterlink data through to the USB (and vise versa) or whether it filters/converts this data relative to it's original and intended use. PhilLondon may be able to answer this one.
You are however correct in what you say about reading the raw data from ML - this should only require a few external components and some software and therefore should be reasonably simple to implement. It's one of those projects I've considered doing for a while but haven't found the time to do yet. My idea was to sniff ML data, spefically looking for A.MEM related commands, as a trigger to send datalink instructions to my Beogram (which is connected to the aux input of my BS9000). Because the BS9000 is in option 0 with a BV7 in option 2, all commands will cross the ML network, even in the main room, so this would be a nice way of gaining full remote control of the turntable from anywhere within the house.
I'll follow with interest any progress you make with your arduino library as it may inspire me to allocate some time to this project.
Kind Regards,
Martin.
Based on that BM-Link for Mac OS X broadcast meta data (artist name and song title) from both N.MUSIC and N.RADIO to to be shown in the display of Bang & Olufsen AV products; could one make the assumption that it blindly passes all the masterlink data through to the USB when communicating with the BeoPort. If, so I would assume that one ought to be able to capture the ML-commands going back and forth.
kimhav:one make the assumption that it blindly passes all the masterlink data through to the USB
That's not the case. Some messages are addressed to the BeoPort itself, such as for changing the volume on the speakers connected to it. Some other messages are ML messages. You can send what you want to ML, but you only receive messages addressed to the ML address of the BeoPort. You do not get messages addressed to the TV for example.
So what you say is that even if i tag a message to be received to the BeoPort the BeoPort has checks whether it's a valid message or not? I would follow that the BeoPort only would pass through what has been tagged to it; but if it doesn't have the possibility to verify whether it's a valid message; then it would pass through what ever would be sent to it.
Of course skipping the BeoPort and hock directly up the ML-network is another story which would be the preferred one as there woouldn't be any limitations of what one can do.
riverstyx:Yes, I looked at this a while ago, but didn't have much spare time available at the time and I then ended up buying a MLGW which removed much of the incentive to investigate further.
Same problem here. Only very little time for such a project. But it is a nice challenge. Buying an PC2 or MLGW would be too boring for me...
Maybe the simplest solution would be to make an RS485 IC work on that voltage. Most of them are rated to accept incoming signals down to +- 200mV. So we would need some modifications on the transmitting part... Next time I order components I will include one and report my findings here.
Best regards,BeoMotion.
While on the topic; but have any of you read anything about the Almando units:
http://almando.com/index.php/almando-category/masterplay-masterlink-konverter/almando-masterplay.html?___store=endkunde_eng&___from_store=endkunde_eng#prettyPhoto
kimhav: While on the topic; but have any of you read anything about the Almando units: http://almando.com/index.php/almando-category/masterplay-masterlink-konverter/almando-masterplay.html?___store=endkunde_eng&___from_store=endkunde_eng#prettyPhoto
Yes, I think they introduced this adapter about one year ago.
If you watch the video or read the manual it says that you have to activate the timer function of e.g. a BL3500.Further more you will need one MasterPlay per ML device. So I think that there is not a lot ML communication involved.
As far as I remember you can only connect that device to your e.g. BL3500 or the "real" MasterLink system. Not both.
I didn't look into that timer stuff on the ML bus yet. Maybe there is one simple command that triggers the speaker to switch on/off.
BeoMotion:Maybe the simplest solution would be to make an RS485 IC work on that voltage. Most of them are rated to accept incoming signals down to +- 200mV. So we would need some modifications on the transmitting part... Next time I order components I will include one and report my findings here.
I added a few MAX3280E to my most recent RS order so will let you all know how I get on with that (it's an RS485 receiver only, so little risk of doing any damage to anything else connected to the masterlink bus)
I've also been studying the service manual for the Ouverture as I have an original hardcopy and the schematics are pretty comprehensive. Unlike many other products there is no ML ASIC in use here, it is all discrete components connecting the ML bus to the "masterlink microcomputer" (an 80c32 microcontroller clocked at 11MHz). These schematics could be a pretty useful reference for the hardware side of interfacing masterlink to an arduino or Pi.
Okay, sounds great.
Very curious to hear whether an RS485 can be made working on ML...
Good luck.
Following this thread with much interest. It would be great to control a raspberry Pi media streamer via the Beo4 remote.
Lee
Hi Lee,
this can already be done!
You need an IR Receiver (IR Puck, VX 5000 IR Sensor, MCP IR Transmitter or one of the IR chips TSOP 7000, TSOP 5700) which will be connected to one GPIO Pin of the raspbery Pi. Using an B&O receiver a voltage divider ( 1K and 1K5) is necessary because the Raspberry wants only 3,3 V Signals and the B&O delivers 5V
Then using LIrC (a Linux universal IR package ) one can remote control the raspberry via IR. a Beolink Converter should also be possible to deliver the controling data at it's Audio AUX port.
More about this connecting can be found here: RaspBMC Beolink
Hope this helps
Ralph-Marcus
RaMaBo: Hi Lee, this can already be done! You need an IR Receiver (IR Puck, VX 5000 IR Sensor, MCP IR Transmitter or one of the IR chips TSOP 7000, TSOP 5700) which will be connected to one GPIO Pin of the raspbery Pi. Using an B&O receiver a voltage divider ( 1K and 1K5) is necessary because the Raspberry wants only 3,3 V Signals and the B&O delivers 5V Then using LIrC (a Linux universal IR package ) one can remote control the raspberry via IR. a Beolink Converter should also be possible to deliver the controling data at it's Audio AUX port. More about this connecting can be found here: RaspBMC Beolink Hope this helps
This is very cool. Would this also work with a BV with PUC? If so, any advice how to make this happen? Would be really cool to control my RPi connected to my BV. Thanks!!!
steve1977:This is very cool. Would this also work with a BV with PUC? If so, any advice how to make this happen? Would be really cool to control my RPi connected to my BV. Thanks!!!
Yes, you can do this too, in fact most of the standard documentation for remote control of RaspBMC (or other XBMC distributions) that can be found online would apply to using if using an IR blaster in one of the BV PUC outputs since the BV is simply emulating some other remote control in this instance (whereas direct control using a beo4 is a special case requiring different IR receiver chips due to B&O using a different carrier frequency to most other remotes). If using the PUC outputs you could even use a USB IR receiver on the Pi if you don't want to mess around with the GPIO pins - or indeed connect the IR output of the BV to one of the GPIO pins via a level shifter with no IR involved at all.
The MCE1039 PUC is a good choice, but LiRC can be configured to work with pretty much any PUC if you don't already have that one in the list and don't want to pay for a service visit to have the PUC table updated.
Thanks, this sounds great. I prefer not to go with a USB IR receiver. I actually have one and it is bigger than the whole RPi, which defeats the purpose. The GPIO pins appear tiny, so this may be a nice setup. MCE sounds like the right way to go as it should be supported by my BV out of the box? Could you point me to a GPIO pins,which is proven to work to work with an MCE PUC? Thanks!!!
steve1977:MCE sounds like the right way to go as it should be supported by my BV out of the box? Could you point me to a GPIO pins,which is proven to work to work with an MCE PUC? Thanks!!!
I can't comment on whether MCE would be included in your PUC list as they are set up according to each owners requirements, so you'd need to check whats in the PUC list on your TV - depending on which BV you have will you may either have to pay for a service engineer to update the list or if yours is one of the more recent internet connected BeoVisions you can download new PUC codes. Alternatively, as I mentioned before, xbmc is not fussy and can be configured to work with most remote controls (and therefore most PUC codes) so just work with whatever PUC codes you have available
With regard to the hardware, just google "raspberry pi gpio tsop" as there are loads of tutorials on this aspect - as a minimum you'll need an IR receiver chip - a TSOP38238 would be suitable but there are also plenty of alternatives that will work equally well. A capacitor and current limiting resistor can also be added to improve reliability and add some additional protection to the GPIO pins on the Pi.
riverstyx:My idea was to sniff ML data, spefically looking for A.MEM related commands, as a trigger to send datalink instructions to my Beogram (which is connected to the aux input of my BS9000). Because the BS9000 is in option 0 with a BV7 in option 2, all commands will cross the ML network, even in the main room, so this would be a nice way of gaining full remote control of the turntable from anywhere within the house.
It has occurred to me that since the BS9000 responds to both A.AUX and A.MEM commands (and selects the aux input in both cases), I might also be able to utilise this behaviour to effectively add an additional input (using an audio switch IC)
Think that I can share my insight here as I got a BV10 mk1 which didn't have the MCE PUC codes which had to be added; while having a service guy out from B&O I asked him to add the Apple PUC codes as well.
Once the MCE codes was installed it worked as charm with both XBMC on Win 8.1 installation using the Intel NUC CIR and same goes for OpenELEC. What did improve the usability was to get a Beo 4 with navigation button which made life much easier when it comes to navigate around in XBMC. As well, fast forward, etc, now works also directly from the Beo 4.
riverstyx: riverstyx:My idea was to sniff ML data, spefically looking for A.MEM related commands, as a trigger to send datalink instructions to my Beogram (which is connected to the aux input of my BS9000). Because the BS9000 is in option 0 with a BV7 in option 2, all commands will cross the ML network, even in the main room, so this would be a nice way of gaining full remote control of the turntable from anywhere within the house. It has occurred to me that since the BS9000 responds to both A.AUX and A.MEM commands (and selects the aux input in both cases), I might also be able to utilise this behaviour to effectively add an additional input (using an audio switch IC) Martin.
Martin,
I'm very interested in following what you are doing. I have a BeoSound 5 as audiomaster and BeoSystem 3 in the same room. I have a Beogram 3000 turntable connected to my BeoSound 5 as the A.AUX. I would really love to regain datalink control of the beogram. One thought I had was to guy a BeoMaster that has datalink and to place the BeoMaster underneath the beogram, connect it to the Beogram with the datalink cable, and have the BeoMaster respond to L.PHONO. I could then create a macro on my Beo6 to active L.PHONO when I also activate A.AUX. Here are a few thoughts running through my head:
1. I seem to recall that adding ANY older (that is, non-N.RADIO) products into the masterlink chain (even in a link room) will cause an incompatibility error when using N.RADIO or PHONO (which are actually the same).
2. I'm curious which of the BeoMasters have the capability to use the PHONO2 command. I'm wondering if there might be a way to use the PHONO2 command to control the BeoGram.
3. I think that the Lintronic code-converter could be used to turn the A.AUX command into PHONO for the purpose of controlling the BeoGram. I have no idea how to get the Lintronic to become compatible with datalink, though.
4. The preamp that I have is a third-party preamp sold by B&O over 10 years ago that is actually capable of sending datalink! It has one input and 2 outputs. I never really understood why it has 2 outputs, but now I'm intrigued that the second output might be useful in connecting a BeoMaster to control the datalink of the BeoGram while I'm using the 1st output to connect the preamp (via a din to RCA adapter) to my BeoSound 5. I suppose, though, that a datalink Y-splitter could achieve the same result.
These are just a few thoughts running through my head that I thought you might be interested in. I would be very interested in your thoughts.
Jeff
beojeff: One thought I had was to guy a BeoMaster that has datalink and to place the BeoMaster underneath the beogram, connect it to the Beogram with the datalink cable, and have the BeoMaster respond to L.PHONO. I could then create a macro on my Beo6 to active L.PHONO when I also activate A.AUX. Here are a few thoughts running through my head: 1. I seem to recall that adding ANY older (that is, non-N.RADIO) products into the masterlink chain (even in a link room) will cause an incompatibility error when using N.RADIO or PHONO (which are actually the same).
One thought I had was to guy a BeoMaster that has datalink and to place the BeoMaster underneath the beogram, connect it to the Beogram with the datalink cable, and have the BeoMaster respond to L.PHONO. I could then create a macro on my Beo6 to active L.PHONO when I also activate A.AUX. Here are a few thoughts running through my head:
I'm not sure if N.RADIO prevents the use of older equipment in a link room, as I would assume you would still be able to select the N.RADIO source with L-N.RA (or L-PHONO) from that link room but I'm not certain of this. You certainly wouldn't be able to have a masterlink main room product that responded to PHONO in a setup with an N.RADIO source though as they will both try to respond to the same command.
You could use a BeoMaster in the manner you are suggesting (with just the datalink pins connected) but it would need to remain standalone (ie not connected to the masterlink). The problem you will have though is that the later Beolink 1000 or beo4 controlled audiomasters will not respond to L-PHONO if standalone and if you program the beo6 to send PHONO instead this will switch the BM/BS5 into N.RADIO mode. Using say an ouverture in this manner could be an option as it has datalink on it's aux connection, and will switch to the aux input on receiving the A.AUX command at the same time your BS5 does - but having an Ouverture just to convert beo4 commands to datalink seems like overkill.
Using one of the older BeoMasters eg 3000, 6000, 8000 etc that used the old (pre beolink1000 / beo4) IR control codes would be an option as the beo6 could then send these codes without risk of your BS5 responding.
My plan is to connect up my Beogram 3000 to my BeoMaster 3000 and monitor what is sent over the datalink pin, I should then be able to duplicate these commands based on what is seen on the masterlink bus. My main room setup is similar to yours - I have a BV7-40 mk3 in Option 2, a BM5/BS5 as audiomaster=no, and a BS9000 as audiomaster. Providing your speakers are connected to your BS3 and not your BM5/BS5, the interface I am looking to create should work for you too.
Jeff,
I'm in the exact same situation and had thoughts along the same lines. Great project to follow. Michael at Lintronic has this information from a failed attempt to gain direct turntable control (which you may already be aware of) which might be useful reference. Particularly, the part about spying on the Powerlink dialogue.
http://lintronic.dk/appnote_beogram.pdf
It's great to see that I'm not the only person thinking about this. I'm really impressed that Michael at Lintronic documented his efforts so well. However, I had thought that the data pin of datalink was the very middle pin. Michael at Lintronic was not using the middle pin. I'm wondering if he might have confused a powerlink cable for a datalink cable.
I do think that I was mistaken about having older non-N.RADIO products in a MasterLink chain causing problems. I'm remembering now that the problem I encountered was when I had a BeoSystem 4500 in slave mode connected to the MasterLink. The BeoSystem 4500 in slave mode was what seemed to cause the incompatibility issue. However, I seem to recall another BeoWorlder mentioning that he had a BeoSystem 4500 in slave mode used in conjunction with his BeoSound 5. I don't recall that he had any similar problems.
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.
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...
BeoMotion: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: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: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: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).
riverstyx:I'd be interested in what people might want to achieve with the finished design
1) distribution of multiple audio/airplay sources to multiple roomsWould 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: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:a separate ML audio PCB
Good idea. This might bring the cost down for the ML board if someone wishes a MLGW replacement only.
BeoMotion: 1) distribution of multiple audio/airplay sources to multiple roomsWould 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: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,
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 stationinfrared 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: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: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: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:
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.