Controllerless Networks

We are having a problem whereby Windows CE clients (multiple versions and multiple Vendors) are losing network connectivity . This happens on both 2.4 & 5Ghz bands when they seemingly have decent wireless signal (we have tried both bands to no avail).

 

Has anyone came across this with Aruba Instant firmware versions 6.5.1.0-4.3.1.3_59179 and below?

 

The client devices are forklift terminals using Summit wireless drivers and Motorola 'voice picking' terminals using Fusion wireless drivers.  These devices are used in a Warehouse environment - the fork terminals are kicked out of their telnet sessions while the Motorola voice units timeout/beep/get kicked out of their current picking tasks. 

 

Some of the settings that we are using:

Broadcast Filtering is set to All

Multicast transmission optimization is enabled

Dynamic Multicast Optimzation is enabled

DMO Channel utilization threshiold 90%

Transmit Rates – Both bands 12-54

DTIM interval – 1

Band Steering: Prefer 5ghz

Airtime fairness: Fair access

Client match: enabled

Cm calculating interval: 10 secs

Cm neighbour matching %: 60

CM Threshold: 5

SLB Mode: Channel

Client Aware: Enabled

Scanning: Disabled

Wide channel bands: None

 

Can anyone advise if there is anything else I can try? I have had multiple calls with TAC who either mess around with power levels, firmware versions or disable/enable client match but my problem has never been solved. I have also been told contradicting information by TAC that if Client Match is enabled but 'Scanning' is disabled then Client Match will not work. 

 

I'm starting to worry that I will always have these issues with Aruba Instant in a warehouse no matter what, as opposed to using a controller solution.

 

Just to confirm, this is happening in two separate warehouses that are both running Aruba Instant and both connecting to two separate Warehouse Management Systems.

 

Thanks

 

 

 

Warehouses are the most difficult environments to put wifi in, because there are so many things that can cause interference and so many variables.  Typically those things are observed, measured and mostly dealt with on install.  After installation, product and equipment can be moved and change the RF environment considerably, causing issues that did not exist before.  Forklifts add another dimension, because they are always moving, so roaming is also a consideration.  Lastly, voice requires the highest quality signal, and is delay sensitive, so an environment that is less than perfect will manifest itself in voice picking.   Those are some of the reasons why it is difficult at times to deal with warehouse issues over the phone.

 

With that being said:

 

- What kind of access points do you have deployed?

- How high are they mounted?

- How far apart are they mounted?

- How many SSIDs do you have deployed?

- Do you have individual clients running on both bands?  (Is the voice picker configured to operate on both the 2.4ghz and the 5ghz band)?

- Are your drivers up to date on your scanners and voice pickers?  Many of those devices were not deployed initially on 802.11ac access points and updated drivers allow better interoperability.

- Do you have any non-default settings on your SSIDs?  (I see you cut of the lower transmit rates...why?)

- If you disable scanning, APs will not be able to scan other channels to mitigate interference.  Turning off scanning is typically a troubleshooting step to make the environment more stable, if the access points have already chosen optimal channels.

- Client Match depends on scanning to find clients that are nearby, but not on their same channels.  You should be able to operate your network without client match, in principle.

 

 

 

Hi Colin

 

I greatly appreciate your reply.

 

I should have made myself more clear on the voice picking terminals. These terminals are not actually true voice over wifi. They are really text-to-speech over wifi.

Basically The Warehouse Management System sends data to the terminal that is displayed on the screen but also translated into speech -that is heard through a headset that is attached to the terminal.

The user then uses phrases and commands (that each user has to train when initially getting setup for use) that are then sent back to the Warehouse Management System. When there are problems with the connection to this system, the user will hear a number of beeps that are then followed by a comms error on screen. This then causes the user to get kicked out of their picking task, This causes alot of frustration for the guys as they are paid on a performance based pay scheme, therefore these interruptions/disconnects are affecting their pay packet.

 

The forklift terminals are bit more simple. Basically they logon to a Telnet session either using 'RFTerm' (on the Honeywelll Thor VM1 units) or with TelnetCE (on the IND3475). Alot of the time, the screens they are in can lag or else they can be completely kicked out/disconnected from their telnet session. The forklift driver then has to contact the WMS System Admin to kill their session so that they can login again and continue their work.

 

