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

Just use ground and data lines, as you say.

You can drive 5V in to the handset RX line, but ideally only when that is powered. Add a resistor in series to limit the current in case of a problem.
Try 10K and you don't get good levels, 1K.

Or use eg. a 1K pullup to the handset 5V and a transistor to switch the data line low - that's actually even better, as nothing can be accidentally powered, and you need that inversion anyway, I believe.

As long as the internal grounds/0V are connected together, the power source should not matter.

UselessPickles said:

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.

Click to expand...

I found it very advantageous to have the Picoscope when the transmitter that I was programming went wrong. I could easily see where the data stream went wrong. It's also possible to get the code to drive a spare pin as the data stream is being transmitted or received, and show that pin voltage along with the waveform on the Picoscope. That can be very useful to show where in the data stream the code isn't working.

It is nice to have a transmitter that allows data streams to be transmitted, which the Picoscope won't do, but you're going to have to make a transmitter anyhow for the final project.

I ordered a USB to UART TTL serial adapter so I can start using RealTerm to spy on and generate serial data transmissions to the handset.

I selected the DSD TECH SH-U09C5 unit, which uses the FTDI FT232RL chip. I had to avoid adapters that use the Silicon Labs CP2102 chip, because that chip is more limited in baud rate support and doesn't support the 800 baud rate that the phone uses. The FTDI chip supports way more baud rate options, including 800.



I went with the DSD TECH product specifically (there are many different products using the FTDI chip) because:

• It has a nice plastic case around the circuit board.
• It provides access to many more pins of the underlying FTDI chip than the usual 4 (power, ground, Rx, Tx). Might be useful some day.
• The voltage level is configurable with a jumper. Cheaper products are hard-wired for only one voltage level.

Now I just need to deal with inverting the signal. I'm following this page's instructions on inverting a signal using a transistor and a couple resistors: https://electronicsclub.info/transistorcircuits.htm

I believe this is the circuit I need in order to "spy on" data being transmitted from the transceiver to the handset (also, I downloaded TinyCad to start playing with drawing circuits):



NOTE: Tx and Rx on the RJ45 sockets is all from the perspective of the transceiver transmitting to and receiving from the handset.

I'm less sure about the circuit for generating data from USB to the handset. Simplest option is to similarly use the USB adapter's +5V for the inverted signal like this (UPDATE: do not use this one!):




But rjenkinsgb previous comment leads me to believe that I should be using a power source from the phone for this to guarantee no voltage is applied to the handset's serial input unless the handset it powered on? There's no +5V from the phone. Only +12V (approx.)

So would I use a couple resistors as a voltage divider like this? (UPDATE: YES, use this one!)




I've already manually decoded a lot of serial data from the transceiver to the handset, and I believe I have already identified what several "commands" do. I'm excited to test the commands one-by-one via RealTerm to see if they have the expected result on the handset

That all looks good, using the last diagram with the resistors to send data to the handset.

UselessPickles said:

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.

Click to expand...

The function of interest here is a Logic Analyzer.

A quick search brought up this. I personally don't know anything about this one, but for under $10 it's pretty inexpensive.

https://www.amazon.com/Comidox-Analyzer-Device-Channel-Arduino/dp/B07KW445DJ

ChrisP58 said:

The function of interest here is a Logic Analyzer.

Click to expand...

I guess I don't know why I need a logic analyzer at this point. Will it provide substantially more value to me than using RealTerm and the USB-UART adapter to capture the serial data? I've never used either before.

UselessPickles said:

I guess I don't know why I need a logic analyzer at this point. Will it provide substantially more value to me than using RealTerm and the USB-UART adapter to capture the serial data? I've never used either before.

Click to expand...

Maybe it'll help. Maybe not.

If all of the data and commands are represented as 7 bit ASCII encoded values, then it may offer no benefit. But some of the data might be 8 bit or larger packets. I don't know how RealTerm handles such data streams.

ChrisP58 said:

I don't know how RealTerm handles such data streams.

Click to expand...

Looks like RealTerm can display incoming data in a variety of formats:



And allows typing/sending data in a variety of formats:



I was briefly excited by the "Invert" option for received data, thinking I could skip the signal inverting circuit. But that would only invert bits on a valid UART signal (idles high). The entire signal is inverted on my phone, not just the bits, so I cannot escape the need for an inverter.

