Ben,

Many thanks for your ideas.  As well as giving me some possible solutions,
you have sparked off a few new ideas in my mind - see below.

Incidentally, I have subsequently read that the "UNIMODEM" serial driver
used in Windows CE 3.0 for Bluetooth serial port emulation hijacks the DSR
and DCD states to confirm that the *Bluetooth* link is still alive (i.e.
both are normally true but go false if the devices go out of range).

IMHO, it's unnecessary to hijack two lines in this way.  Wouldn't it be
more sensible to AND them with the DSR and DCD states from the far end, so
that they are still usable as such when the Bluetooth link is alive?

>What do ATI (or is that AT&I) say?  Maybe you can get one to spit out
>enough identifying information to tell what you're talking to.

Cunning!  However, "ATI" on some mobiles returns only the manufacturer's
name, which is not unique enough since mobile A and modem C may be from
the same manufacturer.

Fortunately, your idea prompted me to remember that there's an "AT+GSN"
command on GSM mobiles which returns its serial number (IMEI).  This is a
globally unique string - not much chance of confusion there!

It's straightforward to issue an "ATI" command at the start of a session
and store the response.  If there's any doubt later about the modem being
communicated with, then another "ATI" command can be issued and the result
compared.  A match would mean that the data link has dropped.

>Also, you could configure one to echo (ATE1/0) and one not and observe the
>echo.  Assumes that you have the problem "solved" at one point in time.

Yes.  This resolves the ambiguity at the time that a command is issued,
though not necessarily when a response comes back (e.g. after an "ATD"
command, it will take some time to get a "NO CARRIER" response, during
which time the GSM data link might also drop out).

>You could set one to respond in numbers and one letters (forget what the
>code for that is).

I originally ruled this out because there will be a lot of numerical
information flying around which could get mistaken for a result code.
However, if I'm disciplined about the data sent to and from the far end
then it may be possible to avoid any ambiguity.

An interesting idea - I must think this one through some more.

>One of the S registers is the 'A' in 'AT' IIRC.

I hadn't heard about that one.

>Also one is the '+' in '+++'.

Unfortunately this S register isn't implemented in the GSM mobiles that I
have worked with so far.  Of course, if it's implemented in the modem (C)
but not the mobile (A) then this becomes a good bet!

>Some of the S registers are harmless or unused, so you could store your
>own "serial number" and retrieve it with ATS?n.

Again, the GSM mobiles that I have worked with seem to implement only a
small subset of S registers.  However, the "AT+GSN" idea above provides a
very suitable serial number!

>Some modems differ in how they handle repeated Ts in ATTTTTT (while
>echoing).  Some will echo T^H over and over and some will just let
>ATTTT show up.

OK.  I can't really rely on this difference in behaviour since a range of
different GSM mobiles and modems may be used in the final application.

>Probably a million other half-baked ideas on that scale if you need them :)

Thanks.  It's reassuring that at least one other person doesn't think that
there's a blindingly obvious and trivial solution!

Your ideas prompted another thought: change the "ATS4" character (response
formatting character sent after carriage return - normally line feed) on
one modem to another character.  This should mean that "NO CARRIER" can be
differentiated by the immediately preceding control character.  However,
I'm not sure whether this S register is universally supported.

Also, I haven't discarded the idea of inserting a second PIC at the remote
end with its UART in series with the serial data output from modem C, so
that it intercepts and occasionally modifies responses from the distant
modem before sending them back.  A simple state machine could recognise
the start of the "NO CARRIER" string and convert it into something else.

I think I'm getting close to a solution now, thanks.  Any other bright
ideas?
--
Ian Chapman
Chapmip Technology, UK

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.