Nabble - GPS

new gps report

2009-12-05T00:05:04Z

Remote: 85.23.163.220:34394

[LD-4W]
type = device
chipset = SiRF-3
date = 5 Dec 2009
location = Oulu, FI, 65N 25E
model = LD-4W
noconfigure = yes
notes = I first tried gpsd package from Ubuntu 9.10, which broke device on probe. Luckily this device has 'reset' function by pressing power button for 10 sec. Then I recompiled gpsd with only support for Generic NMEA and SiRF binary and with fixed speed (--enable-fixed-port-speed=9600). Now device works in sirf mode, and doesn't break on probe.
packaging = mouse
rating = fair
submitter = jussi.kivilinna@...
techdoc = http://europe.nokia.com/find-products/accessories/all-accessories/navigation/gps-modules/ld-4w
tested = 2.39
vendor = Nokia

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

sample.bin (15K) Download Attachment

From forum: GPSd - Dev

Re: [esr at BerliOS] [Gpsd-commit-watch] r6710 - trunk

2009-12-04T22:49:38Z

Greg Troxel <gdt@...>:
> > 1. Once on the bu-303 atltitude calculation under i386 only.
>
> no, also on NetBSD/amd64, but differently.

Noted in the TODO.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

Re: sin/cos issues

2009-12-04T22:48:27Z

Michael R. Davis <mrdvt92@...>:
> We do not need to re-invent the wheel. The official US Government function for calculating earth distances is called INVERSE. http://www.ngs.noaa.gov/TOOLS/Inv_Fwd/Inv_Fwd.html => http://www.ngs.noaa.gov/PC_PROD/Inv_Fwd/source/
>
> This public domain Fortran code has all of the algorithm switching logic built in.

I think we have a winner. We're not likely to do better on technical grounds,
and I like the idea of being able to document that we're using the same
algorithm the U.S. Government's geodesists do.

Somebody with domain expertise (Chris?, Hakan?) please step up to the task
of finding a C implementation or translating the Fortran for our use. I'm
putting this one in the TODO.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: regression failures

2009-12-04T22:41:21Z

Greg Troxel <gdt@...>:

>
> netbsd-5/sparc64 is down to two failures:
>
> bu303-nofix has different altitudes from the checked in "right
> answer". It matches what I get on netbsd-5/amd64. I also get a
> failure on this test on linux/i386, but with a different answer.
>
> superstar2 output is totally missing. Running just that by hand, I
> think gpsd is failing to ever detect a packet in the dump. Almost
> surely this is an endian issue. Has anyone else run on a big-endian
> machine? Fire up those old PPC macs!
>
> The output is too big for the list, and is at:
>
> http://www.lexort.com/gpsd/

I'm adding this to TODO so it won't get lost.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

?Suppress “GPS device” string as in KML?

2009-12-04T17:31:19Z

I’m using version 1.3.6 to convert GPX files to KML with the default settings. The start of the resulting KML file looks like:
<?xml version="1.0" encoding="UTF-8" ?>
- <kml xmlns="http://earth.google.com/kml/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
- <Document>
<name>GPS device</name>

Is there an option to tell GPSBabel to leave the <Document><name> element blank in the KML output file? I looked through the documentation and I did not see any option for this purpose.

I have an app that uses these KML files to produce a map. Anything in the <Document><name> element is displayed on the map as a caption. Right now the phrase “GPS device” is showing up on my map as a caption.

For now I will write more php to read the kml file, erase this bit, and re-write the file. But if I could tell GPSBabel to just leave the <Document><name> element blank, then my app would run faster.

From forum: GPSBabel - General

Timestamps on fix data

2009-12-04T16:58:59Z

I'm using gpsd with a Trimble Resolution SMT starter kit. If I connect
to gpsd and send "w+" to get raw data, the "O" type messages returned
never have a valid timestamp. The "Y" type messages do have a valid
timestamp. Is this normal? Also, if I turn off raw mode and send "d"
to gpsd, I usually get "GPSD,D=?" back in response. However, it does
sometimes return a date/time if I keep doing the "d" command. Is this
also normal or is gpsd acting funny with Trimble/TSIP?

