[Top][All Lists]
[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
>
signature.asc
Description: This is a digitally signed message part
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [gpsd-users] Downloading logs from GPS loggers,
Philip Withnall <=