<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
See <a class="moz-txt-link-freetext" href="http://www.arrl.org/files/file/D-STAR.pdf">http://www.arrl.org/files/file/D-STAR.pdf</a> - pages 3-5 describe
the DD-mode (data) packet.<br>
<br>
The ID-1 apparently doesn't know whether or not the Ethernet frame
is corrupt. From the TX/RX lights for both the radio and the
Ethernet connection, it appears that every received packet from one
end, goes out the other.<br>
<br>
When conditions are right and I receive about 10% of the packets
from a PING (like last Monday), it seems clear from observed
behavior that once an ARP response is received, then quite a few
PINGs get through. I haven't tried listening on FM to a DD packet,
but I can try that on Thursday, when I am at the DEM. I'm not sure
what the point of that would be, though.<br>
<br>
<div class="moz-cite-prefix">On 2014-05-28 17:12, Bart Kus wrote:<br>
</div>
<blockquote cite="mid:53867B80.7090000@bartk.us" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">This is some really broad strokes.
Are there specifics on ID-1 protocol / framing somewhere?<br>
<br>
--Bart<br>
<br>
On 5/27/2014 4:59 PM, John D. Hays wrote:<br>
</div>
<blockquote
cite="mid:CAN77r3zvJVW14KuAzpSMBXBXDtKp4xfDxHhNAwfzh+1q1QLKSg@mail.gmail.com"
type="cite">
<div dir="ltr">ID-1 simply encapsulates an Ethernet frame behind
a D-STAR header. The header has some correction, but the
Ethernet frame is not corrected by D-STAR.</div>
<div class="gmail_extra"><br>
<div>
<hr>
<div style="float:left;padding-left:1em;color:blue">John D.
Hays<br>
<span style="color:rgb(128,128,128)">K7VE</span></div>
<div style="float:right;text-align:right">PO Box 1223,
Edmonds, WA 98020-1223
<div style="padding-top:0.5em"> <a moz-do-not-send="true"
href="http://k7ve.org/blog" target="_blank"><img
moz-do-not-send="true"
src="http://k7ve.org/images/blog-icon-box-red-26.png"></a> <a
moz-do-not-send="true"
href="http://twitter.com/#%21/john_hays"
target="_blank"><img moz-do-not-send="true"
src="http://k7ve.org/images/Twitter-26.png"></a> <a
moz-do-not-send="true"
href="http://www.facebook.com/john.d.hays"
target="_blank"><img moz-do-not-send="true"
src="http://k7ve.org/images/Facebook-26.png"></a></div>
</div>
</div>
<br>
<br>
<div class="gmail_quote">On Tue, May 27, 2014 at 4:28 PM, Bart
Kus <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> There's no protocol
I'm aware of that implements these features on top of
ID-1. You'd need the ability to receive corrupt frames
from the ID1 to allow the use of FEC. How does the ID1
handle corrupt frames? Is there a CRC or something in
the framing? For ARQ, you could keep the TX retrying
until it hears an ACK or times out. Custom software
would be needed, or perhaps pppd can do such tricks, I
dunno.<br>
<br>
Did you hear any signal when you listened with an FM
receiver? Can you use an RTL-SDR or equivalent to see
if there's any signal present?<br>
<br>
--Bart<br>
<br>
<div>On 5/24/2014 8:36 PM, Dean Gibson AE7Q wrote:<br>
</div>
<blockquote type="cite"> That's what I figured
("features [that] are common to all WiFi systems"); it
just made sense (although that is not always
determinative!).<br>
<br>
So, my next question: Is there an available tunneling
protocol that employs those features?<br>
<br>
Note that with the ID-1 in the <b>one watt</b>
setting (same omni antenna), I can use the 1.2GHz
KB7CNN repeater 35 miles away on East Tiger mountain,
with no noise in the FM signal. The link to Paine (5
miles away) was tried at max power (ten watts) on both
radios. I tried two different frequencies (that's the
beauty of being able to control both radios from one
location!): 1.250GHz and 1.249GHz (I listened on both
in FM mode), with no significant difference. So, in
my opinion, it's a path problem.<br>
<br>
<div>On 2014-05-24 13:13, Bart Kus wrote:<br>
</div>
<blockquote type="cite">
<div>Wow that sucks. :( Is the signal level just
too low? Is it a matter of interference?<br>
<br>
And yeah, I can confirm that the microwave stuff
we use includes both FEC (at up to 1/2 rate) and
an ARQ system (look at "hw-retries" setting).
These features are common to all WiFi systems too,
and they're just carried over into our NV2 TDMA
system.<br>
<br>
--Bart<br>
<br>
On 5/24/2014 10:19 AM, Dean Gibson AE7Q wrote:<br>
</div>
<blockquote type="cite"> Scott Honaker and I have
moved forward on this project:<br>
<ol>
<li>We have installed a gateway (Linksys
BEFSR41) between the ID-1 and the internal
ARES/RACES subnet (not 44.x.x.x) of the DEM.</li>
<li>We have installed a Digi "AnywhereUSB" box
to give us remote access to the ID-1's USB
port, and thus remote control of the ID-1
radio. This not only allows multiple use of
the ID-1 (which has useful 1.2GHz FM and
digital voice modes as well as Ethernet data),
but provides for remote frequency agility and
a diagnostic capability. This works
beautifully (eg, to search for and use a
low-noise frequency)!</li>
</ol>
<p>Unfortunately, what does not work very well, is
the RF portion of the connection. PINGs failed
at a rate of over 99% when using the 1.2GHz
antenna at the 70 ft level on the tower, so we
swapped the antenna with the one used for the
Icom 1.2GHz repeater (which wasn't seeing any
action anyway) at 100 ft. That made a
"dramatic" improvement, as PINGs now only fail
at a 98% rate (depends upon the time of day,
etc)!<br>
</p>
<p>Antenna comparison between 1.2GHz and 5.9 GHz
for the two sites:<br>
</p>
<ol>
<li>On 1.2GHz, both antennas are
omni-directional.</li>
<li>At the DEM, the 1.2GHz antenna is now at the
100' level, whereas the 5.9GHz antenna is at
150'.</li>
<li>At my home, the 1.2GHz antenna is about 10'
above the 5.9GHz antenna, and it's on the same
line-of-sight path.</li>
</ol>
<p>Note that voice communication between the two
sites using the two ID-1 radios, is fine (there
is a slight bit of noise on FM).<br>
</p>
<p>The big difference, in my opinion? I'll bet
that the wireless protocol used by the MikroTik
radios includes an aggressive error correction
and retry protocol, whereas the ID-1 is like a
piece of Ethernet cable, and thus relies on the
standard TCP/IP retry mechanism. The TCP/IP
protocols, while "unreliable" in the technical
sense of the term, require a higher overall
reliability than a typical raw wireless
connection.<br>
</p>
<p>What this says (and I'm a bit surprised to note
this), is that sites considering using ID-1
radios for data communications, may find that
even with the tighter siting requirements of
5.9GHz, that the latter may be more successful
(whether or not part of HamWAN). In addition to
being a lower-cost radio with a much higher data
rate, the MikroTik radios offer a built-in
router, which can obviate the need for a
separate router.<br>
</p>
<p>-- Dean<br>
</p>
<p>ps: The callsign and digital code filtering
features of D-Star that we previously discussed,
are not available (greyed out in the software)
for digital <b>data</b> mode. Huh? Another
fine example of software of the "seven last
words" of poor program design: <b>"Why would
you want to do that?"</b></p>
</blockquote>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>