• DIY Audio Articles

• Contact Me...
• Guestbook
• About...

As part of a project that seems to be stuck at the usual 90% done but who knows if it will ever be finished stage, I did a deep dive into the world of cheap Chinese Bluetooth modules. There are many available, but I picked the KRC-86B because it is often recommended on forums, and there seemed to be a reasonable amount of knowledge and experience out there. Given that the write-up for the wider project won't be finished until the project itself is - though that too is perhaps 90% done - I decided to post the information about the Bluetooth module separately.

The KRC-86B Bluetooth module

The KRC-86B is available for around £8 from the usual sources, so it is by no means the cheapest, but still incredible value. As mentioned, this module is frequently recommended on forums, and especially the vintage radio forums for Bluetooth conversions. There are 2 main reasons for this:

1. It contains an analogue switch which allows for automatic switching between the Bluetooth device and a local source of audio
2. When connecting, it does not make any extrenuous noises. Many modules chime or beep when connecting, which gets pretty annoying!

For my project, this first point wasn't relevant as I'm switching the audio separately, but you can see how this could be handy for a retro-fit - assuming you don't mind the current the module takes when not connected, which could be a problem for battery gear. However, the second reason is definitely worth bearing in mind.

Important: This article discusses version 4.0 of the module. Be aware that there is now a version 4.2 available, and it does look to have a number of differences. I have tried to pick up a couple to see exactly what's changed, but each time, I've ended up with more of the V4.0 versions, which is frustrating. The pictures on the listings are no indication, it seems, and many listings offer the "V4.0 or V4.2" with no way of knowing what you'll get. I asked several suppliers if it was possible to have the V4.2 version, but I don't think they understood the question, which is fair enough given the nature of the business. But if I do eventually find a V4.2, I'll post an addendum here. But for now, please be aware that what follows might not apply directly to your module.

Overview

This module uses a CSR8630, originally from CSR (Cambridge Silicon Radio), now Qualcomm. It is quite an old product that is not recommended for new designs, which might explain why it's so ubquitous in these cheap modules. It supports Bluetooth version 4, which is more than adequate for undemanding applications.

The module runs from 5V, and consumes around 30mA when connected. The audio output level measures 0.83V_RMS when fed with 0dBFS.

A 470uF capacitor and a blue LED are supplied with the module. Although no instructions are included, it's obvious that the cap is intended to be connected across the supply input. Without it, there is a lot of digital noise on the audio outputs. With it, it's much better, but the noise is still a bit on the high side in my opinion, and that's especially true if your Bluetooth device is not set to maximum volume.

It's worth bringing up the subject of noise this early in the article because it's a common issue with these sorts of modules, caused by two problems:

1. The shared power and signal grounds
2. The very "spiky" nature of the current draw by the Bluetooth chip

The capacitor obviously helps with the second problem, but I found that for best results you need to pay special attention to decoupling throughout the rest of the circuitry.

The shared ground problem is likely to be an issue in a practical implementation unless you can make the Bluetooth module the only point where the grounds meet. That's how I assessed noise with and without the supplied capacitor above, using my powered bench speaker, which is only loosely tied to ground for exactly this reason.

To break the grounds, some folk recommend using brute-force measures such as isolated DC-DC converters or audio transformers. Suffice to say, I solved the problem without recourse to these expensive and/or inconvient approaches, as explained later. It's also worth saying that the exact level of noise experienced depends strongly on the your scenario, including how you derive the 5V supply for it, so if you're lucky, you might well be happy with the results with no special measures.

The LED has dedicated connections, and is used to indicate the connection state; flashing slowly when powered but not connected, and lighting steadily when a connection has been established. Its use is optional, but it's worth saying that it adds about 1mA to the current draw. As it's rather bright, an additional series resistor to supplement the 470Ω on the module might be a good plan.

In addition to this, there is an "EN" output, which is high (3V3) when connected and grounded when not. This allows you to integrate the module with a control system in a more complex project.

Physically, the module measures about 30mm square, with the bulk of the connections presented along one edge. These are spaced at 2mm rather than a Veroboard-friendly 2.54mm. There are an additional 5 connections along an adjacent edge which are are mostly for local switches for play/pause, and skip/volume. I found that the behaviour of these switches depends a lot on the source device, so test carefully before deciding whether to make use of them.

Here is a rear view, showing the labeling for the connections:

This is mostly self-explanatary, but note the large number of "NC" connections. In many cases, NC means "not connected", but here it means "do not connect". We'll come back to these later!

A search will bring up this overview of the module, which is a decent starting point. But I still had many questions, so decided to investigate further.

