Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Tuesday August 5, [EMAIL PROTECTED] wrote: For a bit more consistency of timing, less manual intervention, and enough readings to get an idea of the run to run variation in that location, can I suggest a script? It could do with a timeout when waiting for a fix since with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly forever in some locations! Thanks for the script. After wondering for a while why it didn't work at all for me, I added stty min 1 /dev/ttySAC1 because either frameworkd in FSO or openmoko-agpsui did an stty min 0 /dev/ttySAC1 and that caused grep to exit immediately. Anyway, I haven't let it run completely yet, but the first result is d i time 0 0 real 9m 52.15s Yes, nearly 10 minutes. This is indoors, but I have had problems getting a GPS fix everywhere, inside, outside, in a car, in the park. Once it fixes it tracks OK (though it doesn't recover from going into a shopping complex and coming out again). It seems a lot like the originally reported problem, but this is with a kernel that has the fix and the magic sysfs files: Linux om-gta02 2.6.24 #1 PREEMPT Tue Jul 29 01:19:38 UTC 2008 armv4tl unknown I have the wireless going, but GSM is possibly turned off as I killed frameworkd to make sure it wasn't touching the GPS. I know someone who I trust to solder the capacitor - should I try that (if I can get hold of him)? Another result just came in: d i time 0 0 real 9m 52.15s 0 1 real 8m 29.79s These numbers are actually pretty good. openmoko-agpsui was giving me 1000 or 2100 seconds! I decided to take out the SD card (and the SIM card) and try again. (just chat quietly among yourselves while we wait for the first result). d i time 0 0 real 5m 14.32s 0 1 real 2m 56.78s 1 0 real 5m 37.79s Well, that wasn't so bad. But still not what I hoped for. I'm wondering if I got a lemon :-( NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Al Johnson wrote: | | For a bit more consistency of timing, less manual intervention, and enough | readings to get an idea of the run to run variation in that location, can I | suggest a script? It could do with a timeout when waiting for a fix since | with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly | forever in some locations! | | I was just about to write a similar script when I saw yours hit my | inbox... other than a couple of assumptions, I like yours better than | what I had in mind These are really interesting, thanks. | d i min / avg / max | 0 0 35.20/ 55.33/144.30 === | 0 1 37.39/ 77.76/315.76 | 3 0 36.07/ 42.07/ 47.82 === | 3 1 97.46/173.09/359.69 These relative numbers are a bit counterintuitive... it might be worth trying it again from a very cold boot but with the script for DRIVESTRENGTH in 3 2 1 0 and seeing if the bias to a worse max moves accordingly. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZSEYACgkQOjLpvpq7dMqZ0wCfUXoX3HMgYVcZOTehrASDkowr QicAnR5AVWf4MqqjdtMH7Kg8qbtLnvrl =nGv9 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Al Johnson wrote: | | For a bit more consistency of timing, less manual intervention, and enough | readings to get an idea of the run to run variation in that location, can I | suggest a script? It could do with a timeout when waiting for a fix since | with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly | forever in some locations! | | I was just about to write a similar script when I saw yours hit my | inbox... other than a couple of assumptions, I like yours better than | what I had in mind These are really interesting, thanks. | d i min / avg / max | 0 0 35.20/ 55.33/144.30 === | 0 1 37.39/ 77.76/315.76 | 3 0 36.07/ 42.07/ 47.82 === | 3 1 97.46/173.09/359.69 These relative numbers are a bit counterintuitive... it might be worth trying it again from a very cold boot but with the script for DRIVESTRENGTH in 3 2 1 0 and seeing if the bias to a worse max moves accordingly. - -Andy Hey Andy, I started a draft of a wiki page here http://wiki.openmoko.org/wiki/Freerunner_GPS_Software_Fix_TTFF_Measurement_Test to describe the test and to collect the results. Can you please add the line you suggest to the script? Thanks, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | I started a draft of a wiki page here | http://wiki.openmoko.org/wiki/Freerunner_GPS_Software_Fix_TTFF_Measurement_Test | to describe the test and to collect the results. Can you please add the | line you suggest to the script? I started editing that page but I don't know what we're trying to do with asking for mass data collection. I think it's OK to get a few results from this script and we get a clear idea, that and Stacy's work yesterday anyway put a limit on how bad the situation is with SD Card loaded: it's not that bad. People don't need to nuke their machine and rootfs two different ways, all they need is current kernel and they can turn the various changes on and off with the script. Plus, it is dangerous to go on just updating kernel partition by hand, people need to use kernel packages so their modules get updated too. The line in the script I mentioned is just something to try to see if there is a bias against the first test run, it changes an existing line there which is otherwise OK. I guess results from this script get skewed because of this sticky behaviour that the GPS chip can apparently remember things between power cycling. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZT2UACgkQOjLpvpq7dMp+pwCeJl72T8+joEjVYaGkelFtxTFl nPcAniia59IJr/l5C5HIJYY/IQZ3ypSL =DtXQ -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Wednesday 06 August 2008, Andy Green wrote: | d i min / avg / max | 0 0 35.20/ 55.33/144.30 === | 0 1 37.39/ 77.76/315.76 | | 3 0 36.07/ 42.07/ 47.82 === | 3 1 97.46/173.09/359.69 These relative numbers are a bit counterintuitive... it might be worth trying it again from a very cold boot but with the script From experience writing the script I think they look within the normal range of variation for a FR sitting near a window, and that if you increased PASSES the stats for all of the IDLECLK=0 runs would look the same if the card wasn't being exercised. I got to see a lot of such apparently counterintuitive results before I forced access to the card after writing the sysfs entries! From the same location some runs have a best ttff of ~150s while others are consistent at around 35-40s. Some start with good ttff, go through a period of poor ttff then back to good again. This would be more visible if people posted the raw results rather than the statistics. I suspect from a couple of observations that a GSM register may make ttff longer, but I don't have any data to back that up - it may just have been unlucky. Any ideas on how GSM status could be factored in? I suppose I should post some results too. Note the 2 results where there seems to have been a GPRMC result sitting in a serial buffer or something. d i time 0 0 real 2m 20.77s 0 1 real 6m 5.84s 1 0 real 2m 7.67s 1 1 real 3m 6.97s 2 0 real 1m 19.33s 2 1 real 9m 59.40s 3 0 real 0m 49.44s 3 1 real 1h 15m 34s 0 0 real 2m 6.22s 0 1 real 6m 25.13s 1 0 real 0m 58.47s 1 1 real 4m 45.95s 2 0 real 2m 10.15s 2 1 real 5m 55.50s 3 0 real 1m 24.57s 3 1 real 54m 27.04s 0 0 real 2m 14.25s 0 1 real 5m 49.14s 1 0 real 0m 40.93s 1 1 real 4m 54.68s 2 0 real 0m 55.83s 2 1 real 5m 39.02s 3 0 real 0m 39.20s 3 1 real 7m 32.77s 0 0 real 0m 46.20s 0 1 real 3m 6.79s 1 0 real 0m 38.62s 1 1 real 1m 20.72s 2 0 real 0m 48.52s 2 1 real 4m 4.87s 3 0 real 1m 3.03s 3 1 real 5m 56.27s 0 0 real 0m 53.03s 0 1 real 2m 8.48s 1 0 real 2m 40.71s 1 1 real 1m 57.13s 2 0 real 2m 1.89s 2 1 real 2m 59.68s 3 0 real 0m 57.95s 3 1 real 4m 41.03s 0 0 real 0m 42.63s 0 1 real 2m 10.56s 1 0 real 0m 46.22s 1 1 real 0m 0.14s 2 0 real 0m 48.24s 2 1 real 5m 40.03s 3 0 real 0m 56.11s 3 1 real 9m 16.78s 0 0 real 0m 38.74s 0 1 real 1m 3.09s 1 0 real 0m 49.23s 1 1 real 0m 0.14s 2 0 real 0m 48.09s 2 1 real 2m 47.54s 3 0 real 0m 53.33s 3 1 real 9m 18.26s 0 0 real 0m 40.45s 0 1 real 2m 10.75s 1 0 real 0m 46.27s 1 1 real 3m 10.67s 2 0 real 0m 48.13s 2 1 real 3m 24.71s 3 0 real 0m 37.41s 3 1 real 10m 9.89s 0 0 real 0m 39.93s 0 1 real 1m 9.94s 1 0 real 0m 39.97s 1 1 real 2m 2.57s 2 0 real 0m 47.56s 2 1 real 3m 36.03s 3 0 real 0m 43.44s 3 1 real 6m 16.24s 0 0 real 2m 1.56s 0 1 real 3m 13.48s 1 0 real 0m 40.60s 1 1 real 2m 37.83s 2 0 real 0m 39.71s 2 1 real 2m 31.22s 3 0 real 0m 51.98s 3 1 real 6m 3.22s ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | On Wednesday 06 August 2008, Andy Green wrote: | | d i min / avg / max | | 0 0 35.20/ 55.33/144.30 === | | 0 1 37.39/ 77.76/315.76 | | | | 3 0 36.07/ 42.07/ 47.82 === | | 3 1 97.46/173.09/359.69 | | These relative numbers are a bit counterintuitive... it might be worth | trying it again from a very cold boot but with the script | | From experience writing the script I think they look within the normal range | of variation for a FR sitting near a window, and that if you increased PASSES | the stats for all of the IDLECLK=0 runs would look the same if the card | wasn't being exercised. I got to see a lot of such apparently | counterintuitive results before I forced access to the card after writing the | sysfs entries! From the same location some runs have a best ttff of ~150s I guess it means there are random accesses to SD Card in background. | I suspect from a couple of observations that a GSM register may make ttff | longer, but I don't have any data to back that up - it may just have been | unlucky. Any ideas on how GSM status could be factored in? Make a call and whistle is what I would do. But there is pretty much no latitude (ha) for meddling with what GSM side is going to do. | I suppose I should post some results too. Note the 2 results where there seems | to have been a GPRMC result sitting in a serial buffer or something. I guess it won't hurt to sleep 3 after turning it off before turning it back on. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZeToACgkQOjLpvpq7dMrO4QCeLjWfOXDMVY+7ZgG0EEI8Ewv/ sw4An3067DpkKz4E1LEsGFDh4bz2Z19r =xr+V -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Wednesday 06 August 2008, Andy Green wrote: | sysfs entries! From the same location some runs have a best ttff of ~150s I guess it means there are random accesses to SD Card in background. Perhaps, but I think I saw similar variation from the same location with the SD card removed when the link was first discovered. It may be the GSM, the constellation, or a neighbour using some crappy device that spews interference too. I might try a few runs with the SD removed to get a baseline for variation not attributable to the SD. | I suspect from a couple of observations that a GSM register may make ttff | longer, but I don't have any data to back that up - it may just have been | unlucky. Any ideas on how GSM status could be factored in? Make a call and whistle is what I would do. But there is pretty much no latitude (ha) for meddling with what GSM side is going to do. I was thinking more of recording when the reregisters were taking place or something. I know we don't have control over it, but I would like to rule it in or out as a cause of interference. I wouldn't want you scratching your head over further ways to reduce interference from the SD if GSM or some other source was now the dominant factor. | I suppose I should post some results too. Note the 2 results where there seems | to have been a GPRMC result sitting in a serial buffer or something. I guess it won't hurt to sleep 3 after turning it off before turning it back on. It already sleeps 20 after switch off as an attempt to get a properly cold start, but I don't know if it's long enough for the ublox chip to lose its memory. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Andy Green wrote: These are really interesting, thanks. | d i min / avg / max | 0 0 35.20/ 55.33/144.30 === | 0 1 37.39/ 77.76/315.76 | 3 0 36.07/ 42.07/ 47.82 === | 3 1 97.46/173.09/359.69 These relative numbers are a bit counterintuitive... it might be worth trying it again from a very cold boot but with the script for DRIVESTRENGTH in 3 2 1 0 and seeing if the bias to a worse max moves accordingly. So I broke the first rule of testing, and changed a bunch of things and then reran the test. First, instead of doing a power off/power on of the GPS, I used Andy's handy dandy UBX construction kit to issue a cold restart to the chip. If I understand the documentation correctly, this will wipe everything from the GPS's memory and do a hardware reset; that should take care of any concerns about residual fix information surviving a power cycle. Second, as Andy suggested, I reversed the order of DRIVESRENGTH values. And finally, I left WLAN enabled (mainly because I did a reboot of the FreeRunner and then ran the test). Here are the results: d i min / avg / max 0 0 36.41/ 51.53/ 84.83 0 1 40.41/ 59.13/128.33 1 0 36.98/ 45.45/ 51.03 1 1 40.94/ 63.74/111.77 2 0 31.43/ 45.08/ 52.31 2 1 32.57/ 57.50/ 76.06 3 0 32.10/ 43.75/ 57.98 3 1 40.34/ 61.71/ 96.67 BTW, the magic incantation to generate the cold restart is ubxcs b5 62 06 04 04 00 ff ff 00 00 coldstart.ubx Then to issue the command, cat coldstart.ubx /dev/ttySAC1 grep '$GPTXT,01,01,02,u-blox' -q -m 1 /dev/ttySAC1 The grep command looks for the powerup message from the GPS to make sure that there is no RMC sentence sitting in a buffer somewhere. -stacy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
On Tuesday 05 August 2008, Michael Shiloh wrote:
Agreed. I've been trying to gather that information for the past little
while. It's proven rather elusive, and I didn't want more people to try
the hardware fix until we really understand what the software fix can
do, so I thought I'd better ask for the test ASAP, and then continue
working on the info.
Andy, can you provide links to two kernels: one before, and one after
the fix?
IIRC the first kernel to have the sd_drive and sd_idleclk fixes in was from
20080723, but this seems to have been removed from the buildhost now. Or did
you mean the fix to slow down the SD clock while GPS is enabled that was
added Friday? In either case I think t can be configured to behave as it did
before the fix by echoing the right variables into /sys/wherever and
accessing the SD card.
The test will consist something like
cat /dev/ttySAC1 | grep GPGGA
and then time it until it gets a fix. I'll be more specific.
For a bit more consistency of timing, less manual intervention, and enough
readings to get an idea of the run to run variation in that location, can I
suggest a script? It could do with a timeout when waiting for a fix since
with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly
forever in some locations!
#!/bin/sh
PASSES=10
TTFF=
get_ttf() {
echo 1 /sys/bus/platform/devices/neo1973-pm-gps.0/pwron
TTFF=`(time grep GPRMC,[0-9\.]*,A, -m 1 /dev/ttySAC1) 21 |grep real`
echo 0 /sys/bus/platform/devices/neo1973-pm-gps.0/pwron
echo $DRIVESTRENGTH $IDLECLK $TTFF
sleep 20
}
echo d i time
until [ $PASSES -eq 0 ]
do
for DRIVESTRENGTH in 0 1 2 3
do
for IDLECLK in 0 1
do
#echo testing drive strength $DRIVESTRENGTH and clock idle $IDLECLK
echo $DRIVESTRENGTH /sys/module/glamo_mci/parameters/sd_drive
echo $IDLECLK /sys/module/glamo_mci/parameters/sd_idleclk
touch /media/card/gpstest
sync
get_ttf
done
done
PASSES=$(($PASSES-1))
done
Perhaps I'll set up a wiki page for this.
Michael
Josh Thompson wrote:
Could we get a link to some image files to use for this testing? I'm not
quite sure when Andy's fix made it in the kernel. It would also help
standardize the tests if we all use the same images.
Josh
On Mon August 4 2008 7:29:17 pm Michael Shiloh wrote:
Before we conclude that the hardware fix is required, we'd really like
to gather a lot of statistics from you about the behavior of the
software fix. We have been able to test in only a limited number of
locations, and a limited number of phones.
We'd like to ask you to run some tests and report back the TTFF in each
case:
1. Prior to Andy's software fix
1a. Without SD card
1b. With SD card
2. Using Andy's software fix
2a. Without SD card
2b. With SD card
Preferably run this test in multiple locations.
Results should be reported on a wiki page, which should include your
location (so we can assess other influences e.g. satellite elevation and
weather conditions)
Thanks,
Michael
___
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
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Hi all, Just to let you know, I tried the above script and am not quite sure the gpsr is completely reset ( e.g. a real cold start occurs ) . However, since I DID apply the HW cap fix that might also be a reason for the results... In short, no matter which settings are used I get a TTFF of 38-42seconds, repeatably, with only a few seconds more when constant SD-Card activity is provoked. It was on a rooftop, clear sunny sky, about 1/5 of the sky/horizon covered by an appartment, but results are consistent with my observations during geocaching in any terrain, be it cities or woods. Let me know if I can be of further assistance getting data, ( and of course this report of great gpsr performance should not lead anyone to try out the HW mod until final approval by OM ;-) ! ) Stefan ### Kernel version Linux om-gta02 2.6.24 #1 PREEMPT Sat Aug 2 00:43:10 CEST 2008 armv4tl unknown ### ROOT ( opkg upgraded today ) 200807160132 Tag Name: VERSION: 27cd6d55ab393f51eaf4811418a4346669f53c2a Branch: org.openmoko.dev Build Host: buildhost.openmoko.org Time Stamp: Wed, 16 Jul 2008 01:34:56 +0200 ### Bootloader # u-boot /dev/mtdblock0: Neo1973 Bootloader U-Boot 1.3.2-moko12 # u-boot /dev/mtdblock1: Neo1973 Bootloader U-Boot 1.3.2+gitr18+64eb10cab8055084ae25ea4e73b66dd03cc1a0cb ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
When you are collecting data you might also keep in mind conditions vary a lot according to the current satellite constellation. You should include the count of satellites in view and the pdop number with your results data. You can do some planning to make sure you don't run one test when conditions are good and then another tomorrow when conditions are bad by using mission planning software. See my comments here: http://wildsong.biz/index.php?title=GPS_mission_planning_software including a link to a Windows program that is available from Trimble for free. (If anyone knows of an open source planning program do let me know!) Brian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Al Johnson wrote:
For a bit more consistency of timing, less manual intervention, and enough
readings to get an idea of the run to run variation in that location, can I
suggest a script? It could do with a timeout when waiting for a fix since
with deivestrength 3 and idleclk 1 this can take a _very_ long time, possibly
forever in some locations!
I was just about to write a similar script when I saw yours hit my
inbox... other than a couple of assumptions, I like yours better than
what I had in mind
#!/bin/sh
PASSES=10
TTFF=
get_ttf() {
echo 1 /sys/bus/platform/devices/neo1973-pm-gps.0/pwron
TTFF=`(time grep GPRMC,[0-9\.]*,A, -m 1 /dev/ttySAC1) 21 |grep real`
echo 0 /sys/bus/platform/devices/neo1973-pm-gps.0/pwron
echo $DRIVESTRENGTH $IDLECLK $TTFF
sleep 20
}
You assume that the gps is already off, you should either check that the
gps is off or just turn it off
echo d i time
until [ $PASSES -eq 0 ]
do
for DRIVESTRENGTH in 0 1 2 3
do
for IDLECLK in 0 1
do
#echo testing drive strength $DRIVESTRENGTH and clock idle $IDLECLK
echo $DRIVESTRENGTH /sys/module/glamo_mci/parameters/sd_drive
echo $IDLECLK /sys/module/glamo_mci/parameters/sd_idleclk
You assume the mount point of the SDCard. Probably a reasonable
assumption, but I mount mine as /home
touch /media/card/gpstest
sync
get_ttf
done
done
PASSES=$(($PASSES-1))
done
should likely set drivestrength and idleclk back to default values.
And the results:
d i min / avg / max
0 0 35.20/ 55.33/144.30
0 1 37.39/ 77.76/315.76
1 0 33.92/ 38.90/ 41.78
1 1 38.70/ 84.46/151.32
2 0 37.66/ 47.78/108.26
2 1 45.10/120.80/207.08
3 0 36.07/ 42.07/ 47.82
3 1 97.46/173.09/359.69
-stacy
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
GPS rework: Please test and report on software fix prior to attempting any hardware fix
Before we conclude that the hardware fix is required, we'd really like to gather a lot of statistics from you about the behavior of the software fix. We have been able to test in only a limited number of locations, and a limited number of phones. We'd like to ask you to run some tests and report back the TTFF in each case: 1. Prior to Andy's software fix 1a. Without SD card 1b. With SD card 2. Using Andy's software fix 2a. Without SD card 2b. With SD card Preferably run this test in multiple locations. Results should be reported on a wiki page, which should include your location (so we can assess other influences e.g. satellite elevation and weather conditions) Thanks, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Could we get a link to some image files to use for this testing? I'm not quite sure when Andy's fix made it in the kernel. It would also help standardize the tests if we all use the same images. Josh On Mon August 4 2008 7:29:17 pm Michael Shiloh wrote: Before we conclude that the hardware fix is required, we'd really like to gather a lot of statistics from you about the behavior of the software fix. We have been able to test in only a limited number of locations, and a limited number of phones. We'd like to ask you to run some tests and report back the TTFF in each case: 1. Prior to Andy's software fix 1a. Without SD card 1b. With SD card 2. Using Andy's software fix 2a. Without SD card 2b. With SD card Preferably run this test in multiple locations. Results should be reported on a wiki page, which should include your location (so we can assess other influences e.g. satellite elevation and weather conditions) Thanks, Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Agreed. I've been trying to gather that information for the past little while. It's proven rather elusive, and I didn't want more people to try the hardware fix until we really understand what the software fix can do, so I thought I'd better ask for the test ASAP, and then continue working on the info. Andy, can you provide links to two kernels: one before, and one after the fix? The test will consist something like cat /dev/ttySAC1 | grep GPGGA and then time it until it gets a fix. I'll be more specific. Perhaps I'll set up a wiki page for this. Michael Josh Thompson wrote: Could we get a link to some image files to use for this testing? I'm not quite sure when Andy's fix made it in the kernel. It would also help standardize the tests if we all use the same images. Josh On Mon August 4 2008 7:29:17 pm Michael Shiloh wrote: Before we conclude that the hardware fix is required, we'd really like to gather a lot of statistics from you about the behavior of the software fix. We have been able to test in only a limited number of locations, and a limited number of phones. We'd like to ask you to run some tests and report back the TTFF in each case: 1. Prior to Andy's software fix 1a. Without SD card 1b. With SD card 2. Using Andy's software fix 2a. Without SD card 2b. With SD card Preferably run this test in multiple locations. Results should be reported on a wiki page, which should include your location (so we can assess other influences e.g. satellite elevation and weather conditions) Thanks, Michael ___ 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
Re: GPS rework: Please test and report on software fix prior to attempting any hardware fix
Agreed. Would be a whole lot easier on everyone if a uboot, kernel(s) and rootfs were provided along with test scripts and a procedures document to follow. On Aug 4, 2008, at 5:02 PM, Josh Thompson wrote: Could we get a link to some image files to use for this testing? I'm not quite sure when Andy's fix made it in the kernel. It would also help standardize the tests if we all use the same images. Josh On Mon August 4 2008 7:29:17 pm Michael Shiloh wrote: Before we conclude that the hardware fix is required, we'd really like to gather a lot of statistics from you about the behavior of the software fix. We have been able to test in only a limited number of locations, and a limited number of phones. We'd like to ask you to run some tests and report back the TTFF in each case: 1. Prior to Andy's software fix 1a. Without SD card 1b. With SD card 2. Using Andy's software fix 2a. Without SD card 2b. With SD card Preferably run this test in multiple locations. Results should be reported on a wiki page, which should include your location (so we can assess other influences e.g. satellite elevation and weather conditions) Thanks, Michael ___ 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
