[Millemissen]

That is highly interesting – thanks and congratulations on the result.

I see the benefits of using the 5500 and the panel, but it would potentially work with any B&O master/system with a datalink-based A.Tape input port…..as I assume.

Will be interesting to hear how high the costs will be and how many ‘subscibers’ you’d need, befor starting making a batch.

P.S.
The video is ok!

MM

 

 

[matador]

Absolutely stunning development. This is Beoworld! Thank you, tank you, thank you!

Except for the name… BeoTooth? Honestly, it scares me like an MLGWNL (whatever) box profoundly dug in my human body.

Jokes apart, you just made raise BM 5500 prices (jokes not so appart after all…).

 

[B3OHACK3R]

Nice, congrats!
Which BT chip are you using?

[Madskp]

Very nice project ? thanks for letting us know about it. Unfortnuate that the status text is not shown on newer system ( I guess that it is other than the BS2500 where this applies?)

If it only is a hobby project and you dont want to be a manufactur /seller of these units an option could be to make the plans available for others to build it themeselves. I am aware that is not for everyone to do, and there might also be an issue with programming of the chip holding the software, but in the end it could save you some trouble, and worldwide distribution could be easier.

Depending on price I might be interested

 

[lausvi]

VERY nice! I’d be surely interested in buying (either pre-made or kit-form, latter preferred) at least a couple!

[skolesen]

Lovely, count me in as well if the price is right.

I still daily use pilatomic previous Beolnik 5000 upgrade project.

[pilatomic]

Millemissen wrote:

[…] it would potentially work with any B&O master/system with a datalink-based A.Tape input port…..as I assume.

Indeed. I have also tried it with a Beosystem 2500 where it works nicely, providing controls from the Beosystem and its remote, and automatically turning it on / off. Btw it works on A TAPE but also TP2 input (except that on the BM5500, you loose the live status display when using it on the TP2 port).

matador wrote:

Absolutely stunning development. This is Beoworld! Thank you, tank you, thank you! Except for the name… BeoTooth? Honestly, it scares me like an MLGWNL (whatever) box profoundly dug in my human body. Jokes apart, you just made raise BM 5500 prices (jokes not so appart after all…).

Thank you for your enthusiasm, means a lot to me, as I tend to quickly lose my drive after completing a project, and often move to something else without talking much about it. Regarding the name, I know BEOTOOTH sounds a bit cheesy, but it does match the beo* pattern, and it’s cheesy enough that I shouldn’t get in trouble with B&O for using it. If you have a better name in mind, feel free to propose it, nothing is set in stone yet !

B3OHACK3R wrote:

Nice, congrats! Which BT chip are you using?

I did a proof of concept about 2 years ago using an ESP32, but couldn’t get a reliable sound stream with anything other than the default SBC codec (which really isnt that good). I then attempted to pivot to Qualcomm chips, but they are really interested in small volume orders. I ended up using the Microchip BM83 module, which works quite well for my use case, except for its really arcane documentation !

Madskp wrote:

[…] ( I guess that it is other than the BS2500 where this applies?) If it only is a hobby project and you dont want to be a manufactur /seller of these units […]

Indeed status display is only on the BM5500 as far as I know (not too familiar with the entire B&O lineup from that era). But control features works on BS2500, so they should work on any Datalink compatible device, and I have yet to test it with my BS9500 (which is currently in storage).

lausvi wrote:

VERY nice! I’d be surely interested in buying (either pre-made or kit-form, latter preferred) at least a couple!

I’ll see what I can do regarding a kit but I think the only solderable item left would the wiring to the datalink connector. Would that still count as a kit for you ?

skolesen wrote:

Lovely, count me in as well if the price is right.

I will try selling it with the same terms as my Beolink 5000 E-Paper kit, and see how it goes. I haven’t determined a price yet, as there are still some things that needs to change from my prototype, and things I have not taken into account, like proper machining of the connector slots in the enclosure (I really prefer not to show the back of the prototype enclosure, with its very DIY knife cuts), buying the proper screws (my random screws box won’t be able to provides another set of matching screws) and determining the actual assembly time required.

