[aprssig] Ham Radio MOBILE Traveler PL-FIND device?

spam8mybrain spam8mybrain at yahoo.com
Wed Nov 29 12:59:29 CST 2017


Too bad all of the repeater databases have always been closed and proprietary (both the old ARRL TravelMate program and the new RFinder mobile app). There's no way for a user to dynamically query the DB from their own radio-vendor-specific app to drive their radio appropriately, and neither app allows exporting the entire database for other apps to search (obviously wouldn't be a good business model for the RFinder folks).
At least with APRS repeater objects, we have a snowball's chance in **** (small though that is with travel speed, beacon typos, and infrequency of transmission) of learning about geographically useful repeaters.
Can we start a campaign to identify invalid-format APRS repeater objects and report them to their transmitting parties, so as to get them cleaned up (and thereby usable by the radios that support 1-button TUNE)? Should local repeater objects get 1 hop of digipeating (in appropriate environments) so they can be learned about early enough that the out-of-town traveler can learn about them in time to use them? Should the beacon send rate of repeater objects be tuned to be transmitted at least twice or three times within the time an expressway-traveling mobile station would be in range? Without the above two suggestions, it is likely that a mobile user would be nearly out of range before they heard about the repeater, let alone had a chance to tune to it and listen.
I'm considering adding a new view to my APRS program YAAC to display only repeater objects, sorted by usability, and displaying all the relevant parameters clearly (frequency, offset direction, PL tone or DCS, whether some mode other than analog FM, distance and vehicle-relative bearing to repeater station, i.e., "ahead 20 degrees to starboard"). My preliminary definition of usability weighting would be related to how close the repeater is to the travel direction of the mobile station (strongly biased to being forwards of the vehicle rather than being left behind), and within simplex range of the mobile but furthest away within that range (i.e., maximum talk time before you lose it, assuming you don't change course).
Of course, that means you still have to drag a laptop along, since I haven't yet ported my app to Android or iOS (and devices running those operating systems don't tend to support non-standard peripherals like ham radio transceivers).
But it's an idea....
Andrew, KA2DDOauthor of YAAC and regular long-haul APRS traveler



-------- Original message --------
From: "John D. Hays" <john at hays.org> 
Date: 11/29/17  12:35  (GMT-05:00) 
To: TAPR APRS Mailing List <aprssig at tapr.org> 
Subject: Re: [aprssig] Ham Radio MOBILE Traveler PL-FIND device? 

I think a much better approach would be to use an improved beacon type.  The message should contain:
LAT/LONG (Approximate or Actual)Output Freq:  Mhz. with a minimum scale of up to 5 digits after the decimal point (e.g.  440.00625)
Input Freq; Mhz. with a minimum scale of up to 5 digits after the decimal point (e.g.  440.00625)Mode(s):  FM, NFM, D-STAR, DMR, Fusion, CODEC2, etc.Input signalling:  CTCSS: 123.0, DCS: 44, Color: 1, ... Callsign:  W1AW  or "W1AW   C", ...Comment: Other information
With this information sent both on the air and to APRS-IS, we could have a database of repeater stations that could be preloaded into a device (eg. a Raspberry Pi) and could be updated  with off air beacons using an RTL-SDR or similar receiver.  With a GPS, a small display could provide all the details of nearby repeaters and for radios with computer controlled programming, the radio could be tuned to frequency and other operating parameters by touch selection.  
The RTL-SDR could also look for active repeaters (and simplex) nearby and provide similar programming.


On Wed, Nov 29, 2017 at 8:09 AM, Robert Bruninga <bruninga at usna.edu> wrote:
APRSSIG thoughts about Mobile TRAVEL operations. 

John D. Hays
Edmonds, WAK7VE

   


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20171129/d800a413/attachment.html>


More information about the aprssig mailing list