All of my data is 8-bit packets/frames. It's possible that some "commands" may be multi-byte, but there is never more than 8 bits sent at a time (which I believe is UART standard?).

Here's a sample from the spreadsheet where I've been recording my manually-decoded serial data sequences from transceiver to handset



Yellow cells are printable ASCII characters. In the power-up sequence, in addition to turning on/off a bunch of indicators, it also fills the display with "8" (0011100 x14), then displays the phone's programmed phone number (currently set to all zeros: 00110000 x10). There's also the ASCII delete character (01111111) that seems to be used for clearing the alphanumeric portion of the screen.

All possible indicators on the display:




I've manually decoded data for many other actions and it appears there are 2 "modes" for writing alphanumeric text to the screen:

1. Clear display and output characters from left to right, starting on the top line and wrapping onto the second line (used during the power on sequence, and when navigating settings, adjusting volume, etc.). (UPDATE: I was wrong about this one. details in future post)
2. Push characters onto the display from the end (bottom right), shifting all existing characters left and wrapping back up onto first line (used when typing a phone number).

After getting setup with RealTerm and the USB adapter, I'll start with replicating the power-on sequence one byte at a time, which will quickly confirm/identify the commands with obviously visible consequences. I suspect I have already identified commands for enabling/disabling the loudspeaker, turning the backlight on/off, setting the LCD "viewing angle" to any of its 8 settings, and turning some of the indicators on/off.

After that, I should be left with a small number of unknown commands that are likely related to managing the alphanumeric portion of the display (setting the mode? placing cursor position?) that I should hopefully be able to figure out pretty quickly.

While waiting for my USB-UART adapter to arrive, I got started on something else important: sound!

The phone transceiver produces all of the sounds of button presses, alerts, ringing, etc., and I'll be a middle man mostly intercepting all communication between the handset and transceiver. So all the button presses I handle won't have sound unless I produce the sound myself and send that sound to the handset. I'll also need to produce my own "ringing" sound.

The first step is to identify what sounds I need to reproduce:

• Standard dialing sounds are standard DTMF (Dual Tone Multi-Frequency signaling). There's a variety of IC chips available to produce those tones, so I'm not too concerned about this.
• Other non-dialing sounds: other button beeps, power on/off sounds, ringing (alert) sound. These are the ones I have to identify.

First, I noticed that there seems to be two separate "pure" tones. I started by pressing a button that produces one of the pure tones and using an app on my phone called SPLnFFT to identify the frequency of the tone:



I then found an online tone generator website that directly plays any desired tone: https://onlinetonegenerator.com/

Entered 775 Hz, and of course it was off a bit. The phone app isn't perfect, but got me pretty close. I was able to play both the tone from the phone and the website at the same time while adjusting the frequency on the website and listening for the acoustic "beat" interference to slow down to almost nothing - much like tuning a guitar string relative to another string (demonstrated in the video later in this post).

I landed on 768 Hz for this tone.
Then repeated for a higher tone produced when turning the phone off:



This one turned out to be 1152 Hz.
Another sound produce by the phone sounded like a dual tone. The phone app confirmed it was simply a combination of of the 768 Hz and 1152 Hz tones I already separately identified:






To confirm this for sure, I found another website that allows you to generate and download a WAV file of a tone: https://www.wavtones.com/functiongenerator.php
And another website that allows you to upload and merge multiple sound files together: https://www.onlineconverter.com/merge-audio

The resulting dual tone sounded just like the dual tone sound from the phone, but cleaner (I assume the websites are able to produce more "pure" sine waves).

Next was the "ringing" sound. I'm not 100% sure what the phone should sound like when ringing (because it's impossible to get service and receive a call), but there is an adjustable "alert" volume that produces a sound during adjustment that sounds suspiciously like a 90's digital phone ring, so I'm going with it. It's a quickly pulsing/chirping sound that seemed to also be made up of the same two tones as other sounds.

I suspected it was just quickly alternating on/off the same dual tones (768 Hz and 1152 Hz). I recorded a slow motion video of the alert sound so I could listen at a slower speed and count the individual cycles. It turns out to be 20 on/off cycles per second.

Back to the previous two websites:

• Use the "burst" option with on/off times of 0.025s each to generate separate pure "burst" tones of the 2 separate frequencies here: https://www.wavtones.com/functiongenerator.php
• And merge the two "burst" tones together here: https://www.onlineconverter.com/merge-audio

Here's the final result of my re-manufactured "alert" tone, plus a demonstration of how I zeroed in on the exact frequency for each tone:


