- PSDR - mailman.hamwan.org

An important note on RF safety and human exposure limits
by Bart Kus 29 Aug '14

29 Aug '14

http://englishrussia.com/2012/12/23/listening-to-the-radio-with-help-of-gra… --Bart

1 0

Switch to 10 MHz channel plan ACTION REQUIRED
by Tom Hayward 09 Aug '14

09 Aug '14

We will be switching the network from the 5 MHz channel plan to the 10 MHz channel plan. This affects sectors and client nodes. Client nodes that are live on the network and have shared administration enabled will be updated automatically. Other clients will need to update their own channel list. With the following channels configured in your modem, it will scan for the new channel as soon as the old channel disappears: /interface wireless channels # Current 5 MHz plan add band=5ghz-onlyn comment="Cell sites radiate this at 0 degrees (north)" frequency=5920 list=HamWAN name=Sector1 width=5 add band=5ghz-onlyn comment="Cell sites radiate this at 120 degrees (south-east)" frequency=5905 list=HamWAN name=Sector2 width=5 add band=5ghz-onlyn comment="Cell sites radiate this at 240 degrees (south-west)" frequency=5890 list=HamWAN name=Sector3 width=5 # New 5 MHz bandwidth in 10 MHz channel plan (first channel is identical to old 5 MHz plan) add band=5ghz-onlyn comment="Cell sites radiate this at 0 degrees (north)" frequency=5920 list=HamWAN name=Sector1-5 width=5 add band=5ghz-onlyn comment="Cell sites radiate this at 120 degrees (south-east)" frequency=5900 list=HamWAN name=Sector2-5 width=5 add band=5ghz-onlyn comment="Cell sites radiate this at 240 degrees (south-west)" frequency=5880 list=HamWAN name=Sector3-5 width=5 # New 10 MHz bandwidth in 10 MHz channel plan add band=5ghz-onlyn comment="Cell sites radiate this at 0 degrees (north)" frequency=5920 list=HamWAN name=Sector1-10 width=10 add band=5ghz-onlyn comment="Cell sites radiate this at 120 degrees (south-east)" frequency=5900 list=HamWAN name=Sector2-10 width=10 add band=5ghz-onlyn comment="Cell sites radiate this at 240 degrees (south-west)" frequency=5880 list=HamWAN name=Sector3-10 width=10 For optimal performance, some sectors will continue to use 5 MHz bandwidth on the new 10 MHz-plan center frequencies. Add all the above channels to ensure your modem will connect in this situation. This change will be implemented in 7 days, August 9th. Please update your configuration before then for a smooth transition. Tom KD7LXL

3 7

Haystack coming up as a 2nd gen site
by Bart Kus 01 Aug '14

01 Aug '14

Hello, After some discussion we decided to deploy Haystack as a 2nd generation site. It has a huge view of the Puget Sound, it will have a very fast uplink (via the new Queen Anne facility), so it will do well with the extra throughput capacity. What this means is: 1) The sector modems are dual-channel (MIMO, RB911) instead of single-channel (SISO, Metal). This, in theory, doubles speed while still using the same bandwidth. 2) The sector antennas are dual-polarity, and higher gain to (mostly) compensate for the power loss of going to the lower-powered MIMO modems 3) The sector antennas and dishes feature shielding materials to minimize interference between the radios 4) All the modems are in metal enclosures to prevent any stray radiation and interference This 2nd gen architecture is fully compatible with 1st and 2nd gen clients. Going to a 2nd gen client may not actually be the speediest thing for you! The 1st gen client setup (Metal 5SHPn + Poynting 30dBi grid) offers better gain + EIRP than a typical RB912 + 2ft dish 2nd gen client setup. That added signal power may actually prove to achieve faster speeds than the added 2nd channel of dual-polarized MIMO signals when your signal levels are low. If your signal levels to the site are high, then switching to a 2nd gen client should be beneficial. I have footed the $601 bill (shipping included) for the upgrade. I have also allocated one of my personal MIMO sector antennas (~$150 value) to the cause. If someone feels like raising a vote to compensate me fully or partially, that'd be awesome. The reason for the rapid action is I got word our site sponsor would like to deploy this weekend. I'm not sure if the hardware will make it in time at this point, but at least I tried. If it doesn't make it, we'll do a 2nd round of deployment later. There's plenty of work to be done at the site with installing the mounting points and solar power system. BTW, if you'd like to volunteer your time and energy, the deployment is sometime this weekend. The mountain is near Sultan, WA. I don't know which day(s) we're going up. Let me know if you'd like to help. Thanks, --Bart

