[aprssig] Digital two-way Radio communication in emergency situations

Mon Sep 8 12:07:56 EDT 2014

The 1/4 second time slot at 9600 baud ought to be big enough for any 
reasonable APRS packet.  I was sending two small position packets in 
that time.

A new network ought to allow only users with certain coordination 
capabilities.  At the very least they need accurate timing data, either 
from GPS or provided by a local digi during a periodic beacon.  You 
don't get to transmit without knowing the exact time, and uncoordinated 
'in the blind' transmissions could be restricted to a set of designated 
slots.  The tricky part is coordinating slot reuse between overlapping 
digis that themselves may not have any a priori coordination.

Scott
N1VG

On 9/5/2014 11:22 AM, andrewemt wrote:
> But how do we get better access control without having central control 
> over the timeslotting for every transmitter in the area? This works OK 
> on a dedicated frequency for a limited-size team, but runs into 
> trouble as soon as an uncoordinated outsider comes on frequency. The 
> marine AIS system has a solution,  but it's patent-encumbered. Also, 
> the fixed equal-size timeslot scheme only works with stations sending 
> about the same amount and size of traffic (in your case, only trackers 
> transmit, not mixed station types). I note that those Kenwood radios 
> you identify can't do timeslotted transmissions (at least not without 
> an external TNC to control them).
>
> The old token-ring network worked without central coordination,  but 
> depended on a high-reliability medium and no hidden transmitters.
>
> Hate to be a party-pooper, but we need to keep in mind the reason why 
> someone would consider amateur radio instead of a top-down commanded 
> commercial solution. Can we come up with a high-efficiency channel 
> access protocol that doesn't require single-point command?
>
> Andrew,  KA2DDO
>
>
> -------- Original message --------
> From: Scott Miller <scott at opentrac.org>
> Date:09/05/2014 13:42 (GMT-05:00)
> To: TAPR APRS Mailing List <aprssig at tapr.org>
> Cc:
> Subject: Re: [aprssig] Digital two-way Radio communication in 
> emergency situations
>
> The system I deployed last week achieved many times the normal APRS
> channel utilization while still staying compatible with existing gear.
> The receive stations were Kenwoods (TH-D7, TM-D700, TM-D710). Most of
> the gain came from using tightly controlled time slotting and
> transmitters with short TX delays.  Going faster wouldn't have made much
> difference - in fact the trackers were set to send each packet twice for
> redundancy since it didn't increase the transmission duration that much
> after the preamble.  Total duration was about 220 msec per transmission,
> with a total of 8 packets per second, counting duplicates.
>
> Going faster isn't the answer; we need better channel access control 
> first.
>
> Scott
> N1VG
>
> On 9/5/2014 9:08 AM, andrewemt wrote:
> > Well, nothing says we have to stay at 1200 baud. There have been 9600
> > baud amateur radio modems around for over a decade. And a parallel
> > protocol (using a different AX.25 PID value) could be used for
> > acknowledged messaging and log transmission (perhaps metering the log
> > transmissions to prevent clogging the channel) while asynchronous
> > un-acked APRS is still used for position and status reporting.
> >
> > Can we go to a wider (more spectrum - eating) channel to gain baud rate?
> > In the quoted system, there might not be voice repeaters to piggyback
> > off, so we don't have to be constrained by their limitations.
> >
> > I don't think we want to get as complex as the current cellphone network
> > technologies;  aside from the cost and patent issues, those networks are
> > all about centralized control and 1-hop access to that central control
> > (which presumably wouldn't be available in the SAR environment,  or
> > they'd just use cellphones).
> >
> > Just my $.02.
> >
> > Andrew, KA2DDO
> >
> >
> > -------- Original message --------
> > From: SARTrack Admin <info at sartrack.co.nz>
> > Date:09/05/2014 02:43 (GMT-05:00)
> > To: TAPR APRS Mailing List <aprssig at tapr.org>, sarcomm at yahoogroups.com,
> > Search_and_Rescue_Communications at yahoogroups.com
> > Cc:
> > Subject: [aprssig] Digital two-way Radio communication in emergency
> > situations
> >
> > Hi all,
> >
> > As the CEO of SARTrack Limited, and developer of the SARTrack Search and
> > Rescue software, I get occasionly approached by Emergency Services
> > organisations who basically require a full two-way *radio* based
> > tracking and communication system for teams in the field, in disaster
> > situations where all other communication networks have failed or are out
> > of range.
> >
> > SARTrack Limited did build type-approved (non Amateur Radio) based APRS
> > Trackers and Digipeaters, but we no longer do this.
> > While the SARTrack software can transmit Operation Logs and Objects over
> > an APRS radio link, this is really not recommended, as the 1200 bps
> > radio channel is simply not fast enough for that kind of work, and APRS
> > is obviously not the right protocol for reliable two-way communication.
> >
> > My question is this:
> > - What does currently exists in the area of affordable two-way, medium
> > speed, digital radio equipment, which can be somehow connected to a user
> > interface like maybe a smartphone or another device which enables
> > display on a screen and entering data on a (digital) keyboard?
> >
> > I start to wonder if it would be possible to develop a 'commercial'
> > package which would make it possible to send people out in the field, on
> > foot or vehicle, carrying a VHF radio based system like this, and using
> > (portable) Digipeaters for same system to setup links to a remote base.
> >    There is clearly a market for this, as 'hi-speed' satellite based
> > systems are incredible expensive and probably more in the militairy
> > domain...
> >
> > The radio link speed would have to be at least 9600 bps, and it should
> > preferably a full digital signal like PSK or QPSK or some other suitable
> > digital modulation type.
> >
> > Any ideas and information welcome.
> >
> > Thanks
> >
> > Bart Kindt
> > SARTrack Limited
> > http://www.sartrack.co.nz/
> > --
> >
> > SARTrack Developer and CEO
> > _______________________________________________
> > aprssig mailing list
> > aprssig at tapr.org
> > http://www.tapr.org/mailman/listinfo/aprssig
> >
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at tapr.org
> > http://www.tapr.org/mailman/listinfo/aprssig
> >
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig