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

Dean Gibson AE7Q hamwan at ae7q.com
Mon May 26 15:15:14 PDT 2014


If you want to try to PING the ID-1 at Snohomish County DEM, try the 
following settings:

In your ID-1:

  * Mode: DD
  * Frequency: 1297.750


In your router:

  * IP address: 172.20.10.2 (this is unique for you)
  * Netmask: 255.255.0.0
  * Gateway: 172.20.20.254
  * DNS servers: (doesn't matter at this point)


Let me know how it goes ...

-- Dean

On 2014-05-26 11:14, Bob wrote:
>
> It was over four years ago that I started this project.  At the time 
> my knowledge of networking was 2 of a scale of 10. Today I might be a 
> 3.5; still have a lot to learn.
>
> Initially I had a XP lap top connected directly to the ID-1. It was 
> configured the same as the router below.
>
> I started by pinging the gateway.  LWHC has a number of IP addresses 
> assigned, not all will reply to a pings.
>
> I use "ping 10.0.0.1"  (basic garden variety ping) to determine if I 
> had a usable path.
>
> I then "ping Comcast.net" and got an average reply time of 243ms 
> through the ID-1 and K7LWH-DD.  This compares to a Concast.net ping 
> using my commercial (Comcast) account of 98ms.
>
> I then connected to Bing.com, Google.com and ARRL.org through K7LWH-DD 
> using Internet Explorer.  The performance, subjectively, was a little 
> better than a dial up connection.
>
> I stopped most work on our high speed data project in early 2012.   I 
> reactivated it as a feasibility study rather than an implementation 
> project.
>
> I now have the ID-1 connected to a router.  With a Windows7 computer 
> connected to the router, I can "ping 10.0.0.1" with average times 
> between 110 and 120 ms.  Internet Explore does not connect to Bing, 
> Google, nor ARRL.org  and Packlink indicates that it cannot find a 
> path to a Winlink CMS but somehow messages get to the CMS via telnet 
> connection.
>
> Anyhow, at least for now, we have an alternate path to get emails out 
> of Kirkland if we lose Internet at the City Hall.  I am changing the 
> focus of high speed data transfer away from the ID-1 to HamWAN and 
>  NW-MESH.
>
> Regards
>
> Bob -- KE7JL
>
>
> *From:*PSDR [mailto:psdr-bounces at hamwan.org] *On Behalf Of *Dean 
> Gibson AE7Q
> *Sent:* Monday, May 26, 2014 9:01 AM
> *To:* Puget Sound Data Ring
> *Subject:* Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN 
> network at Paine]
>
> Ah, I'd like the IP address you are PINGing.  What do you type after 
> the command "ping"?
>
> On 2014-05-25 10:22, Bob wrote:
>
>     The router is setup as follows:
>
>     IP: 10.136.19.168
>
>     Sub Mask: 255.0.0.0
>
>     Gateway: 10.0.0.1
>
>     DNS: 10.0.0.2
>
>     Alt: 10.0.0.1
>
>     Bob
>
>     *From:*PSDR [mailto:psdr-bounces at hamwan.org] *On Behalf Of *Dean
>     Gibson AE7Q
>     *Sent:* Saturday, May 24, 2014 9:33 PM
>     *To:* Puget Sound Data Ring
>     *Subject:* Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN
>     network at Paine]
>
>     When you attempt to ping using the K7LWH/DD module, what IP
>     address do you specify?
>
>     On 2014-05-24 14:36, Bob wrote:
>
>         Dean,
>
>         Here are some observations and conclusion that I have come up
>         with in adding the ID-1 to the Kirkland Emergency
>         Communications Team's tool box.  I have done a number of tests
>         of the ID-1 from various locations in Kirkland in both the
>         Digital Data (DD) mode and the Digital Voice (DV) mode.  I
>         tested simplex paths (ID-1 to ID-1) and paths to the Lake
>         Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway
>         nodes in Bellevue.
>
>         1.There are a few locations in Kirkland that have direct
>         visual line of site to LWHC Gateway in Belleview.  From those
>         locations, pings are consistently returned in 100 to 200ms
>         with an occasional loss.
>
>         2.We have two location (Stations 22 and 25) are not visual but
>         according to Radio Mobile modeling skim the terrain.  At these
>         sights no ping are returned.
>
>         3.At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a
>         visual of the LWHC Gateway, but I get occasional pings returned.
>
>         4.John Hays loan me a 1.23 GHz directional antenna. With the
>         directional antenna I detected two paths to the gateway. One
>         was off a condo about 180 degrees from the gateway about a
>         mile away; the other was off the NOAA building four miles awat
>         at Sand Point about 15 degrees clockwise from the gateway. 
>         This indicates the presents of multi-paths that could be
>         interfering with the data even with good signal strength.
>
>         5.I will also confirm the DV mode is more robust than the DD
>         mode, but it too is affect by multi-path.
>
>         About 2 weeks ago I brought the ID-1 on line to serve as an
>         alternate path to the Winlink CMS.
>
>         Bob -- KE7JL
>
>         *From:*PSDR [mailto:psdr-bounces at hamwan.org] *On Behalf Of
>         *Dean Gibson AE7Q
>         *Sent:* Saturday, May 24, 2014 10:20 AM
>         *To:* Puget Sound Data Ring
>         *Subject:* [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN
>         network at Paine]
>
>         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/20140526/2e88091e/attachment.html>


More information about the PSDR mailing list