Interestingly, 768 Hz is very close to the 770 Hz used as part of standard DTMF, so I could likely use a DTMF generator chip to generate that tone (close enough), and that may even be what the phone is doing. 768 is well within the allowable +/-1.5% tolerance.

However, 1152 Hz is not one of the standard DTMF tones, so I will need to find another way to produce this tone.

How to actually produce a pure sine wave tone, merge it with another tone, and potentially even merge that with other audio (e.g., when in a call, pressing a number button needs to send the DTMF tone merged with the microphone audio)?. This is getting into stuff I understand even less about electronics (audio, impedance matching, etc.)

But what I've found so far is that I will probably try using a 555 timer to generate a square wave of the desired frequency, then a 3-stage RC network to filter it into nearly a sine wave: https://electronics.stackexchange.c...-different-types-of-tones-using-the-555-timer

One detail I haven't found explanation of is how to choose the balance between the resistor and capacitor values? I can determine total value of resistance x capacitance needed for a given frequency, but how much of that should be resistance, and how much should be capacitance? And if I'm generating 2 different tones in a similar manner, then merging them together, is there any importance in using the same resistor or capacitor values on both tone generators' RC networks?

Once I'm able to generate the desired tones, I still have more research to do on the remaining audio problems:

• Merging multiple audio sources together into one. I'm hoping a simple passive audio mixer circuit will work?
• But I'll probably have to deal with different audio sources having signals "centered" around different voltages, and having different amplitudes before mixing them. I think I've stumbled across some explanations of using op amps for adjusting both of these aspects of a signal, so I need to dig into that more.
• Getting the final output of the mixed audio to "match" what is expected at the "other end" (impedance matching? definitely need to get the voltage range to match expectations).
  • I need to figure this out for sending audio to the handset (need to split audio into 2 separate and opposite signals, which I believe can also be done with op amps somehow).
  • Also need to figure this out for sending voice and dialing beeps to the mic input of whatever Bluetooth chip I decide to use. I hope this will be simpler because I won't need to generate a differential signal.
• I also need to manage user-adjustable volume control for all sounds to the handset. The volume of sound on the handset is proportional to the peak-to-peak voltage of the audio signal it receives. I've already found that there are digital logarithmic potentiometer IC chips available, so I suspect I'll be using one of those so that I can replicate original functionality of user-adjustable volume being adjusted with the up/down arrows on the handset in steps, and stored in memory that persists with power off/on cycles (EEPROM on whatever MCU I choose?). I need to find a digital potentiometer that supports directly setting it to a desired level. One I glanced at so far seemed to only support incrementing/decrementing its current position.

I'm just getting started on trying to research and understand this type of audio circuitry, so I would appreciate any pointers to get me moving in the right direction.

My goal is to first drive a small speaker with my sounds before worrying about sending the sound to the handset correctly.

I designed a "telephone tones" unit for a company a few decades ago.

That was an oscillator and divider chain with gates to combine or pulse the audio tones using outputs from the lower frequency stages of the divider. It emulated the UK telephone signal tones at the time - no DTMF back then.

If you use an MCU with a decent amount of memory for the controller you would be able to create the tones directly with that.

Microchip even supply a software library for DTMF generation; it also has other stuff you can ignore:

The demo code for this board appears to have the tone files in it:

Success!








I ordered an electronics starter kit on Amazon to get a breadboard and a variety of wires, resistors, transistors, etc., so I could set up the UART signal inverters. I manually tested at a few points along the way with my oscilloscope to confirm proper voltage levels before finally connecting everything together. A couple resistors in series were necessary to get one of the values I needed for a voltage divider, and I tweaked the value a bit from the original circuit diagram because the power supply voltage to the handset was 10.8V instead of 12V for some reason when using the AC adapter for the phone.

I also made a small change after these photos so I could easily move a wire to quickly switch between allowing data to pass through from transceiver -> handset, or allow me to send data to the handset via RealTerm. This was useful for allowing me to get the phone into a specific valid state, then experiment with commands from there. A real switch would have been better, but I didn't have one .

I have successfully deciphered all commands I have seen the transceiver send to the handset, except for one command during the startup sequence that does nothing as far as I can tell. I also discovered many commands on my own that I've never seen the transceiver use.

I'll write up a summary of handset commands as a separate post.

