BEOTOOTH 5500 : A Datalink Bluetooth Receiver

[pilatomic]

Hello fellow B&O owners,

I have been working on this project on and off for quite a long time, even had to restart from scratch at one point when it turned out the hardware I had selected was a dead end, but it’s now becoming a reality. Let me introduce : the BEOTOOTH 5500.

Short version : It’s a Bluetooth receiver that happens to be very friendly with my Beomaster 5500.

Longer version : It’s a Bluetooth receiver that happens to be very friendly with my Beomaster 5500… by impersonating a Beocord 5500 tape player on the Datalink bus, and makes playing music from a phone / PC on a B&O system an experience as enjoyable as using any other B&O device from the same era.

Bluetooth related features :

• Support AAC audio codec for proper quality sound restitution.
• Can be paired with up to 6 Bluetooth devices (Only 1 connected at the same time).
• Pairing entered by pressing the button at the back. Long press unpairs all devices.

Datalink related features :

• Connects to a B&O system using the usual 7-pin DIN Datalink connector.
• Provides audio signals at the same level as other B&O devices.
• Communicates using the Datalink-80 protocol.
• Converts the Datalink commands from the B&O system to AVRCP (1.0) commands for the Bluetooth device.
• Notify the B&O system of link status (Bluetooth disconnected shows as “NO SOURCE”)
• Turns off the system after 5 minutes without Bluetooth link, or 15 minutes without audio activity on the Bluetooth link (Usually means no sound on a mobile device, but means another audio output selected on my Linux PC).

When paired with an AVRCP 1.3 Bluetooth device :

• Notify the B&O system of current playback state (Playing / Paused / Seeking)
• Shows the current track number and live elapsed time on the MCP5500.
• Automatically turns on the B&O system when playbacks begins (AVRCP Status shows “playing”. I did not want the system to turn on as soon as sound is available on Bluetooth, to prevent it happening for every notification my phone receives, and waking up the whole house by the same occasion).

Misc features :

• Powered through a standard USB-C connector (5V 100mA).
• Red LED at the back to show its status (Not connected / Pairing / Paired).
• Small form factor, making it easily concealable.

Missing features :

• Select track by entering track number. At the time being, it seems my phone does not support the AVRCP version (1.6) required to select tracks from their track number, despite claiming otherwise, so I was no able to implement that feature yet.
• Trigger pairing from a special code on the remote. I did not need that one in the end, as I only have 2 devices paired, but I could look into that.

Here is a video of it in action (Please excuse the blurriness of it, my camera is getting a bit old, and we have been so spoiled with perfect 1080p video on internet these last years that I even forgot that not every camera could film that way) :

https://www.youtube.com/watch?v=Swrvj8xP6Dk

I have tested its compatibility with both a Beomaster 5500 (Where I have it permanently plugged as TP1, the Beocord having been relegated to TP2, as only TP1 shows live status on the MCP5500), and a Beosystem 2500 (the latter of does not show any status info, just like it would happen with a Beocord 5500).

As of now I only have one working unit, as the first version PCB I designed ended up requiring a few more tweaks than I had hoped for. If there are enough members interested, I can have a look at producing a small batch of those with all the fixes implemented, so let me know if you want one.

[pilatomic]

B3OHACK3R wrote:

Ah, interesting that it wasn’t reliable for you with an ESP32. Been using it myself for a couple of projects already and was always happy. Did you use their IDF SDK or the Arduino stuff? Yes, I know those BM83 modules. Around for ages I think and come with a hefty price tag for what they are. Was there a particular reason you just didn’t go with a Linux system? Things tend to be a lot easier then.

The ESP32 is mostly okay (except that awful ADC !). I use it for other projects with the IDF devkit (not that Arduino rubbish), but here it came short on 2 points :

First :  Connection stability, especially in bad conditions (mostly occurring here when my wool sweater generates a bit of static electricity, that was a guaranteed loss of link with he ESP32). Does not happen often, but losing link even for a few seconds every couple of hours is very noticeable on a audio stream.

Second : Not having a working implementation of a good audio codec (ESP-IDF only comes with the Bluetooth standard SBC codec, and you can definitely here the compression). Some third party have tried porting AAC, which kind of work when using the second CPU to perform the decompression, but it does still have some dropouts from times to times (maybe caused by bus contention due to having the 2 CPU working heavily on RAM data ?).

The BM83 are indeed very expensive for what they do, but they are typically targeted at this kind of low volume products, and the Bluetooth link has been rock solid since I switched to those (not even one unplanned link drop !). Interestingly, I had rejected those in my first search 2 years ago, as back then their firmware did not support AVRCP. It has been updated since.

Regarding using Linux SOC, it definitely was an option. I did not go that way mainly because I am more comfortable with bare metal development, and I do not trust the completeness of the Bluetooth Stack on Linux (AFAIK it is based on a old version of the Android BT stack), I don’t know if AVRCP is properly implemented. Also I like using the simplest tool for the job. And going with a module with integrated antenna almost guarantees EMC compliance by following good practice PCB design, that’s also a plus.

Madskp wrote:

An idea to make it more simple for you could also be to just sell the working PCB and inform what enclosure you have used. I guess for many people doing the mechanical assembly themselves would be an ok compromise.

That’s actually a good idea ! I’ll keep it in mind !

LukeS wrote:

This looks like a great project. I’m looking for something like this with airplay 2 streaming – I guess that is a completely different technology to Bluetooth?

Indeed Airplay is quite different AFAIK, as it requires a proper IP connection (WiFi).

[pilatomic]

