gpsd-users
[Top][All Lists]
Advanced

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

Re: [gpsd-users] Downloading logs from GPS loggers


From: Philip Withnall
Subject: Re: [gpsd-users] Downloading logs from GPS loggers
Date: Sat, 15 Oct 2011 23:14:56 +0100

On Thu, 2011-09-29 at 07:11 +0000, Philip Withnall wrote:
> Hi all,
> 
> (Resent because this appears not to have reached the list the first
> time I sent it. Apologies if it did and just didn't reach the web
> archives.)
> 
> I own a Holux M-241 logger, and I was wondering of the best way to go
> about implementing a decent user experience for downloading the logs
> from the device.
> 
> Users currently have several options:
>  • BT747 (http://www.bt747.org/), a Java program which allows
> downloading track logs from all sorts of loggers.
>  • gpsbabel (http://www.gpsbabel.org/), a GPS format conversion program
> which has sprouted support for downloading logs from a few devices.
>  • mtkbabel
> (http://www.rigacci.org/wiki/doku.php/doc/appunti/hardware/gps_logger_i_blue_747),
>  a Perl program similar to BT747 but with fewer features.
> 
> Apart from the fact that all three projects seem to be dying, all three
> of them conflict with gpsd. If I plug my M-241 into my computer, gpsd
> grabs the device due to its lovely hotplug goodness, and any attempt to
> use gpsbabel without first killing gpsd is doomed to failure.
> 
> Having given it a little consideration (though I may be completely wrong
> on this, as I'm still getting to grips with the immense breadth of the
> GPS software available on Linux; please do correct me), I think it would
> be best if gpsd provided an interface for such track log downloaders to
> temporarily take control of an attached GPS device and send/receive
> whatever proprietary commands they need to download the log.
> 
> In more detail, some JSON commands to:
>  • Lock a specified device, which would cause gpsd to attempt to put the
> device into some specified, known state. While locked, gpsd would only
> send data received from the device to the client which holds the lock.
>  • Send a raw command (byte stream) to a locked device.
>  • Unlock a specified device. At this point, it might be safest/simplest
> if gpsd completely reinitialised the device. However, it might be
> possible for gpsd to require clients to leave the device in some
> specified, known state so that it can do less reinitialisation. I don't
> know enough about specific logger protocols to know if this is possible.
> 
> I had a bit of a search around, and I could only find one previous
> mailing list thread about this, which doesn't seem to have gone
> anywhere: http://marc.info/?l=gpsd-users&m=129155232821033&w=2.
> 
> Bearing the comments on that thread in mind, I still think it's best for
> gpsd to provide such an interface to clients. The alternative would be
> for the log downloader to signal gpsd to disconnect from a device, the
> downloader to grab the device itself and do its magic, then signal gpsd
> to connect to the device again. This has much the same effect as
> allowing raw communication through gpsd, except that it eliminates the
> possibility of warm reinitialisation of the device after the
> downloader's finished. It also gives the possibility of a client DoS
> attack on gpsd, since the client could never relinquish control of the
> device's STTY.
> 
> The other alternative is to add high-level support to gpsd for
> downloading logs from GPS loggers. This would remove the security and
> state handling problem of allowing arbitrary user processes to send
> commands directly over the device serial link; but I worry that it
> might be out of scope for gpsd.

Having thought about it some more, I wonder if this is the way to go. As
I said before, while it expands the scope of gpsd somewhat, it doesn't
have the security issues of allowing user processes exclusive control
over a GPS for an indeterminate period of time.

Perhaps a “?LOGS;” JSON command which returns the amount of free flash
memory, a few other statistics (such as logging settings: how many
points to log per unit distance/time/etc.) and the log tracks/waypoints
in an array.

As before, feedback appreciated.

Cheers,
Philip

> Basically, my aim is to provide a good user experience for GPS loggers
> in GNOME. I want to be able to plug my logger in and have a dialogue
> come up with the option to start my live tracking application of choice,
> or download GPS logs from the device. In writing that dialogue, I don't
> particularly want to have to write code to kill gpsd and then run
> gpsbabel in a subprocess. That would be horrendous. It would be much
> nicer if I could write a library which cannibalises the log extraction
> parts of gpsbabel and uses them to communicate with a logger through
> gpsd. (Or which asks gpsd directly to download the logs.)
> 
> Anyway, enough rambling. I'd appreciate people's opinions on this, or
> pointers to previous discussions about it which I haven't been able to
> find. I've got some spare time at the moment to implement such a
> solution in gpsd if desired.
> 
> Cheers,
> Philip
> 

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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