Discussion:
Digital two-way Radio communication in emergency situations
andrewemt
2014-09-05 18:22:10 UTC
Permalink
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-***@public.gmane.org>
Date:09/05/2014 13:42 (GMT-05:00)
To: TAPR APRS Mailing List <aprssig-***@public.gmane.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
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
andrewemt
2014-09-05 19:07:29 UTC
Permalink
Note also that the cellular systems have full-duplex transceivers using very stringent subchannel and timeslot assignments to jam so many high-bandwidth smartphones into one serving cell (basestation coverage area), prohibiting direct mobile-to-mobile communications (all is relayed through the basestation). Again, the central control.

But, regarding bandwidth, there are numerous higher-efficiency encodings than Bell 202 or G3RUH. Look at the menu in Fldigi. We just need one tuned for packet instead of RTTY, and accept that it won't be backwards compatible with Bell 202.

That, and we have to better solve the channel access problem, to get better use of what bandwidth we do have, per Scott's observation.

Andrew, KA2DDO-------- Original message --------
From: "Stephen H. Smith" <wa8lmf2-***@public.gmane.org>
Date:09/05/2014 14:38 (GMT-05:00)
To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Cc:
Subject: Re: [aprssig] Digital two-way Radio communication in emergency situations
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>
Heikki Hannikainen
2014-09-06 03:42:28 UTC
Permalink
Post by andrewemt
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.
By the way:

The United States Patent and Trademark Office (USPTO) canceled all claims
in the original patent on March 30, 2010.

USPTO ex-parte reexamination certificate (7428th), issued on March 30, 2010

(Source: wikipedia, but I think I saw/read the USPTO documents back in
2010, it was news then)
Post by andrewemt
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).
AIS supports a few different sizes, the shorter position packets are sent
often, and every now and then the station reserves a larger slot for
sending it's full name and/or other information.

- Hessu
andrewemt
2014-09-06 20:13:57 UTC
Permalink
Maybe the US overturned the patent, but did other countries overturn theirs? I thought AIS was originally a Swedish invention.


-------- Original message --------
From: Heikki Hannikainen <hessu-***@public.gmane.org>
Date:09/05/2014 23:48 (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 andrewemt
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.
By the way:

The United States Patent and Trademark Office (USPTO) canceled all claims
in the original patent on March 30, 2010.

USPTO ex-parte reexamination certificate (7428th), issued on March 30, 2010

(Source: wikipedia, but I think I saw/read the USPTO documents back in
2010, it was news then)
Post by andrewemt
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).
AIS supports a few different sizes, the shorter position packets are sent
often, and every now and then the station reserves a larger slot for
sending it's full name and/or other information.

- Hessu
SARTrack Admin
2014-09-08 07:11:40 UTC
Permalink
Thanks everyone for their input.

I am still looking for a digital transmission unit which can transmit
data in a higer modulation scheme.
I actually just found an interesting company who sells just that, but I
assume this gear is going to be very expensive. They use OFDM on Time
Division Multiplex 256-QAM modulation, which enables them to transmit up
to 56Kb on a 12.5 Kc channel, but it would require a huge amount of FEC.
I would think something like 8PSK would be more suitable for what I have
in mind.

Anyway, its interesting stuff.

Thanks,

SARTrack Developer and CEO
Curt, WE7U
2014-09-08 15:50:19 UTC
Permalink
Post by SARTrack Admin
Thanks everyone for their input.
I am still looking for a digital transmission unit which can transmit data in
a higer modulation scheme.
I actually just found an interesting company who sells just that, but I
assume this gear is going to be very expensive. They use OFDM on Time
Division Multiplex 256-QAM modulation, which enables them to transmit up to
56Kb on a 12.5 Kc channel, but it would require a huge amount of FEC. I would
think something like 8PSK would be more suitable for what I have in mind.
Anyone send you this link?

http://nwdigitalradio.com/

This hasn't come out yet, but should be out sometime in the coming months. I'm on the pre-order list.

I plan to use it for TCP/IP applications and experimentation. Runs Linux inside.
--
Curt, WE7U. http://wetnet.net/~we7u
APRS Client Capabilities: http://wetnet.net/~we7u/aprs_capabilities.html
Scott Miller
2014-09-08 16:07:56 UTC
Permalink
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
Post by andrewemt
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 --------
Date:09/05/2014 13:42 (GMT-05:00)
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
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
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
Bill Vodall
2014-09-08 18:12:22 UTC
Permalink
Post by Scott Miller
The 1/4 second time slot at 9600 baud
Now that you're home and hopefully recovered from all the burning man
fun - what's the chance of getting some higher speeds going on the
T3-9670?

Bill
Scott Miller
2014-09-08 18:15:40 UTC
Permalink
I just need some time for testing. Doesn't seem to be much call for
backward compatibility with other gear, though - there's not a lot out
there above 9600.

Scott
N1VG
Post by Bill Vodall
Post by Scott Miller
The 1/4 second time slot at 9600 baud
Now that you're home and hopefully recovered from all the burning man
fun - what's the chance of getting some higher speeds going on the
T3-9670?
Bill
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
Bill Vodall
2014-09-08 18:19:02 UTC
Permalink
Post by Scott Miller
I just need some time for testing. Doesn't seem to be much call for
backward compatibility with other gear, though - there's not a lot out there
above 9600.
Right. Don't look back - lets see what we can do going forward..

It would be very nice to be compatible with the (mythical) UDX-R if it
ever comes out and gets going faster than 9600.

Bill
Post by Scott Miller
Scott
N1VG
Post by Bill Vodall
Post by Scott Miller
The 1/4 second time slot at 9600 baud
Now that you're home and hopefully recovered from all the burning man
fun - what's the chance of getting some higher speeds going on the
T3-9670?
Bill
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
Robert Bruninga
2014-09-08 16:20:25 UTC
Permalink
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
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 --------
Date:09/05/2014 13:42 (GMT-05:00)
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
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
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
Jason KG4WSV
2014-09-08 17:30:20 UTC
Permalink
Post by Robert Bruninga
An easy fix for purpose built nets for special events is to eliminate that
problem by using split freqs.
That's not a useful solution for the general case.

-Jason
Scott Miller
2014-09-08 17:52:59 UTC
Permalink
Post by andrewemt
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
Loading...