Here is a summary of the ICs on the module:

1. CSR8630 B04U Bluetooth codec
2. T24C64 serial EEPROM
3. 4052 CMOS switch IC
4. PT2308 dual op-amp. Note that the LMV358 is also found in these modules
5. Unmarked 8 pin IC, which appears to be a microcontroller

The PT2308 op-amp is actually a headphone driver - presumably chosen because it's happy to work from 5V. This the first time I've met this IC, but it appears to have a pretty good specification if the datasheets can be believed (the "official" one linked here is a bit sparse, but you can find more detailed ones on the various datasheet websites). As mentioned, the LMV358 is often used instead, and this has the advantage of much lower current consumption (see later), but it has a pretty mediocre distortion performance.

Almost inevitably, I set about reverse-engineering the module. This was not an easy task, given how well the white solder-resist hides the tracks. There are no component designations on the silk screen so what you see here are mine. As they are too small, none of the resistors are marked, and as usual, nor are the caps. The values on the schematics are based on in-circuit measurements, so should be regarded with caution.

The audio circuitry

Starting with the circuitry surrounding the op-amp, we see that it is configured as a differential amplifier because the outputs from the CSR8630 are balanced, which of course is very common for audio DACs:

This is good news because I can solve the earthing problem by removing the caps that decouple the mid-point to ground (C7 and C8) and return a decoupler somewhere else, meaning that the signal outputs are now relative to my choice of ground. More later.

This is followed by the 4052 that deals with the aux input.

The op-amp outputs have a 2.5V DC offset, which is removed in the usual way by C9 and C10. The aux inputs are assumed to have no DC offset, but as they are DC coupled, it would be prudent to include coupling capacitors to ensure this is the case. But how does the 4052 cope with signals swinging either side of ground?

There is a negative supply rail for the V_EE rail. This is generated by a simple charge pump based around 2 diodes and 2 capacitors. The input to this is a square wave, which comes from the mysterious microcontroller - pin 6 oscillates at close to 3kHz for as long as the module is connected to a power supply. Luckily, the current demand is practically nothing, so there is no obvious ripple on the -VEE rail.

Both the microcontroller and the 4052 are powered from +3.3V. This means that the negative rail would be -3.3V if the diodes were "perfect" - in practice it is around -2.75V.

Given that the module runs from 5V, and there's no obvious voltage regulator present, where does the 3V3 rail come from? That's one of the functions hiding inside the CSR8630.

The microcontroller

As well as generating the square wave for the charge pump, the microcontroller controls the 4052 and produces the "EN" signal:

On the 4052, the "A" input is used to select between inputs 0 and 1 (aux in and Bluetooth). The "B" input is grounded, meaning inputs 2 and 3 will never be used. Incidently, the input pins for those are left floating - not even soldered to the PCB. From the point of view of susceptibility to static discharge, this might not be the best plan...

The 4052 inhibit signal also comes from the microcontroller. In normal operation this is low, but taking it high turns off all the switches, leaving the common outputs in a high impedance state. I wondered if they were using this to mute the outputs, even though it would have been better to ground the unused inputs and simply raise "B" to achieve that. However, I've not seen this pin do anything other than sit down at 0V. Note the pull-up resistor R19 is 2k2, which seems unreasonably low to me, taking 1.5mA for no good reason. Given that the 4052, clearly, is CMOS, you could make that resistor several orders of magnitude larger with no ill effects.

As mentioned, the microcontroller also generates the "EN" signal that tells us a connection has been established. This is fed via a 470Ω resistor so you could connect an LED directly between this and ground if you wished (it would be similar to the dedicated LED connections, minus the flashing when not connected).

There are 2 connections between the microcontroller and the CSR8630, landing on pins 37 and 40. Taking pin 37 first, it is low when connected, and high when not. It is one of three LED drivers. They are open-drain, hence the pull-up (which is 2k2, so another waste of 1.5mA). In this instance, it is programmed to tell the microcontroller that a Bluetooth device has successfully connected. At which point, the microcontroller asserts the "EN" output and switches over the 4052.

The signal at pin 40 is also low when connected and high when not. But it pulses 3 times at power-up. Pin 40 is an input to the CSR, telling it to enable the internal voltage regulators (not including the 3V3 regulator, which is always enabled), and it could be connected to a push-button if desired. Here, the three pulses are sent quite slowly over the course of around 5 seconds, after a brief delay of about half a second. This is simulating a user pressing a power-on button 3 times. The regulators latch on after (presumably) the first pulse, so the extra ones are perhaps "just in case".

The yellow trace is the line from pin 7 to pin 40, and the magenta trace is the 3V3 rail.

