Designing by the channel

Channel planning! Almost as glorious as clicking in all those little walls on your million sq. ft. floorpan…. Which by the way is a scanned in PDF from 1994. The things they don’t tell you when you decide to do wireless…

Today I’m writing about my preferred method of planning channels. “How hard is this?” You may be thinking. Well, its not. But with my personality type (ISTP or a 1,5,4 as Devin calls it) I like to help people, tinker, and fix things. As my friend Chris Hopkins once described me: “Joey is the type of guy that could take a car apart and put it back together with a screwdriver.” I don’t know about that much, but I do find myself dismantling things and fixing them and most of the time making them better throughout my days. Also helped me figure out that I’m an extremely visual learner. To sum all this up, I’ve been planning channels for almost as long as I’ve done wireless (sad, I know). But in all this planning, I’ve tried several methods to figure out what the best and most time-efficient way of laying out a building’s channel plan. Here is what I’ve come up with…

All my planning is done using Ekahau. I know there are others, but Ekahau has become my favorite because of the ease of use, and the features that they keep coming out with that is making our jobs as wireless engineers easier. I mean, what other company has a VP that drives across a country he isn’t from just to talk to customers about new features and asks what they want? Props @JussiKiviniemi. Props.

First off, lets start with the available channels.

I only channel plan for 5Ghz. Why? Cause there are 25 channels available to use and that means less interference, better connections, and higher speeds for the little guys(clients). A part of this channel set is the dreaded, evil DFS! You’ve heard the stories… Mostly from those “Tech on the side” guys:

“DFS is evil! If you are within 4 million miles of an airport, you’ll NEVER be able to use DFS! And Radar?! Why do they even allow wifi on those channels? Nobody can use them! Its like wasting energy just typing the number into the standard!”

Hardly. I HIGHLY recommend testing for DFS events before deciding that you can’t use them. You’d be amazed at the times that you can. The hospital I worked at implemented a full 5Ghz channel plan across 7 buildings and 6 stories; less than 2 miles from an airport. After baking for a month, I discovered ONE DFS event. Always on the same channel 116. Always on the same AP. So what happened? Did the FCC come shut our hospital down, dooming all the grandmas that were laying so helplessly in all the beds? Did the entire wireless network collapse while surgeons were cracking rib cages open with ball peen hammers and chisels, listening to Dire Straits wirelessly (I’ve seen that.)? No, we just changed the channel to something else that doesn’t interfere. Don’t forget that most (all?) of the time, the AP doesn’t stop working when it gets a DFS trigger. It simply moves to a non-DFS channel for 30 minutes and then moves back. So uneventful!

In my experience with using DFS channels, so far I’ve only had one instance where it caused a problem. A doctor in a corner office said he didn’t have any signal on his Toshiba laptop. I went over to the area and sure enough, my AirCheck G1 said the same thing. What the heck?! There was an AP IN his office! Looking on the controller, I quickly realized that the AP was on channel 144. This channel, at the end of the DFS spectrum, is the newest channel allowed in the 5Ghz range. Because he was in a corner office, his secondary coverage was crap and he’d drop once he closed the door. There are quite a few clients and wireless cards that do not support 144 yet. After seeing that instance, I decided to remove channel 144 from our entire layout (which hadn’t been installed yet). This was a crappy process but it helped me hone the subject of this blog post and once it was completed, I didn’t have to worry about it again because I USE STATIC CHANNELS. (yes, you can remove 144 from RRM settings. but I couldn’t resist.)

So with all that, lets remove 144 and back it down to 24 channels. We want to make sure that all devices can reach Facebook, am I right?

Signal First.

So the first step I take in planning the RF coverage of a building (after testing walls, and replicating them for weeks) is placing 1 of my chosen model APs in a location that covers -67dbm (or my target signal strength) at the corner of the building. This is typically in a room across the hall from the corner office or conference room unless I’m designing for HD or VHD.


