<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
The ID-1 has one of those cell-phone-like "3 bars" scales for signal
strength. When I set my home to ping the DEM (via the ID-1 radios),
the DEM ID-1 would sometimes show one bar (with no response), and
then on the next ping (one second later) show three bars, with a
reply being transmitted. At the time, there was no rain or
appreciable wind, but obviously something on the path was varying
the signal strength. When we tried FM voice a couple months ago
(to evaluate the path for the 5SHPn), it was virtually free of
noise; I don't recall if we tried DV voice.<br>
<br>
<div class="moz-cite-prefix">On 2014-05-28 20:27, Bart Kus wrote:<br>
</div>
<blockquote cite="mid:5386A90D.2090004@bartk.us" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Well yeah, you can't have ping
without arp first, unless you configure static arp entries. :)<br>
<br>
So it looks like the protocol does support 1/2 FEC, and also
enforces an FCS (CRC). The FEC starts after clock recovery and
frame synch, which is optimal.<br>
<br>
Forget the FM receive thing, all I really wanted to know is what
the SNR of the 1.2GHz signal you get from Paine? If the ID-1
doesn't tell you this, an RTL-SDR should. Does the link work in
4.8kbit mode? I'm assuming you have both sides set for 128kbit
right now.<br>
<br>
--Bart<br>
<br>
On 5/28/2014 7:20 PM, Dean Gibson AE7Q wrote:<br>
</div>
<blockquote cite="mid:53869963.4060202@ae7q.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
See <a moz-do-not-send="true" 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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
PSDR mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
PSDR mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a>
<a class="moz-txt-link-freetext" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
</body>
</html>