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

UPDATE: If you want to skip the full history of progress/discussion and just see the current state of the project, then take a look at it on GitHub: https://github.com/UselessPickles/diamondtel-m92-bluetooth

UPDATE 2: I've entered "phase 2" of this project, attempting to fit my entire project inside the original phone transceiver with its own li-ion battery power supply, instead of the first version that was an external plug-n-play adapter. Documentation of progress on this begins here: https://www.electro-tech-online.com...phone-from-the-90s.162764/page-9#post-1445391

This thread will be document my journey as I try to reverse-engineer a car phone from the 1990's and build/program a Bluetooth adapter so that the obsolete phone can communicate to my modern cell phone using the "Headset profile". I'm no expert, so I'm hoping I might get some pointers along the way too

First a quick intro about me: I'm a long-time software engineer with some very basic electronics knowledge, and a bit of experience programming microcontrollers for a few fun personal projects. I will be stumbling my way through this project a bit, but I think it's within my abilities with some patience, research, and maybe a bit of friendly guidance along the way.

And now an intro to the phone I'm working with: It's a DiamondTel Model 92 portable telephone, manufactured by Mitsubishi in the early 90's. It's a "1G" analog cell phone:




Yes, that's the original protective plastic film on the display. I recently acquired one of these phones still new-in-box! Here's a video of me peeling the film off and powering it up (I've already rebuilt a battery pack with new NiCd cells):



The phone will be installed in my 1993 Mitsubishi 3000GT VR4 for extra 90's nostalgia geek points (these are actually pictures of a previously installed not-new-in-box phone):




This particular model of phone was actually an official Mitsubishi accessory available for a couple model years of the car. The car is pre-wired from the factory for a plug-n-play install with "hands-free" controls on the steering column, and integration with the original radio (auto-mutes the radio when in a call, and sends phone audio to front right speakers). The phone automatically powers on/off with the vehicle ignition.




More details about the phone and its integration with the car can be found in this 3000GT-specific wiki article I wrote: https://www.3swiki.org/Accessory:_Cellular_Telephone


That's probably enough for an intro post. I'll start diving into more specifics of the project next...

Now for the goals of the project and the approach I'm taking.

The general goal: I want to be able to use the obsolete car phone to make/receive phone calls, of course!

Some approaches I have considered as possibilities:

1. Gut the internals of the handset and hack an off-the-shelf Bluetooth headset into it. I quickly dismissed this option because I want to preserve the original functionality and display of the phone as much as possible. I'm not taking the easy path.
2. Find a way to tap into the microphone and speaker audio signals of the handset and non-destructively wire up an off-the-shelf Bluetooth headset. The phone will still "work" as original, but the Bluetooth functionality would be completely separate and "in parallel" with original phone behavior. Can't actually dial out, and the phone won't ring for incoming calls, but I could at least use the car phone handset as a glorified speaker and microphone during calls.
3. Find a way to intercept more complex communication between the handset and transceiver and build a custom Bluetooth adapter with my own programming that interprets commands from the handset and transceiver and chooses whether to pass commands through unaltered, or translate them to/from Bluetooth handset profile commands. With this approach, I could hypothetically intercept attempts to dial out from the handset, redirect them to Bluetooth commands, then fake appropriate responses to the handset so that it believes it is now "in a call". With enough persistence in reverse-engineering and emulating, I could hypothetically support most/all of the phone's original functionality (speed dial, etc.).
4. The perfect solution: emulate an analog cellular base station that connects directly to the antenna port of the transceiver and translates between analog cellular commands and Bluetooth headset commands. This would be the ultimate in preserving ALL original functionality of the phone, but would be the most complicated solution technically. Even though I have found the official technical specs (page with overview and link to specs) for the AMPS cellular system, and even an open-source implementation that runs on a Linux computer with external FM transmitters/receivers, I think this is way beyond my skill level (RF/antenna circuits, can't find off-the-shelf FM transceiver chips that support 800MHz band + Manchester encoding, I don't know audio processing circuits, etc.).

So I have set out on a journey to attempt either option #2 or #3. Preferably option #3 if feasible. I'd like to build a device that is plug-n-play, inline between the handset and transceiver, requiring no modifications to the phone itself. But there's no way to know what's feasible until I have some understanding of what kind of communication is available for intercepting and manipulating on those wires.

So this brings me to my first hurdle: I didn't have an oscilloscope. And without having any idea whether I could get anywhere with this project, I didn't want to invest a large amount into a benchtop oscilloscope that I'll rarely have other uses for. But I also didn't want a cheap junky oscilloscope that couldn't properly identify digital communications that I may find.

After overwhelming myself with different oscilloscope options, not even really understanding what features and capabilities I will actually need, I settled on the OWON HDS272S.

Here's the review video that sealed the deal for me:



The reasoning behind this decision is that in the worst case scenario that I discover I absolutely just can't do anything useful with the signals in those phone wires (impossible to decipher, etc.), then I at least still have a nice hand-held oscilloscope and decent digital multimeter (better than any I currently have) for automotive diagnostics. The handheld form factor is way more practical for automotive use, which is the more likely use case for me. The built-in waveform generator really made it seem more economical (useful for simulating sensor signals on a vehicle to test/calibrate gauges, etc.).

Step one: try to identify what's going on with the wires between the handset and transceiver.

The phone cord has 8 wires and an RJ45 connector at the end. So I found a dual-jack RJ45 breakout board on Amazon and wired the two jacks together as a pass-through so I can connect it inline between the handset and receiver, probe the wires, and eventually wire other stuff up to it for experimenting and developing a Bluetooth adapter (picture taken after I already identified ground and voltage supply wires):



With power disconnected from the phone, I was able to easily identify the ground wire on the phone cord via continuity check against the ground pin on the DC power supply input connector to the phone. Then I was able to apply power to the phone and safely probe the other wires with a multimeter to find a power supply. What I actually found was one power supply wire for when the phone is off (~12v in standby), but when powering the phone on the voltage drops on that wire, and another wire jumps up to nearly 12v.

Then my new oscilloscope arrived!




Here's an RJ45 pinout diagram for pin number reference (relative to the RJ45 connector on the phone cable that plugs into the transceiver). Note that the wire colors are completely different on the phone.



And here's what I've identified so far:

1. Analog audio from transceiver to handset.
2. Same as pin 1, but negated.
3. Analog audio from handset microphone to transceiver.
4. Ground
5. Digital serial communication from transceiver to handset.
6. Digital serial communication from handset to transceiver.
7. ~12V power supply to handset when phone is on.
8. Power button

More details to follow...

Initial observations about pins 7 and 8 (power supply and power button).

Pin 8 is basically connected to the power button on the handset. It's an open circuit when no pressed, and closed to ground with ~40 Ohm resistance when pressed.

Here's what the oscilloscope shows when powering the phone on (Yellow is pin 8; Blue is pin 7):




Initial state while in standby mode (powered off):
Pin 8: ~12.8V.
Pin 7: ~0.45V.

When the power button is pressed, pin 8 drops to about 0.24V and the voltage on pin 7 soon begins climbing. The handset powers on soon after pin 7 reaches the top of the climb, and it seems to settle in at about 11.88V.

When the power button is released, pin 8 jumps up a bit to about 2.17V, and stays there while the phone is on.

If you release the power button before pin 7 finishes climbing (or too soon after it finishes climbing), then pin 7 drops immediately back to about 0.45V, and the power-up is aborted. Pin 8 holds low-ish (~2.17V) for a short while (~2 seconds?) before jumping back up to ~12.8V.


And now for power off:



When the power button is pressed, pin 8 again drops very low to about 0.24V, then jumps back up to the low-ish 2.17V upon release.

If you held the button long enough to trigger a power-off, then soon afterward pin 7 drops and pin 8 jumps high simultaneously, returning to the initial standby state.

Initial observations about pins 5 and 6 (digital serial communication).

Here's what the oscilloscope shows when I press one of the numeric buttons on the phone (Yellow is pin 6; Blue is pin 5):


(Note: The glitch in the blue line seems to be interference from the speaker being activated? It is not a high signal that the oscilloscope failed to capture)

Both pins seems to be carrying some variation of UART, but with the signal idling low instead of high.

The duration of a single bit seems to be ~1.25ms, for a bit rate of 800 bps (800 baud).

Pin 6 (handset -> receiver) seems to use 8-bit frames, and each button sends a single 8-bit frame when pressed, then another 8-bit frame when released. There's also messages corresponding to the handset switching between "on hook" and "off hook".

Pin 5 (receiver -> handset) seems to use 16-bit frames 8-bit frames also, and sends multi-frame messages to the handset both in response to button presses, and periodically as some kind of "heartbeat" message (maybe to keep status updated on the handset about things like signal strength, roaming, no service, and possibly even turning the backlight off after some period of inactivity).

Based on these observations, it appears that the handset is basically just a keyboard and a display. The only communication from handset -> transceiver is button presses/releases. At this point I am assuming that the handset does not maintain any substantial state or update its own display. It probably relies on the transceiver to send commands to update the display to match the state that is maintained by the transceiver (transceiver is the brains; handset is a "simple" I/O device).

This is promising. My plans to proceed with understanding these serial communications include:

• Manually record the bit pattern of every button press and release, then evaluate for patterns (I suspect I'll be able to identify which bits are the button ID, and which bit(s) is/are the up/down indicator).
  • I'll probably also invert every bit pattern too to see if they make more sense that way? I'm not sure if high signal is 1 or 0. I would assume high is 1, but this might be a completely inverted UART?
• Record bit patterns of some buttons when the handset is in different operating modes (e.g., after pressing the "function" button for alternate button functions) to confirm that the handset really is just sending button identifiers, and not doing anything more intelligent.
• Record as many examples of response messages from the transceiver as I reasonably can with the limited memory depth of my oscilloscope, so I can start trying to decipher some of the commands (hoping for things like: clear the display; push a digit to the display, pop a digit off the display, etc.).
• Get some dip switches, a button, and a microcontroller that I can program to emulate these 8-bit and 16-bit messages at the same bit rate. I would set the dip switches to the bit pattern I want to send, then press the button to send it. Then I can connect this device to one of the wires at a time, first confirm that I can reproduce known behavior with by simulating known messages, then move on to experimenting with small alterations of known transceiver -> handset messages to try to figure out what individual bits and groups of bits actually control in the messages. This was a horrible idea. A USB-UART adapter and RealTerm on a computer was the right answer (more about this later in the thread).

I'm now seeing how a benchtop scope with more memory depth, digital logic analyzer, etc., would be very helpful. But I'm going to try to work with what I have for now. I'm not prepared to spend another several hundred dollars on a good benchtop scope. I may end up needing to program a microcontroller to process the transceiver -> handset messages and stream them to a terminal on my PC.

Initial observations about pin 3 (analog audio from handset microphone).



This one is pretty simple. I talk or blow into the microphone, and waveforms appear that look like audio.

The signal seems to be centered around 4.32V with waves reaching +/- ~2.8V.

Interesting notes:

• Microphone is live/"hot" any time the handset is "off hook". It doesn't matter whether the phone believes it is in a call or not. This is good. Makes it easier for me to use the audio .
• A few seconds after putting the handset back "on hook", voltage drops from the center of the audio signal (4.32V) to about 1.66V, and stays at this "idle" voltage until taking the handset "off hook" again (immediately jumps back up to ~4.32V and captures the sound of the handset clatter).

Initial observations about pins 1 and 2 (analog audio from transceiver to handset).

This is where things get a little more complicated. Here's the waveform on both pins when pressing a button (loud beep):



Both wires carry the same analog mono audio signal, but one is negated relative to the other.

Signal is approximately centered around 0V with waves reaching about +/- 0.3V at the highest volume level.

I've already gotten some tips that this is a common approach to send the same signal over 2 wires, negated on one, such that the true signal is the voltage difference between both wires. Any interference around the wires is likely to equally interfere with both wires the same way, and therefore not affect the voltage difference between the 2 wires.

But wait! There's more!

The handset sometimes plays sound through a loudspeaker, and other times through the earpiece. These 2 wires are the source of the sound in both cases, so the handset must somehow know which speaker to send the sound to. And it's not as simple as send sound to earpiece when off hook, loudspeaker when on hook. When off hook, some sounds (call failed tone) go to the earpiece, but other sounds (button presses) still go to the loudspeaker. In this situation, the button press sound interrupts the earpiece tone sound, so sound can only go to one speaker at a time.

I think this is the culprit:




When no sound is playing at all, and the handset is on hook, there's this periodic "noise" in the lines. It looks quite deliberate, like a digital message. And notice that they are the same on both wires; not one negated from the other (unlike the audio). I suspect that this is a digital signal used to signal what "type" of sound is coming next, so the handset can send it to the correct speaker. This signal could be sent "on top of" audio to, for example, interrupted earpiece sound temporarily to play a button beep sound through the speaker.

So I think we have 2 signals on these 2 wires:

1. Analog audio = [pin 1] - [pin 2]
2. Digital signal for audio destination = [pin 1] + [pin 2]

When adding the signal from the two wires together, the analog audio will cancel itself out and leave an approximately steady 0V baseline with occasional blips of some digital message. I'm guessing a positive blip is 1 and negative blip is 0.

This will probably be the trickiest thing for me to reverse engineer the actual meaning of different signals, and also the trickiest thing for me to emulate when directing audio from a Bluetooth chip to the handset. I'm open to suggestions for how to go about both:

1. How to capture an occurrence of this digital signal "riding on top of" ongoing analog audio (e.g., how to catch the predicted signal that is suspected to cause a button press to interrupt earpiece sound; then the suspected subsequent signal when the interruption ends).
2. How to take analog audio coming out of a Bluetooth chip and split it into 2 separate signals (one of them negated), then inject these digital "spike" messages into both signals as needed.

UPDATE: The "digital signal" spikes in the audio is just noise from pin 5 (serial data from transceiver -> handset). Link to post with details.

This thread is now fully caught up to where I am with this project. I think my next steps are to capture/decode as much digital communication as I can, and start planning a test device to generate digital messages for further testing. I'll worry about audio last. I'll even start figuring out the integration with a Bluetooth chip before I worry about audio. My first major celebration will be when I can dial a number on handset and trigger the appropriate Bluetooth headset command that makes my modern cell phone actually call the specified number. Then I'll be truly motivated to figure out the audio part

If anyone has any advice for me based on what I've done so far, has any relevant expertise/knowledge that could help confirm/reject any of my current assumptions/predictions/plans, etc., please let me know!

Hi. Interesting project!

My thought on what you have so far:

Pin 8 may be the power button directly to ground, with a pullup resistor to 12V.
Try connecting a mid value resistor to ground, eg. 1K, and see if the voltage reduces by some amount? That's a safe way of testing if it is a direct power connection or not.

The audio looks interesting; I'd not be sure the common mode pulses are deliberate yet, that could be related to voltage changed as power consumption changes somewhere. Or not!

The audio routing could also be controlled by the digital data to the handset; that would be a more reliable system, to my way of thinking.

I'd try and work out how the data to the handset correlates to the display, and see if some other data does not?

rjenkinsgb I think you're right about pin 8. I was too focused on playing with my new oscilloscope and thinking in terms of voltage signals to think about it being a simple button circuit in the handset.

I confirmed that pin 8 is connected to ground with about 40 ohm resistance when the button is pressed. What I still don't understand is why voltage on pin 8 is only about 2V when the phone is on and the button is not pressed. If you have a plausible explanation for this, I'm curious to know, but it also has no impact on my ability to proceed with my project. I won't be messing with Pin 8 at all.

I will definitely be focusing on the digital communication first before digging into the audio, and I'll keep an eye out for anything that could possibly control the destination of the audio. I think I want to get to the point of successfully initiating a call from the handset via Bluetooth before I start worrying about any of the audio. For now it's enough to know that it seems doable

Original posts updated to clarify the function of pin 8.

I captured the codes for all handset inputs that are sent to the transceiver on pin 6. I can now confirm that the serial data is an inverted UART signal:

• Idle signal is low (instead of high for UART).
• 1 is low and 0 is high (opposite of UART)
• Otherwise identical to UART:
  • A start bit with a value of 0, followed by 8 data bits, then a stop bit with a value of 1 (idle signal).
  • Bits are in reverse order (least significant bit transmitted first).

When applying the these rules and manually decoding every button press, etc., it makes a lot of sense. Here's a table of all the button/action codes. Buttons 0-9 are particularly obviously correct, because the the value of the 4 least-significant bits matches the numeric value of the button, so I think that's all the evidence I need to confirm I'm interpreting the signal correctly. Table is sorted numerically so you can see the groupings and order of buttons pretty clearly:

Update: Added HEX and ASCII columns to the table after it was pointed out that many of the codes make sense as ASCII.



Handset buttons for reference:




Some interesting notes:

• There's only a single code for "releasing a button" no matter which button is released.
• The handset does some strange things with overlapping button presses. Here's a couple examples of button press/release sequences and resulting sequences of transmitted codes (in terms of button/action name from the above table):
  • Press 1, Press 2, Release 1, Release 2 -> 1, [release button], 2, [release button] (types "12" on display)
  • Press 1, Press 2, Release 2, Release 1 -> 1, [release button], 1, [release button] (types "11" on display)
  • Press CLR, Press 1, Release CLR, Release 1 -> CLR, 1, [release button], [release button]
  • Press CLR, Press 1, Release 1, Release CLR -> CLR, 1, [release button], [release button] (same as above)
    • NOTE: holding CLR while pressing numbers is probably implemented as a special case, because that's how you enter the programming menu: hold CLR and type a specific numeric code, then release CLR.
• If the handset is off-hook upon power-on, the handset nearly immediately sends the [off hook] code to the transceiver.
• If the handset is on-hook upon power-on, the handset waits about 2 seconds before sending the [on hook] code to the transceiver.

I also started trying to decode some data on pin 5 and discovered that it is using 8-bit frames just like pin 6; not 16-bit frames like I previously thought. I updated my initial post about this pins with this correction. Communication on pin 5 is much more complex (8 bytes just for writing the first pressed digit to the display), so it's going to take a while for me to manually decode enough "operations" to start comparing and identifying what various parts control. This is where a nice benchtop scope with built-in serial data decoding would be really nice.

The numbers etc. are just straight ASCII code; 0x30-0x39, with the release code being 0x04, EOT (end of text).
Up & down are colon & semicolon.

The functions 0x8n are their own codes.

If you have an MCU of some sort with a display, can you invert the serial data to it so it gets the start & stop bits, read it with the UART then invert the data content again for display?

It does look promising though!

Note, I was meaning that for the data to the handset / LCD, if it's in the same format; you can display it as hex for easy transcription.

Sparkfun made a Bluetooth adaption of a rotary dial telephone. The link is here:- https://www.sparkfun.com/products/retired/9804

That might be of use.

rjenkinsgb Thanks for pointing out the ASCII mappings. It's been quite a long time since I routinely dealt with ASCII data at a low level, so I didn't recognize it, and hadn't thought to compare to an ASCII table yet. I updated my previous post now with Hex and ASCII columns.

I will definitely be looking into (inexpensive) options to more efficiently capture that serial data, because manually decoding it on an oscilloscope is a bit tedious .
If I understand what I'm seeing correctly, I think I would only need to invert the serial data from the phone transceiver to make it valid UART, and the resulting data would be a correct interpretation (without any further invert). I don't have anything on-hand for doing this, so I'm open to suggestions. Are there any inexpensive devices that are basically configurable USB to serial adapters, and corresponding PC software for sending/receiving data? It would be amazing if I could both capture data from the transceiver, and send data from my PC to the handset to experiment without needing to solder up any circuits, program a MCU, etc.

UselessPickles said:

Are there any inexpensive devices that are basically configurable USB to serial adapters, and corresponding PC software for sending/receiving data?

Click to expand...

Yes, loads of them.

Search "USB TTL Serial" on ebay or amazon - eg.

You would need to add a gate or transistor to invert the data.

Or, try connecting directly to an RS232 port? The polarity is correct for that, by the sound of it.

Most will work for receive with 0V/5V or 0V/12V levels, as long as it is very close to 0V; a 10K to 0V may help.

Add a series 1K resistor in the RS232 transmit to the handset and 680 Ohm to ground to reduce the 12V signal to 5V levels, plus a diode to 0V (across the 680R), to prevent it going negative of ground, in case the logic cannot take that. You may have to adjust the resistor values, depending on the RS232 port drive capability and what levels the handset needs.

The only problem may be baud rate.. Not all devices can take non standard rates, though most MCUs can be programmed for just about any speed.

For software, try Realterm; you can send with that, keyboard or a file, and receive / view or capture to a file.

For viewing file content in hex (and many other things), I use ZTree:

A Picoscope (https://www.picotech.com/) will decode serial data.

A couple of years ago I had to make a LIN signal converter, that took in a LIN signal, made some changes, and transmitted the altered signal. I used a Picoscope to understand the original signal, and to check each stage of development of my converter. I didn't have any other LIN testing device or simulator.

rjenkinsgb said:

The audio looks interesting; I'd not be sure the common mode pulses are deliberate yet, that could be related to voltage changed as power consumption changes somewhere. Or not!

The audio routing could also be controlled by the digital data to the handset; that would be a more reliable system, to my way of thinking.

Click to expand...

I figured out the source of the spikes in the audio signal. It's noise from the serial data.

Yellow line is pin 8 (transceiver -> handset audio), blue line is pin 5 (transceiver -> handset data), and this is one of the periodic "heartbeat" messages (that I still haven't deciphered yet).




The audio is likely transmitted as a difference on 2 wires as a solution to this noise.

I have have also spotted a pattern of serial data when the loudspeaker "activates" and "deactivates", which may be related to routing audio properly.

Diver300 said:

Sparkfun made a Bluetooth adaption of a rotary dial telephone. The link is here:- https://www.sparkfun.com/products/retired/9804

That might be of use.

Click to expand...

Thanks. The linked info/articles seem like they might provide some options for specific Bluetooth chips. I was also looking at a chip on Sparkfun that seems to be a programmable MCU + Bluetooth chip all combined in one (link) so I could directly program all my phone behavior on the same chip, rather than have a separate MCU that communicates with a Bluetooth chip. But that option may be a bit more limiting and/or overkill? I think I will need a chip with 2 built-in UARTs so I can communicate with both the handset and the transceiver.

Diver300 said:

A Picoscope (https://www.picotech.com/) will decode serial data.

Click to expand...

Thanks for the suggestion, but I'm looking for something inexpensive and something that I can use for communication in both directions so I can send ad-hoc data to the handset/phone for testing/experimenting. It's looking like a UART/USB adapter and RealTerm is probably exactly what I need.

rjenkinsgb said:

Search "USB TTL Serial" on ebay or amazon - eg.

You would need to add a gate or transistor to invert the data.

Click to expand...

I found an article on Sparkfun about doing just that: using a transistor to invert a not-quite-UART signal just like what I'm dealing with: https://www.sparkfun.com/news/2461

That's looking like the simplest solution, and probably what I'll also need to eventually do when I start working on programming a MCU to communicate with the phone, so that I can take advantage of built-in UART support.

The part I don't understand how to deal with is this: The USB TTL Serial adapters have their own +5V and ground, and seem to be intended to provide power to the circuit that they will communicate with? But the phone that I'm going to use this with has its own power supply and ground reference. This is where my understanding of circuits and voltage falls apart:

1. Is it safe for me to connect the grounds together between the USB adapter and the ground running between the handset and transceiver?
2. If I'm using the USB adapter to just "spy on" data going between the handset and transceiver, would I just not connect the +5V from the USB adapter to anything? Only connect the ground and Rx?
3. If I'm using the USB adapter to send data to the handset or transceiver, I would obviously disconnect my passthrough wire on the appropriate pin of my RJ45 breakout board and wire it so that the Tx output of the USB adapter is the only source of signal to the phone component I want to send data to. Is it safe for me to use the +5v from the USB adapter to "drive" the signal to the phone/transceiver (using the transistor circuit to invert the Tx signal from the USB adapter). Will that properly be seen as +5V signal by the phone relative to phone's ground (because I have the USB ground and phone ground tied together)?

Potentially relevant: The phone can be powered by battery or an AC/DC "wall wart". I believe the answer to my questions may be different depending on which power supply I use for the phone?