[Regenpak]

With the help of a cheapo logic analyzer I finally managed to get readings from the affected Beocenter (which happens to be a 9500). It only sends single bursts whereas the display only reacts on two bursts. The protocol is a bit tricky to decode so I only record the timing of the pulses. This also makes it much easier to program the burst (“riedel” in Dutch) in my PIC. My 2k5 sends:

RADIO 8 44
1151232123213123221313212222223122222222313212222241
11512322132221222231321222222222312222231222222222241

and the 9k5:

(radio)
115123221322212222313122222222222222222222341

The latter is only one command which is also much shorter. No idea why that is. Maybe it should also send parameters (program, volume) for the display to show it.

There have been efforts to decode the Beocommands but these seem incomplete. Will do some more testing.

• This reply was modified 2 hours, 58 minutes ago by Regenpak.
• This reply was modified 2 hours, 55 minutes ago by Regenpak.

[Regenpak]

The chance of all four displays sharing the same failure are infinitesimal. With the help of a Beocenter 2k5 I loaned from a friend I fed one display a beolink databurst and lo and behold the correct text appeared on the display! I even got my PIC code to send a valid command to the display. Now all we must find out is why the Beocenter 9k fails to produce the correct data. To be continued…

[Regenpak]

I just realized something. The AUDIO/!VIDEO input is HIGH to unblank the display. When LOW in case of home theater it blanks the display but if the input has gone phut and always reads LOW for the firmware inside the 80C52 the display will never get unblanked. So if that is actually the case all four units are toast. There is current flowing out of pin#25 but being TTL that is always the case.

To troubleshoot further I will do some supply current analysis. If there is any processing going on this will show in the current going into the VCC pin #40.

[Author]

Posts