I'm not sure why this line goes high when the Bluetooth is disconnected. Upon reconnection, the pin simply goes low again - there's no obvious pulsing. I guess this is just a quirk of the firmware in the microcontroller.

Other details and full schematic

The serial EEPROM is a T24C64A, which is 8K (64k bits). It connects directly to the CSR8630, with 2k2 pullups on each of the three lines. As above, these feel rather low, but as they sit high most of the time, they aren't contributing significantly to the average current draw.

There is 26MHz crystal for the CS 8630. And a smattering of decoupling capacitors, plus a filter for the aerial. There's an inductor for an internal switching regulator that makes the 1.8V rail - it runs at 4MHz. And that's pretty much it. I'm sure that my schematic contains errors and omissions, especially around the CSR8630 where it's hard to trace the tracks, but none of that really matters, as we have more than enough to understand the circuitry surrounding the CSR chip...

Again, please remember that all passives were measured in-circuit, and so I would be cautious about some of the results. The resistors should be OK, but the caps will likely be affected by the surrounding circuitry, especially where there are parallel combinations. Still, none of them are critical.

The schematic also includes a layout diagram so you can identify the components on the board. Remember that all component designations were made up by me as there are no markings on the silkscreen.

Modifications

It's not in my nature to leave alone! I ended up doing some quite extreme mods to these, but I'll break them down into a number of different steps, depending on how brave you're feeling...

Breaking the earths

As already mentioned, if you have separate power and signal earths in your project, you'll probably run into problems with noise from this module. So this first mod gets around that problem. It only involves removing a couple of SMT caps and bringing a flying lead out to join to your signal earth. This should improve things a lot without having to resort to DC-DC converters or isolation transformers.

This simplified diagram shows the idea. Usually - and definitely in the case of my project - we don't want to connect the power and signal earths together at more than one point - and this common point generally needs to be elsewhere unless you have totally separate power supplies for audio and this module. If you do join them together at a second point, unwanted currents will be able to flow in the earth system, which will generate voltages in the earth wiring because of the inevitable resistances. Of course, the noise voltage might be small, but so are the audio signals we're trying to amplify!

So we start by separating the earths, which breaks the loop and returns the earthing arrangements to the original design intent. But now we must accept that the two earths have a potential difference between them - represented by Vn on the diagram. The 10Ω resistor weakly ties the earths together, in case this part of the circuit has been disconnected from the rest of the unit, perhaps for testing.

Next, remember that with a differential amplifier, while it responds to the difference between its two inputs, it generates an output that is relative to the bottom end of R4. So make sure that is tied to the signal earth. Simple!

The difference between the two earths, Vn, appears equally at each input as a common-mode signal. But even a basic differential amplifier using standard 1% resistors will reject this signal by around 40dB. Remember that before, this noise was adding itself to the wanted signal, but also the loop formed was likely causing other problems, such as inducing digital noise from the Bluetooth chip into the earth (and hence the audio signal), as well as undoing the point of keeping the earths separate in the first place, causing problems elsewhere.

Implementing this is as simple as removing the decoupling capacitors mentioned above (C7 and C8) and bringing out the mid-point on a flying wire to be joined to signal ground via a capacitor. This is a mod that I'd suggest to anyone having problems with noise when using this module.

Increasing the input impedance

This for me is the "odd one out", in so far as I haven't needed to do this myself, but for completeness, I should mention that many folk using these modules with valve radios often need to increase the input impedance so that the existing AM and FM detectors in the sets continue to work correctly. As I generally stick to solid-state radios, I've not come across the need to do this yet.

Basically, between the two 100k resistors either side of the 4052, you have 50k for each channel. But for a mono radio, you'll join left and right, bringing down the impedance to 25k.

So the answer is to remove the resistors (R13 to R16). In fairness, the output resistors (R15 and R16) probably aren't needed anyway, but if they are the only thing providing a DC path to ground for the following circuitry, it is good practice to have something there, as CMOS switches present a high impedance for a very brief time when switching, which can be heard as loud clicks.

Also, you probably should provide some DC path to ground on the input side unless you can be very sure that the signal is centred on ground already. Of course, that won't be the case for an AM detector, so AC coupling will be needed from that and you will need to tie the input to ground, even if it's via 1MΩ or similar. Make the capacitor as small as possible (while assuring the required LF performance) to minimise the current that can find its way to the 4052, as that might be damaged. Perhaps a 10k series resistance might be a wise precaution.

