Making a Bluetooth adapter for a Car Phone from the 90's

I finally acquired another Hands-Free Controller Unit for my car phone. In over 3 years of searching, this is only the 3rd one I've been able to confirm that exists, and the 2nd one I was able to buy.



The first one I bought was pretty corroded from what looks like sitting in water. I think the car it was in had suffered a broken rear hatch window, and was left outside in the weather with that broken window. Here's what that looked like:











A few components/leads that had constant 12V power supply in the car are actually completely corroded away to nothing. I got some help fixing the most obvious damage, but the audio circuit still doesn't work. The car radio audio doesn't even pass through the unit to the car speakers when not in a call. I just gave up and hoped I would find another in better condition.


Well, here it is... one in much better condition!







And to my disappointment, the audio circuit on this one doesn't work either, but the car radio audio does at least pass through. But it always passes through, even when in a call. And the hands-free microphone audio never passes through to the phone .

Failed capacitors (usually leaked electrolytes) are a pretty common issue in electronic components for these cars, so I looked for and found some evidence of crusty deposits under a capacitor. I also suspected that the audio switching relay may have been stuck (possible if the car had an upgraded audio system running more watts; could have welded the contacts together).

So first step was to verify if the relay works. I thought it would be safe to test by checking for continuity while applying 12V to the relay coil leads, with the relay still on the board. And it would have been safe if I hadn't misunderstood the diagram on the relay:




I interpreted "Bottom View" to mean, "this is a see-through view of the bottom, from above". What it really means is, "this is a diagram you must memorize or photograph, then flip the relay over to match it up to the leads, so the polarity of the coil is backwards from what it seems".

Yeah... I let the smoke out of the relay, killed the "freewheel" diode in parallel with the coil, and destroyed a trace on the board between the coil and the diode.

So I removed the relay, multiple suspicious capacitors, and the diode.

Before cleaning (diode not removed yet):



After cleaning:






A couple traces on the board have no continuity (one is my fault), leading to the audio circuit not having any power. I've ordered some replacement capacitors, diode, and relay. And I can easily bypass the damaged traces with wires on the bottom side of the board.

This is such an obvious smoking gun for the audio circuit not working. I'm really hoping this was the only damage that needs to be fixed. I'm obviously a complete amateur at electronic diagnostics/repair, so I hope I don't have to do any more.