I had made a custom PCB, and tried playing with the decoupling caps (both ceramic and tantalum, values from 10nF to 10µF), but it didn’t lead to any changes. The fact it only happens when radio perturbations are present lead me to believe that there might be an issue with channels scheduling and / or frontend AGC. (Either that, or my PCB had a very bad EMC susceptibility issue, but being such a simple project, I don’t find that too plausible). Also I did most of the test connected to my Linux workstation, so the issue might be there too. Anyway, I turned away from the ESP32 for that project when I could not get other codec working than SBC, and that was a deal breaker.

I’m not a big fan of bit-banging stuff, not with a full Linux running at least, but it seems you have more experience than me on that subject. My approach would be to delegate protocol handling to a small MCU, and have it communicate with the SOC using a local UART or any other dedicated bus. That way the SOC does not have to care about timings.

[Beitie]

This is very cool!

[pilatomic]

Hello Beoworlders,

Weeks went by, and this project is now reaching completion. I have received the new PCBs, and got myself access to a small CNC machine to mill the back of the enclosure, so that I’m not ashamed anymore of showing that side of the device. I have also made properly sized labels (the previous ones were too small), and designed and printed a cable holder, that ensures any mechanical strain on the cable is transferred directly to the enclosure rather than ripping the wires off the PCB.

This version does support a USB firmware upgrade process, so that both the MCU and the BT module firmware can be upgraded later.

I also came up with a pricing scheme. My intent is to offer those mainly as kits, only requiring some beginners soldering skills to assemble it. A kit would include :

• A PCB fully programmed, missing the red LED.
• The red LED. (As it is easier to have it flush with the enclosure when soldering it after mounting the PCB).
• Around 80cm of 4 conductor cable.
• The DIN-7 connector.
• The enclosure with properly machined holes, and all screws.
• The cable holder part, with 2 zip-ties.
• The adhesive label.
• The pricing would be 80€ (ship. Excl) for a kit, and 115€ for a fully assembled device.

I still need to spend a bit of time tweaking some features, notably I am looking at a way to change the device Bluetooth name, so that you can have it match the system it is connected to.

Lastly, I have everything needed to build a few kits, except I need to order new enclosures, as I ruined the few I already bought honing my CNC machining skills (no wonder machinist is a real job, who would have thought !), and only the last one ended up living to my expectations.

Based of those 2 points, I expect to be able to provide the first kits in a few weeks. Please contact me in PM if you are interested.

While I work on those last details, here are a few up-to-date picture :

[pilatomic]

B3OHACK3R wrote:

You could evaluate lowering the series resistance of the RC filter on the PCM5102 output a little. Otherwise you won’t be able to hit the THD+N value they are mentioning in the datasheet. Some TI reference designs are….

That’s interesting ! Any insight on the mechanism that lowers the THD here ? Too much drop through the resistors ?

B3OHACK3R wrote:

Someone in love with tantalum caps? 😉 .

Oh yeah, I really like their yellow color ! Joke aside, I’m using the venerable LM1117 LDO to provide +3.3V rails, and the recommended output cap is a 10µF tantalum (that’s also a TI design), so ceramics probably lack enough ESR to reach stability here. Used here as regulator outputs caps, the dV/dT is no issue, 16V caps on 3.3V rail, and with low current (0.35A) polyswitch on the supply (and a 6V TVS), I’d say we’re in a correct configuration for tantalums caps, don’t you think ? 🙂
Bonus point is virtually no aging, and no microphonic effect (but that’s a bit of a moot point when used as decoupling caps).

[B3OHACK3R]

pilatomic wrote:

Would you happen to recall the output load characteristic during that test ? Having a relatively low (~1k) load impedance could definitely degrade that THD.

I’m usually measuring at 10k. It is a known “problem” with those DACs. Same goes for the output volume. It only shows optimal THD+N at around -1.5 dB. Any higher and it will degenerate (saturate the output stage?).

pilatomic wrote:

No, really 10µF. That’s what the LM1117 is characterized with (the 3.3V fixed version, not the ADJ one). It requires the output cap ESR to be > 0.3R, which already excludes ceramic caps.

Ah, I see. Was only quickly looking at the reference schematic where 100 uF is used. Been quite a while since I was using such higher power LDO. Mostly switching buck converters nowadays and only small / modern LDOs with high PSRR for noise optimised low-power stuff.

[Madskp]

I have also received mine now and got it up and running.

Very nice and very good quality. and attention to detail for easy assembly.

I have testet it on both a Beosound Ouverture (Tape2), a Beomaster 4500 (Tape1 and Tape 2) and a MCL2AV (Tape), and from my little testing it seems to work flawless with the Beotooth 5500 activating all of the above when playing music from my phone, and also all of the systems being able to control the music (start, stop and skip) via the B&O remote and local control on the music systems.

Based on my little time with it till now I can only reccomand it.

Thanks to Pilatomic for making our old systems even more usefull 🙂

 

[pilatomic]

Hello,
Quick update for those who already own a Beotooth 5500.
Firmware V1.3 is now available, with the following changes :

• Fix playback not resumed when switching from Beogram to Beotooth (I was not processing that datalink command)
• Prevent transmitting AVRCP (Playback control) commands to Bluetooth player when player is not sending audio. This fixes an issue where I was listening music on my computer though the Beotooth, then switched to a headset. A few minutes later, The Beomaster would, rightfully, go to sleep, but that caused a “pause” AVRCP command to be emitted, pausing the playback. “Play” commands are still sent unconditionally, to be able to resume playback.

If you are interested to get that firmware update, contact me via private message.

In other news, I am still in contact with Microchip, diagnosing why the AVRCP Browsing feature is not working. Once that is solved, I should be able to support selecting a track by its track number directly.

[Author]

Posts