This post will explain everything I've figured out about controlling the handset via serial data commands (on pin 5 of the RJ45 cord, inverted UART at 800 baud). Refer to this Google Docs spreadsheet for a complete list/description of all commands (second sheet/tab named "Transceiver -> Handset").

All commands will be referenced in this post by their numeric hexadecimal value.

The handset is dumb and will not do anything on its own in response to any button presses, and it knows nothing about the current "state" of the phone. It must be explicitly told to do everything. This is actually a good thing for me, because I want complete control of the handset.

Display Layout​

There are two main portions of the display: text and status indicators.

The status indicators are pretty straightforward: they can each be on or off. The 6 bars in the top right of the display are the signal strength indicator, and each bar can be individually controlled. Also interesting is that the "NO SVC" indicator is actually two separately controllable indicators ("NO" and "SVC"), even though they are always used together as a single indicator.

The text portion of the display is 2 rows of 7 characters. Each character is 5x7 pixels. Some commands can individually address each character position. The above photo shows the hexadecimal index of each position. The end of the bottom row is the starting point (index 0), increasing index to the left, then wrapping to the top row.

Backlight​

Both the LCD screen and the buttons have backlighting. All backlighting is turned on/off together with the following commands:

• On: AC
• Off: AD

Status Indicators​

All of the status indicators can be individually turned on and off. There are also commands to turn ALL indicators on/off together.



The signal strength indicator can also be set more conveniently in terms of a strength value from 0-6 (number of bars to display) using commands E0-E6. These commands appropriately turn all the signal strength indicators on/off to show the correct number of bars.

LCD Display Angle​

The "display angle" of the text portion of the display is adjustable for optimal contrast depending on whether you are looking at the display with it facing directly toward you, or if the display is tilted more "up"/"away" from you. There are 8 possible angles, presented to the user as angles 1-8, where 8 is best for looking directly at the display, and lower values are better as you tilt the display further "up"/"away".

Commands for setting the display angle are C8-CF, but the order of angles is opposite of what is presented to the user. The raw numeric angle ranges from 0-7:

• [numeric angle] = 8 - [angle displayed to user]
• [angle displayed to user] = 8 - [numeric angle]
• Command to set angle = C8 + [numeric angle]

Clear/Fill Text Display​

The normal method of clearing the text display is to send the ASCII "DEL" character (7F).

There is also a pair of commands for turning all pixels of the text display area on/off:

• All pixels on: BA
• All pixels off: BB

It's unclear whether there is any practical difference between using 7F and BB for clearing text, but 7F should probably be generally preferred because that's what the transceiver always uses.

Printing Text ("normal" printing)​

Any "printable" character that is sent to the handset will be printed to the text display at the end of the second row (index 0), pushing all previously printed characters to the left (to a higher index), wrapping up onto the second row. If you print more than 14 characters to the display, then the first printed characters will be "pushed off" the beginning of the top row.

Printable characters include:

