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
I would love Option 1.
And it is probably the easiest option to realize.
I only use the old Masterlink infrastructure for my Beolab 2000 and Beolab 3500. All other Beolabs are already equipped with a Raspberry Pi + HifiBerry DAC for Squeezebox / Squeezelite as a very comfortable / easy to handle multiroom audio set-up. But I am still looking for a feasible solution to connect my two Masterlink Beolabs to the Squeeze-Server.
In option 1 and 2 I see the same problems.
Maybe the best solution would be option 3. Although this is not a very easy one.I am still not that convinced about the idea adding a MCU.It would increase the BOM cost and is not very flexible in general.The only advantage I see here is that a separate MCU could boot/shutdown the linux machine as needed.
For option 3 a second UART is really needed. So why not switching to a BeagleBone Black?I think there are 5 or 6 UARTs available...
BR,BeoMotion.
Alsfeld: I would love Option 1. And it is probably the easiest option to realize.
It would be except that it would require specific modifications to the design - some audio switching with either 2 masterlink sockets on a single interface, or some mess of wires external to the design, and I'm keen as far as possible not to deviate away from creating what should be simple modular building blocks. You could choose to use a single interface in each segment (room) and loose the masterlink connections between different segments and instead stream to each room independently - you could even stream what is on the masterlink audio bus in one segment onto the masterlink audio bus in another - effectively bridging two masterlink networks over ethernet (or wifi), although there would likely be audio sync issues in this scenareo if you're trying to achieve a multi-room 'party' mode type situation.
BeoMotion:In option 1 and 2 I see the same problems.
Different problems I think, but there are fundamental issues with both of these approaches.
BeoMotion:Maybe the best solution would be option 3. Although this is not a very easy one.
I think option 3 is the right solution, it does not require me to redesign any of what I have already done or add 'hacks' to make specific scenarios possible, and is the most flexible solution. It means additional cost for those who require two independent masterlink interfaces on the same machine, but will also reduce costs for those who do not, which sounds like the right approach.
BeoMotion:I am still not that convinced about the idea adding a MCU.It would increase the BOM cost and is not very flexible in general.The only advantage I see here is that a separate MCU could boot/shutdown the linux machine as needed.
I understand your reservations, and it's something I've given a lot of thought to as I can see the downsides and benefits on both sides of the argument but I'm not sure I agree about it being not very flexible. I'm leaning towards an arduino shield formfactor for the interface (with some additional through headers for audio) for the following reasons:
BeoMotion:For option 3 a second UART is really needed. So why not switching to a BeagleBone Black?I think there are 5 or 6 UARTs available...
There are, although one is TX only and one can't be used at the same time as the HDMI overlay, but that would still leave plenty, but the BBB lacks an analogue audio output (audio out is via HDMI only) which could be a major downside for some applications. The RPi also seems to have more options with regard to DAC add-ons than the BBB (The HiFiBerry for example since it has already been mentioned, but there are others as well).
I'll outline my conclusions in more detail over the next day or two (and in particular my ideas for the audio channels and switching) but for tonight this will have to do as it's rather late and I need to sleep...
Martin.
I am afraid that here we are at a point where it is about to become to complex.
Too many boards and possibilities. It has to be more simple. A single board that is only made to be attached to a RPi or BBB. Audio should also be included. It should act similar to a BeoMedia 1. Just adding two more sources to the system + the ability to simulate some basic MLGW stuff.
Even this will consume much more time as we can imagine at this point, I believe.I really think option 3 would be a great one. The more I think about it the more I realize that the cost and time consumption would be too much...
BeoMotion: I am afraid that here we are at a point where it is about to become to complex. Too many boards and possibilities. It has to be more simple. A single board that is only made to be attached to a RPi or BBB. Audio should also be included. It should act similar to a BeoMedia 1. Just adding two more sources to the system + the ability to simulate some basic MLGW stuff. Even this will consume much more time as we can imagine at this point, I believe.I really think option 3 would be a great one. The more I think about it the more I realize that the cost and time consumption would be too much...
You are right, better to keep things simple and achieve a result. Extra complexity can be added later if time allows.
My desire to connect to arduino comes predominantly because some of the uses I have planned (for example, controlling my beogram as already mentioned) but I am also concious that connecting to a raspberry pi will allow many more possibilities.
So what I propose is that I will design an initial data only prototype (I'm pretty much there with that already - I just need to spend some time routing the PCB tracks in EagleCAD) and will have a few of these PCBs manufactured (the cost per unit drops dramatically such that having say five PCBs produced is not vastly more expensive than the cost of having one produced). I can use these to experiment, in particular I need to determine the power requirements of the -ve rail with a view to ultimately using a voltage inverter IC powered from the RPi rather than needing a dedicated PSU, and I need to work out what component changes will be required for 3.3V operation as the circuit it currently designed for 5V logic.
I can then use these initial prototype PCBs in conjunction with an arduino nano to implement my ML to datalink interface whilst using the results of my experimentation to then design a 3.3V PCB with audio for connection to a RPi.
Regarding the audio, my feeling is that the minimum requirement is 2 x stereo line in and 1 x stereo line out, with GPIO control over routing between line in / line out / ML audio bus.
In fact this also gives us the possibility of an option 4 to cover the previously discussed functionality, but this time using two Raspberry Pi's with line out of one connected to line in of the other, and ML data sent as required over ethernet between the two RPi's (or even sending the audio over ethernet too if the Raspberry Pi's were also fitted with sound cards with a Line-In in addition to the ML interfaces)
Does this sound like a reasonable way forward?
riverstyx:my feeling is that the minimum requirement is 2 x stereo line in and 1 x stereo line out
Hm, for what I have in mind I don't see any line-in / -out in my design. What is your purpose for that? Connection of external analog sources? Do you really think that this is neccessary? One analog source could always be connected via a USB soundcard.To have it simple I would use an I2S DAC with differential outputs only.
riverstyx:using two Raspberry Pi's with line out of one connected to line in of the other
I can't really understand what you have in mind here. Never ever think about using the onboard sound of the RPi. There is no codec. As far as I can remember it uses a PWM pin from the processor. Even with the cheapest speakers it sounds horrible. The only way is an USB soundcard or I2S codec. If you want input and output run simultaneously you have to use both. Streaming audio over network is not a big deal. So maybe you mean something like wireless ML?
riverstyx:for 3.3V operation as the circuit it currently designed for 5V logic
Maybe it is the best not to touch the given schematic from the Overture for the first PCB and just add a level-shifter for 5V<->3V3.Also don't forget to add as many testpoints and solder-bridges / 0R as possible for the first prototype.
BeoMotion: riverstyx:my feeling is that the minimum requirement is 2 x stereo line in and 1 x stereo line out Hm, for what I have in mind I don't see any line-in / -out in my design. What is your purpose for that? Connection of external analog sources? Do you really think that this is neccessary? One analog source could always be connected via a USB soundcard.To have it simple I would use an I2S DAC with differential outputs only.
A misunderstanding I think - I took "additional sources" in your previous post to indicate you wanted additional external sources but on re-reading I guess you were referring to sources from a beo4 perspective? eg. N.MUSIC, N.RADIO etc.. I was howerver talking about inputs / outputs from the audio part of the ML interface, and not necessarily external to the whole RPi + ML interface per se. Using the term 'line' was probably misleading on my part as what I'm actually talking about is audio-in and audio-out, but not necessarily at line levels. More about this in a moment.
BeoMotion: riverstyx:using two Raspberry Pi's with line out of one connected to line in of the other I can't really understand what you have in mind here. Never ever think about using the onboard sound of the RPi. There is no codec. As far as I can remember it uses a PWM pin from the processor. Even with the cheapest speakers it sounds horrible.
I can't really understand what you have in mind here. Never ever think about using the onboard sound of the RPi. There is no codec. As far as I can remember it uses a PWM pin from the processor. Even with the cheapest speakers it sounds horrible.
I agree, the analogue audio out of the RPi is dreadful, it was a near zero cost addition to the RPi design to allow some form of audio for those using composite video but that's about all, so I certainly have no intention of utilising it for our purposes.
BeoMotion:The only way is an USB soundcard or I2S codec. If you want input and output run simultaneously you have to use both. Streaming audio over network is not a big deal. So maybe you mean something like wireless ML?
Regardless of whether we incorporate a DAC into the design, or utilise something external such as the HiFIBerry, Wolfson card or USB DAC and/or ADC, I envisage wanting some GPIO controlled audio switching to isolate the ML audio bus from these when not in use (at least for the DAC although perhaps not for the ADC).
Wireless ML is one potential application of the end product - eg. ML audio -> ADC -> RPi1 -> WiFi -> RPi2 -> DAC -> ML audio (with the ML data being sent over WiFi between the two RPi's also) and this could be a very useful feature - the only downside being it will result in audio sync issues in a multi-room 'party mode' type situation, but this is only a downside in this usage scenario.
Add in an additional switched input, ie the 2nd audio-in I described previously (the 1st being from the DAC), and an audio out (think tape-monitor style output from ML audio bus) and you also have the option of linking the ML audio of RPi1 directly to the ML audio of RPi2 (with any data being communicated between them over ethernet/WiFi as and if required).
Either solution requires that we allow for extracting the audio from the ML bus - either to feed into the ADC or to feed via a cable to another RPi+ML interface. The decision to be made if we decide to do this is whether this is done at (a) ML bus audio levels or (b) line levels.
Option (a) requires almost zero additional BOM count - three header pins connected directly to the ML socket providing GND, ML_Audio+ and ML_Audio- output, and the same three signals as an input via an audio switching IC (to select between the DAC, external ML level audio, or neither being injected into the ML audio bus). This solution would allow for linking audio between units but would not allow for use of a standard ADC to sample the audio by the RPi (thus excluding uses such as the aforementioned wireless ML)
Option (b) is to effectively do the same thing but at line level, it means having level conversion between the ML socket and the audio switching but the by-product of this is that you then have a line-level copy of the ML-audio which can be fed into an ADC if desired (giving the RPi access to both audio output and audio input). If this option were chosen it would probably not make sense to use a DAC with balanced outputs as we would want both the DAC and the other input to be at the same level.
BeoMotion:Maybe it is the best not to touch the given schematic from the Overture for the first PCB and just add a level-shifter for 5V<->3V3.
I Agree. I've no intention of doing so at this stage as I actually want 5V logic for the initial prototype PCBs so I can make use of the with the arduino for the other uses I have in mind. The idea being though that once I have these initial prototypes I can experiment with changes to avoid the need for level shifting and additional power supply rails in the final RPi hat style design.
Edit: fixed typos
riverstyx:I guess you were referring to sources from a beo4 perspective? eg. N.MUSIC, N.RADIO etc..
Yes. I had the idea of a BeoMedia like AirPlay "injector" with some basic MLGW functionalities (e.g. AirPlay starts - switch Livingroom to N.Music). This should be one of the most useful scenarios of such a device.
I here what you are saying and this are some really good ideas.
In my opinion the next step should be reversing to protocol itself before going too much in detail here. If this target is reached and everything is fully working the next step should be the audio part.
Just tell me if you need help with reversing / testing.
BeoMotion: In my opinion the next step should be reversing to protocol itself before going too much in detail here. If this target is reached and everything is fully working the next step should be the audio part.
In my opinion the next step should be reversing to protocol itself before going too much in detail here.
If this target is reached and everything is fully working the next step should be the audio part.
I agree, no need to make final design decisions at this stage and in any case the audio part should be relatively straightforward when we do reach that point.
BeoMotion: Just tell me if you need help with reversing / testing.
Thanks, I will do. For the moment I need to concentrate on finishing the works in my lounge, then getting it plastered and decorated - then I will be able to setup my B&O system again and should also have some free time (I've almost forgotten what that feels like!) to finish the design of the initial (overture based) data only prototype.
Kind Regards,
Following this thread I thought about connecting my Raspberry I2C interface via GPIO to my Masterlink set-up and see what will happen / what I can do.
Unfortunately with "sudo i2cdetect -y 1" no connected units are shown.
So some questions, to get some ideas what to do to go further:1) Masterlink is working with I2C originally developed by Philips?2) What voltage does Masterlink use, 5V?3) What electronic device (IC) B&O uses to handle I2C-Bus?
I used the following set-up to connect Masterlink to my Raspberry PI.
Is something wrong at the wiring?
Any hint would be helpful to get further with my experiment.
Alsfeld:So some questions, to get some ideas what to do to go further:1) Masterlink is working with I2C originally developed by Philips?2) What voltage does Masterlink use, 5V?3) What electronic device (IC) B&O uses to handle I2C-Bus?
===== STOP! =====
1) No. Masterlink is NOT I2C - where did this information come from?
2) No, it is not 5V, it's 0.5V peak to peak (ie +0.25V on ML_DATA+ and -0.25V on ML_DATA-). There is some protection from over-voltage in the ML circuit design (at least on the Ouverture) but by connecting the ML lines to 3.3V or 5V you run the risk frying the ML circuitry in your B&O devices.
3) they don't - see above.
In one of my previous posts on this discussion, I posted a screen grab from EagleCAD. This is essentially the ouverture ML interface re-drawn in EagleCAD and at least at this stage should be considered the minimum requirement for interfacing masterlink to a microcontroller / microprocessor. Even then it should be noted that the circuit is designed to work with 5V logic so it would not be suitable for connecting directly to the GPIO of a RPi without further modification / level shifting.
My intention was, and still is, to take this design, and spend some time routing tracks to produce a 2 layer PCB design in EagleCAD and have some prototype PCBs fabricated (data only at this stage, I've not really even looked at the ML audio yet), but a change in my work location means I'm currently spending three hours a day travelling in addition to my normal working hours and this has eaten even further into my already rather limited spare time.
If anyone else has the skills and the time to take the schematic and produce a PCB design ready for fabrication I am happy to share the EagleCAD files as they stand at the moment, otherwise this will need to remain on the back burner for the next few months until I have more time to commit.
riverstyx:1) No. Masterlink is NOT I2C - where did this information come from?
Yes, really would like to know where he caught this up. Nobody was talking about I2C here. Hopefully everything is okay with his ML devices?
riverstyx:If anyone else has the skills and the time to take the schematic and produce a PCB design ready for fabrication I am happy to share the EagleCAD files as they stand at the moment
Time is my biggest issue, too. Nevertheless I am interested in to get it working. I am not a big friend of EAGLE and would like to start from scratch with KiCAD. Have some good experience with it and you are flexible if you want to design a bigger PCB with more than two layers.
Will keep you all updated on any progress.
BeoMotion: Time is my biggest issue, too. Nevertheless I am interested in to get it working. I am not a big friend of EAGLE and would like to start from scratch with KiCAD. Have some good experience with it and you are flexible if you want to design a bigger PCB with more than two layers. Will keep you all updated on any progress.
That's interesting - I tried KiCAD a few years ago and found it rather buggy (although EagleCAD also has more than its fair share of bugs and quirky behaviours!). Perhaps it is time for me to re-visit KiCAD as I am sure a lot will have changed in that time.
I've got an original hard copy of the ouverture service manual if you need any high resolution scans - I seem to remember the pdf copy on beoworld is a little difficult to read in places although that may have just been the PCB layouts (I was trying to trace a fault on PCB12 at the time).
I did create a pad layout for the masterlink socket based on the dimensions in the datasheet, but given the original molex part (p/n 15-83-0316) is now discontinued, I did wonder whether we ought to consider using a shielded 8P8C (RJ45) socket instead? I can check the pin designations based on the official B&O ML to RJ45 cable if we go down this route.
Thank you for the hint, that I am totally wrong.
My masterlink set-up is still working :)
Nevertheless I am searching for a way to scan the Masterlink bus. I do not want to send any information myself into the bus, only would like to read it not to write.
The pin designation B&O ML to RJ45 is here: http://www.abo-center.dk/Abo_center_2/reptips/diagrammer/Link/2009-01-29_084426_IHC_Net_til_MasterLink.jpg. I use it, because I have CAT 7 cable in my home instead of Masterlink cabel, to be more flexible in future.
riverstyx:I tried KiCAD a few years ago and found it rather buggy
It really got a lot better over the time. Now that CERN is actively contributing to the project I am sure it will even get better in future. Now differential pair routing and trace length matching is also supported.
riverstyx:I've got an original hard copy of the ouverture service manual if you need any high resolution scans
Thanks for the offer but I have those documents on my own already.
riverstyx:I did wonder whether we ought to consider using a shielded 8P8C (RJ45) socket instead?
Yes, I think this is the way to go.
riverstyx:I can check the pin designations based on the official B&O ML to RJ45 cable if we go down this route.
Okay, great. I will upload some screenshots here when the schematic + layout is finished. This way we are able to identify mistakes before the PCB is manufactured.
Alsfeld:Nevertheless I am searching for a way to scan the Masterlink bus.
You might do some testing with the MAX3280E. This is an RS485->UART receiver only IC which COULD work since it is rated to accept signals down to +-200 mV. But don't expect it to be plug-n-play. Especially not on the SW side. Never ever connect a RS485 transmitter to the ML bus!
Alsfeld:My masterlink set-up is still working :)
That's good news. I suspect that as there are higher voltages on other cores of the masterlink cable, the protection that is incorporated into the design is there in case incorrect connections are made in a masterlink junction box or shorts occur - but I wouldn't want to test that theory unnecessarily
The MAX3280E that I ordered may provide a simple means of reading the data on the bus but I haven't yet had a chance to try this out. All of my B&O equipment is now in my kitchen with the doors sealed with tape as this is the only room that is free of building dust (we're currently eating out a lot!) and works on my lounge/cinema room are progressing more slowly than anticipated as I am now getting home from work too late to achieve much in the evenings. This weekend I have been constructing a motorised projector lift and next weekend I hope to start building my suspended ceiling raft to hide this and the projector screen mechanism so even if things go smoothly it's going to be a few more weeks before everything is plastered and decorated.
BeoMotion: riverstyx:I can check the pin designations based on the official B&O ML to RJ45 cable if we go down this route. Okay, great. I will upload some screenshots here when the schematic + layout is finished. This way we are able to identify mistakes before the PCB is manufactured.
I've checked a B&O ML to RJ45 cable and can confirm the pinout is as per the diagram Alsfeld posted.
Masterlink pins 3 (ML_SENSE) and 12 (ML_V+) are joined within ML junction boxes and usually provide a means of detecting whether masterlink is connected when using the 16 pin ML plus/socket arrangement, but since these will both be presented on pin 3 of the RJ45 the ML_SENSE logic is lost (assuming we are providing power to the V+ and V- as the ouverture does). It may still be worth implementing this circuitry though as it doesn't add much to the component count and may prove useful if we discover we don't need to supply ML power ourselves in some applications.
I will need to investigate the whole ML power functionality as it is unclear how it is negotiated between video master and audio master regarding who supplies this power. The ML Handbook also indicate this ranges from +/-7V to +/-15V (or +/-3V to +/-15V in standby) but it is unclear whether this variation is significant.
I think I mentioned / suggested before about using a voltage inverter to provide the -5V rail and looking at the MX4002 service manual this is exactly what they have done (using a MAX660)
At the prototype stage it may be worth jumpering the entire +ve rail such that it can be optionally connected to the RPis 3.3V supply instead of the 5V, possibly negating the need for logic level conversion after swapping the opamp for one that will tolerate a +/-3.3V supply (the TLE2074 or TLE2084 might be suitable candidates to replace the LF347).
Thank you very much for the hint with the MAX3280E. I bought a MAX3280EAUK+T and connected it to my Raspberry and Masterlink the following way: VCC (MAX) to PIN 1 (3.3 V - PI); GND (MAX) to PIN 6 (GND - PI); RO (MAX) to PIN 15 (GPIO 22 - PI) AND A (MAX) to PIN 2 (Daten + - Masterlink); B (MAX) to PIN 1 (Daten - - Materlink) I used LIRC to “read” / “sniff” my Masterlink set-up via GPIO 22 (similar software set up as I tried with infrared receiver TSOP7000 before). I have an Audio-Master (Beocenter 2 - Option 0) and a Video-Master (Beosystem 3 - Option 2). After installing LIRC at my raspberry PI I used the command “mode2 -d /dev/lirc0” to see what signals are moving through my Masterlink set-up. The commands are pretty clear and it should not too difficult to steer the raspberry via these signals (some examples see attached zip excel sheet). All the testing so far I did with one of my Beolab 3500 within the Masterlink set-up. Some general findings: · The signals differ if addressing the Audio- or Video-Master · When changing / starting sources there are always two signals (I have no idea if one comes from the Beolab 3500 and the second one is the answer of the master) · When changing channels (up, down, number) there is only one signal (probably no answer from the master) · Many signals from the beolink4 are not passed through (e.g. volume up, volume down, light button) · When I start the Beolab 3500 (connect it to electricity) there is one signal (from the Beolab 3500 ?), after a while when the clock is adjusting there are two further signals (from the master and / or Beolab 3500?). · Turning on / off the timer at the Beolab 3500 no signal. · When I program the timer option at the Video-Master, there are 4 signals send (exchanged), when Beolab 3500 turns on. Some strange findings: · When I connect the Beolab 3500 directly to my raspberry (as described above) via Masterlink cable without an Audio or Video-Master included, I get no signals at all. I can push any button on my Beolink 4, nothing happens on the masterlink cable. The Beolab 3500 display changes to CD or Radio or whatever, but no signal on the cable. OR the singles are so week that I do not detected them. · Even when I turn on the Beolab 3500 (connecting it to electricity) no signals are detected. That is strange, somehow the masterlink network should get the information, that there is a new device. When I reintegrate my Audio- and VideoMaster I get the singles as described above (not knowing which device is sending them). Questions: · Could there be signals I do not see with my raspberry set-up, because there are some signals that are too week? · How can I send the timer turn on signal into my masterlink set-up, in order to turn on the Beolab 3500 loudspeaker via raspberry PI? Codes LIRC gelesen.zip
Thank you very much for the hint with the MAX3280E.
I bought a MAX3280EAUK+T and connected it to my Raspberry and Masterlink the following way: VCC (MAX) to PIN 1 (3.3 V - PI); GND (MAX) to PIN 6 (GND - PI); RO (MAX) to PIN 15 (GPIO 22 - PI) AND A (MAX) to PIN 2 (Daten + - Masterlink); B (MAX) to PIN 1 (Daten - - Materlink)
I used LIRC to “read” / “sniff” my Masterlink set-up via GPIO 22 (similar software set up as I tried with infrared receiver TSOP7000 before). I have an Audio-Master (Beocenter 2 - Option 0) and a Video-Master (Beosystem 3 - Option 2).
After installing LIRC at my raspberry PI I used the command “mode2 -d /dev/lirc0” to see what signals are moving through my Masterlink set-up. The commands are pretty clear and it should not too difficult to steer the raspberry via these signals (some examples see attached zip excel sheet).
All the testing so far I did with one of my Beolab 3500 within the Masterlink set-up.
Some general findings:
· The signals differ if addressing the Audio- or Video-Master
· When changing / starting sources there are always two signals (I have no idea if one comes from the Beolab 3500 and the second one is the answer of the master)
· When changing channels (up, down, number) there is only one signal (probably no answer from the master)
· Many signals from the beolink4 are not passed through (e.g. volume up, volume down, light button)
· When I start the Beolab 3500 (connect it to electricity) there is one signal (from the Beolab 3500 ?), after a while when the clock is adjusting there are two further signals (from the master and / or Beolab 3500?).
· Turning on / off the timer at the Beolab 3500 no signal.
· When I program the timer option at the Video-Master, there are 4 signals send (exchanged), when Beolab 3500 turns on.
Some strange findings:
· When I connect the Beolab 3500 directly to my raspberry (as described above) via Masterlink cable without an Audio or Video-Master included, I get no signals at all. I can push any button on my Beolink 4, nothing happens on the masterlink cable. The Beolab 3500 display changes to CD or Radio or whatever, but no signal on the cable. OR the singles are so week that I do not detected them.
· Even when I turn on the Beolab 3500 (connecting it to electricity) no signals are detected. That is strange, somehow the masterlink network should get the information, that there is a new device. When I reintegrate my Audio- and VideoMaster I get the singles as described above (not knowing which device is sending them).
Questions:
· Could there be signals I do not see with my raspberry set-up, because there are some signals that are too week?
· How can I send the timer turn on signal into my masterlink set-up, in order to turn on the Beolab 3500 loudspeaker via raspberry PI?
I'm abroad at the moment so will reply in more detail once home again, but great to hear the MAX3280 works for reception.
The beolab 3500 (no transmission) behaviour is expected, as the audio or video master would be responsible for supplying the bus power to the ML_DATA + and - lines. Slave devices will then pull these lines to ground to transmit, so without a master the 3500 cannot transmit anything. It will be possible to supply this power but would also need to analyse the other behaviours in a timer on scenario and emulate those too, and obviously the MAX IC can't be utilised for transmission.
Alsfeld:Thank you very much for the hint with the MAX3280E.
Hi Alsfeld,
thanks a lot for trying and reporting this!I ordered some MAX3280E a while ago but never unpacked them.
Your findings finally gave me the kick to build a little dead-bug breakout board for one of them and hook it in between a BS3200 and a Rpi. I connected the MAX to the UART RX of the PI.I didn't even knew that it is possible to use LIRC as a kind of logic analyser...But I don't think that we really have to use such very "raw" data since the ML protocol is similar to a standard serial protocol. Instead it should be possible handling hex data.
Look what I found out with my setup. I used a little quick-n-dirty python program for grabbing this data. It is totally unchecked as I don't have enough time today. I will come back in the next days an try to analyse this raw data.BR,BeoMotion.
CD track 1->2: 3e 7d fa ae fe ca f9 e2 a9 ee ca 69 fe fe fe de fa 02 09 64 02 d9 fa 02 09 24 90 40 80 01 02 09 14 cf 00
CD track 2->3: 3e 7d fa ae fe ca f9 e2 a9 ee ca 69 fe fe fe de fa 02 09 24 02 d9 fa 02 09 24 90 40 80 01 02 09 f4 e7 00
CD->RADIO: 3e 7d fa ae fe ca f9 e2 a9 ee ca e9 fe fe fe fe fa 02 09 24 02 d9 fa 02 09 24 90 40 80 01 02 09 f4 cf 00 3e 7d f4 ae fe 42 fe e2 a9 ee 42 fa fe fe fe 06 fa fa fe fa fa f6 fa 02 09 24 90 40 80 01 02 09 54 cd 00
RADIO 1->2: 3e 7d fa ae fe 42 fe e2 a9 ee 42 fa fe fe fe de fa fa fe f6 fa f6 fa 02 09 24 90 40 80 01 02 09 e4 e4 00
RADIO 2->3: 3e 7d fa ae fe 42 fe e2 a9 ee 42 fa fe fe fe de fa fa fe f2 fa f6 fa 02 09 24 90 40 80 01 02 09 a4 e4 00
RADIO->CD:3e 7d fa ae fe 42 fe e2 a9 ee 42 fa fe fe fe 06 fa 02 09 24 90 40 7e 80 01 02 09 24 90 40 80 01 02 7d f3 00 3e 7d fa ae fe ca f9 e2 a9 ee ca e9 fe fe fe de fa 02 09 24 90 40 7f ff 01 02 09 24 90 40 80 01 02 b9 fe 00 3e 7d fa ae fe ca f9 e2 a9 ee ca e9 fe fe fe fe fa 02 09 24 90 40 7f ff 01 02 09 24 90 40 80 01 02 9d fe 00 3e 7d fa ae fe ca f9 e2 a9 ee ca 69 fe fe fe de fa 02 09 24 02 d9 fa 02 09 24 90 40 80 01 02 09 f4 e7 00
I should be able to help... I'll look into LinkPlayer's code, and see wether this matches the code I received through the BeoPort...
Beoworld app with direct photo upload and emoticons.
PhilLondon: I should be able to help... I'll look into LinkPlayer's code, and see wether this matches the code I received through the BeoPort...
That would be great. Maybe BeoPort's MCU is working like some kind of uart-usb bridge that passes through the raw ML data?
There are 2 type of messages... some messages are going from the PC to the Beoport (or BeoPort to PC), and some messages are ML messages passed through. I'll be checking them against the codes you sent to see if they match.
P.
Okay, thanks.
Just compared my sequences with the ones that were already posted some time ago on the forum. For some reason they look completely different...
I think before we can go any deeper into analyzing this I need to verify the output of my python program with a logic analyzer.
P.S. I edited my initial post and added two useful links and a current state description. Should then be easier for new readers to follow this...
Great work guys.
BeoMotion: Just compared my sequences with the ones that were already posted some time ago on the forum. For some reason they look completely different... I think before we can go any deeper into analyzing this I need to verify the output of my python program with a logic analyzer.
Yep, that output does look unexpected, the data posted previously on the forum seems to correlate with the screenshot in the 'using MLGW as ML-logger' document so I would assume it is indeed what we should be expecting to see.
A couple of thoughts:
I wonder perhaps whether the logic levels signalling the mark/space of the serial data are inverted? I think when I looked at the datasheet of the MAX3280E I figured A and B would need to be connected to ML_DATA+ and - the opposite way around to how it would usually be used with RS485 in order to function, as the logic switching thresholds were negative and both ML_DATA lines are simply pulled to ground on transmit (as opposed to RS485 where the lines both invert polarity) but I didn't get as far as working out whether the output polarity would be correct or inverted.
or:
You mention you've connected a BS3200 to the MAX3280E - do you have anything else connected to the masterlink? If there is nothing else connected I'm wondering whether each of the communications you're seeing is just failed efforts by the BS3200 to establish comms / announce its presence on the masterlink bus (with a new attempt being triggered each time some event occurs) rather than the data that would be seen once other devices are present. It might be worth connecting a second device and seeing if the output is still the same.
Regarding transmitting data, I was thinking a pair of open collector outputs and a pull down resistor may be all that is required, just to pull both ML_DATA lines to ground - perhaps an SN7407 for example.
Today I wired it up between a BV7 and a BS/BM5.Still the same confusing output.
It always starts with 0x3E which is 0011 1110 in binary.But it should be 0x83 which is 1000 0011 in binary. Well, looks a bit like LSB/MSB problem + swapped endianness + swapped high/low.
Tomorrow I will compare ML DATA with the output of the MAX using a scope and a logic analyzer.I think this will bring a bit more light into the problem.
BeoMotion:It always starts with 0x3E which is 0011 1110 in binary.But it should be 0x83 which is 1000 0011 in binary. Well, looks a bit like LSB/MSB problem + swapped endianness + swapped high/low.
I also thought about endianness but reckoned this was unlikely as the previous tests were conducted at the output of the ML_ASIC which only replicates the functionality of the ouverture receiving circuit with a reduced BOM - one of the MX service manuals shows both versions of the receiving circuit (ie ML_ASIC or ouverture type) depending on production date.
Comparing the binary of 0x83 0xC1 0x01 which seems most common in previous logs, vs your received 0x3E 0x7D 0xFA, I think it is probably just inverted high/low logic, with the byte boundaries being shifted around a little due to any inverted start or stop bits or gaps also being misinterpreted. The binary of each of these looks broadly correct in the middle of each byte if you invert the bits and ignore the shift to the left or right.
Obviously if you can compare things with a scope/LA then it should be possible to confirm this.
riverstyx:I think it is probably just inverted high/low logic, with the byte boundaries being shifted around a little due to any inverted start or stop bits or gaps also being misinterpreted.
Yes, you are totally right.Connected a logic analyzer today and immediately saw this.Switched over to inverted mode and all values were like expected.
Tomorrow I will connect a little inverting logic to the output of the MAX which should solve the issue within the Raspberry.
Here is what the LA showed up when selecting the TV source:
83 C0 01 14 00 0B 00 87 1F 04 0B 01 00 00 00 00 01 01 00 00 01 02 02 00 00 01 01 01 02 00 02 00 00 00 00 00 00 00 00 00 00 27 00
That's better!
The first byte is the recipient. The second is the sender.
VIDEO_MASTER = C0, AUDIO_MASTER = C1, SLAVE_DEVICE (Beoport or BeoMedia) = C2, ALL_LINK_DEVICES = 83
The 8th byte (87) is the command type. This one is a status message.
GOTO_SOURCE=0x45, DISTRIBUTION_REQUEST=0x6C, PC_PRESENT=0x96, STANDBY=0x10, RELEASE=0x11, TIMER=0x3C, BEO4_KEY=0x0D, MASTER_PRESENT=0x04, CLOCK=0x40, TRACK_INFO=0x44, TRACK_INFO_LONG=0x82, STATUS_INFO=0x87, DVD_STATUS_INFO=0x94
The 11th byte (0B) is the source.
TV = 0B, SAT = 1F, VMEM = 15, DVD = 29, PC = 47, V_AUX = 33, V_AUX2 = 3E, CAMERA = 00, CD = 8D, RADIO = 6F, AMEM = 79, A_AUX = 97, NRADIO = A1, NMUSIC = 7A
Byte 20 is the channel number. Here 00, as you're probably on an external STB.
Byte 25 is the state UNKNOWN=00, STOP=01, PLAYING=02, FASTFORWARD=03, REWIND=04, RECORD_LOCK=05, STANDBY=06, LOAD=07, STIL_PICTURE=08, SCAN_FORWARD=14, SCAN_REVERSE=15, BLANK_STATUS=FF
Oh and I forgot... the last byte before the last 00 is a checksum.
spezializten:Phil, what have happened to Linkplayer 2? I'm just curious about the status. I'm still using it with very good results. /Björn
/Björn
Björn, could you open a new thread for this please? There is already quite a lot of detailed discussion / information on this thread relating to a very specific topic and I'm keen that it does not end up wandering off topic as this will make it much more difficult to refer back to and find relevant information for those working on this project.
BeoMotion: riverstyx:I think it is probably just inverted high/low logic, with the byte boundaries being shifted around a little due to any inverted start or stop bits or gaps also being misinterpreted. Yes, you are totally right.Connected a logic analyzer today and immediately saw this.Switched over to inverted mode and all values were like expected.
That's excellent news - it seems then we have a cheap and simple way to receive data from the ML bus which for some applications may be all that someone needs, and should in any case aid with the reverse engineering of the protocol.
PhilLondon: Oh and I forgot... the last byte before the last 00 is a checksum.
Phil, thank you for all of the information. It's much appreciated.
It has also enabled me to confirm that much of the MLGW protocol is, as I expected, pretty much unmodified ML data.
The MLGW protocol documentation can be found here:
http://mlgw.bang-olufsen.dk/source/documents/mlgw_2.24b/MlgwProto0240.pdf
riverstyx: It has also enabled me to confirm that much of the MLGW protocol is, as I expected, pretty much unmodified ML data. The MLGW protocol documentation can be found here: http://mlgw.bang-olufsen.dk/source/documents/mlgw_2.24b/MlgwProto0240.pdf
I am also familiar with the MLGW protocol. They share the same codes for sources, keys, states, but the rest is totally different. The MLGW greatly simplify the messages.
PhilLondon:I am also familiar with the MLGW protocol. They share the same codes for sources, keys, states, but the rest is totally different. The MLGW greatly simplify the messages.
Sorry Phil, you're right of course - "unmodified" was a poor choice of word on my part, "repackaged" would probably have been closer, and as well as the MLGW only communicating a subset of the raw masterlink data there are obviously additional telegram types defined within the MLGW protocol to deal with MLGW <-> 3rd party communication which will be of no relevance when dealing with the masterlink comms directly, but the document should in any case prove a useful reference for the parts that are common to both protocols.
On a separate note, there was for some time a section/link for the beonet protocol on the beointegration site, which stated 'not yet published' - which I had hoped was an indication that B&O were intending to publish this at some stage, but this has now been removed and I've had a response from beocare when I asked about it stating:
"I'm sorry but the information on Beointegration is wrong. We will not release our beonet protocol. Instead we are working with control system partners and let them build a driver to control Bang & Olufsen products.Currently we have drivers for Crestron, Control4 and Savant."
I don't currently own any beonet products but this is still disappointing as I had hoped to be able to write some code to provide control of beonet products without having to resort to further reverse engineering efforts first.
Again, thanks for all that info.
Today I built the inverting logic and connected it between the MAX and the Raspberry.And viola - it works like a charm now :-)
Now we can start to understand how the protocol works. No need for EOL components like BeoPort etc. Just some simple standard components for little money.See the attached schematic and feel free to use it on your very own risk. It is connected to a Raspberry Pi and now part of my setup. So I can use SSH to log and see all the ML data without touching a single wire.
There is a lot to understand. Especially when selecting RADIO or CD from BS5 a lot of data is going through the bus. Might be due to meta data like station and track names in this case. I won't post this here since it is really "a lot" of data. I may upload it to e.g. pastebin and link it here for further analyzing later. Even when pressing standby it is much more data then a simple status sequence.
Here is a little cut out from my recent dump. Test setup is [ BV7 (OPT.2) ] <-> [ BS5 (OPT.0) ]
System is playing A.AUX. Beo4 - CURSOR UP:
c1 c0 01 0a (from v.master to a.master ?)00 00 00 0d 03 01 97 1e 02 54 00 (the up command ?)c1 c0 01 0a 00 00 00 0d 03 01 97 7e 02 b4 00 (the release command ?)
System is playing A.AUX. Beo4 - CURSOR DOWN:
c1 c0 01 0a 00 00 00 0d 03 01 97 1f 02 55 00 c1 c0 01 0a 00 00 00 0d 03 01 97 7e 02 b4 00
System is playing A.AUX. Beo4 - STOP:
c1 c0 01 0a 00 00 00 0d 03 01 97 36 02 6c 00 c1 c0 01 0a 00 00 00 0d 03 01 97 7e 02 b4 00
System is playing A.AUX. Beo4 - PLAY:
c1 c0 01 0a 00 00 00 0d 03 01 97 35 02 6b 00 c1 c0 01 0a 00 00 00 0d 03 01 97 7e 02 b4 00
One step volume up via BS5 wheel:
c0 c1 01 0a 00 47 00 20 05 02 00 01 ff ff 60 59 00
One step volume down via BS5 wheel:
c0 c1 01 0a 00 47 00 20 05 02 00 01 ff ff 64 5d 00
BeoMotion: System is playing A.AUX. Beo4 - PLAY: c1 c0 01 0a 00 00 00 0d 03 01 97 35 02 6b 00 c1 c0 01 0a
c1 c0 01 0a 00 00 00 0d 03 01 97 35 02 6b 00 c1 c0 01 0a
Indeed these are simulated key presses (8th byte = 0D). Going from the Video system (C0) to the Audio system (C1).
The 11th position is the source (97 = A,AUX),
The 9th position is (i think) how long presses are handled (either sending repeated keypresses, or sending a KEY_RELEASE code when the key is released).
The 12th position is the key code. 35 = Play.
I posted another message earlier but it ended up in Moderation for some reason. I guess it will probably appear in due course but there was nothing of any real significance so doesn't matter if it doesn't.
Anyway, thanks for the schematic and the sample data. I'm going to start writing some code to translate some of the captured data into a more human readable form (based on the information provided by Phil and in the old post from psand) so that we can hopefully work out which attributes are already understood and which require further investigation. Whilst most of my system is still stacked up in the kitchen I do have an old avant and an ouverture still in use upstairs so I will reconfigure these as audio and video masters and try and capture some data from those - I would expect much less status related traffic from those given their age (and lack of MLGW compatibility) but a simpler data set might be good to start with anyway.
If you are able to upload the dumps you have taken somewhere that would be useful as it will give me some more data to test my code.
Cheers,
PhilLondon: Indeed these are simulated key presses (8th byte = 0D). Going from the Video system (C0) to the Audio system (C1). The 11th position is the source (97 = A,AUX), The 9th position is (i think) how long presses are handled (either sending repeated keypresses, or sending a KEY_RELEASE code when the key is released). The 12th position is the key code. 35 = Play.
Yes, this makes sense. Thanks.Just re-formatted the codes above that it is more clear to see that we have two sequences on each key press. The second one being the release command.
Here is what happens when pressing standby when the system is already in standby:
c2 c0 01 0a 47 00 00 11 04 02 00 00 01 02 ee 00 83 c0 01 14 00 0b 00 87 1f 04 0b 01 00 00 40 00 01 ff ff ff ff 06 ff 01 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 54 00 2b c0 01 14 00 29 00 87 1f 04 29 01 00 00 00 00 01 00 00 01 ff 00 02 02 ff ff 00 ff 00 00 ff ff 00 00 00 00 00 00 00 00 00 fd 00 83 c0 01 14 00 29 00 87 1f 04 29 01 00 00 00 00 01 00 00 01 ff 00 02 02 ff ff 00 ff 00 00 ff ff 00 00 00 00 00 00 00 00 00 55 00
riverstyx:Anyway, thanks for the schematic and the sample data. I'm going to start writing some code to translate some of the captured data into a more human readable form (based on the information provided by Phil and in the old post from psand) so that we can hopefully work out which attributes are already understood and which require further investigation. Whilst most of my system is still stacked up in the kitchen I do have an old avant and an ouverture still in use upstairs so I will reconfigure these as audio and video masters and try and capture some data from those - I would expect much less status related traffic from those given their age (and lack of MLGW compatibility) but a simpler data set might be good to start with anyway.
Okay, sounds great.
riverstyx:If you are able to upload the dumps you have taken somewhere that would be useful as it will give me some more data to test my code.
I will do some additional dumps over the next days and upload them elsewhere but here is a first start. Very curious about how the addressing stuff works...
System was Playing N.Radio and then pressed CD:
c1 c0 01 0b 00 00 00 04 03 04 02 01 00 9b 00 c0 c1 01 14 00 00 00 04 03 04 01 01 01 a4 00 c1 c0 01 0b 00 00 00 45 0d 01 02 8d 00 02 01 00 01 00 00 00 03 02 00 78 00 c0 c1 01 14 00 00 00 44 0d 07 02 6f 00 02 01 00 02 00 00 00 00 00 8d f1 00 c1 c0 01 0a 00 00 00 10 03 03 01 00 02 a5 00 83 c1 01 14 00 8d 00 87 1f 04 8d 01 00 00 1f be 01 00 00 00 ff 02 01 00 03 01 01 01 03 00 02 00 00 00 00 01 00 00 00 00 00 0a 00 c0 c1 01 14 00 00 00 44 08 05 02 8d 00 02 01 00 00 00 79 00 c0 c1 01 14 00 00 00 82 0a 01 06 8d 00 02 00 00 00 00 00 01 b9 00 83 c1 01 2c 00 8d 00 06 11 00 03 01 01 00 00 43 44 20 20 20 20 20 20 20 20 20 20 e1 00 83 c1 01 2c 00 8d 00 0b 11 00 01 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 50 6f 70 ca 00 83 c1 01 2c 00 8d 00 0b 1c 00 02 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 20 2d 20 53 69 6e 67 6c 65 5d 00 83 c1 01 2c 00 8d 00 0b 12 00 03 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6b 6f 6e 27 00 83 c1 01 2c 00 8d 00 0b 13 00 04 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 87 00 83 c1 01 2c 00 8d 00 0b 13 00 05 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 4b 45 49 4e 45 0d 00 83 c1 01 2c 00 8d 00 0b 15 00 06 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 55 6e 6b 6e 6f 77 6e 94 00 83 c1 01 2c 00 8d 00 06 11 00 03 01 01 00 00 43 44 20 20 20 20 20 20 20 20 20 20 e1 00 83 c1 01 2c 00 8d 00 0b 11 00 01 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 50 6f 70 ca 00 83 c1 01 2c 00 8d 00 0b 1c 00 02 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 20 2d 20 53 69 6e 67 6c 65 5d 00 83 c1 01 2c 00 8d 00 0b 12 00 03 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6b 6f 6e 27 00 83 c1 01 2c 00 8d 00 0b 13 00 04 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 87 00 83 c1 01 2c 00 8d 00 0b 13 00 05 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 4b 45 49 4e 45 0d 00 83 c1 01 2c 00 8d 00 0b 15 00 06 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 55 6e 6b 6e 6f 77 6e 94 00 83 c1 01 2c 00 8d 00 06 11 00 03 01 01 00 00 43 44 20 20 20 20 20 20 20 20 20 20 e1 00 83 c1 01 2c 00 8d 00 0b 11 00 01 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 50 6f 70 ca 00 83 c1 01 2c 00 8d 00 0b 1c 00 02 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 20 2d 20 53 69 6e 67 6c 65 5d 00 83 c1 01 2c 00 8d 00 0b 12 00 03 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6b 6f 6e 27 00 83 c1 01 2c 00 8d 00 0b 13 00 04 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 41 6e 67 65 6c 87 00 83 c1 01 2c 00 8d 00 0b 13 00 05 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 4b 45 49 4e 45 0d 00 83 c1 01 2c 00 8d 00 0b 15 00 06 00 01 01 7a 05 00 00 00 ff 00 ff 00 01 55 6e 6b 6e 6f 77 6e 94 00