Finally, if joining left and right at the output of the module to make a mono mix, please use a pair of resistors to do so. If you don't then the two halves of the op-amp will fight when the content isn't exactly the same. This "tug of way" uses the internal resistance of the two paths through the 4052 as the rope, which doesn't seem like a terribly good idea to me. Join the module outputs with a pair of 10k resistors or similar...

As I say, I've not done this myself, so really this section is just my thoughts and advice, based on what I've read on the vintage radio forums. Remember, you probably need to AC couple on the input side and perhaps the output too, and try not to damage the 4052 - don't apply a signal bigger than about 5V_pk-pk and make sure there is no DC component greater than about 3V. A series resistor on the way in will probably help.

Removing the 4052 switch

If like me, you are switching audio signals elsewhere, it doesn't make sense to retain the 4052. With that gone, we could also lose the series caps C9 and C10, replacing them with nicer film capacitors later on if the 2.5V DC offset at the op-amp outputs is not welcome. With that done, here's what the analogue audio stages look like now:

Much simpler! And note that rather than using a flying lead for the analogue reference, I took advantage of a spare connections left by the 4052.

Having ditched the 4052, we can remove R19 (the pull-up for the "INH" pin), saving 1.5mA (every little helps!). And of course, we don't need the charge pump now, so it makes sense to remove the components associated with that.

Here's a summary of what I removed:

1. C9 and C10 - these disconnect the op-amp from the 4052
2. The 4052
3. 100k resistors surrounding the 4052 - R11, R12, R13, R14, R15 and R16
4. The wasteful 2k2 pullup on the 4052 EN pin - R19
5. Charge pump components - D1 and D2, C12 and C13, plus C11

Having removed those components, the signals were routed to the connections at the edge of the module, as shown in the diagram above, with some Kynar wire. The pads left by the 4052 are the easiest to solder to, being fairly large. We just need to get the audio from the op-amp (pins 1 and 7) to the common of the 4052 switches (pins 3 and 13). I could have picked up the signals from the pads where C9 and C10 were, but it was easier to solder to the op-amp legs.

For the mid-point, it was just a case of picking up the connection on the 4052 pads that originally belonged to "INL" (pin 12) and joining it to the appropriate pad left by C7.

Having saved 1.5mA by removing R19, I turned my attention to R20, which is also passing 1.5mA for no obvious reason. I tried removing it, just in case the microcontroller had a weak pullup enabled (the CSR pin is open-drain), but no such luck. A 33k resistor did the job, and knocked another 1.4mA from the current consumption.

By the way, these savings in current aren't so much about maximising battery life in the final project - 1.4mA will hardly make a serious impact there - but it does ease things for the voltage regulator supplying the module, which is being fed with 24V. The 3mA saved from just those two resistors reduces power consumption in the regulator by 57mW, which doesn't sound like a lot, but the thermal resistance between junction and ambient of the LP2950 is 140°C/W, so this means a reduction in junction temperature of 8°C. This also might not sound like much, but we are quite close to the limits of what this regulator can do, and it was running rather warm, even with a clip-on heat sink. So for the sake of a 5 minute investigation and the replacement of one resistor, I think it was worth it. Luckily, a ⅛W resistor fits quite easily between pins 1 and 4 of the microcontroller, but if you have access to a small enough SMT version, that would be even easier.

This picture shows the completed modifications:

Having done this, I did discover that the chip actually does makes a chime when it connects. However, this happens before the EN output goes high, so the audio from the chip isn't connected via the 4052 to the output. Removing the 4052 exposes this. However, the PIC mutes "my" 4052 until EN goes high, so this chime will also be hidden in the completed project.

The next step was to mount the module on a bit of Veroboard. This holds the decoupling cap, the capacitor to reference the audio ground, and the SPI interface (see later):

The supplied decoupling cap was 470uF - although I did spot a YouTube video that mentioned that they'd received a 100µF, so I guess there's a bit of variation. But, it had quite a high ESR (0.48Ω), so to give myself the best chance of minimising digital noise, I used a 220µF that had a much lower ESR of 0.04Ω (Rubicon ZLH).

Remember that the module has its connections spaced at 2mm rather than the much more convenient 2.54mm. But as we're only using 11 out of the 15 connections to the module (plus the EN connection on the side), the resulting Veroboard was pretty much the same width as the module. I used 0.7mm solid core wire to join the module to the Veroboard, and these simply bent into the required pitch. I did consider using double-sided adhesive foam to attach the module to the board, but I was happy with just the wires.

Upon first test, I was rewarded with silence. In a good way! Using my bench amp, I heard nothing but white noise at full volume. This speaker has a sensitivity of around 30mV, which is about 20dB more sensitive than you'd use for normal line-level sources. The bulk of the remaining white noise will be caused by the resistors surrounding the op-amp (16k and 27k).

