Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

AudioVox Bag Phone — Bluetooth capable Project

apexsilvergsr

New Member
Hello, I’m new to the forum and to start off, and I’m an electrician with not a whole ton of experience with the nitty gritty electrical components that I will be working with.
FB237360-B487-4180-9F5F-B2C8478D5524.jpeg


This is my newly acquired AudioVox bag phone. Model BC-65 TRAN series.

Let me begin with this, I saw a similar post by UselessPickles who has put a lot of effort into making his 3000GT a real time piece, and I really appreciate seeing the effort he put into making his factory DiamondTel handset into a fully functional piece, which to me adds just that piece of authenticity you will probably see once in a lifetime. I started getting into old phone tech recently, but have been a long-time car enthusiast and would totally love to have a functioning car phone.

I purchased this handset because my ‘85 Mercedes has the same model Bell-Atlantic phone still installed and working (not the making calls part). It would be easier to figure out one phone so I can copy what I have figured out to the other phone.

I added a few pics to help understand.

So far, I’m at the stage where I have the bluetooth module that UselessPickles has got, along with the RJ45 breakout. I have identified the power/ground and now attempting to see any similarities between the DiamondTel handset and the AudioVox.

Any pointers would be appreciated, maybe any good pieces to decode serial data between the transceiver and handset, I believe the oscilloscope I ordered isn’t too good. I will try the USB RS232 sniffer and the corresponding software to see if I run into any solutions.

‘85 Mercedes 500SEL. 4 heated seats, the rear seats recline aswell!

My daily driven 1982 AMC Eagle wagon, modernized with fuel injection and electronic ignition system. Also, the destination for my bag phone to reside.
 
I just now saw this thread. Subscribed and hoping to see you make progress on this :)

I'll try to offer some pointers, but most of it is already documented in my thread about how I reverse engineered the communication.

I started by probing each wire with an oscilloscope, and observing.

If there are simple analog audio signals for speaker and microphone, those should be very easy to identify: try doing something on the phone that produces sound, and talking into the microphone, while watching the oscilloscope (of course you'll have to play with the setup of the scope to make sure you are able to see anything that happens). If you see analog waveforms that correspond with the sound, then you've got something.

For digital communications, you first have to figure out what type of communication is used. I got lucky that my phone used very simple UART communication (one wire for TX, one wire for RX; clearly distinct individual bytes of data; can't get any simpler than that!). I know some phones (Motorola?) use some kind of proprietary 3-wire serial data communication.

Once you determine the digital communication type, then you have the big puzzle of figuring out what the data actually means. Again, I got lucky that my handset sends simple 1-byte messages for button presses, etc., which was very easy to capture and identify.

For the transceiver -> handset communication, I just recorded the data sent while performing various operations on the phone, and started looking for patterns of how the data related to what was happening on the handset display.

A UART-USB adapter and RealTerm software was an amazing tool that allowed me to both capture sequences of serial data, and produce sequences of serial data sent to the handset (often one byte at a time) to really see exactly how the handset reacted to each byte of data "in slow motion". Again, I got lucky that the protocol was very simple: nearly all commands to the handset are single-byte commands. And ASCII characters for printing text were very obvious.

Good luck!
 

Latest threads

New Articles From Microcontroller Tips

Top