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

[UselessPickles]

Are you programming in assembler or C?

I'm using C. I don't really understand what you mean by "all the interrupt saving issues are taken care of" in C. Just to clarify, I'm talking about the interrupt enable bits; not the interrupt "occurred" flag bits. My problem was that something was always immediately waking the MCU immediately after putting it to sleep. I still don't know what it was, but the simplest and most reliable solution I found was to disable ALL interrupts except the one I want to wake from sleep. I'm not sure how this could be done more simply than storing a copy of all the interrupt enable registers before clearing them, so that I can restore them to their previous state when waking.

What 5V regulator are you using,

STM L7805. And now I know I know what "quiescient current means" and that I should pay attention to it. It's listed as 4.3 mA for this part

Thanks for the tip on MCP1702-5002. It's a reduction of output current compared to my current part, but 250 mA is more than enough for what I need. The L7805 was overkill. I wish I didn't have to pay $5-8 in shipping and wait up to a week for delivery every time I find another $0.64 part I want to test.

Battery monitoring is an issue, but can easily taken care of by a buffer opamp

I tried that already, but apparently the opamp I somewhat arbitrarily selected is a very power hungry part. It draws about 1 mA, which is not much less than a simple voltage divider that stays within the 10kOhm max impedance recommendation for the ADC input of the MCU.

I guess I need to dig into understanding opamp specs more and test with some other parts (I also had issues with the output being non-linear with respect to input as the input approached Vdd)

So basically, have the low power 5V regulator feeding the PIC, and then an FET switch feeding the 5V to everything else - switched ON and OFF by the PIC

I'm already doing this for switched power to the handset and all audio circuitry that isn't used when "off", but with reed relays (partially because I understand how those work and got a bit overwhelmed why trying to research all the different kinds of transistors and FETs).

I want battery voltage available while "off" so that I can avoid attempting to turn on if battery level is low, so I currently have the battery level voltage divider powered by the same "constant" +5V as the MCU. It would just be a matter of adding a bit more complexity so that I can control power to the voltage divider independently of the rest of the circuit to get a voltage reading before deciding whether to power everything else on.

I actually considered this already, but decided it wasn't worth the extra complexity for now, and using up the one remaining unused I/O pin on the MCU that I may want to use for another purpose in the future.

One point to watch is what peripherals are doing while the PIC is in sleep - if you're not careful things like serial ports can draw draw current out the pin while it's sleeping, to cure that, disable the serial port, and set the pin LOW.

Thanks. I'll review what state all my I/O pins at the time I'm going to sleep and see if I need to do anything more than I already am. I already saw significant decreases in current draw by disabling the UART peripherals when I don't need them, which I think accomplished what you are saying, because UART wants to hold the TX line high at all times when not sending data. I never manually set the output value of those pins, so they should default back to low when the UART peripheral is not controlling them. I'll check if I have any other I/O pins held high by default that I should set low when sleeping.

I'm quite horrified by 1.22mA just for battery monitoring.

Yeah, I know . But in the grand schema of things, it doesn't really matter based on how this car phone will be used. It will be mounted in the car most of the time connected to the 12V power of the car to maintain battery charge, and only removed from the car and used on battery power for a few hours at a time occasionally (e.g., carrying it around while I'm at a car meet). Even before I was able to successfully put the MCU to sleep and my circuit was drawing 8.3 mA when "off", it was still way less parasitic draw as an entire system (including the battery charging module) than the original car phone when installed in the car with the car turned off.

The original car phone with its battery charging circuitry for NiCad batteries draws 159 mA when the batteries are fully charged. My complete project should now be below 40 mA when off and fully charged. So I'm not concerned about it draining my car battery while parked, even for weeks at a time.


I think for now I'll definitely try the voltage regulator you suggested, because that is an easy change with a proportionally huge reduction in power consumption when sleeping. Just that change alone should get me down to about 1.22 mA (voltage divider) + a handful of uA for the MCU and voltage regulator. That's plenty efficient for my needs and keeps battery voltage detection simple.

I could maybe even try doubling the values of my resistors (or more) beyond recommended max impedance for the ADC input. I think I would just have to increase the amount of time I configure to allow for sampling, because it will just take longer for the sampling capacitor to charge (or add an external capacitor to the ADC input pin to act as a "reserve" to allow the sample and hold capacitor to charge quickly)? I'm only reading the voltage once every 5 seconds. I don't need a high sample rate and fast samples

 