Just a note:

Warehouse 1 - is the only place where we use the Forklift Terminals

Warehouse 2 - is the only place where we use the "Text-to-speech"/Voice Picker Terminals

 

- What kind of access points do you have deployed?

Warehouse 1

A mixture of IAP304 (with directional antenna - AP-ANT-38) and IAP305 (omni). There is an IAP304 mounted on every aisle in the Warehouse - these are staggered so that they are at opposite ends every aisle (x22). The IAP305s are mounted in the middle of every other aisle (x11).

 

Warehouse 2

A mixture of IAP304 (with directional antenna - AP-ANT-38) and IAP305 (omni). There is an IAP304 mounted on every aisle in the Warehouse - these are staggered so that they are at opposite ends every aisle (x9). There are x2 IAP305s in the middle of the warehouse although we currently have these set to spectrum monitor mode.

Note: There are sections in this Warehouse/Cluster, dry goods and the freezer. I've only given you the AP numbers and information for the dry goods area as this is the area I have been focusing my testing and troubleshooting in.

 

- How high are they mounted?

Warehouse 1

IAP304 - at one end 6m high at the other end approx. 4m high

IAP305 x11 - approx. 50ft/15m high

 

Warehouse 2

IAP304 - x5 at one end approx. 3.4m high. x4 at opposite end approx. 5m high

 

- How far apart are they mounted?

Warehouse 1

IAP304 - approx. 12m apart

IAP305 - approx. 12m apart

 

Warehouse 2

IAP304 - approx 12m apart

IAP305 - approx. 18m apart

- How many SSIDs do you have deployed?#

Warehouse 1

1 x SSID in Cluster

 

Warehouse 2

1 x SSID in Cluster

 

- Do you have individual clients running on both bands?  (Is the voice picker configured to operate on both the 2.4ghz and the 5ghz band)?

Warehouse 1

No, currently we are running the Forklift Terminals on 2.4ghz band only - 802.11g. I have actually tried running these on 5ghz band - 802.11a - but we just have the same issues.

 

Warehouse 2

No, the "Text -to-speech"/Voice Picker Terminals are all running on 5ghz band - 802.11a.

 

- Are your drivers up to date on your scanners and voice pickers?  Many of those devices were not deployed initially on 802.11ac access points and updated drivers allow better interoperability.

Yes, we have updated the drivers of the client devices to the latest possible versions.

 

- Do you have any non-default settings on your SSIDs?  (I see you cut of the lower transmit rates...why?)

The lower rates were trimmed I believe to promote better roaming. This was done by TAC when we had contacted them during our initial setup phase of Warehouse 1. We then carried this on when we setup Warehouse 2.

As regards non-default settings - the following were also set:

Broadcast filtering to All

Multicast transmission optimization to Enabled

Dynamic multicast optimization to Enabled

DMO channel utilization threshold 90%

802.11r, 802.11k & 802.11v are all unticked.

 

- If you disable scanning, APs will not be able to scan other channels to mitigate interference.  Turning off scanning is typically a troubleshooting step to make the environment more stable, if the access points have already chosen optimal channels.

Scanning is off in Warehouse 1. But on in Warehouse 2. This hasn't made a difference either way.

- Client Match depends on scanning to find clients that are nearby, but not on their same channels.  You should be able to operate your network without client match, in principle.

 

On another note in Warehouse 2 we have completely locked down (admin assigned) channels and power on APs (All APs are either channels 36 , 40, 44 or 48 - non-DFS channels and are either set to 15dbm or 18dbm). When ARM was enabled we thought it might be making too many changes making the RF environment unstable - I admit this is a longshot, but I would try anything to stop these disconnects. 

 

I can upload maps if this helps at all.

 

Thanks

 

 

 

 

 

 

 

Have you used a handheld with Aruba Utilities from the Google Play Store to see how many access points you can see in any area and at what signal strength?  That might give you an idea of your coverage from the handheld point of view at your current transmit power.

 

You might also consider re-adding more non-dfs channels to your allowed channels to avoid interference.  APs on the ceiling can see each other much better than the clients and that might be a source of contention if you are not spreading your channels out more.

 

In the warehouse, can product get all the way to the ceiling, or not?

 