Thank you all for you interest ! I’ll keep you posted

[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.

[LukeS]

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?

[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).

[B3OHACK3R]

From what I know there are no connectivity issues with ESP32. Actually its reception quality is pretty good for what it is. For stable operation it requires some external low ESR bulk capacitance. Also some supply rail filtering between ESP and the remaining system is good practice here. All the low cost dev boards you can get are a little short on this end…

Probably let’s not talk about compliance here. It will certainly vanish any fun on such projects. 😉

BlueZ is… well often there is just no way around it when using linux. Although for audio streaming bluez-alsa works pretty nice.

For that other project I was actually thinking about implementing the whole DL communication on the same FTDI chip that already handles the ML communication. It has some nice GPIOs that are more than fast enough to bit bang it. So that could be a nice single chip solution that entirely runs over USB…

[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.

[B3OHACK3R]

pilatomic wrote:

values from 10nF to 10µF

Had to use a good 100 uF electrolytic cap combined with 3x 22 uF and fine tuning of the buck converter feedback loop to get the ripple on that rail to an acceptable level. Anyway, as you said not of much interest here.

Somehow DL can only be bit banged. Of course offloading realtime tasks to a dedicated MCU would give best results. Nevertheless DL is so slow and looking to be tolerant enough that you can abuse it quite a lot. For me it works 100% reliable.

[pilatomic]

B3OHACK3R wrote:
[…] Somehow DL can only be bit banged. […]

Indeed. I meant bitbanging from a SOC, rather than a dedicated MCU.

[B3OHACK3R]

pilatomic wrote:

I did a proof of concept about 2 years ago using an ESP32, but couldn’t get a reliable sound stream with anything other than the default SBC codec (which really isnt that good). I then attempted to pivot to Qualcomm chips, but they are really interested in small volume orders. I ended up using the Microchip BM83 module, which works quite well for my use case, except for its really arcane documentation !

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.

[Madskp]

pilatomic wrote:

and things I have not taken into account, like proper machining of the connector slots in the enclosure (I really prefer not to show the back of the prototype enclosure, with its very DIY knife cuts), buying the proper screws (my random screws box won’t be able to provides another set of matching screws) and determining the actual assembly time required.

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.

[Beitie]

This is very cool!

[B3OHACK3R]

pilatomic wrote:

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

Someone in love with tantalum caps? 😉

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….

[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:

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

Only noticed when measuring a PCM5122 on the audio analyzer (pretty much the same chip on the analog output). Never made much assumptions why this is actually the case. In-field you will either see the 470R from the datasheet / EVK being used or a value around 100 … 75R. The ones with a lower value were likely be tuned with a proper analyzer, the others are probably just copy-paste. Just make sure you have proper ESD protection. Also sometimes they don’t like a ferrite bead (FB3?) in front of the analog power input. Better to have the whole system powered by a buck converter and only have a small LDO for the analog part of the DAC.
With exception of the PCM5242 (convenient if you need symmetrical output) I stopped using those TI DACs a while ago because they also seem to have a higher variability in quality than usual. E.g. ESS has a part that is pretty similar to the PCM5102 and has no such issues.
Not that all that would make any difference when connected to vintage Beo gear… 😉

pilatomic wrote:

and the recommended output cap is a 10µF tantalum

You mean 100 uF, right? Which is likely also the reason why they are recommending tantalum caps. Ceramics in that range are quite a bit more expensive (and probably weren’t even available back when that LDO was designed – same goes for low-ESR electrolytics).
Personally I don’t like tantalum much. Only use it if there is no way around. Although they still have the highest density with lowest ESR they also really dislike repetitive and excessive in-rush current. They tend to go up in flames if they are unhappy with their environment. Then there is also the fact that it’s a conflict resource…
Alu-Poly is a great alternative if normal electrolytics or ceramics won’t cut it.

[Author]

Posts