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