On Fri, Aug 15, 2008 at 08:35:20PM +0200, arne anka wrote:
> ok, here they are, teh scripts i use to make the baby sleep.
> the fr still wkaes up from an gsm event after a few hours (6 or 10), but
> still the battery lasts a lot longer now.
> thanks to Stevhen**, who pointed me to the qtopia sour
On Fri, Aug 15, 2008 at 03:16:58PM -0500, Steven ** wrote:
> Thanks should be directed to Thomas B. <[EMAIL PROTECTED]>. He's the
> one that found the relevant Qtopia source. Thanks Thomas!
Glad that I could help :-)
Regards,
Thomas
___
support mail
> Well, you could turn the GSM chip off via the power menu...
that's not really a solution.
yers ago i had i cellphone working in the 1800 band only. since my
provider did not cover the entire area i was moving in sometimes the phone
did not find connection and scanned wildly burning a lot of
Thanks should be directed to Thomas B. <[EMAIL PROTECTED]>. He's the
one that found the relevant Qtopia source. Thanks Thomas!
-Steven
On Fri, Aug 15, 2008 at 1:35 PM, arne anka <[EMAIL PROTECTED]> wrote:
> ok, here they are, teh scripts i use to make the baby sleep.
> the fr still wkaes up fro
Well, you could turn the GSM chip off via the power menu...
I haven't noticed a large power drain when without signal. It
suspends just fine now and will sit in suspend consistently.
Suspended for an hour uses 1% or so of the battery. Perhaps one of
the GSM commands in the suspend script is disa
ok, here they are, teh scripts i use to make the baby sleep.
the fr still wkaes up from an gsm event after a few hours (6 or 10), but
still the battery lasts a lot longer now.
thanks to Stevhen**, who pointed me to the qtopia sources executing the at
commands on suspend/resume.
now, if someone
> it's worth mentioning that running GSM without association to a network
> probably drains battery like hell, as GSM-chipsets tend to constantly
> search
> the whole frequency range for some BS to register. I've experienced
> factor 5
> to 10 for power consumption.
i know, i had a phone once
Am Mi 13. August 2008 schrieb arne anka:
> > I finally got around to checking this. The script runs instantly when
> > I have cell registration. So, that explains why my script was taking
> > so long. But what can I do about it?
>
> you could check if you have registration, someway along
> ech
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|>> To what are you referring? Did you see that in the linked qtopia code?
|> no. i think you said that -- umount/mount on suspend/resume was a
|> workaround except when resuming from gsm event. am i wrong?
| Oh, yes. That is what it seemed like.
Oh, yes. That is what it seemed like. Perhaps I was just unlucky the
first time. I'll mess with it again after work to confirm that that
truly is the difference. But right now, I haven't corrupted my SD
card for a few days.
-Steven
On Wed, Aug 13, 2008 at 9:42 AM, arne anka <[EMAIL PROTECTED]
> To what are you referring? Did you see that in the linked qtopia code?
no. i think you said that -- umount/mount on suspend/resume was a
workaround except when resuming from gsm event. am i wrong?
___
support mailing list
support@lists.openmoko.org
To what are you referring? Did you see that in the linked qtopia code?
-Steven
On Wed, Aug 13, 2008 at 8:08 AM, arne anka <[EMAIL PROTECTED]> wrote:
> well, i am still curios inhowfar resume_reason!=GSM is different from
> resume_reason==GSM ...
___
s
> I finally got around to checking this. The script runs instantly when
> I have cell registration. So, that explains why my script was taking
> so long. But what can I do about it?
you could check if you have registration, someway along
echo -n "csr" | libgsmd-tool -m shell
and read the return
I finally got around to checking this. The script runs instantly when
I have cell registration. So, that explains why my script was taking
so long. But what can I do about it? If I've suspended my Neo, I
wouldn't want it waking up (and corrupting the SD card) as soon as I
move into a cell tower
> Yup. OM2007.2 used here.
check when you got registration?
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Yup. OM2007.2 used here.
-Steven
On Tue, Aug 12, 2008 at 9:42 AM, arne anka <[EMAIL PROTECTED]> wrote:
>> I'm concerned then. Running the commands with "echo -e ..." takes
>> even longer. I gave up and killed the script after 6 minutes. Maybe
>> it's because I'm not receiving cell signals righ
> I'm concerned then. Running the commands with "echo -e ..." takes
> even longer. I gave up and killed the script after 6 minutes. Maybe
> it's because I'm not receiving cell signals right now? Why else would
> mine take so long when yours goes quick?
sounds likely. but then, i do absolutely n
On Tue, Aug 12, 2008 at 7:44 AM, arne anka <[EMAIL PROTECTED]> wrote:
>> Well, I think I figured it out a little myself. Maybe I'm doing it
>> wrong, but those chat commands take a long time to run on my Neo.
>
> i do
> echo -e "AT..." | libgsmd-tool -m atcmd
> and there's no significant delay.
I
> Well, I think I figured it out a little myself. Maybe I'm doing it
> wrong, but those chat commands take a long time to run on my Neo.
i do
echo -e "AT..." | libgsmd-tool -m atcmd
and there's no significant delay.
> There's no way they were run before the device entered suspend when I
> put th
Well, I think I figured it out a little myself. Maybe I'm doing it
wrong, but those chat commands take a long time to run on my Neo.
There's no way they were run before the device entered suspend when I
put them in the /etc/apm/suspend.d/ folder. Does your suspend script
take several minutes to r
Would you mind posting those scripts? I'd like to try them out.
-Steven
On Tue, Aug 12, 2008 at 4:13 AM, arne anka <[EMAIL PROTECTED]> wrote:
>>> http://git.openmoko.org/?p=qtopia.git;a=blob;f=devices/ficgta01/src/plugins/phonevendors/ficgta01/vendor_ficgta01.cpp;hb=HEAD#l603
>
> i put it into /
>> http://git.openmoko.org/?p=qtopia.git;a=blob;f=devices/ficgta01/src/plugins/phonevendors/ficgta01/vendor_ficgta01.cpp;hb=HEAD#l603
i put it into /etc/apm/suspend.d/ (and the accoring reset into
/etc/apam/resume.d/) and after running the script manually (apm seemed not
to pick it up automati
> http://git.openmoko.org/?p=qtopia.git;a=blob;f=devices/ficgta01/src/plugins/phonevendors/ficgta01/vendor_ficgta01.cpp;hb=HEAD#l603
sounds good, i give it a try tonight.
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mai
On Mon, Aug 11, 2008 at 12:14:10PM +0200, arne anka wrote:
> i logged the resume_reason for the past days and all undesired wakeups are
> caused by EINT01_GSM -- as expected.
> so, i'd like to catch that events and send the phone back to sleep
> immediately.
> but, and it's a big but, EINT01_GS
i logged the resume_reason for the past days and all undesired wakeups are
caused by EINT01_GSM -- as expected.
so, i'd like to catch that events and send the phone back to sleep
immediately.
but, and it's a big but, EINT01_GSM is triggered even when a call comes in
(and probably an sms, too)
25 matches
Mail list logo
