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 everyone!
A month ago, or so, I got the idea to do something about the annoying separation between my Beosystem 7000 and my Mac. The BS is of course nicely controlled with the remote, but the Mac is not. I do listen to both my iTunes library and Spotify a lot, so the nuisance was kind of there all the time. I figured that it must be possible to use the data signals sent from the beomaster to the other units and have the computer act accordingly.
I started searching the forum, thinking that others had done this before, but to my surprise I found almost nothing (and that's why I figured I'd write this post.) I then googled for microcontrollers, and the choice fell on the Aurdino Uno Rev 3. In part because an electronics retailer not 10 minutes walk from my home has them, but mainly because it's dead cheap, about the equivalent of $30. I went and got one the same day.
My next problem was that I don't have an oscilloscope, and even if I had one, I'm not sure I know how to use one, and even if I did it wouldn't be one of those expensive ones that can record signals for off-line inspection. I found the MCL2 technical description on the site which describes the MCL2 format, and I thought that it'd be worth a shot. I connected the board to the TAPE 2 socket on the back of the BM and wrote a program to record whatever the BM was sending. It made no sense at all. The MCL2 standard uses PWM coding, and interpreting datalink signals as PWM gives you jibberish, I assure you. :-) I then figured it might be standard serial communication, so I tried that. Success! It worked. It turned out that the datalink format uses the same bit-times as the MCL2 format (3,125 millis), and that was just a lucky guess.
The datalink format, as far as I can tell, works thus: it is serial communication with 8 bit bytes sent MSB first. The first bit is always a 1, to allow synchronization, then 7 information carrying bits. It is active low (so low means 1), and each bit is 3125 us long (the MCL2 standard allows a maximum error of 312 us, and possibly there is something similar for datalink, but since you can resynch every 8 bits, it shouldn't be anything to worry about.)
Some commands are:
Play: 0xABStop: 0xB5>>: 0xB1<<: 0xAFUp: 0x99Down: 0xB3Number: 0xBCStby: 0xCB
Numers are sent in decimal form and one digit at a time. So 12 would be sent as first the 1 and then the 2. Also, before the numbers 0xBC is sent to start the sequence. The sequence of numbers is terminated by 0xAB (Play). Now for some reason the numbers are shifted one bit to the left, eg 1 is 10000011. So you need to right-shift them to get the right number (and also unset the MSB of course).
There are lots of other things sent as well, in particular when you swith to CD, and I haven't figured out what half of those things are, and since I don't need them I probably wont bother.
Anyway, I wrote some code to receive these commands and relay to the computer via USB. The Arduino board has a simple and easy-to-use library to for serial communication over USB. All I had to do was to write a program on the Mac that detects when the board is connected (and disconnected) and opens a serial port to talk to the board. Then it waits for commands and acts appropriately, by sending AppleScript events to either iTunes or Spotify, whichever is playing at the moment.
I realize now that this post didn't get as technical as I'd hoped. Apparently it's easier to write prose and be vague than to write down hard-core details in a note like this. Even so, I'll be happy to answer any questions you might have!
What turned out to be trickiest with this project was to build a suitable box for the thing. It's kind of prototypical, because I used stuff I had home or stuff I could get quickly and easily to build it. I might build a prettier one some day, now that I've learnd a thing or two (especially how to make holes that are not round).
Here is is:
One end has USB and two phono connecttions. This is the "computer end".
The other end has a 7-pin din socket to connect to the BM:
The inside looks like this:
So what was the end result? I'm a much happier man, having done this project. My (old spare) Mac sits connected to the beomaster all the time and is happily responding to my commands on the remote.
As I said, I'll be happy to answer any questions, should you like to proceed on a similar project!
/ Johan
Edit: I decided to put in a little extra circuit, and the reason is twofold: first, I wanted to limit the current flowing between the two uCs. Second, I realized that when the board is connected to the BM but the USB is disconnected the board shorts and hogs the uC in the BM, which doesn't work properly. So, I put in a transistor and a couple of resistors (very similar to the relevant part in the BG CD5500 service manual). I would also like to acknowledge and thank Mika (tournedos) who helped me with this. / Johan
Well, all I can say is very nice & well done :) Now knowing all the mac lovers on this forum, I wouldn't be surprised if you get a few commissions :)
Olly
Thanks! Yeah, it's been a satisfying project, in many ways. :-)
Note, though, that this is not bound to the Mac, per se, writing the equivalent program for M$ or some Linux is probably not that difficult for someone who knows those platforms (or is willing to learn.)
very interesting. It would be nice if you can post the connection scheme to the Arduino bord and the code
How would you compare the capabilities of your solution with B&O's BeoPort ?
I suspect the BeoPort offers a number of "bells and whistles", but compared to what the "average" B&O user wants you may tick all the boxes ?
BeoNut since '75
elephant: How would you compare the capabilities of your solution with B&O's BeoPort ? I suspect the BeoPort offers a number of "bells and whistles", but compared to what the "average" B&O user wants you may tick all the boxes ?
Well, I guess it's really only a matter of how much work one wants to put into it. The hardware would probably allow most of what the BeoPort can do, it's the software that does the real work. I only bothered to implement the things I use (though that might change in the future, who knows..?), i.e., Play/Stop/Next/Prev and standby. I see no real limitations. Also, the software I have right now does not send anything back to the BM, but I might fix that. I will be moving shortly, and in my new place I will build myself a link setup. There it would be nice to have a display in the kitchen revealing the source, volume etc of the main system.
Any particular feature you were thinking of?
Disclaimer: I've never used a BeoPort (or even seen one), so I'm not really sure what it can do. There may be things that are harder to implement than other things, but in my experience it's usually only a matter of subbornness and time to get what you want.
pacificocean: very interesting. It would be nice if you can post the connection scheme to the Arduino bord and the code
Personally, I hope the OP keeps this to himself, to prevent unscrupulous individuals selling his hard work ;-)
Amazing work Johan, really !
Congratulations...
Step1: pacificocean: very interesting. It would be nice if you can post the connection scheme to the Arduino bord and the code Personally, I hope the OP keeps this to himself, to prevent unscrupulous individuals selling his hard work ;-)
The connection to the board couldn't be any simpler: ground pin on board to ground on 7-pin din socket, and one of the digital pins (whichever you like) to pin 7 on the din. That's it.
I won't post the code, partly because it needs a clean-up. :-)
I will, however, happily answer any questions and give tips etc. to any fellow beoworlder who wants to build one. It's really not that difficult.
For the record, the hardware I used is:
1 Aurdino Uno Rev 3 ($30 - $35 or in the vicinity)1 7-pin din socket ($1)2 phono plugs (from a few cents to infinity)The usb socket is the one from the board, which I desoldered. But those are probably around $2, or something.And some cable.
Pretty cheap, not counting the hours of work figuring out the datalink protocol.. but even that was a lot simpler than I had thought.
Emmanuel92: Amazing work Johan, really ! Congratulations...
Thanks! :-)
Johan: 1 Aurdino Uno Rev 3 ($30 - $35 or in the vicinity)1 7-pin din socket ($1)2 phono plugs (from a few cents to infinity)The usb socket is the one from the board, which I desoldered. But those are probably around $2, or something.And some cable.
Oh, and the box, of course. That was about $5, I think.
First of all, congratulations! Very well done without an oscilloscope
My application is currently completely on IR side; I receive the B&O commans with an Arduino (actually a Teensy, a smaller AVR board with a bit more advanced processor and more versatile USB connection). It then controls my Nokia STB directly via IR. It is also connected via USB to my Linux VDR box, where a PHP script with a bit more intelligence converts the remote semantics so that the VDR can be used with a Beo4 (quite a pain to achieve actually, as there simply aren't enough buttons that also wouldn't do something to the TV itself). I don't think PWM is the correct term to use for the MCL2 / IR traffic although it is similar, with the bit values encoded into different length pulses depending on the current bit value and the one preceding it.
I've been planning to tap on the Datalink peripheral bus (and AVL and SCARTs) as well, but haven't gotten around to it. The problem with those is that they won't show you the traffic of the entire system, only what belongs to that particular bus. For example a.tape1 and a.tape2 aren't differentiated logically in any other way except that they are on separate buses can't see each other's commands. Same with a Beogram and a CD.
--mika
Exactly why I won't be posting any code - nobody else has EVER done it either even though there are always interested parties around
I'm way too lazy to make any commercial products out of my work, but there are enough of these similar projects for sale that I'd rather have those folks spend weeks of their own time coming up with the protocol details that can only be reverse engineered...
Sharing basic ideas is of course much more fun than fighting with them by yourself
Thanks, Mika! Yes, I did some guessing and was lucky, I suppose. :-)
I guess you're right on the PWM terminology.. What I meant was that it uses different length pulses, as opposed to the datalink format that is constant time. As I said, I started out with the assumption that the datalink format was similar to MCL2, and used the table in the MCL2 tech.spec. to decode what I recorded, but it always ended in the "error" state.. which had me change route to normal serial communication. Lucky for me the bit times seemed to be the same.
Of course, you're right on the datalink buses being separated, but for my purposes on this project that's quite enough. I just wanted the computer to work like any of the other peripherals connected to the BM. It does exactly what I want.
tournedos: Sharing basic ideas is of course much more fun than fighting with them by yourself
Agreed!
Awesome work!
I was once thinking of something similar (on IR-side) but didn't have enough patience (or knowledge!). Your final product is exactly what I was hoping to achieve.
Here's mine - eternally waiting for an enclosure it seems
Electrically trivial: the IR reception done by a TSOP7000 wired directly to an interrupt pin, and the transmitter diode directly on an I/O pin (with a series resistor). Doesn't even need a buffer amp as the STB is 10 cm away.
As you can see, the Teensy board has a fitting name... I used to have a full-size Arduino here, but was planning to fit this inside the soap box sized STB some day. It also has an ATmega32U4 processor, which has a high-speed timer/counter that is missing from the Arduino. Therefore it's possible to use the internal peripherals to accurately generate the 455 kHz carrier needed for sending B&O IR commands without any external oscillator. I've implemented it, even though not really using it for anything yet.
Unfortunately the TSOP7000 IR receiver module is out of production. Nowadays it would make more sense to take your route and take advantage of the IR receivers built in every Beomaster and TV, either via Datalink or MCL2 (or Masterlink).
Cool stuff! I like that tiny little thing!
You should definitely mount it inside the box, I'm sure you'll feel very satisfied having done that! :-)
I looked up Teensy, and it seems very attractive, both size-wise and price-wise. I think I'll get a couple of those. The ATmega32U4 sounds very useful for upcoming projects, involving IR. I was looking at external oscillators, but if I can do without that's all the better!
Good tip, thanks!
Would it be possible to connect one of those boxes to two Datalink-buses? E.g. two scarts? I guess it wouldn't be good to connect them together, but with diodes or something? (This is really not my field)
Magnus: Would it be possible to connect one of those boxes to two Datalink-buses? E.g. two scarts? I guess it wouldn't be good to connect them together, but with diodes or something? (This is really not my field)
To accomplish what? I don't think I understand your question..
tournedos: First of all, congratulations! Very well done without an oscilloscope
Actually, Mika, I remember now, after having looked at some old source code, that I did implement a poor man's oscilloscope, of sorts.
What I did was, I measured the inactive voltage on pin 7, and found that it was 5 volts (suggesting that my active-low suspicion was indeed true). Then I wrote a program for the board that detected changes from high to low and low to high, recording the time between such changes. That's what I used to figure out what the structure of the messages looked like. So I guess, I did use an "oscilloscope" after all.. :-)
Magnus:Would it be possible to connect one of those boxes to two Datalink-buses? E.g. two scarts? I guess it wouldn't be good to connect them together, but with diodes or something? (This is really not my field)
Not directly, but there's nothing preventing the same processor from listening/writing on more than one bus. For example in these shoe box Beomasters, the processor is handling four control buses - tape1 / CD, tape2 / phono, MCL2 / AVL / speakers, and the built-in IR transceiver. All this on a ~9 MHz 8032, which has about one 20th of the raw processing power of the 16 MHz AVR in Arduinos.
The B&O engineers probably needed some clever timing critical assembly coding to achieve this though, while we can wuss out with plain C
The data buses on SCARTs aren't quite this simple to use, though. They are at a much smaller signal levels than straight TTL, and depending on what's connected, may be riding on a DC offset (they share pin 8 which is used for switching and aspect ratio control).
Johan: To accomplish what? I don't think I understand your question..
Control two different boxes/PCs.
tournedos: Not directly, but there's nothing preventing the same processor from listening/writing on more than one bus.
Not directly, but there's nothing preventing the same processor from listening/writing on more than one bus.
Ah, okey. The reason for asking is that I have a Lintronic box (great box for us who cannot build our own!). It can listen to commands from pin 8 on scart, but it only has one input. Therefore it would be nice if it was possible to connect two together somehow, so that it could control two boxes.
Magnus: Ah, okey. The reason for asking is that I have a Lintronic box (great box for us who cannot build our own!). It can listen to commands from pin 8 on scart, but it only has one input. Therefore it would be nice if it was possible to connect two together somehow, so that it could control two boxes.
Splitting the signal and have it go to two boxes is easy enough and probably works, but then you have the next issue, which is how to have the two boxes agree on which should react to a command. They'd both get the same command at the same time, kind of like when you have two IR devices in the same room. Now, one could probably add something in between that selects one or the other, but that would require some wiring/programming.