The state of RTCM3 support, and two request for healp

[Eric S. Raymond]

I have spent the last week or so adding RTCM3 support to gpsd.  But
I don't have an RTCM3 source and RTCM3-capable GPS to test with,
so I need some help verifying that the support is correct.

Enhancing the packet sniffer to detect RTCM3 packets was not
difficult. They have a well-defined framing protocol with a unique
leader byte and a strong checksum (actually, the best checksum
algorithm I've ever seen). The RTCM3.1 standard includes a hex dump of
a good test packet.  Thus, I have high confidence in the support at
the packet-sniffer level.

I am fairly sure that gpsd will correctly pass RTCM3 packets from a source
to all attached RTCM3-capable GPSes, but only because the code to do
that was trivial once the sniffer changes were in place -- I basically
cut and pasted the RTCM2 passthrough support.  But this needs to be
tested.  

To test RTCM3 passthrough, somebody needs to run gpsd at a high debug level
with the right equipment attached (an RTCM3 source and an
RTCM3-capable GPS) and verify by looking at the <= and =>  that the
right thing is happening.

Testing rtcmdecode's facility to analyze and dump the contents of
RTCM3 packets is more difficult; in fact, right now I have no way to
check the correctness of that code, and it is almost certainly wrong
in some of its details. I've tried to follow the 10403.1 standard as
closely as possible, but getting this sort of thing perfect on the
first try is notoriously difficult and I doubt I have managed it.

Just having a binary RTCM3 capture isn't good enough.  To verify this
code I need both a capture and a set of testable assertions about what the
the data in it means -- ideally, an ASCII dump of the data fields in the
capture produced by a tool that is known good.

I haven't actually finished the analyzer code, because there doersn't
seem to be a lot of point in trying before I can test it.  Can anyone
supply both a binary RTCM3 test load and some sort of text dump of at
least the key data in it?
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The whole of the Bill [of Rights] is a declaration of the right of the
people at large or considered as individuals...  It establishes some
rights of the individual as unalienable and which consequently, no
majority has a right to deprive them of.
         -- Albert Gallatin, Oct 7 1789
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Matthias Urlichs]

Hi,

Eric S. Raymond:
> To test RTCM3 passthrough, somebody needs to run gpsd at a high debug level
> with the right equipment attached (an RTCM3 source and an
> RTCM3-capable GPS) and verify by looking at the <= and =>  that the
> right thing is happening.
>
I'll do that once I get the rtcm3-capable high-end GPS beast that
I've been promised. (This will probably take a few weeks.)

RTCM3 feeds from Euref are free, if you have a good reason for requiring
one (and are located in the EU) (and don't overtax their servers).

(NB, how does gpsd figure out whether it can send RTCM to an
 NMEA-delivering gps device?)

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
The secret of healthy hitchhiking is to eat junk food.
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Matthias Urlichs]

Hi,

Matthias Urlichs:
> I'll do that once I get the rtcm3-capable high-end GPS beast that
> I've been promised. (This will probably take a few weeks.)
>
Ah, I just found that my low-end receiver purports to support the stuff.

Unfortunately we're not there yet:

gpsd: <= GPS: $GPRMC,195208.000,A,4927.7487,N,01106.6356,E,0.09,0.00,160708,,,A*6C
gpsd: GPRMC starts a reporting cycle.
gpsd: GPRMC sets mode 2
gpsd: LOS matrix is singular, can't calculate DOPs.
gpsd: transfer mask on RMC: 1000036b
gpsd: client(0): channel 5 already active.
gpsd: GPS has a fix (status=1, mode=2).
gpsd: => client(0): GPSD,O=RMC 1216237928.000 0.005 49.462478333 11.110593333 ? ? ? 0.0000 0.046 ? ? ? ? 2
gpsd: => GPS: 2447504747412c3139353231302e3030302c343932372e373438372c4e2c30313130362e363335362c452c312c352c312e38342c3330352e382c4d2c34372e382c4d2c2c2a35420d0a2447504753412c412c332c32392c32312c33302c32342c33312c2c2c2c2c2c2c2c322e30392c312e38342c302e39392a30420d0a2447504753562c
gpsd: <= DGPS: 132 bytes of RTCM relayed.
gpsd: => GPS: 1002128e7f0101000101010001000000000000131003
gpsd: <= GPS: $GPGSV,2,2,07,30,35,129,44,23,06,317,,40,,,*77
gpsd: GPGSV field 3 value of 7 != actual count 6
gpsd: Satellite data OK (2 of 2).
gpsd: transfer mask on GSV: 40001
gpsd: client(0): channel 5 already active.
gpsd: => client(0): GPSD,Y=GSV 1216237928.000 6:30 35 129 44 0:23 6 317 0 0:38 0 0 0 0:30 35 129 44 0:23 6 317 0 0:40 0 0 0 0:
gpsd: => GPS: 2447504747412c3139353231312e3030302c343932372e373438372c4e2c30313130362e363335362c452c312c352c312e38342c3330352e382c4d2c34372e382c4d2c2c2a35410d0a2447504753412c412c332c32392c32312c33302c32342c33312c2c2c2c2c2c2c2c322e30392c312e38342c302e39392a30420d0a2447504753562c
gpsd: <= DGPS: 132 bytes of RTCM relayed.
gpsd: => GPS: $PFST*11\x0d

