ARCHIVED FORUM -- March 2012 to February 2022READ ONLY FORUM
This is the second Archived Forum which was active between 1st March 2012 and 23rd February 2022
Hi BeoMotion,
Please put me down for one. I don't expect you to give it away though - I am more than happy to contribute a share of the PCB fabrication and component costs along with whatever it costs to post it to me.
Kind Regards,
Martin.
duplicate - site isnt great for editing on an iPad! (or a Mac with Safari either)
Ink me in too!
duplicate
@ TWG, riverstyx, frog: great, thanks!
Finally the PCB's arrived today and almost all parts.Only the power IC's are still in transit.As soon as they arrive I can assemble the boards.
See the attached picture for a size comparison between the ML board an a RPi.
BR,BeoMotion.
.
Hi all, I just came across this and read this thread and the technical one. I'm very interested in a PCB to connect to a RPi. In fact, I would take two. The idea I'm having is to connect a Raspberry to the BLC and read Masterlink data. I could then control my Yamaha AV-receiver for Internet Radio and Spotify, the audio is already connected to the BLC line in.
@BeoMotion: you mentioned you have some initial python code to interpret masterlink telegrams. Did you put that on github or somewhere else yet?
kind regards, Matt
Please count me in too
sia
mattb: Hi all, I just came across this and read this thread and the technical one. I'm very interested in a PCB to connect to a RPi. In fact, I would take two. The idea I'm having is to connect a Raspberry to the BLC and read Masterlink data. I could then control my Yamaha AV-receiver for Internet Radio and Spotify, the audio is already connected to the BLC line in. @BeoMotion: you mentioned you have some initial python code to interpret masterlink telegrams. Did you put that on github or somewhere else yet? kind regards, Matt
Hi Matt,
Welcome to beoworld and thanks for your interest in this project.
Decoding of the ML protocol is still at a very early stage - once I have an interface to work with and can start injecting telegrams into the ML network it should become easier to make progress on this. So far I have just worked with some sample data that BeoMotion logged whilst performing various actions with the connected equipment.
Nothing is on github yet, but I'll upload a tgz to the technical thread now in case you or anyone else wants to take a look.
Hi,
thanks a lot for uploading the perl decoder, riverstyx!
Unfortunately the current ML PCB is not fully functional.The transmitter part isn't working. I have not that much time at the moment for debugging but I will come back to this.Also the pinout of the RJ45 connector isn't correct although I have checked everything at least twice.
I'll post the schematics of the non working PCB later this day. Maybe someone can see the problem without wasting a whole day for debugging.
BeoMotion:thanks a lot for uploading the perl decoder, riverstyx!
No problem - there's still loads of stuff to figure out, even with the current relatively small data set, and like you I am struggling to find much time to work on this at the moment. I will make some time to carry on with this in due course but by making the code public it gives others the option of contribute if they are able and so inclined. The current 'tree of switch/case statements' is messy but covers all of the TELEGRAM_TYPE, PAYLOAD_TYPE, PAYLOAD_VERSION combinations seen so far (and will flag up any new ones encountered as new telegrams are added to the data set) and thus gives a place to add comments for each as their meaning are determined.
BeoMotion:Unfortunately the current ML PCB is not fully functional.The transmitter part isn't working. I have not that much time at the moment for debugging but I will come back to this.Also the pinout of the RJ45 connector isn't correct although I have checked everything at least twice. I'll post the schematics of the non working PCB later this day. Maybe someone can see the problem without wasting a whole day for debugging
I'll post the schematics of the non working PCB later this day. Maybe someone can see the problem without wasting a whole day for debugging
Sorry to hear this. It proves you were right to take the decision to limit the first prototype to data only but I know this will be of little comfort right now. I'm happy to work my way through the schematic to see if I can identify anything as sometimes a different set of eyes can save hours - this is often the case with finding bugs in code too as it's easy to repeatedly read what you intended to write rather than what you've actually written!
riverstyx:I'm happy to work my way through the schematic to see if I can identify anything as sometimes a different set of eyes can save hours - this is often the case with finding bugs in code too as it's easy to repeatedly read what you intended to write rather than what you've actually written!
Hi Martin,
yes this would be really great!I've uploaded the current schematic as a pdf in the technical thread.
Thanks a lot.
Unfortunately, I have no capabilities and talent in coding or engineering, so won't be able to help. Having said this, please let me know if you need help with testing. Also, it may be worth to put the financial burden on more shoulders and I am happy to contribute. Others of the beiworld community may follow. OR you even go with kickstarter?
I would also take 2, potentially 3. One question, though: do you think it would be possible to communicate with Beolink Wireless as well or is anyone else working on that?
The main reason why I am asking is, because I am also considering a project were I would try to realise something like the LC2 using an Arduino. If Beolink wireless communication is possible, the light controllers wouldn't need their own IR receivers.
Regarding the electronics I am afraid that I can't offer any useful help. But if you need help with designing a casing and making 3D CAD drawings of that, I am happy to contribute and make them accessible for customisation and 3D printing (I'm not a professional, but it wouldn't be the first time I'm doing it).
Okay, great. Thanks for the feedback.
Yes, I also thought about crowdfunding but I think it is a bit to special.
First thing now is to get the DATA PCB up and running.Unfortunately I haven't had the time until now for debugging.Hopefully there will be some hours left for that next weekend.
I'll keep you posted on the progress.
Yes, 3D printed cases would be the way to go on such a small series.So I'm sure you could help and contribute some nice STL files to the project as soon as the size of the PCB's are final :-)
Great, just let me know when you have some more input on that
Hi all,
finally I was able to find some time to hook up a scope and do some investigations.The ML transmitting part is perfectly working, which are indeed very good news. :-)The level shifter was the problem.
There are also some other minor design changes to do and then I will send out a second prototyping PCB for manufacturing.
Will keep you posted.
This is great news. Thanks and well done!
Has the new PCB arrived and any update for us?
Has there been any progress in the background and anything I can be helpful with?
Just pulling this one up in hope for any news :)
Espen: Just pulling this one up in hope for any news :)
Same here! I am trying to get the Lintronic box to work over my MCL system, and I want to connect it also to my Pi that is already sitting next to my beovision as a Kodi media center. But it is not really working well for me so to feed the ML/MCL directly into the pi and vice versa is more and more favorable!
Thanks for all the work done so far
Beosound 5 Encore + Beosystem 5500 + S45.2; BV7-40 MKV + BL7.1 + BL14.4+ AppleTV4; various link rooms with MCL2 A or MCL2 A/V + RL60.2 / CX100 / CX50 & Cona / IWS2000; BG4000; Beosystem 1200 + BV1600.
sorry for my little longer absence here. For some strange reasons I didn't receive any "new post notification" mails from beoworld and I only randomly look into the active topics.
The current project status is still that we can successfully receive and transmit data from and to the ML data bus. The first PCB had problems with wrong ML RJ45 pin connections and a very difficult to solder negative DCDC converter.
At the moment my problem is that I'm missing some time for continuing this project. Good news is that currently I am working hard on a different project which could be easily combined with the final ML PCB and make an even better solution in the end.As some of you might know I never was really a friend of all that Raspberry Pi stuff... So when I have the time to continue the work on the ML PCB chances are good that there will be an exclusive connector for my own single-board-computer instead of generic pin headers. More infos on this and some words on why I think using a not a Pi is better to come soon...
Of course the idea is still to make the ML PCB and SW fully open source with all PCB design files available. So that people are able to tweak the design and the SW for their own needs.
Hello BeoMotion,
I'm also interested in two or three pcbs.
How do you connect them to the RPi? flying wires?
kind regards_beast_
yes, the initial plan was to connect it via single jumper cables.The new version I have in mind can be connected using a single FPC cable.I will come back in about 2 to 3 weeks with more news :-)
When it's more flexible using single jumper cables, please stay with them. :-)I'm REALLY happy when we have a small simple box that can pass "light" and "control" infrared commands onto the ML bus as it will be a GREAT benefit for the home automation fun for places where a B&O speaker or audio system would be out of place.I'm excited to test and see the final product!
If you need support please let us know!
At the moment I'm discovering that some people have difficulties with jumper cables.It is easily possible to count pin headers in the wrong direction, swapping colors, ...
For a different project I'm currently engineering a single-board-computer from scratch. It has a nice size, native support for ethernet, WiFi, BT and some other nice things. It also comes with a special audio connector featuring two serial ports and two completely independent audio interfaces.
This is excellent for building a ML bridge or anything else that needs two independent ML sockets. Due to the demands of the other project this special SBC comes with small pitch FPC connectors.This is the reason I have in mind to make the ML PCB plug-n-play with that machine.
Beolab 50, Beolab 8000 x 2, Beolab 4000 x 2, BeoSound Core, BeoSound 9000, BeoSound Century, BeoLit 15, BeoPlay A1, BeoPlay P2, BeoPlay H9 3rd Gen, BeoPlay H6, EarSet 3i, BeoVision Eclipse Gen 2 55", BeoPlay V1-40, BeoCom 6000 and so much else :)
Michael:Can this be used for NL conversion as well?
Why not? :-)Would require some reverse engineering on the NL protocol but seen from the hardware side there is nothing that could prevent this function.I think at the moment the NL protocol is plaintext and you can easily listen and learn from an existing setup.As long as they don't start to encrypt it this is a manageable tasks.
BeoMotion: Why not? :-)Would require some reverse engineering on the NL protocol but seen from the hardware side there is nothing that could prevent this function.I think at the moment the NL protocol is plaintext and you can easily listen and learn from an existing setup.As long as they don't start to encrypt it this is a manageable tasks.
Michael:That is interesting. I just have a BS9000 still, that is ML so perhaps I should just get rid of it, but it seems like a fun project anyway, and if it could communicate with NL perhaps it could be integrated with other stuff as Hue lights?
Yes, of course. But remember that there needs a lot of SW work to done before we we can even think of such a solution.First thing is to get the ML communication on the SW side working reliably.Once this is done interaction with IP based services like Hue or NL is just a matter of how many people are willing to spend some free time on this topic.
This is a really interesting project, I am going to follow this one.
Also I am interested in one PCB with audio injection, and one PCB without audio injection.I am running Raspberry Pi 3 Model B's at the moment.
BeoVision 4-65 - BeoSystem 3 - BeoSystem 5500 - BeoVox Redline 60.2 - BeoVox Redline 45 - Beolab Penta MKIII - BeoRemote One - Beo4 - Master Control Panel 5500 - LC2 - PUC Sources
Is this still project still in motion? I am still interested!
For a long time I observe this posts with ML communication. if possible I would contribute something.
Simple boards for sending and receiving would be great.
What I did not understand, where can you look at the technical details from your project?
Bruno
This topic is dead??
I have some plans to reverse engineer ML.
I am building a test system with few ML products and RS485 transceivers which I am not afraid to burn, I am then planing to record and interpret RS485 bus communication. Once timing and data structure is figured out, I am planning to build a dictionary of control commands and device addressing structure as per RS485 Master/Multiple Slaves addressing.
Once this is complete, possibilities are endless. Firstly, any NL products could be integrated into existing ML network, also major limitations of ML could be lifted, having multiple master like I do, masters can be dynamically allocated based on the desired audio workflow with sources and outputs. And finally, all devices could be controlled via home.app on iPhone and for more refine controls via say single web.page. That would leave no need to use BLGW and NL/ML contverters and rather have automation based on home kit and google home or Alexa.
If any of you is willing to contribute, I will be grateful if you can send anything that you have obtained so far with regard decyphering ML protocol, data structure : speed, parity bits, MSB/LSB order. Thanks.