Re: date and GPS related questions
Hello, pushing this over to smartphones-standards to raise awareness. On Thu, 02 Apr 2009 07:24:21 +0800 William Kenworthy bi...@iinet.net.au wrote: On Wed, 2009-04-01 at 18:15 +0200, Daniel Willmann wrote: Hi, Well, timekeeping is independent from that. The UTC time will stay right no matter what timezone you're in. Unfortunately it doesnt - wanders all over the place, usually lagging. If I notice it, I usually find otimed.py has overwritten my changes to the ntp reference (a local timeserver helps a lot - but its still not great). Depending on where I am connected to, it may or may not see the site in Germany, which may or may not be extremely slow/lagged. If it gets too far out, you have to manually set it. It looks like it often just refuses to work. Nothing in the logs. I also noticed yesterday it says checking every 600 seconds - then it went off and started checking just over every 60 seconds. Okay, this still seems to be a problem with time and not timezone in that case. Jan, do you have anything planned for otimed? I would really like to see the NTP server configurable (with persist) as well as which time(zone) sources are enabled. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Mon, 16 Mar 2009 11:15:34 +0300 Paul Fertser fercer...@gmail.com wrote: Daniel Willmann dan...@openmoko.org writes: I think (not sure) that Qt Extended uses the time(zone) cellbroadcast messages which are broadcasted by some operators. Looks like +CTZV unsolicited message doesn't actually supply timezone information (which must include country-specific DST information), only current offset to UTC (or GMT even?), so it's somewhat useless anyway. Right, though you do know which country the network belongs to so with some nasty assumptions you could probably find the right timezone.. IMO it's not worth the trouble, though. Am i missing something? Probably not. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Hi, On Mon, 16 Mar 2009 06:59:20 +0900 William Kenworthy bi...@iinet.net.au wrote: No, otimed sucks for a number of reasons (not the least being hard coded to an NTP server somewhere in Europe) so control like you are after is critical. just wanted to follow up on this. From the sample frameworkd.conf file: # # Subsystem configuration for otimed # [otimed] # a list of time/zone sources to use or NONE timesources = GPS,NTP zonesources = GSM It would be nice to change that at runtime, patches welcome. :-) In Perth Australia, vodafone appears to have my location set to Lord Howe Island - some 3000+ km away in the pacific - I am near the Indian Ocean. As well, I suspect they are not sending local time, but time as it is in the eastern states (2hr diff). Is there a way to get the gsm to print the data as to what it thinks it is? - some command in mickeyterm? - be nice to confirm and know what its actually doing as I certainly cant trust the FR to get it right. Framework debugging should tell you. The freerunner by design seems unable to keep accurate time unless you are in Europe ... Well, timekeeping is independent from that. The UTC time will stay right no matter what timezone you're in. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Wed, 2009-04-01 at 18:15 +0200, Daniel Willmann wrote: Hi, On Mon, 16 Mar 2009 06:59:20 +0900 William Kenworthy bi...@iinet.net.au wrote: No, otimed sucks for a number of reasons (not the least being hard coded to an NTP server somewhere in Europe) so control like you are after is critical. just wanted to follow up on this. From the sample frameworkd.conf file: # # Subsystem configuration for otimed # [otimed] # a list of time/zone sources to use or NONE timesources = GPS,NTP zonesources = GSM It would be nice to change that at runtime, patches welcome. :-) For counties that have more than one timezone make sure that /etc/localtime is COPIED from /usr/share/zoneinfo and /etc/timezone is properly set as well. In /etc/frameworkd.conf change zonesources to zonesources = NONE In Perth Australia, vodafone appears to have my location set to Lord Howe Island - some 3000+ km away in the pacific - I am near the Indian Ocean. As well, I suspect they are not sending local time, but time as it is in the eastern states (2hr diff). Is there a way to get the gsm to print the data as to what it thinks it is? - some command in mickeyterm? - be nice to confirm and know what its actually doing as I certainly cant trust the FR to get it right. Framework debugging should tell you. The freerunner by design seems unable to keep accurate time unless you are in Europe ... Well, timekeeping is independent from that. The UTC time will stay right no matter what timezone you're in. The timezone packets for multi timezone countries aren't processed properly yet. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Wed, 2009-04-01 at 18:15 +0200, Daniel Willmann wrote: Hi, Well, timekeeping is independent from that. The UTC time will stay right no matter what timezone you're in. Unfortunately it doesnt - wanders all over the place, usually lagging. If I notice it, I usually find otimed.py has overwritten my changes to the ntp reference (a local timeserver helps a lot - but its still not great). Depending on where I am connected to, it may or may not see the site in Germany, which may or may not be extremely slow/lagged. If it gets too far out, you have to manually set it. It looks like it often just refuses to work. Nothing in the logs. I also noticed yesterday it says checking every 600 seconds - then it went off and started checking just over every 60 seconds. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Daniel Willmann dan...@openmoko.org writes: I think (not sure) that Qt Extended uses the time(zone) cellbroadcast messages which are broadcasted by some operators. Looks like +CTZV unsolicited message doesn't actually supply timezone information (which must include country-specific DST information), only current offset to UTC (or GMT even?), so it's somewhat useless anyway. Am i missing something? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Monday 16 March 2009, Daniel Willmann wrote: I think (not sure) that Qt Extended uses the time(zone) cellbroadcast messages which are broadcasted by some operators. Yeah, I think you're right, the code says: The TimeUpdate service monitors time and timezone data from sources such as the modem and updates the system time and timezone accordingly. I can't find where it actually polls the modem though. In Germany for example nobody sends these so the framework looks up the country code of the GSM cell we're logged in and changes the timezone according to the zone this country belongs to. This is problematic/inaccurate/annoying for countries that span different timezones like the USA, Russia, Australia Yup, and don't assume that all TZ's are 1 hour apart, Adelaide is 30 minutes different from here.. ;-) cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Sat, 14 Mar 2009 10:35:37 +0100 Fernando Martins ferna...@cmartins.nl wrote: BTW, the date was automatically set, somehow, some days later. Is this done when there is a phone call? (I have few phone calls). Timezone will be set according to the nationality of the GSM network you're associated to. Since this is annoying for a couple of people we'll probably make this optional/prompt for new timezone. Time will be updated either through NTP if your FR has a connection to the Internet or through GPS if you wait long enough. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Sunday 15 March 2009, Daniel Willmann wrote: Timezone will be set according to the nationality of the GSM network you're associated to. Since this is annoying for a couple of people we'll probably make this optional/prompt for new timezone. Qt Extended has 3 options for this - Always, Ask and Off. Mind you I've never had Always or Ask work for me (in 4.4.2, not tried 4.4.3 yet) so I'm not sure if the functionality works in it, or whether it's just not finding what it expects to find. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Hello, On Thu, 12 Mar 2009 22:19:05 +0100 Fernando Martins ferna...@cmartins.nl wrote: 1) I got the date reset to 1970 a few times. I was not paying attention but I guess this happens when battery is removed, i.e., there's no battery specific for the clock? there is a backup battery, but in my experience it only takes a couple hours without battery until the time is lost again. 2) Several posts mentioned that GPS could only get the fix if date was correct, the requirements being within 1 sec precision. However, with the date/time completely messed up, GPS is getting the fix anyway (and it's fairly fast, 1 min or so). So, what's up? I'm using SHR unstable from January. Is the GPS driver (?) being to ignore dates before FR production, or something else? It's not ignoring anything, but the chip is robust enough to recover from that. ogpsd should add some safeguards like storing the offset GPS time/system time so that it will report the correct time to the GPS chip even if somebody sets their time to be five minutes ahead constantly. 3) While using tangoGPS and I enter a building, when I come out, a fix is not gotten until I reboot FR. Is this a known issue? any quicker workaround than rebooting? So you're going in with a fix and when you come out you wont get a fix any more? How long are you staying in the building? Please check with the GPS tabs in zhone How many SVs have ephemeris before and after you are inside the building. Also check after you've left the building if you are seeing any signals from SVs and if the chip actually thinks there are SVs in the sky. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Daniel Willmann wrote: On Sat, 14 Mar 2009 10:35:37 +0100 Fernando Martins ferna...@cmartins.nl wrote: BTW, the date was automatically set, somehow, some days later. Is this done when there is a phone call? (I have few phone calls). Timezone will be set according to the nationality of the GSM network you're associated to. Since this is annoying for a couple of people we'll probably make this optional/prompt for new timezone. Time will be updated either through NTP if your FR has a connection to the Internet or through GPS if you wait long enough. I'm a bit confused with this: I would assume that if timezone is changed, time/date would be automatically updated. So, why then bother to update time based on NTP or GPS? Also, it would be nice to know, grossly, how much is long enough, but I suppose it's not yet done or decided... When I'm traveling for short periods, usually I don't bother to change times to local, unless I have tight schedules to follow and prefer not to risk missing a mental time translation. For longer periods, usually I do. I think it would be nice to go to a date/time setting panel having (also) a button to just change the timezone. Of course this requires the FR to know at all times that the set timezone is not the local one. Also, a very small but annoying issue: busybox date command displays a very brief help string that does not tell which is the input format to set date/time. If one is on the road, without a GUI to set date/time, and no man page, the format is difficult to guess (date -s MMDDhhmm.ss). I suggest to show this format on the help string of date (I know technically it is a trivial change, but no idea of what this involves regarding patch bureaucracy). Regards, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Sun, 15 Mar 2009 23:31:18 +1100 Chris Samuel ch...@csamuel.org wrote: On Sunday 15 March 2009, Daniel Willmann wrote: Timezone will be set according to the nationality of the GSM network you're associated to. Since this is annoying for a couple of people we'll probably make this optional/prompt for new timezone. Qt Extended has 3 options for this - Always, Ask and Off. Mind you I've never had Always or Ask work for me (in 4.4.2, not tried 4.4.3 yet) so I'm not sure if the functionality works in it, or whether it's just not finding what it expects to find. I think (not sure) that Qt Extended uses the time(zone) cellbroadcast messages which are broadcasted by some operators. In Germany for example nobody sends these so the framework looks up the country code of the GSM cell we're logged in and changes the timezone according to the zone this country belongs to. This is problematic/inaccurate/annoying for countries that span different timezones like the USA, Russia, Australia. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Daniel, many thanks for your replies, please see below. Daniel Willmann wrote: Hello, On Thu, 12 Mar 2009 22:19:05 +0100 Fernando Martins ferna...@cmartins.nl wrote: there is a backup battery, but in my experience it only takes a couple hours without battery until the time is lost again. I never leave the battery out, I only take it out to reboot after a crash. But now I wonder: usually I keep the phone switched off during the night, and since I use it rarely, sometimes I forget it switched off at home. Is it the case that, when FR is switched off, the main battery does not feed the backup battery? (yeah it sounds weird, the main battery would become the backup of the backup battery). So you're going in with a fix and when you come out you wont get a fix any more? How long are you staying in the building? 1 hour is sufficient to become unable to get the fix back. Please check with the GPS tabs in zhone How many SVs have ephemeris before and after you are inside the building. Also check after you've left the building if you are seeing any signals from SVs and if the chip actually thinks there are SVs in the sky. I don't have zhone installed but from using tangoGPS I remember it stated always 0 SV on the sky (e.g. 8/0). I don't think in tangoGPS I can see how many have ephemeris data (I though all of them had it). I'll install zhone and do the checks. regards, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Sun, 15 Mar 2009 14:41:03 +0100 Fernando Martins ferna...@cmartins.nl wrote: Daniel Willmann wrote: Timezone will be set according to the nationality of the GSM network you're associated to. Since this is annoying for a couple of people we'll probably make this optional/prompt for new timezone. Time will be updated either through NTP if your FR has a connection to the Internet or through GPS if you wait long enough. I'm a bit confused with this: I would assume that if timezone is changed, time/date would be automatically updated. So, why then There are a couple reasons actually. First, determining timezone based on the country code of the GSM network you're logged in does not give you any indication of the actual time. Second, the actual timezone and time cellbroadcast messages are not sent by all providers. In Germany none of the providers support these... Third, even if time is sent as cellbroadcast the time sent can be off by a couple of minutes (warning, this is hearsay. I have no real experience with time cellbroadcast messages). bother to update time based on NTP or GPS? Also, it would be nice to know, grossly, how much is long enough, but I suppose it's not yet done or decided... IIRC otimed (Jan should know better) will listen to the time signal of the GPS (which is only sent if GPS is on) and adjust the system time accordingly. Same with ntp which is checked periodically (and only works if a network connection is present, obviously). periods, usually I do. I think it would be nice to go to a date/time setting panel having (also) a button to just change the timezone. Of course this requires the FR to know at all times that the set timezone is not the local one. I'm not sure I understand completely. I can't see why one wouldn't want to set the proper time (maybe with an offset option for people notoriously being late so they can set the clock to real-time + 5min). Could you explain some more what you mean by that? You can already statically enable specific time(-zone) sources or disable them all together in /etc/frameworkd.conf: [otimed] # a list of time/zone sources to use or NONE timesources = GPS,NTP zonesources = GSM Also, a very small but annoying issue: busybox date command displays a very brief help string that does not tell which is the input format to set date/time. If one is on the road, without a GUI to set date/time, and no man page, the format is difficult to guess (date -s MMDDhhmm.ss). I suggest to show this format on the help string of date (I know technically it is a trivial change, but no idea of what this involves regarding patch bureaucracy). Yes, I have learned to have busybox for this and similar reasons. Maybe some day we'll replace it with the real packages, but I don't know how much space that will eat. Anyway, what I would want on the road (regardless of the busybox annoyance, which should be fixed) is actually a GUI to change date/time. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Sun, 15 Mar 2009 15:36:29 +0100 Fernando Martins ferna...@cmartins.nl wrote: Daniel Willmann wrote: there is a backup battery, but in my experience it only takes a couple hours without battery until the time is lost again. But now I wonder: usually I keep the phone switched off during the night, and since I use it rarely, sometimes I forget it switched off at home. Is it the case that, when FR is switched off, the main battery does not feed the backup battery? (yeah it sounds weird, the main battery would become the backup of the backup battery). That should work. I'm trying to reproduce that now. Does that also happen if you keep your FR switched off overnight or for a couple of hours? After that happens is your main battery drained completely or is it at about the same level before you turned your FR off? So you're going in with a fix and when you come out you wont get a fix any more? How long are you staying in the building? 1 hour is sufficient to become unable to get the fix back. Okay, would be interesting to see what zhone says about the issue. I don't have zhone installed but from using tangoGPS I remember it stated always 0 SV on the sky (e.g. 8/0). I don't think in tangoGPS I can see how many have ephemeris data (I though all of them had it). IIRC 8/0 means the GPS thinks there are 8 SVs in the sky, but it uses 0 for the fix. I'll install zhone and do the checks. Great, thanks. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Am So 15. März 2009 schrieb Fernando Martins: Daniel, many thanks for your replies, please see below. Daniel Willmann wrote: Hello, On Thu, 12 Mar 2009 22:19:05 +0100 Fernando Martins ferna...@cmartins.nl wrote: there is a backup battery, but in my experience it only takes a couple hours without battery until the time is lost again. I never leave the battery out, I only take it out to reboot after a crash. But now I wonder: usually I keep the phone switched off during the night, and since I use it rarely, sometimes I forget it switched off at home. Is it the case that, when FR is switched off, the main battery does not feed the backup battery? (yeah it sounds weird, the main battery would become the backup of the backup battery). From PCF50633 PMU datasheet it seems backup bat isn't used as long as main battery is supplying sufficient voltage, no matter whether phone switched off or not. So backup bat is the backup for main bat, not vice versa ;-) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Daniel Willmann wrote: I'm not sure I understand completely. I can't see why one wouldn't want to set the proper time (maybe with an offset option for people notoriously being late so they can set the clock to real-time + 5min). Could you explain some more what you mean by that? Ok, this might not seem so rational, but it works for me: because I have to correct the time for several devices (wrist-watch, car, phone, etc), I just ignore all of those. In a couple of days, they'll be back to the correct time anyway :). The important point is that all my clocks are consistently wrong. If FR changes the timezone without me realising it, then I can be tricked into looking into the right time and wrongly add up one hour more on it. (it has happend that I fixed one clock and then get tricked by another - it can happen both under stress or total relaxation :-) That's why (consistency) I would prefer to have manual control of time changes on FR, but I'm starting to feel I'm the nut job here :-) Regards, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Sun, 15 Mar 2009 17:14:23 +0100 Fernando Martins ferna...@cmartins.nl wrote: Daniel Willmann wrote: I'm not sure I understand completely. I can't see why one wouldn't want to set the proper time (maybe with an offset option for people notoriously being late so they can set the clock to real-time + 5min). Could you explain some more what you mean by that? Ok, this might not seem so rational, but it works for me: because I have to correct the time for several devices (wrist-watch, car, phone, etc), I just ignore all of those. In a couple of days, they'll be back to the correct time anyway :). The important point is that all my clocks are consistently wrong. If FR changes the timezone without me realising it, then I can be tricked into looking into the right time and wrongly add up one hour more on it. (it has happend that I fixed one clock and then get tricked by another - it can happen both under stress or total relaxation :-) Okay, I can totally understand that. But in that case you only want to disable the timezone changes. You would still want your time to be accurate to the second (of the timezone it is set to), would you not? That's why (consistency) I would prefer to have manual control of time changes on FR, but I'm starting to feel I'm the nut job here :-) No, I'm all for control. But I need to understand what you actually want before I can think about implementing it. :-) Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Daniel Willmann wrote: But now I wonder: usually I keep the phone switched off during the night, and since I use it rarely, sometimes I forget it switched off at home. Is it the case that, when FR is switched off, the main battery does not feed the backup battery? (yeah it sounds weird, the main battery would become the backup of the backup battery). That should work. I'm trying to reproduce that now. Does that also happen if you keep your FR switched off overnight or for a couple of hours? After that happens is your main battery drained completely or is it at about the same level before you turned your FR off? It's not simple to give an accurate answer because I hardly need a mobile and even rarely look at the FR time. When I notice the date was reseted (which happened ~3 times in a couple of months) it's difficult to associate it with what I've done with the battery. Usually (but not always) I charge it in the evening before switching it off (it's never fully charged because of GSM being ON). I don't recall ever being surprised by a (almost) drained battery. I never let the battery discharge completely (for known reasons). I will pay attention to battery date in the mornings. If there is some other specific observation that could be useful let me know. IIRC 8/0 means the GPS thinks there are 8 SVs in the sky, but it uses 0 for the fix. Yes, you are right. Regards, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Joerg Reisenweber wrote: Am So 15. März 2009 schrieb Fernando Martins: Daniel, many thanks for your replies, please see below. Daniel Willmann wrote: Hello, On Thu, 12 Mar 2009 22:19:05 +0100 Fernando Martins ferna...@cmartins.nl wrote: there is a backup battery, but in my experience it only takes a couple hours without battery until the time is lost again. I never leave the battery out, I only take it out to reboot after a crash. But now I wonder: usually I keep the phone switched off during the night, and since I use it rarely, sometimes I forget it switched off at home. Is it the case that, when FR is switched off, the main battery does not feed the backup battery? (yeah it sounds weird, the main battery would become the backup of the backup battery). From PCF50633 PMU datasheet it seems backup bat isn't used as long as main battery is supplying sufficient voltage, no matter whether phone switched off or not. So backup bat is the backup for main bat, not vice versa ;-) /j Uff, I was getting all confused with these batteries back and forth :-) I never let the main battery drain fully, so something else has caused the date to reset. BTW, I was also curious whether the backup battery recharge itself, and from the datasheet above it seems to be the case. I still remember the old times where I had to replace batteries in PC motherboards. Nowadays motherboards dye before the battery :-) Regards, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Daniel Willmann wrote: Okay, I can totally understand that. But in that case you only want to disable the timezone changes. I assume the default is to have automatic timezone changes enabled. I would like to go to a config file (no big need for UI) and change enabled to disabled (or change 1 to 0). When I need to change the date/time, I would go to an UI, which tests if (option=0 AND FR_timezone local_timezone), a button labeled Adjust to local timezone would become enabled. You would still want your time to be accurate to the second (of the timezone it is set to), would you not? Personally yes, but I know people, as you also mentioned, who advance their watches 5 min (or even 15 min) to help them be on time. Therefore I am inclined to say that in this case an automatic change after moving to another timezone should keep an existing shift on time. Is this problematic? Regards, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Sun, 15 Mar 2009 20:43:46 +0100 Fernando Martins ferna...@cmartins.nl wrote: Daniel Willmann wrote: Okay, I can totally understand that. But in that case you only want to disable the timezone changes. I assume the default is to have automatic timezone changes enabled. I would like to go to a config file (no big need for UI) and change enabled to disabled (or change 1 to 0). When I need to change the date/time, I would go to an UI, which tests if (option=0 AND FR_timezone local_timezone), a button labeled Adjust to local timezone would become enabled. Sure thing. Go to /etc/frameworkd.conf and look at the section # # Subsystem configuration for otimed # [otimed] # a list of time/zone sources to use or NONE timesources = GPS,NTP zonesources = GSM Just set timesources to NONE and nobody but you will meddle with the time. Set zonesources to NONE and the same will be true for timezones. You would still want your time to be accurate to the second (of the timezone it is set to), would you not? Personally yes, but I know people, as you also mentioned, who advance their watches 5 min (or even 15 min) to help them be on time. Therefore I am inclined to say that in this case an automatic change after moving to another timezone should keep an existing shift on time. Is this problematic? As I said setting timesources to NONE will just not change the time at all. What isn't implemented, but I'd like to see is a configurable offset from the current time so people could keep timesources enabled and still have their clock be 5 minutes early. I don't see any problems implementation wise, just that someone will have to do it. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Sun, 15 Mar 2009 15:36:29 +0100 Fernando Martins ferna...@cmartins.nl wrote: I'll install zhone and do the checks. Hi Daniel, I'm having trouble to install zhone. What about using telnet to extract the GPS info you asked? (what would I have to do?) Regards, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
No, otimed sucks for a number of reasons (not the least being hard coded to an NTP server somewhere in Europe) so control like you are after is critical. In Perth Australia, vodafone appears to have my location set to Lord Howe Island - some 3000+ km away in the pacific - I am near the Indian Ocean. As well, I suspect they are not sending local time, but time as it is in the eastern states (2hr diff). Is there a way to get the gsm to print the data as to what it thinks it is? - some command in mickeyterm? - be nice to confirm and know what its actually doing as I certainly cant trust the FR to get it right. The freerunner by design seems unable to keep accurate time unless you are in Europe ... BillK On Sun, 2009-03-15 at 17:14 +0100, Fernando Martins wrote: Daniel Willmann wrote: I'm not sure I understand completely. I can't see why one wouldn't want to set the proper time (maybe with an offset option for people notoriously being late so they can set the clock to real-time + 5min). Could you explain some more what you mean by that? Ok, this might not seem so rational, but it works for me: because I have to correct the time for several devices (wrist-watch, car, phone, etc), I just ignore all of those. In a couple of days, they'll be back to the correct time anyway :). The important point is that all my clocks are consistently wrong. If FR changes the timezone without me realising it, then I can be tricked into looking into the right time and wrongly add up one hour more on it. (it has happend that I fixed one clock and then get tricked by another - it can happen both under stress or total relaxation :-) That's why (consistency) I would prefer to have manual control of time changes on FR, but I'm starting to feel I'm the nut job here :-) Regards, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy bi...@iinet.net.au Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Mike Montour wrote: Fernando Martins wrote: 1) I got the date reset to 1970 a few times. I was not paying attention but I guess this happens when battery is removed, i.e., there's no battery specific for the clock? There is a backup battery. Make sure that the system time is being saved to the hardware clock, e.g. hwclock --utc --systohc. I'm sure I did it, per Wiki page (no --utc) http://wiki.openmoko.org/wiki/Date. Next time I remove the battery, I'll pay more attention to the date. BTW, the date was automatically set, somehow, some days later. Is this done when there is a phone call? (I have few phone calls). Cheers, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
On Thu, Mar 12, 2009 at 10:19:05PM +0100, Fernando Martins wrote: Hi, 1) I got the date reset to 1970 a few times. I was not paying attention but I guess this happens when battery is removed, i.e., there's no battery specific for the clock? There was a kernel bug that would cause failure to read the hardware clock on the following dates: March 1st, 2nd and 3rd. May, July, October, December 1st. Additionally, if the device was off or suspended across the beginning of a month, you might have seen it lose or gain a day. Behaviour during January was undefined. All of this because the hardware clock was one month behind: https://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009147.html I don't which distributions ship a kernel with this bug fixed. I'm also still looking for someone with a GTA01 to confirm that the bug also exists with the pcf50606-rtc driver as well. 2) Several posts mentioned that GPS could only get the fix if date was correct, the requirements being within 1 sec precision. That's only when feeding the GPS with data to speed up getting a fix. Unassisted GPS works fine with incorrect date and time. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Hi Fernando, On Thu, 2009-03-12 at 22:19 +0100, Fernando Martins wrote: Hi, 1) I got the date reset to 1970 a few times. I was not paying attention but I guess this happens when battery is removed, i.e., there's no battery specific for the clock? 2) Several posts mentioned that GPS could only get the fix if date was correct, the requirements being within 1 sec precision. However, with the date/time completely messed up, GPS is getting the fix anyway (and it's fairly fast, 1 min or so). So, what's up? I'm using SHR unstable from January. Is the GPS driver (?) being to ignore dates before FR production, or something else? There is no need for the clock to be correct to get a fix, however if you want to use AGPS, the time has to be accurate in order to know where the satelites are a what time. I hope the other questions are answwered by someone else... ;-) 3) While using tangoGPS and I enter a building, when I come out, a fix is not gotten until I reboot FR. Is this a known issue? any quicker workaround than rebooting? 4) How can I avoid going into suspend mode? (alternatively, are Power Mng settings working in recent SHR testing?) Regards and TIA, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Kind regards, Ed ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date and GPS related questions
Fernando Martins wrote: 1) I got the date reset to 1970 a few times. I was not paying attention but I guess this happens when battery is removed, i.e., there's no battery specific for the clock? There is a backup battery. Make sure that the system time is being saved to the hardware clock, e.g. hwclock --utc --systohc. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
date and GPS related questions
Hi, 1) I got the date reset to 1970 a few times. I was not paying attention but I guess this happens when battery is removed, i.e., there's no battery specific for the clock? 2) Several posts mentioned that GPS could only get the fix if date was correct, the requirements being within 1 sec precision. However, with the date/time completely messed up, GPS is getting the fix anyway (and it's fairly fast, 1 min or so). So, what's up? I'm using SHR unstable from January. Is the GPS driver (?) being to ignore dates before FR production, or something else? 3) While using tangoGPS and I enter a building, when I come out, a fix is not gotten until I reboot FR. Is this a known issue? any quicker workaround than rebooting? 4) How can I avoid going into suspend mode? (alternatively, are Power Mng settings working in recent SHR testing?) Regards and TIA, Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