gpsd: <= GPS: $GPRMC,195209.000,A,4927.7487,N,01106.6356,E,0.03,0.00,160708,,,A*67
gpsd: GPRMC starts a reporting cycle.
gpsd: GPRMC sets mode 2
gpsd: LOS matrix is singular, can't calculate DOPs.
gpsd: transfer mask on RMC: 1000026b
gpsd: client(0): channel 5 already active.
gpsd: GPS has a fix (status=1, mode=2).
gpsd: => client(0): GPSD,O=RMC 1216237929.000 0.005 49.462478333 11.110593333 ? ? ? 0.0000 0.015 ? ? ? ? 2
gpsd: => GPS: 2447504747412c3139353231322e3030302c343932372e373438372c4e2c30313130362e363335362c452c312c352c312e38342c3330352e
gpsd: <= DGPS: 56 bytes of RTCM relayed.
gpsd: => GPS: $PFEC,GPsrq*5B\x0d

gpsd: GPS is offline (1216237932.358712 sec since data)
gpsd: closing GPS=/dev/rfcomm1 (5)
gpsd: => client(0): GPSD,X=0

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
"Incidents from the Iliad and the Exodus come
 within the same degrees of credibility."
   [John Ruskin, from Rufus K. Noyes,
    Views of Religion, also James A.
    Haught, ed., 2000 Years of Disbelief]
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Matthias Urlichs <smurf@...>:
> Eric S. Raymond:
> > To test RTCM3 passthrough, somebody needs to run gpsd at a high debug level
> > with the right equipment attached (an RTCM3 source and an
> > RTCM3-capable GPS) and verify by looking at the <= and =>  that the
> > right thing is happening.
> >
> I'll do that once I get the rtcm3-capable high-end GPS beast that
> I've been promised. (This will probably take a few weeks.)

Thanks.  Do you have access to any RTCM3 dumping tools?

> (NB, how does gpsd figure out whether it can send RTCM to an
>  NMEA-delivering gps device?)

It's a capability of the device type; there's an rtcm_writer method in the
driver structure.  So if gpsd can identify the device type it will know.

Generic NMEA devices *are* assumed to be RTCM-capable, as RTCM
packets sent to a device that doesn't grok them will generally be ignored
due to failing the NMEA checksum.
--
                <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

[Eric S. Raymond-2]

Matthias Urlichs <smurf@...>:
> > I'll do that once I get the rtcm3-capable high-end GPS beast that
> > I've been promised. (This will probably take a few weeks.)
> >
> Ah, I just found that my low-end receiver purports to support the stuff.
>
> Unfortunately we're not there yet:

In your log I see messages like "gpsd: <= DGPS: 132 bytes of RTCM relayed."  
Do you have some other reason to believe this is not actually happening?
--
                <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

[Matthias Urlichs]

Hi,

Eric S. Raymond:
> In your log I see messages like "gpsd: <= DGPS: 132 bytes of RTCM relayed."  
> Do you have some other reason to believe this is not actually happening?

No. The problem I have is at the bottom of the log:

gpsd: => GPS: 2c2a37430d0a24475047
gpsd: <= DGPS: 10 bytes of RTCM relayed.
gpsd: GPS is offline (1216239728.738411 sec since data)
gpsd: closing GPS=/dev/rfcomm1 (5)
gpsd: => client(0): GPSD,X=0


