Report from Mike and Key Electronics Show and Fleamarket
We had lots of interest for the HamWAN project at the Mike and Key Electronics Show and Fleamarket. I had a grid dish on my table at the Puyallup hamfest this year. I answered lots of questions and I distributed 40 fliers to interested hams. Here are some of the comments: - "How do you stay in line for Part 97?" - Upon seeing the MikroTik QRT-5: "Wow, I didn't know it could be so easy, look so nice!" - "What kind of Ubiquiti equipment do I use?" (the MikroTik brand is not well known with hams in our region) - "Okay, line of sight, I am going to take a look this afternoon!" - "How much does it cost? Where can I buy the equipment?" (Flytec sells the QRT-5 cheap on Amazon) - "How do you guys fund this project?" Many were very excited to see and touch the three configurations that I showed: - Integrated, flat-panel MIMO antenna/radio/modem - MIMO radio/modem with a dedicated panel antenna - Grid dish with single-channel radio/modem A handful asked for path plots. Tom, you should see some requests coming from people who join the mailing list in the next few days. Some were curious about a north sector at Tiger Mountain. Thanks for your help on the tri-fold brochures, Nigel. These were a BIG hit at the hamfest. 73 from Dan at K7MM
I replied to Dan who encouraged me to post to the list, so here I am. :-) I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use). Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share. 1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible... 2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd... Again, any thoughts you have on this would be appreciated... Thanks, -Ed (WB7UBD) -Ed (WB7UBD)
Howdy Ed, RE #1: Do you have the GPS coordinates and how high the antennas would end up being? If so, we can look at the models and see what they look like. RE #2: We have gear on East Tiger, but Cougar is pretty much out. Cougar would be a nice site to add, but us, and several others on our behalf, have never been able to get site owner buy in. If you’re able to push that forward, we’d be happy to work with you on that. Nigel
On Mar 6, 2016, at 15:43, Ed Morin <edmorin.jr@gmail.com> wrote:
I replied to Dan who encouraged me to post to the list, so here I am. :-)
I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use).
Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share.
1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible...
2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd...
Again, any thoughts you have on this would be appreciated...
Thanks,
-Ed (WB7UBD)
-Ed (WB7UBD) _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Thanks Nigel. I can nose around about Cougar. Do you know what the issue(s) is(are)? There are several ham repeaters there of course. 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 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...) In terms of height, there are a number of factors that may limit us, BUT the fire stations have "hose towers" (for hanging hoses to dry after use) which are pretty tall. I think 20 - 30 feet might be doable. The lower the better from a "political" point of view, the higher the better from a "technical" point of view. ;-) Any thoughts would be appreciated. (I have been using the ubnt.com/airlink site for doing some of this analysis as well as some other tools. A recent test we did seemed to confirm its validity although it was a bit optimistic -- that is, leaning more towards the "theoretical" which isn't surprising.) On Sun, Mar 6, 2016 at 3:48 PM, Nigel Vander Houwen <nigel@nigelvh.com> wrote:
Howdy Ed,
RE #1: Do you have the GPS coordinates and how high the antennas would end up being? If so, we can look at the models and see what they look like.
RE #2: We have gear on East Tiger, but Cougar is pretty much out. Cougar would be a nice site to add, but us, and several others on our behalf, have never been able to get site owner buy in. If you’re able to push that forward, we’d be happy to work with you on that.
Nigel
On Mar 6, 2016, at 15:43, Ed Morin <edmorin.jr@gmail.com> wrote:
I replied to Dan who encouraged me to post to the list, so here I am. :-)
I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use).
Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share.
1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible...
2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd...
Again, any thoughts you have on this would be appreciated...
Thanks,
-Ed (WB7UBD)
-Ed (WB7UBD) _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Ed, I have heard many of the horror stories about gaining access to Cougar for HamWAN, but am taking another run at it currently. Feel free to ping me if you'd like an update. I don't know if I will have any more success than the previous attempts, but I am trying. 73, Kenny, KU7M On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@gmail.com> wrote:
Thanks Nigel. I can nose around about Cougar. Do you know what the issue(s) is(are)? There are several ham repeaters there of course.
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
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...)
In terms of height, there are a number of factors that may limit us, BUT the fire stations have "hose towers" (for hanging hoses to dry after use) which are pretty tall. I think 20 - 30 feet might be doable. The lower the better from a "political" point of view, the higher the better from a "technical" point of view. ;-)
Any thoughts would be appreciated.
(I have been using the ubnt.com/airlink site for doing some of this analysis as well as some other tools. A recent test we did seemed to confirm its validity although it was a bit optimistic -- that is, leaning more towards the "theoretical" which isn't surprising.)
On Sun, Mar 6, 2016 at 3:48 PM, Nigel Vander Houwen <nigel@nigelvh.com> wrote:
Howdy Ed,
RE #1: Do you have the GPS coordinates and how high the antennas would end up being? If so, we can look at the models and see what they look like.
RE #2: We have gear on East Tiger, but Cougar is pretty much out. Cougar would be a nice site to add, but us, and several others on our behalf, have never been able to get site owner buy in. If you’re able to push that forward, we’d be happy to work with you on that.
Nigel
On Mar 6, 2016, at 15:43, Ed Morin <edmorin.jr@gmail.com> wrote:
I replied to Dan who encouraged me to post to the list, so here I am. :-)
I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use).
Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share.
1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible...
2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd...
Again, any thoughts you have on this would be appreciated...
Thanks,
-Ed (WB7UBD)
-Ed (WB7UBD) _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Ed, Don Sayler, W7OXR and I did a study to determine the feasibility of using HamWAM to handle the IRLP link at the LWHC repeater at the Bridle Trails site. We used Radio Mobile to rule out Hay Stack and Baldi It did show “Green Lines” for Capitol Park and Pain Field. One of the club members had access to a drone and we got permission from the city to fly it near the tower and tower. We did several 360 video and different altitudes. At 120 feet we were able to clear the trees on “Bridle Trails Ridge” and could see the ridge of Capitol Hill in Seattle. At about 90 feet we could no longer see Seattle. We came to the conclusion that Pain Field would be iffy at best and any misalignment due to winds or an earthquake would put if off line. Capitol Park to Bridle Trails Pain Field to Bridle Trails Haystack to Bridle Trails Baldi to Bridle Trails I do have a RouterBOARD Metal 5SHPN and dish antenna if you want to try getting into the network from your locations. Bob Morrisson KE7JL ke7jl@comcast.net From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Ed Morin Sent: Sunday, March 6, 2016 4:05 PM To: Puget Sound Data Ring Subject: Re: [HamWAN PSDR] Report from Mike and Key Electronics Show and Fleamarket Thanks Nigel. I can nose around about Cougar. Do you know what the issue(s) is(are)? There are several ham repeaters there of course. 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 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...) In terms of height, there are a number of factors that may limit us, BUT the fire stations have "hose towers" (for hanging hoses to dry after use) which are pretty tall. I think 20 - 30 feet might be doable. The lower the better from a "political" point of view, the higher the better from a "technical" point of view. ;-) Any thoughts would be appreciated. (I have been using the ubnt.com/airlink site for doing some of this analysis as well as some other tools. A recent test we did seemed to confirm its validity although it was a bit optimistic -- that is, leaning more towards the "theoretical" which isn't surprising.) On Sun, Mar 6, 2016 at 3:48 PM, Nigel Vander Houwen <nigel@nigelvh.com> wrote: Howdy Ed, RE #1: Do you have the GPS coordinates and how high the antennas would end up being? If so, we can look at the models and see what they look like. RE #2: We have gear on East Tiger, but Cougar is pretty much out. Cougar would be a nice site to add, but us, and several others on our behalf, have never been able to get site owner buy in. If you’re able to push that forward, we’d be happy to work with you on that. Nigel On Mar 6, 2016, at 15:43, Ed Morin <edmorin.jr@gmail.com> wrote: I replied to Dan who encouraged me to post to the list, so here I am. :-) I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use). Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share. 1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible... 2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd... Again, any thoughts you have on this would be appreciated... Thanks, -Ed (WB7UBD) -Ed (WB7UBD) _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
WA7NWP has some ideas to get HamWAN to Rose Hill. He lives nearby. On Sun, Mar 6, 2016 at 5:57 PM, Bob <ke7jl@comcast.net> wrote:
Ed,
Don Sayler, W7OXR and I did a study to determine the feasibility of using HamWAM to handle the IRLP link at the LWHC repeater at the Bridle Trails site. We used Radio Mobile to rule out Hay Stack and Baldi It did show “Green Lines” for Capitol Park and Pain Field. One of the club members had access to a drone and we got permission from the city to fly it near the tower and tower. We did several 360 video and different altitudes. At 120 feet we were able to clear the trees on “Bridle Trails Ridge” and could see the ridge of Capitol Hill in Seattle. At about 90 feet we could no longer see Seattle. We came to the conclusion that Pain Field would be iffy at best and any misalignment due to winds or an earthquake would put if off line.
Capitol Park to Bridle Trails
Pain Field to Bridle Trails
Haystack to Bridle Trails
Baldi to Bridle Trails
I do have a RouterBOARD Metal 5SHPN and dish antenna if you want to try getting into the network from your locations.
Bob Morrisson KE7JL
ke7jl@comcast.net
*From:* PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Ed Morin *Sent:* Sunday, March 6, 2016 4:05 PM *To:* Puget Sound Data Ring *Subject:* Re: [HamWAN PSDR] Report from Mike and Key Electronics Show and Fleamarket
Thanks Nigel. I can nose around about Cougar. Do you know what the issue(s) is(are)? There are several ham repeaters there of course.
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
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...)
In terms of height, there are a number of factors that may limit us, BUT the fire stations have "hose towers" (for hanging hoses to dry after use) which are pretty tall. I think 20 - 30 feet might be doable. The lower the better from a "political" point of view, the higher the better from a "technical" point of view. ;-)
Any thoughts would be appreciated.
(I have been using the ubnt.com/airlink site for doing some of this analysis as well as some other tools. A recent test we did seemed to confirm its validity although it was a bit optimistic -- that is, leaning more towards the "theoretical" which isn't surprising.)
On Sun, Mar 6, 2016 at 3:48 PM, Nigel Vander Houwen <nigel@nigelvh.com> wrote:
Howdy Ed,
RE #1: Do you have the GPS coordinates and how high the antennas would end up being? If so, we can look at the models and see what they look like.
RE #2: We have gear on East Tiger, but Cougar is pretty much out. Cougar would be a nice site to add, but us, and several others on our behalf, have never been able to get site owner buy in. If you’re able to push that forward, we’d be happy to work with you on that.
Nigel
On Mar 6, 2016, at 15:43, Ed Morin <edmorin.jr@gmail.com> wrote:
I replied to Dan who encouraged me to post to the list, so here I am. :-)
I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use).
Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share.
1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible...
2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd...
Again, any thoughts you have on this would be appreciated...
Thanks,
-Ed
(WB7UBD)
-Ed
(WB7UBD)
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
-- ------------------------------ 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>
WA7NWP has some ideas to get HamWAN to Rose Hill. He lives nearby.
I was going to suggest checking the path to the local HamWAN sites and they've already got that done. Next option would be to see if there are at least two local hams with good internet access and a path to the repeater site. I could probably make it on 440 from across the valley but there are many trees in the way. Guessing and need to test that anything higher than 440 MHz would not stand a chance. It is an interesting path and will be fun to experiment. Bill, WA7NWP
Bob, I noticed a couple of issues with your study. First, you assumed a 2 dBi gain for the HamWAN sectors. This is quite pessimistic. You can use published and measured data to calculate the gain much more accurately with Radio Mobile. Bart measured 14 dBi peak gain from the Laird SAH58-120-16-WB and Ubiquiti advertises 19 dBi peak gain for the Ubiquiti AM-5G19-120. I have published .ant (Radio Mobile antenna pattern) files for each of these antennas: https://www.hamwan.org/t/tiki-download_wiki_attachment.php?attId=99&page=Lai... http://www.hamwan.org/t/tiki-download_wiki_attachment.php?attId=224&page=Ubi... Here are the sector antenna models in use at each of the HamWAN sites: Capitol Park: Laird SAH58-120-16-WB Snohomish County DEM: Laird SAH58-120-16-WB Haystack: Ubiquiti AM-5G19-120 Baldi: Laird SAH58-120-16-WB East Tiger: Ubiquiti AM-5G19-120 Gold: Ubiquiti AM-5G19-120 If you set up Systems in Radio Mobile for each of these, it will calculate the gain at non-peak angles. Also, the receiver threshold you used is too optimistic. This doesn't influence your calculated rx level (the important number), but it will give you a "green line" when signals are well below the noise floor. You can find receiver thresholds published in the Mikrotik datasheets for the various modems we use. The RB912 modem we recommend for MIMO stations has a receive threshold of -96 dBm. This is another parameter in the System setup in Radio Mobile. http://i.mt.lv/routerboard/files/RB912-150924141406.pdf Lastly, I noticed is you have Haystack at the wrong position. HamWAN's site is not at Haystack Mountain, but on a nearby ridge. The position is 47.808024°, -121.727227° (published at http://www.hamwan.org/t/Haystack ). If you use that position for your calculation I think you will be pleasantly surprised. If you share the latitude and longitude for the LWHC Bridle Trails site I can run these calculations for you with the sites and systems I already have plugged into Radio Mobile. Tom KD7LXL On Sun, Mar 6, 2016 at 5:57 PM, Bob <ke7jl@comcast.net> wrote:
Ed,
Don Sayler, W7OXR and I did a study to determine the feasibility of using HamWAM to handle the IRLP link at the LWHC repeater at the Bridle Trails site. We used Radio Mobile to rule out Hay Stack and Baldi It did show “Green Lines” for Capitol Park and Pain Field. One of the club members had access to a drone and we got permission from the city to fly it near the tower and tower. We did several 360 video and different altitudes. At 120 feet we were able to clear the trees on “Bridle Trails Ridge” and could see the ridge of Capitol Hill in Seattle. At about 90 feet we could no longer see Seattle. We came to the conclusion that Pain Field would be iffy at best and any misalignment due to winds or an earthquake would put if off line.
Capitol Park to Bridle Trails
Pain Field to Bridle Trails
Haystack to Bridle Trails
Baldi to Bridle Trails
I do have a RouterBOARD Metal 5SHPN and dish antenna if you want to try getting into the network from your locations.
Bob Morrisson KE7JL
ke7jl@comcast.net
*From:* PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Ed Morin *Sent:* Sunday, March 6, 2016 4:05 PM *To:* Puget Sound Data Ring *Subject:* Re: [HamWAN PSDR] Report from Mike and Key Electronics Show and Fleamarket
Thanks Nigel. I can nose around about Cougar. Do you know what the issue(s) is(are)? There are several ham repeaters there of course.
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
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...)
In terms of height, there are a number of factors that may limit us, BUT the fire stations have "hose towers" (for hanging hoses to dry after use) which are pretty tall. I think 20 - 30 feet might be doable. The lower the better from a "political" point of view, the higher the better from a "technical" point of view. ;-)
Any thoughts would be appreciated.
(I have been using the ubnt.com/airlink site for doing some of this analysis as well as some other tools. A recent test we did seemed to confirm its validity although it was a bit optimistic -- that is, leaning more towards the "theoretical" which isn't surprising.)
On Sun, Mar 6, 2016 at 3:48 PM, Nigel Vander Houwen <nigel@nigelvh.com> wrote:
Howdy Ed,
RE #1: Do you have the GPS coordinates and how high the antennas would end up being? If so, we can look at the models and see what they look like.
RE #2: We have gear on East Tiger, but Cougar is pretty much out. Cougar would be a nice site to add, but us, and several others on our behalf, have never been able to get site owner buy in. If you’re able to push that forward, we’d be happy to work with you on that.
Nigel
On Mar 6, 2016, at 15:43, Ed Morin <edmorin.jr@gmail.com> wrote:
I replied to Dan who encouraged me to post to the list, so here I am. :-)
I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use).
Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share.
1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible...
2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd...
Again, any thoughts you have on this would be appreciated...
Thanks,
-Ed
(WB7UBD)
-Ed
(WB7UBD)
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@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
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@tomh.us> wrote:
On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@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@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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@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@tomh.us> wrote:
On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@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@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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@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@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@tomh.us> wrote:
On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@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@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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@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@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@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@tomh.us> wrote:
On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@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@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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@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@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@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@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@tomh.us> wrote:
On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@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@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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@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@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@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@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@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@tomh.us> wrote:
On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@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@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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@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@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@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@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@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@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@tomh.us> wrote: > > On Sun, Mar 6, 2016 at 4:05 PM, Ed Morin <edmorin.jr@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@hamwan.org > http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Could a HamWAN style hub be situated at the Ed hill water Tank? Maybe at two other similar super sites. From there run sector links to the fire stations and other facilities and even home ham stations. Those super hubs would probably have good access to multiple HamWAN resources as one of several upstream feeds. Bill, wa7nwp
On Mar 6, 2016, at 3:43 PM, Ed Morin <edmorin.jr@gmail.com> wrote:
I replied to Dan who encouraged me to post to the list, so here I am. :-)
I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use).
Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share.
1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible...
2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd...
Again, any thoughts you have on this would be appreciated...
Thanks,
-Ed (WB7UBD)
-Ed (WB7UBD) _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Hi Bill, It's a good thought, but the Education Hill water tank, as odd as this sounds, actually sits in a bit of a "bowl" and has pretty crummy visibility of a good many of the the fire stations. The other water tank near FS 16 is probably even worse than the Ed. Hill tank in terms of HamWAN, so there isn't much to be gained their either. :-( (Not to mention that getting access is more difficult than with the fire stations.) On Mon, Mar 7, 2016 at 8:36 AM, Bill <wa7nwp@gmail.com> wrote:
Could a HamWAN style hub be situated at the Ed hill water Tank? Maybe at two other similar super sites. From there run sector links to the fire stations and other facilities and even home ham stations. Those super hubs would probably have good access to multiple HamWAN resources as one of several upstream feeds.
Bill, wa7nwp
On Mar 6, 2016, at 3:43 PM, Ed Morin <edmorin.jr@gmail.com> wrote:
I replied to Dan who encouraged me to post to the list, so here I am. :-)
I am part of the City of Redmond ARES group and we are working towards implementing a HamWAN link to a city network we hope to put together. We were allocated a /24 network and our intentions are to (eventually) multi-home for redundancy as well as provide AP's locally (for ham use).
Anyway, I was intrigued by two things Dan noted in his post which he thought others on the list might have some ideas they could share.
1. The Redmond area -- particularly where our fire stations are -- is very spotty in terms of coverage as it appears on the homepage coverage map. We would love it if somebody could help in determining what our "real" chances are for getting HamWAN links at a few of our fire stations. I have studied the coverage map on the homepage, but I assume it's not "perfect" when coverage is showing "spotty" (particularly in the Redmond area). We're looking to get an end-user "setup" to use for "surveying" with, but do not have that yet since it would be out of our own pockets until we can demonstrate a proof-of-concept to the city (after which we could likely get reimbursed). My present thinking is that fire stations 13 and 17 are possible candidates although (if memory serves) there are two others that may have a shot at it as well. So, any ideas on how we could work to nail that down would be great. If somebody has a "portable" unit, maybe we could just try it sometime to see if a signal is visible...
2. Putting a core node on Tiger Mt. might be potentially very helpful to us. A node on Cougar Mt. might be even more so; have any of you looked into that possibility? It appears to have better Eastside coverage than Tiger and a better "view" of Redmond up the Sammamish valley. This might be attractive to the Microsoft / MicroHams crowd...
Again, any thoughts you have on this would be appreciated...
Thanks,
-Ed (WB7UBD)
-Ed (WB7UBD)
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Please excuse the Redmond focused queries here on the PSDR list. First question - is there some sort of Redmond discussion forum. I was in a group years and years ago but that has, I believe, been replaced. Second - any progress on the MESH networking project? I've been taking little steps in a similar arena and would be good to compare notes. Third - I saw the Winlink AP, K7REM-1, beaconing on 145.63 MHz but it didn't respond to my connection attempt. Nor did the more conventional K7REM-10. Are there any local packet resources still in operation? Thanks, Bill WA7NWP On Mon, Mar 7, 2016 at 9:20 AM, Ed Morin <edmorin.jr@gmail.com> wrote:
Hi Bill,
It's a good thought, but the Education Hill water tank, as odd as this sounds, actually sits in a bit of a "bowl"
participants (9)
-
Bill -
Bill Vodall
-
Bob -
Daniel Ransom -
Ed Morin -
John D. Hays -
Kenny Richards -
Nigel Vander Houwen -
Tom Hayward