3 4

8dB drop in ten minutes!
by Dean Gibson AE7Q 23 Jul '14

23 Jul '14

This morning (well after the update to v6.15 last night) just after 9:30am, I saw a 8dB drop in both TX and RX signal levels, which persist at this time. I did a "reset configuration", which did not solve the problem. Did anyone do a change at Paine sector 2 around 9:30am?

5 13

Fwd: [44net] 44net and internal BGP tests
by K7VE - John 10 Jul '14

10 Jul '14

------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays> ---------- Forwarded message ---------- From: K7VE - John <k7ve(a)k7ve.org> Date: Thu, Jul 10, 2014 at 10:21 AM Subject: Re: [44net] 44net and internal BGP tests To: AMPRNet working group <44net(a)hamradio.ucsd.edu> These are the applications we need to bring to 44-Net ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays> On Thu, Jul 10, 2014 at 4:56 AM, <lx1duc(a)laru.lu> wrote: > > > We are currently running the following services in our 44net: > > - 2 DMR repeaters > - several D-Star HotSpots > - DNS resolvers open to 44net (Anycasted), secondary DNS Service available > for fellow YLs and OMs > - NTP servers (Anycasted) > - VoIP (SIP) and Jabber (XMPP) server > - VPN > - (planned) APRS Server > - (planned) connect existing APRS I-GATEs > - (planned) Hosting of HAM webs > - (planned) Hosting of HAM email services > > 73 de Marc, LX1DUC > _________________________________________ >

2 1

Switching to the 10MHz frequency plan
by Bart Kus 25 Jun '14

25 Jun '14

Hi, Can I hear any objections to switching to the 10MHz frequency plan? We'd be retaining the 5MHz bandwidths for now to keep the power spectral density high, it would just be moving the center frequencies onto the 10MHz plan. This switch would let us keep those center frequencies through 2 upgrade cycles sometime in the future: 1) Expansion from 5MHz to 10MHz channels 2) Expansion from 10MHz SISO to 10MHz MIMO Presently our speeds are limited to 10Mbit/sector. Upgrade phase 1 would bring us to 20Mbit/sector without any additional hardware costs. Upgrade phase 2 would bring us to 40Mbit/sector with a hardware replacement of sector antennas and sector modems. Hardware in phases 0 (present), 1 and 2 can happily co-exist within the same region if we take this change. If we stick on the 5MHz plan, any 10MHz hardware will interfere. The 20MHz plan collides with other radios present at some of our sites, so expansion to 20MHz will be difficult, if it ever happens at all. The 10MHz plan should be good for the next few years until we find some better solutions should the need for speed be there. Portland is thinking of bringing up a compatible system so that users can roam up and down the coast without re-programming and they've asked for confirmation on the frequencies. The other benefit of coordination onto the same channel plan is the border between the Washington and Oregon systems will not be full of interference. Users could roam between the systems seamlessly. If there are any objections to switching to the 10MHz plan, please speak up. --Bart

5 6

Re: [HamWAN PSDR] Internet Maintenance Notification
by Tom Hayward 16 Jun '14

16 Jun '14

