[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