[aprssig] Open Source/Commercial Use acceptable APRS Alternative?

Sun Aug 13 13:11:32 EDT 2023

We really need to open the door to investigation of OpenTrac.  It provides some much more consumable structure that avoids the append this string in this format “design” principals that make APRS difficult to create parsers for. 

You’ll find OpenTrac (http://opentrac.org/) support already in some popular trackers!

Gregg Wonderly
W5GGW

Sent from my iPhone

> On Aug 7, 2023, at 8:14 PM, John Gorkos <jgorkos at gmail.com> wrote:
> 
> I was more concerned with copy write and patent violations than with frequency issues.
> 
> The use case is pretty straight-forward:  we have a very large event that takes place over ~3500 acres of desert.  It's perfectly flat, and about 80,000 people show up for it.  The organization that runs it uses a Kenwood trunking system for voice comms among the thousands of people, paid and volunteer, that keep things on the rails.  There are also hundreds of utility vehicles, ranging from golf-carts to heavy diesel fuel trucks.  A non-trivial amount of radio chatter on the 25 or so talk groups is "where are you"? Usually, that query is from a command-and-control center (i.e. fuel truck dispatch) to a mobile unit.
> 
> The majority of the non-working participants are bicycle mobile, and unfortunately, there is a lot of bicycle re- and mis-appropriation.  Being able to track my $1000+ electric bicycle in the case where it wanders off is worth taking an extra few hundred dollars worth of gear out there.
> 
> In both cases a super-cheap, short- to mid-range tracking solution would be great.  In fact, this is almost exactly the kind of environment (in my mind) that Bob had when he started promoting a tactical, data-driven position aware radio network.  But, in this case, it's just too big for amateur radio.  I suppose if we started using 440, multiple 2m channels, etc, and started playing fast and loose with licenses, if could be done, but the beauty of it is that it doesn't have to be done.  The LoRa transmitter chips are perfect for this use case.  They put out about 20dbm, they come with really nice microcontrollers that have no problem polling a GPS serial stream, assembling a packet, and deciding when to transmit it.   Plus, we get to use everything from 902-928MHz.  Also, being in the middle of the desert, there's not a lot of interference.
> 
> I'm initially using ~40 byte on-air messages at 125kHz for an on-air time of ~300ms.   One of the goals this year is to experiment with the range of modulation speeds,spreading factors, and  coding rates that LoRa offers to see what gives me the best range/on-air rates.  The absolute maximum distance you can possibly need to transmit is 3 miles.  And like I mentioned earlier, it's REALLY flat.  There are two bits of kit I'll have out there:  trackers and iGates.  Trackers are Heltec HTCC-AB02S GPS/LoRa dev boards with a 600mAh battery that's good for 6-8 hours, and can be powered/recharged via USB.  You can get them on Amazon for $25 or so.  iGates are Lilygo T-Beams.  They have the GPS, LoRa, and throw in an ESP32 for WiFi/Bluetooth connectivity, and run about $40.  The Organization provides a point-to-multipoint Ubiqiti network that covers the event space, so there are pockets of WiFi coverage scattered across the whole service area.  Igates are deployed into these Wifi enclaves to get the data from RF to backhaul as quickly as possible.  There are no digipeaters; everything is one-and-done.
> 
> Once the data is on backhaul, ideally it would be processed and used onsite.  That requires a level of access I don't have, so everything gets sent out of the event.  First hop is 60gb/s AirFiber, then it's dropped onto actual fiber into the Internet. And that's where the real line-crossing happens.  Right now, all of the data is in APRS format.  Some of the call signs are tactical, some of them are actual ham callsigns with -[A..Z] SSIDs.  The iGate firmware on the T-Beams has the ability to connect directly to APRS-IS.  It also provides an MQTT client. There are plenty of great online and standalone APRS-aware clients (YACC, Xastir, and of course, APRS.FI come to mind).  There's already quite a bit of LoRa APRS traffic on APRS-IS.  Most of it is ham-originated, but I'm pretty sure it's not ALL that way.  For me making sure some naked hippie doesn't ride off on my bike at Burning Man, using APRS-IS is fine.  For a large organization tracking hundreds of assets, absolutely not.
> 
> Which brings me all the way back to my original question.  Is the APRS protocol appropriate for a network like this?  How much of the APRS infrastructure can/should I leverage to a) use it for personal use (i.e. where's my bike) and b) for proof-of-concept to the host Organization to see if we want to expand to dozens or hundreds of trackers in the future?  Should I invest time in OpenTRAC and something like Traccar, or perhaps just set up a standalone aprsc node (or several, for redundancy) and run everything as a walled-garden?  There's no profit in it for me, or for anyone, really, save for the equipment manufacturers.  It's more of a "I've been playing with IoT, and digital radio, and vehicle tracking, and tactical situational awareness both personally and professionally for over 30 years, and this is the first time I've really seen a 'perfect storm' of need, opportunity and availability of cheap hardware really collide."
> 
> Open to thoughts, especially from those of you that have been to the playa.
> 
>> On 8/7/23 11:29, John Langner WB2OSZ wrote:
>> I haven't seen anything that would prohibit the use of the APRS protocol for
>> commercial use.
>> The issue would be using the Amateur Radio frequencies.
>> 
>> What, exactly, is the use case?
>> Would hams be present for the event?
>> We've put APRS trackers on vehicles in town parades so everyone can track
>> their progress.
>> 
>> You mentioned that LoRa is already being used.
>> QEX July/August 2023 describes an implementation of APRS for the LoRa TTGO.
>> https://github.com/lora-aprs
>> 
>> 73,
>> John WB2OSZ
>> 
>> 
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
> <OpenPGP_0xA4025CE04AE176ED_and_old_rev.asc>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20230813/e7371f2d/attachment.html>