Hi Jann, Our network is happy to receive your packets to 44.24.240.0/20 direct via internet, or IPIP encapsulated via 44.24.221.1. This is a published AMPR gateway (at least, it was listed in the encap a few hours ago when I last checked). We're not asking everyone to use BGP. In fact, we support packets from public/BGP networks and IPIP encapsulated packets alike. There is no spec that says gateways must be outside of 44.0.0.0/8. We picked 44.24.221.1 as a gateway because it fit the needs of our network only to discover later that it doesn't work with all AMPR configurations. There is no technical reason for this limitation; it merely comes down to configuration. I'd like to see the bugs worked out of the configuration so that what we publish to AMPR is honored. Our configuration conforms to the AMPR IPIP mesh design and works well with many existing AMPR networks. I don't know specifically why we can't communicate with your network. If you have manually installed a route to 44.24.240.0/20, that may be the problem. The route as defined in the AMPR encap file should work just fine, or if you like, just send packets out the default gateway and we will receive them via internet routing. Tom KD7LXL On Mon, Jun 16, 2014 at 10:07 PM, Jann Traschewski <jann(a)gmx.de> wrote: > Ooops, it's my gateway. I'm well aware of a missing IPIP route > (44.24.240.0/20 via 44.24.221.1 if I remember right) at DB0FHN. After > half a year I did reboot the machine and didn't reinstall that route > since I didn't expect anyone talking to us... > > The route 44.24.240.0/20 via 44.24.221.1 is very special since nobody > else uses a 44-address as a gateway IP-address for now. Tom might > remember my experiment to manually add this route at DB0FHN. The route > is not published by the AMPR gateway and even if it would publish it, it > would fail for most IPIP-gateways. So I'm pretty sure I was the only > IPIP-gateway supporting communication to 44.24.240.0/20. > > Since DB0FHN is the core router for the IPIP net44 connectivity of the > Hamnet, all Hamnet-Nodes doesn't have a special route to 44.24.240.0/20. > However most Hamnet-Nodes can talk *to* 44.24.240.0/20 since packets > will travel to their next default gateway in that particular region and > then will be processed by SNAT/DNAT or Masqueradeing with commercial IP > addresses. Of course that is not very useful for people coming *from* > 44.24.240.0/20 trying to contact Hamnet-Nodes. That's one of the reason > why I'm promoting the "amateur radio intranet" using net44-ip-addresses > only... > > I even think it isn't very polite to keep asking the rest of the world > to put BGP connected gateways in their area rather than to understand > how many other hosts are really connected to net44 (it is *not* only > some popular AMPR configuration scripts as my example above is showing). > BGP connected gateways are very new in the AMPRNet world and the first > thing I would be interested in if I start with BGP direct connected > networks is "full connectivity" to all hosts on net44. Rather than to > insist in support of IPIP-gateway addresses with net44-addresses I'm > pretty sure there would be a solution to get a *single* commercial > IP-address from the ISP for that purpose. > > I'm really open for respectful discussions and I'm also willing to move > net44 forward (e.g. I support to have net44 IPIP gateways and did test > the functionality at DB0FHN). We recently started to define ranges for > BGP direct connected networks in our IP-address space and already have > the permission to announce one network (two more to come). So we are > constantly moving forward. > > What I'm missing on the net44 discussion list and especially on the > #HamWAN Freenode IRC-channel is fair and respectful treatment of others. > > 73, > Jann > DG8NGN > Ps: I'm going to install the 44.24.240.0/20 route again on Friday since > I have a very important meeting at the european comission in Brussels > regarding the 23-cm-band (Galileo).

1 0

Internet Maintenance Notification
by Tim Osburn 16 Jun '14

16 Jun '14

FYI: I will be moving HamWAN off of the Cisco 7206 and over to the Cisco ASR 9k routers today so it's possible you may see a blip in the internet access if any at all. Tim Osburn www.osburn.com 206.812.6214 W7RSZ

5 6

Network Planning Mtg Sat 9am for New OR/SW Wash Group
by Kenneth Tolliver 16 Jun '14

16 Jun '14

Attached is the flyer for this Saturday's High Speed Digital Ham Network planning meeting. It's from 9am to Noon at the Tigard North Dakota LDS Meetinghouse. 11065 SW North Dakota, Tigard OR 97223. All hams are invited to help us design/plan a new High Speed Digital Network for Hams. We hope it will eventually connect with the Puget Sound HamWAN project in the Seattle Area and run down to at least Albany, Oregon. Hopefully, it will also go east to Hermiston, Oregon; giving coverage along the Columbia Gorge. We will start planning for coverage of the Portland/Vancouver Area. It will use commercial/consumer Microwave equipment on 2.4 GHz, 3.6GHz, and 5.8 GHz. It will be a very fast network. We will need good Node Sites, IP Network Design, and lots of hands on-- try it out stuff. If you are interested in being part of the project in Oregon & SW Washington come to the meeting. You don't have to be a RF Engineer or a Network Nerd; but it sure would help us if you were. There are jobs for every skill level. We need your help. This is not part of HamWAN or NW-MESH. I just thought those groups would have some pepole interested in helping our project. Come help us bring Amateur Radio into the High Speed Digital Era. Nothing is written in stone. Your input is needed. Hope to see you there. 73 Ken Tolliver K7ICY 503-544-7945 Flyer Attached.

1 0

5SHPn v6.15 firmware upgrade
by Dean Gibson AE7Q 13 Jun '14

13 Jun '14

Part of the change log below. What's new in 6.15 (2014-Jun-12 12:25): *) ... What's new in 6.14 (2014-Jun-06 15:34): *) ... *)*ssh server - allow none cipher;* *) ...

2 1