Unfortunately that's not a hobbyist reseller that will send me only the 1 or 2 units I need. Still looking for a supplier that I can actually buy one from.

Ask for a sample?

WT32i? No experience with them, but one I had as a bookmark.

https://www.silabs.com/products/wireless...th-audio-module

Not sure how you'll go using it as the dev board looks a little hard to get. You want a dev board type unit to make it easier to connect to, power etc right?

Thanks, Shonky, I'll have a closer look at that one too.

Current status of support for RN-52 chip:

Have managed to get the ground loop noise fixed by being more careful about power and grouding in my breadboard layout, and also by specifically grounding the "Mic -" connections.

There is still a problem with the gain settings on the chip. The empeg line level outputs are way overdriving the RN-52 inputs and making them clip by a large amount.

Trying to solve the gain problem:

- Turning down the Empeg's volume helps, but not completely. Can't turn it down quiet enough to stop it from clipping.

- There is discussion of the mic/line gain here: http://www.microchip.com/forums/m770128.aspx which says "The microphone gain can be changed from -3dB to 42dB in linear steps. If the gain is set to less than 24dB using the ‘SM’ command the line in mode is automatically entered."

- There is indeed an "SM,xxxxxxxx" command which is supposed to adjust the microphone gain, but it does nothing, no matter what I set it to the gain never changes. I can set it to all zeroes and reboot the unit and... still the same volume, gain still clipping.

- Datasheet on the chip says "MIC_BIAS requires a minimum load to maintain regulation. MIC_BIAS maintains regulation within 0.199 and 1.229 mA. Therefore, if you use a microphone with specifications below these limits, the microphone output must be pre-loaded with a large value resistor to ground." - I tried a 10k ohm resistor from Mic_Bias to ground, no change.

- This page: http://www.microchip.com/forums/m843896.aspx hints that there is an "SL" command to set line level to go with that "SM" command but I cannot get it to work, even based on the information that the person in that thread said to set it to. I try to do a "GL" command and it just says "ERR", and all variants of the "SL" command that I try give me "ERR".

- There is also at that same page http://www.microchip.com/forums/m843896.aspx a schematic for converting speaker level to line level using a couple of resistors. I may try that. But I feel like I shouldn't have to if the chip is supposed to support it directly.

Though the speaker-to-line circuit (with the 10k and the 1k resistor) seems to work to reduce the gain, I'm concerned about overall quality of doing that. Basically now I'm still using the chip at mic-level and bringing down the empeg's output to match. I still have the keep the empeg down at about -15db to keep it from overdriving the RN-52 input even with that circuit.

As long as the input impedance of the device is high enough, a resistor divider should be fine but you're right regarding the gain settings that should work and you shoudl be using the line level inputs and you shouldn't have the bias issues as it really should be simple voltage output from the empeg into a high impedance line level input

However you say -3dB to +42dB "gain" which is basically an amplifier. You're saying the empeg is overdriving by some 15dB so -3dB isn't going help that enough.

There's an empeg setting to limit the output isn't there?

Yes, there's an empeg setting to limit the output, but my idea is that I want the best audio quality so I want everything to be at line level with the correct dynamic range. My feeling is that I should be able to set the empeg at 0db and then control the gain at the bluetooth chip's input. So I'm not sure what to be expecting from this thing.

0dB at the empeg is referenced against what it considers maximum output. 0dB on its own means not a lot. Was that 4Vpp lineouts? RMS? I don't remember

What is the input maximum for the device? It won't be 4V pp
or RMS.

It's unlikely you'll be able to input a high signal and have a significant negative internal gain as the input circuitry will still need to accept the higher input. So you'll ultimately need to limit or reduce the output of the empeg.

Yes it's best to have the highest output possible, particularly in car audio, but you're not going to hear (or lose) any significantly quality IMO between running the empeg at full and reduce it vs running it at a lower level *unless* the cable between the empeg and the BT device are picking up significant noise.

Yeah, the audio out through the dock connector should be a different level than that on the RCA line-out jacks. Tried the former yet?

Thanks for that information, Shonky!

Currently what I'm trying is a circuit like this, except where it says "speaker" it's the empeg line outs, and where it says "line out" is where I'm plugging it into the RN-52 chip. (obtained from here.)

Do you think that would work, or do you think there is a better way?

Maybe I should really just put a variable stereo pot on it so that I can adjust the attenuation?

Something else I noticed that I'm wondering about...

I think the RN-52 might have some sort of "auto gain" on its mic input that I need to figure out how to turn off. For example, on a song that fades out, it appears to be playing the music at full volume all the way to the very end of the song.

Regarding the Silicon Labs WT32i, I found this interesting thing:

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

This looks real interesting to me. Look at all that audio I/O on that dev board. Haven't looked up pricing on it yet, but wow.

Edit:
http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=49919
https://www.ebay.com/i/263156265565?chn=ps&dispItem=1
https://www.silabs.com/products/wireless...th-audio-module

I think I'm going to abandon the RN-52 and try that BlueGiga WT32i module. I've ordered one of those fancy reference kits with all the RCA plugs.

I figure that the RN-52 seems to have had only one firmware release of the "Source" mode firmware, and that firmware is really half baked. Their gain control command doesn't do anything. Also I noticed that the command reference has no way of entering track metadata at runtime in source mode, so I wouldn't ever get to have track data in there.

So I think I have a better bet with that BlueGiga module since clearly their refernce kit has RCA inputs and it's intended to be a high quality audio interface.

Despite my fear that doing literally anything to improve my car will surely result in its death, one of these would probably convince me to figure out how to dissemble the dash and get the empeg in... and probably replace the dead speakers too.

Cool, thanks! This is encouraging. I'm hoping to get the prototype working, and then refine it into an easy-to-duplicate kit. Maybe Stu would want to sell the kits once it's ready?

I'm deeply disappointed that I'm now on my third bluetooth chipset trying to get this thing working. Should have had it done by now. Honestly that BC127 should have done the trick if it didn't have that weird bug where it's incompatible with my car stereo.

I have high hopes for the BlueGiga chip set based on how audio-focused that dev board looks. The datasheet and docs are also very audio-quality focused, down to the level of describing how to run the audio/ground traces for the best noise rejection. So, crossing my fingers.

I made some good breakthroughs with the BlueGiga development board today. It initially had some of the same problems as the other two chipsets, but it has a much more complex and flexible commandset, so I was able to fix them the right way with the right commands.

This one doesn't have dox about how to set the Track Metadata on the A2DP/AVRCP channel (it shows how to receive that data but not how to set it). I haven't experimented with that yet but that's the last hurdle. Crossing my fingers.

More later. Optimistic about this one.

I'm just waiting on deck for this to go through! I want to try the same in the new Subaru.

Sorry it's taking so long. :-)

I hope to have finished example Arduino code, prototype assembly instructions, and prototype bill of materials within the next week or so if I'm lucky. That might be enough on its own to get you going.

Then after that, the next step is a custom "sandwich" PCB board to connect all the parts, instead of using a bunch of jumper wires, and a custom housing box for housing all the parts, to turn it from a messy prototype assembly into a buildable kit.

First version of the firmware will be Bluetooth A2DP audio and AVRCP controls, but no track titles on the car's screen yet.

Assuming that everything above works, and I can find the correct commands to get this chipset to send track titles to the car screen, would you be interested in helping with the necessary empeg-side code to get it to spit out parseable track metadata on the serial port? I think you'd be able to do that part much faster than me.

I would likely be inclined to skip the Arduino and just have the empeg talk directly to the BT adapter. In which case I'll add a "BT mode" to the existing Hijack menu for the Serial Port, along with anything necessary to make it work there.

Mostly just need to know if it really can do track data on the HU display or not.

That makes sense. I have a lot of information about how this thing works, and also a lot of information about things that are still not working about it, I could send you what I've got privately.

I'm finding that there are quirks about its initial handshaking with a device right after you pair with it, and it may work fine on one device and not on another, and I'm trying to figure out how to configure and program the thing so that it works in all cases. This is really tricky.

Example: I found that if I pair up with my car stereo and wait for the pairing to complete, I get a certain set of messages on the console. It doesn't work properly until after I issue an "A2DP STREAMING START" command to the chip, at which point everything works well. Except unless I get the timing wrong of exactly when I send that command. If I send it too soon then it has the old "30 seconds delay" problem on the steering wheel controls. But if I send it later it still has the same problem. And there's no documentation telling me how to do the initial handshaking. Also on my bluetooth headset, audio doesn't stream until I issue the "CALL <btaddr>" command but on the car stereo it streams fine and the "CALL" is automatic. Issuing the CALL command on the car stereo doesn't fix any issues.

Another example, the docs for the A2DP/AVRCP communication seem like they have a lot of good syntax examples, but in practice none of the examples work as expected and the entire system is almost completely inscrutable: https://www.silabs.com/documents/login/application-notes/AN986.pdf (link won't unlock for you until after you sign up for an account at their web site).

For instance, in the document linked above, for the track titles, it looks like what you are supposed to do is register with the headunit to respond to notifications where it requests to get the track titles from you, and then you respond with the track titles. But the syntax is poorly documented and only a single non-working example is given for doing it.

So I'm pulling my hair out on this one. :-)

Mark, here's my current information about the BlueGiga WT32i board, all contained in comments within my work-in-progress code.
https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

If you're planning to connect one of thse WT32i ports directly to the empeg serial port, and write all the code on the empeg, then all you'd need is:
- RCA cables to the Line In ports of the WT32i.
- 5v power to one particular pin of the WT32i.
- Ground (of course).
- Serial RX and TX in a crossover configuration to the WT32i's RX/TX pins.
- The latter will have to go through the one of those usual RS-232 chips that allows you to connect a UART to an RS-232 cable. I forget what you call that thing. In my case, I'm using an RS-232 shield for the Arduino that has that little chip in it. I expect you'd roll your own there.

