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

[Ed Morin]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20160307/ad4ef5f9/attachment-0001.html>