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
Ah i did not know that, then it is fine
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 the multiple posts
<<note to self: never try to post using website on iPhone>>
Here is a screenshot of the BeoPi in its current state.
You can see the 4 RJ45 connectors, the 40 pin interface as well es 5V in and IR out.All parts of the ML data section are already in their final place....
Looking very good, nice work!
Have you considered whether there might be any cost savings (either on BOM or assembly costs) by using a 4 port modular connector (or a pair of 2 port modular connectors if you wanted to allow for populating just the ML and IR connectors on the 'lite' version), rather than using four individual sockets? (I should admit I haven't actually looked at the cost for these so they may actually be more expensive than multiple individual connectors!).
Regarding the power barrel connector - I presume this is so that we have a more robust and reliable connection than is offered by the microusb connector on the RPi, so that the connector is on the same face of the enclosure as the rest of the connectors, and to provide greater flexibility regarding the maximum power than can be provided to any connected peripherals by bypassing the 1.1A polyfuse?
The only downside to this is that there is much more potential (no pun intended) of the device being exposed to different voltages / polarity when someone accidently plugs in the wrong PSU. For the sake of approx 2 euros added to BOM cost, it might make sense to include a switching regulator in the circuit if you are not already planning to do so.
Keep up the excellent work.
Martin.
riverstyx:Have you considered whether there might be any cost savings (either on BOM or assembly costs) by using a 4 port modular connector
The 4 port connectors I found were all more expensive than using single ones.Since those are the only THT components we could save some money switching to SMT. I don't want to do so because I already saw them falling off...
riverstyx:Regarding the power barrel connector - I presume this is so that we have a more robust and reliable connection than is offered by the microusb connector on the RPi, so that the connector is on the same face of the enclosure as the rest of the connectors, and to provide greater flexibility regarding the maximum power than can be provided to any connected peripherals by bypassing the 1.1A polyfuse?
Yes, the main reason is to have all connectors on one side. The polyfuse on RPI is not a problem since exceeding this value something would be really going wrong. I thought about placing a similar one behind the barrel jack.
riverstyx:The only downside to this is that there is much more potential (no pun intended) of the device being exposed to different voltages / polarity when someone accidently plugs in the wrong PSU. For the sake of approx 2 euros added to BOM cost, it might make sense to include a switching regulator in the circuit if you are not already planning to do so.
Yes, this is a good idea. Will add a little DC/DC converter with up to 18V input.
I'm also thinking of adding a small charge pump (double voltage) for creating 10V on ML pin 12. Looking at the manual of BL active it watches this pin for going above 7V (low behind the transistor). Since I don't want to add the complete ma/sl pull circuit from e.g. the overture I will add what is shown on the last page of BL active manual plus an enable/disable possibility. Isn't a very save solution but worth a try on the first prototype.
Also it could be worth trying the IR eye with 3V3 instead of 5V since the I2C port expander will also work at 3V3. Would be interesting how much the range suffers. Cost reduction would be minimal and I really think that it is better to include those both mosfets needed for level shifting...
BeoMotion:The 4 port connectors I found were all more expensive than using single ones.Since those are the only THT components we could save some money switching to SMT. I don't want to do so because I already saw them falling off...
Yes, I did think if the four port connectors were available in SMT this might be an option as they would likely be much less prone to being pulled off the PCB than individual ones, but I can only find them in TH so there is really nothing to be gained here unfortunately.
BeoMotion:Yes, the main reason is to have all connectors on one side. The polyfuse on RPI is not a problem since exceeding this value something would be really going wrong. I thought about placing a similar one behind the barrel jack.
Yes, I thought with 4 usb ports on the RPi B+ it might not be so hard to exceed 1.1A (especially as the max usb output can be switched from 600mA to 1.2A) but it seems the B+ has a 2A polyfuse for this reason. I think placing a 2A polyfuse behind the barrel would be good as it might provide a little protection if something is shorted accidently whilst "experimenting". Depending on the minimum input voltage of the DC/DC converter chosen, we might need a 6V+ PSU if we use a series diode for polarity protection. Alternatively the diode could be in parallel after the polyfuse if we don't mind the fuse being sacrificed if polarity is accidently reversed (alternatively there is a recommended circuit in the HAT spec that has a much lower volt drop than using a series diode).
BeoMotion:I'm also thinking of adding a small charge pump (double voltage) for creating 10V on ML pin 12. Looking at the manual of BL active it watches this pin for going above 7V (low behind the transistor). Since I don't want to add the complete ma/sl pull circuit from e.g. the overture I will add what is shown on the last page of BL active manual plus an enable/disable possibility. Isn't a very save solution but worth a try on the first prototype.
Good idea. I though after I made the suggestion of the DC/DC converter on the input that this might also allow us to use a 10-15V PSU and therefore have a source for this voltage - perhaps with a physical jumper to enable/disable (much the same as adding the BLC power box), but your charge pump idea would be much much safer - I don't really like the idea of coupling the PSU input directly to other (potentially very expensive) masterlink devices because of the same possible polarity and voltage risks I've already outlined for the interface itself.
BeoMotion:Also it could be worth trying the IR eye with 3V3 instead of 5V since the I2C port expander will also work at 3V3. Would be interesting how much the range suffers. Cost reduction would be minimal and I really think that it is better to include those both mosfets needed for level shifting...
Yes, it's definately worth trying, but I agree, it would be best to have the level shifting in place for the prototypes. We can then experiment, and if we determine we can do without this then it can be removed in the future.
Kind Regards,
Looks like this is getting very real now. Great to see and happy to see this "project" moving along.
Two questions:
1) WIll this require mt to have two power supplies? One for the RPi and one for the PCB? Or would one be sufficient?
2) What is the default use of the IR eye? Is there a PUC that can be used for it? If so, which one?
Hi Steve,
steve1977:1) WIll this require mt to have two power supplies? One for the RPi and one for the PCB? Or would one be sufficient?
Just the one - the idea is that the Raspberry Pi and the ML interface would sit side by side in a case such that almost all of the connectors are along the back of the case (including the new barrel type power connector). Plugging a power supply into the Interface will also power the Rastberry Pi, or, if you don't have them mounted like this, and prefer to power both units with an existing PSU through the micro-USB connector on the RPi itself, rather than through the barrel connector, this should work too (subject to final design considerations).
steve1977:2) What is the default use of the IR eye? Is there a PUC that can be used for it? If so, which one?
The IR eye socket will allow the connection of a B&O eye, and will support reception of IR direct from a beo4 / 5 / 6 / beoremote One as well as use of the buttons on the eye. Alternatively you could connect an alternative type of IR receiver and receive IR from non B&O remotes (or even from the PUC output of a Beovision).
The IR output will support connection of a IR emitter for sending IR to non-B&O devices (in the same way the PUC output on a Beovision does).
The actual codes are configured in software so could be tailored to suit depending on the application.
The first stage is the design and production of the hardware and then comes the not insignificant task of writing the software. BeoMotion has / is doing an excellent job of designing the interface to be as flexible as possible and support as many potential usage scenarios as we can think of but all of these will require software to be written. We will undoubtably need to decide upon and focus on a small number of applications initially and then expand on these over time.
Both the hardware designs and the software we develop will be open source, so the hope would be that once we have some initial functionality implemented there may be others with some software development experience who may wish to get involved and contribute and expand the functionality further - perhaps adding functionality which we haven't even thought of at this stage.
One step at a time though - the first goals must be to produce some working hardware, and to gain sufficient understanding of the Masterlink protocol through reverse engineering to be able to interact reliably with other devices on the masterlink network. Then the real fun can start...
Great to see the project evolving! Hardware:- electrical security for all devices is a MUST. That thing must be idiot-proof and there should be no risk of damaging any ML-equpiment. If the raspberry dies it can much easier be replaced than e.g. a Beovision 7. ;-)- mechanical stability: I would go for a standard plug for the power source instead of micro USB which tends to break easily (like seen on mobile phones...).- maybe one or more status LEDs (no SMD, just old-school 3mm LEDs) installed so that the user can see from the outside "Ah ok, it works, seem to have power!" etc. Not like on the Beolink active or Beoport where you must take an educated guess if it's working or not.- IR-receiver: as we ALL are used to the great range of Bang & Olufsen remote controllers, I wouldn't lower the level if the range is shortened to e.g. 50% because of that.- IR-to-ML- will be very nice as we could send Light and Control commands to the MLGW/BLGW and would have more options to e.g. HUE-control in more places.- IR-ML-IR as an easy Masterlink-IR transmitter for greater multiroom light control in rooms without compatible B&O products. Here it would be suitable to just use a cable with 3,5mm jack on one site and an infrared-transmitter on the other side. That would support hidden installation. Or we could use the round aluminium eye and place a transmitter inside for the people who love the look of it. But I guess if there's 3rd party infrared support, it has to be a very strong emitter - like on the great Lintronic device.The whole system should NOT depend on a Ethernet-Network. It should just work in a ML-Network. Ethernet can be an added bonus for extended functionality.Reading and participating on this thread I'm starting to think that I should have studied engineering instead of economics & management. Keep going with the great work!
riverstyx: steve1977:2) What is the default use of the IR eye? Is there a PUC that can be used for it? If so, which one? The IR eye socket will allow the connection of a B&O eye, and will support reception of IR direct from a beo4 / 5 / 6 / beoremote One as well as use of the buttons on the eye. Alternatively you could connect an alternative type of IR receiver and receive IR from non B&O remotes (or even from the PUC output of a Beovision).
Got it, so with the included IR receiver, I would need the Beo4 to control and cannot attach the PUC. This may work for me as well depending on the strength of the IR eye. I would like to hide-away the RPi in a cabinet, so doubt the Beo4 will be strong enough to bring the signal through?
I actually already have a IR receiver attached to my RPi, but this one is MCE compliant and my BV5 does not have a PUC to support it. So, are there other IT receiver that my BV5 would have a PUC for? I do not mind buying another IR receiver as long as I can finally control Kodi with my Beo4/BV5 through PUC
riverstyx:The first stage is the design and production of the hardware and then comes the not insignificant task of writing the software. BeoMotion has / is doing an excellent job of designing the interface to be as flexible as possible and support as many potential usage scenarios as we can think of but all of these will require software to be written. We will undoubtably need to decide upon and focus on a small number of applications initially and then expand on these over time.
It is really a pity I have no codign experience and cannot contribute to the software development. I agree and am happy with the smallest functionalities. I have a lot of great ideas, but am already happy with "just" allowing the new device turn on (and off) my BV when sensing a signal.
One thought though - on what platform will be used for the coding. I - as probably most RPi users - use Openelec for Rpi. Would this be the base for future coding?
Hi TWG,
Thank you for your input.
TWG:- mechanical stability: I would go for a standard plug for the power source instead of micro USB which tends to break easily (like seen on mobile phones...).
Yes, that's one of the ideas behind using the barrel connector rather than relying on the micro USB on the RPi itself - the other being that we bring the connections to the back of the case.
TWG:- electrical security for all devices is a MUST. That thing must be idiot-proof and there should be no risk of damaging any ML-equpiment. If the raspberry dies it can much easier be replaced than e.g. a Beovision 7. ;-)
Indeed. One of the advantages of the micro USB connector employed on the RPi is that pretty much any power supply with this connector will be 5V, whereas there are many devices such as set-top boxes and internet routers etc that use barrel connectors and the power supplies for these therefore tend to vary in voltage. So by adding regulation and polarity protection we protect both the interface and the RPi (and in turn, other connected masterlink devices) whilst allowing ourselves to safely use a more physically robust connector.
TWG:- maybe one or more status LEDs (no SMD, just old-school 3mm LEDs) installed so that the user can see from the outside "Ah ok, it works, seem to have power!" etc. Not like on the Beolink active or Beoport where you must take an educated guess if it's working or not.
That's an interesting thought. There is already a SMD power LED on the RPi so I'm not sure there is much to be gained by adding a further LED soldered onto the interface PCB - especially as we want to avoid through hole components wherever possible to keep assembly costs to a minimum. Any LED is also likely to be of little value once enclosed inside an case.
It might though make sense to include a pair of pads such that a 5V through hole LED or 5V panel mount LED on flying leads could be soldered to the board by the end user if they wished to do so. A similar pair of pads already exist on the RPi that can be used for adding a reset button. BeoMotion: what are your thoughts on this?
TWG:- IR-receiver: as we ALL are used to the great range of Bang & Olufsen remote controllers, I wouldn't lower the level if the range is shortened to e.g. 50% because of that.
Yes, it could be that operating the B&O IR eye at 3.3V will result in no difference in behaviour or range, but this can only be verified by testing. The cost saving from doing so would be small so for the time being we will implement the level shifting required to operate the eye at 5V.
TWG:- IR-to-ML- will be very nice as we could send Light and Control commands to the MLGW/BLGW and would have more options to e.g. HUE-control in more places.
Yes, light & control to ML is one of the easier features to implement so is like to be an included feature in pretty much any of the planned applications.
TWG:- IR-ML-IR as an easy Masterlink-IR transmitter for greater multiroom light control in rooms without compatible B&O products. Here it would be suitable to just use a cable with 3,5mm jack on one site and an infrared-transmitter on the other side. That would support hidden installation. Or we could use the round aluminium eye and place a transmitter inside for the people who love the look of it. But I guess if there's 3rd party infrared support, it has to be a very strong emitter - like on the great Lintronic device.
Transmitting IR to third party devices (which typically operate at carrier frequencies of 36 or 38kHz) is straightforward to achieve in software and multiple emitters could be connected to the IR-out to send pulses in more than one direction.
Generating accurate B&O IR signals (at 455KHz carrier frequency) is more difficult in software though, which is why the range and reliability tends to be lower than what we would normally experience with a beo4 for example. This can however be overcome by designing a slightly more complex emitter (with the modulation being performed in hardware by the emitter) and this would still connect to the same IR-out jack on the BeoPi interface.
TWG:The whole system should NOT depend on a Ethernet-Network. It should just work in a ML-Network. Ethernet can be an added bonus for extended functionality.
In some cases it might be that configuration changes for a given application would be easiest to achieve by plugging the device into the network as web based configuration tends to be easier for the end user than editing configuration files directly, but there will be no requirement for the ethernet to be plugged in more generally unless the application that the interface is being used for requires this.
For example a simple IR->ML application would have no need for a network connection, but using the device as a streaming media player obviously would.
The beauty of the SD card slot on the RPi is that images can be created for a variety of different applications allowing the entire function of the device to be changed simply by swapping SD cards.
It's common for manufacturers to take the same approach in their designs, especially with the modern tendency for devices to be microprocessor based - I suspect for example that the BLGW and the NL/ML converter are identical hardware wise - it is likely that they just run different software. It is not usually in a manufacturers economic interest to allow the end user to easily re-purpose their hardware though, especially when they are being sold at substantially different price points.
steve1977:Got it, so with the included IR receiver, I would need the Beo4 to control and cannot attach the PUC.
We wont be including any IR receiver. You can either use a B&O IR eye (for receiving IR from a beo4 etc), or a generic IR receiver for receiving IR from third party remotes or from the PUC output of a Beovision.
steve1977:This may work for me as well depending on the strength of the IR eye. I would like to hide-away the RPi in a cabinet, so doubt the Beo4 will be strong enough to bring the signal through?
It depends on what the front of your cabinet is made from - IR is light (just not within the visible spectrum), so it will pass through glass, but not through wood, metal etc..
steve1977:I actually already have a IR receiver attached to my RPi, but this one is MCE compliant and my BV5 does not have a PUC to support it. So, are there other IT receiver that my BV5 would have a PUC for?
You can probably already reconfigure LIRC on your Raspberry Pi to learn codes from any of the existing PUCs on your BV5 to control it this way. It might be configured by default to recognise the MCE remote but there should be no reason why you cannot change this. Look for tutorials online regarding configuring LIRC.
steve1977:One thought though - on what platform will be used for the coding. I - as probably most RPi users - use Openelec for Rpi. Would this be the base for future coding?
There are two relevant considerations here:
Choice of distribution:
Openelec is a distribution - a bundle of a linux kernel and GNU tools (which together make the operating system) together with a graphical user interface, a package manager, and a collection of applications (including Kodi). There are many different distributions and each have their strengths and weaknesses. Openelec might be great as a dedicated media centre, but would be way down the list if I was looking to build a web server for example - I'd want a different set of applications, and wouldn't want a graphical user interface at all because it would waste CPU cycles that could be better spent serving web pages ~(and since I would like be maintaining the server remotely it would be unlikely I'd ever connect a display.).
For the same reasons, our selection of distribution may be different for different applications of the interface. A much simpler and smaller distribution would probably suffice for some of the simpler applications. We don't need the ability to play full HD video on an IR light and control -> masterlink box, nor on a MLGW type box, but we would want a web server on the latter for configuration and control purposes. Because a distro is simply a collection of software, we can install our masterlink specific software on any distribution.
Choice of programming language:
I've learnt (and in many cases forgotten!) many (at least a dozen) programming languages over the years.For the reverse engineering stuff I'm currently coding in Perl as it is well suited to the work involved. It may be that some of the lower level masterlink specific code ends up being written in C (primarily for speed and efficiency), with other parts being written in Python given it is a popular choice on the RPi and so is likely to have the widest appeal and therefore the greatest chance of enabling others to contribute. I'm not currently familiar with Python but it really doesn't take long to learn a new programming language if you are already familiar with the concepts.
You got me intrigued to learn a programming language ;-) I believe though that I am hopeless as I have never learnt any (except a bit of VBA), so I doubt that I would be of any use here...
Fantastic to hear that you see a chance that I can already today use LIRC on my openelec distribution to use the PUC. That sounds fantastic and I will look into it.
I am not dependent on openelec, so any other platform will go well for me (and others I guess). I see Kodi as a critical element and would assume I am not on my own. I tried other distributions in the past that run Kodi, but openelec appears the by far best supported one. If I read you right, you would see a B&O-specific distirbution, which could run many things (incl. Kodi)?
riverstyx: steve1977:I actually already have a IR receiver attached to my RPi, but this one is MCE compliant and my BV5 does not have a PUC to support it. So, are there other IT receiver that my BV5 would have a PUC for? You can probably already reconfigure LIRC on your Raspberry Pi to learn codes from any of the existing PUCs on your BV5 to control it this way. It might be configured by default to recognise the MCE remote but there should be no reason why you cannot change this. Look for tutorials online regarding configuring LIRC.
Spend some time googling about getting the Beo4 to remote to work with the AppleTV PUC. Some indications that it works, but also saw the link below that says that B&O not supported ("these protocols are supported by the IRMP library, but have been disabled due to program space limitations of the microcontroller." http://www.msldigital.com/pages/more-information). No clue what this means. Any idea whether it may still work somehow?
steve1977:I am not dependent on openelec, so any other platform will go well for me (and others I guess). I see Kodi as a critical element and would assume I am not on my own. I tried other distributions in the past that run Kodi, but openelec appears the by far best supported one. If I read you right, you would see a B&O-specific distirbution, which could run many things (incl. Kodi)?
It's really way too early to make any firm decisions at the moment but openelec is unique in that it is not based on any other linux distro (eg debian, arch etc,) and updates itself in its entirety rather than on a package by package basis - this makes it more difficult to customise with additional software (in our case the ML software) or to retain any customisations after an update. It's also really only a suitable candidate for the media server usage scenario as you wouldn't want Kodi running on a MLGW alternative for example.
I envisage us releasing a number of different SD Card images to suit different usage scenarios for the interface and would probably aim to base all of these builds on a single distribution as this will minimise the amount of work required in keeping things up to date and working. My personal preference would likely be a debian derived distro and to create an apt repository for our software, but as I mentioned we really don't have to worry about this right now. Any media centre type SD card image would obviously include Kodi.
steve1977:Spend some time googling about getting the Beo4 to remote to work with the AppleTV PUC. Some indications that it works, but also saw the link below that says that B&O not supported ("these protocols are supported by the IRMP library, but have been disabled due to program space limitations of the microcontroller." http://www.msldigital.com/pages/more-information). No clue what this means. Any idea whether it may still work somehow?
Forget about anything B&O IR / beo4 related. The IR commands sent out from the Beovision PUC output are not B&O IR commands. If you set the PUC to appleTV for example, the IR that is sent out of the PUC is exactly the same as what would be sent when you press a button on a genuine apple TV remote. You can either configure LIRC by learning each code, or you can look for a guide specific to configuring it to be controlled by an apple remote rather than an MCE remote.
These pages might help:
http://openelec.tv/forum/103-infared-remotes/67150-apple-remote-with-generic-built-and-ir
http://wiki.openelec.tv/index.php?title=Guide_to_add_your_own_remote
I'm happy to help further if I can, but note though that I haven't tried this personally, and I don't know exactly what type of IR receiver you have so it will be a case of trial and error. In any case it would probably be best to open a new thread if need be as this is not really the right place for this discussion.
I don't want that this becomes a never ending story so I decided to make a small data-only PCB for prototyping first.
The layout is finished but before I send it to production I will try one more thing.
All of the original ML circuits seams to be very well protected so I decided to give it a try with a 3V3 RS485 transceiver.I just ordered some and I think they should arrive tomorrow. Let's see what happens...
Just to let others know... A friend and Iare going to try an get Masterlink Data signal from an Arduino...
Beoworld app with direct photo upload and emoticons.
BeoMotion:I don't want that this becomes a never ending story so I decided to make a small data-only PCB for prototyping first.
This makes perfect sense to me as it will also allow us to iron out any issues we encounter with the design whilst prototyping, prior to having the final boards manufactured.
BeoMotion: The layout is finished but before I send it to production I will try one more thing. All of the original ML circuits seams to be very well protected so I decided to give it a try with a 3V3 RS485 transceiver.I just ordered some and I think they should arrive tomorrow. Let's see what happens...
I don't think this will work but I've replied in more detail on the other thread as my reply is rather too technical in nature for this one...
(actually, my reply on the other thread has gone for moderation, but with luck it will appear shortly)
PhilLondon: Just to let others know... A friend and Iare going to try an get Masterlink Data signal from an Arduino...
Hi Phil,
That's great, please keep us updated with progress and if you succeed at the signal level hopefully we can help each other to make progress at a protocol and software level.
Beovision 12-65 NG, Beosystem 4, Beolab 7.2, Beolab 6000, Beolab 5, Beolab 4000, Playmaker, Beogram 5005, Beo4, Beo5, Beovision 7-32 MK3 (2x), Beovision 4.42, Beosystem 2 HD, Beolab 7.1, Beolab 7.4, Beovision 10-32, Beovision 6-26, Beosound Moment, Beosound 2300, Beosound Ouverture, Beogram TX2, Beogram 2404, Beomaster 3002, Beovox CX 75, Beovox CX 100, ibundo, Keyring.......
Newbie:Are there any news?
Hi all,
over the weekend I tried to send some data using the RS485 transceiver IC.Of course it didn't work but I couldn't resist in trying it.In the technical thread you will find a nice explanation why (by riverstyx, thanks!).
During designing the PCB there popped up a problem on the audio part.Might not be a "real" problem but the audiophile part in me says that driving analog audio switches and OP amps from a noisy +- 5V rail is not that ideal. This is also one of the reasons why there will be a data-only version first. We need some experimentations on the audio part which are better done using breadboards rather than manufacturing a new PCB each time...
I'm sure that I will send the gerber files into production by the end of this week. All parts are kept as small as possible (SC70 / 0402 range) to reduce the PCB size and cost to an absolute minimum.I'll also put the python code for receiving and interpreting ML DATA on GitHub in several days.I'll keep you updated on this.
In the very beginning I also experimented with arduino. In theory it could be possible to use the analog pins for receiving data from ML+. This would require a lot of programming and you might run into timing problems... Since a SBC is much more flexible than a normal Arduino it should be preferred for prototyping and figuring out how the protocol works. If we know everything about it can easily be ported to other platforms.
BR,BeoMotion.
Great to see the progress, thanks!
Out of curiosity, what functionality would be supported by a data-only ML version?
steve1977: Great to see the progress, thanks! Out of curiosity, what functionality would be supported by a data-only ML version?
Same as MLGW. So sending and receiving data only.
Input:
Output:
The aux header is 90 deg and on the right side of the PCB. So if prototyping is successful we can go the modular path and simply stack in an IR or audio PCB.
Got it, so this is for home automation, right? And sending audio to BV may eventually follow at a later stage. Please keep us posted on the progress.
Think positive: We finally will have a small box that is able to send Light and Control commands to the ML-Bus whereever it's installed! :)
I'm thankful for the effort and respect the hard work! Keep going.
the last days were much more busy for me than initially expected so the progress here slowed a bit down.
Today I replaced the inverting DCDC converter with a much smaller one that even offers a higher efficiency and a bit more power.I also optimized the solution size of the ML-DATA TX part and added the little charge pump for the positive ML power rail.Since the audio part might get a bit more expensive I really want to reduce the size of the DATA PCB to an absolute minimum to keep the cost down.At the moment I am expecting the fully populated and ready-to-use DATA PCB to be around 30,- Euro.
Sorry for the delay but I don't want to hurry through it and maybe have a great idea after I send out the layout files to production :-)
So the only thing left at the moment is to translate the recent schematic changes into the PCB layout and check everything again.
You don't need to excuse yourself for the delay. I'll rather wait for a finished and reliable working product! :-)
Fully agree, We are everly grateful for you spending your time on this exciting project.
Finally!
All components placed and ready for production.Routing was a bit time consuming since I wanted to stay with 2 layers... To reduce some cable clutter there is passthrough for I2S+I2C for the audio PCB.Tomorrow I will check everything again and send it into production.With some luck the PCB's should arrive by the end of next week. :-)
Nice work BeoMotion.
Looks good and I can see why the routing was so time consuming!
It looks like it might even fit inside a matchbox...
Very cool. That's the data version, right?
steve1977:Very cool. That's the data version, right?
Yes, that's the data version / prototype - the idea is that later an audio board will attach to this.
I think BeoMotion is right to take this modular approach. It ultimately allows costs to be kept low for those who don't require all the extra bells and whistles, but more importantly it drastically reduces the financial risks if a mistake is made with the design or if the prototyping identifies changes that need to be made as only that particular PCB would need to be re-designed and manufactured again.
The bulk of the work next will be in figuring out the finer details of the masterlink protocol and designing / writing the software needed to get the RPI + interface to reliably communicate with other devices on the ML network. Really only once this has been achieved will the audio side be possible so from this perpective too it makes sense that the hardware functionality matches (and in some senses helps to focus) the development work that is needed on the software side.
Thanks for the explanation, riverstyx.
Few minutes ago I ordered 6 PCB's. Let's see when they arrive. Normally the production can take up to 8 working days but they were always faster on my last orders.So with a bit luck the PCB's could arrive next friday. This will give me some time to order the components...
Will keep you updated.
I'm excited: light & control command receivers all over the house!
@beomotion,Thanks for sharing your schematic with us. It is looking a nice project.
I think the power barrel connetion is the more robust and relable connection than the microusb connector of RPi, because the connector is on the same face as the other connectors. and provides the greater flexibilty on maximum power also.
pcb cost
RobbDicks:I think the power barrel connetion is the more robust and relable connection than the microusb connector of RPi, because the connector is on the same face as the other connectors. and provides the greater flexibilty on maximum power also.
The barrel connector was only meant for the all-in-one PCB. At the moment we have switched over to a more modular path where all the power comes from the SBC. If you go for a BBB instead of the Pi you will have a barrel connector directly on the SBC.
The production of the first prototype batch is nearly finished. Time to order the parts now...
BR,BeoMotion
All parts are ordered now!In a couple of days everything should arrive and I can start with assembling.
If those 6 prototype PCB's are functional: let me know if somebody wants to have one of these. I could give away three under the condition that you are able to help with testing and programming.
I'm interested but I can only help in testing, not programming. ;-)