[TK]

Im still learning about Masterlink, but if I understand what you are asking about RE the 1611, I would think it would be possible to convert a DL86 signal from a 1611 into something a BM8000 could deal with.  That said, it may only be possible to have maximum control via the BM8000 IR input. In this instance, the Powerlink cable from the 1611 would go to an Arduino which in turn sent the control signals through an IR emitter, and the line audio output (or input) went through Tape2.  From what little I know about the BM8000, I’ve read that the TP2 jack is fully functional, apart from Datalknk.  But it is IR-selectable, so perhaps it plus the IR receiver can function as a sort of DL86 Aux. What this example cant do in it’s current arrangement is send a command signal back to the 1611, so a bit more thinking would need to be done on how to listen in on the internal DL signals.

[TK]

Just my thoughts –

One of the benefits to buying a Beogram 6500 or 7000 is that those two turntables will integrate seamlessly with your system, and be controllable via the remote. I think there are a few other options that will work as well.  Some turntables u may need to provide RIAA as a typical BM7000 will not have one. installed.  If your father had a turntable hooked up to it at one point, you’ll might need to check to see if your BM7000 has a built in RIAA card already.

RE: Bluetooth – look into the Beotooth offering, as it also integrates seamlessly with the 7000. I have one, and it was an excellent purchase. A generic bluetooth dongle will likely also work, but wont integrate as well.

Remote- consider spending the money to purchase a 2-way remote, such as the Beolink 5000, MCP 5500, or Beolink 7000.  They are specifically designed to work with two-way IR systems like the BM7000.  Of those three options, the MCP 5500 will likely be the least expensive option.

The 7000 has both passive and active speaker hookups, so you have a choice for your speaker system.  A Beolab 8000 is a reasonably priced option that will work well. “Period hard core” would be something like a Penta. Shop carefully, as some of these older speaker systems require some TLC/reworking to get back to their original condition.

[TK]

LOL it was a bit long winded a post. One takeaway to note is that with a little effort, it appears to be entirely possible to make a cheap translation dongle which allows any vintage B&O component to interface with any other vintage B&O component (something one or two people have already worked on).   So one could,  for example, easily make a dongle which would allow a Beomaster 5000 or BM8000 to work with more modern datalink protocols that the 5500-7000 know how to translate. The only limits are the capabilities of the least-capable component.

[TK]

Yes, I have one of his BeoTooth devices, and it’s very well made.

I’ll explain it this way: The beocord is able to transmit lots of information about it’s current state over datalink: what track it’s on, what side of the tape it’s playing, how many seconds it’s been running, how loud the recording is, etc. It’s a very “chatty” component.  In the example above, it’s transmitting CassetteInfo, TrackNumber, and Counter over Datalink for the Beomaster to display. Most Datalink 80 messages are 1 byte in length (eight 1’s and/or 0’s in sequence, in specific combinations) , but a few status messages are longer, because more information needs to be passed then can be done in a single byte.  Fore example, when the Beomaster sees the incoming. code for “TrackNumber” it knows that the next 5 bytes it receives will include which track it should display on the remote. HOWEVER! of the next five bytes it is expecting, only the last byte received is ever used (AFAIK) for this particular status command, and of that last byte, only a portion of it is used. So the first four bytes of the message could have been jibberish, but the original writers of Datalink 80 apparently decided to send “00000111”, which is translated as either “UNKN” or “14+” on your B&O display. But in practice it really doesn’t matter what is sent – the first 4 bytes of data is not used for anything, AFAIK.  They could have chosen to send something else if they’d wanted to.

The ‘UNKN’ label is basically the English label Ive assigned for the sequence of bits ‘1111’, or the Hex letter ‘F’.  which also represents the number 15 in computer-speak.  It’s the largest number that can be represented using 4 bits.  This is the primary reason why most older B&O systems only count tracks up to 14. On any higher numbered track, it will show as “14+” which is signifies “Track 15 or higher”, and also “Unknown Track Number”.  AKA “I can’t count any higher than that, because I’ve run out of digits”.

IF the last byte is also sent as “UNKN” (i.e five “UNKN” in a row), then the Beomaster knows that the beocord either does not know what track it’s. on, or the current track number is 15 or greater. The Beomaster  subsequently relays that information to a 2-way remote IR or the console panel, so the appropriate number is lit up. In the example above, the last number translates to a “10”, so solely the information in his last byte will cause the “10” to flash on an MCP panel.

Ironically,  the system already has a means to describe any track number between “0” and. “99999” easily, using the tape counter to transmit current track info.  In the example above, the Counter returns “07270”, which will display as “0727” on the MCP (I think- it might display “7270”, I’ll check later). Pilatomic has implemented this feature using the Status counter in his excellent adaptation.

[TK]

Well, since I’m here talking to myself, I’ll post an update for my own edification.  After attaching a cheap logic analyzer to the DL80 pins, I realized that I was getting some of the right answers by mistake.  There’s a series of timing issues when using the toresbe method which caused transcription errors in multi-byte status commands, but you wouldn’t know it, because it was always incorrectly transcribing in the same predictable way, about 95% of the time.  The other 5% I was not understanding the data.  After some fiddling and looking at logic traces, it looks like some multibyte data with respect to numbers is transmitted as shown below.  I’m in the process of updating the code to work based on my current understanding, and will post it at some point when I’m satisfied for the two or three of you globally who might care about such things.

Multi-byte numbers: ‘0 + 4-bit-number + 111’ with the leading 0 being the start byte

