[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] SDDBT

From: Eric S. Raymond
Subject: Re: [gpsd-users] SDDBT
Date: Tue, 10 Jan 2012 14:11:42 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

bertram waterman <address@hidden>:
>                    Trawling through your mailing lists I
> see the subject of including DBT was discussed in the latter part of last
> year but in the absence of any further info, can I assume that any proposed
> support has been dropped? 

Yes, but I think mainly because we didn't have a test load for it.  Sounds
like you can supply that lack with a sentence dump from your device.

> If so, then I suspect it will be easier for me to just use gpsd as a NMEA
> "socket" and parse the sentences myself.

I recommend against this.  Ad-hoc NMEA parsers look simple when you
start one but are brittle and hard to maintain.  It took years to get
ours properly bulletproofed.

> 2. I've been writing a small C routine to act as a client in preparation
> for having to parse the NMEA but as yet can't seem to find the correct
> combination of flags to suppress the JSON report - even with
> WATCH_ENABLE|WATCH_NMEA I still seem to be getting the JSON report where I
> only want to have to parse NMEA. 

That is odd.  I will look into it.

>Is the output affected by the input? 

No, it shouldn't be.

> 3. Finally, looking through the sources (driver_nmea.c) I see that the OHPR
> sentence/device is supported and depth is added to the attitude structure.
> Now my C skills are just about up to cobbling together a NMEA parser - is
> there any scope there for a user hack? (obviously using a different
> structure).

The best path would be for us to parse DBT for you and put the results in
the gpsdata_t structure.  Don't worry about writing C for that; just send
us a properly annotated sample via the form at

and I'll do it.
                <a href="";>Eric S. Raymond</a>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]