After that first AP is placed we can configure the settings for the rest of the placements. I put the channel on 116 and set the desired power level. Why? Well, 116 is pretty much in the center of the 5Ghz band, so later on, I can change that channel to the final channel and the coverage isn’t going to change too much. I also have it engrained in my head that APs on 116 haven’t been planned yet so its a good starting point. This will make sense later. If the power is lowered I then move the AP as needed to keep signal where it was in the corner.

Next, I layout all the primary coverage in the entire building. All floors, indoor and out. Placing all the APs with the settings from the first -Channel 116/tx-power xx. Ekahau duplicates the first AP automatically. Just don’t leave the screen…I’ve been bitten by that in the past. Its not fun to fix 50 “generic” APs after you’ve saved…

Secondary coverage

This isn’t something that is talked about by vendors very much. Instead they say something stupid like “20% cell overlap!” What the heck does that even mean? Who said that and then convinced others that it was a good idea? Someone that uses that “honeycomb” pattern..Not a CWDP.

Secondary coverage has two functions. First, its what makes roaming successful. Too hot, and devices will have a hard time making a decision to which AP they should roam. Too lacking, and the client will either disconnect from the primary AP before roaming or you’ll stick to the primary AP and your signal will turn to crap before the roam is successful. Either is bad for the client. The second purpose is for redundancy. With a good secondary coverage plan, and AP can go down and users won’t notice. I experienced this at the HD3 hospital that I redesigned:

Cablers (somehow) always manage to get a bunch of ceiling tile fiberglass inside the ethernet port. They plug it in and it works initially, but later it craps out and you get an alert that the AP went down. When you go unplug the AP and blow the entire ceiling tile out of the ethernet port and plug it back in -it works fine. This happened to the MAIN AP in the middle of the Emergency Department. The one that ALL the nurses and doctors sit under and work from. Average client count of 35. The AP went down, and nobody said a word. No calls, no support ticket. I just noticed it was down. I remediated the AP a couple weeks later during a slow day and all was good. That is what secondary coverage can do for you.

To plan secondary coverage on Ekahau, select the 5Ghz band for the view, and click options. Down at the bottom is a drop-down that says “Show the (strongest) signal at (all) channels“. Change the first drop-down from (strongest) to (2nd strongest). Then change the legend to your desired secondary level. I mostly use -70. Some devices recommend more. If you use the default view, you want the map to be speckled with mostly yellow and gray. Once you see darker green, your APs are probably too close and you need to move them apart a little bit to get rid of the green. Lighter green is certainly better than dark green. Also, remember grey is ok for this view. Large spots of of grey should probably be fixed. I don’t typically worry about the secondary coverage for the edge of the building because users won’t be roaming in those areas.


Now all the APs are placed. Primary and Secondary coverage is looking good and I’m ready to start changing channels.

Before I start changing channels, I like to do a calculation to determine how many APs need to be on each channel in order to get blanket coverage with non-DFS and DFS channels. I like to design with a 60-65% coverage model for non-DFS and 35-40% for DFS channels. I do this calculation per floor instead of the entire building.

If I’m working on a large floor that has 60 APs, I find out what 60% of 60 is: 36. There are 9 non-DFS channels (36-48, 149-165). So 36 divided by 9 = 4. Each non-DFS channel will have 4 APs. The remaining 40%(24 APs) will have DFS channels.  24 divided by 15 is 1.6 APs per channel.


  • 60 APs
    • 60% of 60 APs is 36 APs.
    • 40% of 60 APs is 24 APs.
  • 36 APs will use the 9 non-DFS channels.
    • 36 divided by 9 is 4 APs per channel.
  • 24 APs will use the 15 DFS channels.
    • 24 divided by 15 is 1.6 APs per channel.

Still following? Hopefully.

Now to the channels.

So then we begin:

In ekahau, set these settings:

  • Show “Channel Overlap” for “Selected APs” on 5Ghz only
  • Click Options, and select “Detailed” view
  • I turn contours off in the legend (personal preference)
  • Leave the legend at 0 and 2.

Now, starting with non-DFS, select 4 APs that do not cause CCI. CCI shows in yellow:


Then click Actions, Edit selected APs, and change the channel to 36. Be sure when you are selecting the APs, that you only click the 116 icon. If you select the AP itself, it will select both channels and the edit screen won’t let you change the channels.