That’s as far as I’ve gotten for the time I’ve had this afternoon to work on it. I’ll check to see if ‘sound level’ display is sent the same way tomorrow.

As an example, a request to For showing Tape Status from the MCP would be (using my nomenclature):

DL80-1.EF Sys.ShowStatus  (Active Low: 00010000 )

DL80-1.F8 Tape.Status.CassetteInfo+  (Active Low: 00000111 )

DL80-1.A0 :Side-Top  (Active Low: 01011111 )

DL80-1.D8 :Dolby-C  (Active Low: 00100111 )

DL80-1.A0 :Side-Top  (Active Low: 01011111 )

DL80-1.BE Tape.ShowStatus  (Active Low: 01000001 )

DL80-1.B7 Tape.Status.Playing  (Active Low: 01001000 )

DL80-1.F4 Tape.Status.TrackNumber+  (Active Low: 00001011 )

DL80-1.F8 UNKN  (Active Low: 00000111 )

DL80-1.F8 UNKN  (Active Low: 00000111 )

DL80-1.F8 UNKN (Active Low: 00000111 )

DL80-1.F8 UNKN (Active Low: 00000111 )

DL80-1.D0 "10"  (Active Low: 00101111 )

DL80-1.FA Tape.Status.Counter+  (Active Low: 00000101 )

DL80-1.80 "0"  (Active Low: 01111111 )

DL80-1.B8 "7"  (Active Low: 01000111 )

DL80-1.90 "2"  (Active Low: 01101111 )

DL80-1.B8 "7"  (Active Low: 01000111 )

DL80-1.80 "0"  (Active Low: 01111111 )

[TK]

Very interesting.  The color versions would not be to my particular taste, but IMHO it illustrates the possibilities quite well.  Does the anodization process require you to remove the rubber parts, and/or the glued-on studs? I know that vinyl does not survive the acid cleaning  process intact, but I did wonder about rubber? You do your own stencil work for the arm cover? Overall, IMHO a nice service option to offer, even if it’s only to refinish to original colors.

[TK]

BTW the DL80 serial stream Im working on is printed as below (Work in progress – not everything is decoded properly).  Id like to eventually have something similar for the DL86 channel, so I can parse the output stream from a real-time monitor.

Tape.Status.CassetteInfo->:Side-Top:Dolby-B:Side-Top
Tape.Status.Playing
Tape.DataErr?
Tape.Status.TrackNumber->8
Tape.Status.CassetteInfo->:Side-Top:Dolby-C:Side-Top
Tape.FF->>
Tape.Status.CassetteInfo->:Side-Top:Dolby-C:Side-Top
Tape.Status.Adv->
Tape.Status.TrackNumber->9
Tape.Stop
Tape.Status.CassetteInfo->:Dolby-C
Tape.AutoRev?
Tape.Status.Stopped
Tape.Status.TrackNumber->9
Sys.ShowStatus
Tape.Status.CassetteInfo->Tape.AutoRev?:Dolby-C:Tape.AutoRev?
Tape.ShowStatus
Tape.Status.Stopped
Tape.Status.TrackNumber->9
Tape.Status.SoundLevel->00
Tape.Status.SoundLevel->00

Tape.Display-Select
Tape.Status.CassetteInfo->Tape.AutoRev?
Tape.ShowStatus
Tape.Status.Stopped
Sys.ShowStatus
Tape.Status.CassetteInfo->Tape.AutoRev?:Dolby-C:Tape.AutoRev?
Tape.ShowStatus
Tape.Status.Stopped
Tape.Status.TrackNumber->9
Tape.Status.Counter->08080

 

[TK]

Hi all, I’m new to B&O, and I’ve been working a bit on the side trying to do much of the same thing, but with detailed status.  In essence, I’m looking to create an IoT MCP, so I can control – and equally important to me -query system status on my BM7000.

My first thought was to graft an Arduino into an old MCP that I purchased.  Button-press implementation appeared straightforward, but it seemed a bit daunting to decipher the incoming IR without a suitable logic probe, so I largely went the route as described in this thread – monitoring the DL80 and DL86 channels for messages, and mapping them to a status matrix.  It’s been a bit of a learning curve on the DL80 ports, but now that I have that work largely complete, I’ve turned my attention to DL86 piece, broadcast on the Aux channel.

As described above, there are at least two types of DL86 command structures – one for things like incoming short Beo4 commands which don’t monitor return status, and another is the longer outbound messages containing status.  What I’m seeing on the outbound packets differs somewhat from what I’d expected, as shown below.  I’m using the DL86 packet example as shown in the 9-page DL86 manual to count the bits as 4-bit localAddr, 5-bit toAddr, 5-bit fromAddr, rest is data.

Source  Data

Radio:   DL86.Local:0011 toAddr:10111 fromAddr:10000

Tape:     DL86.Local:0011 toAddr:10111 fromAddr:10100

Phono:  DL86.Local:0011 toAddr:10111 fromAddr:10100 (same as tape?)

Tape-2: DL86.Local:0011 toAddr:10111 fromAddr:10101

CD:      DL86.Local:0011 toAddr:10111 fromAddr:10100  (Same as Tape & Phono)

So unless I’m counting bits wrong, it looks like the source-status-info must be in the data field, in order for it to appear on a Penta display (for example).  Before I go too far down the rabbit hole and, I’d like to ask if anyone already has deciphered outbound DL86 status data and has posted it somewhere.  If not, I’ll do my best with decoding it and post results. Any guidance would be a time saver, and greatly appreciated. I’ll of course post what I come up with on GitHub as my contribution to the solution. Thanks in advance!

 

[Author]

Posts