[HamWAN PSDR] Report from Mike and Key Electronics Show and Fleamarket
edmorin.jr at gmail.com
Mon Mar 7 00:52:22 PST 2016
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
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:
> 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
> - 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)?
> 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
> > 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
> > because it sure doesn't resemble one on paper! (Owing to the geography
> > course...)
> > Core triangle of 12, 13, and 17 for reasons stated earlier -- UNLESS one
> > the other stations ends up having a "better" link
> > Station 14 would hang off 12 (and possibly have a HamWAN link as well as
> > 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
> > 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. :-)
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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
> >> > 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
> >> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PSDR