Now, repeat for the other 8 channels. Keep in mind to stay away from ACI. ACI is Adjacent Channel Interference. ACI is caused by putting 2 neighboring channels next to each other in an environment such as 36 and 40. ACI can cause most problems than CCI because its harder to detect without a protocol analyzer and it can produce errors in the transmissions from clients to AP and vis versa. As far as I know, the 2.4 range doesn’t experience ACI because there is a separation of 25 Mhz in between the 1, 6, and 11 channels. In 5Ghz, there is no separation. Channel 36 butts straight up against channel 40. This is where the problem is. *Sometimes its unavoidable. I’m still getting better at this.

At the end of this section you should have covered most of the floor with non-DFS channels, possibly with little gaps here and there. I find that its typically hard to get coverage in the middle of the area. Most of the outside APs will hear the APs in the middle so you can limit yourself if you aren’t paying attention.



Next, Do the same thing with all the DFS channels that you require according to your percentage, again keeping in mind ACI. Your last couple of APs can stay on 116 if you decide to leave them and the channel hasn’t shown any DFS triggers.

DFS coverage.png

(ignore the 2.4 radios. I was mid-project)

Once you are finished, you double check your coverage and interference by viewing “My APs” instead of selected and looking at signal coverage and channel overlap.



And thats it!

When doing a multiple floor building, I start at the top because most APs have a down-tilt antenna. If CCI is going to happen floor-floor, most of the time it will happen from the upper floor broadcasting down. Speaking of, I haven’t found a good way to check floor to floor CCI during the planning phase. What I do currently is take a screen shot of the floor above, and reference that as I’m channeling the current floor. Not perfect but its better than waiting 10 minutes for each floor to refresh.

Lastly, depending on the power level, you probably aren’t going to get rid of all the CCI. My advice would be to know the building and requirements when you are designing. That way you can make good decisions when you get into that situation. Sometimes you just need to accept it, and sometimes you just move a couple APs here and there.

Please comment below! I’d love to hear some feedback on this.

As always… ’till next time!


Aruba AOS6 Static Channeling

Aruba ARM! Its the greatest!

Recently I’ve been checking out a bunch of the Cracked “If so&so ads were honest” series. They are quite hysterical. Theme Parks, Grocery stores, Expensive purses….they all give a very interesting perspective on whats really going on and the thoughts that these industries/companies probably have behind closed doors.

Every time I have to mess with ARM, I think about these videos. I hear Mr. Horton saying:

“We know that setting channels statically is probably easier but we just don’t think you are intelligent enough to do it. So use ARM! Why mess with channels when you could be sitting on the beach with a Corona and reading Feci-Fi blogs on your new wireless network?!?”


Does seem kind of true though, doesn’t it? It can’t be that hard to add a command to the controller that says “put this radio on this channel and power and leave it there.” It’s easy with an IAP, why not with a controller?

At least in AOS8 it seems be available. Until then, here is what I did to get a full static channel configuration on my latest system.

Some RRM thoughts…

So are “ARM” type systems all stupid and useless? No, I believe that ARM has its place in the wireless world. In certain environments riddled with neighbors using RRM technology to adjust(or not adjust) all their channels. There has to be a way to tweak RRM to respond to their unknowledgeable high schooler “tech on the side” guy that threw up 40 Ruckus APs in a gas station and called it a network. Never mind the fact that they are all on 80Mhz channels, 10 foot apart, and using 36e and 149e. Hopefully AOS 8’s Airmatch will be better at determining these situations and react better.

Ruckus 80.png

However, I’ve learned throughout my life that its really best to have a good foundation. In housing, a bad foundation will cause your house to fall over. Currently, I’m getting quotes to repair my cinderblock wall in my basement. Its buckled an inch and a half inward and the previous homeowner’s paint just started to crack. Convenient. (This of course is after I put 15K into a full 2 bedroom apartment.) The right side of my house is skewed 2 inches -because of a bad foundation. In life, a bad foundation will lead you into years of trouble with yourself and others. Counseling, jail, lifelong unhappiness, who knows? But it will happen if your foundation isn’t solid.


