An interesting idea would be to acquire a fix, then bring the phone under cover, so it loses the fix, then bring it back in the open and see how long it will take to reacquire the fix.
On 7/7/08, Kai Römer <[EMAIL PROTECTED]> wrote: > Hi Al, > If you need testers, please contact me. I have several gta02v5 > available and can do tests in Germany Munich. > > thanks > Kai > > 2008/7/7 Al Johnson <[EMAIL PROTECTED]>: >> I'm not saying there isn't an antenna issue, but that we may be able to >> mitigate the effects on startup time. >> >> On Monday 07 July 2008, Kai Römer wrote: >>> Hi Al, >>> >>> Sounds really convincing, but how do you explain the constantly fast >>> fix via external antenna then. I really think its an antenna issue. >>> >>> Also the difference of the GPGSV values support this idea. >>> >>> Tomorrow evening i will ask a specialist to check the antenna signal >>> qualities. Maybe a cable is broken or there is a short circuit on the >>> main board. >>> >>> I ll report about the results. >>> >>> CU Kai >>> >>> 2008/7/6 Al Johnson <[EMAIL PROTECTED]>: >>> > From what I've seen on the wiki the version of the Antares4 on the >>> > GTA02 >>> > doesn't have the memory needed to store almanac and ephemeris, last >>> > known >>> > position or time. This means that every start is a true cold start, >>> > unlike every other reasonably modern GPS we're comparing it to. It >>> > starts >>> > up thinking the time is midnight on 30th November 1999 and seems to >>> > need >>> > a fair bit of decent signal to convince it otherwise, contributing to >>> > the >>> > long startup time. >>> > >>> > It looks like there is a way around this if you look at the >>> > documentation >>> > for the assist. The AID-INI message needn't be supplied by a remote >>> > server; we can generate it locally to provide the sort of data that's >>> > stored internally most of the time. At the very least we have a fair >>> > idea >>> > of the current time and date. We should also be able to store location, >>> > almanac and ephemeris when we shut down the GPS, and provide it at the >>> > next startup. We can also have a stab at current location, based >>> > perhaps >>> > on cell ID or wifi data as discussed by some of the other threads, or >>> > on >>> > user input. >>> > >>> > I'll try to patch together something to do this based on the example >>> > perl >>> > client and server code, and see how much difference it makes. >>> > >>> > On Friday 04 July 2008, Kai Römer wrote: >>> >> I can affirm this for 6 opemoko devices. i guess its an internal >>> >> antenna issue. as soon as you connect a external antenna to it works >>> >> like a charm. but fur me thats no solution. >>> >> >>> >> TTFF with external antenna (perfect condition): 40 to 60 seconds >>> >> TTFF with internal antenna AGPS (perfect condition): more than 1:20 >>> >> minute but not always. its like gambling. >>> >> >>> >> I guess a miss design of the internal antenna. >>> >> >>> >> CU Kai >>> >> >>> >> 2008/6/23 Peter Kraker <[EMAIL PROTECTED]>: >>> >> > This timings are insane unless you don't even have a valid almanac, >>> >> > which is rare. This doesn't look right. >>> >> > >>> >> > Yorick Matthys pravi: >>> >> > >>> >> > Marcus Bauer said: >>> >> > >>> >> > >>> >> > My experience with the Freerunner is ~12 minutes TTFF (time to first >>> >> > fix) without use of agps and ~4-8 minutes TTFF with agps from >>> >> > agps.u-blox.com using the software from openmoko. >>> >> > >>> >> > The Neo1973 (GTA01) had a TTFF without agps assistance of ~2 min. >>> >> > >>> >> > >>> >> > 12 minutes without AGPS and 4-8min with AGPS?? >>> >> > I hope there was a thunderstorm inside the basement where you tested >>> >> > this... >>> >> > >>> >> > :) >>> >> > >>> >> > Seriously, these just don't seem realistic. >>> >> > Compare them for example with some other devices from 2003: >>> >> > http://www.pocketgpsworld.com/ttffcomparisons.php. >>> >> > Or from ublox: http://www.u-blox.com/technology/assistnow/ (table at >>> >> > the bottom of the page) >>> >> > >>> >> > Surely there must be something wrong with your >>> >> > software/settings/hardware/environment... >>> >> > (or maybe they still have a lot of work to do on the GPS :)) >>> >> > >>> >> > y >> >> >> _______________________________________________ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Sent from Gmail for mobile | mobile.google.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community