[davidu]

Great write-up. Great entrepreneurial tenacity. Would love more insight on the wireless challenges and how you tackle them? I wonder if a software monitoring app could detect increased noise and automate channel hopping.

Surely that must exist -- on the other hand, you mentioned the vendors do everything to lower the BOM, so perhaps they are lazy and this software is needed. Could be a good OSS project.

[chrishacken]

So Mimosa, one of the hardware vendors we use, does actually have this built-in to their firmware. The issue is, from what I've seen, is that it hops around too much. It also moves to congested channels sometimes. I'm sure there's a way to perfect it, we just don't have the time at the moment (I also don't believe they provide full API access yet, so I'm not even sure if we can change it without creating an automated UI tool that clicks around on a browser.)

[jaimef]

Jaime from Mimosa here...happy to speak to the software radio related stuff, thanks Chris for mentioning. So we've done a huge amount of experimentation on auto-channel approaches now that we've had a few years to collect data and analyze. Simple answer is it's really different in different environments, and if you're collocating with yourself vs. with other WISPs and gear.

We definitely allow the B5 series to be more aggressive on auto-changes since it's dual-chain, and is in a noisy band, so moving 1 impacted chain while we keep the other up, if it means better throughput, is a nice option IF that's what you want.

To your comment Chris, we definitely will begin to open channel programming via software API for y'all, and more rich monitoring in the API/SNMP info relatively soon (hoping before year end).

When it comes to 5 GHz, I always suggest "exclude before you auto" - we were unique in offering single page spectrum setup and live spectrum analysis to make it easy for you to program where you want the radios to operate. So smarter exclusion based auto can be really nice if you know how to use it well. As you know, we built this all in the radio, but hadn't opened it up externally much other than the UI/browser.

We actually also built in some L2 and beacon discovery smarts to locally detect other radios on the same sync settings to make sure to coordinate so to speak. Frankly speaking, even if the radio wants to make a change, it has no way of knowing if it might impact something else, it just knows what's best for it's own operation without some higher level spectrum management coordination, so some coordination intelligence is a must if you have some spectrum that needs protecting when collocated.

Really the need for auto behaviors is relatively limited to backhaul and unlicensed - most don't want their sector/APs to move unless it's a major event given all the clients connected. On new products like the B24, we really just analyze narrowing channels if things get bad enough, but there's really no other channels to move to, and on licensed products, you have to stick to your licensed channel of course.

On multipoint, for example, the APs collect and analyze spectrum masks from each client, and the primary thing they'll do is allow an individual client to narrow (e.g. from the 80 MHz channel to 20 MHz) in case they see more noise in a part of the channel, poor mans OFDMA, but that functionality becomes very advanced in the 11ax based chip for us in the future.

Lots of new stuff announcing and shipping this week and in Vegas next month, so stay tuned.

[sathackr]

How has your Mimosa gear worked out? I tested some B5s and they choked when you got them near even a tiny bit of interference. The B11s we have won't even hit MCS9 on a 1.5 mile link. I hear people swear by them, but in my testing, Airfibers & Rocket M5/AC spanked them every time, particularly when there was even a little bit of interference.

And FWIW I've never had auto anything actually work and pick the right channel. If you're trying to GPS sync, forget auto. But you know that already.

[davidu]

A founder of Mimosa (CTO Jaime) is a friend of mine. I'll try to direct him to this thread.

[sathackr]

I really wanted them to work.

I've tried to get their attention before and it winds up being a constant loop with Support. The B11s work good enough that it's not worth my time to chase the last couple hundred Mb/s. I just gave up on the B5.

10 We need you to connect these to the cloud so we can monitor them.

20 Okay we see your monitoring data, we will circle back in a month

30 Hey try this latest firmware update.

40 Are you sure the antennas are aimed right?

50 Try replacing the cables

60 Oh, your chains are unbalanced by 3db, that's the problem.

70 GOTO 20

By about the 3rd iteration we replaced the B5s with Airfiber using the same antenna and haven't touched it since. I've just accepted that the B11 link won't hit its advertised speed and quit spending time/money on it since we are putting in fiber soon.

I pulled the B5s back off the shelf a few months ago just to see if maybe newer firmware would fix, and once again a tiny bit of interference dropped a link that was doing 1.2Gb/s to 7mb/s or less.

I'm testing some B24s in a real-world link in a couple of weeks. I hope they do what they're supposed to.

Feel free to contact me via email -- my username at gmail

[walrus01]

From a WISP perspective you rarely want sector or horn antenna APs hopping to randomly chosen frequencies. Particularly if you have a well designed AB-AB back to back synced reuse or ABC frequency assignment pattern by azimuth. Any of this gear has a fairly full featured SNMP MIB and OID documentation so there are a lot of different backend operational support syetems you can use to monitor it.