I have it paring and working on the following things:
- My Honda car stereo.
- A plantronics mono headset/earpiece.
- A cheap third party stereo bluetooth headset.

With the BlueGiga WT32i development board, the audio quality from the empeg is immaculate. Playing the same song direct-digital from my phone to the car stereo, versus playing the song through the empeg using the line-inputs on that BlueGiga WT32i board (into its ADC and then to the car stereo), the audio quality of those two sources are indistinguishable from each other. I have to strain to hear any differences at all, and then I can't tell which one is objectively "better". Also: No detectable ground loop noise that I could hear (but I don't have my power supply working yet so maybe that'll come later).

It processes play/pause/next/prev commands from the bluetooth devices (ie the car stereo screen or steering wheel, or the pushbuttons on the headsets) and changes the tracks on the empeg as expected. That's enough to get me going, but not quite everything that we want yet...

I haven't been able to get track titles to work yet. In theory the car stereo should be querying my bluetooth chip for the track titles, and then my code is supposed to respond, but it doesn't seem to do that: I don't see the query for the track titles ever showing up on the bluetooth chip's serial port. There must be some configuration tweak that I'm missing.

Sometimes (not always) the car stereo will query for other data unrelated to the track titles. But I can't even seem to get those queries to show up reliably, even when I try. (Right now my code tries to shut off the queries but I'm not even sure about those.)

Their documentation supports it all though:
Command reference: https://www.silabs.com/documents/login/reference-manuals/iWRAP6-API-RM.pdf
AVRCP command reference: https://www.silabs.com/documents/login/application-notes/AN986.pdf
(You have to set up and log in to an account at the silabs web site to get those files.)

From their docs:


The problem is knowing how to configure the chip so that the car stereo even knows to send the queries in the first place. Not sure how to do that, the documentation is extremely hard to follow. Maybe you can look at those docs and see how it's done?

I'm in Ohio for several days and I'll come back to this late next week.

Documents are not protected by a login.

Have you played around a bit with the arguments for the commands:

SET PROFILE AVRCP TARGET 7
SET BT CLASS 280428

I suspect you need to enable a bit in the second one. Maybe just try setting all the bits? The car audio system will/should probably only look for ones it cares about.

You've selected "Car Audio" but that's not what *your* device is so sounds a bit strange but I'm not an expert.

Very cool, and very generous of you Tony!

I'm actually not quite ready for it on this end -- techie things are indoor winter projects up here, so not until January most likely.

Meanwhile, I am hunting for the A/C clutch relay in my new 2018 XV Crosstrek, so I can wire up a kill switch for the A/C. Unfortunately, nobody seems to know where such relay is located on the vehicle, or even if it exists. The service documentation shows a location clearly labelled as "A/C relay", but in fact that slot in the relay box is empty from the factory. Duh..

Shonky, those are excellent suggestions, I'll give that a shot.

Mark, good luck with finding that info about the relay. :-)

Did you check your compressor to see if it even has a clutch? A lot of new cars don't, they have a modulating valve built into the compressor and just allow it to bypass when not needed.

Dunno, but it could be something like that. Just weird that the factory service manual at the dealership shows a (non-existent) relay.

The compressor has two electrical connectors attached to it. One has two wires, the other has three wires. Both disappear into a massive wiring harness.

EDIT: Ah, found this description:

Apparently some Subaru vehicles began using those in 2010, though my deceased 2013 Impreza still had a clutch. Looks like perhaps the new Crosstrek has one of these newfangled beasts. Effectively, the "clutch relay" equivalent is built-in, so I just need to figure out which wires for for that part, and install my kill switch onto one of those.

EDIT2: Yup. Denso TSE14F: ECV Compressor. Thanks for the hint!

EDIT3: Good description: https://axleaddict.com/auto-repair/Variable-Displacement-Compressors

In the early days of the variable displacement compressor, some still had clutches. My '06 Volvo is that way, the clutch engages just once, the first time the compressor is needed, and stays on 'till you turn off the car.

The variable compressor is a "first world" thing, probably in other markets they use the simpler old stuff, which is why you would still have a place for the relay.

Given this new info, do you still think you need a kill switch?

Yes. Like most other vehicles of this era, the car automatically turns on A/C whenever I direct internal air flow at the inside of the windshield. On most of the planet, this is an okay idea.

In Canada, in winter, at -20C, it is a very bad idea. We need hot air directed at the windscreen to melt the friggin ice, snow, and freezing rain while driving. If the A/C is cooling that heated air by 5-10C, then the system cannot keep up with ice accumulation, and visibility suffers.

Having A/C on in the dead of winter gives another problem too: damp air in the ventilation system after A/C has been on and the ice it created has melted. Next time one starts the car, this damp air blows onto the windshield and instantly freezes, icing up the inside of the window. Which then requires running the A/C to get rid of it, thus perpetuating the cycle.

Interesting!

My old Honda would default to turning on the compressor in defrost mode, but I could turn it off with a single button press. The new one, I honestly haven't had a chance to even think to try yet. Hasn't been cold enough in Seattle this year yet.