GSM modem sleeps on virtual channels in MUX

[mickey@…]

Tests with the gsm0710muxd show that the TI Calypso falls into deep sleep per
_virtual channel_, which is completely bogus, because the MUX mode has its own
power saving commands (PSC). Can we fix that in the firmware?

[mdt@…]

while \r\n is the wakeup sequence in standard mode there is a wakeup-sequence in
muxer mode for the calypso (see #1289) also. i don't know why a per channel
sleep should make sence (wakeup in one channel does not wake up all other).

even more strange is that this does not happen if gprs is on. there is no wakeup
needed in any channel if gprs/ppp is used on one channel.

[mickey@…]

I'm going to do much more tests for this bug. I do not yet fully trust our test
cases where this behaviour has ben seen. I will update you on the status.

[mdt@…]

after heavy testing i have another behavior:

after around 6 days with gsm on (most of the time even using gprs also) the
modem stopped responding to commands on all channels. \r\n didn't wake it up.
stopping the pygsmd and using the first channel did not help. still no responses
at all.

after restarting the muxer (which issues the echo 0 > /sys...) the behavior was
different: most of the commands (but not all, pure device commands like requests
vor vendor, product, version and serial succeeded) gave the good old error "+CME
ERROR: failed to abort" (or similar, not shure, the log is lost). after a
restart of the pygsmd the error did not occure again.

i'm not shure if this observation is related to pm/psc.

[mickey@…]

Multiple automated tests now confirm that the enter the sleep individually per
virtual channel, however once the first channel has been woken up
(either by receiving an unsolicited response or a command that is terminated
with \r\n [which will receive no response]), all virtual channels wake up.

Until we have a proper fix, I will work around this by using a dedicated
KeepAlive? channel that keeps the modem alive (sic!) :(

I would consider one of the following solutions as a proper fix from the side of
the modem, with c) being the most wanted solution, a) or b) being acceptable and
d) being the very last resort.

a) stop sleeping on virtual channels and receive act on PSC wakeup, or
b) stop sleeping on virtual channels and send PSC sleep command, or
c) a) + b)
d) continue sleeping on virtual channels, but accept a special AT wakeup command
that does not send 'OK' if the modem is already woken up.

[mickey@…]

For the records, EOF (\x1a) seems to also wakeup the modem and in contrast to
\r\n, it does not emit an 'OK' if the modem is already woken up.

With that and a global modem communication timestamp, I think we can settle this
issue. Since I'm pretty sure that no one inside Openmoko nor TI will attempt to
fix this properly (see #1289), I will now close this as WONTFIX and limit the
severity since we have a workaround.

[mickey]

And even more for the records, although probably no one is reading this anymore... my analysis was wrong, it doesn't sleep on the virtual channels, it sleeps in multiplexing mode and needs to be sent a full frame (not just flag characters) to be woken up correctly. With regards to the original problem, it's no longer a problem at all, since you can even wake it up properly on mux layer (which is what fso-abyss does) and no longer have to care on the AT layer.

Case closed :)