Re: [gpsd-dev] Jupiter-T driver

[djch]

Many thanks for the reply - I've looked a bit deeper here. To avoid confusion, 
my receiver says TU60-D001-001 on it - it's not the TU30 series

It is described by the LA010050B datasheet - for example in 
http://www.rabel.org/archives/Navman_Jupiter_11_12/LA010050B_JupiterT_DataSheet.pdf

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.

I hacked the oncore driver to include a probe detect that called 
oncore_event_hook for event_wakeup and event_reactivate, and the receiver was 
then detected as oncore, and gpsmon started to display correctly. (For a quick 
test I hard-coded success- I haven't done the code to prove you've seen a 
Jupiter-T yet)

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.

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

I'd quite like to do the driver 'properly' - but this raises two questions:

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.

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

Many thanks - I've no idea how many Jupiter-Ts are out there, but they are 
popular for GPS disciplined oscillators, as they have the very rare 10Khz 
output as well as 1 Hz, and 10 KHz makes the PLL filtering much easier.

--David 

On Mon, 28 Jan 2013 05:27:14 -0500
"Eric S. Raymond" <address@hidden> wrote:

> address@hidden <address@hidden>:
> > Around the end of 2007, Mick Durkin appears to have had a gpsd driver for 
> > the Jupiter-T timing receiver. The 'writing-a-driver.html' page still 
> > describes his work. However, I can't find the driver code (and I have a 
> > Jupiter-T, which is silent because it need .probe_detect to start sending 
> > data)
> > 
> > Did this driver ever get incorporated into gpsd? I've looked at 2.96, and 
> > it doesn't seem to be there - I think 2.36 was mentioned as a potential 
> > first release.
> 
> The Jupiter-T uses the Zodiac driver.  That has indeed been incorporated; it's
> actually one of the oldest and best-tested drivers in our suite.  But many
> Zodiac devices have odd startup requirements like the one you describe, and
> we'll need to teach gpsd about yours.
> 
> To do that, we'll need technical documentation describing how the probe_detect
> needs to be written. Can you supply that?
> 
> Also, be aware that (because of the startup requirement) we won't be able to 
> regression-test the device.  Support for it is likely to be somewhat fragile.
> -- 
>               <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
> 


-- 
 <address@hidden>