• All standard ASCII printable characters (20-7E), but with the following deviations:
  • \ (5C) prints as ¥ (yen symbol)
  • ` (60) prints as α (Greek alpha)
  • ~ (7E) prints as → (right arrow)
• Special symbols (C0-C7):
  • C0: Small up arrow (outline)
  • C1: Small down arrow (outline)
  • C2: Small up arrow (filled)
  • C3: Small down arrow (filled)
  • C4: Large up arrow (filled)
  • C5: Large down arrow (filled)
  • C6: Solid rectangle
  • C7: Horizontal striped rectangle

Special printable characters (C0-C7):

Printing a Character to a Specific Location​

The commands 01-0E will cause the next printable character to be printed at a specific index of the text display.

Command: 01 + [index]

For example, the command sequence 08 33 will cause an exclamation point to be printed at the end of the top row.

If that index lands within a section of text that was printed the "normal" way, then it replaces the previous character at that index and will continue to behave as normal printed text (will be pushed left along with surrounding characters as more text is printed "normally").

If that index lands beyond where "normal printing" has reached, then the precisely positioned character will remain at its specified index as more text is printed normally, until the normally printed text reaches the precisely positioned character. The precisely positioned character is then overwritten by the normally printed text.

Enable/Disable Text Display​

The text portion of the display can be turned on/off. This can be useful if you need to print several characters to the display at once, and you don't want the user to see the display update with each new character: disable the text display, print all character, then enable the text display, so the user will see only one update. It is also overall quicker to write many characters while the text display is disabled.

• Text display on: B6
• Text display off: B7

NOTE: While the text display is off, there is nothing displayed in the text area (not even the text that was previously displayed), so the user may still notice a flicker of empty display between the old text and new text.

Blinking Text​

A blinking option can be enabled that causes the entire text display to continuously blink on/off.

• Blinking on: B8
• Blinking off: B9

Note: The text display cannot be disabled while blinking is enabled. The blinking behavior will automatically re-enable the text display.

Blinking Cursor​

Warning: This is a bit buggy/awkward, but could be used with care and workarounds.

A blinking cursor can be positioned at any index of the text display using commands D0-DD (D0 + [index]).
The blinking cursor alternates between a solid rectangle and whatever character is currently printed at the same index.

Any of the following will remove/disable the blinking cursor:

• Command DE (seems to be explicit command for disabling the cursor).
• Printing any character to the screen in any way.
• Clearing the text display.
• Disabling the text display.

Bug #1: After flashing cursor position is set higher than 6 (D7-DD), positioning of the blinking cursor seems to become corrupted in very strange ways until a character is printed to the display. You can initially reliably position/reposition the cursor anywhere in the 0-6 index range as much as you want, but you can only reliably position the cursor in the 7-D range once. And afterward it is also impossible to position the blinking cursor in the 0-6 range without printing a character to the display first.

Bug #2: If no text has been printed to the display yet since the last clearing of text, then the cursor cannot be placed at indexes 0-6. The cursor can be placed at indexes 7-D in this situation, but then Bug #1 applies, and there's still no way to move the cursor into any index 0-6.

Audio Control​

The ear speaker, loud speaker, and microphone can all be individually turned on/off. There is also a "master" audio enable/disable that must be on in order for any of the individual items to actually be enabled.

The on/off status of each individual item is retained while the master audio enable is off.

Note: There is only one source of analog audio going into the handset. These audio controls must be used to control which speaker the audio is sent to.

Initial Conditions​

When the handset initially powers on, it has the following initial conditions:

• Backlight is off.
• All status indicators are off.
• Text display is clear.
• Text display is enabled (any printed characters will appear immediately).
• Display angle numeric value is 0 (what is normally presented to the user as angle 8).
• Blinking text is disabled.
• Blinking cursor is disabled.
• All audio is off.

Observed Patterns​

Here's some patterns I observed about how the original transceiver sends commands to the handset:

• When connected to an external power supply, the backlight and master audio remain on continuously.
• When running on battery power, the backlight and master audio turn on with each button press, then remain on for 10 seconds after the last button press.
  • Assumed to be a compromise between reduced power consumption and instant/clear response for audio. A quick button press will often fail to beep if the master audio is being switched on at the same time, and enabling master audio can produce a "pop" sound.
  • The backlight and master audio remain on the entire time the handset is off-hook, even when on battery power.
• There's a lot of simplicity/laziness in how commands are crafted. For example, every button press causes the commands to turn the backlight and master audio on, turn the ear speaker and microphone off, and turn the loudspeaker on, even if everything is already in that state.
• When the user is typing a number, each new digit is simply printed to the display, allowing the normal printing behavior to push previously typed digits to the left.
• When the user uses the CLR button to "backspace" (delete the last digit), the entire text display is cleared (7F) and all digits are re-printed to the display, except for the last digit that was deleted.

Nice work - but poor 'grammar'

I 'has' control

Nigel Goodwin said:

Nice work - but poor 'grammar'

I 'has' control

Click to expand...

I learned from the best:

Progress is going to be slow for a while as I research and select components, but here's some updates on what I think I'll be using.

• Microchip BM62 for the Bluetooth Hands-Free Profile implementation. There's an overwhelming amount of documentation and example code to digest, but I think I understand it well enough to know it will meet my needs. After some pre-configuration with a mix of provided tools, I will be able to communicate with the Bluetooth module via UART to perform all the hands-free operations and be alerted to "events" from the paired phone, etc. There's quite a bit of potential for me to make use of:
  • Get the paired cell phone's service status, roaming status, and signal strength to display it on the car phone handset.
  • Get caller ID info for incoming calls to display on the car phone handset.
  • Get contact info (names and phone numbers) from the paired cell phone. I could re-implement the car phone's original "find contact by name" functionality, but in terms of contacts from the paired cell phone.
• This breadboard adapter for the BM62, although I'm getting concerned that I ordered it several days ago and messaged the seller, but have not heard anything yet.
• A few pieces of the puzzle for generating the differential audio signal for the handset:
  • TL7660 for generating a negative voltage reference.
  • LT6350 for generating a differential signal from a "single-ended" signal.
  • Some black magic involving a rail-to-rail op amp to level-shift the original audio signal to be "centered" around 0V (ranging from - to + voltage) before feeding it into the LT6350.

I like rjenkinsgb suggestion to generate the tones I need for button presses in software on the MCU. If I consistently generate all tones (DTMF tones, and non-DTMF beeps, ringing, etc.) on the MCU, then I only have one source of tones to worry about processing/mixing. The DTMF library from Microchip is overkill for my needs, plus it may not be able to generate the "other" tones I need, so I'll definitely be looking into a stripped down solution, even if I need to implement it myself. It shouldn't be too hard to generate hardcoded arrays of sine waveforms at a predetermined sample rate that I loop through to set the value of a DAC output of the MCU at the same rate via a timer.

I'll need to come up with a solid plan for exactly how to implement that tone generation to determine memory requirements, etc., before I can select a MCU. But in the meantime, I think I will get started developing some basic behavior of the phone (minus sounds and Bluetooth integration) using a random spare PIC16 MCU I have from a previous project.

The general plan now is to basically re-implement all phone behavior from scratch, using the original car phone's behavior/features as inspiration. I'll mimic exact original behavior as much as makes sense, but I think I have to give up on the idea of a "hybrid" implementation where I allow some original car phone functionality to "pass through" (e.g., original phone book / contacts implementation) while also integrating it with Bluetooth. Life will be much easier if I just maintain all state of the phone myself rather than trying to keep a separate "copy" of the original phone's state in sync with actual state of the original phone based purely on interpreting handset display update commands from the transceiver. One reasonable exception would be detecting low battery warning and battery voltage info from the original transceiver, but otherwise I would ignore all communications from the transceiver and basically only use the transceiver as a power source (and its power on/off functionality).

Here's a completely unrelated photo of some silly output on the handset display:

Can anyone point me in the right direction for what circuitry (simplest approach) I need between the DAC output of a MCU (0-5V, but definitely not enough current to drive a speaker) and a simple 8ohm 1W speaker? I'd like to experiment with generating tones on an MCU, using its built-in 5-bit DAC.

In my searching, I keep finding what examples that appear to be overcomplicated for my purpose of generating a few pure tones and dual tones. I don't need great audio quality. I also found a common audio power amplifier (LM386), but it's for use with low-voltage inputs in the -0.4V - 0.4V range.

The DAC on the microchip I'm experimenting with does allow for using different +/- voltage references that are independent of the voltage supply and ground for the MCU itself, so I could use a simple voltage divider to constrain the voltage range of the output, and I suppose use the TL7660 to generate a negative voltage reference if I need to get the output into the -0.4 - 0.4 range for use with the LM386, then follow some examples of how to properly use the LM386 to drive a speaker. But is there a simpler way to do this?

The LM396 uses a ground referenced input, so all you need is a resistive divider, probably with a small cap to ground to reduce the sample frequency passthrough, and a series coupling cap to the amp input, with eg. 10K to ground from that to minimise output offsets.

Or use a 1K volume pot / preset resistor, directly coupled to the LM386 input, and a series resistor and coupling cap feeding that, eg. 10K and 10uF or 47uF.
Add a 10nF across the pot for some HF filtering, then adjust as needed.

You could split the upper half of the divider and add a cap to ground there as well for a bit more filtering, if you wish.

rjenkinsgb So I'm basically aiming to divide voltage of the DAC output so output is in the 0-0.4V range (or less for lower volume, either via adjustment to R values or manually adjustable volume pot) before feeding it into the LM386?

As for the filtering, my maximum "signal" frequency is 1477Hz, and my sampling rate will be probably 8kHz or 10kHz. For a starting point of choosing R and C values for the RC network, what cutoff frequency should I be aiming for? My thought is something well below my sample rate, but above 1477Hz by a safe margin. Maybe a cutoff around 3kHz?

Edit: Btw - I'm aware that there's more to designing proper filters than simply picking a cutoff frequency, analysis can be done by calculating attenuation vs frequency plots, etc., but I'm not looking for perfection here. Even the tones generated by the original phone are not very "pure". I'm just looking to get "in the ballpark" to start, then experiment with adjusting values and adding stages as I desire.