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

Tom Hayward tom at tomh.us
Mon Mar 7 14:28:13 PST 2016


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


More information about the PSDR mailing list