David
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

From forum: GPSd - Users

Re: sin/cos issues

2009-12-04T15:48:33Z

GPSD Folks,

> For such small distances it should be much better to just
> use Pythagoras directly, i.e. evaluate

We do not need to re-invent the wheel. The official US Government function for calculating earth distances is called INVERSE. http://www.ngs.noaa.gov/TOOLS/Inv_Fwd/Inv_Fwd.html => http://www.ngs.noaa.gov/PC_PROD/Inv_Fwd/source/

This public domain Fortran code has all of the algorithm switching logic built in.

Mike

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: regression failures

2009-12-04T15:34:25Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have not been following this issue closely, so I apologise if I'm
misinterpreting something here. That said:

Matthias Urlichs wrote:
> On Fr, 2009-12-04 at 12:08 -0500, Greg Troxel wrote:
>> I thought that earth_distance computed the difference between two
>> lat/lon pairs on the surface, and was used to find out how different
>> two fixes were.
>
> Bah. That has slipped my mind. Sorry.

The working principle however, is roughly the same as Matthias
illustrated in his previous post, i.e., one is measuring the length of
an arc of great radius (~6000km) subtending a very small angle.

There is an inherent lack of precision in this problem, which appears
to be what the regressions tests are showing.

Wouldn't it be possible to work on the regression tests so that they
detect this artifact and behave accordingly, rather than giving a
straight fail? e.g., what about if one had a different set of
regression results for each different architecture?

Again, I apologise if I'm missing the point by a mile (I blame it on
my own kind of instability :).

Regards,
Diego Berge.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksZnIEACgkQmlKEtSWrbj0HTQCgiJWhFbn+MbyKMCFCusUw2Gft
xqgAoIWOmEsqhIytaEXfbS5Sb+IgHY1p
=uoTt
-----END PGP SIGNATURE-----
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: sin/cos issues

2009-12-04T15:09:35Z

I have not tested the code itself, this is just 'theoretical'
considerations:

sin/cos are not at fault, but the algortihm as such for small distances.

Assume a distance b of 1 dm, then the 'normalized' dot product called a
in the routine will have a value of approximately 1-b^2/R^2, R being the
radius. I.e. 1 - 2.46e-16, where 2.46e-16 is close to the epsilon of a
double (2.22e-16).

For such small distances it should be much better to just use Pythagoras
directly, i.e. evaluate

R = CalcRad((lat1+lat2)/2);
d = sqrt((x1-x2)*(x1-x2) + (y1-y2)*(y1-y2) + (z1-z2)*(z1-z2));
if (d < 10000) // comment on this value below
return d * (1 + (d/R)*(d/R) / 24);

a similar issue appears for points on opposite sides of the globe, where a
is ~= -1. acos(a) should then be close to pi and the result about 20000
km, so the loss of accuracy of a dm should not matter. but it makes no
sense to return nans, rather do

if (a < -1)
a = -1;

before the final calculation.

The simple use a Pythagoras above sort of defies the fact the the earth is
not flat. If b is the distance along the surface and we call d the
straight distance between the two points, and theta the angle between
them (where a = cos (theta), approximately), we have:

b = R * theta
d = 2 * R * sin(theta / 2)

since sin x = x - x^2/3! + x^5/5! + O(x^7)

and with theta = b/R we get

d = 2 * R * ((b/2R) - (b/2R)^2/3! + (b/2R)^5/5! + ...)

d = b - b^3/(2R)^2/3! + b^5/(2R)^4/5! + ...

now, to solve for b, set b=d for the correction terms:

b = d + d^3/(2R)^2/3! + d^5/(2R)^4/5! - ...

If we do not want an error larger than say 1e-8 in b (relative to d), then
look for

d^3/(2R)^2/3!/d = 1e-8 ==> d = 3.1 km

for the next term:

d^5/(2R)^4/5!/d = 1e-8 ==> d = 421 km

b = d + d^3/R*2*2*3*2*1 = d + 1/24 * d^3/R^2

So I opted for a 10 km cut and applying a first term correction. At d =
10 km, a = 0.9999987 so I think the original should work.