Another run:

gpsd: connection to Ntrip broadcaster www.euref-ip.net established.
gpsd: client 127.0.0.1 (0) connect on fd 6
gpsd: packet sniff finds type 1
gpsd: switch_driver(Generic NMEA) called...
gpsd: selecting Generic NMEA driver...
gpsd: ntpd_link_activate: 0
gpsd: => GPS: $PSRF100,0,9600,8,1,0*0C\x0d

gpsd: <= GPS: $GPGGA,203615.454,4927.7444,N,01106.6396,E,1,7,1.25,321.3,M,47.8,M,,*54
gpsd: can't use GGA time until after ZDA or RMC has supplied a year.
gpsd: GPGGA sets status 1 and mode 3 (changed)
gpsd: unflagging descriptor 4
gpsd: closing GPS=/dev/rfcomm1 (4)
gpsd: checking client(0)
gpsd: <= client(0): w=1
gpsd: client(0): assigning channel...
gpsd: User requires 2, channel type is 1
gpsd: opening GPS data source at '/dev/rfcomm1'
gpsd: garmin_gps not active.
gpsd: no probe matched...
gpsd: gpsd_activate(1): opened GPS (4)
gpsd: => GPS: $PSRF100,0,9600,8,1,0*0C\x0d\x0a FAILED
gpsd: flagging descriptor 4 in assign_channel
gpsd: => client(0): GPSD,W=1
gpsd: => GPS: 9fb7e40dd300593f4000a2162402b086b81f7b002b3bfa79a80c0016f0ff1431155830fffc9986968afe57fd54a1ca1458a13887fa783fa89c8160015e9fefc58f9dd0ef00a38fe8b0e03e81c03bfdaa84b49e8d007be7fa3b8810508a7dff640dd4da0d FAILED
gpsd: <= DGPS: 100 bytes of RTCM relayed.
gpsd: => GPS: $PGRMCE*0E\x0d\x0a FAILED
gpsd: transfer mask on GGA: 01
gpsd: => GPS: $PFEC,GPint*58\x0d\x0a FAILED
gpsd: transfer mask on GGA: 01
gpsd: => GPS: 1002128e7f0101000101010001000000000000131003 FAILED
gpsd: transfer mask on GGA: 01
gpsd: => GPS: $PFST*11\x0d\x0a FAILED
gpsd: transfer mask on GGA: 01
gpsd: => GPS: $PFEC,GPsrq*5B\x0d\x0a FAILED
gpsd: transfer mask on GGA: 01
gpsd: => GPS: $PASHQ,RID*28\x0d\x0a FAILED
gpsd: transfer mask on GGA: 01
[ LOTS of repeats ]
gpsd: transfer mask on GGA: 01
gpsd: GPS is offline (2.070754 sec since data)
gpsd: GPS is offline (1216240582.921666 sec since data)
gpsd: closing GPS=/dev/rfcomm1 (4)
gpsd: => client(0): GPSD,X=0

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
:fum: n. [XEROX PARC] At PARC, often the third of the standard
   {metasyntactic variable}s (after {foo} and {bar}). Competes with {baz},
   which is more common outside PARC.
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Matthias Urlichs]

Hi,

Matthias Urlichs:
> gpsd: => GPS: 9fb7e40dd300593f4000a2162402b086b81f7b002b3bfa79a80c0016f0ff1431155830fffc9986968afe57fd54a1ca1458a13887fa783fa89c8160015e9fefc58f9dd0ef00a38fe8b0e03e81c03bfdaa84b49e8d007be7fa3b8810508a7dff640dd4da0d FAILED
> gpsd: <= DGPS: 100 bytes of RTCM relayed.

This FAILED is obviously a consequence of

ssize_t gpsd_write(struct gps_device_t *session, void const *buf, size_t len)
{
     ssize_t status;
     bool ok;
     if (session->context->readonly)
        return 0;
     status = write(session->gpsdata.gps_fd, buf, len);
     ok = (status == (ssize_t)len);
     (void)tcdrain(session->gpsdata.gps_fd);
     /* no test here now, always print as hex */
     gpsd_report(LOG_IO, "=> GPS: %s%s\n", gpsd_hexdump(buf, len), ok?"":"      + FAILED");
     return status;
}

