[om2008.8] Testing packages for Qtopia

[Florian Lohoff]

On Tue, Aug 12, 2008 at 07:38:20PM +0200, Holger Freyther wrote:
> On Tuesday 12 August 2008 17:31:48 you wrote:
> > On Tue, Aug 12, 2008 at 05:22:11PM +0200, Holger Freyther wrote:
> > > Two solutions:
> > > 	- Send a command that does not generate a response. Mickeyl found one
> > > and is happily using that for the TI Calypso in ogsmd and I copied that
> > > now.
> >
> > This sounds really strange - Wouldnt it make more sense to send an AT^M
> > every 50-100ms until you get an OK. By then you know the module is
> > reachable.
> 
> This would make things worse. When would one know that a command is timed out 
> and really lost and needs to be reissued, when do one know that you have 
> every OK one should have gotten? This would also add a lot of latency on 
> answering a phone call. So, yes it would be possible, require to write a lot 
> of code to make it bullet proof and can be totally be avoided by sending 
> something that will never ever generate a response and will always wake the 
> modem up.

Okay - as i understand the problem you wakeup and try to wakeup the GSM
part and you have no knowledge on its state. If you issue a command in
that case it might be lost because the first command only woke it up but
did not get issued. So you basically want a feedback on whether the GSM
modem is available. So my naive assumption is that you issue NOPs until
you get a response at which time you know the GSM modem is awoke and
able to answer/issue/process commands and send the command to issue
after the successful response.

A NOP would be a an AT^M which is simply answered with OK but does
nothing else.

If we have knowledge on what the typical resume time is (i would assume
only a couple of ms) one would trigger a second AT directly after the
first which supposedly woke it up. So given that it takes typically 10ms
to wake the GSM modem up one would send an AT wait for 15ms - if you
receive an OK you know the modem is full concious. If you dont you send
an AT again which should be processed and return an OK.

I wouldnt call this processing a latency killer but rather the only sane
way of getting into a known state. Issueing commands which will not
return anything will probably do something, sometimes probably not and
will not return anything useful on the state you will be in afterwards. 

Its a fire-and-forget strategy. In case something goes wrong in the GSM 
module, it does not wake up in time or whatever it might decide to do
you end up in the same position again.

But nevermind - its just my naive thoughts - not having dealt with the
Calypso ...

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.openmoko.org/pipermail/devel/attachments/20080812/869dc7bb/attachment-0001.pgp