[FOSS-GPS] foxtrotgps: Tracking weather probes in addition to the own position

Mon Jul 22 06:23:47 PDT 2019

the article for this functionality mentions APRS (Automatic Position
Reporting System) which is a ham radio based system that uses custom
communication packets that broadcast position information over ham radio.
this system has been used for well over 20 years now and is quite robust.
the issue with it has always been the fidelity of the maps it uses to
overlay the reported positions.

this could work with foxtrot GPS easily, If the following are met.

1) an api into foxtrot GPS that allows inserting a "marker" onto the map at
a given position
2) the ability to link successive positions in a track.

to do the aprs part an application must be written that allows the
reception of the aprs packets from either a network port or serial port,
parse them to extract the object id, and its position, then using foxtrot
api placing it on the map.

gpsd is not the proper application to handle that as it would require
implementing parsers for every aprs packet and that is outside of its scope.

chris

On Mon, Jul 22, 2019, 01:49 Tilman Glötzner <tilman_1 at gloetzner.net> wrote:

> Dear Joshua, Dear all
>
> > These days I think libgps/gpsd actually has the ability to use multiple
> > `GPS' devices
> > (whether or not they're actually GPS receivers or something else
> entirely)
> > and even report them to us with distinct ID-strings. So it might
> > actually be
> > most *straightforward* to just try to do things that way: maybe have your
> > RS decoder feed into gpsd, and modify foxtrotgps to differentiate
> > between multiple devices as reported by libgps?
> >
> > This is of course just a suggestion, and is based on things that I've
> > read--
> > if someone has actually used the multi-device support and can comment
> > on its usability (or lack thereof), I'd love to hear it.
> >
> > I'm assuming that it would be easy enough to produce gpsd's JSON
> protocol,
> > but again I don't really have first-hand experience doing so....
> >
> > Maybe you've already considered it and rejected it though?
> a) Something like that has been done:
>
> https://destevez.net/2017/11/tracking-an-rs41-sgp-radiosonde-and-reporting-to-aprs/
>
> The procedure  works fine at home. When going after the probe by a car
> (i.e. hunting the probe), this setup with all its pipes and scripts
> proved  to be difficult to handle in  "field conditions". Usability and
> reliability become issues in cramped conditions of a car and operating
> under time pressure (other are after the probes as well -- only the
> first one at the probe  wins :-)).
>
> b) I have not really rejected using gpsd and have not looked deeply into
> it.
>
>  The choice to try follow the path of writing an additional module for
> foxtrotps had several drivers:
>
> -  I was not really sure how to extend foxtrotgps to use 2 gpsd sources
> and found it easier to implement an additional module for foxtrotgps
> that reads the datagram of the probe decoder.
>
> - I would probably need to write a gpsd driver in addition as the setup
> using the pseudo device as described above works not reliably: I needed
> to restart gpsd  and the scripts/programs feeding into the pseudo device
> after I woke up the laptop from sleep mode for instance.
>
> - The gpsd's JSON protocol seems  not provide separate data fields for
> the vertical and horizontal velocity.
>
> Ideally, the full setup  (receiver, probe decoder, gpsd for gps mouse,
> and foxtrotgps) would be running on a raspberry pi. The used programs
> would open the sockets themselves (rather than using nc ) and
> automatically reconnect in case something fails. And fewer programs
> along the processing chain should increase reliability.
>
> c) Why did I opt for foxtrotgps ?
> - Code is available and in principle good to read/understand
> - Maps can be downloaded for offline use
> - Can be compiled and runs on rasperrypi. The the gui elements are big
> enough to be used with a touch display.
> - The routing function is already there. It should not be difficult to
> enhance this with function "calculate route to additional target, i.e.
> the position of the weather probe.
>
> >
> >> - Once a GPS position is received, it is drawn. If a datagram from a
> >> weather probe is received, everything i.e. the map window is redrawn. So
> >> if a valid gps position is received and a datagram of the probe is
> >> received, redrawing takes place twice per second. I wonder if it is
> >> possible to only locally draw the probe position rather than redrawoing
> >> everything.
> >
> > Hm. How are we doing it right now for the GPS marker that we already
> have?
> Not entirely sure. The key seems to be gps_function.c:cb_gps_timer.
> gdk_window_process_all_updates() updates all pending event of all
> windows. The GPS marker seems then to be drawn directly with
> gdk_draw_arc and subsequent gdk_draw_line commands on the canvas. I
> however do not understand when the events drawing the GPS marker are
> actually processed, i.e. if they are synchronously visualized with the
> execution of the gdk_draw_* commands on the canvas. And I do not really
> understand how the outdated GPS marker is removed when a new fixed is to
> be drawn. I assume that first the map is redrawn and then the new fix on
> top of it.
>
> When I draw the probe icon in rs_functions.c:paint_rs_position with
> gdk_draw_pixbuf, it is not drawn until I click on the canvas with the
> mouse or zoom thereby issuing an event. When I insert an additional
> gtk_widget_queue_draw_area at the same position, the icon is shortly
> drawn and then vanishes...
>
> rs_functions:paint_rs_position
> ....
> gdk_draw_pixbuf (map_drawable->window,  gc_map, rsposition_icon,
>                                         0,0,x-12,y-32,
>                                         24,32,
>                                         GDK_RGB_DITHER_NONE, 0, 0);
> gtk_widget_queue_draw_area (map_drawable,x-12, y-32,24,32);
>
> Thanks
> Tilman
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit https://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
> subscription
> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20190722/261ab42a/attachment.html>