Motorola MC9500 Handheld Roaming Issues

[LWA]

We have a client that we recently replaced their 15+ year old Cisco Aironet equipment with all Meraki.  They have a warehouse, an office building and a couple outdoor WAPs.  We spent a week or so working out the signal strength issues for the outdoor "yard", but now we are having issues with the Motorola MC9500 Handhelds (Windows Embedded) running the Fusion wireless connectivity software.  The handhelds connect the wifi without any issues.  However, while walking around the yard the signal drops a bit and randomly the handheld will connect to another AP that is further away and has worse signal.  Once that happens, the software on the handheld can't retrieve data and the handheld becomes a brick until it reconnects.  To my knowledge, wireless is working fine with mobile phones.  In fact, I took my Samsung phone and wandered all over the yard while doing a ping test to the GW and it didn't drop once.  I did look through the Meraki logs for my phone and I can see that it bounced around from AP to AP, but never once had any issues with it doing that.  I'm 80% sure it has something to do with the handhelds and their roaming abilities, but there is lack of any real support on the handhelds and Google isn't coming up with anything significant.  I'm new to Meraki and I'm trying to decipher all of the data that is available on the Meraki portal.  I'm wondering if anyone else has had this type of issue with Motorola/Zebra handhelds??

In the picture below, the arrow on the right side points to an outdoor AP (MR74) and the APs the handheld will drop and try to connect to are indoor and located in the building at the bottom of the pic with the two arrows.  These are MR42s.  The big red box outlines the general area where the handhelds drop.  Any ideas would be helpful!

Troy

[PhilipDAth]

802.11r is the best protocol for roaming.  If you have it on, try turning it off.  If you have it off, trying turning it on.  On the whole, you want it on when you have mulitple access points.

Next, when you tested your device was it using 2.4Ghz or 5Ghz?  Does the MC9500 use the same frequency as your device?  If they are different then your test results are not valid.  You'll need to repeat them using the same frequency.

For devices that are not roaming friendly you can sometimes give them a "hand" by increasing the minimum connect speed.  For example, I frequently make the minimum connect speed 12 Mb/s (which disables the old 802.11b).  When a device can't sustain this speed it has to disconnect and reconnect to the next nearest AP.  This often solves the problem of devices hanging onto an AP when it is a long distance away and there is a closer one.

I often disable the 2.4Ghz band if I can.  2.4Ghz is much more narrow.  There are only three non-overlapping channels.  So when you have 10 AP's you are guaranteed that some of the APs will be re-using spectrum.  Note that 2.4Ghz does have better range - if you can get some good clear spectrum.

Some lower cost devices or older devices don't support 5Ghz so sometimes you don't have a choice.

[LWA]

Thanks Phillip for the pointers.  The yard AP is primarily putting out 2.4Ghz only.  It does have an antenna facing to the north that puts out 5Ghz, which is then received by a repeater on the building in the top right of the image.  However, I went back through the logs and my phone was using a channel on the 2.4Ghz frequency.  As you recommended, I did go ahead and increase the min bitrate to 12Mbs.  It would be nice if there was a way to set that per AP.  I'll give it a couple of days and see if the performance is any better.

I was going to enable the 802.11r protocol, but when I went back into the specs of the handheld, it does not support that.  In addition, it is 2.4Ghz only.  The customer purchased these handhelds within the last 3-4 years, but apparently they hit the market back in 2009, so the technology is a bit dated.

Thanks again!

Troy

[TTS]

Hi Troy -

I am wondering if you have resolved the roaming issue on the handheld. Recently, I also replaced the client with Meraki APs in their warehouse and they are having the same issue with AP roaming. Let me know if you have figured out the solution.

TTS

[Uberseehandel]

---

@TTSwrote:

Hi Troy -

I am wondering if you have resolved the roaming issue on the handheld. Recently, I also replaced the client with Meraki APs in their warehouse and they are having the same issue with AP roaming. Let me know if you have figured out the solution.

TTS

---

Barcode readers are notorious for having their WiFi systems specified by Neanderthals. It is a barcode reader problem. Because they were/are comparatively expensive, businesses often hang on to them for a long time.

I would set up an entirely separate 802.11g/n 2.4GHz only WiFi network for them only. If you have enable .11b it will compromise performance for all other users, so keep the readers in their own environment.

[AndyF]

I realize I am late to this post and am sure you have already found the solution to your problem.  I thought I would comment since I came across this post while I was troubleshooting roaming issues in a warehouse as well.  Hopefully somebody finds this useful.  Our organization is new to Meraki and we recently deployed 23 Meraki access points (MR53E) in a warehouse and started noticing that clients would connect to only certain access points which in some cases were too far away. This was causing many disconnects and frustration for the guys on the forklifts while using their scan guns.  We are using 5 GHZ in our deployment.  In the end we found out that the scan gun devices were not capable of using all of the 5 GHZ channels we had the access points using at the time.  We had to limit our access point to using only UNII-1 and UNII-3 channels.  This resolved the issue in our case.