[UselessPickles]

Battery monitoring is an issue, but can easily taken care of by a buffer opamp (I use the MicroChip MCP6022), allowing the use of much higher value resistors in the potential divider

I just looked up the datasheet on this opamp and it has the same supply current rating as the opamp I tried using already: 1 mA. Which is only 0.22 mA less than my simple voltage divider is consuming now.

So it's really the MCU-controlled power switching to the voltage divider (and/or opamp) that would really reduce power consumption. I think it's just not worth the effort, extra complexity, and giving up my one last unused I/O port to do this.

I'll just try the more efficient voltage regulator you suggested for now, keep my battery voltage detection simple, and that's plenty good enough for me (reasons explained more fully in my previous post),

 

[Nigel Goodwin]

I just looked up the datasheet on this opamp and it has the same supply current rating as the opamp I tried using already: 1 mA. Which is only 0.22 mA less than my simple voltage divider is consuming now.

Yes, but the point is you switch power to it OFF when in sleep, which of course you could also do with the opamp you tried.

So it's really the MCU-controlled power switching to the voltage divider (and/or opamp) that would really reduce power consumption. I think it's just not worth the effort, extra complexity, and giving up my one last unused I/O port to do this.

A simple dual FET (one n-channel, one P-channel), and two resistors (I use 2x4.7K) and it really wipes out lot's of problems The tiny little FET I use is also incredibly high current.

I'll just try the more efficient voltage regulator you suggested for now, keep my battery voltage detection simple, and that's plenty good enough for me (reasons explained more fully in my previous post),

To be fair, for a car it doesn't really matter that much - as you've got massive battery capacity - whereas I'm trying to run items for years on a small battery.

 

[Nigel Goodwin]

I'm using C. I don't really understand what you mean by "all the interrupt saving issues are taken care of" in C. Just to clarify, I'm talking about the interrupt enable bits; not the interrupt "occurred" flag bits. My problem was that something was always immediately waking the MCU immediately after putting it to sleep. I still don't know what it was, but the simplest and most reliable solution I found was to disable ALL interrupts except the one I want to wake from sleep. I'm not sure how this could be done more simply than storing a copy of all the interrupt enable registers before clearing them, so that I can restore them to their previous state when waking.

Right, I presumed you were storing all affected registers and flags, which you have to if you're using interrupts in assembler.

It should be easy to find out what interrupt is causing it though, but in any case you probably don't need to store and restore the enable bits, just disable ones you don't need in sleep, and then re-enable then as it wakes up.

I generally wake from sleep every second (using a TMR0 interrupt from a 32KHz crystal), or from IOC interrupts from I/O pins.

I was just checking what my logger routines do:

FVR_Enable(1);              // FVR on
ADCC_Enable(1);             // ADCC on
UART1_Enable(1);            // UART1 ON
I2C_Enable(1);              // I2C on

This is called when the alarm time is reached, at the beginning of the routine to transmit the data, enabling the various peripherals, then after that the FET switch is turned ON, to power the GSM module. Once the data is sent, the power is switched OFF, and the reverse of the enable code is run, to turn the peripherals back OFF. All four of those make a worthwhile difference - FVR was probably the last one I thought about

The only extra interrupt used is for the UART routines, and disabling the UART stops those running.

 

[UselessPickles]

Yes, but the point is you switch power to it OFF when in sleep, which of course you could also do with the opamp you tried.

So what is the benefit of using the opamp buffer with high value resistors in the voltage divider if you still have to switch power off to it when sleeping to realize power savings? A simple voltage divider with lower value resistors draws about the same amount of current and could just as easily be switched off when sleeping.

To be fair, for a car it doesn't really matter that much - as you've got massive battery capacity - whereas I'm trying to run items for years on a small battery.

Exactly. Anywhere I said that it wasn't worth the effort/complexity should be assumed to be qualified with "for my use case". It's definitely worthwhile for what you are doing.

And I would like to clarify that my car phone will be a hybrid vehicle-mounted and portable phone, so I am still concerned about power consumption to a certain extent when in portable mode and my project is powered by 3 3.7V 1100 mAh batteries in series. My estimates seem acceptable so far. I'm expecting:

