Calypso Mux Observations

[Wally Ritchie]

I've been working with calypso mux for a bit and thought i'd share
some things I've learned.
BTW, I'm working in userland for now. Where the mux actually belongs is another
story. In any case, userland is the place to get this working before
blindly distributing
untested kernel patches ;-).

All of the following refer to the stock GTA01Bv4 and its firmware load
May 15, 2007
as originally shipped in the first batch. I understand that there are
later firmwares
with no explanation of the changes if any or if they affect any of the
following.

Please comment if you have any information or testing that contradicts
the following.

1. The calypso uses GSM7.10 "Advanced" option. This is quite different
in several
important respects from "Basic" option as used in BT RFCOMM, Motorola, and
several others.

2. GSM7.10 spec differs a bit from the 6.1 version to the 7.2 version
but AFAIK these
differences only affect the "Basic" option which is NOT supported by
the calypso.

3. Calypso escapes the DC1 and DC3 as well as the FLAG (0x7e) and ESCAPE (0x7d).
full transparency needs to be correctly implemented. These are listed
as options in
the spec but they appear to be required. A well-designed receiver
should, of course,
handle any escaped characters in the stream.

4. Calypso does not support MCC (Mux Control Channel) command TEST. It does
respond to FCon and FCoff. In addition the calypso does not respond to
PSC. Since
it doesn't respond to PSC it presumably doesn't wake up according to
spec either and
so handling of resume from suspend is not orderly and data will likely be lost.
Because error-recovery options are not supported the data loss is unrecoverable.
Calypso also does not respond either to 3 or more flags as required by
7.10 section
5.2.5

5. Calypso on startup of a DLCI sends "AT-Command Interpreter ready<cr><lf>"
as data on the channel, similar to the after-reset entry to non-mux mode.

6. Calypso appears to send two flags and not share a single flag on back to back
transmissions.

7. Calypso supports MCC command CLD and closes the mux regardless of
open channels and returns to the non-multiplexed mode with the AT-Command
Interpreter ready message.

8. Calypso returns to non-multiplexed mode if the MCC is disconnected, even
if other channels are open.

9. After a channel is opened and after the AT-Command Interpreter Ready Data is
sent the calypso sends MCC MSC (Modem Status Command) without the break
option. The command is repeated every T2 until responded to. This command is
only supposed to be relevant for Basic Option (where in-band flow control is not
available). This behaviour does not appear to be to spec (5.4.6.3.7)
both because it
is "only relevant when the basic option is chosen" and "this command
shall be sent
PRIOR to any user data after a creation of a DLC."

10. Calypso sends NSC (Non Supported Command) to MCC PN command. This
means that no DLC parameters can be negotiated on any of the channels and UIH
frames are the only ones supported on any of the channels.

11. Bringing /sys/bus/platform/devices/gta01-pm-gsm.1/power_on to a low level
and then high level resets the modem and brings it back to non-mux operation as
expected.

None of the above characteristics present any real difficulties with
the possible
exception of the suspend/resume. The data loss, however, can probably be
recovered at higher layers, especially for an active GPRS session.
Loss of messages
relating to an incoming SMS can probably be recovered by examining the SIM
after resume.

Anyone else working on the mux feel free to PM me. It would be nice to have as
many docs and first hand reports on various GSM7.10 variants in order to provide
as wide a range of support in OM for different modem hardware.

Cheers