Of course, one could probably skip the correction altogether, as a
correction of 1e-8 on 10 km is just 1 mm... :-)

--

Some further notes:

with such a cut, the routine will certainly not be continous. would that
matter?

I wrote 'normalized' dot product in the above as it divides not by the
product of the two vector lengths, but some square of an 'average' of the
two.

It's late night here, factors of 2 and 3 may easily be wrong.

Cheers,
Håkan
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: [esr at BerliOS] [Gpsd-commit-watch] r6710 - trunk

2009-12-04T14:36:57Z

"Eric S. Raymond" <esr@...> writes:

> 1. Once on the bu-303 atltitude calculation under i386 only.

no, also on NetBSD/amd64, but differently.

> 2. Once on the Navcom test file due to the sin/cos instability.

More like "due to a numerically unstable earth_distance algorithm". I
have not seen any evidence that sin/cos is broken.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: [esr at BerliOS] [Gpsd-commit-watch] r6710 - trunk

2009-12-04T13:59:12Z

Greg Troxel <gdt@...>:
> There have been a lot of changes in the last week, and regression tests
> have been failing enough to put us into state red according to the
> documented procedure, so it's hard to tell what's going on.

We just shipped. I fixed two of the port problems (the time-overflow ones)
last night, and added the others as known problems to the TODO list.

I expect your regression tests may currently break in two places:

1. Once on the bu-303 atltitude calculation under i386 only.

2. Once on the Navcom test file due to the sin/cos instability.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

new gps report

2009-12-04T13:45:11Z

Remote: 216.239.45.4:21209

[device]
type = device
model = device
packaging = mouse
submitter = nobody@...
techdoc = http://www.example.com/no-such-gps.html
vendor = fake

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

sample.bin (22 bytes) Download Attachment

From forum: GPSd - Dev

make regress status

2009-12-04T13:14:48Z

As of r6712, make check shows only the known failures:

netbsd-5/i386: bu303-nofix navcom
netbsd-5/amd64: bu303-nofix

and actually running on netbsd-5/i386 with an antaris 4 works.

in progress, will yell if unexpected trouble
netbsd-5/sparc64: bu303-nofix

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: sin/cos issues

2009-12-04T13:04:06Z

On Fri, Dec 4, 2009 at 10:37 AM, Eric S. Raymond <esr@...> wrote:
> Greg Troxel <gdt@...>:
>> Or, I could easily make test_trig.c. Perhaps that is better.
>
> Do it. Good idea.

http://arxiv.org/abs/cs.PL/0701192 (The pitfalls of verifying
floating-point computations)
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.8553
(Numerical Replication of Computer Simulations: Some Pitfalls and How
To Avoid Them)

A separate trig tester would be good. I tried to be very careful about
writing the float test so that all the intermediate results should be
precise even in IEEE754 - that will be basically impossible for trig.

A very cursory glance at citeseer and scholar didn't show a similar
sort of document oriented at verifying trig results and I'm drawing a
blank on finding regression test suites for space programs... anyone
got friends at NASA, ESA, CSA (et al.) who could tell us about their
test suites? IS-GPS-200 has very little to say about this other than
pi is defined as "3.1415926535898."

> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFLGVbOrfUW04Qh8RwRAjdWAJ9l4nk0xNPfKifHcddL4f5zrz8iGwCgpmEI
> JfUdhYZIUq2m0cFv4+AGEZ8=
> =Q5Ku
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Gpsd-dev mailing list
> Gpsd-dev@...
> https://lists.berlios.de/mailman/listinfo/gpsd-dev
>
>

--
GDB has a 'break' feature; why doesn't it have 'fix' too?
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

[esr at BerliOS] [Gpsd-commit-watch] r6710 - trunk

2009-12-04T12:48:58Z

So I presume

we are really really frozen, with changes only after list discussion

you expect people to svn up and run tests, and we can assess whether
to ship or not?

There have been a lot of changes in the last week, and regression tests
have been failing enough to put us into state red according to the
documented procedure, so it's hard to tell what's going on.

Author: esr
Date: 2009-12-04 21:45:44 +0100 (Fri, 04 Dec 2009)
New Revision: 6710