which is unable to send the whole buffer; apparently Bluetooth/rfcomm
is somewhat limited here.  strace says much the same thing:

>> write(4, "$PASHQ,RID*28\r\n", 15)       = 15
>> ioctl(4, TCSBRK, 0x1)                   = 0
>> write(2, "gpsd: => GPS: $PASHQ,RID*28\\x0d\n\n", 33) = 33
>> write(2, "gpsd: Navcom: command dump: 0299661c0800040200001203\n", 53) = 53
>> write(4, "\2\231f\34\10\0\4\2\0\0\22\3", 12) = 12
>> ioctl(4, TCSBRK, 0x1)                   = 0
>> write(2, "gpsd: => GPS: 0299661c0800040200001203\n", 39) = 39
>> write(2, "gpsd: Navcom: sent command 0x1c (Test Support Block)\n", 53) = 53
>> write(2, "gpsd: Navcom: command 0x1c mode = 02, length = 0\n", 49) = 49
>> write(2, "gpsd: Navcom: command dump: 029966200e000001ae02000071000000f203\n", 65) = 65
>> write(4, "\2\231f \16\0\0\1\256\2\0\0q\0\0\0\362\3", 18) = 18
>> ioctl(4, TCSBRK, 0x1)                   = 0
>> write(2, "gpsd: => GPS: 029966200e000001ae02000071000000f203\n", 51) = 51
>> write(2, "gpsd: Navcom: sent command 0x20 (Data Request) - data block id = ae at rate 00\n", 79) = 79
>> write(2, "gpsd: Navcom: command dump: 029966200e00000186020a0071000000d003\n", 65) = 65
>> write(4, "\2\231f \16\0\0\1\206\2\n\0q\0\0\0\320\3", 18) = -1 EAGAIN (Resource temporarily unavailable)

Thus it seems that gpsd_write() needs to buffer its data and hook
into the select loop.

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Fools are certain, but wise men hesitate.
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Matthias Urlichs <smurf@...>:
> No. The problem I have is at the bottom of the log:
>
> gpsd: => GPS: 2c2a37430d0a24475047
> gpsd: <= DGPS: 10 bytes of RTCM relayed.
> gpsd: GPS is offline (1216239728.738411 sec since data)
> gpsd: closing GPS=/dev/rfcomm1 (5)
> gpsd: => client(0): GPSD,X=0

That sure doesn't look good.  Does it replicate if you don't have an RTCM3
source attached?
--
                <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

[Eric S. Raymond-2]

Matthias Urlichs <smurf@...>:
> Thus it seems that gpsd_write() needs to buffer its data and hook
> into the select loop.

OUCH!

That's not going to be easy.  In fact, I shudder at the thought.
Debugging ut will be a bitch and a half...
--
                <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

[Matthias Urlichs]

Hi,

Eric S. Raymond:
>
> That sure doesn't look good.  Does it replicate if you don't have an RTCM3
> source attached?

Works when I drop the rtcm3.

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Sergeant Comely was working on the general assumption that where you got
lots of people gathered together, something illegal was bound to happen
sooner or later.
                -- Terry Pratchett (Johnny and the Dead)
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Matthias Urlichs]

Hi,

Eric S. Raymond:
> Matthias Urlichs <smurf@...>:
> > Thus it seems that gpsd_write() needs to buffer its data and hook
> > into the select loop.
>
> OUCH!
>
> That's not going to be easy.  In fact, I shudder at the thought.

Unfortunately, I see no good way around it; in any case, the gpsd code
seems to have multiple _other_ places where it basically days

        if(write(fd,buf,len)!=len) DIE

> Debugging it will be a bitch and a half...

Yeah, plus you need some sort of hook / timeout, for when the thing
doesn't accept data for too long. :-/ (Happens easily enough, I only
need to take the receiver and wander out of Bluetooth range with it.)

This whole thing would be so much easier with a programming language
that supports continuations. You don't perchance want to rewrite the
whole thing in Python? ;-)

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Kiss me, Kate, we will be married o' Sunday.
                -- William Shakespeare, "The Taming of the Shrew"
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Chris Kuethe]

On Wed, Jul 16, 2008 at 2:28 PM, Matthias Urlichs <smurf@...> wrote:
> You don't perchance want to rewrite the
> whole thing in Python? ;-)

no.


--
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

[Steve Franks]

