[HamWAN PSDR] Report from Mike and Key Electronics Show and Fleamarket

Ed Morin edmorin.jr at gmail.com
Mon Mar 7 16:04:48 PST 2016 

We have the LoA already having run that gauntlet with Brian and Nigel..  I
didn't realize DHCP was provided; that's great.

So statics are only needed (I presume) for when routing of a client network
is required (or somebody needs a static for a special application such as
hosting.  That's good to know.

On Mon, Mar 7, 2016 at 3:57 PM, Tom Hayward <tom at tomh.us> wrote:

> When you connect to HamWAN you'll get a single address via DHCP. That
> works great for testing and most general use. We also have plenty of
> address space in case your site needs a larger subnet.
>
> To advertise your own /24, we need a Letter of Authorization from the
> owner of the address space. For AMPR addresses, that comes from Brian
> Kantor. If you own the addresses and your name is on file with ARIN, you
> can write the LOA. Nigel usually handles submitting the LOAs to our transit
> providers.
>
> Tom
>
> On Mon, Mar 7, 2016 at 3:43 PM, Ed Morin <edmorin.jr at gmail.com> wrote:
>
>> Yep, agreed.  I'm going to borrow the specified equipment for a portable
>> HamWAN setup, but I think I will need link addresses to use.  We have a /24
>> allocation, but I don't think we need to route it for simple testing and/or
>> NAT via an AP.  If you have the proper contact for that off the top of you
>> head, let me know.  I believe I submitted an application already, so I'll
>> dig in my e-mail for that as well...
>>
>> My plan is to start surveying the stations as well as a few other points
>> of interest (my home of course!).
>>
>> As a side note, down the road, it might be possible to work with HamWAN
>> to deploy a general-purpose cell site in Redmond somewhere; it will take
>> some research as that's beyond my knowledge in terms of permissions
>> process, etc.  I think a case could be made that it would support emcomm
>> around Redmond including ARES.  At any rate, need data and I will certainly
>> share what I find; it'll take a while although I'm sure some of the other
>> ARES members would love to help as it's exciting stuff.  :-)
>>
>>
>>
>> On Mon, Mar 7, 2016 at 2:28 PM, Tom Hayward <tom at tomh.us> wrote:
>>
>>> Ed,
>>>
>>> HamWAN has a relatively new offering we call our Open Peering Policy.
>>> This allows you to multi-home your /24 on our network. After the
>>> appropriate paperwork is filled out with our transit providers and the
>>> owner of the /24, you will be able to announce your /24 over HamWAN and
>>> subsequently HamWAN's Internet transit providers. This will allow HamWAN to
>>> be one piece of your autonomous network.
>>>
>>> You are right that my recommendation would leave you with Haystack as a
>>> single point of failure. My point is you have to start somewhere. Some of
>>> your stations should also be able to see the HamWAN Capitol Park site, so
>>> you have an opportunity for redundancy there. And you're free to create as
>>> many independent links as you want, in due time.
>>>
>>> If any of the sites you have access to have the coverage to serve a
>>> significant number of potential HamWAN users, we could deploy sectors
>>> there. We have also been experimenting with distribution over 900 MHz,
>>> which may work well in your area. HamWAN coverage to Redmond has been poor
>>> for a long time--if you can't see Haystack or Capitol Park, there's no
>>> other option. It would be great to fill some of that area with some new
>>> cell sites (our term for anywhere we deploy sectors).
>>>
>>> Regarding deployment by ARES members: it takes practice! Get some
>>> portable HamWAN stations put together. You can see a photo of mine on the
>>> homepage of hamwan.org:
>>> http://hamwan.org/t/tiki-download_wiki_attachment.php?attId=147 It's
>>> simple, but allows me to go anywhere with a view of the mountains and set
>>> up a HamWAN client in a few minutes. I get a little better at it every
>>> time. It also gets you thinking about how you want to use it--this picture
>>> shows it connected directly to my laptop, but I've practiced setting up
>>> other configurations as well, like a local 2.4 GHz access point for sharing
>>> the HamWAN.
>>>
>>> You've got a lot of great ideas. The next step is to get out there and
>>> build something!
>>>
>>> Tom
>>>
>>> On Mon, Mar 7, 2016 at 12:52 AM, Ed Morin <edmorin.jr at gmail.com> wrote:
>>>
>>>> All great questions Tom!  First off, my answers are not necessarily any
>>>> sort of "gospel" in the matter.  I can answer some of what you are asking,
>>>> but some of these answers are based on "stick in the ground start from
>>>> somewhere" thinking that will almost certainly evolve over time.
>>>>
>>>> 1. Having built an ISP network covering much of the NW back in the
>>>> '90's, one of our core principles was to not wholly depend upon ANY
>>>> networks beyond our own control.  I would not necessarily say an "in-house
>>>> only solution," but rather an "in-house design" that includes redundancy to
>>>> HamWAN's infrastructure.  It's fine to link to Haystack, but what if
>>>> Haystack fails and we don't have other good HamWAN link options??  At this
>>>> point, I do not see a 100% HamWAN solution; more likely a :"HamWAN+"
>>>> solution.  That is to say, I fully expect to have *some* non-HamWAN
>>>> redundancy component (eventually).  "Cheaper" isn't the sole driver, but it
>>>> is certainly a strong consideration.  Getting linked to HamWAN is our first
>>>> priority.  Redundancy routing is desired, but must come later.
>>>>
>>>> 2. Your suggestion of connecting as many stations as possible to
>>>> Haystack is very much worth a serious look.  One of my assumptions thus far
>>>> has been that only a few stations would have a decent HamWAN signal and
>>>> that shorter inter-station paths might perform better.  That is strictly
>>>> assumption which needs to be replaced with hard data.  How redundancy
>>>> routing via non-HamWAN networks also needs to be factored in (eventually).
>>>>
>>>> 3. I totally see, and agree with, your logic -- from a technical point
>>>> of view -- about 2.4 vs 5.9 GHz.  It very much makes sense and squares with
>>>> what I have read and studied.  Not sure about the total cost being lower,
>>>> but that will depend on what we find during surveys and testing along the
>>>> way.
>>>>
>>>> 4. Ok, so your last questions are getting more to what really should
>>>> drive the requirements and discussion.
>>>>
>>>> First off, my experience with building networks is to try and create a
>>>> flexible foundation, but evolve and grow them as time and resources permit.
>>>>  "Phase I" will be quite simple -- just getting some HamWAN connectivity to
>>>> even a few stations would be huge.  I can also envision capabilities I'd
>>>> like to see far beyond that.
>>>>
>>>> My assumptions (yep, more of 'em) for longer-term functionality based
>>>> on various conversations, personal experience, etc. are:
>>>>
>>>> 1. INITIALLY, having at least one PC at each station that is able to
>>>> transfer documents, spreadsheets, pictures, video and maybe even providing
>>>> VoIP and video-conferencing capability.  Eventually, I want to grow this to
>>>> providing an Access-Point that multiple ARES members at the station could
>>>> use simultaneously.  *IF* we went part-15 for inter-station links, then
>>>> non-hams (e.g. other incident staff) could use it as well and the hams in
>>>> the group would manage the HamWAN gateway transition to part-97 governed
>>>> network infrastructure.  Now, that's not necessarily a requirement per se,
>>>> but an interesting consideration.  It is also a HUGE architecture driver as
>>>> the network evolves.  It's not an "out of the shoot" assumption or
>>>> requirement, but I could certainly see it come up for discussion.
>>>>
>>>> 2. The fire stations, being geographically dispersed, would potentially
>>>> make great core sites for linking portable networks using private address
>>>> space at shelters, mobile command posts, etc.  I think having
>>>> infrastructure that is totally tied to the stations would be very limiting
>>>> and potentially frustrating.  That means that the stations themselves might
>>>> potentially have some sort of "sector-based" infrastructure for handling
>>>> these local-area connections.  It would be nice to have a network where
>>>> each station (or several anyway) could run "standalone" on a HamWAN link,
>>>> but also have redundancy to other stations and/or ISP.  That is, they can
>>>> use the highest performing link(s) and have the "other" for fail over.  (I
>>>> am assuming ONE non-HamWAN ISP link somewhere in the network is probably
>>>> sufficient.)  All of this bullet item is way beyond Phase I though.
>>>>
>>>> 3. The above needs to be deployable and maneagable by several ARES team
>>>> members.  People can be a failure point as well, so having features and
>>>> capabilities needs to be weighed against technical and administrative
>>>> complexity.  It will be interesting to see how far we can push it.
>>>>
>>>> 4. In terms of other driving factors, getting stuff mounted on a fire
>>>> station is not easy.  Having something "less obtrusive" bodes better.  As
>>>> much as seeing towers bristling with antennas and dishes supporting
>>>> redundant links and other capabilities is a beautiful thing and a very
>>>> pleasant thought, sadly, most who are on the critical path for success
>>>> don't feel the same.  That means "as low as possible, as unobtrusive as
>>>> possible, as small as possible, as simple as possible, as cheap as
>>>> possible, etc."  You get the idea.  And even *that* list is in conflict
>>>> with itself!  (Smaller isn't always cheaper, etc.)  Some of those "battles"
>>>> can be fought, but from a pragmatic point of view, I'd rather pick them
>>>> based on functionality and effectiveness for fulfilling the needs than my
>>>> own fleeting fantasies.  ;-)
>>>>
>>>> Part of what needs to be understood here is that we've been flogging
>>>> the 1200 baud packet stuff for YEARS.  A number of folks don't (yet)
>>>> understand how having a multi-MEGAbit network will "change everything."
>>>>  All of a sudden, when the paradigm is radically shifted, how we think
>>>> about ARES' function and what can be provided to the city radically
>>>> changes.  Not everybody "gets" that (yet).  But, they will be blown away
>>>> when they do!
>>>>
>>>> So, in a way it's hard to totally articulate a detailed requirement
>>>> because as one begins to understand how radically different things *could*
>>>> be, the requirements will change.  From my own experience, I know that
>>>> having control over redundancy and infrastructure is a Good Thing.  Not out
>>>> of any mistrust or disrespect, but out of best practice.  Having a flexible
>>>> architecture/design that can both accommodate evolving requirements and
>>>> adapt to potentially rapidly changing conditions during a disaster is also
>>>> a Good Thing.
>>>>
>>>> Does that help?
>>>>
>>>>
>>>> On Sun, Mar 6, 2016 at 11:32 PM, Tom Hayward <tom at tomh.us> wrote:
>>>>
>>>>> Ed,
>>>>>
>>>>> It might be time to step back and talk about your goals. I thought we
>>>>> were talking about putting these stations on HamWAN, not creating a
>>>>> new independent network. I'm not opposed to helping you with this
>>>>> plan, but it certainly will be easier (and cheaper!) to lean on our
>>>>> existing infrastructure. I'd start by trying to get as many of the
>>>>> stations connected to Haystack as possible. I think it should work for
>>>>> all but 11.
>>>>>
>>>>> My experience with 2.4 GHz is that it's just really noisy. HamWAN
>>>>> settled on 5.9 GHz for a number of reasons:
>>>>> - ham-only, so relatively lower noise floor
>>>>> - equivalent size dishes will have significantly more gain on 5.9 GHz
>>>>> than 2.4 GHz. This gain happens to be about equal to the increased
>>>>> path loss, meaning you have net zero cost for moving up to the quieter
>>>>> band.
>>>>> - smaller Fresnel zone on 5.9 GHz allows mounting lower on towers and
>>>>> shooting through smaller gaps in trees (as long as there's a gap!)
>>>>> - down in the Part 15 section of the band, there's lots of spectrum
>>>>> for wide-channel, fast point-to-point links
>>>>>
>>>>> What criteria are guiding your triangle-topology design? What types of
>>>>> applications do you want to use this network for? What constraints
>>>>> have you been given (sounds like an in-house solution is preferred)?
>>>>>
>>>>> Tom
>>>>>
>>>>> On Sun, Mar 6, 2016 at 11:00 PM, Ed Morin <edmorin.jr at gmail.com>
>>>>> wrote:
>>>>> > Hi Tom,
>>>>> >
>>>>> > Well, you have been busy!  Thank you for looking into these things
>>>>> -- I know
>>>>> > it can take a while sifting through the possibilities.
>>>>> >
>>>>> > My "stick in the ground" model that I've been presently mulling is a
>>>>> > "hub-and-spoke" sort of setup -- at least from a theoretical point
>>>>> of view
>>>>> > because it sure doesn't resemble one on paper!  (Owing to the
>>>>> geography of
>>>>> > course...)
>>>>> >
>>>>> > Core triangle of 12, 13, and 17 for reasons stated earlier -- UNLESS
>>>>> one of
>>>>> > the other stations ends up having a "better" link
>>>>> > Station 14 would hang off 12 (and possibly have a HamWAN link as
>>>>> well as it
>>>>> > surprisingly has a possible shot at it)
>>>>> > Station 16 would likely hang off 13 (and/or possibly) -- station 11
>>>>> would
>>>>> > have to hang off 16 (so having a redundant link to 16 would be worth
>>>>> > considering)
>>>>> > Station 18 is potentially a challenge, but might have a shot at 12
>>>>> (and
>>>>> > maybe HamWAN as well as you point out)
>>>>> >
>>>>> > Anyway, we need to get on the roofs and "see what we can see" to get
>>>>> a
>>>>> > better idea.
>>>>> >
>>>>> > As an aid for this, I made a little "telescoping mast" out of some
>>>>> PVC pipe
>>>>> > that I can put my phone on and hoist up 15 feet or so using a rope
>>>>> (from
>>>>> > wherever I'm standing).  (It's a Windows phone, so it's expendable.
>>>>> :-)  I
>>>>> > use it to first take a short 360 video.  Once I have an idea of a
>>>>> > potentially promising direction, I use a timer for taking a
>>>>> > higher-resolution picture that I can study in more detail.  The
>>>>> other day I
>>>>> > was pleasantly surprised that I might very well have a good shot at
>>>>> station
>>>>> > 16 from our home where there is a relatively convenient mounting
>>>>> point.
>>>>> > (For testing convenience as it's a nice 3 km+ path.)  Anyway, it was
>>>>> nice
>>>>> > not having to drag out the extension ladder.  :-)   So, it may be
>>>>> helpful
>>>>> > for scoping things out at the stations; we'll see.  If any of you
>>>>> have ideas
>>>>> > for simple site surveying, I'd love to hear them.
>>>>> >
>>>>> > I don't know how this is all going to play out, but several folks on
>>>>> the
>>>>> > ARES team are excited by the prospects and having some more hard
>>>>> data from a
>>>>> > survey will definitely kick up the energy level I'm sure.  :-)
>>>>>  We're still
>>>>> > kicking around ideas on what to do for inter-station linking; it can
>>>>> get
>>>>> > expen$ive in a hurry...  Has anybody here played with 2.4 GHz amps
>>>>> and
>>>>> > dishes?  They are relatively inexpensive and the choices for routers
>>>>> to use
>>>>> > are plentiful and inexpensive as well...  One of the ARES guys and I
>>>>> > achieved (more or less) a 1.5 km link using Linksys routers with
>>>>> dd-wrt and
>>>>> > only 70 mW into DIY helical antennas on flimsy tripods!  It wasn't
>>>>> > super-stable, but for only 70 mW, I thought it wasn't too bad...
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Sun, Mar 6, 2016 at 9:35 PM, Tom Hayward <tom at tomh.us> wrote:
>>>>> >>
>>>>> >> On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr at gmail.com>
>>>>> wrote:
>>>>> >> > As for locations.  These are the fire station addresses and GPS
>>>>> >> > coordinates
>>>>> >> > that one of our other members put together:
>>>>> >> >
>>>>> >> > Station Address City Zip Lat/Long
>>>>> >> > 11 - HQ  8450 161ST AVE NE REDMOND 98052-3848 47.677913,
>>>>> -122.124938
>>>>> >> > 12 4211 148TH AVE NE  BELLEVUE 98007-3119 47.648426, -122.143646
>>>>> >> > 13 8701 208TH AVE NE REDMOND 98053 47.680206, -122.063499
>>>>> >> > 14 5021 264TH AVE NE REDMOND 98053-2718 47.651962, -121.987793
>>>>> >> > 16 6502 185TH AVE NE REDMOND 98052-5039 47.664105, -122.093651
>>>>> >> > 17 16917 NE 116TH ST REDMOND 98052-2246 47.703403, -122.114135
>>>>> >> > 18 22710 NE ALDERCREST DR REDMOND 98053-5845 47.692245, -122.03717
>>>>> >>
>>>>> >> Ed,
>>>>> >>
>>>>> >> I have not done RF models for each of these, but some quick plotting
>>>>> >> on the map shows line of sight from Haystack to stations 12, 13, 14,
>>>>> >> 16, 17, and 18. Station 11 is in a low spot and the only
>>>>> opportunity I
>>>>> >> see is a direct link to station 16.
>>>>> >>
>>>>> >> > My thinking is to have a "core network" of links between stations
>>>>> 12,
>>>>> >> > 13,
>>>>> >> > and 17.  Of all the stations, 13 seemed to be the most promising.
>>>>> >> > Station
>>>>> >> > 12 is practically next door to Microsoft's main campus and the
>>>>> noise
>>>>> >> > level
>>>>> >> > is huge there, but it potentially has great shots to several other
>>>>> >> > stations
>>>>> >> > which makes it attractive to having in the core.  Station 17 has
>>>>> become
>>>>> >> > somewhat of a "hub" station for ARES -- at least we continue
>>>>> moving in
>>>>> >> > that
>>>>> >> > direction; trees could be an issue there.  One or two of the other
>>>>> >> > stations
>>>>> >> > might have coverage potential, but it's all showing even more
>>>>> spotty on
>>>>> >> > the
>>>>> >> > map than these others.  (Of course if we were able to access a
>>>>> node on
>>>>> >> > Cougar, everything changes for the better...)
>>>>> >>
>>>>> >> Station 17 shows line of sight to station 12, 13 and 18, so could be
>>>>> >> somewhat useful as a hub, but not for all of the stations.
>>>>> >>
>>>>> >> Keep in mind the coverage map on hamwan.org is binary and only
>>>>> shows
>>>>> >> signals greater than -70 dBm. This is essentially 100% signal
>>>>> >> strength. "Spotty" might mean 5 Mbps speeds instead of 15 Mbps. Of
>>>>> >> course it could also mean zero signal, especially if there are local
>>>>> >> issues not accounted for in the model, like trees. It's worth doing
>>>>> >> calculations for specific sites in those "spotty" areas with a tool
>>>>> >> like ubnt.com/airlink or Radio Mobile, and if it looks favorable,
>>>>> ask
>>>>> >> here on the mailing list for someone to come out and test. We've
>>>>> got a
>>>>> >> number of people here who love playing with our portable HamWAN
>>>>> rigs.
>>>>> >> :-)
>>>>> >>
>>>>> >> Tom KD7LXL
>>>>> >> _______________________________________________
>>>>> >> PSDR mailing list
>>>>> >> PSDR at hamwan.org
>>>>> >> http://mail.hamwan.net/mailman/listinfo/psdr
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > PSDR mailing list
>>>>> > PSDR at hamwan.org
>>>>> > http://mail.hamwan.net/mailman/listinfo/psdr
>>>>> >
>>>>> _______________________________________________
>>>>> PSDR mailing list
>>>>> PSDR at hamwan.org
>>>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PSDR mailing list
>>>> PSDR at hamwan.org
>>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>>
>>>>
>>>
>>> _______________________________________________
>>> PSDR mailing list
>>> PSDR at hamwan.org
>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>
>>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org
>> http://mail.hamwan.net/mailman/listinfo/psdr
>>
>>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20160307/fec613e3/attachment-0001.html>

More information about the PSDR mailing list