• About 10 days battery life when off/sleeping (this should improve quite a bit with the changes I am planning to try).
• About 16 hours of "standby" battery life (phone powered on, not in a call, handset hung up so the handset backlight and audio is powered off.
• About 5 hours of "talk time" battery life.

This is already better than the original car phone, and it's a novelty/toy that isn't expected to be used all day every day like a modern cell phone. It's not an important tool that someone will expect to be able to turn on and use after leaving it sit powered off for a month. After my next round of planned improvements, I think I'll be heading into the realm of diminishing returns if I worry about optimizing power consumption more. But I'm definitely enjoying squeezing out as much as I can reasonably/easily do without derailing my current design much.

 

[UselessPickles]

I bumped up the values of my battery voltage divider resistors by a bit more than a factor of 10, increased my ADC acquisition time by a factor of 10, and added a 10 nF capacitor to the ADC input pin of the MCU. I'm still getting usable and stable ADC readings. The nice thing about my use case is that it doesn't really matter if my ADC readings are inaccurate due to exceeding the impedance recommendation, etc. All that matters is that the readings are consistent for a given voltage so that I can map approx max and min battery voltages to raw ADC readings.

I've dropped my "sleeping" amp draw from 4.55 mA to 3.33 mA. Yes, the math doesn't quite add up because I previously claimed by voltage divider was consuming 1.22 mA, and I clearly didn't reduce it down to zero. It should be about 0.14 mA now. I think my multimeter just isn't accurate enough at these levels.

I'll be ordering the MCP1702-5002E/TO voltage regulator this weekend (the through-hole variant of the part suggested by Nigel, so that I can test on the breadboard). This part claims 5 uA quiescent current, compared to the claimed 4.3 mA of the part I'm using now, so expect to see a big drop in "sleeping" current draw when that arrives (hopefully by next weekend).

 

[Nigel Goodwin]

I bumped up the values of my battery voltage divider resistors by a bit more than a factor of 10, increased my ADC acquisition time by a factor of 10, and added a 10 nF capacitor to the ADC input pin of the MCU. I'm still getting usable and stable ADC readings.

As long as you're only using one ADC input, it doesn't matter much - the issue is if you're switching between different pins, as the sample and hold capacitor takes time to charge/discharge, as long as it's just one pin it stays charged correctly.

 

[UselessPickles]

you probably don't need to store and restore the enable bits, just disable ones you don't need in sleep, and then re-enable then as it wakes up

It turns out that I don't need to disable/re-enable any interrupts.

Disabling all then restoring them was my brute force way of making it work because I wasn't sure which interrupt was waking from sleep (and I wasn't sure how to identify what caused the wake from sleep). I did this before I added code to disable peripheral modules before sleeping.

I tried removing all my code that stored/disabled/restored interrupt enable bits and everything is still working, so it must have been one of the peripherals that I now disable that was causing trouble. I still don't understand what the problem was before, but it's not worth caring any more because I'm disabling everything I don't want running and it's working now.

 

[UselessPickles]

So I've haven't been thrilled with the idea of using a pair of relays for switching power on/off (high power waste just to keep it switched on, risk of mechanical failure). But it's very simple compared to everything I could find about setting up high-side switching with transistors/mosfets, especially when I need to use the 5V I/O of the MCU to switch a 12V power supply.

But today I discovered the existence of "load switch" ICs!

The TI TPS22810 (link to datasheet) looks like it could work well. Am I interpreting this correctly? Could I really just use this IC pretty much just like a relay (in terms of circuit simplicity)? As I understand, I could use the 5V I/O output of the MCU to switch 12V power supply to the handset, and the only additional external component I need is a 1uF capacitor (and I could also use one to switch 5V to the rest of my circuit too?).

Is there some "devil in the details" gotcha I need to worry about, or does this really practically work like a solid-state relay?

Looks like it also has some cool features like configurable low-voltage-cutoff, rise time when switching on, and discharge rate when switching off.

BTW - Here's a webpage to help find a load switch from TI that meets your needs: https://www.ti.com/power-management/power-switches/load-switches/overview.html