Creating a static plan for your building ensures that your wireless has a good foundation. Its solid and will not change (excluding DFS). Then by utilizing spectrum analysis and WIDS and WIPS, you can be notified of events that are trying to cause problems to your network and then you can go deal with those events accordingly.


Aruba configuration is all based on profiles. VAP profiles, Radio Profiles, SSID profiles, etc. Its a great design because you can build all the profiles out in the beginning and then just point and click your way through new AP deployments as opposed to hand configuring every new AP and site that comes online.

Aruba Profiles:


The problem with this regarding static channels is that the channel and power settings are inside the 802.11a radio profile. This means that if you change the channel inside that profile, its going to change it for every AP that is associated with that profile. On top of that, the power settings (Transmit EIRP) are inside the advanced tab of that profile. What does that mean? It means you’ll need a radio profile for every channel, and every necessary power level of that channel. *note that there is an 802.11g radio profile for 2.4. I’ll stick to “a” profiles for this post but it applies to both.

The best way to do this is of course in the CLI. To get that configuration, I created a new radio profile in the GUI and then checked the CLI for the configuration. You’ll end up with something like this:

rf dot11a-radio-profile “profile_name”
channel 36
tx-power 1
arm-profile “arm-maintain”

For the naming convention, I decided on this:


This tells me (and future engineers) that the Channel(dash)power is 036-01. I padded with the 0 because Aruba orders everything numerically by the first digit. Regardless if it is 2 or 3 digits long. If you don’t pad with 0, you end up with this structure:


Very annoying to my obsessive compulsive side. It also makes the profile list a mess.
So now I have this:

rf dot11a-radio-profile “Ch-Tx_036-01”
channel 36
tx-power 1
arm-profile “arm-maintain”

To create all the other profiles, I popped that into excel and created a bunch of concatenate formulas to create a profile for every other combination that I needed. For the 26 5Ghz channels, I created a power setting for 1-10, 15, 20, 25, and 30. 14 Profiles per channel =  364 profiles!

And that’s not all!
Now that you have your 364 radio profiles, you then have to apply those profiles to each AP! So instead of having 364 lines of configuration that you should really need, now you have that plus however many APs:

ap-name “FFI-04-079”
dot11a-radio-profile “Ch-Tx_149-10”
dot11g-radio-profile “rp-monitor-g”
ap-name “FFI-04-080”
dot11a-radio-profile “Ch-Tx_132-10”
dot11g-radio-profile “Ch-Tx_06-02”
ap-name “FFI-04-081”
dot11a-radio-profile “Ch-Tx_060-10”
dot11g-radio-profile “rp-monitor-g”
ap-name “FFI-04-082”
dot11a-radio-profile “Ch-Tx_040-10”
dot11g-radio-profile “Ch-Tx_06-01”
ap-name “FFI-04-083”
dot11a-radio-profile “Ch-Tx_104-10”
dot11g-radio-profile “Ch-Tx_11-02”
ap-name “FFI-04-084”
dot11a-radio-profile “Ch-Tx_048-10”
dot11g-radio-profile “rp-monitor-g”

One careful note about quotes: Aruba OS uses quotes, but does not like quotes being pasted in. Before you paste copied configuration back into any Aruba controller using AOS6, find and replace ALL quotes with nothing:
Find replace quotes.png
If you don’t, you’ll end up with configuration that looks like this:

rf dot11a-radio-profile “Ch-Tx_036-01″
channel 36
tx-power 1
arm-profile “arm-maintain”

It will create new profiles in addition to the current ones and make your configuration very confusing. Also, NEVER use spaces. (This should be a given.)

I’ve read some of the Aruba Airheads responses to static channel requests and they always point to the “regulatory domain”. They say “remove all the channels you don’t want and then apply the domain to the AP”. In investigating this solution, I’ve found that while that will help with keeping the channels static, the power will still fluctuate depending on ARM. Maybe I’m wrong, but meh. There’s more than one way to skin a….potato.

