motorola oncore position hold mode for pps timing

[Håkan Johansson-5]

Hi,

I'm using the position hold mode of oncore devices, which allows it to
work for timing with only one satellite in view.  I'd like to implement it
cleaner.

What would be the gpsd way of loading the position hold coordinates at or
before startup?  I'd like to do it from the command line.  Is gpsctl
suitable for such exercises?  Or should I use a hacked version of
motosend.c ?  Easy access to wgs84_separation would be appreciated :-)
(perhaps not so difficult anywhere)

When in position hold mode, it does not deliver lat/long and therefore the
session->context->fixcnt variable used in gpsd_ppsmonitor never reaches 3.
How to work around this?  Some gps_mask_t like TIME_SET would do.  But
TIME_SET itself likely not, as it seems not to mean that time is known and
accurate to 'pulse-per-second' precision.  Perhaps a TIME_SET_PPS ?

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

[Eric S. Raymond-2]

Håkan Johansson <f96hajo@...>:
> I'm using the position hold mode of oncore devices, which allows it to  
> work for timing with only one satellite in view.  I'd like to implement
> it cleaner.

I think this should be done with a JSON conmmand to the daeomon,
invoking a new driver methood.  There are eniugh decices with
the capability to accept a starting-locartion approximation
to justify this.

> What would be the gpsd way of loading the position hold coordinates at or
> before startup?  I'd like to do it from the command line.  Is gpsctl  
> suitable for such exercises?  Or should I use a hacked version of  
> motosend.c ?  Easy access to wgs84_separation would be appreciated :-)  
> (perhaps not so difficult anywhere)

Agh. Please do not add code to mortosend.c.  I want to eliminate
type-specific utilities, not proliferate them.  If the daemon's protocol
interpreter is not a convenient interface, this should be a gpsctl function.

> When in position hold mode, it does not deliver lat/long and therefore
> the session->context->fixcnt variable used in gpsd_ppsmonitor never
> reaches 3. How to work around this?  Some gps_mask_t like TIME_SET would
> do.  But TIME_SET itself likely not, as it seems not to mean that time is
> known and accurate to 'pulse-per-second' precision.  Perhaps a
> TIME_SET_PPS ?

On the server side, TIME_SET maans the last packet contained timec data.

On the server side, TIME_SET means the time field in the gpsdata_t report
structure is valid.  

You might be able to reuse TIME_SET for this safely.  There's certainly no clash
on the client side; the only question is whether your device delivers time
information in the packets it ships while in hold mode.

TIME_SET_PPS would raise difficulties, as we're already using 32 bits in that
mask vector and I don't want to inntroduce a 64-bit dependency.
--
                <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