link

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 ?

link

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

Only noticed when measuring a PCM5122 on the audio analyzer (pretty much the same chip on the analog output).

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

You mean 100 uF, right?

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.

link

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

Good evening,

Sorry for letting that many days go by without updates, I originally planned to write last week about my avancement,
but I caught the covid in the meantime, and while the novelty factor has dry out, the fever is still quite effective.

Anyway, I'm now back on my feet (mostly), so here are the news :

Following B3OHACK3R's concerns about the usage of tantalum caps, I went looking for other regulators that would be stable with ceramic caps.
I found a new Texas Instrument part, the TLV761 : it is stable with output ceramic caps, has a lower Vdrop and a better PSRR than the LM1117 I originally selected,
which both means less noise when used on a noisy USB-C supply. Bonus points, it is pin compatible with the LM1117, and comes with a soft start function ! Perfect !
I'll be using those with cermic caps from now on.

I did make some (rough) measurement of the PCM5102 DAC using my PC soundcard input to investigate the impact of changing the value of the output filter resistor.
Going from 470R to 100R produces a small (around -6dB) improvement of a bit of 50Hz present in the output. But that noise was already at a ridiculously low level (-90dB).
I reckon it lowers the output impedance of the system, making it a tiny bit better at ignoring the 50Hz ambiant noise ?
The improvement seems ever so small in my case, I don't think I'll implement it.

I also spent a bit of time working on the firmware. I does now identify itself as a USB CDC device when plugged to a computer,
which means you can connect to it with a terminal emulator (such a Putty), and get a command prompt.
Only 3 commands are supported now : querrying the firmware version, querrying the device bluetooth name, and setting the bluetooth name.
That means if you have multiple Beotooth, each one can be named to reflect the system it connects to.
More commands might be implemented in future firmware versions.

I did mill about a dozen enclosure, and the result is even better than the first I did, so now I have everything required to build the first few Beotooth.
I'll be writing to those who sent me messages as soon as I am ready to ship theirs.

Wishing you all healthy holidays !

Hi Pilatomic,

good news, really looking forward to it! Healthy holidays to you from now on.

Kind regards,

Rolf

Amazing!

MM

Hello,

Right before the Christmas celebrations, as I have started shipping some Beotooth 5500, I have just put together an assembly / usage manual. You can find it there :

/api/files/335454e941a847b8af50c8f5084203e9

Wishing you all a merry Christmas from France !

Looks very promising ? Great job and merry christmas to you

Hey Pila, really nice project you put together here!

I´m currently looking into creating something less sophisticated for my personal use. The idea is to control a Beomaster 6500 by transmitting Datalink commands. I´m using an off-the-shelf Arduino Uno R4 WiFi and as a code basis I used this link.

Currently I can send and receive Datalink commands on the TV/AUX Port of the BM and I was able to retrieve commands from a MCL Sensor I bought for this Project. But unfortunately the commands only startup the BM in muted state and I can´t get it to unmute (See my post ).

I think I´m lacking a deeper understanding of the actual structure/content of the Datalink protocol beyond the published Datalink'86 spec-sheet.
As it seems you succeeded in solving these difficulties, do you have some tips and tricks or a documentation about Datalink you are willing share?

Any advice is welcome!