You might want to try pinging a device from a wired endpoint and walk some rows and see where and when it might get disconnected or lose alot of pings, to get an idea where you problem lies.

 

Have you seen the PDF of the presentation here?  http://community.arubanetworks.com/t5/Airheads-Breakouts/Hostile-Environments-Wireless-LAN-Design-for-Warehouses/ta-p/247147

 

 

Hi Colin

 

I think I'll download the Aruba Utilities from the Play Store and see if anything stands out although I do use inSSIDer when looking at power levels etc.

 

We have only started using solely non-DFS channels (36, 40, 44 & 48, i.e. UNII-1 Domain) as of last week in Warehouse 2. We tried this because we noticed that every now and again a client would get a ping response time of 2000ms or more when using the DFS channels and thought that this might be causing our disconnect problems. We had read that clients can only passively scan DFS channels which can take 4 times longer than normal and could be causing these high response times.

When we changed Warehouse 2 to non-DFS channels only we noticed that we didn't get these intermittent high ping response times anymore, although the disconnect problem is still on-going so it really made no difference.

I don't think we are able to use any of the higher non-DFS channels (UNII-3) because we are in the UK, therefore I believe we are stuck with channels 36, 40, 44 & 48 only (as far as non-DFS channels go).

 

As regards the APs on the ceiling. We actually have the 2 IAP305s in the middle of the ceiling in Warehouse 2 set to spectrum monitor. And we are just using the IAP304s that are shooting down each aisle.

 

Yes, product on the shelves/racking can get pretty much as high as the ceiling.

 

I will try the pinging the wireless client device from a wired endpoint and see what are response times and ping rates are like and I will report back.

 

And thanks, I have read Charlie Clemmers presentation and also the one by Chuck Lukaszewsk.

 

Are there any logs that you think might be useful for me to look at when we experience these issues? One that I could maybe look at in real-time to see if anything jumps out?

 

Also, how can you tell if you have too many APs or the power is too high? Is there anything within the CLI I can look at to determine this. When we do a walk around, our RF looks good, so it's hard to identify if the issues we are having is because of power or lack of, or because of channel quality, contention etc.

 

Thanks

Paul

 

 

 

 

 

 

 

 

 

 

 

Warehouses can have lots of square footage, so it is very hard to troubleshoot issues.  It is most important to find out where the most of the complaints exist, and focus on those limited set of areas, to try to make progress.

 

Using Aruba utilities on an Android Handheld is mainly to get an idea of how your other handheld devices see how many access points.  If they can see more than two access points on the same channel, that *might* be a source of contention.  Two access points on the same channel that can be seen is not a dealbreaker, but look on the Instant GUI to see what percentage utilization each AP has on its bands to see if you have more than 25% utilization.

 

You should enable all the lower rates to get an idea of how the devices roam at the current transmit power and see if they roam smoothly, or do they drop packets even when they are not roaming.  Dropping a packet or two during a roam is not a dealbreaker.  If you see your client going past an AP and not roaming to it, your overall power might be too high.

 

If you have site survey software, you should do a limited survey of the areas determined to have the worst issues, to see what access points are really providing coverage in those areas and if they are part of the problem.

 

Lastly, you should consider having an expert come out to your facilities to see if there is a hidden problem with your RF (interference) or if your access points or antennas could be mounted wrong and providing the wrong coverage.  Tracking down an issue that has multiple causes is very difficult without actually seeing the space.

Hi Colin

 

Can you explain what the message "Auth failure......Reason AP is resource constrained" means? I've read that this could mean that the AP has reached it's max client threshold (this is very unlikely because this is set to 64 and we were the only client on the AP at the time).

 

This may be completely unrelated to the disconnects we are experiencing, but I keep coming across the same message when I am looking at the logs in Support tab on Instant (ap log all) and it would be good to rule this out so that I'm not focusing on this too much.

 

Thanks

Paul

That is a generic message the AP sends if it is beyond capacity when it wants a client to go somewhere else.  It also could be send as the result of client match load balancing.  You can turn off client match to see if those messages go away.

Hi Paul,

 

Did you manage to solve this disconnects?

 

I am currently experiencing the same issuess with forklift terminals using Summit wireless drivers.

 

Thanks

Hi Patt

 