So there it is! Can’t tell you how long I searched for something like this when I was a little Aruba certified associate. Unfortunately, knowledge like this isn’t getting me closer to ACMX. Back to studying!

’til next time!

HD3 Removal

Ah, HD3.

The laughing stock of Twitter a couple years back after Devin Akin did his extensive post of how much of a failure it is. (

Screen Shot 2017-06-09 at 3.46.30 PM.png

I had the pleasure of hanging out with Devin on the first week of my employment at my former workplace and it was during one of these days that a colleague and I took Devin over to our new hospital to show him this monstrosity of a design. The pictures in his post are from that location.

In case you haven’t clicked on that link yet, let me explain what HD3 (High Density, Design, Demand?) is in some layman’s terms. HD3’s whole purpose is to put SSIDs on different sections of the 5Ghz band. They divide it into low, medium, and high band sections. Their argument is that the higher frequencies are “more robust” and “faster”, so they take all your SSIDs and put voice and medical SSIDs on the high band, Guest on the (DFS) mid band and 2.4, and standard employee SSID on the low band. How do they do this? They use an RF filter called a Tri-plexor to limit the RF frequencies that can be heard by the AP. 3 profiles are created for each “band”. Then, they remove a 2×2 ceiling tile and inside of an overpriced antenna box that they sell you, they place 3 APs and 3 Tri-plexors. Each AP has its antennas plugged up to the respective Tri-plexor and then each Tri-plexor is connected to the antenna. Yes, they are connect 3 APs to one antenna. If they wasn’t interesting enough, think about how they are getting 3 bands out of the 5ghz frequency range. They use the Tri-plexors to limit the 26 5Ghz channels into 3 groups of 4 channels. 36-48, 100-116 (5 but at this point does it matter?), and 149-161. The other channels are ignored and cannot be used in the system. If you are reading that correctly and know anything about the limited channel problem of 2.4GHz, you are coming to the conclusion that they are bringing that problem over to the 5GHz band. Because, wifi is easy, right? How hard is it to not run wires?

Here is my colleague trying to draw it on a whiteboard…


So in the simplest terms possible, HD3 is 3 wireless systems that are installed over top of each other. These 3 systems only have 4 channels to work with and CCI and ACI go through the roof. The design that was installed at our location had an average power output of 14dBm for all access points. The antenna boxes were installed in locations that wouldn’t make sense except in a coverage only model, and introduced failures throughout the building with low power clients. Most AP boxes were in hallways and open areas.

This all sounds so wonderful! Because with the filtering, the APs see this:


But unfortunately, then the clients see this:

emphasis added

(emphasis added)
    To quote the sales guy during a meeting: “When the network has no clients, the system is flawless!” (Yes. Really.)

Here are some of the tickets that I was given in the first 2 weeks of my employment, which was 2 months after the grand opening (problems began at day 1):

  •    Wireless VOIP phones (iPhones) were constantly dropping in all areas of the hospital. Wireless ceased to function in any stairwell or elevator, and coverage to those areas was offered to us for only an additional umpteen thousands of dollars! What an offer!
  •    Registration (Wireless on wheels, or FLO-carts) would drop in any room they went in. They would also roam while they were sitting still. Nurses very quickly refused to take them into rooms and had to register patients on paper, and then transfer that information to the carts that were sitting in the hallways.
  •    Pharmacist PDAs that were used to scan and dispense medications would not work in the rooms.

So what do you do with that? You rip it out.

After 6 months of arguing over protocols and wireless fundamentals, 3 on-site visits and “tunings”, unending tickets and troubleshooting, and numerous chief level meetings trying to keep their gear in the hospital, it was approved for me to rip and replace the entire system.

My first step in ripping the system out was to figure out what could remain. With 3 CAT6 cables run to every box, there was a definite desire from management to recoup some of the money that was used on the copper. In the hospital, we had a total of 5 SSIDs. 2 guest networks, a medical device network, our main connectivity network, and a VOIP network. Since the VOIP network was the only one on the high band, I was able to successfully move all the SSIDs to the mid and low filters. This freed up the cable that was run to the “high band” AP without having any downtime.

Next, a new design was created using the AP215 from Aruba. We had already moved to Aruba as a wireless vendor at 4-5 remote sites, and with the Juniper exit from the wireless industry, we decided to continue that migration. At the time, the AP325 had just come out but the code had not reached GA(general availability) level so I was uncomfortable moving to such a new model. We also discussed the AP225, however, my high capacity design would negate any need to put a high client AP in such a dense deployment. The AP215 had been out around 6 months and we felt comfortable with standardizing on that model. This is also the model that we had designed for at the main campus. The design was completed using the standard steps:

  1.      Walk the building and take measurements of RF attenuation for each change in wall and door type. Since the hospital was brand new, this didn’t take long because everything was the same. There were no new additions or changes to the building. I took a baseline measurement from a standard wall and door, and measured some of the oddball materials that were scattered throughout. Elevators were also measured as well as floor-floor signal.
  2.      Using Ekahau, I was able to take those measurements and create a model of the building that represented the environment to the best of my ability.
  3.      APs were added at 10mw from the top floor working my way down. Primary and secondary coverage were planned at -67 and -70dBm levels. Elevator and Stairwell coverage was included (and ended up only costing about 2k. Imagine that.). Channel planning was also completed. I’ll go into that during another post.
  4.      Once the design was complete, low voltage maps were pulled from Ekahau and the new placements were compared to the current layout of the HD3 system. Cables that were able to be relocated were marked accordingly and the cabling contractor was able to begin moving the existing cables and running the new cables. They also hung all the new APs since we were not using any cables that were in use. This process took around 3 months. By installing all new cabling we were able to find DOAs, test, and preconfigure Aeroscout location tracking before go-live.
  5.      During that time I was able to fully configure the new controller design and spin up 2 sites prior to the go-live. This ensured that when the hospital went live there would be no troubles. Phone connectivity, medical devices, and other equipment was brought on location to the test bed site and tested for connectivity issues that would cause problems at the hospital. All tests passed although we did determine that the 8010 Spectralink phones that were in use would have to be swapped out. The phones were older 1×1:1 devices that would not support 2 spatial streams. Because of the Aruba profile settings and how they operated, we would have had to limit the APs to 1×1:1 in order to get the phone to connect. I described this to management as “putting wooden wheels on a Ferrari” and they decided it would be best to upgrade.
  6.      The new controller system was “baked” for a month before go-live. The two testing sites were live and working well. On the night of go-live, at 12am during a maintenance window, I was able to turn all the Aruba radios on, and turn all the Juniper radios off. It was a glorious event for an entire hospital system that had never had a wireless network that worked efficiently. All clients successfully roamed to the new Aruba system and only a few devices needed to actually have hands put on them. The conclusion to all the efforts made was one of the most boring 6 hour blocks of 2016. And I was very appreciative.

After the go-live, tickets stopped immediately. All of the problems mentioned earlier in the post were eliminated and my life was boring for 2 weeks. Post installation surveys had been completed before the go-live since all access points were up and mw was reduced to 5, and sometimes 1mw. Unfortunately, some of my measurements had been a little on the high side. This made the network a little hotter than I liked but it was easily resolved and was still lightyears above the coverage that was there originally.

There were some issues that arose later in the month involving iPhones, Airwatch, and Avaya. I’ll go into some of those next time!

’til next time…

Aruba Airwave Triggers

An intro to Triggering with Aruba Airwave.

Recently we had a new site come up that only needed one access point. It’s a small doctors office that we are renting space in so one of our doctors can use it every other Wednesday.

There was some confusion of how the network was going to be installed and it ended up that we had to install all our own gear instead of using a VPN from their gear. Property managers… meh.

Since the site was only in use once every 2 weeks, we installed everything but didn’t have a cable run for the access point (AP215). It was estimated that the signal coverage would be good enough coming from the IT closet. It was confirmed with an AirCheck in the patient rooms. After the first couple of weeks that the practice was open, the staff decided that the AP was not in a good location and proceeded to move it to their liking instead of calling us. Then of course, we started getting complaints about how it was installed and where it was. Great. I’d love to go push their EKG machines around the office and hide it in a broom closet somewhere claiming that it worked better.

This brought up a new topic with our manager about our monitoring of APs and where the alerts are going. We hadn’t set up any monitoring for the APs because usually I’d end up in the controller once a day or so and if I saw one go down I’d look into it. Either that or I’d get a ticket about crappy coverage. It also brought concerns about the possibility of people stealing our APs. I was tasked to setup alerts so we’d get a notice every time certain APs went down.

So on to Airwave. I had setup an Airwave server (Device management and monitoring from Aruba Networks if you aren’t familiar) to monitor the new Aruba system that we are installing. I’ve got a thousand permanent licenses and 2500 eval licenses to play with. So I ended up adding all our current Juniper APs as well as the new Arubas that are going in. I’ll pull all the Junipers out when the aruba system is live.

Triggering from Airwave is quite easy. Go to the “System” tab at the top and then “Triggers”:

Screen Shot 2016-04-09 at 4.41.55 PM

Click Add and you’ll end up here:

Screen Shot 2016-04-09 at 4.43.55 PM

Since I was only worried about APs that went down, I chose the “Device down” type. There are a couple different options here that I left default. I’ve also read some advanced threads about triggering where more advanced options can be use to really dive into configuration alerts, etc. Nothing I need right now but good to keep in mind.

The main purpose of my trigger was to receive an email when an AP goes down so I created a group for “Monitored APs” (under the Groups tab) and checked the email notification button. This opened another set of options:

Screen Shot 2016-04-09 at 4.48.34 PM

The sender address is the email you want the message to come from. Initially this confused me because I thought we’d have to get Sys Admins to create an exchange account and then setup all this crap just to get it to work. Wrong. Airwave has a built in SMTP service. You can literally just pick some email address to type in and thats what it will use as the sender. I wouldn’t suggest using your CEO’s email address but I had toyed with the notion of using just for kicks.

Fill out the addresses you want the notifications to be sent to and you are ready to go.

One note… the “Suppress Until Acknowledged” means you will only receive 1 email and it won’t send another notice about the AP/device until you go into Alerts and click “Acknowledge”. This will reset the status and send the email again when its necessary. I turned it off because for now I’m not Acknowledging any of the alerts. I may change it later but a lot of the time I need to be bugged in order to keep stuff on my mind. Other the other hand, if an AP is bouncing, it would probably send me an email every 3-5 minutes. That would get on my nerves. I’ll fix it if needed.

Once you are finished with all your options, click add and its active right away. Now just pick some of the devices or APs that you want to monitor and add them to the Monitored APs group.

For testing I just unplugged the AP at my desk. Success.

Let me know some of the cool things you’ve done with Triggers below. And as always, feel free to correct me. I’m learning too!


’til next time…



Might as well start somewhere…

My name is Joey Feci(FeeChee) and I’m the Wireless Engineer at Northeast Georgia Hospital System in Gainesville, GA. I’ve never had a blog, never enjoyed writing, and grammar is not my strong suit. Hopefully this blog will help me learn about Wifi AND writing!

I first got started in IT in 2005 when I got sick of playing original music(drums) for tables and chairs in Atlanta for $25 bucks a night -split 4 ways. Not knowing anything about researching schools or choosing colleges, I saw an ad for DeVry university being the leader in technical education and chose to go there because there was no entrance exam really, I only had to sign some papers about loans, and they had the word Cisco in one of their program listings. Ahh, to be young and dumb.

Stepping back a little further, I built and owned my first PC only two years prior in 2003. While visiting some friends back home in Virginia Beach, I had the budget to get my first computer from a tax return and was guided by one of the most awesome guys I know(Tim Gawne) into the world of building your own PC because it was cheaper and you could get better components. Before this, I had only surfed the web on friends’ computers, and gotten completely addicted to Half-life and Counter-Strike.

So my DeVry education in IT started. At the end of 2006 I received an email from a friend of mine with a job description attached. It was for a repair tech in the Repair Services Department of LXE, a manufacturer of rugged scanners and computers. I went in for a basic interview where it was determined that my current skill set was not enough to be one of the techs they were hiring for. However, a couple days later I got an offer from the manager for a QC position. I would be checking all the repaired computers; configuring them back to customer settings; and passing them to shipping so they could be returned. It paid a little more than my current job in an appliance warehouse and was in the field I was studying for so I accepted and my career began…

Since the computers and scanners that were built were for warehouse installations, I was then introduced into the technology of wireless communication! Through the next couple years I was able to learn the complete product suite of LXE terminals while configuring and learning different client configuration parameters. Most of the configuration I was doing was to Cisco Aironet and Summit wireless radios. I’d configure the authentication and encryption methods as well as power management settings, roaming thresholds, and tx power settings.

I graduated from DeVry in 2008 with loads of debt and not much education. I had moved around Repair Services and ended up back in the QC position when the new guy couldn’t handle the position and I was brought back in to clean up his mess. For some reason I was the only guy in the department that could QC and configure 100+ terminals a day without holding up the line. I was eventually introduced to the Technical Support manager and after 6 months or so, I was offered a position on their level 1 team. This is when I finally learned that brain power was worth a lot more money than man power, lol. Unfortunately, 2009 had taken its toll on LXE and EMS(its parent company) and the company was put up for sale and bought by Honeywell in 2011. Thats when I learned about corporate takeovers. In the beginning it was “We are going to work together and make the warehouse terminal world a better place!” 3 months later they had fired all my friends in repair services and moved everything else to China. Kumbuya. Technical services and some sales and engineering were kept around because of contracts and knowledge transfer but everyone else was told to have a good life. I missed the layoff by 1 month.

I stayed with Tech Services for another year, all along, putting my resume on every site there was and submitting to every craigslist post that had the work “network” in the title. I sent 200 resumes and got 3 responses. In 2011 during the takeover, I had started going to Gwinnett Technical College where I was able to graduate from the OFFICIAL Cisco academy and started pursuing my CCNA.

Then in 2012 during the end of my Cisco course I received a random email. A company called Layer 3 Communications had received a resume from somewhere and called me in for an interview. 6 hours later I was hired and my call to Wireless Engineering was confirmed. I started in September of 2012 with the best company I’ve worked for so far and enjoyed a quick 2.5 year span with them before joining the hospital.

During my time at Layer 3 I was quickly thrown into the world of Wireless design. RF topics were not really mentioned in meetings and some of my first networks (I’m ashamed to say) were designed with Visio instead of Ekahau or AirMagnet. We had an older copy of AirMagnet but it was a couple months before I installed it. Luckily, that was short lived because we were getting ready to purchase Ekahau for the increased workload. Through the Ekahau site and videos, I was able to hear about people such as Keith Parsons, Devin Aiken, and Andrew Von Nagy. After seeing a bunch of Twitter handles, I figured out that it was the fastest way for me to learn from these guys. I created an account and so far I’ve built up a following list of 168 Wifi professionals and I check it daily to get my 10 minutes of Wifi training or at least some laughs about RRM.

Then I got the opportunity of the year. I had the interview with my hospital and took the position -starting on Memorial day of 2015. On my first employee-less day (remember “Memorial day”?) I was walking around with a colleague and lo and behold, here I am standing in front of Mr. Devin Akin. Devin had been contracted by the hospital before I got hired to perform a completed predictive design of 7 major buildings in the vicinity of our main tower. 1465 access points. Through the next 6 months I was able to build up a pretty good friendship with Devin and learn more than I had in the past 6 years of doing it on my own. While the education was mostly about design, I did have a fun time going toe to toe with a particular vendor that Devin later wrote about on his blog ( Just search “Technical Analysis”. You’ll figure it out. If you already know -then yes, I’m taking credit for that introduction. You’re Welcome.

Recently I was able to attend the WLPC2016 conference in Phoenix and meet some of the people that have helped me and others that are in the same boat. It was an awesome experience and hopefully I will continue to get the opportunity to go in future years.

’til next time…