UPDATE: looks like the TPS22917 (link to datasheet) would be better for switching my 5V circuit because it has much lower shutdown and quiescent currents (and I don't need support for the higher Vin voltage levels of the TPS22810 for the 5V circuit). And here's a link to a comparison that shows the specs of both parts side-by-side. I think I'll order a few of each and some breakout boards so I can test them on my breadboard prototype.

 

[UselessPickles]

I received my new Bluetooth daughterboard PCBs the other day and assembled one yesterday. I still hate soldering that BM62 Bluetooth module to the board. The rest of the surface mount components were very easy by comparison.

And a side-by-side comparison with my first design with through-hole components:

I like the new design much better

 

[UselessPickles]

As long as you're only using one ADC input, it doesn't matter much - the issue is if you're switching between different pins, as the sample and hold capacitor takes time to charge/discharge, as long as it's just one pin it stays charged correctly.

I am only using one ADC input (and only performing a conversion once every 5 seconds). I tried removing the 10nF capacitor and increasing my battery voltage divider resistors by a factor of 10 again (now at 560k and 330k). Success! I'm still getting stable and equally accurate ADC readings as before (or at least close enough that I didn't casually notice a difference), and now my voltage divider should be drawing only about 13.5uA.

 

[rjenkinsgb]

The load switch ICs look interesting, but you only need a couple of transistors and two resistors for a high side switch & you can select components that JLC can assemble from stock.

eg. One NPN "digital transistor" plus a P channel MOSFET with a gate-source resistor & a series gate resistor, low value surge limiting or higher to act as a divider if the switched voltage is higher than the safe gate voltage.

 

[UselessPickles]

The load switch ICs look interesting, but you only need a couple of transistors and two resistors for a high side switch & you can select components that JLC can assemble from stock.

The TI load switches are stocked "extended" parts at JLCPCB. So far, I have been unable to find any "basic" parts matching any of the components that I want/need, so if that trend continues, then the load switches may end up being cheaper anyway because of fewer components to pay the $3 load fee. Also fewer components to solder if I assemble any boards myself (I'm only paying to have 2 of the 5 boards assembled to limit my initial investment into a PCB design that I haven't been able to test yet).

Understanding how to choose the individual transistors, mosfets, resistor values, etc, is where I got hung up. I kept getting lost in explanations of how they work, requirements to make them work, etc., and don't know what specs to look at to pick parts that will work for me. The load switches are something I can understand and look at their datasheets to pick one that meets my needs pretty confidently.

Fewer components, a specialized component designed to efficiently do exactly what I need, and simpler circuit design all seems like good things to me.

 

[UselessPickles]

So far, I have been unable to find any "basic" parts matching any of the components that I want/need

I decided to dive deeper into this because I find it hard to believe that NONE of my resistors or capacitors are available as "basic" parts.

It turns out that the "footprint" filter can have many different variations of representations of the same exact footprint (e.g., "1206", "3.2x1.6mm", "SMD3.2x1.6mm", "SMD,3.2x1.6mm", etc.), and I needed to find and select all of them. Then I was able to find a grand total of 15 different resistor values available in the footprint I am using.

So there are several resistor and capacitor values I can use from "basic" inventory that will help reduce the cost of these boards

 

[UselessPickles]

I started working out details of how the Bluetooth module daughterboard will physically connect to the motherboard.

Here's the original connectors between the "transportable" cover and the transceiver. This connects the NiCad battery and battery charging circuitry to the transceiver.

The connector in the cover is loosely mounted with oversized holes that allow it to self-align as you install the cover on the transceiver:

And the socket on the transceiver is quite tall with a sturdy base so that it can stick up through the hole in the lid:

So I'm attempting to replicate this connector setup reasonably closely. Here's the best I came up with so far.

For the socket in the transceiver, I'm using this socket with very long "tails" and a stack of small custom PCBs to form the base:

For the connector on the cover, I soldered a shrouded pin header to a small custom PCB with the same oversized mounting holes as the original connector:

I had to cut the ends off of one copy of that PCB and glue them on to double up the thickness. The combination of the beveled shroud and beveled holes on the socket help with self-alignment, but not quite as well as the original connectors.

But that shroud is larger than the original connector, so I had to grind some material off the metal mounting plate:

Looks like I didn't have to grind off quite that much material.

The next problem is that the shrouded pin header makes contact with part of the transceiver case lid, so I also had to grind some material around the edge of the hole in the lid (original top; modified bottom):

And here's the basic idea of where the Bluetooth daughterboard will go (in the compartment for the large rechargeable NiCad battery):