We have never found a true fix for this issue, but as a workaround we set the Radio Mode to B rates only and then adjusted the Transmit rates on the SSID to Min = 5 & Max = 11. We were able to do this because the clients using the Summit radios where the only devices using the 2.4GHz band - all our other devices in this Warehouse utilised 5GHz.

 

Once we made these changes we carried out a few test walks arounds the Warehouse with the devices using the Summit radios (Honeywell Thor VM1 & IND 3475). The results actually looked awful - going by the readings in the Status & Diags tabs.

I dont know about you, but when we had the Summit radios using 802.11a or 802.11g the ping responses, roaming etc. all looked good, even though we were getting alot of complaints.

Anyway we decided to go ahead and roll out the new Summit settings (802.11b) as we were at the end of our tether with these. 

 

Since we have made these changes though, the users in the Warehouse have had no real issues and we have had no complaints in the last 3 months. Before we made these changes we were getting multiple complaints of Telnet sessions getting dropped every day.

 

Paul

Hi Paul,

 

Thanks for sharing your workaround!

 

My customer is using the same devices (Honeywell Thor VM1).

We noticed a lot of disconnects we could not explain with the AP-305. Some troubleshooting steps we took were also using low transmit rates and B rates also but always in combination with higher rates.

 

We have replaced all the AP-305s for AP-105s for now and are still looking for a decent solution. Currently im setting up a lab to run some tests with the AP-207. It appears to be a AP-305 thingie since the customer did not report any issues since we replaced these. Also in our lab we did not get any disconnects with the AP-105 while getting multiple disconnects every hour with the AP-305.

 

We have tried multiple different settings like 'legacy chain mode' and also received best practise guidelines from Honeywell to collaborate with Aruba wireless. Unfortunalely this did not show any improvement.

 

I knew we wouldn't be the only one facing these issues. Thanks again for the workaround, I will definitly give it a try!

 

Kind regards, Patrick

Yes we felt the exact same way, "surely we can not be the only people having this issue??"

 

You should definitely give the 802.11b & rates combination a try, as I said, we are now not getting any complaints from the Forklift users. Although, it's kind of annoying that we have implemented this all singing and dancing wireless solution with brand new manufactured Honeywell Thor units and end up limiting the 2.4GHz band in our warehouse to 802.11b rates, but what can you do!

 

Just curious, have you encountered any other issues with other Warehouse type clients dropping out (Motorola, Symbol etc.)? 

 

Paul

 

 

 

 

The customer is only using Honeywell Thor VM1 clients at this location.

They do have another warehouse but without any issues. Probarly because this location was using AP-105s since the beginning.

The issues only started since they moved from Cisco wireless to Aruba AP-305's.

 

I will ask the customer nex time I talk to him, which will be within one week.

 

Patrick

Hi Patrick

 

Can I just ask, is your customer who is having issues with the 305 APs  using a controller or are they using Aruba Instant versions of the 305s?

 

Thanks

Paul

Hi Paul,

 

The customer is using AP-305's with a controller. I have upgraded and downgraded to controller to see if it a version issue but unfortunately not. AOS 6 and AOS 8 is demonstrating the same issues.

Are you using Instant AP-305's?

 

To answer your previous question; the customer has also motorola devices (Motorola MC9090 en MC92n) at a different warehouse. The customer is not experiencing any issues with these devices. Access points used at this location are all AP105's (with controller aswell).

 

Kind regards, Patrick

 

 

Yes we are using Instant. Like yourself, we have tried multiple firmware versions to no avail.

We are also having issues with Motorola WT4090 & WT41N0 units (users getting completely disconnected). Plus Telnet sessions on Motorola Barcode scanners seem to 'run slow' alot of the time  (MC9090, MC9190 & MC920).

We have roughly 125 IAPs (all either 304 or 305s) across 3 Warehouses so we don't really have an option to try any previous versions of IAP. It's getting very frustrating to say the least.

.

Hi - I was wondering how this is going?

 

We have clients using VoicePick (VoCollect) and WinCE devices using IAP305 infrastructure and are running ok.  Definately disable Client Match, band steering, 802.11r.

 

I didn't like the surprise that UNII-3 wasn't available on these AP's and I have been told the the RW model has been based off Europe's regulations even though UNII-3 is available here in Australia. 

 

