Re: [gpsd-dev] Jupiter-T driver

[Eric S. Raymond]

address@hidden <address@hidden>:
> It is capable of three formats - a subset of oncore, a number of
> Zodiac messages, and some less good NMEA. Out of the box it sends
> *nothing*, so it isn't detected. Unless commanded otherwise, it
> speaks oncore.

OK, that's not a Zodiac chip.
 
> I am puzzled by the how to write a driver.html page - it describes
> the driver I need, and all the issues writing it would raise, but
> the driver itself has disappeared!! I checked all the drivers with
> non-NULL probe_detect, and the Jupiter-T isn't there.

You don't understand.  The code for older Jupiter-Ts *is* there.  They
used the Zodiac chip; the code is in driver_zodiac.c.  The previous
case of a Zodiac with wakeup was the pre-2007 Delorme Earthmate -
look at drivers.c around line 614.

> Is it possible to look back into subversion to see if it was ever
> checked in - I realise we're now on git....

The git archive includes the entire project history.  I can assure you
that we have never removed a driver; if it's not there now, it was 
never there.

> 1 Does gpsd allow for devices that you have to send characters to
> before they start talking. Clearly there's a theoretical risk this
> could confuse some other types. I tried the -t command to gpsctl,
> but this doesn't work as a way to force oncore, since the unit is
> silent unless probed, and gpsctl won't call .event_hook unless the
> device is detected.

Yes.  In the new driver structure this is what event_wakeup is for.
Look at the TNT driver for an example of how it'd done.

>  2 The oncore code seems to keep the Jupiter-T in 3D nav mode all
> the time. The T is intended as a timing receiver, and on its own it
> runs a 24h survey, then freezes location and generate the best
> timing it can. Does gpsd allow drivers with options, so you can
> select whether to run the Jupiter-T as a navigation receiver, or as
> a timing unit? (I realise that user-settable options are essentially
> forbidden, but how else would you determine what I want to use the
> receiver for?)

The way we handle this sort of thing (mode switches) is with a DEVICE command
shipped from the client - same way you do baud-rate switching.  I suppose we
could co-opt the "native" command for this, but it might be cleaner to add
some sort of mode attribute that can take a flag list.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>