PC-mobile serial interface
by
L. Padilla
Foreword
I have owned several mobiles and since the first one I was curious about
getting it connected to PC but I had not enough information. I was not
seriously interested until I owned a Siemens MC 60 because it does
have the capability to connect to computer as it is stated in the manual. For
that purpose Siemens freely provide
software (Siemens
Data Suite) and they have cable
accessories (serial and USB) you can buy to link the mobile to PC.
The original cable seemed to me a little bit expensive given the expected
utilization I foresaw (though there are much cheaper clone cables you can buy
in many places). Also I am the kind of person who likes to do by myself as much
as I can, so given both reasons I tried to make my own cable. First, of course,
I had a look in Internet to see if someone had already published a design. I
found a circuit and
some variants based on the MAX232 or MAX3232 integrated circuits. This scheme
looks rather simple and cheap, however I thought I might design something even
simpler and cheaper.
In this article I present a PC-mobile interface using serial port which I
believe the simplest possible while being reliable and safe. It only consists
of two normal transistors, one normal diode (optional, included for better
mobile protection) and three resistors. This circuit was specifically designed
for the Siemens MC60 however it will surely work with most of the Siemens
family (I tested it works with the Siemens
M 55 too) as well as very likely with most of other manufacturers: Nokia,
Motorola, Ericsson, Alcatel, etc. Note that this design is highly
experimental and it makes use of some tricks thus having some non standard
behavior. Therefore use it at your own risk and don't blame me if something
gets damaged (though I consider it unlike).
In order to use this design with other mobiles you just need to find out
where the FBUS TX,
RX and GND lines lie within your mobile's interface to know how to wire it (see
some pin outs here and also
here). I consider the circuit safe enough so that you can then connect it
without much risk and see whether it works. If it does not then it is up to you
to find out the reason. Note that this interface is fine tuned specifically for
the Siemens MC60 so that we can keep it extremely simple. If other mobiles
differ significantly in their electrical behavior of the FBUS (most likely
input and output impedances) then some modifications in the resistors values
may be required in order to make the PC-mobile connection work. If you have
some knowledge of basic electronics you can find yourself the required
modifications because the interface is exhaustively explained step by step in
the rest of this article.
Siemens MC60 interface
Before you even think about connecting your mobile to a PC you first need
to know the mobile IO capabilities. If it has IrDA or Bluetooth then things are
much more easier because no cables are needed, but if the mobile (or the PC)
has not such features you will need a cable which at least must adapt different
connector types. If the mobile has USB lines the cable will be very simple, no
electronics will be needed, just a pin by pin connection with your PC's USB
interface in which getting the mobile connector is the more difficult step.
However the most common IO capability is the serial line, though it is not
in the form of the well known RS-232-C standard of the PC
serial port but in the form of what is called FBUS,
which is similar to TTL (as in PC parallel port)
but with a logic one of about +2.9 volts instead of +5 v. The logic zero is 0
volts as in TTL. The protocol is the classic serial with start bit, data bits,
parity bit (if any) and stop bit(s). Three pins are involved, one for
transmitting (TX), one for receiving (RX) and ground (GND) which is the common
reference.
Once you decided to go on with the serial cable then look for your mobile's
pinout, at least for the location of the TX, RX and GND lines. Here you can
find some of the most common mobile
pinouts and also here,
be aware however that the pin out may have changed even if the connector
is the same. This happens with the Siemens pin out in the latter link, which is
the one used in older models, in newer models such as the MC60 the pin out is
different and can be found here.
In my case, the MC60 (also valid for the M55), the pin out of the concerned
lines is:
- Pin 2 => GND
- Pin 3 => TX
- Pin 4 => RX
where pin 1 is the leftmost pin when you are facing the connector with the
mobile's keyboard upwards. Note that this pin-out is different from former
Siemens models, it is easy to distinguish both just by measuring the voltage of
the power supply. It uses pins 1 and 2 in both cases but with reversed
polarity, in the older pinout GND is pin 1 while in the newer pinout GND is pin
2, of course GND is the pin which have negative voltage compared with the other
pin.
The circuit
In principle there is a chance to connect the mobile FBUS directly to the
PC RS232 port and get a working link between both. However a few problems arise
if you try this. On one hand it might be risky to connect a -25/+25 volts
signal (but usually it is about -12/+12) into a device designed for 0/+5 volts
input, but this is not the problem because input and output impedances are
usually high and therefore currents are low enough to be safe. The main problem
is that you may shift the voltage working point of different components and
this may lead to an unpredictable behavior (which ceases when you retire the
disturbing voltage). This problem can be solved with a couple of resistors and
one diode.
On the other hand mobiles are very current conservative due to their
battery powered nature, this is noticed in the high output impedance of the TX
line. Output current is so limited that the mobile TX line is unable to drive
the RX input of the PC serial port. This problem can be solved with an external
power supply and one transistor.
Nevertheless there is another problem which complicates things a bit more:
FBUS uses direct logic while RS232C uses inverse logic (not in the control
lines). This means that FBUS represents a logic one setting TX output voltage
in high state (+2.9v) while RS232C codes it with low state (-12v). A logic zero
is showed by FBUS with low state (0v) while it is high state (+12v) in RS232C
TX output. This problem must be solved using some active electronics: an
external power supply and one transistor per line at least.
The figure above shows the circuit of the adapter to interface the mobile
with a PC via serial port. You can see it is the simplest solution required to
solve the problems mentioned above. It must be powered with +12v and the best
choice is to take it from one of the two output control lines of the PC serial
port, RTS or DTR. Choose the one that the data exchange software will keep at
+12v all the time (or any if both), in case of the Siemens Data Suite the only
line kept high all the time is RTS. It is almost guaranteed that at lest one of
the two output control lines will be kept up by standard software because the
original data cable must be powered as well.
Resistors R2 and R3 are a voltage divider which adapts the RS232C high
state voltage to the FBUS level, therefore it must be tuned so that the circuit
output for RX of the mobile matches the same voltage as TX of the mobile,
usually around +2.9v. You can do this by using a three leg variable resistor,
which will account for both, R2 and R3. Adjust the variable resistor in two
steps, first without the mobile connected to set a safe level before
connecting, then attach the mobile and fine tune the voltage. Once you are done
setting the level you can measure the resistance of both halves of the variable
resistor (from one end to the cursor and from the cursor to the other end) and
now you can replace it with two equivalent normal resistors which are usually
cheaper and smaller (this might be important to fit the circuit within the box
of the PC serial connector). Actually the output voltage for mobile RX is not
so critical and you can leave it a bit above or below +2.9v, say plus/minus 1v
and therefore you can use the suggested resistor values without any tuning,
just check for safety that the level is acceptable.
The purpose of resistors R1 and R2 is to pull up to high level by default
RX of mobile and PC (note they have different voltages due to R3) when
transistors are closed. When they are open, resistors limit the current and
drop voltage forcing low state of both RX inputs by grounding them (we
acknowledge this is not standard for PC but it works, see next paragraph).
Transistor Q1 is responsible for driving PC RX high when mobile TX is low
and leaving it low when mobile TX is high. Note the inversion of states
required due to the different logic of both ports we commented above. Also note
that we are relaying in a feature of the PC RS232C out of the standard: an open
or grounded input is considered by the UART low state, as if an input of -12v
was driven. This is the only non standard behavior I had to use in this circuit
in order to keep it so simple. All UARTs I have tested behave like that and I
had no problems relaying on that feature.
One might avoid that situation by connecting Q1's emitter to -12v instead
of to ground, but this will introduce the additional requirement of having a
-12v power supply, which we might take from the control line not used to
provide +12v. That is, if we want to avoid an external power supply we will
require that the data exchange software will keep RTS and DTR at +12v and -12v
(or vice-versa) permanently. In case of the Siemens Data Suite it is exactly
like this, maybe Siemens original cable uses this double powering. I traded
simplicity for standard feature and chose a simpler non standard circuit that
works. If you prefer to choose the other option (complexity for standard
behavior) now you know what modification is required to the circuit.
Transistor Q2 is in charge of driving mobile RX up when PC TX goes down and
leaving it low when PC TX is high, note again the inversion of states. Diode D1
has the purpose of protecting the mobile if the power source of the circuit
goes below zero. This happens any time you reboot your computer if you power
the interface with a control line, because the default state of the RS232C
output lines is -12v. If you are so cautious not to connect the mobile to PC
before the software is run or after it has exited then D1 is not strictly
needed.
Laptops (troubleshooting)
This interface was designed and tested using a normal clone PC, and though
there is no reason why it shouldn't work with other computers, I found a couple
of problems when used with laptops. The first one is that mobile computers
seem to use less than 12v in their RS232C ports, very likely due to power
saving; I've seen 9v and even 6v. There is nothing wrong with this as long as
you take it into account when you choose the R2/R3 ratio, 9v would require a
ratio of 2 and 6v a ratio of 1. If you take this ratio equal to 3 (for the more
used RS232C level of 12v) as suggested in the scheme above, then you might find
that the interface does not work with your laptop even when it does work with
other PCs.
If you plan to use the circuit with computers that use very different
RS232C levels, then you have several options. You might have one interface for
each computer, this is feasible because the circuit is cheap and easy to do,
however this does not look like the best solution. Another option is to include
a variable resistor or a switch to select appropriate R2/R3 values given each
computer. Again this solution isn't very clean, I prefer to make just one
interface with a fixed R2/R3 ratio, but set halfway between the values required
by the two computers with more different RS232C levels. This way the input line
of the mobile device will receive less or more voltage than standard when
connected to one or another computer. There shouldn't be problem with this as
there is tolerance with the input voltage. For example, if you want this
circuit to work with 6v and 12v RS232C PC ports, you might choose R2/R3 = 2,
then the mobile RX line will receive 2v and 4v respectively, which is 1v below
and above the standard 3v level. While I think there is no risk feeding the RX
line with 4v or even more, I consider 2v somewhat low to work reliably with any
mobile, so actually I would choose a smaller ratio, 1.7 for example.
The second problem I found using the interface with laptops, is that
sometimes more current is needed to drive their RS232C ports. To fix this is
enough to choose a smaller value of R1, for example half the value suggested in
the scheme above, that is, to use 5k instead of 10k.
The cable
There is no special requisites about the cable, signals are strong, low
current and not too high frequency. For my first interface I used a one meter
long thin cable with two twisted pairs, that is, four cables, thought only
three are strictly needed, two cables (one for each twisted pair) are connected
to ground. In my second interface I used an old mouse cable which has the
advantage of already having the PC serial connector (it seems mice use at least
TX, RX, RTS and GND which is what we need), however I cut it away because this
kind of factory made connectors cannot be opened to place the electronics
inside.
The circuit can be arranged within the box of the DB-9S or DB-25S PC serial
connector without a PCB, soldering components directly to the pins of the
connector and to neighbor components; some short cables may help but I did not
need to use any. Note that the circuit can be powered there using a control
line of the serial port.
The major problem of this project was the mobile connector. Silly but true.
I started using the connector of a handsfree cable but it was a real headache.
Pins are very small and close one to each other so I had lots of problems
soldering cables with my soldering iron which is not sharp enough. Once I had
cables soldered they broke often because they have to be very thin to be
soldered to one pin and not to touch adjacent pins. Really painful.
One option brought to my attention by a friend who used his imagination
(you should do the same :) when making his personal interface (likely the first
person trying this circuit right after me), is to use the connector of the
charger, which can be opened without damage to insert the three cables needed
for proper connection. Here you have the
illustrated process of making the interface, courtesy of this friend and
his digital camera ;-).
Maybe if you are lucky you'll find a mobile connector well suited for this
project but if you don't or if you like to do everything by yourself (like me)
there is an alternate option: build your own connector. The following
instructions are only valid for Siemens mobiles and those with a similar type
of connector, for other types just use your imagination.
Cut a piece of thick paper or thin cartoon the size of the mobile connector
wide and about four centimeters long. Bend it by half so you get a V shape 2 cm
long which will fit into the mobile connector. Insert the paper with the vertex
toward the mobile and mark with a pen the position of pins 2, 3 and 4 (this is
for Siemens models with the same pin out as the MC60, for some older models you
have to mark other pin positions), pins can not be seen when the paper is
inserted but you can see the beginning of the tracks where they are attached.
Then extract the paper and do a couple of holes per pin with a needle. One
hole must be a couple of millimeters ahead your mark (toward vertex) where you
expect the contact of the corresponding pin of the connector will begin. The
other hole must be done a couple of millimeters before the vertex where you
expect the contact of the corresponding pin of the connector will end.
Now take a very thin copper wire (one of the several hair sized wires that
runs within common low current electric wires), pass it through one hole from
inside the V toward the exterior and then pass it again through the other hole
of the same pin from the exterior toward the inner part of the V. Do this step
for the three pins so that you will get three little copper lines running
parallel which will touch the corresponding pin contacts of the mobile
connector. You've got the idea, uh?
Inside the V you will have three pairs of copper wires, twist each pair so
that you end with only three copper wires, one for each pin. Twist tight to
avoid that cables remain too loose, especially in the side that will make
contact with the mobile connector. To facilitate the soldering of these thin
copper wires with the normal cable wires make another three holes with the
needle half a centimeter before the outer end of the paper connector but as
much separated one to each other as possible. Now pass the copper wires through
each corresponding hole from inside the V toward the exterior. This will help
to solder the external cable preventing that copper wires touch each other
inside or outside the V (though there are other methods like using adhesive
tape to isolate them or using copper cables from a transformer which are
already isolated, but in this case you have to remove the isolation in the part
of the cables that will make contact with the mobile pins).
It only remains to solder the external cables to the connector cables and
fix the connector with adhesive tape so it gets firm, stable and cables do not
move. Before fixing the connector with tape it is convenient to fill the V with
another V identical to the other (but without holes or cables, of course) so
that the connector fits tight into the mobile socket and it is not left too
loose. This will add pressure to prevent accidental extraction of the connector
and to force the connection between the connector and the mobile contacts.
After the problems I had with the original connector I made this one and it
worked at first try. Now is my preferred connector. Here you have a couple of
images (outer and inner views) of the connector so you get an impression. By
the way, pictures were taken with the MC60 integrated camera, you can see it is
not very good for close ups (it isn't good for long distance images as well,
best performance is achieved with photos of people, that is, mid range).
The software
That's a key point, without it the PC-mobile cable is useless. Some
manufacturers provide custom software specific for their mobiles like Siemens
Data Suite, Nokia Data Suite, etc. I don't know how similar are the
protocols, commands, etc. of different manufacturers or even if is there any
standard, maybe they share some basic operations like SMS handling, etc. so
that you can use the same software with different mobiles. It is for example
curious that many anonymous SIM-lock removers and other utilities may be found
in a lot of GSM dedicated sites. Where does people get the knowledge of the
protocol and commands if it is not published anywhere? This seems to be a
matter of research and experimentation, it's up to you!
The software for firmware update provided by Siemens also works (I updated
my MC60 with it) but it seems that unlockers, loggers, etc. do not work with
this interface because it is a data cable and not an
unlock cable which is different but I don't know the difference yet,
please tell me if you know it! It seems that external powering is required in
order to boot the phone with custom software, here is a hint of how an unlock
cable might look. Another possibility seems to be the use of the auto
ignition feature like in this circuit.
If any of these is the case then my circuit might also be used for an unlock
cable provided you add the external power supply and the short circuit with the
other lines or the auto ignition connection, depending on the case.
Another software that works with this interface is the Windows
HyperTerminal because it raises RTS, I tested it on Windows 98 and Windows XP.
Using this program you can type an AT command and you get the OK answer from
the MC60 internal modem! The mobile works with any PC COM speed, so set it for
115200 bauds, 8 data bits, no parity and 1 stop bit and you will reach the top
speed. By the way, the Siemens GPRS software does not work with this interface,
it does not detect the mobile. As long as, by now, I'm not interested in GPRS
connectivity, I haven't investigated the reason. It might be due to that it
uses hardware handshake and needs other lines apart from TX and RX (the MC60
seems to have several such additional serial lines). If this is the case, one
can use the same circuit to interface those lines between the PC and the
mobile, just like with TX/RX lines, however some tests are required to find out
the exact lines. Nevertheless the problem might be much simpler and just be a
matter of shortcircuiting certain lines, like in the handsfree kit. If you find
it out, let me know! ;-)
If you try this design with a mobile different from what I tested please
tell me and I will include it in the list of successfully tested mobiles. Have
fun with your mobile!
E-mail: padilla at
domain "gae ucm es" (my PGP/GPG public key)
First version: 14-May-2004, last update: 4-Dec-2009
This link: http://www.gae.ucm.es/~padilla/extrawork/mobile.html
Go to the parent page: Cheap Hi-Tech.