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
-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
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
-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
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
-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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