I have two options for routing wiring between the Bluetooth daughterboard and the connector:

1. The long route (yellow line) under the metal plate (where the original battery charging circuit board belongs). this requires no further modifications because this partially follows the route of the original wiring, then there's a gap the wires can pass through into the battery compartment where the battery contacts of the charging circuit used to be.
2. The short route (red line), but this would require cutting/grinding away some plastic to make a gap for the wires to pass through directly into the battery compartment.

The final problem to solve: how do I mount the Bluetooth daughterboard in there? For my first prototype, I think electrical tape will be good enough. But long term, I think this my excuse to learn basic 3d modelling for 3d printing. I could make a plastic tray tray with mounting holes/posts that clips into the battery compartment the same way that the original battery clips in. Then I'd also have to update my Bluetooth daughterboard PCB design to have mounting holes.

 

[rjenkinsgb]

Could you attach a strip of plastic somehow under the metal lid with clearance around the upper screw, so it protrudes into the space at the left?

 

[UselessPickles]

I hadn't thought of trying to use that hole as a mounting point. Added to the list of possibilities.

 

[UselessPickles]

I got some new parts today. I already swapped out my 5V voltage regulator from the power-hungry STM L7805 to the Microchip MCP1702, and my amp draw when off/sleeping is down to 0.05 mA!!! A huge improvement compared to the 4.55 mA I was at when I first got the MCU to go to sleep.

I also received my TI TPS22810 and TPS22917 load switches today, but I still have to solder them to breakout boards before I can test them on my breadboard circuit. They are SOT-23 package. I'm not really looking forward to that soldering job. Hopefully it will be easier than soldering the BM62 Bluetooth module.

Since these load switches have very low "off" power consumption (500 nA and 10 nA), I don't expect to see a significant change in overall amp draw when my circuit is "off". It won't even register on my meter that only has a resolution of 0.01 mA.

So I think 0.05 mA should be a realistic expectation for the final "off" amp draw of my project. All of the audio circuitry that is currently missing from my breadboard circuit is irrelevant, because that will all be powered off by a load switch.

 

[Nigel Goodwin]

I got some new parts today. I already swapped out my 5V voltage regulator from the power-hungry STM L7805 to the Microchip MCP1702, and my amp draw when off/sleeping is down to 0.05 mA!!! A huge improvement compared to the 4.55 mA I was at when I first got the MCU to go to sleep.

Good aren't they

Bit annoying the pin connections are in a different order to the 78L05 though.

I also received my TI TPS22810 and TPS22917 load switches today, but I still have to solder them to breakout boards before I can test them on my breadboard circuit. They are SOT-23 package. I'm not really looking forward to that soldering job. Hopefully it will be easier than soldering the BM62 Bluetooth module.

Since these load switches have very low "off" power consumption (500 nA and 10 nA), I don't expect to see a significant change in overall amp draw when my circuit is "off". It won't even register on my meter that only has a resolution of 0.01 mA.

So I think 0.5 mA should be a realistic expectation for the final "off" amp draw of my project. All of the audio circuitry that is currently missing from my breadboard circuit is irrelevant, because that will all be powered off by a load switch.

I use a dual-FET, DMC3026LSD-13 - this is a 'reasonably sized' SM device, and along with a couple of 4.7K resistors makes a nice high level switch. I wouldn't like to go any smaller with SM

 

[UselessPickles]

After all that work I put into a customized connection between the two halves of the transceiver, grinding metal away to make clearance for connectors, etc., I think I may go a different direction now.

This connector has "JAE" stamped on it:

So I contacted JAE to see if they can identify the connectors used in the original car phone.

Good news: These were manufactured by JAE and I got part numbers:

• Male pin connector is DRA-8PC-F0
  • Crimp terminals are D02-22-22P or D02-22-26P
• Female pin socket is DRA-8SC-F0

Bad news: Both parts are obsolete.

OK news: The crimp terminals are still available.

So next step is to search around for any suppliers that still have any stock of these obsolete parts. Worst case, I can order the crimp terminals that are still available and reuse the socket and connector housing from the original car phone.

If I can't find new-old-stock of the obsolete parts, then it's a bit of a tough decision of whether my Bluetooth adapter kit should require cannibalizing parts from the original electronics, or grinding openings larger to make space for different connectors.