Category Archives: Beacons

Mist Systems Polishes Their Message at Mobility Field Day 2

It’s always refreshing when a truly original story comes along in the WLAN world. Mist Systems isn’t quite brand new (I wrote about them for Network Computing back in 2016) but their approach is fresh enough to cause some good energy in the room when you do get the chance to hear a briefing from the company’s top dogs, and I recently got that chance again at Mobility Field Day 2.

Here’s the thing about Mist, now- today: if you’re not careful, their story can sound like another one of the many from network vendors where terms like AI and Machine Learning are bandied about like the Buzzword Flavors of the Month. But Mist was talking this language well ahead of the current curve. Where established vendors are largely painting their long-running gear up in a coating of hype and APIs, Mist is actually new magic built by data scientists and proven network visionaries. It’s heady, exciting stuff.

But can Mist make a legitimate go of it as new player in the Big Customer Kickball Game where most current potential customers have already chosen a side? Here, only time will tell as Mist’s marketing paradigm is put to the test. I can share my own opinions and gut reactions from the Mobility Field Day for you to consider, and welcome any dissenting opinions or comments:

In Mist’s Favor

  • When Bob Friday and team tell the tech story behind Mist, it’s impressive and believable
  • Mist is the real deal when it comes to Machine Learning, etc- where the message feels forced with other vendors
  • Mist seems to have mastered the UI challenge (put lots of important stuff in front of the WLAN admin without making it feel like overload) with their cloud dashboard
  • Mist uses no controllers (bug hotels) or user-upkept bloated NMS system
  • They tell a great story on bug management and code quality
  • The virtual BLE beacon thing is huge. As in freakin huge. And it can stand alone even if you don’t need Mist’s WiFi solution
  • Nyansa-like analytics are compelling
  • Long-time users of established systems are getting burned out in spots on license overkill, huge costs- creating potential openings for a WLAN vendor change

Of Concern

  • Mist is late to the overall WLAN party, so is up against established players
  • The lack of switches and security appliances can be problematic in some RFPs, and when looked at through bullshit lenses lenses like Gartners Magic Quadrant
  • We’re still not hearing enough about “unnamed Fortune Blah Blah Blah customers” to really do our own independent verification of how Mist is working out in the real world
  • Mist is just getting ready to ship outside APs later in 2017, and how that impacts their analytics (especially when outside/inside WLAN are managed in same pain of glass) remains to be seen

I really enjoyed what I saw and heard from Mist, and it’s obvious that the company’s leaders truly believe in their baby’s potential. And- you don’t just have to hear my opinion… form your own after watching the Mist MFD session here.

 

 

 

 

Quien es Mas Macho? A Beacon Battery Brouhaha!

There’s not a lot of networky substance here, so if you’re looking for that, well- you just keep moving. But, if you’ve been following what’s going on with beacons and location services that use these little gems, you might want to keep reading.

I give you… Exhibit A.

Beacon2

At the top, we see The Aruba (Meridian) BT-100 beacon, which was given to me at Wireless Field Day 8 as I sipped a cold one and got briefed on lofty tech topics at Levi’s Stadium by Aruba’s SMEs (I run in those circles). At the bottom, we have the Gimbal beacon, by Qualcomm. This was another freebie, which I scored during a promotion. Each has it’s place in the beacon universe, with the power to help build amazing success stories in the field of location based applications and services.

This isn’t a Beacon X vs Beacon Y smackdown in the making- but it is an opportunity to point out a pretty important point about beacons.

I give you… Exhibit B.

beacon 1

Using my world-class Leatherman Skeletool CX (special Kieth Parsons Edition), I jimmied my way into the innards of each beacon with the precision maneuvers of a skilled surgeon. And what I saw made me do some thinkin’ about the powerful lonely feeling that grips a man when batteries go dead and whatever the thingy is in play stops working. Which brings me to the points of this blog:

  • Some batteries are bigger than others
  • Bigger batteries have more capacity
  • More batteries combine for more capacity
  • More batteries that are bigger combine for even more capacity

Sounds so simple, right? The implications aren’t so profound if whatever you’re doing with beacons only needs a few of them in easy-to-reach places. But I have been to Levi’s Stadium, oh yes I have, and I can testify that copious amounts of beacons are in use and not all are easy to get to. This is an example of a place where beacon battery brevity blows. 

You want loooong battery life in many beacon situations, and out of the box the BT-100 promises an impressive 1,460 days. For those not up on Common Core math yet, that equals 4 years. By contrast, the Gimbal above is rated for “many months” (I got about 6-7 months out of mine).

The Gimbal uses the CR2032 battery, whereas the BT-100 uses two of the phat-daddy CR2477 cells. This is the biggest “watch battery” I’ve ever seen, personally.

What’s the Big Deal?

To me, battery refresh on deployed beacons has the potential to significantly add to total TCO where hundreds are deployed, especially if ladders need to be climbed and maintenance windows need to be followed. This simple example shows that not all beacons will have the same battery life, based solely on the battery used (note- I’m leaving out some important operational parameters that impact battery life, but these are beyond what I’m trying to get across here).

There are many, many more beacons on the market than just these two, but if you’re going down the beacon path, make sure you consider expected battery life as you make your choices.


Just getting started with beacons? Here are a couple of blogs I wrote up as I went from knowing absolutely nothing about beacons to knowing enough to be able to not be totally clueless.

Beacon Baby Steps
A Little More on Beacons

Code Suck Regulation: Should We Fine Vendors For Major Code Bugs?