And since I was ordering these parts, I decided to order doubles and try my luck replacing the same parts on my first water-damaged board. I already removed the components and found similar telltale signs of leaked capacitors, corrosion, and damaged traces in that same area, including the traces going from the relay for the audio output (explains why car radio pass-through wasn't working). Maybe I'll finally have some goof luck with this rare elusive module and end up with two properly functioning examples.

UselessPickles said:

Since I also support displaying Caller ID during an incoming call, I think it's unlikely that I'll be able to adjust my adapter's code to trigger proper hands-free operation for an incoming call just like the original phone. I may cheat and simply turn the "IN USE" indicator on during incoming calls

Click to expand...

Well, that was a dumb idea. If I set the "IN USE" indicator during an incoming call, then the Hands-Free Controller believes that a call is active, and then the "H/F" button on the steering column controls will trigger a simulated "END" button press to end the call (rejecting the incoming call), instead of simulating a "SEND" press to answer the call.

So I had to do it the hard way: capture commands from the original transceiver to the handset when simulating an incoming call from my mobile service tester to see what exact sequence of commands occurs, then narrow it down to the minimum sequence of commands necessary to trigger the correct Hands-Free Controller behavior (through trial and error).

Good news: I now have the Hands-Free buttons working as intended in all situations (answer an incoming call, end an outgoing or active call, speed dial, initiate voice command), and I have things working so that the Hands-Free Controller takes control of audio when it should, and relinquishes control of audio when it should.

Bad news: There's no way for incoming calls with Caller ID to be compatible with the Hands-Free Controller. Printing "CALL " to the display, followed by a couple other commands ("IN USE" off, enable blinking text) is what triggers the Hands-Free Controller to be in "incoming call" mode. But if I print any other character to the display afterward, then it breaks out of "incoming call" mode, and then it becomes impossible to answer the call using the Hands-Free control button.

There's no way for me to detect when the Hands-Free Controller is connected, so I'll have to rely on manually switching a mode on the phone to ensure that Caller ID is disabled when used in a vehicle with Hands-Free support.

SUCCESS!!

I was able to repair BOTH of my non-functioning Hands-Free Controller Units.

New capacitors (the 3 bigger ones all in a row) and a new audio output switching relay installed:




A few damaged traces on the are bypassed with some wire. Not my best soldering work, but the connections seem solid. One damaged trace and another questionable trace between the relay coil pins and a "freewheel" diode were bypassed with the leads of the new diode itself, since the traces were so short with nothing else nearby.




The other unit that has water damage needed a few more bypass wires (in addition to the same 3 new capacitors). This one also has some additional previous repairs that someone helped me with (that's why there's an extra diode on the bottom of the board that seems out of place). I had previously given up on this one because the board had so much corrosion all over it that it seemed hopeless to try to identify possible root causes of failure. But the obvious issues on my new clean board gave me ides to check for similar issues on this one, and the gamble paid off!




And here's the full setup I used to test the repaired units. A small speaker is standing in for the car radio speaker, and I'm using an oscilloscope to verify that the hands-free microphone signal is being passed through the controller unit:







Now I need to update my Bluetooth adapter circuit and code to handle the hands-free microphone input, and switch between it and the handset microphone depending on whether the handset is on or off hook.

The biggest issue to solve is a large difference in voltage level of the hands-free microphone (about 340 mV peak-to-peak) versus the handset microphone (about 5 V peak-to-peak). The Bluetooth module has configurable mic input gain at 2 different stages. These are my current settings that seem to work well with the handset mic output:



"MIC Gain (Codec)" ranges from 0 dB to 46 dB
"MIC Gain (Digital)" ranges from -19 dB to 20 dB

These are not settings that I can (easily) switch on-the-fly from the microcontroller, and synchronizing a change in gain with the input switching could add complications, so I need to normalize the two microphone inputs before passing them through the switch and on to the Bluetooth module.

My current thoughts are that it would be best to attenuate the handset microphone signal down to the same level as the hands-free microphone, then rely on the Bluetooth module's gain to bring both back up to whatever level is appropriate (the Bluetooth module likely has better quality gain circuitry than I would be able to put together).

Would a simple voltage divider (resistors) be sufficient for attenuating the handset mic signal?

UselessPickles said:

There's no way for me to detect when the Hands-Free Controller is connected, so I'll have to rely on manually switching a mode on the phone to ensure that Caller ID is disabled when used in a vehicle with Hands-Free support.

Click to expand...

I just realized that if I get a microphone jack that includes a switch to detect when a plug is inserted, then I can use this switch to automatically toggle between modes. When an external microphone is plugged in, then disable Caller ID, and also disable the "idle" feature where the handset backlight and audio circuit is turned off after 10 seconds of no button presses (conserves energy for battery-powered portable mode).

I now have the entire hands-free system working good enough to demonstrate!


I have the hands-free microphone input added to the circuit, and I'm automatically switching between the hands-free and handset microphones depending on the whether the handset is on or off hook. I kept the mic input circuitry simple for now assuming that I only need to support this particular Hands-Free Controller mic (it's an "active" mic signal that doesn't require me to apply any voltage/current to it from my circuit).

I think I'm nearing the limit of progress on breadboards, because there's just too much noise in the circuit for the hands-free microphone. My original plan was to attenuate the handset microphone signal down to the same level as the hands-free microphone, then configure the Bluetooth module to amplify its mic input. However, this made the signal-to-noise ratio for the handset mic pretty horrible, and the hands-free mic was even worse (absolutely awful).

I ended up using an op-amp to amplify the hands-free mic about 30x and it did a respectable job of amplifying the signal much more than the noise... but the noise is still amplified to an unbearable level. I have to shout pretty loud or talk very close to the hands-free mic to get a good enough SNR for my voice to be understandable on the other end of the call. But I've played around with things enough to have confidence that this is mostly due to noise in the power supply and ground connections throughout the circuit board that should mostly go away once I solder everything together.

Major tasks remaining:

• Add mic plug insertion detection circuitry and code to automatically switch modes when the external mic is plugged in (need to disable Caller ID to avoid interfering with the operation of the Hands-Free Controller).
• Rebuild the entire circuit on a soldered prototype board (requires coming up with an actual plan for the circuit layout, and juggling MCU pin assignments around as necessary; this is the part of the project I've been dreading).
• Pray that my noise issues are largely solved by simply having solid soldered connections. My plan is to run dedicated supply and ground routes to each major component (or small groups of components) from a common power/ground source.
• Tune the op-amp gain for the hands-free mic input to balance it with the handset mic signal.
• Tune the mic gain and noise suppression settings on the Bluetooth module.
• Enable and tune the Active Echo Cancellation feature on the Bluetooth module (the voice from the other end of the call currently echoes back through the hands-free mic pretty bad, causing the "speech jamming" effect on the person at the other end of the call).

Here's an updated component diagram for my car phone Bluetooth adapter. I added the audio jack for an external "hands-free" microphone and updated the circuit/code so it can detect when an external microphone is connected, and can switch between the handset microphone and the external microphone as the source for outgoing voice audio.




The breadboard prototype has become very messy!



I'm using this breadboard-friendly audio jack with internal disconnect switch that I was able to setup to trigger a transistor that pulls down an I/O port on the MCU when the external mic is disconnected. I followed the design from the diagram below (diagram source link).




The detection circuitry conveniently also provides a bias voltage for a simple electret-based external mic. I found a basic external microphone from one of my spare phones, and it actually seems to work well with the 1K resistor and 2.5V bias voltage that I'm using to bias all of my audio signals (not the full 5V Vcc). I know there's more to tuning the circuit properly based on the mic specs, operating current range, etc., but I have no specs for this microphone.

I updated my 2.5V bias voltage supply to use an op amp to buffer the 2.5V supply, isolating the resistor/capacitor network behind it (this was needed to simplify the op-amp circuit I use to amplify the microphone audio).

I added a user-settable config option for whether the adapter will be used together with the "Hands-Free Controller Unit". If enabled, and if an external microphone connection is detected, then Caller ID is automatically disabled to prevent interference with the Hands-Free Controller Unit's ability to infer when an incoming call starts/ends.

I even improved the adapter to automatically detect when the phone transceiver has external power connected. The original phone would keep the handset backlight and audio circuit turned on continuously when external power is connected, but would turn it off after 10 seconds of inactivity when running on battery power. I initially supported this behavior only through manual selection between the 2 modes. My adapter cannot directly detect when external power is connected, but it can detect when the transceiver is trying to send commands to the handset to turn the backlight and audio on/off, so I can infer when the transceiver has external power connected or not (after properly handling some special situations that I won't dive into now).

Everything technically "works" now, in that it does all the right things at the right time, automatically without any tricks or intervention from me for "proof-of-concept". The only gap in "functionality" now is audio quality:

• Significant noise in audio output to the speakers.
• Microphone audio from the integrated vehicle Hands-Free system is very noisy with quiet voice audio compared to the handset microphone and a simple electret microphone.
• I haven't even tried to setup echo cancellation on the Bluetooth module yet (need to solve other audio quality issues first).

I think it's time to start documenting the current complete circuit layout, reorganize it a bit, and rebuild it on a soldered prototype board to hopefully solve most of the audio noise issues. I'll wait til then before I share any detailed circuit diagrams. I already have some ideas for updating my microphone circuit to get proper volume levels with both types of external mic, assuming that the majority of audio noise disappears as I hope.

I've started the part I've been dreading: planning my circuit layout on a pad-per-hole perf board.

I'm using VeroRoute software to help, and have already created representations of the MCU, the Bluetooth module breakout board, the RJ45 jack breakout board I'll be using, the audio jack I'm using for the external microphone, and the 5V regulator that powers the whole circuit.

I don't think that auto-routing is going to help me much




I'm thinking that a reasonable starting plan might be to route all power/ground connections on the bottom of the board, then run most other data/signal/IO connections with wires on top of the board? I really just need to get all the components on the board first and start playing around with arrangements to see if I can minimize crossing of paths.

I think I'm about ready to order parts and build my first soldered prototype. It's been a struggle to organize the components in a way that I can make all the necessary connections without creating a huge tangled mess. I can imagine how this would be much simpler with a multi-layer PCB, but I'm limited to basically one layer plus jumper wires.





I really hope my ground routing is sufficient to eliminate most of the noise.

The whole layout is 4.8 x 6.7 inches, so I'm hoping it will fit nicely in this RadioShack 5 x 7 x 3 project box:

I'd take another look at that before ordering a PCB.

If I am understanding the format correctly, it appears you have lots of point-to-point wire links that do not cross PCB tracks and could be tracks themselves instead?

What's the reason for the PCB limitation? If you use EasyEDA you can get a two or four layer PCB made very cheaply.

Or, if you want to prototype it first, look at using a ground plane stripboard or square pad board?

(Vero "Microboard" 10-2845 is really good for low-noise prototyping as it combines stripboard, power tracks and a ground plane, but unless you can find one on ebay etc. the price is now ludicrous, it's cheaper to use custom PCBs).

rjenkinsgb said:

Or, if you want to prototype it first, look at using a ground plane stripboard or square pad board?

Click to expand...

Yes, I'm prototyping on pad-per-hole perfboard because I need the freedom to make mistakes and alterations, and the general fear that I would waste time and money getting custom PCBs made just to find out that there's problems and now it's very difficult to test changes.

As for all the point-to-point wires:

• I thought it might be simpler for my first attempt to follow a general pattern of routing power and ground on the bottom of the board as "traces", and all other "signals" on top of the board as wires, to help minimize confusion of figuring out all the connections and cross-overs between them.
• This software does have a limitation for wires that they can only be straight, which is why every corner shows a connection/solder point. I'll run a single wire with bends when building the prototype.

I'm using pad-per-hole instead of any kind of vero board with pre-defined strips mostly because I thought it would give me more freedom to position everything and make all the connections with less confusion about trying to optimize the use of the pre-existing strips. I think it may also allow for a more compact circuit too? And space is a concern, because I would like to put this in my car in the limited space of the storage tray in the trunk next to where the phone mounts.

I could be very wrong on all of this. But I think I'm doing it anyway for whatever valuable learning experience it may turn out to be (unless there's some clearly better approach that I don't know about yet that will be an amazing epiphany when I learn about it).

OK, that makes it a bit clearer. I'd still suggest a ground plane board, though - have a look at the Roth Elektronik RE201-LFDS; that's a pad per hole that has a top side colander ground plane.

It's a standard 100 x 160mm Eurocard size so not quite as wide as your example, but with the ground plane you could easily reduce the the spacing between the columns of ICs slightly, to allow it to fit.


The only consideration using a ground plane is to peel it away in the area around the Bluetooth antenna, if that is overlapping the board.

(I'd also be careful of the overall orientation if that is a metal front case, as the metal panel will affect the bluetooth signal).

rjenkinsgb said:

I'd still suggest a ground plane board, though

...

The only consideration using a ground plane is to peel it away in the area around the Bluetooth antenna, if that is overlapping the board.

(I'd also be careful of the overall orientation if that is a metal front case, as the metal panel will affect the bluetooth signal).

Click to expand...

I will definitely spend some time learning about boards with ground planes and how to effectively use them. I didn't even know that was a thing before today . I also found some info about adding a ground plane to a basic perf board with adhesive-backed copper foil. It looks like a lot of tedious work, but I also have already ordered perf boards without ground planes. I'll just have to see if I can find any boards with ground planes in the size I need, and decide how to proceed from there.

I've already paid attention to the Bluetooth module datasheet's recommendations on antenna placement relative to ground planes, components, and other metal objects. That's why I have it oriented "vertically" in that layout so the antenna can hang off the edge of the board with nothing around it on either side. Otherwise, I would have liked to rotate it 90 degrees for a smaller total footprint of the circuit.

And the project box I ordered comes with both a plastic and aluminum lid, so I'll definitely be using the plastic lid.

Thanks for the tips!

UselessPickles said:

Yes, I'm prototyping on pad-per-hole perfboard because I need the freedom to make mistakes and alterations, and the general fear that I would waste time and money getting custom PCBs made just to find out that there's problems and now it's very difficult to test changes.

Click to expand...

PCB's aren't as expensive, nor as slow to get made, as you might think - I had 5 boards 125x69mm for £10.61, including shipping from JLCPCB. At that price it's slow shipping, but they still arrived in less than two weeks from ordering - and if your boards are less than 100x100mm they are a special even cheaper price (£1.69 for 5 boards - plus shipping).

Nigel Goodwin said:

PCB's aren't as expensive, nor as slow to get made, as you might think

Click to expand...

My concern at this point isn't about cost/time to get one board. There's a very good chance that I'll have to experiment with making changes to the circuit still, and a perf board will allow me to do that. Not as easy as a breadboard, but still easier, cheaper, and quicker than updating a PCB design, buying more, and waiting for delivery.

I was getting ready to order all the parts to build another Bluetooth adapter (so I can keep my breadboard prototype fully intact and functioning for reference), but found that the INA105 "precision unity gain" op amp I'm using to produce differential audio is on back order (until October) and out of stock nearly everywhere. It's ridiculously expensive where I can find it. So time to find another way to accomplish the same thing.

First I tried working with other components I already have on-hand. I found this document about using 2 op-amps to convert a single-ended signal to differential output. Here's a diagram from the document:




I conveniently had a LMC6042 dual op-amp, and I already have a 2.5v bias voltage reference in my circuit, so I gave it a try. It produced the differential signal as expected, but it was noisier than my current approach of using two INA105's. There was a constant 62 kHz noise (nice clean sine wave, but only when connected to the handset) that mostly cancelled itself out, but worse was the substantial noise in the audio caused by digital UART commands being sent to the handset, which is one of the main things that the differential signal seems to be intending to avoid. There is lack of symmetry in the amplitude of the brief spikes caused by the UART commands, so they only partially cancel each other out.

Instead of going down the rabbit hole of trying to really understand op amps and how to select the correct op amp and supporting circuitry for the job, I think I'll go with a component I found that is specifically designed to convert single-ended audio to differential audio: The DRV134



I'll only need one of these instead of two INA105's, and it will operate on the same +/-5v supply I have setup for the INA105's.

I'm hoping it will basically be a drop-in replacement for my pair of INA105's and give me similarly clean audio. If I understand correctly, I believe the +6dB gain is not an actual gain applied to the signal itself, but both the positive and negative output are the same amplitude as the input and the total signal effectively doubles at the receiving end when subtracting one from the other. This would be identical to my current setup. Of course, I'll test this new component on the breadboard before committing to using it in a soldered prototype.

Now I just have to find replacements for some other random components (capacitors and resistors) that I had already added to a "project" list on mouser.com, but are now out of stock.

I got my breadboard prototype updated with the DRV134 replacing the pair of INA105 for producing the differential audio output. It works better than the simple circuit with 2 basic op amps, but not as well as the pair of INA105. There's now a noticeable amount of noise in the audio correlating with UART commands being sent to the handset.

I think it may be due to the lower common-mode rejection ratio specs on the DRV134:

• INA105 - min: 72 dB, typical: 90 dB
• DRV134 - min: 46 dB, typical: 68 dB

But I think at this point, I just need to keep moving forward with the soldered prototype and see if the better connections and grounding reduce that noise to an acceptable level.

In more interesting news: I discovered a cause for a difference in sound quality between the original phone and my Bluetooth adapter, and it turns out that my sound output was "too good"! I've occasionally noticed that the sound of my beeps and tones don't quite sound the same as the original phone. The original phone sounds a bit more harsh/shrill/piercing, while my tones sounded warmer/smoother.

Here's a close-up view of an audio waveform from the original phone producing a beep:



The DAC audio output is only partially filtered! I'm guessing this was an intentional design decision to retain some higher frequency overtones, which creates an illusion of the tones sounding "louder" and "cutting through" other background noise.

So I simplified my low-pass filter to a single stage with a higher cut-off frequency. It's not a perfect match due to differences in sample rate, and the original phone also seems to have some additional spiky noise when producing some other beeps (like DTMF beeps). I started playing around with trying to match the original phone's sampling rate and filtering, but decided it wasn't worth the hassle. It already sounds subjectively very similar, especially compared to my original more "perfectly" filtered sound.

Here's what the same tone produced by my Bluetooth adapter looks like now:



I tried to make a video comparing the different versions of the sounds, but it didn't work. Something gets lost in the audio recording/playback of the video, and they end up sounding extremely similar.

And my final update for now: I have an initial version of operating instructions for the Bluetooth adapter that explains what original behavior of the car phone is replicated/adjusted/omitted, and explains all of the new behavior provided by the Bluetooth adapter: https://github.com/UselessPickles/diamondtel-m92-bluetooth/tree/main/operating_instructions

I made some decent progress on building a more sturdy soldered prototype. I'm moving forward with the prototype board I already have because I wasn't able to find a board with ground plane that seemed big enough and was readily available, reasonably priced, etc.

I quickly learned that I should have gotten a single-sided board with square pads instead of a double-sided board with round pads/vias. I was originally planning to create all the power/ground traces on the bottom of the board by bridging solder across gaps. But that doesn't work so well with the this board because the solder really wants to just fill in the hole instead of staying on top of the board. So I had to change my approach a bit: jumper wires on the bottom of the board, combined with some use of clipped component leads to create junctions and small ground busses for the wires to connect to.

Here's a photo dump of my progress:










Still a long way to go, but I got enough done that I could program the microcontroller and confirm that it can communicate with the car phone properly. I still need to add all the components related to audio and Bluetooth. Here's proof of life!




I also made some cables for connecting the MCU programmer and the UART/USB adapter for console I/O:






And I cut some sloppy slightly misplaced holes in my project enclosure for the the RJ45 jacks and microphone jack. Good enough for a prototype. I'll eventually trim down the height of the project enclosure too.






Several stupid mistakes were made along the way that resulted in many hours of confusion and troubleshooting.

First, the the PICKIT couldn't communicate with the MCU (one incorrect connection and 3 connections I forgot to complete; took me 3 rounds of finding/fixing to catch them all). It's pretty gut-wrenching to see that error pop up that the PICKIT could not read the device ID after spending many hours across two days getting to this point. Then again after you thought for sure you found and fixed the problem... twice.

Then once the programming was successful, more confusion ensued when the handset was displaying the expected startup sequence, but button presses were not doing anything. But sometimes there was sporadic behavior like some phantom button presses had occurred. And every once in a while, real button presses would work for a short while.

After much double checking of connections on the board, MCU peripheral configurations, and pin assignments (which I had to juggle around quite a bit to adjust from the haphazard breadboard layout to the more organized prototype layout), I started probing the circuit with my oscilloscope. I found that the UART RX pin was receiving exactly whatever the TX pin was outputting to the handset. I checked for shorts between the TX and RX circuits and found none (using continuity mode on a multimeter). Then I switched to testing resistance in general and found about a 20k ohm resistance between the TX and RX pins! This made no sense! The TX and RX circuits were completely independent of each other, so there should be no way for them to has such a low resistance between them.

It turned out to be some solder paste on the board and MCU that was leftover from when when I was mistakenly using it as flux to help de-solder a mistake. I now know that solder paste and flux are different, and that solder paste residue is fairly conductive. After a cleaning mishap made things even worse (the brush I used to clean was apparently contaminated with something greasy and conductive), I finally blasted the whole board with electrical contact cleaner and scrubbed with a brand new tooth brush. All good now. And I already got some plain old flux for when I need to re-melt a soldered connection.

This is the most complicated soldering project I've ever done. Many lessons have been learned. Hopefully the rest will go smoother.

I confirmed that the voltage regulator is the tallest component in my circuit (not much taller than the RJ45 jacks), so I was able to chop about half of the height off of the project enclosure.

Unfortunately, the size of the enclosure tapers down a bit from top to bottom, so the lid can't properly set "into" the
top of the box, but instead sits on top of the edge. Good enough for a prototype.

I finally finished building my soldered prototype! It only took 3 rounds of testing and identifying small connections I had forgotten to make before it worked nearly perfectly.










Color coded wires:

• Red: voltage supply (mix of +12V, +5V, +2.5V, -5V)
• Black: Ground
• Green: Analog audio
• Yellow: Simple digital I/O (on/off signals)
• White: Digital serial data output from MCU
• Blue: Digital serial data input to MCU

The Good:

• Everything works!
• Most of my audio quality issues are solved.
• Most importantly, there's no noticeable background noise in microphone audio when using the car's OEM hands-free system microphone!
• No more audio noise caused by the Bluetooth module doing its Bluetooth stuff.

The Bad:

• There's still some light high pitch whine in the audio output, only noticeable when using the loudspeaker. Can't hear it when using the handset ear speaker.
• There's still some light audio noise caused when UART commands are being sent to the handset while the speaker is enabled.
• The OEM hands-free system microphone audio amplitude is substantially lower than the handset microphone. But when I use a simple passive external microphone, the amplitude is pretty similar to the handset microphone. I think I need to increase the gain of my op amp used for external mic gain, but also increase the current-limiting resistor for the mic jack bias voltage to decrease the amount of "pre-amplification" done within a simple passive mic?
• When using the OEM hands-free system microphone, my voice randomly cuts out sometimes for individual syllables or words. I'm hoping that this is because I'm not applying enough gain to the signal yet and sometimes the amplitude of my voice audio is just too low and gets filtered out as noise by the Bluetooth module? Or it's possible that the OEM hands-free controller itself is doing some strange stuff because of degraded capacitors? That controller unit does have a hands-free microphone audio processor chip that deals with filtering out constant sounds (If I just shout "AHHHHH" continuously, then it drops the volume of my audio drastically after about 1-2 seconds; probably a way of filtering out road noise in the car).

All in all, I'm very happy with the result! If I can get the OEM hands-free microphone audio working better, then I'll be perfectly happy with the remaining minor audio quality issues. Then I need to move on to calibrating the Bluetooth module's echo cancellation for hands-free use in the car.

I managed to calibrate microphone gain and echo cancellation on the Bluetooth module to a good starting point of "acceptable" hands-free microphone performance. I have nearly completely removed the "single-talk" echo (other person's voice echoing back to them through the mic), but double-talk performance is horrible (when the other person is talking, they can't hear me talk at all). The audio quality through the hands-free mic isn't great either (a bit muffled/distant sounding), but clear enough to maintain a conversation. I suspect it's the circuitry in the "hands-free controller unit" that's causing generally poor quality.

• Maybe I should replace all the 30-year-old capacitors in the hands-free controller unit and hope that improves microphone audio quality?
• I definitely need to spend more time trying to fin tune all the echo cancellation/suppression settings for optimal quality.

Today I took my car out of winter hibernation and installed the "hands-free controller unit" for the first time, then added my Bluetooth adapter.




And just as a quick recap, here's the hands-free microphone and answer/end/call buttons on the steering column:



And the phone handset in the storage area under the center console arm rest:




Aside from the less-than-ideal voice quality through the hands-free microphone, everything works great in the car!

• It automatically mutes the radio when making a call, or when there's an incoming call.
• Phone ringer and phone call audio comes through the passenger side speaker in the car, and it sounds great. The high pitch background noise is only noticeable if you try to listen for it (at least for me and my wife).
• Everything just does what it's supposed to do. It fully functions just like it was originally intended to 30 years ago, except with the addition of some modern features like voice dialing and voice control of music thanks to modern cell phone voice assistants.

I'll work on putting together a video tour and demonstration of the complete system in the car.