The average current consumption has fallen from around 30mA to 25mA. We know that removing R19 and R20 acounts for 3mA of that. Definitely a step in the right direction!

Removing the op-amp

While the mods so far gave excellent results, I couldn't stop worrying about that op-amp, which apparently takes 7mA, according to a datasheet I found here: https://pdf1.alldatasheet.net/datasheet-pdf/view/391548/PTC/PT2308.html. In fact, when I tested it, it was taking 7.77mA, which is practically as much as an NE5532. A TL072 should take less than half of that. As mentioned earlier, the 5V regulator that supplies the module in my project was running rather warm, and relieving it of that 8mA would make me feel much more comfortable. Also, if an external op-amp was running from the same rails as the rest of the pre-amp, it could have more headroom - no worries about clipping from a single 5V rail if I wanted more output level from the Bluetooth source.

Of course, this might not be a concern for you in your application - you might have totally different arrangments for supplying your module. Or you might have the LMV358 instead, which only takes a fraction of a milliamp, meaning that there's no need to worry about the power it takes? But the LMV358 is not exactly an audio op-amp. In a vintage radio conversion this might be academic, but for something half-decent, this would bother me.

As the op-amp is a standard SO-8, it might be possible to change it for something better. But it runs from 5V, and that's not easy to change, so you're restricted to the relatively small range of audio op-amps that are happy to work at 5V. Also, don't forget the surrounding resistors, which are rather high at 16k and 27k, and dominate the noise performance of the circuit. Changing those is definitely possible if you have stocks of tiny SMT parts, but I didn't.

All this led me the towards this final mod, which involves removing all of the analogue circuitry, and bringing out the 4 audio signals from the CSR8630 to the connection pins. We have the two input and two output pins available for this, so it's just a case of using some Kynar jumper wires. Another benefit is that we can lose the ceramic coupling caps C1 to C4, which aren't exactly the best for audio coupling!

So now, with the audio emerging from the module as stereo balanced pairs, you just need a differential amplifier to convert back to unbalanced - but this will be free from noise and referenced to the signal earth of your choosing. The module can be situated some distance from the audio circuitry if desired - although it might be worth using 47-100Ω resistors to isolate the IC from the cable capacitance.

While this is probably well within the capability of anyone who's read this far, I'll include some details of how I went about it - although these really belong in the project write-up, so these details will probably be edited down from this page eventually.

Once the mods were complete, a quick test showed that the current consumption was down to about 17mA when connected and playing music, which is in line with what we'd expect - before we were around 25mA, and we knew that the op-amp took nearly 8mA. But there was one pleasant surprise: no digital noise, despite the temporary lash-up involving long test leads and no decoupling capacitor. This suggests that the original op-amp circuit was picking up noise somewhow - perhaps via a bad grounding strategy. That's impossible to verfify without removing all of silk screen to inspect the layout.

About 5 or 6 seconds after stopping playback, I found that the module becomes noisy. Checking, the DC potential on each of the outputs drops from around 0.8V to 0V, which suggests the output stage is being turned off to save power, and going to a high impedance state. Therefore the noise is just pickup from the test leads, and if this is a problem once the differential amplifier has been built, a low value resistor added between hot and cold would fix it. Also, it will be worth checking that this transition to and from low-power mode does not result in pops and clicks from the diff-amp when built, as the EN line stays high while this happens, meaning the signal is not being muted during these events.

Interestingly, while that happened with my phone, it didn't with my Windows 10 laptop. Easily missed if you don't test with a range of source devices. I did discover that to put the module in that connected-but-low-power state with the laptop, you have to switch the audio output device (from the menu you get when you pop up the volume control from the system tray) away from the Bluetooth module.

When in this power-saving state, the current draw is a bit variable, with occasional narrow peaks, but the average current demand is tiny - just a couple of milliamps.

As this basic testing showed that all was working as expected with the module after its mods, I designed the layout for the support board. This time I decided to mount the module vertically by threading the wires through the holes in the module and soldering both sides to adjacent holes in the Veroboard. This took less space, but is perfectly robust and the aerial is still well away from the electronics and metalwork.

I initially planned to include a couple of transistors to switch the op-amp on and off according to the state of the incoming 5V rail, but quickly decided to move the 5V regulator onto the new board, and have the incoming switched 24V supply also power the op-amp via a suitable dropper/decoupling resistor. Any normal audio op-amp will be perfectly happy with 24V DC, plus moving the regulator away from the crowded pre-amp board to the vertically-mounted support board massively improves the airflow around it. Win-win!

