Call Search

New to Ham Radio?
My Profile

Friends Remembered
Survey Question

DX Cluster Spots

Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement

donate to eham
   Home   Help Search  
Pages: [1]   Go Down
Author Topic: Bagphone Handset control protocol needed  (Read 3835 times)

Posts: 6

« on: April 20, 2001, 08:34:35 PM »

I need to build an interface (probably based on a PIC microcontroller) that will plug into a Motorola bag phone and pretend to be a handset being dialed.

While emergency auto-dialers are readily available for POTS (plain old telephone system), a simple cellphone interface just plain doesn't exist.

After many evenings with various search engines I did stumble on a magic box that makes a cellphone look like a phone jack, complete with 48 volt on-hook, ringing voltage, dial tone, DTMF, etc. However this thing has a price tag with too many digits to the left of the price tag, enough to pay for a really nice repeater site and a few extra goodies - for ONE unit!

I did find the pinouts and signal names for both the RJ-45 jack the handset plugs into, as well as identical signals available on the DB-25 at the end of the cellphone "brick".

There are 3 signals used to communicate between the handset and "brick": Data in, data out, and clock.

It is unknown if the data is on rising or falling edges of the clock, the maximum and minimum bit rates, any CRC or header information, or other protocol details.

Also I need to of course be able to assemble the proper bit streams to mimic button presses, and to parse bit streams from the brick to extract status information.

My guess is this is probably similar to IIC or SPI bus protocol, or even similar to reading / writing from a serial EEPROM, but I'd rather not spend months with a logic analyzer slowly picking apart the codes.

I did dig up in my research that handsets can be interchanged, but some of them support "extensions" to the basic command set, which are used for specific lines of phones.

So this implies that all of them share the core protocol, much as packetcluster and APRS use AX.25 frames, but the data output by a PIC-E hooked to a GPS will be different than a DX spot.

If I can get my hands on the basic protocol, I can then program a PIC to do the bit-banging.


Posts: 90

« Reply #1 on: April 27, 2001, 03:08:34 PM »

I don't know exactly what you are trying to do, but the hardware may just be in place already.   First, realize that not all Motorola bagphones are created equal.  there are newer and older, different firmware/sofware versions, and ones that were made under contract markets without some features in place.

There WAS  a bag/mobile phone chassis made that had a "dialtone" port--The main box looks just like any other bag/mobile, but the 8 pin connector is instead either a 4 or 6 RJ, I forgot which.  Good luck finding one.

Otherwise, some of the mobile/bagphones had an alarm feature.  I've forgotten how I was going to do this, but it seems to me some of the newer ones could be set up to dial up on an alarm feature.  Unfortunately, I have no books anymore.  If you can find a good, old, big, cooperative wireless outlet/service place that still has their old books on these, they might be able to help.  

Posts: 6

« Reply #2 on: April 29, 2001, 06:35:40 PM »

> Posted By N7JAU
> I don't know exactly what you are trying to do, but
> the hardware may just be in place already. First,
> realize that not all Motorola bagphones are

I'm specifically trying to emulate a handset with a microcontroller, to open the door to other interfacing.

As to the pinout and codes, there appears to be a "pool" of codes between handset and transciever, which different models of the bag phones use a subset of with a few that are common to all.

A good analogy would be the IBM PS/2 and AT keyboards. I have a "generic" keyboard which works fine on my E-machine, but the keyboard that came with it has a whole bunch of extra special function keys that only the E-machine understands.

However, I can plug the E-machine keyboard into the Acer, and the standard QWERTY keys work just fine, although the Acer chokes on the extended keys.

But there is a common signal protocol involving timing and bit stream contents that correspond to all of the standard characters that is shared by all PC/AT computers regardless of manufacturer.

This standard is published somewhere, to a sufficient extent that one could write code for a PIC processor to emulate a computer keyboard, enabling a Wintel box to be booted and operated with the PIC emulator plugged in, fooling the computer into thinking it is
talking to a keyboard.

There is also a standard that exists somewhere for the Motorola bag phones that defines the communication protocol between handset and transciever. There must be  "common denominator" to these serial codes because handsets can be interchanged among different models with limited functionality, at least on the service bench.

At least one outfit does make a "POTS" interface for most of the Motorola bag phones, both the AMPS only (circa 1994/95) and the PCS capable units. The problem is, this thing is 1) too expensive, and 2) requires more circuitry to deal with the POTS emulation.

Instead I'd rather directly talk to the transciever than to make a "frankenface" that first converts to phone line standards, and then pay in the high 3 digits PER UNIT to get from phone line signals to the bag phone.

By cutting out the overpriced interface, I can vastly reduce the overall complexity of the system, plus have control over the low level functions, thus speeding up overall response time and simplifying the software.

The device I have looked at would make the project a "Rube Goldberg" contraption.

I want to locate a copy of that protocol, much like I can get the protocol for the PC/AT keyboard.

At the moment it may turn out more productive to just fork over about $900 for a logic analyzer and do my own reverse engineering of the handset protocol, as examination with an oscilloscope and breakout connector suggests it is a relatively simple inter-processor protocol for both keystrokes from handset to transciever and display from transciever to handset.

Then I can build maybe a dozen interfaces for the price of ONE of "brand X" phone line emulator to transciever interface, and not be at their mercy from a supply standpoint.

The down side is that if protocol changes are discovered in later phones, I've got to hook up the logic analyzer to the new phone and figure out what they changed, and modify the PIC include files as required to accomodate it.

The whole thing really started from a need to call a list of people from a remote site when something breaks, and keep calling until someone answers and acknowledges that they are on their way to fix it.


Posts: 90

« Reply #3 on: May 02, 2001, 11:02:54 PM »

Well, I'm sure you won't find the info your'e looking for published anywhere, because Motorola, at least, is very protective and proprietory about this kind of thing.    When I was working on this stuff, a FEW of the older cellphones had pretty much full service literature available to maintain them, but the new stuff, not so.   You fix them with a sort of limited service manual, does not even have a full schematic of the device.

Not all handsets will work on all bagphones, either.

My point was hinting that, if you can find the programming info for one of the "full featured" models, (and this should still be available at some phone outlets, service centers, etc) you could probably pull this off with a pretty much stock phone.

The other thing is, these phones are real cheap at thrift stores and garage sales.   I have a COMPLETE mobile if you want it cheap.  The problem is, I no longer have any programming/setup info.  The Motorola joint I worked for went bankrupt, and I don't know where or if any of the people and tech materials went from there.
Pages: [1]   Go Up
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!