Wireless frame captures are the best way to see what is going on 'in the air' - do you have access to capture software that will capture mulitple channels/USB adapters at once?

 

On the client side try Dr Debug's Netlog feature available on Motorola/Zebra newer OEM firmware.  It gives you a pretty good debug from the client's perspective. 

 

I'd be happy to analyse any frame captures if you can obtain them.

 

Good luck.

 

Hi Paul, I really appreciate your post. We are using a mixture of IAP304 & IAP305, the IAP304 are using external directional/patch antennas (AP ANT 38) we have our doubts about the quality of these external antennas though.

 

Regarding UNII-3 channels, apparently it became legal to use these channels in the UK in Aug 2017 - see:  http://community.arubanetworks.com/t5/Wireless-Access/5Ghz-UNII-3-band-C-in-UK/td-p/313497

I'm not sure about Australia though. We have not really focused on this too much, I'm not entirely sure but think it would be unlikely that our devices would support these channels (without some sort of firmware upgrade anyway).

 

We have found that we had high latency and some roaming issues when we let devices use DFS channels - this was due to the fact that client devices can only passively scan DFS channels. Therefore, in two out of our three Warehouses, we are only broadcasting on channels 1, 6 & 11 on 2.4Ghz band & channels 36, 40, 44 & 48 on the 5GHz band. We have these IAPs locked down to static channels and power.

In the other warehouse we have let ARM take care of 5Ghz, while we have locked down 2.4.

We are dubious about how effective ARM is in a warehouse environment, although it seems to work quite well in our offices (separate cluster).

 

Is there a reason you suggested to turn off client match? Everytime we are on with TAC they insist on turning this on.

 

