[HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]

[Dean Gibson AE7Q]

See http://www.arrl.org/files/file/D-STAR.pdf - pages 3-5 describe the 
DD-mode (data) packet.

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.

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.

On 2014-05-28 17:12, Bart Kus wrote:
> This is some really broad strokes. Are there specifics on ID-1 
> protocol / framing somewhere?
>
> --Bart
>
> On 5/27/2014 4:59 PM, John D. Hays wrote:
>> 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.
>>
>> ------------------------------------------------------------------------
>> John D. Hays
>> K7VE
>> PO Box 1223, Edmonds, WA 98020-1223
>> <http://k7ve.org/blog> <http://twitter.com/#%21/john_hays> 
>> <http://www.facebook.com/john.d.hays>
>>
>>
>> On Tue, May 27, 2014 at 4:28 PM, Bart Kus <me at bartk.us 
>> <mailto:me at bartk.us>> wrote:
>>
>>     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.
>>
>>     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?
>>
>>     --Bart
>>
>>     On 5/24/2014 8:36 PM, Dean Gibson AE7Q wrote:
>>>     That's what I figured ("features [that] are common to all WiFi
>>>     systems"); it just made sense (although that is not always
>>>     determinative!).
>>>
>>>     So, my next question:  Is there an available tunneling protocol
>>>     that employs those features?
>>>
>>>     Note that with the ID-1 in the *one watt* 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.
>>>
>>>     On 2014-05-24 13:13, Bart Kus wrote:
>>>>     Wow that sucks.  :(  Is the signal level just too low?  Is it a
>>>>     matter of interference?
>>>>
>>>>     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.
>>>>
>>>>     --Bart
>>>>
>>>>     On 5/24/2014 10:19 AM, Dean Gibson AE7Q wrote:
>>>>>     Scott Honaker and I have moved forward on this project:
>>>>>
>>>>>      1. 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.
>>>>>      2. 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)!
>>>>>
>>>>>     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)!
>>>>>
>>>>>     Antenna comparison between 1.2GHz and 5.9 GHz for the two sites:
>>>>>
>>>>>      1. On 1.2GHz, both antennas are omni-directional.
>>>>>      2. At the DEM, the 1.2GHz antenna is now at the 100' level,
>>>>>         whereas the 5.9GHz antenna is at 150'.
>>>>>      3. 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.
>>>>>
>>>>>     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).
>>>>>
>>>>>     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.
>>>>>
>>>>>     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.
>>>>>
>>>>>     -- Dean
>>>>>
>>>>>     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 *data* mode.  Huh?  Another fine
>>>>>     example of software of the "seven last words" of poor program
>>>>>     design: *"Why would you want to do that?"*
>>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20140528/61700727/attachment.html>