Modified:
trunk/configure.ac
Log:
Version bump. Time to ship 2.90.

Modified: trunk/configure.ac
===================================================================
--- trunk/configure.ac 2009-12-04 20:41:03 UTC (rev 6709)
+++ trunk/configure.ac 2009-12-04 20:45:44 UTC (rev 6710)
@@ -1,6 +1,6 @@
dnl $Id$
AC_INIT
-AM_INIT_AUTOMAKE(gpsd, 2.90dev)
+AM_INIT_AUTOMAKE(gpsd, 2.90)
dnl AC_PREFIX_PROGRAM(gcc)
AM_CONFIG_HEADER(gpsd_config.h)
AC_LANG([C])

_______________________________________________
Gpsd-commit-watch mailing list
Gpsd-commit-watch@...
https://lists.berlios.de/mailman/listinfo/gpsd-commit-watch

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: regression failures

2009-12-04T12:09:07Z

Matthias Urlichs <matthias@...> writes:

> On Fr, 2009-12-04 at 12:08 -0500, Greg Troxel wrote:
>> I thought that earth_distance computed the difference between two
>> lat/lon pairs on the surface, and was used to find out how different
>> two fixes were.
>
> Bah. That has slipped my mind. Sorry.
>
> Anyway, the comment in that function does say that the value for small
> distances _is_ numerically unstable and can even be mathematically
> impossible. Also, arccos magnifies numeric errors; for example,
> arccos(0.9999999999) has only four zeroes after the decimal point.

I didn't find that comment. But since we use it for small distances, we
should replace it with a stable algorithm.

This doesn't seem urgent, because minor differences in whether estimated
position erros are greater than motion don't seem that important.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-04T11:20:23Z

On Fr, 2009-12-04 at 12:08 -0500, Greg Troxel wrote:
> I thought that earth_distance computed the difference between two
> lat/lon pairs on the surface, and was used to find out how different
> two fixes were.

Bah. That has slipped my mind. Sorry.

Anyway, the comment in that function does say that the value for small
distances _is_ numerically unstable and can even be mathematically
impossible. Also, arccos magnifies numeric errors; for example,
arccos(0.9999999999) has only four zeroes after the decimal point.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: sin/cos issues

2009-12-04T10:37:02Z

Greg Troxel <gdt@...>:
> Or, I could easily make test_trig.c. Perhaps that is better.

Do it. Good idea.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-04T09:08:46Z

Matthias Urlichs <matthias@...> writes:

