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
BeoMotion: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...
Great, thanks.
BeoMotion: System was Playing N.Radio and then pressed CD: c1 c0 01 0b 00 <snip>
System was Playing N.Radio and then pressed CD:
c1 c0 01 0b 00 <snip>
What is your system setup in this instance? I presume since you mention pressing CD is more than just the BV7 and BM5/BS5 connected, or is 'CD' the BS5 ripper?
Kind Regards,
Martin.
Ok, so my code so far just decodes the headers (first 11 bytes) of each telegram and puts names to the values where these are known or [???] where they are unknown. In addition it computes the checksum and confirms this matches.
I haven't got as far as even attempting to decode the payload section of the messages and the code to do so will take a little more work as there are numerous cases involved depending on the message type, but what I have done out of interest is convert the hex to ascii where the hex value is 0x20 or above. This alone has yielded some results and should hopefully assist in determining the meaning of some of the unknown message parameters.
Attached is the output so far based on the dump provided by BeoMotion for "System was Playing N.Radio and then pressed CD:"
*Edited to remove output from message and include it as an attachment instead - post was too long and ruined by auto smilies
riverstyx:What is your system setup in this instance? I presume since you mention pressing CD is more than just the BV7 and BM5/BS5 connected, or is 'CD' the BS5 ripper?
riverstyx:Ok, so my code so far just decodes the headers (first 11 bytes) of each telegram and puts names to the values where these are known or [???] where they are unknown. In addition it computes the checksum and confirms this matches.
riverstyx: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.
BR,BeoMotion.
BeoMotion:Sorry, my description was a bit confusing. It was still the same setup [ BV7 (OPT.2) ] <-> [ BS5 (OPT.0) ] .Source RADIO (webradio) was playing and I pressed CD (internal HDD of BS5) on Beo4.
Ah, I'd forgotten that it was possible to change the source name mapping on the BS5 - I'm used to them being N.RADIO and N.MUSIC respectively. Mine is configured as AudioMaster=No and I think that removes the option to change the source names, but in any case it wouldn't make much sense for me to do so as my BS9000 responds to CD and RADIO.
BeoMotion:This really looks awesome! Thanks for the work you are putting in.
I'll make a start soon on decoding some of the payload data too, although probably not until the weekend, as in hindsight, coding until 4:30am last night when I had to leave for work at 7am was probably not such a good idea!
Luckily I had quite an easy day at work today
BeoMotion:I think I am going to add a little webserver to my python program so that it is even easier to capture and see the messages.
That sounds like a good plan.
I was thinking that once I've made some more progress on decoding the full telegram with the data we are already capturing, I will look at writing a capture program with the ability to log data remotely - perhaps via syslog, as that would enable us to pool data captured from a number of different setups resulting in a larger data set to analyse and test against. Perhaps even allowing others to contribute data from their system if they wished to do so.
BeoMotion:It should be a good idea to put our work on github. I think we don't want to convert closed source to another closed source.
I agree, and I've made an effort to keep my code relatively simple and tidy so that it should be reasonably obvious to others what is going on even if they're not overly familiar with Perl. The bit I've implemented so far has been quite straightforward anyway as the headers are the same for all telegram types, but the payload data is likely to be more complicated to decode as there will be many different possible scenarios depending on the type of telegram being analysed.
riverstyx:coding until 4:30am last night when I had to leave for work at 7am was probably not such a good idea!
Oh yes, I know this too good. :-)
Now I also reached the point where my program is able to extract and decode a single telegram out of a sequence on the fly. Maybe now we should start trying to send data to the bus to validate our interpretation of the data.
riverstyx: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.
I will try this.
BeoMotion: riverstyx: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. I will try this.
Having thought about it a little more I'm not sure this will work, I don't know the internal design of the 7407 but there are two potential issues:
1) The fact that MLDATA- will be at negative potential relative to ground.
2) The internal resistance of the 7407 May be too high to pull such small signals close enough to ground.
A pair of FETs is probably a better solution.
I thought about this again and also looked at the schematic once more.
Maybe we shouldn't try this since this would be a very dirty solution as all other devices are using a virtual ground between the +- 5V rails for this.
It is a better practice if we would take the transmitting circuit as it is and just add that MAX3280E for receiving.
Maybe I start designing a PCB for this over the weekend.
BeoMotion:Maybe we shouldn't try this since this would be a very dirty solution as all other devices are using a virtual ground between the +- 5V rails for this
Yeah, I'm inclined to agree.
BeoMotion: It is a better practice if we would take the transmitting circuit as it is and just add that MAX3280E for receiving. Maybe I start designing a PCB for this over the weekend.
That would be great. I haven't yet got around to building the receiving circuit yet as I'm awaiting delivery of the mosfet - I was waiting to add them to a larger order until I remembered RS have recently removed their minimum order value requirement for free delivery
I'm going to continue with decoding as much as I can from the various payload types - I've got at least 16 different payload types so far that are either mentioned in the archives or that I've encountered in the captured data you posted, some of which are (at least partly) self explanatory and some of which are quite cryptic.
If you've got any more logged data I can work with that would be useful, I'll pm you my email address and you can either email them across to me or drop me a link to download them if you have anything further I can use at this stage.
For payload type 0x0b I have the following data:
'Pop' # genre?'Angel - Single' # album'Akon' # artist'Angel' # track'KEINE' # ???'Unknown' # ???
Could you take a look at the tags for that audio file and see if it is apparent how each of the items map to those?
Cheers,
Martin
riverstyx:If you've got any more logged data I can work with that would be useful
I will connect a BL Passive to the setup and capture some more data this evening. I am interested in how that slave addressing and controlling works...Of course I will also give you access to the captured data.
riverstyx:Could you take a look at the tags for that audio file and see if it is apparent how each of the items map to those?
Yes, looks very good so far. I still have to try some other songs to find out for what the two unknown descriptions are standing for.
riverstyx: until I remembered RS have recently removed their minimum order value requirement for free delivery
Okay, maybe I have to switch from Farnell to RS for smaller orders. Didn't know that there is no minimum order value at RS :-)
More to come in a couple of hours...
BeoMotion:I will connect a BL Passive to the setup and capture some more data this evening. I am interested in how that slave addressing and controlling works...Of course I will also give you access to the captured data.
Perfect, thanks.
BeoMotion:Yes, looks very good so far. I still have to try some other songs to find out for what the two unknown descriptions are standing for.
It may be worth taking a look at the ID3 tags (or equivalent depending on the format of the audio file) to see whether those are simply extracted straight from there. 'KEINE' I think is 'no' in german, and 'unknown' is actually a string in the data so may be something that the BM5 has inserted because of an empty tag, or there may actually be a tag with 'unknown' as it's value.
BeoMotion:Okay, maybe I have to switch from Farnell to RS for smaller orders. Didn't know that there is no minimum order value at RS :-)
They used to do free delivery for all orders years ago, then introduced a minimum order value (was 20GBP), but around a month ago removed this for online orders from account customers. I still feel a little guilty when, for example, last week I placed an order for 22 pence, given it will cost them around 50 pence in postage, but hey, it was their choice to offer this ;-)
riverstyx:It may be worth taking a look at the ID3 tags (or equivalent depending on the format of the audio file) to see whether those are simply extracted straight from there. 'KEINE' I think is 'no' in german, and 'unknown' is actually a string in the data so may be something that the BM5 has inserted because of an empty tag, or there may actually be a tag with 'unknown' as it's value.
Just tried some other songs and also some webradio stations. There is always "KEINE" (yes, I'm from Germany) and "UNKNOWN" at payload value 00 05 and 00 06. Don't know what this is for. Maybe some spare values...
See the attached file. A radio station was playing and I pressed the RADIO button once more.I also noticed that the status telegrams are always sent twice...
ml_log.txt
And the decoded version of the data.
ml_log_decode.txt
Still the same setup [BV7 OPT2] <-> [BS5 OPT0]Output after power cycle of TV: ml_log_reset_VM.txt
Now I unplugged the BS5 and connected a BL Passive instead.Output after power cycle of TV: reset_TV_only_passive_connected.txtBL Passive pressed PLAY on the IR eye for the first time (TV source was activated then): passive_first_play_tv.txt
BeoMotion:Just tried some other songs and also some webradio stations. There is always "KEINE" (yes, I'm from Germany) and "UNKNOWN" at payload value 00 05 and 00 06. Don't know what this is for. Maybe some spare values...
Ok, thanks, I'll maybe try creating an mp3 with all the ID3 tags set to their field names to see if I can narrow this down. One possibility I thought of are the existence of separate album and album_artist tags, the latter of which are often only populated for tracks which are part of a compilation.
BeoMotion:And the decoded version of the data.
One thing to note, I got the header details slightly wrong as I misinterpreted what psand had said in his post in the archived thread (he mentioned the payload_version_minor byte, then said the last byte of the header was payload version, but was actually talking about the same byte, rather than an additional one, which is how I initially interpreted it). The header is therefore only 10 bytes long, not 11. What I labelled as Payload Version Major is in fact the first byte of the payload itself and it's meaning depends on the type of payload - it's sometimes the souce (like in psands example) but not always.
Thank you for the additional logs. I'll have a proper look at them tomorrow. If you get a chance, could you take some logs with the inbuilt DVD or blueray of the BV7 if yours has one as there is a DVD_STATUS_INFO payload type which I am hoping would then be generated.
riverstyx:The header is therefore only 10 bytes long, not 11.
riverstyx:Thank you for the additional logs. I'll have a proper look at them tomorrow. If you get a chance, could you take some logs with the inbuilt DVD or blueray of the BV7 if yours has one as there is a DVD_STATUS_INFO payload type which I am hoping would then be generated.
BeoMotion:Maybe I start designing a PCB for this over the weekend.
Okay, the schematic for my design is nearly finished. The only part that is still missing is the master/slave logic at the moment.
I added following parts:- inverting DC/DC converter for the -5V rail (TPS6735)- 3V3 -> 5V level converter for the UART TX consisting of two MOSFETs- RJ45 ML connector with two integrated LEDs that will light up on RX/TX activity- 40 pin RPi connector
If there is some space left over on the board I will also add a DAC so that we have a one-for-all solution on a single PCB.
I am quite busy over the next days so I don't know whether I will have the time to continue my work next week...
How many Beoworlders are interested is such a PCB for connecting a Raspberry Pi to your MasterLink system?
Hi,
i follow this thread since the beginning and would be very interessted in a PCB for connecting a Raspberry Pi to Masterlink
My current setup is a BV 3-32 MK1, BS9000 MK1 (NetMusic compatible), BeoMedia 1 (with Twonky Server installed for DLNA compatibility), BeoLab 2000. The BS900 could be changed to a BS2500 with Beolink Converter if it would be necessary for testing.
Greetings from Munich
Ralph-Marcus
BeoMotion:Okay, the schematic for my design is nearly finished.
Excellent work, well done.
If possible could you add an additional pair of pads such that the serial RX of the pi can optionally be linked to another GPIO input as this will enable me detect whether the attached masterlink device is driving the bus (supplying power to MLDATA+ and MLDATA- ) which will hopefully assist with working out the logic for ML_MA/SL.
BeoMotion:I am quite busy over the next days so I don't know whether I will have the time to continue my work next week...
Take your time. No need to hurry. I'm probably going to take a few days break from coding too as I'm busy again at work and I need to catch up on lost sleep...
BeoMotion:How many Beoworlders are interested is such a PCB for connecting a Raspberry Pi to your MasterLink system?
Put me down for 5 or 6 of the PCBs and I can populate them as much or as little as I need to for the reverse engineering efforts.
It might be worth starting a new thread with regard to seeing how many are interested as I suspect given the number of posts to this thread and their very technical nature at times, many forum members will not be reading this one frequently.
riverstyx:If possible could you add an additional pair of pads such that the serial RX of the pi can optionally be linked to another GPIO input
Yes, no problem. If it's okay I will add a solder bridge or a 0R between RX and an additional GPIO on the 40 pin connector.
riverstyx: Put me down for 5 or 6 of the PCBs and I can populate them as much or as little as I need to for the reverse engineering efforts. It might be worth starting a new thread with regard to seeing how many are interested as I suspect given the number of posts to this thread and their very technical nature at times, many forum members will not be reading this one frequently.
Okay, great. I won't include much THT components. Maybe just the 40 pin and the RJ45 connector. Those are also available as SMT but as THT they are much more robust.
I hope that I don't have to go smaller than 0603 range. Where I order my PCB prototypes there is only one stencil pair with each order. So I would suggest that I populate at least the ML part of each PCB since I think this is much more effective in time. Let's see how big the general interest is. If some more people would like to have one it is possible much better to order completely populated PCBs from the manufacturer.
Yes, I will open a separate thread for asking around. Good idea.
RaMaBo: Hi, i follow this thread since the beginning and would be very interessted in a PCB for connecting a Raspberry Pi to Masterlink My current setup is a BV 3-32 MK1, BS9000 MK1 (NetMusic compatible), BeoMedia 1 (with Twonky Server installed for DLNA compatibility), BeoLab 2000. The BS900 could be changed to a BS2500 with Beolink Converter if it would be necessary for testing. Greetings from Munich
Okay, great to hear this! You are on the list. :-)As written before I will open up a new thread for asking around who is interested in such a PCB.
BeoMotion:Yes, no problem. If it's okay I will add a solder bridge or a 0R between RX and an additional GPIO on the 40 pin connector.
Great, a 0 ohm resistor would be perfect, as it can easily be removed when no longer needed.
BeoMotion: Okay, great. I won't include much THT components. Maybe just the 40 pin and the RJ45 connector. Those are also available as SMT but as THT they are much more robust.
Yep, THT for connectors makes sense as they are far more resilient to abuse... Can we use one of the stacking type 40 pin headers? (the ones with the long pins) as that will make it easier to connect other things to GPIO pins not used by the ML interface (and for connecting a scope during testing to those that are).
BeoMotion:I hope that I don't have to go smaller than 0603 range.
Yeah, 0603 is a good lower limit if possible. I'm quite happy hand soldering SMD down to 0603 size (as long as I haven't had too much coffee!), anything much smaller than that though and you're in the realms of needing a stereo microscope and a very steady hand ;-)
Having said that, if you'll have a stencil set and have access to an oven then by all means feel free to fully populate the boards - I'm not worried about the cost of the additional components - it was more a case of if I was having to hand solder everything then I would have just populated what I needed in order to reduce the assembly time.
Thanks again for taking on the PCB design side of things. It seems that you are much more experienced with this aspect that I am anyway so it undoubtedly makes good sense.
I bought a second MLGW today from ebay (at 260GBP it was a bargain compared to what I paid for my existing MLGW!). My intention is to use it in the reverse engineering process. Once we have the ability to transmit I am intending to connect it to a RPi via the interface*, transmit various telegrams from the RPi, and look at the output from the MLGW as this will hopefully enable me to determine the meaning of some of the bytes which are not currently obvious (the MLGW protocol format is different, and the data therein is obviously a only a subset of the full ML protocol data, but MLGW protocol is at least fully documented so will hopefully provide some clues to deciphering some of what is currently unknown).
I've added some code to my decoding script to build a basic schema for the masterlink protocol as it decodes ML telegrams (showing TELEGRAM_TYPE=>PAYLOAD_TYPE=>PAYLOAD_VERSION=>PAYLOAD_LENGTH) so that I can at least start to get a feel for what the possible combinations are.
Ultimately, I'm looking to create a set of classes and subclasses that can be used to contain/describe each telegram instance and I may implement this in Python rather than Perl as I suspect it may be more useful to those just starting out with the RPi. It will mean me having to learn Python but I've been looking for a reason to do so for a while anyway. To be honest it has taken me a little while to get back into coding in Perl as it has been around 10 years since I last did this professionally.
*we need a name for this as I'm bored of typing 'the interface' or similar every time I need to refer to it - perhaps BeoPi ? or we could ask in the other thread for suggestions...
Regarding the with/without DAC option (I'm answering here as I'm trying to keep the other thread completely non technical) , I'd be happy with a mixture - both for testing / development purposes and subsequently because I have some applications in mind that require audio and some which do not.
A few quick questions:
Does your design use a balanced output DAC or are you doing the balancing externally to the DAC?
Either way, is there any space available for additional headers (to be used in the case of more sophisticated audio requirements, for example if adding an external ADC as well)?
Is there a way we can force the DAC to mute, for example when we switch to another source supplying audio to ML such that we don't get two lots of audio even if the application on the RPi is still producing an output?
riverstyx:I bought a second MLGW today from ebay
Sounds great! I don't have a MLWG at my home and would be lucky if you could find out how e.g. the MLGW addresses and controls a single device on the bus.
riverstyx:It will mean me having to learn Python
That is quite easy. Like Pearl it is also a scripting language and really straight forward. For prototyping it is much more comfortable than e.g. C/C++ and there are thousands of tutorials of all different topics out there.When we completely understand the protocol and everything else is finished I'm dreaming of a ML kernel module written in C far in future :-)
riverstyx:Does your design use a balanced output DAC or are you doing the balancing externally to the DAC?
I would like to use a balanced one but there is always the problem that there is no audio MLCK on the Pi available. Most of the differential ones require this. I think the better option would be to use a PCM5102 from TI which uses internal PLL for this. This one is known to work very will with the Pi and with a couple of OP amps we can make it differential.
riverstyx:Either way, is there any space available for additional headers (to be used in the case of more sophisticated audio requirements, for example if adding an external ADC as well)?
Yes, should be possible. What won't work is receiving ML audio, passing it digital to the Pi and then sending it out digitally to the DAC and connect it to PL speakers. The reason is that there is just one I2S interface on the Pi. If we would like to do so there would have to be some switching logic on the I2S without feeding it to the Pi. I don't think that this would fit on the ML board but I am thinking of adding some connectors behind the DAC that it could be reused for this purpose. In this case it would also better to switch over to the more expensive PCM5121 which offers HW volume control.
riverstyx:Is there a way we can force the DAC to mute, for example when we switch to another source supplying audio to ML such that we don't get two lots of audio even if the application on the RPi is still producing an output?
Yes, on the PCM5102 and PCM5121 there is a dedicated mute control pin which will be brought to the GPIO connector.
Two thoughts regarding the PCB:
1) Why not using a DAC already on the market? I am using HifiBerry DAC+ and very happy with it.
One advantage would be, that many raspberry media software already recognizes the HifiBerry DAC+. That is important for people like me, which are not too deep into linux / phyton programming.
2) How about considering some electrical relays?
I would like to use several raspberry parallel to my Masterlink set-up controlling each of my Masterlink-Beolabs (like Beolab3500 or Beolab2000 - to get a kind of Sonos feeling ;)). But there are scenarios which you probably have to cut Masterlink communication AND / OR Masterlink sound from the rest of the system.
Scenario 1 you want to listen to different music at one Beolab3500 as at the others. In this case you have to take off the one relevant Beolab from Masterlink sound and have to connect it to the raspberry sound. All other beolabs still could / should be connected to the master (e.g. beosound 3000) or another raspberry.
Scenario 2 the only way (I know) to turn on a Masterlink-Beolab via Masterlink is to put it on timer. As soon as the Masterlink timer commands comes, all Beolabs on timer turn on. Unfortunately you cannot address one single individual Beolab because the Masterlink protocol is not able to handle it. In this case it would be great, to take off the relevant Beolab from Masterlink data, send a timer command via the raspberry and put it back to Masterlink data if necessary.
To conclude I am thinking about setting up my raspberry between Masterlink and the Beolab via some relay. In default mode, the raspberry works parallel to Masterlink and can "listen" to the Masterlink set-up. In "action" the raspberry can take off the designated Masterlink-Beolab from the Masterlink set-up and communicate directly with it.
That is the reason why I think featuring some relays could be more important than a DAC. But nevertheless I will buy some PCBs whatever you are deciding on.
Alsfeld:1) Why not using a DAC already on the market? I am using HifiBerry DAC+ and very happy with it.
It is much cheaper to integrate a DAC directly in the BeoPi HAT rather than buying a separate one and stacking that on top. We are talking about 5 euro integration cost vs. 30 euro plus shipping for the hifiberry. Additionally there is the space problem and you have to solder a connector to the hifiberry.
Don't worry about the software support. If we take the PCM5102 or the PCM5122 you can use the same driver like you do with the DAC/DAC+ since those are the same ICs.
Alsfeld:2) How about considering some electrical relays?
Okay, the only thing that needs to be implemented for this is a second ML RJ45 connector and a "off-switch" for the incoming ML audio.We don't have to split the data lanes. So I hope that it is possible to squeeze in that second connector. They tend to be really big and bulky if space is limited.
For Scenario 2: It is possible to control single / individual linkrooms independent from each other although connected to the same ML. So no need to split anything here. Actually this is what the MLGW does and chances are really good that we are able to copy that.
I must learn to type quicker (or be more concise with my answers!) as this is the second time in as many days that BeoMotion has posted his response whilst I'm in the middle of writing mine
BeoMotion: Alsfeld:1) Why not using a DAC already on the market? I am using HifiBerry DAC+ and very happy with it. It is much cheaper to integrate a DAC directly in the BeoPi HAT rather than buying a separate one and stacking that on top. We are talking about 5 euro integration cost vs. 30 euro plus shipping for the hifiberry. Additionally there is the space problem and you have to solder a connector to the hifiberry. Don't worry about the software support. If we take the PCM5102 or the PCM5122 you can use the same driver like you do with the DAC/DAC+ since those are the same ICs.
Yes, the DACs BeoMotion is suggesting are supported so will be detected in exactly the same way as your HiFiBerry DAC is.
Also, stacking of RPi add-on PCBs is not really supported. Whilst it can work (providing none of the stacked boards use of any of the same GPIO / signal lines) it's generally best avoided if possible.
BeoMotion: Alsfeld:2) How about considering some electrical relays? Okay, the only thing that needs to be implemented for this is a second ML RJ45 connector and a "off-switch" for the incoming ML audio. We don't have to split the data lanes. So I hope that it is possible to squeeze in that second connector. They tend to be really big and bulky if space is limited.
Okay, the only thing that needs to be implemented for this is a second ML RJ45 connector and a "off-switch" for the incoming ML audio.
We don't have to split the data lanes. So I hope that it is possible to squeeze in that second connector. They tend to be really big and bulky if space is limited.
Unfortunately, I don't think it is quite as simple as that - consider the situation where the audio lines are disconnected but a remote command is issued to the 'detached' BS3500 (which is being fed audio from the local RPi), for example pressing 'next track' on the beo4 - the BS3500 will still instruct the main room source to take this action (via masterlink) and thus affect what is happening in other rooms.
You would need to disconnect both audio and data lines, and then this will mean the BeoPi having to step in as audio master and supply bus power. Then when you switch it back such that the masterlink segments are joined again, you might have to power cycle the BL3500 in order to avoid ML address conflicts.
I'm not saying it isn't possible, just that it is not necessarily as straightforward as it might seem at first glace. As such I think any available space on the BeoPi is best left to the core functions already discussed (namely masterlink data plus a DAC) along with ensuring we have enough headers to support further applications and enhancements via separate PCBs if desired.
I need to go out for an hour or so, but will expand on this (where I think we need headers) a little further when I return.
[edited by: riverstyx at 7:37 PM (GMT 0) on Tue, Jun 16 2015] Edited quoted text to make it clearer that it was scenario 1 that was not straightforward - scenario 2 should be achievable without modification to the design as BeoMotion has already mentioned.
riverstyx:I must learn to type quicker (or be more concise with my answers!) as this is the second time in as many days that BeoMotion has posted his response whilst I'm in the middle or writing mine
Sorry! :-)
riverstyx:Unfortunately, I don't think it is quite as simple as that - consider the situation where the audio lines are disconnected but a remote command is issued to the 'detached' BS3500
Yes, you are right. But we should be able to detect if there comes a command from the BL3500 that addresses the mainroom. We could just "manipulate" or even cut the checksum of this command to make it not valid. Well, quite a hard solution but much better than anything else if it works. Hopefully there is no ML command for "CRC not valid, please send again"
riverstyx:As such I think any available space on the BeoPi is best left to the core functions already discussed
Yes, I really think the same. If there should be some space left over, I will try to integrate it for the first prototyping PCBs to see what is possible. :-)
BeoMotion:Yes, you are right. But we should be able to detect if there comes a command from the BL3500 that addresses the mainroom. We could just "manipulate" or even cut the checksum of this command to make it not valid. Well, quite a hard solution but much better than anything else if it works. Hopefully there is no ML command for "CRC not valid, please send again"
As I want to keep all the code as modular as possible, my code will return a class instance for a complete telegram, so we would not even know about the telegram from the BL3500 until it had been received in full (and had therefore also been received in full by the main room product). I also think that trying to deliberately cause a collision on the ML bus to obscure or corrupt data is bad idea in principle. I also suspect there is some collision detection within masterlink products as there are possible error codes relating to this defined within some of the product service manuals.
A much better solution to scenario 1 is to have several separate masterlink networks each with a RPi & BeoPi, some (audio) switches to connect ML_AUDIO lines of different segments together on demand, but no other physical connections made between the different ML networks. Any ML data telegrams received on one network can then be sent to all the other RPi's via ethernet, these will then re-transmit the data on their local network.
By doing this we effectively create one ML network from an ML_DATA perspective (and all devices will have unique ML addresses), but separate ML networks from an audio perspective (but with the option of joining the audio).
The same could be achieved by transmitting the ML audio between RPi's too, but this would require each to have both a DAC and an ADC and would also lead to audio sync issues between the different ML networks. In contrast, any slight delay in relaying the data telegrams is unlikely to be significant or cause any issues.
An add on PCB for audio matrix switching is something I have in mind anyway so this could provide a solution to this scenario without adding additional complexity to the current hardware and software design.
With regard to headers, my thoughts are as follows...
For the audio side we currently have:
i2s header --> DAC --> OP amps --> ML_AUDIO --> RJ45 connector
If we can add a pair of headers with a jumper (or equivalent arrangement) at each of the "-->" positions, we then have the ability to break the above chain at any point by removing the jumper (or jumpers plural where stereo and/or balanced audio is involved) and do something on a separate PCB with the signals at that point whilst also then being able to inject a signal back into the chain or re-purpose the DAC and/or OP amps from the piggybacked PCB too.
Perhaps also we could consider using a quad audio OP amp rather than a dual and utilise the extra two OP amps in the package to convert ML_Audio L/R/+/- back to unbalanced L&R as this would be a useful input to any audio switching matrix (no need for the matrix to then deal with a mixture of balance and unbalanced inputs).
Finally, I think the DAC without volume control is fine, as I'd be inclined to add an i2c volume control to any add-on PCB that has powerlink on the basis that we'd still want full volume going into the ML audio bus.
Regards,
BeoMotion: riverstyx:Does your design use a balanced output DAC or are you doing the balancing externally to the DAC? I would like to use a balanced one but there is always the problem that there is no audio MLCK on the Pi available. Most of the differential ones require this. I think the better option would be to use a PCM5102 from TI which uses internal PLL for this. This one is known to work very will with the Pi and with a couple of OP amps we can make it differential.
That's fine, a non differential DAC will also make things easier when it comes to audio matrix switching on a separate PCB.
BeoMotion:What won't work is receiving ML audio, passing it digital to the Pi and then sending it out digitally to the DAC and connect it to PL speakers. The reason is that there is just one I2S interface on the Pi. If we would like to do so there would have to be some switching logic on the I2S without feeding it to the Pi. I don't think that this would fit on the ML board but I am thinking of adding some connectors behind the DAC that it could be reused for this purpose.
That's not an issue, as it would be easier to route the analogue audio from the ML bus to the powerlink speakers, eg:
ML socket --> extra two OP amps --> audio switch matrix --> i2c volume control --> powerlink socket
BeoMotion:on the PCM5102 and PCM5121 there is a dedicated mute control pin which will be brought to the GPIO connector.
perfect
riverstyx: i2s header --> DAC --> OP amps --> ML_AUDIO --> RJ45 connector If we can add a pair of headers with a jumper (or equivalent arrangement) at each of the "-->" positions, we then have the ability to break the above chain at any point by removing the jumper (or jumpers plural where stereo and/or balanced audio is involved)
If we can add a pair of headers with a jumper (or equivalent arrangement) at each of the "-->" positions, we then have the ability to break the above chain at any point by removing the jumper (or jumpers plural where stereo and/or balanced audio is involved)
Actually, for most applications I think we will only need headers between the DAC and the OP amps to be able to split the chain here and extract audio from the DAC output and inject (potentially different) audio into the OP amps.
As you mentioned, it might be worth being able to disconnect the DAC from i2s, although I can currently only envisage one application where I would want an ADC and that is in order to be able to convey the ML data and ML audio over the internet between devices - imagine having a second home with link room products and haing the ability to access sources from the main room products in your main home from there...
Okay, I think I will try to add a header with jumpers on the output of the DAC. If you remove the jumpers a second board could be attached.
The idea with the ML data over LAN is great but I think this is something that will lead to frustration.There is always the risk that something gets wrong with one Pi which requires a manual reboot. Until that reboot the connected ML device "behind" this Pi will be unresponsive. So this would be only be a acceptable solution for the "hardcore" freaks.
I think for the first version we should stick to the given ML limitation that only one source is possible at the same time...
Later we might consider building a server version with ADC of the BeoPi. Then we could stream the ML audio to the clients which are totally cut from the "real" ML. Yes, in this case there would be a sound delay but in most cases this should be okay since you are only upgrading to this if you want to listen to different sources.
BeoMotion:The idea with the ML data over LAN is great but I think this is something that will lead to frustration.
Yeah, this was more about showing how Alsfelds scenario could be achieved in principle without having to try and clobber data on the bus, without causing ML address conflicts on disconnect / reconnect, without modifications to the interface design, and without requiring a redesign of the software. I firmly believe that any switching, whether audio or otherwise, is best done externally to the BeoPi. There should be plenty of spare GPIO lines for this sort of thing if people want to do clever things, but I don't think we need to add additional RJ45 ports and switching to the interface itself as it just complicates things for one very specific application. I think it's best to keep the interface as simple as possible, whilst providing headers where appropriate to facilitate additional features to be added externally.
BeoMotion:Okay, I think I will try to add a header with jumpers on the output of the DAC. If you remove the jumpers a second board could be attached.
Perfect, thanks. Are you able to squeeze in another pair of OP amps to convert the balanced audio on ML bus to unbalanced audio and provide a header for this? (perhaps by using a quad op amp package rather than a dual where there are currently OP amps converting the DAC output to balanced audio)
The reason I am requesting this is that the main piggyback board I would like to create at some stage is an audio matrix addon, with powerlink socket, aux socket with datalink, and IR reception. This would allow the unit to be used as a full blown audio master.
eg.
Inputs:-
Outputs:-
I'm looking to utilise a TEA6420 audio matrix for this, which has 5 inputs and 4 outputs and is controlled by i2c. The datalink on the aux socket would need to be implemented with soft serial but given it is only 320bps that shouldn't cause any issues. I've already figured out the datalink protocol with a logic analyser and some information that Ridax (Mikael) was kind enough to share.
BeoMotion:Later we might consider building a server version with ADC of the BeoPi.
Yes, or if people really want to do this there is also the option of using a supported USB sound card for input. As I hope I've shown above, most applications don't require the RPi to sample the audio, just to switch it.
Hello masterlink masters,
although having some it knowledge, this is a higher league for me, but:
I wanted to let you know that i am really really interested in such device. You have to keep it simple for the end users wanting it to integrate. Because thats what B&O does and thats why the people love it. They are now in post-masterlink era so they will not develop products like this anymore. But normal users could benefit from it many years to come. Because of RPi it can still bring the latest trend in an "outdated" masterlink. We have build our masterlink network for years, bought expensive products which were guaranteed future proof and now we should get rid of it? It would be a huge pity.
So please:
Make a device which is user friendly and with hard to beat reliability, because thats what the majority of ML users want. Primarily it should be a n.radio n.music device not a Hotel capable network. It became more B&O than the B&O itself in your future plans. Of course those are nice to have, but start with something real an you can develop it in the future.
Me personaly:1. want some DLNA or similar technology renderer being able to play the HD flac, alac files BEO4 for the everyday practical use by pushin n.music and IOS beomusic kinda app for the music collection playing when sitting down and having time to listen
2. n.radio device. although thousands of stations available out there, who listens to them actually. Make the app simple by being able to create own playlist or two.I can bet the majority of time is spent by listening to your favourite station. BEO4 as the main user device. Managing stations could be done through web browser.
3. airplay or apt.x receiver through n.music with the priority over dlna storage when connected
4. i don't know if the reliability goes hand in hand with USB but, haven't you thought about using the best compact DACs available. Something like meridian explorer or audio quest dragonfly for the output. So that the sound going out of the device could be the best.
I know that the "networked" devices being able to deliver room per room freedom would be maybe revolutionary, but for the startup it needs something real simple.
I think that i can speak for more of potential users, although having advanced it knowledge i don't want to have a piece of kit that i can play with. I am willing a reliable product. I don't want it free of course, i want to buy it, take your time and develop an easy product.
I will buy it, i will even buy installation support or even updates. So that you can earn something from your hobby. I think it will still be much much cheaper than original. not to mention that no original with this features does not exist.
A real killer would be a graphical interface inspired by BS5 which is being discussed in other posts with all these features discussed above. I think that as the beomasters 5 would retire. there will be lots of BS5 controllers left. I think it would be a real future proof design.
Really boys make it at least a little commercially so that you will get some of your time spent developing back in money. Thats normal you cannot do it enthusiastic way only.
thanks
Mike
Hi Mike,
thanks for your great input. Very much appreciated.
You want to have a commercial product that just works plug-n-play. That's totally fine and I think some other people also want to have such a solution.The problem I see is that this product would be in the $1.000...2.000 range and only few people would buy it.The effort single persons would have to put into development is enormous and the commercial risk is high.
The only chance I see for this project is that several people are working together on an open source basis. If someone suddenly don't have enough time anymore others can take his work and improve it further.
Nobody will ever give a guaranty that this solution will always work without a single fault but everything is done that it works ok for most of the time.In the end the final user has to buy that raspberry and install + configure all that SW that comes without warranty. If the interest is high enough I am sure that the SW and the HW will become better and better. But I really doubt that there will ever be a plug-n-play solution.
All of the things that you wrote are possible but for most of them you would have to use google to find out how to get that working with the Raspberry.
Your points 1 + 2 + 3 should all be covered by one of the audio distributions for the Raspberry. Take a look at Volumio or RuneAudio.What we would like to do is to create a control layer that handles the controls between the ML bus and that audio software.
Point 4: We are talking about a relative good I2S DAC that is normally found in expensive audio gear. Of course we could also use an XMOS + Sabre DAC combo but that would be an overkill for the B&O components and much to expensive.
michscho:A real killer would be a graphical interface inspired by BS5 which is being discussed in other posts with all these features discussed above. I think that as the beomasters 5 would retire. there will be lots of BS5 controllers left. I think it would be a real future proof design.
Yes, it is possible to connect a BS5 to a Raspberry or every other SBC. In theory this is a excellent solution but the effort is quite big since you have to create all that GUI stuff. Maybe me or somebody else will come back to that topic in a couple of years when the BM5 died.
michscho:Really boys make it at least a little commercially so that you will get some of your time spent developing back in money. Thats normal you cannot do it enthusiastic way only.
Again, the problem on commercial solutions is the warranty and that people expect that everything runs smoothly out of the box. For me I have to decline both and say that this project is just for fun and for people that like to tinker / hack.
Hi all,
last weekend I was finally able to work on the schematics again.I included the DAC and made the decision to exclude all the master stuff. It would be required to create that +- 12V on the ML bus when the BeoPi is the only ML master.
This would mean that we couldn't use the 5V microUSB power source for the Pi.BeoPi would require a power connector, a fuse, additional voltage converters and the backpowering protection circuit.All-in-all we would run out of board space.
So let's keep it simple and start with a slave-only HAT. Maybe an additional PCB that adds master functionality to come later...
BeoMotion:The only chance I see for this project is that several people are working together on an open source basis. If someone suddenly don't have enough time anymore others can take his work and improve it further.
Yes, I agree completely as this is also how I see it. The concept behind this project was something that had been on my to-do list for quite a while, but since I already have so many other commitments that take up my time, it was also something that was likely to have stayed on that list indefinitely.
The interest shown by BeoMotion and others is what spurred me into setting aside some time to actually work on this, and when, fairly early on, work on this stalled as I was too busy with other things, BeoMotion kindly volunteered to take over the hardware / PCB design and I have since focused my attention on the software (or more specifically the reverse engineering of the Masterlink protocol).
I really struggle at times to find the time to work on things like this - we were (are) part way through extensive renovations of our house, and bought an apartment to live in in the meantime as it became increasingly difficult to make much progress whilst we were also trying to live there, but have then (unexpectedly) ended up needing to do renovation work to the apartment too As a result, most of my B&O equipment is currently not installed and is instead occupying a large proportion of our kitchen floor space...
On one hand I should really be prioritising the work on the apartment, and then the work on the house (I'm doing the vast majority of the renovation work myself), but a project such as this can be a welcome distraction at times and I'm keen to try and keep things moving forward and maintain the momentum - especially whilst there is interest being shown and others who are prepared to take on some of the work. That said, it is somewhat catch 22 as if I could at least complete work on the apartment and connect up my masterlink network again I would make the reverse engineering that much easier as I wouldn't be reliant on others to provide data logs.
I'm unlikely to achieve much this month as I am working some ten hours drive away from home this week, and again in a couple of weeks time, although if I remember to bring the RPi with me next time I may be able to do some work on this in the hotel room during the evenings.
BeoMotion:Yes, it is possible to connect a BS5 to a Raspberry or every other SBC. In theory this is a excellent solution but the effort is quite big since you have to create all that GUI stuff. Maybe me or somebody else will come back to that topic in a couple of years when the BM5 died.
Yes, creating a good graphical user interface is not easy, indeed many would debate whether B&O have ever succeeded in this respect. I personally like the BS5 interface but feedback would appear to indicate that others have found it far from intuitive.
The goal for the BeoPi interface at this stage is to create a hardware design and some software that can be used as building blocks for more extensive projects - this alone will require a considerable amount of work. I know both BeoMotion and myself have ideas of what we would personally like to achieve with the interface, and it will undoubtedly be these ideas which are likely to be implemented first, but I would hope that this will then serve as examples and inspiration as to what is possible, and allow us, and others, to then expand on these ideas and progress them further. This is the reason for, and the beauty of, making the whole project open source, as it allows anyone to pick up what we have already done and expand it or even branch it off in a completely new direction without massive duplication of the work that has already been done.
BeoMotion:In the end the final user has to buy that raspberry and install + configure all that SW that comes without warranty. If the interest is high enough I am sure that the SW and the HW will become better and better. But I really doubt that there will ever be a plug-n-play solution.
I do think we can get close to a plug and play solution for the specific applications we create. Some configuration is always going to be required but we (and others) can provide bootable images to download and copy to an SD card as a starting point for using the interface for a particular purpose. The real power though is in facilitating people to create and share their own applications and designs using the hardware and software as a framework.
BeoMotion: michscho:Really boys make it at least a little commercially so that you will get some of your time spent developing back in money. Thats normal you cannot do it enthusiastic way only.. Again, the problem on commercial solutions is the warranty and that people expect that everything runs smoothly out of the box. For me I have to decline both and say that this project is just for fun and for people that like to tinker / hack.
Yes, with commercial solutions / monetary transactions come expectations - either of the product itself or of a level of support that we would not realistically be able to provide.
It changes the whole ethos from one where those with the technical skills are able and encouraged to contribute to the overall design, to the benefit of the project as a whole and to its other users, to one where people contribute financially but then have expectations that everything will be done for them, and those with the skills to do more then have no incentive to do so as it is others who will be seen to reap the financial rewards from their contributions.
BeoMotion:last weekend I was finally able to work on the schematics again.
Excellent. Thank you for your efforts.
BeoMotion:I included the DAC and made the decision to exclude all the master stuff. It would be required to create that +- 12V on the ML bus when the BeoPi is the only ML master.
Yes, I think that is a sensible approach. It is easy to overcomplicate things but for the first revision at least, it is best to keep things simple.
BeoMotion:BeoPi would require a power connector, a fuse, additional voltage converters and the backpowering protection circuit.
Yes, I've been meaning to study this circuit some more because I don't fully understand it. From what I recall, it seemed that each (master capable) device provided this power but that there was some feedback from this circuit (ultimately to the audio switching area of the schematic) but I'm not sure for what purpose. ML_DETECT is then triggered from the wires linked to this power in the ML junction boxes etc, but that link only seems to be required for ML networks over a certain total cable length and it doesn't seem that the +/- 12V (or +/- 15V in some devices) is used for much else. One device also has the responsibility of driving the data bus by providing the +/- 0.25V but I'm not certain whether the logic of these two functions are linked.
This link is interesting as it is more up to date that any version of the beolink handbook I've seen before:
http://www.echo14.com/wp-content/uploads/Handbook.pdf
Hello, from the your point of view all those arguments make sense.
With the "commercial" i thought that i am willing to support or to donate also a DIY project, not necessarily a boxed version with manuals and support, or you could sell some pre-made sd card images with some basic functionality. Thats not a real commercial product, and i think that its also very fair to you people out there spending lots of time developing.
Sending some extra votes for simple solution at first. N.radio, N.music, Streaming but with the correct ML functionality. The sooner it gets out the more user feedback you get. And then you'll see if complexity is needed or not
I am dreaming about some hideaway box most of the time used in link rooms with beo4 (or better said in every room because in fact there would be no master room) or taking iphone/ipad sit in the sofa and listen to my HD audio collection.
I know that the RPi is capable of all my 1.2.3. expectations but the easy preasembled os image with the ML functionality is missing.
Dac overkill it is for airplay or network radio channels, but i think for HD flacs there could be some real benefit. And if somebody wants DAC XXX let him download the image XXX if you want DAC YYY you need image YYY
And i think people buying BO stuff are quite used to som higher price tags also in used gear market, so the price/power ratio would be huge even with the more expensive DAC
thanks again and the further it gets the keener i am
thanks again for you input.Having a downloadable ready-to-use image is something very important and I think we really should offer this when sending out the boards.I think most of your ideas should be included if we are forking e.g. volumio and add the ML stuff.
The DAC that will be included into the BeoPi HAT is a PCM5102a from TI. It is a really good on and is able to receive up to 32/384 via I2S. The PI will limit this to 24/192. As far as I know the BBB (AM335x) is the only SBC that can handle up to 32/384 and DSD via its integrated audio controller...Then there is also the question whether you will really hear the difference via the ML connection. I really doubt it...So I think it is okay if we go for the PCM5102a. If you want a bit more snake oil, feel free to connect one of those USB DACs with integrated XMOS controllers. You could connect its output to the BeoPi HAT via a jumper behind the onboard DAC. UAC2.0 support is directly integrated in the linux kernel and will work just out of the box on nearly any distro.
If you really want more fidelity from your B&O speakers please connect them directly to a high quality DAC. All other attempts will always be limited by the internal audio logic of the BeoSound or the BeoVision.