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

Mon Sep 8 12:20:25 EDT 2014

> A new network ought to allow only users with... coordination
capabilities.
> You don't get to transmit without knowing the exact time... [slot]
> The tricky part is coordinating slot reuse between overlapping digis...

An easy fix for purpose built nets for special events is to eliminate that
problem by using split freqs.  One for the trackers and the other for the
digi outputs.  Just like we do here for local special events.  144.39 for
digi outputs (so everyone can see everything and everyone) and +600 for
tracker inputs.

Bob, WB4aPR

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

_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig