in Search
Untitled Page

ARCHIVED FORUM -- April 2007 to March 2012
READ ONLY FORUM

This is the first Archived Forum which was active between 17th April 2007 and 1st March February 2012

 

Latest post 09-12-2010 5:41 PM by tournedos. 19 replies.
Page 1 of 1 (20 items)
Sort Posts: Previous Next
  • 11-19-2009 4:44 PM

    • Stoney3K
    • Top 500 Contributor
    • Joined on 10-26-2007
    • Eindhoven, NL
    • Posts 91
    • Silver Member

    Decoding Datalink

    Hi all,

    Since a few years I'm in possession of a Beomaster 2000 receiver and accompanying Beocord cassette deck. The unit was originally owned by my parents and was put aside as being defective due to a lightning strike several years ago, and I got the whole set for free. (Unfortunately, the matching Beogram was trashed because of a wasted pickup).

    I eventually pulled the unit apart with the service manual alongside it and disconnected the tuner circuit, which seemed to output static on all inputs (including PH and TP), and the unit has been my primary amplifier ever since, with a pair of Magnat speakers. I suspect the lightning caused a power spike on the aerial which blew the HF filter caps, causing them to leak noise to the power or ground rails.

    Anyway, I've just moved into my new flat and started on a project to get the Beosystem back to its original glory, with improvements. Since the system is used  as an amplifier for other audio sources (DTV, HTPC, Wii, Bluray) as well, I decided to have a look at the Datalink system that's featured on the BS2000 series, and maybe implement a USB to/from Datalink interface so I can integrate the AV system in my home automation network.

    On all Beosystem 2000 units, the main CPU is a  8048 microcontroller with the Datalink connection wired to a GPIO pin. The 8048 didn't have an internal UART, and all Datalink connections seem to be hard-wired together in the Beomaster. For some reason, Datalink is on pin 6 for the Phono port and  pin 7 for the Tape port (see board 2 schematic in the service manual). I'm not  sure if the 8048 has any open-collector I/O pins, nor do I have any idea on how the MCU's arbitrate the bus to prevent simultaneous writes.

    Ultimately, I'd want to figure out the protocol format and control codes for the 'old' Datalink, so I can connect my own hardware to it to respond to Datalink actions (like pressing a program key) or control the system remotely (e.g. a master standy function for all AV equipment). I can also use the remote decoder input of the Beomaster to control the system, but that would involve modifying the receiver from its original state. I have plenty of spare MCU's so building a new Datalink device is pretty easy.

    Has anyone done some research on the old Datalink codes before? I'd figure they're easy to reverse engineer if you hook a scope to one of  the bus pins and sniff out the data when you're performing certain actions. If I want to go the adventurous route, I can try to rip the firmware from the MCU and disassemble it (and possibly drop in a new 8051 with extra features...)

  • 11-20-2009 7:16 AM In reply to

    • Dillen
    • Top 10 Contributor
    • Joined on 02-14-2007
    • Copenhagen / Denmark
    • Posts 5,008
    • Founder

    Re: Decoding Datalink

    Maybe Ridax would be the man to ask.

    Martin

  • 11-20-2009 7:42 AM In reply to

    Re: Decoding Datalink

    I thought BM2000 / BC2000 used the "new" Datalink? Anyway, I haven't seen a single word of description of the old Datalink format (the new/current format is semipublic as far as the frame structure goes). Unfortunately I don't own any of the old format devices, otherwise I would've scoped it a long time ago Smile

    Physically I suppose it is a wired-or bus just lke the current, so the arbitration is similar to I2C: a device sending on the bus must monitor it and detect a collision if the bus wire doesn't agree at any time while sending a high level. At a previous job I had the immense displeasure to maintain some old 8048 code - as far as I remember, at least some of the ports are pseudo-bidirectional just as in 8051. Write a 1 to the port and it activates a weak internal pullup that can be easily driven low by an external signal. Many of the earlier B&O Datalink devices that use either of these processor families have the Datalink buses wired more or less directly to a port pin. Definitely none of them use the UART, the message frames are too long for that.

    I guess the pin 6/7 distinction was there to encourage people to connect the devices to the correct input Smile When the RIAA preamp was moved from the receivers to the turntables, the Datalink pin changed as well.

    As an interesting piece of trivia, all B&O Datalink implementations until 1997 or so contain a bug in the collision detection that occasionally causes messages to be lost. Apparently the protocol contained a few thousand lines of decade old assembly code which was also the main documentation. The bug had proved impossible to trace conventionally, but was finally nailed using a formal state-transition graph analyzer. There was an Aalborg(?) University CS report on this, I'll post the link if I ever manage to find it again.

    EDIT: Found the report - it was published in Proceedings of the 18th IEEE Real-Time Systems Symposium (you need IEEE Xplore access from an academic library, or otherwise, to download the full text), and the unpublished version can be found here (gzipped PostScript, so not directly viewable unless you have the tools).

    -mika

  • 11-20-2009 8:04 AM In reply to

    Re: Decoding Datalink

    tournedos:
    the new/current format is semipublic as far as the frame structure goes

    Have you got any documentation/lins about the protocol... I'll be really interested.

  • 11-20-2009 8:19 AM In reply to

    Re: Decoding Datalink

    Google for "datalink.zip". There used to be a broken link for it in Beotech - might actually be on site somewhere nowadays. The IR remotes use the exactly same data format (but obviously L level on bus  = 455 kHz carrier on).

    EDIT: Yes it's on site - rather confusingly as the MCL2 technical service manual.

    -mika

  • 12-06-2009 7:38 PM In reply to

    • Stoney3K
    • Top 500 Contributor
    • Joined on 10-26-2007
    • Eindhoven, NL
    • Posts 91
    • Silver Member

    Re: Decoding Datalink

    tournedos:

    Google for "datalink.zip". There used to be a broken link for it in Beotech - might actually be on site somewhere nowadays. The IR remotes use the exactly same data format (but obviously L level on bus  = 455 kHz carrier on).

    EDIT: Yes it's on site - rather confusingly as the MCL2 technical service manual.

    I had a look around the manual and found out that it describes the data link format for Beosystem 5000, Beolink 1000, Beovision MX5xxx and other models of the series. That includes the (later models) Beomasters 3500 and 4500, but not the 2000, which uses the old data link format.

    The document does mention that the 'old format' is compatible with the new format, meaning the basic signal timing is identical but only new address and command codes may be added. However, I also recall a mention of some Datalink devices being incompatible with each other (e.g. a 2000 series Beomaster with a 4002 Beogram and the like).

    Is there a difference between those formats as well? I'd really like to upgrade my Beosystem with a tangential tracking turntable, but I want one that can be controlled from my Beomaster. Not being sure of that kept me off purchasing one for the time being.

    EDIT: I got a hold of the IEEE document (hey, it helps when you're an EE student, free IEEE Xplore access!) and there's enough data on there to make a complete implementation of the Beolink (new style) protocol in something like an AVR. I'm not really sure how much of which we could publish it, however, because I'm quite clueless as to when the relevant patent(s) would expire.

  • 12-08-2009 4:12 AM In reply to

    Re: Decoding Datalink

    Goddammit I hate it when you write a lengthy reply and the forum eats it! Devil I'll try once more with as much as I still remember...

    Stoney3K:

    The document does mention that the 'old format' is compatible with the new format, meaning the basic signal timing is identical but only new address and command codes may be added. However, I also recall a mention of some Datalink devices being incompatible with each other (e.g. a 2000 series Beomaster with a 4002 Beogram and the like).

    Is there a difference between those formats as well? I'd really like to upgrade my Beosystem with a tangential tracking turntable, but I want one that can be controlled from my Beomaster. Not being sure of that kept me off purchasing one for the time being.

    The "Ye Olde Format", as I now call it Big Smile, used by BG4004 and I guess 2404, has really nothing in common with Datalink, new or old. The only Beomaster using that format is 2400-2 as far as I understand. The message only contains a couple of bits, and as these Beograms don't even have a microcontroller, is decoded completely with hardwired discrete transistor logic at the Beogram end. I've never seen it documented, but it would be possible (although tedious and boring) to decipher from the Beogram schematic. Would be easier to scope it off the wire, but I only have the BG4004 and it isn't very talkative by itself Smile

    EDIT: I got a hold of the IEEE document (hey, it helps when you're an EE student, free IEEE Xplore access!) and there's enough data on there to make a complete implementation of the Beolink (new style) protocol in something like an AVR. I'm not really sure how much of which we could publish it, however, because I'm quite clueless as to when the relevant patent(s) would expire.

    I don't think it's patented, and that wouldn't prevent any personal use anyway. The state-transition diagrams have been published in that article, so they are public information as well - however, the actual article has copyrights so let's not regurgitate it here.

    A DIY project, which would probably be only point-to-point communication, will manage with a much simpler implementation that doesn't  care about collision detection. That would mostly be an issue on an MCL bus with multiple devices, like a multiroom installation.

    The "future, more automated version of the protocol" mentioned in that document must be Masterlink.

    -mika

  • 12-08-2009 4:58 AM In reply to

    Re: Decoding Datalink

    Where can I find these documents? I have been looking for these for a while. They would be very useful for a project I am doing.

    Thanks in advance for your help.

  • 12-08-2009 5:13 AM In reply to

    Re: Decoding Datalink

    Phil, as I said the MCL2 technical manual is on site, and the other one really contains nothing you wouldn't already know after reading the MCL2 doc (and I already posted a direct link to the freely available version of the latter). It's not really a technical document on Datalink, just a case study on an unrelated software tool.

    -mika

  • 12-08-2009 5:50 AM In reply to

    Re: Decoding Datalink

    Stoney3K:
    Is there a difference between those formats as well? I'd really like to upgrade my Beosystem with a tangential tracking turntable, but I want one that can be controlled from my Beomaster. Not being sure of that kept me off purchasing one for the time being.


    Hi Stoney,

    The Beogram 3000 tangential will datalink with your BM2000. I used to have one with my BM3000, which is nothing more then a remote controllable BM2000. It's a great and good looking turntable!

    I have been following this interisting thread, although I lack a real technical background  I am very interested in datalink for home integration and interlinking older and newer B&O products. Do post any datalink discoveries you make, I am all ears, and I'm sure I'm not the only one!Smile

    Groeten!Wink

  • 12-08-2009 9:46 AM In reply to

    • Stoney3K
    • Top 500 Contributor
    • Joined on 10-26-2007
    • Eindhoven, NL
    • Posts 91
    • Silver Member

    Re: Decoding Datalink

    tournedos:
    The "Ye Olde Format", as I now call it Big Smile, used by BG4004 and I guess 2404, has really nothing in common with Datalink, new or old. The only Beomaster using that format is 2400-2 as far as I understand. The message only contains a couple of bits, and as these Beograms don't even have a microcontroller, is decoded completely with hardwired discrete transistor logic at the Beogram end. I've never seen it documented, but it would be possible (although tedious and boring) to decipher from the Beogram schematic. Would be easier to scope it off the wire, but I only have the BG4004 and it isn't very talkative by itself Smile

    I've got the BM2000 (1983 version, model 2917 IIRC... (*flips over Beomaster... yap!*), which uses the v1 version of Datalink. So, if all goes well, I can use the codes which are mentioned in the MCL2 service manual for Tape1 (tape), Phono (Beogram), Tape2 (DTV/DVD/HTPC) or Tuner. And even then I have some spare addresses to play around with, since the protocol has space for expansion and the Beomaster should happily ignore anything that isn't meant for it.

    I don't think it's patented, and that wouldn't prevent any personal use anyway. The state-transition diagrams have been published in that article, so they are public information as well - however, the actual article has copyrights so let's not regurgitate it here.

    A DIY project, which would probably be only point-to-point communication, will manage with a much simpler implementation that doesn't  care about collision detection. That would mostly be an issue on an MCL bus with multiple devices, like a multiroom installation.

    Beolink is essentially a single-wire CSMA/CD protocol which should be a piece of cake to implement in any recent microcontroller. Keep in mind, that current uC's run on clocks that are in the 4-20MHz range, which gives you plenty of cycles to do anything aside from generating or reacting on Beolink messages. It doesn't implement error correction, the only thing to do in case of a collision (parity error when reading the message back) is jam (pull the bus low for a set amount of time) and repeat the message.

    I'm planning to do home automation, but I want to use Ethernet or DMX512 to control my lighting, as I don't want to burden the Beolink bus with anything I don't need. Although it would be awesome to get a 455KHz receiver, wire it up to the Beolink bus and control the entire system with a Beo4, my current implementation will use a server, web page and touchscreen PC or PDA like an iPod Touch. The Beosystem and all associated hardware will be slaved to the home automation network, not the other way round.

    premiumverum:

    The Beogram 3000 tangential will datalink with your BM2000. I used to have one with my BM3000, which is nothing more then a remote controllable BM2000. It's a great and good looking turntable!

    I'm more inclined to go for the black verison of the BG5500, as it looks a little more like the 'original' BG2000 than the BG3000 does.

    At least I know now that it's possible to link products from the newer (late '80s, early '90s) series with the 1980's Jensen gear, maybe I'll even put a Beosound Ouverture in the bedroom! I already installed a spare CAT5 cable for multiroom audio when decorating my flat, it's currently got L/R audio only, but that also means I got two wire pairs left for Beolink and possibly DMX512.

  • 12-09-2009 3:44 PM In reply to

    • Stoney3K
    • Top 500 Contributor
    • Joined on 10-26-2007
    • Eindhoven, NL
    • Posts 91
    • Silver Member

    Re: Decoding Datalink

    Little update, for the people who would like to fiddle around with the Datalink/Beolink protocol: As the codes are the same as for the B&O remotes, sending and receiving Datalink codes is supported in the LIRC and WinLIRC (Linux Infrared Remote Control) packages!

    The only thing you need are a base resistor (470ohms should be OK) and NPN (BC547/550) transistor for the transmitter circuit, the receiver circuit can be a passive wire to the LIRC input. I'll post detailed schematics later.

    I would have loved to do more research, but I think there's no need to reinvent the wheel, right. Wink

  • 02-27-2010 4:47 PM In reply to

    • Stoney3K
    • Top 500 Contributor
    • Joined on 10-26-2007
    • Eindhoven, NL
    • Posts 91
    • Silver Member

    Re: Decoding Datalink

    Time to give this thread an update...

    The (Win)LIRC trick only works for systems equipped with a remote from Beolink 1000 up, since that's the point B&O introduced a new, multiroom-capable, Datalink format as outlined in the MCL2 service manual. The LIRC codes are programmed from that or just trained from a remote.

    The 'older' (I'll call it 'Type 1' from now on) Datalink format, as used by Beosystems 2000-5000 and later systems between the components, has a simpler frame structure and I'll outline it here.

    Here's the setup I used for reverse engineering the format, it's easy when you have a digital storage oscilloscope with logging capability handy. I made a little gadget which allowed me to eavesdrop on the bus:

    Basically, not much more than a 7-pin DIN plug I scrapped off an old Beocord and a scope probe. Next, I just started hammering some keys on the Beomaster and Beogram and log everything that was transmitted. With some careful examination, here's what I found out:

    • Signals are transmitted as 8-bit codes, with the MSB being the first, and with MSB always 1. This allows the controllers inside the devices to synchronize with the transmitted signal, as they trigger on the falling edge. 7 bits (128 codes) are available for use, and I haven't seen any codes beneath 0xA0 (hexadecimal) in the Beosystem 2000.
    • A full 8 bit transmission lasts for 25 ms (so the bit time is 3,125ms like in the new format), and a message is repeated after a 25ms space to ensure its validity.
    • A logic 'one' is active low, and for the rest, it's more or less a standard serial transmission which you can implement in any microcontroller. In theory, a USART can do it (320 baud, 7 data bits, 0 stop bits, no parity), but building it in software is a lot easier.

    Having collected some data, I started work on a transmitter in an AVR development board, and connected it to my Beosystem (here on the bench for some more convenient testing):

    And the tedious work began, pummeling the Beosystem with random Datalink codes until I found out some useful effect. It wasn't long until I heard a loud, satisfying 'CLICK' from the Beomaster's standby relay -- Success! I have been able to figure out the majority of the Beomaster and Beocord codes (the Beogram still needs some work), and I can already control the whole system without even having to touch it. As far as the actual Datalink functionality goes, that is. Wink

    Some remarks on the DL function (even some that might be surprising):

    • Codes from a specific source (Tape, PH) only function when that source is selected. For example, if you hit STAND BY on a Beocord while the tuner or Phono is selected, only the Beocord will stand by, instead of the entire system.
    • TAPE 2 can be selected from remote sources. The switch on the Beomaster's front panel is only a dumb selector which informs the controller.
    • When recording from PH, a special code is sent to the Beomaster to prevent any intervention (and therefore a faulty recording). In this case, the front panel buttons are ignored.
    • Most, if not all, functions of the Beocord can be operated from Datalink. This is probably because of the later Beomaster 3000, which can operate the tape (and phono) deck with the remote. Seek, pause, play and record are all accomodated in the Datalink codes, however, I haven't been able to figure out all Beogram codes yet (which will probably also feature seek forward/back, because of BG3000), since I need some additional test subject hardware for that. Smile
    • Volume control and muting are NOT operated from the link. This wouldn't be convenient in a multi-room system anyway, since sending, for example, a mute command on the bus would mute ALL connected receivers.
    • STAND BY can be controlled individually for each device.
  • 03-06-2010 11:00 AM In reply to

    Re: Decoding Datalink

    Hi Stoney3K, just wanted to thank you for posting your findings - only now had time to read them properly. Do you intend to publish the codes, or make me find them out myself? Big Smile

    (I don't blame you if you want to keep them to yourself - nobody else publishes anything either, everybody just wants to sell you something, or at least reserve the possibility Angry  )

    -mika

  • 03-08-2010 7:21 PM In reply to

    • Stoney3K
    • Top 500 Contributor
    • Joined on 10-26-2007
    • Eindhoven, NL
    • Posts 91
    • Silver Member

    Re: Decoding Datalink

    tournedos:

    Hi Stoney3K, just wanted to thank you for posting your findings - only now had time to read them properly. Do you intend to publish the codes, or make me find them out myself? Big Smile

    (I don't blame you if you want to keep them to yourself - nobody else publishes anything either, everybody just wants to sell you something, or at least reserve the possibility Angry  )

    I'll post them here (at least the Beosystem 2000 codes from my own set) once I'm 100% positive that I found every code in the book and I know which code does what. If you're really in a hurry, you can always brute-force them yourself, since there are only 128 possible codes... that's exactly what I've been doing anyway. Smile

    If I'm selling stuff, it's only hardware which works with Datalink. Either a monitoring or injection gadget (so you can connect a central server to it for home automation) or something more intelligent like a Datalink device switching unit for Beomasters and Beosounds that may be a few AUX sockets short. Wink

    The protocol is not rocket science and in principle, it's proprietary, so I'd be stupid if I would claim codes as my own.

     

  • 03-09-2010 3:24 AM In reply to

    Re: Decoding Datalink

    No hurry at all, my current projects (which are on hold anyway) are on the infrared side, which is much more complex. I just think that compiling a comprehensive list of commands will need some cooperation, as nobody will have every possible device to try out in practise. They may have different semantics even though the commands are the same.

    -mika

  • 09-12-2010 2:50 PM In reply to

    • richtoy
    • Top 500 Contributor
      Male
    • Joined on 09-20-2007
    • Valkenburg, Netherlands
    • Posts 184
    • Gold Member

    Re: Decoding Datalink

    How is the development of the datalink device going?

    I think I need one in order to be able to turn on my bedroom mounted BM4500 from a Logitech Duet that I would like to use as an wakeup alarm.  The BM4500 is connected to an MX5500 via an AUX cable and my intention was to use either the unused TAPE or CD inputs for the Duet.  The device would need to detect an audio line level signal emitted by the Duet and use this to trigger the transmission of the correct code to wake the B&O.

    Does anyone have a suitable circuit for generating a trigger (5v ?) from an audio line level signal?

    Richard

    Some of my B&O: BV3/32, MX7000, MX5500, LX5500, MX4000, BM8000, BM6000, Overture, BL8000, BM6000 Quad, BM4400, BM3400, BG-CDX, BM3000, BM1001, BM1200, BM1600, BM1700, BM1500, BM1400, BM2400, BM2300, BM4500, BM4000, BVM70, BVS45-2, BVS60, BC7700, BM2200, BM1900, BG8002, BM1202, BVPenta, BVP45

  • 09-12-2010 3:17 PM In reply to

    Re: Decoding Datalink

    Nothing new from this side... but the trigger circuit would be a high gain amp (one or two transistors, or an opamp), couple of rectifying diodes and an RC filter. Using a suitable microcontroller with an A/D converter, you could do it all in software.

    -mika

  • 09-12-2010 4:54 PM In reply to

    • richtoy
    • Top 500 Contributor
      Male
    • Joined on 09-20-2007
    • Valkenburg, Netherlands
    • Posts 184
    • Gold Member

    Re: Decoding Datalink

    tournedos:

    Nothing new from this side... but the trigger circuit would be a high gain amp (one or two transistors, or an opamp), couple of rectifying diodes and an RC filter. Using a suitable microcontroller with an A/D converter, you could do it all in software.

    Are you saying that it can be done with just a suitable microcontroller with an A/D converter, a single device?  Its been 25 years since I designed anything from scratch so do you have suggestions of a suitable device / circuit.  Would I need to buy the development platform for the microcontroller too?

    One thing I have noticed tonight whilst playing is that both TV (V.OPT 2) and BM4500 (A.OPT 0) turn on if I press CD or TAPE on the BL1000 but only the BM4500 turns on if I press CD or TAPE on the BM4500.  I presume the same would happen if I was to trigger via datalink so could/should a developed device transmit IR codes like the BL1000?

    I am surprised something like this does not already exist...

    Some of my B&O: BV3/32, MX7000, MX5500, LX5500, MX4000, BM8000, BM6000, Overture, BL8000, BM6000 Quad, BM4400, BM3400, BG-CDX, BM3000, BM1001, BM1200, BM1600, BM1700, BM1500, BM1400, BM2400, BM2300, BM4500, BM4000, BVM70, BVS45-2, BVS60, BC7700, BM2200, BM1900, BG8002, BM1202, BVPenta, BVP45

  • 09-12-2010 5:41 PM In reply to

    Re: Decoding Datalink

    Many microcontrollers have a (slow serial approximation) A/D converter that has 10 bit resolution, so using the full 5V reference would give about 5V / 1024 = 5 mV resolution -> just bias the A/D input with two resistors, connect the audio there through a series cap, and follow the reading. -20 dB from the full audio swing (1 Vp-p) should still show as couple of bits worth of signal after the conversion, therefore no problem telling real music content from silence.

    AVR controller family was already mentioned, and I can also recommend them as straightforward powerful chips, nowhere near as quirky as PICs for example. If you have any idea about C programming (or are willing to learn), check out Arduino project - they are based around AVR, the development tools are multiplatform and completely free, and the ready built boards aren't expensive either. I'm actually using those myself, it's just so much easier than using raw chips.

    No sure how that example of yours would behave, but a general problem in using the hardware Datalink interfaces is that they only carry the commands that belong there: e.g the Tape connector won't know anything about what's happening on the Beogram side, which is a different Datalink bus on the Beomaster CPU (standby command, for example, is of course delivered to all sources).

    IR could be easier, but the 455 kHz B&O carrier is difficult to generate accurately in software, even on a 16 MHz AVR. Could of course just gate a separate hardware oscillator like the Beomasters do - the 8051 family @12MHz used in them has actually less than one tenth of the processing power!

    -mika

Page 1 of 1 (20 items)