> On Fr, 2009-12-04 at 11:11 -0500, Greg Troxel wrote:
>> sin is sometimes different in the lowest order bit, more or less.
>>
>> For points that are very close, earth_distance computes distances
>> that
>> can be several % off (0.25 vs 0.21 or something like that) depending
>> on this tiny difference in sin().
>
> Is it? Consider how far away those satellites are, let's say 10^5
> meters. We're talking about a difference of 10^-3 meters or so. That's
> an error on the order of 10^-8.
>
> The bit in the sin output is 10^-15, if I remember correctly. Now add in
> a couple of numerically tricky calculations (think "two lines crossing
> at a very shallow angle" for an example of this sort of problem) and I'm
> not sure there's any real problem.

I thought that earth_distance computed the difference between two
lat/lon pairs on the surface, and was used to find out how different two
fixes were.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-04T09:01:24Z

On Fr, 2009-12-04 at 11:11 -0500, Greg Troxel wrote:
> sin is sometimes different in the lowest order bit, more or less.
>
> For points that are very close, earth_distance computes distances
> that
> can be several % off (0.25 vs 0.21 or something like that) depending
> on this tiny difference in sin().

Is it? Consider how far away those satellites are, let's say 10^5
meters. We're talking about a difference of 10^-3 meters or so. That's
an error on the order of 10^-8.

The bit in the sin output is 10^-15, if I remember correctly. Now add in
a couple of numerically tricky calculations (think "two lines crossing
at a very shallow angle" for an example of this sort of problem) and I'm
not sure there's any real problem.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: regression failures

2009-12-04T08:11:41Z

According to http://docs.sun.com/source/806-3568/ncg_math.html , 1 ULP
in double is about 2.220446e-16, which is just about the difference in
the sin outputs.

So as I see it:

sin is sometimes different in the lowest order bit, more or less.

For points that are very close, earth_distance computes distances that
can be several % off (0.25 vs 0.21 or something like that) depending
on this tiny difference in sin().

If that's true, the problem is poor numerical stability of
earth_distance, not the sin() implementation. It's not clear that
either of hte answers is correct.

It's very good to have found this - unless I'm confused all uses of
earth_distance may be getting the wrong answer.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-04T07:43:54Z

On Dec 4, 2009, at 9:01 AM, Greg Troxel wrote:

> Michael: How different are the results from sin and cos on various
> platforms?

I think the best thing to do is show some differences. I essentially
broke out all the calculations and printed them with %2.30f. Looking
at it, it appears that the difference comes around 1.*10e-15. We could
truncate the calculations but that would probably introduce other
errors.

< earth_distance(): x1Rad1 = 6352183.601540576666593551635742187500;
x1Rad2 = 0.213431703525181981628833227660; x1Rad3 =
1.041234054705739042745449296490; x1cos =
0.977309784626648858640862727043; x1sin =
0.863028273901615849972301930393;
---
> earth_distance(): x1Rad1 = 6352183.601540576666593551635742187500;
x1Rad2 = 0.213431703525181981628833227660; x1Rad3 =
1.041234054705739042745449296490; x1cos =
0.977309784626648858640862727043; x1sin =
0.863028273901615738949999467877;

< earth_distance(): x2Rad1 = 6352183.601475819945335388183593750000;
x2Rad2 = 0.213431705596529519564086285754; x2Rad3 =
1.041234055889366239000537461834; x2cos =
0.977309784187906482877394864772; x2sin =
0.863028274499531788954698185989;
---
> earth_distance(): x2Rad1 = 6352183.601475819945335388183593750000;
x2Rad2 = 0.213431705596529519564086285754; x2Rad3 =
1.041234055889366239000537461834; x2cos =
0.977309784187906482877394864772; x2sin =
0.863028274499531677932395723474;

< earth_distance(): y1Rad1 = 6352183.601540576666593551635742187500;
y1Rad2 = 0.213431703525181981628833227660; y1Rad3 =
1.041234054705739042745449296490; y1sin1 =
0.211814977924161845779238433352; y1sin2 =
0.863028273901615849972301930393;
---
> earth_distance(): y1Rad1 = 6352183.601540576666593551635742187500;
y1Rad2 = 0.213431703525181981628833227660; y1Rad3 =
1.041234054705739042745449296490; y1sin1 =
0.211814977924161845779238433352; y1sin2 =
0.863028273901615738949999467877;

< earth_distance(): y2Rad1 = 6352183.601475819945335388183593750000;
y2Rad2 = 0.213431705596529519564086285754; y2Rad3 =
1.041234055889366239000537461834; y2sin1 =
0.211814979948510062612854198960; y2sin2 =
0.863028274499531788954698185989;
---
> earth_distance(): y2Rad1 = 6352183.601475819945335388183593750000;
y2Rad2 = 0.213431705596529519564086285754; y2Rad3 =
1.041234055889366239000537461834; y2sin1 =
0.211814979948510062612854198960; y2sin2 =
0.863028274499531677932395723474;

< earth_distance(): z1Rad1 = 6352183.601540576666593551635742187500;
z1Rad2 = 1.041234054705739042745449296490; z1cos =
0.505155618048931054353545277991;
---
> earth_distance(): z1Rad1 = 6352183.601540576666593551635742187500;
z1Rad2 = 1.041234054705739042745449296490; z1cos =
0.505155618048931165375847740506;

< earth_distance(): x1 = 5357723.700667369179427623748779296875; x2 =
5357723.701919406652450561523437500000; y1 =
1161193.866297113010659813880920410156; y2 =
1161193.878187472000718116760253906250; z1 =
3208841.233196514658629894256591796
875; z2 = 3208841.226675023790448904037475585938; a =
0.999999999999999666933092612453
---
> earth_distance(): x1 = 5357723.700667368248105049133300781250; x2 =
5357723.701919406652450561523437500000; y1 = 11611
93.866297113010659813880920410156; y2 =
1161193.878187471767887473106384277344; z1 =
3208841.233196515589952468872070312
500; z2 = 3208841.226675023790448904037475585938; a =
0.999999999999999666933092612453

Sincerely,
Michael
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

From forum: GPSd - Dev

Re: sin/cos issues

2009-12-04T06:20:58Z

Or, I could easily make test_trig.c. Perhaps that is better.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

sin/cos issues

2009-12-04T06:19:55Z

OK to commit this? It makes test_float be more verbose, but also print
out some trig that we could compare to expected.

I ran this on netbsd-5 i386 and sparc64, and got the same results,
available at:

http://www.lexort.com/gpsd/

Index: test_float.c
===================================================================
--- test_float.c (revision 6694)
+++ test_float.c (working copy)
@@ -30,9 +30,10 @@
int main( void );
int test_single( void );
int test_double( void );
+int test_trig( void );

int main() {
- int i, j;
+ int i, j, k;

if ((i = test_single()))
printf("WARNING: Single-precision "
@@ -42,7 +43,12 @@
printf("WARNING: Double-precision "
"floating point math might be broken\n");

+ if ((k = test_trig()))
+ printf("WARNING: trig "
+ "floating point math might be broken\n");
+
i += j;
+ i += k;
if (i == 0)
printf("floating point math appears to work\n");
return i;
@@ -254,3 +260,30 @@
}
return 0;
}
+
+#include <math.h>
+
+#define Deg2Rad(x) ((x) * (2 * M_PI / 360.0))
+
+int test_trig() {
+ int i;
+ double arg;
+ double res;
+
+ for (i = 0; i <= 360; i++) {
+ arg = Deg2Rad(i);
+ res = sin(arg);
+ printf("sin(%.14f) = %.14f\n", arg, res);
+ }
+
+ for (i = 0; i <= 360; i++) {
+ arg = Deg2Rad(i);
+ res = cos(arg);
+ printf("cos(%.14f) = %.14f\n", arg, res);
+ }
+
+ /* Always claim success. */
+ return 0;
+}
+
+

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-04T06:01:08Z

Michael Ledford <michael@...> writes:

> I did more logging that shows the differences of calculations coming
> from the sin() and cos() functions inside earth_distance(). And as you
> can tell they add (or multiply) to a bigger difference coming out of
> the function.

I'm glad you are digging into this - it seems very tricky.

@esr: We should be careful about saying "numerically unstable":

http://en.wikipedia.org/wiki/Numerical_stability

I understand that we are having a situation where gpsd computes a
different value from the same inputs on different systems, and that the
cause of the difference is trig returning different values for the same
inputs. But that doesn't mean that the trig is at fault; it could be
that those differences are allowable and that the use of them magnifies
the resulting difference beyond reason - which would be the essence of
being able to label the earth_distance *function* numerically unstable,
not sin/cos.

It would be good to have a regression test for earth_distance.

Michael: How different are the results from sin and cos on various
platforms?

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-04T05:48:51Z

netbsd-5/sparc64 is down to two failures:

bu303-nofix has different altitudes from the checked in "right
answer". It matches what I get on netbsd-5/amd64. I also get a
failure on this test on linux/i386, but with a different answer.

superstar2 output is totally missing. Running just that by hand, I
think gpsd is failing to ever detect a packet in the dump. Almost
surely this is an endian issue. Has anyone else run on a big-endian
machine? Fire up those old PPC macs!

The output is too big for the list, and is at:

http://www.lexort.com/gpsd/

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: Using gpsd without real GPS; reading position from text file

2009-12-04T00:08:01Z

Antti Toivanen <anttit@...>:
> Thanks for your quick responses, I'll investigate how to get our flight
> simulator to output gps-fake compatible data. Let's see if I succeed :-)

If you can get it to emulate plain-vanilla NMEA 0813, that will do.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

From forum: GPSd - Users

Re: Using gpsd without real GPS; reading position from text file

2009-12-03T23:55:07Z

Hi,

On Fri, Dec 4, 2009 at 01:56, Eric S. Raymond <esr@...> wrote:

>
> Easily. This is what gpsfake is for - feeding logfiles to an instance of
> gpsd as though they were GPS hardware. Anything listening on port 2947
> will
> see the position dara from the logfile.
>
> We use gpsfake as a text jig, but you can apply it to gfake our a GPS
> client program as well.
>

Excellent! This is just what I was looking for. I was a bit unsure if
gpsfake can be feed the specific data we want but thanks for correcting me.

> Awkwardly, we have a subproject called gpssim to do do just this - but
> it's only about 75% finished. What's missing is the ability to generate
> skyviews so we can fake $GPGSV. If you have someone who's a decent
> Python programmer willing to learn basic orbital-calculation math, it
> would probably be about ten man-days of work to finish.
>
>
Unfortunately I don't speak Python (..yet :-) so I can't help you, but can
you keep me up to date about this project? Sounds very interesting.

Thanks for your quick responses, I'll investigate how to get our flight
simulator to output gps-fake compatible data. Let's see if I succeed :-)

Best regards,
Antti
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

From forum: GPSd - Users

Re: regression failures

2009-12-03T23:48:02Z

Greg Troxel <gdt@...>:
> >> mkt-3301 and rgm3800 looks like a bogus test with times beyond Y2038.
> >
> > Yes. I think these are due to a driver-level bug in how the time value
> > is extracted fro m these devices. They're ckuethe's patch.
>
> So the 'desired' outputs are wrong too, and when the bug is fixed, we'll
> regen those?

Correct.

> >> navcom looks like a real bug.
> >
> > I think mledford has this diagnosed. It's an instability problem
> > arising from trig functions that IEEE754 doesn't guarantee will have
> > stable outputs.
>
> So are we calling trig functions with values that don't make sense?

No, as mleford explained the trig functions themselves are numerically
unstable.

> > All pass, consistemtly, on my Intel Core Duo 2 running Ubuntu 9.10.
>
> So is that in i386 mode or amd64 mode?

amd64.

>
> I get the same 4 failures (as netbsd-5-i386) on ubuntu/i386.
>
> On netbsd-5/amd64, I get 3 of the errors, but not navcom.
>
> On netbsd-5/amd64, I think time_t is still 32 bits. On netbsd-current,
> I think it's 64 bits (all all cpus), but I haven't run gpsd there yet.

Your results are consistent with a couple of those being 32-vs.64-bit issues.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-03T18:28:29Z

Greg Troxel <gdt@...>:
> uBlox-lea-4t: GPGSA very different, all else ok (including SKY in
> json)
>
> sample GPGSA difference:
>
> -$GPGSA,A,3,21,24,18,26,29,16,10,10,2146959360,2146959360,-1717986918,1073977753,-171798692,1072913448,1889785610,1073809981,687194767,1073123164,687194767,1074171740,1717986919,1078412902,2146959360,14,21,24,15,18,26,29,16,06,10,03,22,,,,,,,,,,,,,,,,2.5,1.2,2.1*05
> +$GPGSA,A,3,21,24,18,26,29,16,10,10,2146959360,2146959360,1073977753,-1717986918,1072913448,-171798692,1073809981,1889785610,1073123164,687194767,1074171740,687194767,1078412902,1717986919,2146959360,14,21,24,15,18,26,29,16,06,10,03,22,,,,,,,,,,,,,,,,2.5,1.2,2.1*05^M

Nailed. This was a uBlox driver bug; USED_SET was getting set when it
shouldn't have been.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-03T17:47:55Z

Greg Troxel <gdt@...>:

>
> I ran regression tests on NetBSD-5/sparc64 (LP64, big endian). The
> navcom test passed, and the three that fail on my other platforms
> failed, plus:
>
> superstar2: no output from test at all
>
> uBlox-lea-4t: GPGSA very different, all else ok (including SKY in
> json)
>
> sample GPGSA difference:
>
> -$GPGSA,A,3,21,24,18,26,29,16,10,10,2146959360,2146959360,-1717986918,1073977753,-171798692,1072913448,1889785610,1073809981,687194767,1073123164,687194767,1074171740,1717986919,1078412902,2146959360,14,21,24,15,18,26,29,16,06,10,03,22,,,,,,,,,,,,,,,,2.5,1.2,2.1*05
> +$GPGSA,A,3,21,24,18,26,29,16,10,10,2146959360,2146959360,1073977753,-1717986918,1072913448,-171798692,1073809981,1889785610,1073123164,687194767,1074171740,687194767,1078412902,1717986919,2146959360,14,21,24,15,18,26,29,16,06,10,03,22,,,,,,,,,,,,,,,,2.5,1.2,2.1*05^M

Those large values for satellite IDs are clearly garbage. Somehow the
GPGSA dump code is deriving a wrong number of satellites. I'll look
into this.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

signature.asc (196 bytes) Download Attachment

From forum: GPSd - Dev

Re: regression failures

2009-12-03T17:19:22Z

I ran regression tests on NetBSD-5/sparc64 (LP64, big endian). The
navcom test passed, and the three that fail on my other platforms
failed, plus:

superstar2: no output from test at all

uBlox-lea-4t: GPGSA very different, all else ok (including SKY in
json)

sample GPGSA difference:

-$GPGSA,A,3,21,24,18,26,29,16,10,10,2146959360,2146959360,-1717986918,1073977753,-171798692,1072913448,1889785610,1073809981,687194767,1073123164,687194767,1074171740,1717986919,1078412902,2146959360,14,21,24,15,18,26,29,16,06,10,03,22,,,,,,,,,,,,,,,,2.5,1.2,2.1*05
+$GPGSA,A,3,21,24,18,26,29,16,10,10,2146959360,2146959360,1073977753,-1717986918,1072913448,-171798692,1073809981,1889785610,1073123164,687194767,1074171740,687194767,1078412902,1717986919,2146959360,14,21,24,15,18,26,29,16,06,10,03,22,,,,,,,,,,,,,,,,2.5,1.2,2.1*05^M

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

attachment0 (200 bytes) Download Attachment

From forum: GPSd - Dev

Re: Using gpsd without real GPS; reading position from text file

2009-12-03T16:00:32Z

Eric S. Raymond <esr@...>:
> We use gpsfake as a text jig, but you can apply it to gfake our a GPS
> client program as well.

I meant "We use gpsfake as a *test* jig, but you can apply it to *fake
out* a GPS client program as well." Typos are the bane of my life...
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

From forum: GPSd - Users

Re: Using gpsd without real GPS; reading position from text file

2009-12-03T15:56:27Z

Antti Toivanen <anttit@...>:
> I am wondering if it's possible to use gpsd without actual GPS device, but
> just to broadcast position data (read from text file for example) to other
> device via ethernet.

Easily. This is what gpsfake is for - feeding logfiles to an instance of
gpsd as though they were GPS hardware. Anything listening on port 2947 will
see the position dara from the logfile.

We use gpsfake as a text jig, but you can apply it to gfake our a GPS
client program as well.

> I've googled around a bit and found a few different softwares for creating
> fake gps-data for testing purposes. Do you have any idea how we could create
> our own fake gps-data from our simulator's position?

Awkwardly, we have a subproject called gpssim to do do just this - but
it's only about 75% finished. What's missing is the ability to generate
skyviews so we can fake $GPGSV. If you have someone who's a decent
Python programmer willing to learn basic orbital-calculation math, it
would probably be about ten man-days of work to finish.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

From forum: GPSd - Users

Re: Using gpsd without real GPS; reading position from text file

2009-12-03T11:01:33Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Antt!

On Thu, 3 Dec 2009, Antti Toivanen wrote:

> I am wondering if it's possible to use gpsd without actual GPS device, but
> just to broadcast position data (read from text file for example) to other
> device via ethernet.

Check out gpsfake in the gpsd package. The gpsd project uses it heavily
for regression tests.

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
gem@... Tel:+1(541)382-8588

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFLGAsRBmnRqz71OvMRAo/+AJ4nP6YmMMQ48irGfZoFU1TLk3xKmACfU9Fg
od4X4yabRhTDRzdzqVBgyFw=
=ZRZY
-----END PGP SIGNATURE-----

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

From forum: GPSd - Users