I have the capability to test the rtcm3 decoder, but not the pass thru
(I have a source, but no target at the moment).

Steve

On Wed, Jul 16, 2008 at 12:28 PM, Eric S. Raymond <esr@...> wrote:

> I have spent the last week or so adding RTCM3 support to gpsd.  But
> I don't have an RTCM3 source and RTCM3-capable GPS to test with,
> so I need some help verifying that the support is correct.
>
> Enhancing the packet sniffer to detect RTCM3 packets was not
> difficult. They have a well-defined framing protocol with a unique
> leader byte and a strong checksum (actually, the best checksum
> algorithm I've ever seen). The RTCM3.1 standard includes a hex dump of
> a good test packet.  Thus, I have high confidence in the support at
> the packet-sniffer level.
>
> I am fairly sure that gpsd will correctly pass RTCM3 packets from a source
> to all attached RTCM3-capable GPSes, but only because the code to do
> that was trivial once the sniffer changes were in place -- I basically
> cut and pasted the RTCM2 passthrough support.  But this needs to be
> tested.
>
> To test RTCM3 passthrough, somebody needs to run gpsd at a high debug level
> with the right equipment attached (an RTCM3 source and an
> RTCM3-capable GPS) and verify by looking at the <= and =>  that the
> right thing is happening.
>
> Testing rtcmdecode's facility to analyze and dump the contents of
> RTCM3 packets is more difficult; in fact, right now I have no way to
> check the correctness of that code, and it is almost certainly wrong
> in some of its details. I've tried to follow the 10403.1 standard as
> closely as possible, but getting this sort of thing perfect on the
> first try is notoriously difficult and I doubt I have managed it.
>
> Just having a binary RTCM3 capture isn't good enough.  To verify this
> code I need both a capture and a set of testable assertions about what the
> the data in it means -- ideally, an ASCII dump of the data fields in the
> capture produced by a tool that is known good.
>
> I haven't actually finished the analyzer code, because there doersn't
> seem to be a lot of point in trying before I can test it.  Can anyone
> supply both a binary RTCM3 test load and some sort of text dump of at
> least the key data in it?
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> The whole of the Bill [of Rights] is a declaration of the right of the
> people at large or considered as individuals...  It establishes some
> rights of the individual as unalienable and which consequently, no
> majority has a right to deprive them of.
>         -- Albert Gallatin, Oct 7 1789
> _______________________________________________
> Gpsd-dev mailing list
> Gpsd-dev@...
> https://lists.berlios.de/mailman/listinfo/gpsd-dev
>

--
Steve Franks, KE7BTE
Staff Engineer
La Palma Devices, LLC
http://www.lapalmadevices.com
[phone]
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Matthias Urlichs <smurf@...>:
> > That sure doesn't look good.  Does it replicate if you don't have an RTCM3
> > source attached?
>
> Works when I drop the rtcm3.

Strraaaaange.  Looks like libgpsd_core.c:768 never gets called when the
source is pure RTCM3 packets.

I just checked in a change that reports full packets received at debug
level 8 and adds the device to a lot of the I/O debug messages.  Try running
at -D 8 and see if you ever get a message that looks like this:

    "Accepted packet on %s.\n"

Maybe the packet sniffer isn't filling the packet output buffer...
--
                <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

[Eric S. Raymond-2]

Matthias Urlichs <smurf@...>:
> This whole thing would be so much easier with a programming language
> that supports continuations. You don't perchance want to rewrite the
> whole thing in Python? ;-)

I've been tempted, but the embedded guys wouls scream bloody murder.
--
                <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

[Eric S. Raymond-2]

Steve Franks <stevefranks@...>:
> I have the capability to test the rtcm3 decoder, but not the pass thru
> (I have a source, but no target at the moment).

How?  Do you have some other way to get readable texct dumps from RTCM3
files?
--
                <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

[Chris Kuethe]

On Wed, Jul 16, 2008 at 2:42 PM, Eric S. Raymond <esr@...> wrote:
> Matthias Urlichs <smurf@...>:
>> This whole thing would be so much easier with a programming language
>> that supports continuations. You don't perchance want to rewrite the
>> whole thing in Python? ;-)
>
> I've been tempted, but the embedded guys wouls scream bloody murder.

I won't insist on C if you'll let me rewrite it in perl. :)


--
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