We are currently running firmware version 6.5.1.0-4.3.1.3_59179. TAC have asked us to upgrade to 6.5.4.4_62887 in order to fix an issue with a high number of 'Radio Resets' on 2.4GHz band. We have upgraded firmware on one of our Warehouse Clusters, which "seems" to have fixed the radio resets issues (although we haven't had any other issues in the other two Warehouse Clusters using the older firmware either).

 

We don't have access to any wireless capture software, we have priced it but the seem to be very expensive and would find it hard to justify purchasing it to use it once in each Warehouse. I'll hunt around again because I've really only looked at Ekahau and Netspot.

 

As for Dr Debug Netlog, our devices don't seem to have this feature. We are using a mixture of devices in each warehouse including VoCollect A720, Motorola WT4090 & WT41N0, Motorola barcode scanners (MC9090 & MC9190) and Honeywell Thor VM1 forklifts.  The WT4090 & MC9090 have actaully been discontinued so there are no new firmware releases for these.

 

Hi Paul - great name by the way. 

 

Yes UNII-3 is available now but for some reason the firmware for the RW model that we get in Australia disables UNII-3, even though it is allowed by our regulatory body.  And I tend to stay away from DFS channels due to the passive scanning, and Honeywell recommends not to use anyway.

 

Client-match simply from personal bench testing gave me horrible ping latency so that is the only reason I say this.  This bench test was not in a warehouse so take that comment with a grain of salt.

 

ANT 38 - Never used these before but I see they are quite a high-gain antenna - unless your aisles are very long (80-100m) I would make sure these antennas are pointing down towards the ground slightly - say 20degrees? Also counter-act the higher gain by lowering the AP power level.  You mentioned you have set to 15dBm -18dBm however I would consider dropping these to 10dBm-13dBm. BUT do the following test first to get an idea about your cell sizes.

 

TEST:

Grab a HHT (eg: MC9x90) using the summit utility and walk from the connected AP along a typical roam path and:

1 - Stop at the point where you would expect the client to roam eg: at the end of the ailse/next aisle - what is the RSSI the client is seeing?  How far off is it from the roam threshold summit global setting? 

2 - Carry on walking until the client actually does roam then stop.  What did the RSSI reach to before the device roamed?  Look at your location, should you be connected to a more appropriate AP?  Did you pass another AP before you roamed?

 

Your ideal coverage cell size should be so that the client reaches it's roam threshold RSSI, from step 2, but at the point you would expect it to roam from step1.  Change the power levels on the AP and test again until you find what the happy medium is.  Oh and if you have enabled the wifi signal icon on your devices, then ignore the operators that tell you that the signal levels are low.  These devices won't roam until the signal level is low so you actually want to encourage these levels to get low more often.

 

Another good test is to repeat the above steps, but try and stop just before the point that the client roams if you can.  Then compare the RSSI level on the AP side - ie: On the Instant VC see what RSSI the AP is 'hearing' the client at.  This should be fairly similar to what the client is 'hearing' the AP at.  If your client is hearing the AP much better than the AP is hearing the client then you need to reduce your cell size by lowering the Tx level of the radio.  

 

We have found even with 5-6dBi patch/directional antennas, clients will tend to stick to these AP's even when moving 1 or 2 aisles over from the AP unless the AP power is kept low.

 

 

If using ARM try to tune the highest and lowest dBm that the AP's can use -  good rule of thumb is 3dB lower and 3dB higher than your ideal power levels found in the testing I recommended.  Typically we disable ARM especially if the omni AP's (305) are sitting high and above stock.  This because the AP's hear each other far better than the clients on the floor and often power down too low.

 

Sorry a long post!  But hopefully this gives you something to try as it sounds like your patience is running thin.

 

I'll keep an eye out for your response...

 

Paul

 

 

Wow, some great tips here Paul, I really appreciate the effort. We will definitely try these two tests to get a better idea of our cell sizes. We wil have to wait until a weekend to make any adjustments though as we can't risk upsetting the Warehouses any more than they already are!

 

In the first test you mentioned the roam threshold of the "summit global setting", we found that roaming is only triggered if the device falls below an RSSI of around -70dBm AND it can also see an access point at better than -60dBm. Therefore, it never really mattered what we set this Summit global setting to (I think in most cases we have tuned it to the most agressive possible roam, -50dBm.

 

Regarding our antennas, we have found it difficult getting any installation information about the AP-ANT-38 (except for the spec sheet). Basically, we have mounted the IAP 304 & AP-ANT-38 at heights of between 3m and 6m and pointed them at a very slight angle towards three quarters of the way down the aisle - in two of our warehouses the aisles are around 100m.

The only other change we have made is set the 2.4GHz & 5GHz antenna gain to 7.5dBi (within the "External Atenna" tab on the Instant VC). We are not entriely sure if this is accurate.

Also, there are three antenna cables coming out of the AP-ANT-38 antenna/panel (labeled +45°, V, and -45 °), we don't think these need to be connected to the IAP304 in any certain way but we would like to see this confirmed somewhere. The 3 antenna connectors on the IAP304 are labeled ant0, ant1 and ant2.

 

You mentioned that even with 5-6dBi patch antennas, clients tend to stick to these APs even when moving 1 or 2 aisles over. We have also found this to be the case. We believe that clients are catching "lobes" of the antenna pattern. The only problem is that we cannot really turn the APs down anymore as then the signal is too poor at the far end of the aisle approx 80-100m away (and there isn't a good enough signal to roam to the AP at the end of the next aisle).

 

Also, we have definitely steered more towards turning off ARM in a warehouse environment. This was due to the same scenario you described, in that the APs hear each other far better than the clients on the floor and then powered down too low - in turn the APs were way too low for the clients. In our case, the APs along the wall are all line of sight and spaced out approx. 12m from each other, so we have turned off ARM in two of our warehouses so far and came up with a static channel and power plan for these.

 

Thanks again for your reply, as I have said, we will definitely be trying the tests you kindly outlined.

 

Thanks

Paul

 

 

 

 

 

 

Hi Paul, look to my post in the following thread. http://community.arubanetworks.com/t5/Controllerless-Networks/Roaming-and-connection-problems-with-Motorola-Symbol-Scanners/m-p/434335#M21332 That should also help for you. Best Regards from Germany Alexander

Hi Alexander. First of all many thanks for providing your suggestions. Your settings are more or less identical to what we are now using, other than we have kept 802.11b rates transmit rates as 1, 2, 5.5 & 11 (not just 1 & 2Mbps).

We have found these settings work better than any others that we have tried, even though we are still experiencing some Telnet disconnects with Honeywell Forklift terminals and roaming issues with Motorola WT 41N0 devices.

Hi Paul,

please try with 1-2 MBit, more stabile then with 1-11.

Also have a look for the legazy mode settings.

 

You have a CE.NET 7.0 Device.

Which WiFi supplicant did you use, the original from the OS or another one like SUMMIT on the old MC9060?

Have you the possibility to optimize roaming options over the device?

Inhouse/Outdoor?

Need more information.

There are no insoluble cases only cases with more or less chellenges. ... :-)

 

Regards from Germany

 

Alexander

Hi Paul,

 

which "Battery Usage Mode" have you setup in the WiFi Settings?

Try with "CAM" if you have selected another one.

 

Set "Transmit Power" to the highest value.

Set "Coutry" to "Allow Any Coutry"

Don't use DHCP.

Disable 802.11d on the device.

 

Regards from Germany

 

Alexander

Hi Alexander

 

I'll try and answer all your questions in the order you asked them.

We have legacy mode enabled (only recently - approx 3 weeks ago).

All Motorola devices use Fusion WiFi supplicant (this includes all variations of the MC90 'scanner gun' and the WT4090 & WT41N0). We have two types of Forklift Terminals that both use the SUMMIT WiFi supplicant (Honeywell Thor VM1 & IND 3475).

Yes we have the possibility to optimise the roaming options on the Forklift terminals using Summit. Not so much on the Motorola devices using Fusion.

What do you mean by Inhouse/Outdoor? If you mean is our wireless environment an outdoor or indoor one, then we have 3 Warehouses all utilising WiFi indoor only.

 

For battery usage, where available we have set all devices to CAM.

On all Motorola devices using FUSION - we have set Transmit Power to 'Automatic', the only other option is 'Power Plus'.

On all devices using the SUMMIT chipset - we have set Transmit Power to Max.

For Country - we have set all Motorola devices using Fusion as 'UK'.

There is no option to set this on devices using Summit.

"Don't use DHCP" - this is very interesting as we have had this same suggestion recently from Honeywell. We are definitely hoping to try this. Currently all our wireless clients in all 3 warehouses are using DHCP.

Disable 802.11d - we have 802.11d disabled on all Motorola devices using Fusion. There is no option to disable 802.11d in Summit (that we are aware of).

 

Thanks

Paul

 

 

 

 

Hi Paul,

 

i read that u use the "AP-ANT-38".

Why? Its only a 45Degree Antenna.

Did the antennas 1-2-3 on each AP look in the same dirrection?

If not, so please change that, all directed anntenas from the same AP should allways have the same direction.

 

Are the antennas mounted on the ceiling or outer wall? 

 

For warehouse it's better to use 360Degree antennas.

 

Regards

 

Alexander 

Hi Alexander 

From looking at the following link https://www.arubanetworks.com/assets/ds/DS_AP-ANT-38.pdf  I believe the AP-ANT-38 is a 60degree directional 'Panel' antenna that points in one direction (although you are correct that the antennas are labeled 90degrees, +45degrees and -45degrees). These are mounted on the outer walls approx 5-6m high 'staggered' at the end of each warehouse aisle (Bottom of first aisle, top of second aisle, bottom of third aisle and so on).

These were the antennas recommended to us by the third party supplier and our local Aruba rep.

We also worry that these might be the wrong antenna types for our warehouse deployments, although we have appox 50 of these across 3 warehouses.

 

Thanks

 

Thanks

Paul

Hi Paul,

 

ups, my fault i didn't see that it is a MiMo antenna.

Forgot the direction stuff, sorry. :-)

 

With the beamwidth we are both wrong.

The beamwidth is H/V 60 degree, +-45 degree is the polaritation. 

 

Regards

 

Alexander

Hi guys,

do you have any update about the problem?

Do you have find any working configuration or firmware?

 

We encountered the same issues with an Aruba 305 deployment with Aruba Controller 7000

 

Regards

Davide

 

Hi Paul,

 

if you have a footprint wit the AP positions, so please send it to me.

Also some pictures of the APs, to see how thea are installed.

 

alexander.fuchs@n-g-i-s.com

 

I have over 100 WiFi projects on my back. :-)

 

Regards

 

Alexander

Hi Alexander

 

I'll get these sent over to you so that you can have a quick look.

 

Thanks

Paul