Digital two-way Radio communication in emergency situations

[andrewemt]

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-an+***@public.gmane.org>
Date:09/05/2014 02:43 (GMT-05:00)
To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>, sarcomm-***@public.gmane.org, Search_and_Rescue_Communications-***@public.gmane.org
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

[Scott Miller]

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

Post by andrewemt
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 --------
Date:09/05/2014 02:43 (GMT-05:00)
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.
- 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
http://www.tapr.org/mailman/listinfo/aprssig
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Bill Vodall]

Post by andrewemt
Well, nothing says we have to stay at 1200 baud. There have been 9600 baud
amateur radio modems around for over a decade.

There have been 19.2K (Kantronics) and 56K modems for over two
decades. 9k6 significantly longer..

http://www.wa4dsy.net/rfmodem.html

Argent Data's T3-9670 (9k6+ on 440 for less than $100) may break
things loose. The (mythical) UDR-X would help even more if it ever
hits the market.

Post by andrewemt
(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.

Like DAMA? Also 2+ decades.

Post by andrewemt
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.

Yes.
We have the technology - just not the use case nor the will...

Bill, WA7NWP - and I'm the optimist...

[Stephen H. Smith]

Post by andrewemt
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.

NO! Ham-style G3RUH 9600 baud modulation (direct binary FSK modulation of
the FM carrier) as used in off-the-shelf "9600-baud packet" (i.e. like the
Kenwood and Yaesu APRS radios at 9600) is now a definite NO-NO in any of the
non-ham spectrum under control of the US FCC. It completely fills a 25
KHz-wide channel.

For the last year and a half, the FCC has required 12.5 KHz channel spacing in
the land-mobile bands. The so-called "narrow-banding" mandate, effective Jan 1
2013, has forced ALL classic "5 KHz deviation" 20 or 25 KHz-spaced channels
to be CUT IN HALF. This means essentially 2.5 KHz deviation on analog voice,
and complex modulation schemes and emission masks for digital that keep all
modulation products and sidebands within +/- 6.25 KHz of the carrier.

In the indeterminate future (5-10 years ??), the FCC plans to split the
channels AGAIN to 6.25 KHz spacing!!

We hams have the luxury of NOT being under the narrow-banding mandate that
every-one else is, and still being able to use wider-band channels.



Schemes like P25 and DMR (Digital Mobile Radio a.k.a. "MotoTrbo") digital voice
radio use 4-frequency or more FSK or QPSK modulation schemes with very
elaborate pulse-shaping to cram a raw 9600 BPS bit rate into these narrow
channels. This after very intricate computation to decompose analog voice into
a 2400 bps or 4800 bps raw data stream.

This is possible only with massive amounts of digital signal processing at both
the TX and RX end. The radio amounts to a fairly high-powered computer that
almost incidentally has RF capabilities.

On top of this, because rather-high bit-error rates occur on RF channels where
signals are subjected to multipath distortion, fading and just plain noise
(compared to wired Ethernet, etc) the desired data to be transmitted is
surrounded in massive multiple-layers of forward-error-correction coding. FEC
allows damaged packets to be "fixed" at the receiving end without
retransmission; a key requirement for real-time non-stop digital voice
transmission. But the overhead of this "packing-for-shipment" coding is
horrendous. It reduces the net data throughput 50%! The "9600 BPS" transport
stream of P25 only delivers a net 4800 BPS data rate!

The impact of this is:

- Power consumption from the intensive computing required along with the
traditional RF components dramatically reduces battery life of hand-helds.

- The usable range for a given band, transmit power and antenna is sharply
reduced, compared to analog voice or even classic 1200-baud packet. Typically
you will require TWO or THREE times as many base stations & repeaters to
achieve the same coverage footprint as with analog systems.

This is due to the "all-or-nothing" nature of digital systems. There IS NO
gradually-degrading-but-still-usable fringe-area reception, as in analog
systems. Once the bit-error rate at the receive end exceeds the ability of any
FEC schemes used to recover missing bits, you "fall-off-the-edge-of-the-world"
data-wise. (The result is the same hiccupping, stuttering or complete silence
you get with digital cell phones when you get too far away from the cell site.)
You must have basically what amounts to "full-smash" hard-quieted signal
levels on analog systems, throughout the intended system coverage area,
before narrow-digital will work consistently and reliably.

Bear in mind that public cellular networks have MASSIVE MASSIVE base-station
infrastructure, with a base station typically every 2-3 miles or less.
Public-safety and customary land-mobile networks, by contrast, typically have
base station and repeater infrastructure 10s of miles apart. This makes a
night-and-day difference in the practicality of low-power digital user
terminals (i.e. hand-helds).

_________________________________________________________


Stephen H. Smith wa8lmf (at) aol.com
Skype: WA8LMF
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net

Live Off-The-Air APRS Activity Maps
<http://wa8lmf.net/map>

Long-Range APRS on 30 Meters HF
<http://wa8lmf.net/aprs/HF_APRS_Notes.htm>

[andrewemt]

Uh, if the digi (as opposed to a human administrator) specifies the timeslot for each tracker, then those trackers have to be two-way (not transmit-only) in order to be able to hear their assignments. Pretty much eliminates all current dedicated trackers, since they can't receive.

And, as you point out, you still have the hidden transmitter problem if you have any central authority (such as your suggested digi) handing out slot assignments, and it can't hear every tracker.

Split frequencies only help a little if there is no coordination among all the trackers, and the digis will just copy the chaos to their output frequency.

Assuming we _can_ get two-way trackers that can listen for assignments, is the AIS protocol still patented somewhere in the world (despite the US government overturning the patent in the US)? I wouldn't want to implement something that would get some users in trouble due to patent infringement.

Just wondering if it's worth trying to implement a dynamic time-slotting (as opposed to the existing static time-slotting the transmit-only trackers use), and whether it could successfully coexist with existing legacy transmit-whenever-I-want-to units.

Andrew, KA2DDO

-------- Original message --------
From: Scott Miller <scott-***@public.gmane.org>
Date:09/08/2014 13:53 (GMT-05:00)
To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Cc:
Subject: Re: [aprssig] Digital two-way Radio communication in emergency situations

Post by Stephen H. Smith

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.

That's not exactly what I meant... though for the Burning Man project I
was working on slotted digis that would aggregate traffic over a 5
second period and transmit everything within a dedicated 1-second digi slot.

The problem I'm talking about is if you have a digi acting as a channel
access control authority and assigning slots to trackers. You don't
want the same slot on the same channel being used by different trackers
in overlapping digi coverage areas.

Scott
N1VG

[Scott Miller]

Post by andrewemt
Uh, if the digi (as opposed to a human administrator) specifies the
timeslot for each tracker, then those trackers have to be two-way (not
transmit-only) in order to be able to hear their assignments. Pretty
much eliminates all current dedicated trackers, since they can't receive.
And, as you point out, you still have the hidden transmitter problem if
you have any central authority (such as your suggested digi) handing out
slot assignments, and it can't hear every tracker.

Let's say every even-numbered second is allocated to non-coordinated
trackers. If you don't have receive capability or haven't heard from a
coordinating authority, you transmit only in a randomized even-numbered
slot. For truly deaf trackers, assuming equal-sized packets and all
that, your channel capacity is doubled using slotted ALOHA vs unslotted
so you can still carry as many non-coordinated trackers as before.

If you have receive capability, maybe you set a bit in the
non-coordinated packet to indicate you're willing to accept
coordination. A coordinating digi offers a slot and you can accept it
or not.

Post by andrewemt
Split frequencies only help a little if there is no coordination among
all the trackers, and the digis will just copy the chaos to their output
frequency.

Digis can coordinate amongst themselves more reliably that mobile
stations. They're typically fixed, in good locations, and up for long
periods. They could much more easily coordinate time slots, and could
rely on carrier detect more. For example, digi A might always start
transmissions in even seconds, and digi B in odd seconds. They'll never
start transmitting at the same time, and can hold off if the other digi
has more than a second's worth of traffic to disgorge. Slotting the
digis also reduces channel overhead by giving them a chance to aggregate
traffic on the input channel. It introduces a bit of latency, but I'll
take a hit of a few seconds for the sake of greater reliability and
capacity.

Post by andrewemt
Assuming we _can_ get two-way trackers that can listen for assignments,
is the AIS protocol still patented somewhere in the world (despite the
US government overturning the patent in the US)? I wouldn't want to
implement something that would get some users in trouble due to patent
infringement.

What specific claims are made by the AIS patent(s)?

Post by andrewemt
Just wondering if it's worth trying to implement a dynamic time-slotting
(as opposed to the existing static time-slotting the transmit-only
trackers use), and whether it could successfully coexist with existing
legacy transmit-whenever-I-want-to units.

Again, I'd like to see a new channel only allow units with a certain
level of smarts, including GPS-synchronized time slotting. You could
add a flag to the protocol to indicate compliance so no one's tempted to
dump their non-compliant tracker on the new frequency and stomp on the
other traffic.

Scott
N1VG

[Brian Webster]

Would Flexnet be something that could be a starting point? I know that in a
connected packet environment it dynamically changes packet sizes and such
based on what it detects for channel activity and retries.

http://www.afthd.tu-darmstadt.de/~flexnet/

Thank You,
Brian N2KGC


-----Original Message-----
From: aprssig-bounces-***@public.gmane.org [mailto:aprssig-bounces-***@public.gmane.org] On Behalf
Of Scott Miller
Sent: Monday, September 08, 2014 4:43 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Digital two-way Radio communication in emergency
situations

Post by andrewemt
Uh, if the digi (as opposed to a human administrator) specifies the
timeslot for each tracker, then those trackers have to be two-way (not
transmit-only) in order to be able to hear their assignments. Pretty
much eliminates all current dedicated trackers, since they can't receive.
And, as you point out, you still have the hidden transmitter problem
if you have any central authority (such as your suggested digi)
handing out slot assignments, and it can't hear every tracker.

Let's say every even-numbered second is allocated to non-coordinated
trackers. If you don't have receive capability or haven't heard from a
coordinating authority, you transmit only in a randomized even-numbered
slot. For truly deaf trackers, assuming equal-sized packets and all that,
your channel capacity is doubled using slotted ALOHA vs unslotted so you can
still carry as many non-coordinated trackers as before.

If you have receive capability, maybe you set a bit in the non-coordinated
packet to indicate you're willing to accept coordination. A coordinating
digi offers a slot and you can accept it or not.

Post by andrewemt
Split frequencies only help a little if there is no coordination among
all the trackers, and the digis will just copy the chaos to their
output frequency.

Digis can coordinate amongst themselves more reliably that mobile stations.
They're typically fixed, in good locations, and up for long periods. They
could much more easily coordinate time slots, and could rely on carrier
detect more. For example, digi A might always start transmissions in even
seconds, and digi B in odd seconds. They'll never start transmitting at the
same time, and can hold off if the other digi has more than a second's worth
of traffic to disgorge. Slotting the digis also reduces channel overhead by
giving them a chance to aggregate traffic on the input channel. It
introduces a bit of latency, but I'll take a hit of a few seconds for the
sake of greater reliability and capacity.

Post by andrewemt
Assuming we _can_ get two-way trackers that can listen for
assignments, is the AIS protocol still patented somewhere in the world
(despite the US government overturning the patent in the US)? I
wouldn't want to implement something that would get some users in
trouble due to patent infringement.

What specific claims are made by the AIS patent(s)?

Post by andrewemt
Just wondering if it's worth trying to implement a dynamic
time-slotting (as opposed to the existing static time-slotting the
transmit-only trackers use), and whether it could successfully coexist
with existing legacy transmit-whenever-I-want-to units.

Again, I'd like to see a new channel only allow units with a certain level
of smarts, including GPS-synchronized time slotting. You could add a flag
to the protocol to indicate compliance so no one's tempted to dump their
non-compliant tracker on the new frequency and stomp on the other traffic.

Scott
N1VG