Turning to the amplifier, the gain of the unmodified module is x1.69 (27k/16k), and as the output voltage was measured at 0.83V_RMS for a 0dBFS signal, this implies the differential output voltage at the CSR8630 is 0.49V. I'm calling that 0.5V! But just to be sure, I re-tested this on the raw module during the above testing, and it measures 0.535V. Close enough!

As we have complete freedom now, what should we pick? CD players produce 2V_RMS for 0dBFS, but who uses those these days? It's more likely that a headphone output would feed into one of the line inputs and those are a bit variable in their voltage.

As an inital compromise, it made sense to go for around x2, giving 1V. This is what you get from an iPhone headphone socket (if you have an old model) or via the £9 Lightning-to-3.5mm adaptor if you have a newer phone. This means simple resistor values - perhaps 3k3 and 6k8. We could go lower as the CSR8630 can drive headphones, but these are a decent starting point.

But the components around the op-amp need to have a low profile to avoid clashing with existing parts on the pre-amp board. So that means using ⅛W resistors that can lie down on the board, rather than ¼W resistors that would need to stand up. Checking my stores, I had just enough ⅛W 3k3 1% resistors but no 6k8. But I did have plenty of 7k5. That'll do for now! So the gain is x2.27, resulting in 1.216V_RMS, in theory. That's about +4dBu. I'm sure it'll be fine, but it's easy to revisit this in future...

While low is good for minimising thermal noise, we need to consider the coupling capacitors - the lower you go, the larger they need to be. With resistors of 3k3 and 7k5, what impedance would each capacitor see? For the non-inverting input, that's simple - it's the sum of the two reistors used (10k8). How about the inverting input? The inverting input is a virtual earth, so the impedance is just 3k3, right?

Wrong! But it's a common misconception. I've started writing a separate article looking at this, but suffice to say, it's just under 2k, assuming a differential signal. Given that, 10µF is fine for this non-critical system, but I would go higher if this was hi-fi - it's well known that electrolytic capacitors exhibit a rise in distortion when even small signal voltages develop across them.

Here is the complete design (click to enlarge):

This time I made a slight change to the SPI enable jumper (for re-naming the module - see below) - moving it across to enable the SPI interface also disconnects the CSR8630 from the 5V regulator. This means there's no need to disconnect the Bluetooth support board from the pre-amp board, and no worries about "backfeeding" the regulator.

Here's a picture of the V2 support board, complete with the modified Bluetooth module:

This side view shows how the module is attached to the board using 0.7mm tinned copper wire. The resulting assembly is very strong, and I'm sure it'll prove to be reliable. I did add a few drops of Superglue to help secure the Kynar wire.

This works very well. It only takes about 20mA from 24V, and the voltage regulator is running at a perfectly comfortable temperature, even without the clip on heatsink that was very necessary before. Compared to the first version, there is much less white noise now, and the higher output voltage also works to improve the signal to noise ratio. It is well-behaved, with no audible clicks when switching in to or out of low power mode, and nothing but silence when in that state. Although it was extra work, I'm glad I did it as I wouldn't have been comfortable knowing that I could have improved on my earlier efforts.

You might notice that there is a small tantalum capacitor on the input to the 5V regulator and a 100Ω series resistor, yet the schematic above shows 47µ and 10Ω respectively. Those changes happened after the photos were taken, when I discovered that there were some audible noises from the Bluetooth module. These were not on the audio output of the module, as the noises didn't change in level with the volume control, and stayed the same even with another input selected, until the PIC turned off the Bluetooth module (it does that after a delay for convenience).

The noises were caused by the CSR8630 drawing current in large spikes; while the average current might be around 17mA, the peaks are more like 80-100mA. I have mentioned the "spiky" nature of the current draw a couple of times now, and this was a good demonstration of the effect.

This caused large disturbances to be present at the input to the voltage regulator as the switching transistor came out of saturation - the voltage at this point was dropping by around 10V! This was finding its way into the audio path elsewhere in the unit, albeit at a relative low level thanks to the careful earth design and the decent CMRR of the op-amps. Upping the base drive to the switching transistor helped, but increasing the capacitor to 47µ reduced the power supply disturbances to less than half a volt. Careful testing with my workshop speaker showed that while this signal could still be found on supply rails and the power ground, it was not present at the speaker outputs. Even with that speaker set to maximum gain (around 40dB), there was nothing but white noise at the speaker outputs of each of the power amplifiers.

Removing the microcontroller?

I also considered removing the microcontroller. After all, once the 4052 had been removed, what exactly was it doing? As detailed earlier, I spent quite a bit of time investigating this, partly with this thought in mind.

I could easily bring out pin 37 (the "connected" signal") by simply bridging the pads belonging to pins 4 and 5 of the removed microcontroller (remembering that the signal would be active-low instead of the active-high of the current "EN" signal). But the real sticking point is the pulse(s) generated on pin 7 at power-up. These, or likely the first of them, get the CSR8630 started up.

Ever the optimist, I did try lifting pin 7 and inserting a simple pull-up resistor between +3V3 and the pad vacated (which connects to pin 40 of the CSR). No such luck, sadly - the CSR definitely needs a pulse or three!

So if I'm determined to lose the microcontroller, I'd need to create this pulse myself. This could be done by the PIC I'm using to control the rest of the project, but for the effort required, we might as well leave it alone. Even if the microcontroller is doing almost nothing, what little it is doing is essential, and it's already there in place. So just leave it alone!

I did see a different module that uses a similar but newer Bluetooth chip that used just a resistor and capacitor on this pin to get it started. But this was some time after I'd done these experiments, and I haven't had a chance to try it here.

Renaming the module

This was quite an exciting prospect, especially as I was sure this won't be the last time I use one of these modules. This involves using a USB to SPI adaptor to connect to the CSR chip and updating the contents of the EEPROM - what could possibly go wrong?!

There are three main challenges here:

1. Obtaining a suitable USB-SPI adaptor
2. Identifying the correct SPI pins
3. Finding the software

Luckily, all this is covered in this blog. At this risk of repetition, I'll cover this here, not least because websites sometimes disappear - it doesn't hurt to duplicate useful information.

For the adaptor, I searched eBay for "CSR USB-SPI", and found dozens of sellers offering something like this (note there are several variations). I figured it was worth the £15 or so to experiment.

To identify the SPI pins, the details for the KRC-86B are in the Instructable. However, at a glance, you might miss them because they are in the form of an image which is hidden away in a gallery with not even a thumbnail preview. With that in mind, here's a direct link to the image. This shows us the pins on the CSR chip itself. However, the blog shows how these signals appear one the connectors on the module. I have confirmed with my module that these tally up, and my version of the schematic includes these details.

Finally, the software. Again, this is linked in the blog, but just in case, here it is: https://disk.yandex.com/d/QAdQ7zuP-X62Xg. At the time of writing, the latest version there is bluesuite.win.2.6_installer_2.6.11.1937.zip

With all of these boxes ticked, how to implement this in a way that would allow easy experimentation? As seen above, I included pin headers on the boards I made to support the Bluetooth module. I might only use them once or twice, but it was no real effort to include them, so why not? Also, as described in the blog, we need to pull the SPI_EN signal up with a 10k resistor, which is also provided for on my boards with a jumper.

My USB-SPI adaptor came with a short 6 way ribbon cable with plugs for each conductor at each end. Also, there was a jumper installed in the 10 way IDC header. There was no documentation supplied with it, but I'm glad they'd plugged it in, as without it, it doesn't work. I think the idea is to connect the Vs pin to either 3V3 or 1V8, presumably to tell the adaptor what voltage to work at. Both these voltages are duplicated on pins either side, so with the jumper in place, you're still able to take the appropriate one on to your device via the ribbon cable.

Connecting up the leads was just a case of following the label on the adaptor with reference to my diagram of the support board, which obviously relies on me correctly identifying the SPI pins. And remembering to instal the SPI enable jumper. Fortunately, it worked first time!

If you plug the USB-SPI adaptor into a machine that hasn't had the Bluesuite software installed, Windows doesn't install drivers for it. For that reason, install Bluesuite first. Once plugged in and appearing correctly in Device Manager, run up "PSTool". The first time, you need to click on "SPI BCCMD" on the left, and then the adaptor should be available on the drop-down labelled "Port".

Once you've clicked on "OK", the software attempts to communicate with the CSR8630. If it fails, double-check all your connections, including the jumper that joins VS to 3V3 at the adaptor, and check also that you've taken SPI_EN high via a 10k pullup (or, in my case, installed the jumper). Click "Retry" if necessary.

It takes less than a second to populate the main window:

At this point, you may wish to take the advice offered in the video and in the Instructable, and back up the current config of your module. From the File menu, choose "Dump". This creates a file in the directory of your choosing that can be read with your favourite text editor. Don't ask me how to restore from the backup - I haven't explored this yet...

The list of parameters is huge, so in the filter box type "name", which will reduce the list down to just one ("Local device's "user friendly" name"). Click on that, and you'll see "KRC-86B" in the text box. Replace that with the text of your choice.

To save that to the module, simply click on "Set". Test by unplugging the USB, which powers down the module. Restart the PSTool program, and reconnect the USB and let PSTool read the config data as before. Find "name" in the list and confirm that it is what you typed earlier. And of course, you can search for it using your phone or similar. If it still appears in your list of Bluetooth devices with the old name, you might need to select it and tell your device to forget it, then re-scan.

Having got this working, I made up a dedicated lead, using a 10 way IDC header, a short length of ribbon cable, and an 8 way SIL header. I joined the 3V3 and VS leads together at the SIL header (blue and grey) because it's clearly a bit tricky to plug the IDC header and shorting plug in at the same time. So now it's very easy to hook up in future, and if I use the same header arrangment for future projects, renaming the module is practically a zero effort endeavour.

Out of interest, I did take a look at the file produced from the File, Dump command above. It's a long list of values, as you'd expect. Searching for "name" gets us this:

  // PSKEY_DEVICE_NAME
  &0108 = 524b 2d43 3638 0042
    

Converting those hex pairs to ASCII gets us this:

  RK-C68B
    

And swapping pairs around:

  KRC-86B
    

Repeating the process after renaming the module:

  // PSKEY_DEVICE_NAME
  &0108 = 614d 6b72 7327 4220 756c 7465 6f6f 6874 5320 6570 6b61 7265
    
  aMkrs'B ulteoohtS epkare
     
  Mark's Bluetooth Speaker
    

You'll notice that when filtering for the name in PSTool, this value is shown just above the buttons on the right of the window:

Where 108 (hex) is perhaps the address in memory where this is stored or, given that some of the parameters can be variable length (like this one) or some of them take more space than others, it's more likely that this is the number of the parameter - the actual storage is managed at a lower level.

Just in case it might be of use to someone experimenting with this module, here is a copy of my backup. I can't guarantee it'll work in other modules or even other versions of this one, and as mentioned, I haven't yet tried to work out how you might restore a backup to the module.

Incidently, as I'm sure you're wondering, "PS" stands for persistent store...

Conclusion

These modules might not be the cheapest or most recent Bluetooth options out there, but they remain good value for money. The fact they can be re-named using a £15 interface and a little bit of effort sets them above a lot of the cheapest modules.

Downsides? They're quite an old Bluetooth version now, so aren't suitable for the highest quality applications. Even with all the mods I've done, there is a noticeable difference in sound quality compared to a direct connection - the SBC codec is quite basic in operation. So fine for a radio conversion or portable speaker, but not for your hi-fi.

The thing that makes these modules popular - the audio switching - is actually the least useful feature of this module for me. That might seem like a strange thing to say, but bear in mind that the module needs to be powered for audio from the existing radio to travel through. This immediately leaves it unsuitable for battery radios - and my radio collection is almost entirely transistor portables! This means that I'd have to add a switch to both switch power to the module and also the audio - at which point, the 4052 is doing nothing for me, so I could use any other module that takes my fancy...

There is another reason why the switching is much less useful for a transistor radio: signal level. The voltage from the detectors is usually less than 100mV, yet the Bluetooth signal is around 0.83V, as mentioned earlier. If we assume the detector output is 50mV, that is a massive 24dB difference! There is no easy way to reduce the level of the the Bluetooth signal apart from replacing those tiny surface-mount resistors. But even if you did that, you're now amplifying the output of the module by that 24dB, meaning you are much more likely to run into problems with noise! Far better to forget the switching, grounding the aux inputs so the 4052 is just acting as a mute switch, and then attenuate the output of the module. If converting to mono with a pair of resistors, you only need one more from the junction to ground to bring down the level by a factor of 10 to 16 - adjust to match your set.

So no matter what you do, you'll probably have to add a switch to allow the use of this module in a transistor set. It will need to be a double pole changeover to cope with the audio and power. Hopefully it can be added without cutting tracks or drilling holes. On a set with a hinged back, the switch could be placed inside on the chassis, but I accept that's not exactly convenient. One trick might be to add a microswitch to detect when the tuning has been turned all the way to one end, but double pole microswitches are rare. That said, you might get away with simply mixing the audio resistively with the output of the detectors. Or add a CMOS switch to deal with the audio in response to the power that is switched by the microswitch. But whatever you do, it's clearly quite a lot of effort.

But for mains-powered sets, this module might be a convenient option, providing you meet all the concerns raised earlier about keeping the 4052 happy - remember that signals need to be AC-coupled, and must be relatively small in amplitude to avoid distortion or damage. And also be prepared to experiment to get rid of digital noise.

If I find samples of the later version, I'll update this page to cover the differences.