Re: Bug #1024 related power measurement of the GSM modem
Am Mittwoch, den 03.12.2008, 09:57 +0100 schrieb Stefan Schmidt: > > I ask because I can see regular > > activity on the AT command interface. For example every minute the > > modem is asked about its SMS status (I wonder why the modem has > > to be polled and why the unsolicited status messages from the modem > > are not enough to find out if a new SMS has arrived). > > Hmm, mickey would know if this is a bug or feature. :) Nothing to worry about. We're not checking for incoming SMS btw., but rather unsent outgoing, since we had some problems with missing ACK PDUs. :M: ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 related power measurement of the GSM modem
Hello. On Tue, 2008-12-02 at 09:31, Dieter Spaar wrote: > > Stefan Schmidt wrote: >> To follow up on the #1024 traces. I fear you are still not able to reproduce >> the >> re-camping? > > No, I cannot reproduce it here. It seems that it requires a special GSM > net situation. Pity. I will see if I can make some more logs this week. > From the PCO2 logs you made, it look like this without applying the > AT%SLEEP=2 workaround (Thank you for allowing to post this trace > overview). All times are relative, CID is the cell ID: > > 00:06:04:667 MMR_REG_CNF received: LAC: 0020, CID: DACC > 00:09:37:249 MMR_REG_CNF received: LAC: 0020, CID: DAB8 > 00:11:45:560 MMR_REG_CNF received: LAC: 0020, CID: 00CA > 00:12:41:293 MMR_REG_CNF received: LAC: 0020, CID: C834 > 00:14:24:681 MMR_REG_CNF received: LAC: 0020, CID: DACC > 00:14:48:234 MMR_REG_CNF received: LAC: 0020, CID: DAB8 > 00:15:23:502 MMR_REG_CNF received: LAC: 0020, CID: 00C0 > 00:16:22:414 MMR_REG_CNF received: LAC: 0020, CID: DACC > 00:16:49:465 MMR_REG_CNF received: LAC: 0020, CID: 00CA > > It seems that you have at least five cells for your network around > which can be received with a similar level. [ Hey, I think I have > buy more BS-11 base stations and install all of them to get > something similar here ;-) ] I would know a source for it, so will you. :) > On a first look the cell re-selections are done because > the GSM modem has decided that a different cell is better > than the current one. I would say that this is not necessarily > a wrong behavior of the GSM modem. The wrong part comes into play if one keep in mind that the phone sits on the same place all the time. > The situation is similar with the AT%SLEEP=2 workaround applied: > > 00:03:44:457 MMR_REG_CNF received: LAC: 0020, CID: DAB8 > 00:03:58:336 MMR_REG_CNF received: LAC: 0020, CID: 00CA > 00:04:32:477 MMR_REG_CNF received: LAC: 0020, CID: DACC > > (The trace is shorter so there are not that many cell re-selections). > > Is this a similar frequency of cell re-selections you see when Bug #1024 > is occurring ? I haven't counted it so far. > What image do you run on your phone ? FSO milestone 4.1 > I ask because I can see regular > activity on the AT command interface. For example every minute the > modem is asked about its SMS status (I wonder why the modem has > to be polled and why the unsolicited status messages from the modem > are not enough to find out if a new SMS has arrived). Hmm, mickey would know if this is a bug or feature. :) >> I still have the option open to have PCO2 disconnected and try to get some >> traces once the phone starts to show the bug. >> > > Yes, this would be great if you could try it out. Maybe there is a > different > behavior than. Will try to produce them this week. > I really appreciate your help. Hopefully if gives some hints to what is > going on. Of course my hope, too. :) regards Stefan Schmidt ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 related power measurement of the GSM modem
Am Di 2. Dezember 2008 schrieb Dieter Spaar: > Hello Stefan, > > Stefan Schmidt wrote: > > To follow up on the #1024 traces. I fear you are still not able to reproduce the > > re-camping? > > > > No, I cannot reproduce it here. It seems that it requires a special GSM > net situation. > > From the PCO2 logs you made, it look like this without applying the > AT%SLEEP=2 workaround (Thank you for allowing to post this trace > overview). All times are relative, CID is the cell ID: > > 00:06:04:667 MMR_REG_CNF received: LAC: 0020, CID: DACC > 00:09:37:249 MMR_REG_CNF received: LAC: 0020, CID: DAB8 > 00:11:45:560 MMR_REG_CNF received: LAC: 0020, CID: 00CA > 00:12:41:293 MMR_REG_CNF received: LAC: 0020, CID: C834 > 00:14:24:681 MMR_REG_CNF received: LAC: 0020, CID: DACC > 00:14:48:234 MMR_REG_CNF received: LAC: 0020, CID: DAB8 > 00:15:23:502 MMR_REG_CNF received: LAC: 0020, CID: 00C0 > 00:16:22:414 MMR_REG_CNF received: LAC: 0020, CID: DACC > 00:16:49:465 MMR_REG_CNF received: LAC: 0020, CID: 00CA > > It seems that you have at least five cells for your network around > which can be received with a similar level. [ Hey, I think I have > buy more BS-11 base stations and install all of them to get > something similar here ;-) ] > > On a first look the cell re-selections are done because > the GSM modem has decided that a different cell is better > than the current one. I would say that this is not necessarily > a wrong behavior of the GSM modem. Please check C1/C2 threshold levels. Usually this *is* an erratic behaviour of GSM. > > The situation is similar with the AT%SLEEP=2 workaround applied: > > 00:03:44:457 MMR_REG_CNF received: LAC: 0020, CID: DAB8 > 00:03:58:336 MMR_REG_CNF received: LAC: 0020, CID: 00CA > 00:04:32:477 MMR_REG_CNF received: LAC: 0020, CID: DACC > > (The trace is shorter so there are not that many cell re-selections). So we see the same unpleasant behaviour here as well :-( Seems sleep=2 won't stop it. Is this really an active complete cell reselect? Could you check if there's GSM TX activity each time we see "MMR_REG_CNF received:" please. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 related power measurement of the GSM modem
Hello Stefan, Stefan Schmidt wrote: > To follow up on the #1024 traces. I fear you are still not able to reproduce > the > re-camping? > No, I cannot reproduce it here. It seems that it requires a special GSM net situation. From the PCO2 logs you made, it look like this without applying the AT%SLEEP=2 workaround (Thank you for allowing to post this trace overview). All times are relative, CID is the cell ID: 00:06:04:667 MMR_REG_CNF received: LAC: 0020, CID: DACC 00:09:37:249 MMR_REG_CNF received: LAC: 0020, CID: DAB8 00:11:45:560 MMR_REG_CNF received: LAC: 0020, CID: 00CA 00:12:41:293 MMR_REG_CNF received: LAC: 0020, CID: C834 00:14:24:681 MMR_REG_CNF received: LAC: 0020, CID: DACC 00:14:48:234 MMR_REG_CNF received: LAC: 0020, CID: DAB8 00:15:23:502 MMR_REG_CNF received: LAC: 0020, CID: 00C0 00:16:22:414 MMR_REG_CNF received: LAC: 0020, CID: DACC 00:16:49:465 MMR_REG_CNF received: LAC: 0020, CID: 00CA It seems that you have at least five cells for your network around which can be received with a similar level. [ Hey, I think I have buy more BS-11 base stations and install all of them to get something similar here ;-) ] On a first look the cell re-selections are done because the GSM modem has decided that a different cell is better than the current one. I would say that this is not necessarily a wrong behavior of the GSM modem. The situation is similar with the AT%SLEEP=2 workaround applied: 00:03:44:457 MMR_REG_CNF received: LAC: 0020, CID: DAB8 00:03:58:336 MMR_REG_CNF received: LAC: 0020, CID: 00CA 00:04:32:477 MMR_REG_CNF received: LAC: 0020, CID: DACC (The trace is shorter so there are not that many cell re-selections). Is this a similar frequency of cell re-selections you see when Bug #1024 is occurring ? What image do you run on your phone ? I ask because I can see regular activity on the AT command interface. For example every minute the modem is asked about its SMS status (I wonder why the modem has to be polled and why the unsolicited status messages from the modem are not enough to find out if a new SMS has arrived). > I still have the option open to have PCO2 disconnected and try to get some > traces once the phone starts to show the bug. > Yes, this would be great if you could try it out. Maybe there is a different behavior than. > I'm pretty busy with FSO tasks, so I can not spend to much time on this, but I > would give this test a go if you think it will give you more hints. > > I really appreciate your help. Hopefully if gives some hints to what is going on. Best regards, Dieter ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 related power measurement of the GSM modem
Hello. (A bit late here, sorry) On Fri, 2008-11-28 at 17:39, Dieter Spaar wrote: > > as a background for the reason of this (very simple) > power measurement: I wanted to find out if the "Deep Sleep" > mode of the GSM modem can be somehow detected from the > outside. To follow up on the #1024 traces. I fear you are still not able to reproduce the re-camping? I still have the option open to have PCO2 disconnected and try to get some traces once the phone starts to show the bug. I'm pretty busy with FSO tasks, so I can not spend to much time on this, but I would give this test a go if you think it will give you more hints. regards Stefan Schmidt ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 related power measurement of the GSM modem
Andy Green wrote: > There's a great isolated Hall-effect integrated solution for current > measurement that would enable monitoring at high bandwidth (80kHz) with > much reduced impact on the voltage cheaply and simply: > > http://www.allegromicro.com/en/Products/Part_Numbers/0712/ Marvellous ! This chip gets a place of honor on my shopping list. Thanks a lot ! - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: Bug #1024 related power measurement of the GSM modem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Setup: The GSM modem is registered to a network but otherwise idle. The | GTA02 is connected to a PC via USB, the battery is removed and instead | power is supplied by an external power supply. There is a 1 Ohm resistor in | one of the supply lines, the voltage across this resistor is measured. Only 1R is very high for this kind of measurement considering it's sucking |2A, you're dropping >2V here to definitely impact operation of the thing you're measuring --> | been clearly visible. One interesting thing: If the external power supply | limits the current, the GSM modem will perform a reset when trying to | send and there is not enough current available (probably the supply voltage | will drop and causes the reset). I am not sure what happens if the battery | is weak and if this could happen during normal operation. I think this is a very nice idea to get a grip on what this autonomous, current-sucking thing is doing. There's a great isolated Hall-effect integrated solution for current measurement that would enable monitoring at high bandwidth (80kHz) with much reduced impact on the voltage cheaply and simply: http://www.allegromicro.com/en/Products/Part_Numbers/0712/ http://uk.farnell.com/allegro-microsystems/acs712elctr-20a-t/sensor-current-20a-soic8-712/dp/1329624 You just replace your 1R resistor with it and give it 5V, hook the output to your scope. BTW it's a great relief to have someone dealing with the firmware :-) - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkwICwACgkQOjLpvpq7dMrL+gCeIgoxQDYl1m11XOPDa74oe0gz 4mcAn2LG7/O0DGxg04HsybJKC+7wtEg5 =aNms -END PGP SIGNATURE- ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