Tell me if this sounds familiar- you spend top dollar on brand-name networking gear, only to put in into service to have some major future bork out and cause your organization significant embarrassment. You’ve researched the product, have been cajoled into buying from a vendor that swears you’re getting a great piece of gear, and yet something catastrophic makes your deployment go sideways. You engage tech support, verify that your topology and configurations are OK, yet the suck storm still pummels the networked landscape. You’ve found yourself in The Bug Zone.

Ever been here? It gives a bloke or blokette a powerful lonely feelin’. With users in pain, managers who may or may not be sympathetic, and the little voice in the back of your head asking “what could I have done differently?” that ultimately answers itself with “maybe I shoulda cut this vendor off after the last dozen major code issues. But like a victim of domestic abuse, I keep going back for more, hoping it’ll get better.” 

Does this ring familiar with anyone?

I’ve heard from a lot of individuals in the greater IT community of late about all of the many bugs they have hit, and 75% of the time the lament is accompanied by something like “the rush to get ever more features under the hood is making the whole damn thing a time bomb of suck, and it feels like QA is being short-cutted in the name of getting it to market faster”.

What if, in our support contracts, we added a section that gave us a weapon against major code bugs? Perhaps we need to become our own CSRs (Code Suck Regulators) and have it in our agreements that any major code bug that is verified to cause network downtime or significant user impact when a half-baked feature sends the network into a tailspin results in a fine of $1,000 a day until the bug is resolved by the vendor?  Would code development maybe slow down a bit and QA labs be better funded, staffed, and used? Would major bugs drag out for weeks and months if the meter was running at each affected customer site? I’d also suggest making vendors keep all of their verified major bugs in plain view of the world on a vendor-neutral website that requires no login to see bug details and impact, with posting a mandatory requirement enforced by somebody or other- or again, fines are levied.

OK- I get that the networking industry and all of it’s various niches doesn’t, and won’t, ever work this way. At the same time, it’s mildly fun to think about not being victimized anymore by companies that don’t feel like they really care about their code quality after you’ve used their stuff long enough to see definite trends in significant bugs. And I am talking about SIGNIFICANT bugs- the ones that are devastating to network performance, and your organizational and personal reputations, and not just horrible misspellings or cryptic broken-English error messages on a webpage.  Maybe fines aren’t the answer, but if you’ve got a better idea on how to change trend of Free-Flowing Suck when it comes to code, I’d love to hear it.

(This is where some of you are thinking- bah, just do better testing before you deploy the code that you say sucks. My reaction: yeah, good luck with that. There’s only so much you can test, and only so far you should have to go to be the vendor’s QA department.).

A Little More on Beacons- Promise and Frustrations

Last week, Beacon Fever bit me, as I described here. Since then, I’ve made little progress in actually doing anything of real-world value with the three Qualcomm Gimbal beacons that I have on hand. But that doesn’t mean I haven’t gained a bit of an education in the few hours I’ve noodled around with them as I’ve consorted with The Google on where to go next. Allow me to share just a little more on Beacons, then I’ll likely put the topic away for a while.

What I’ve Learned:

  • There is a good variety of beacon hardware out there. Here’s another list
  • If you don’t want to $pend, Android and iDevices can be configured to act as beacons for testing
  • There are lots of mobile beacon management and scanning apps out there- some from the beacon manufacturers and some from 3rd party developers
  • The entire proximity paradigm with beacons is built on leveraging “degrees of nearby-ness” like near, far, immediate vicinity, out of range
  • Beacons can be USB powered, or battery powered. If using battery, there will be administrative burden of battery upkeep in large deployments over time
  • Beacons don’t just magically come to life, you have to activate them and do a basic config
  • Every beacon maker seems to have their own management console
  • You can see where heavy beacon use would very much be “another thing to manage”, despite having really cool real-world use cases
  • A “UUID” gets assigned to all beacons in an organization that will be part of the same “system”
  • Each beacon can make use of a Major and Minor field to further segment/identify them
  • Without an application to use with them, beacons aren’t real exciting
  • To leverage beacons, SOMEBODY has to do some coding, and there are a number of frameworks to do that in
  • For people like me, who are definitely not endowed with coding skills, some companies are trying to make “getting started” a little easier
  • There are a lot of beacon videos on YouTube, and blogs from others’ efforts to be had online
  • It doesn’t look like all vendors beacons are welcome in each other’s development environments
  • Connected users “opt in” by enabling Bluetooth on their smartphones, tablets, etc.

That’s the short of it for me, so far, on actual knowledge gained. I also tried to do more with my Gimbal beacons, but found some frustrations- like simply setting the UUID, Major and Minor fields. It looks like other vendors make this a lot more intuitive, but perhaps my lack of experience is the problem here. On my Gimbal developer account, I understand each individual word but get foggy when you put it all together in phrases and sentences. There is a Gimbal iOS management app, but none for Android that I have found yet.

I did discover a couple of promising leads for myself in learning more, as a mental-midget when it comes to programming. Estimote makes a popular kit that comes with three beacons, and from what I can tell their app-building tools seem to have folks like me in mind. But… each kit is $99, and indoor location requires two kits (for some unspecified reason). I’m not ready to drop $200 on beacons yet, but maybe at some point.  And… Meridian (An Aruba HP company) also seems to understand that some of us need all the help we can get. They put a very friendly face on getting started, and I hope to learn more about this product set/application framework in the months to come.

So… that’s all on beacons from me for now. If anyone reading gets further with these fascinating little transmitters, please share what you learn.