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