More details on unattended mode. This did not come from me, so use it at your own risk:
API: PowerPolicyNotify

Unattended mode tells the system that your code is running something that the user does not need to see, for example, synchronizing in the background. Call PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE) to get into unattended mode and PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE) to get out. This is a special state that is different than most. You can call it from any current state, but it only goes into that state in special cases. If the system is currently in Resuming state, it goes into the Unattended state. Otherwise, it stays in the current state and increments a reference count on Unattended. If the user presses the power button and the unattended reference count is greater than zero, the system goes into Unattended state, rather than Suspended state. PPN_UNATTENDEDMODE sends a message to Power Manager, requesting a change into Unattended mode.

More detail please refer to

 

http://msdn.microsoft.com/en-us/library/aa908497.aspx

All, Just for completeness, for JEDI based products use ... [HKEY_LOCAL_MACHINE\Comm\JEDI10_1\PARMS\Tcpip] "ConnectDampingInterval"=dword:00000005 IJ

To be honest I can't remember, it may have come directly from Microsoft as they were involved at the time. The thing is it is only speeding up TCPIP activity which implies that the wireless is not that slow to power up, connect, authenticate etc, but that there is a lag before it starts TCP comms. Which didn't quite correlate with what we were seeing ... but hey ho it works!! IJ

What about unattended mode instead of full suspend? Battery consumption will be higher but the WLAN radio will not shut off when the power button is pressed.

Well, we somehow sorted this out changing suspend timeout "inside" wifi application, so if wifi is on, timeout is disabled and if wifi is off, timeout is set back to 3 minutes. Tell me if this fits you.

Harry, I had similar problems with a customer using MC9090s running WM5 a few years ago. The issue was as you described, the terminal would go into suspend and then when powered up it would take on average 18 seconds for the radio to be completely ready (powered up, connected, authenticated, IP Address received). Sometimes it could be as long as 24 seconds. Unfortunately their application was set to only wait 15 seconds before refreshing the webpage, then there was a 30 second timeout before it tried again ... i.e. a horrible experience for the end user who had to wait 45 seconds everytime the terminal switched on. The customer didn't want to change the wait period, as they would have had to push it out to 25 seconds to be sure that they avoided any extra long power on times. In the end we managed to find the following reg setting; [HKEY_LOCAL_MACHINE\Comm\PCCARD\PHOTON1\PARMS\Tcpip] "ConnectDampingInterval"=dword:00000005 [HKEY_LOCAL_MACHINE\Comm\PHOTON1\PARMS\Tcpip] "ConnectDampingInterval"=dword:00000005 To this day I still can't figure out how or why it made any difference, but as soon as this reg file was applied the average power-on time dropped from 18 seconds to 12 seconds, with a max and min of 14 and 9 respectively, i.e. within their 15 second requirement every time. As I said this was on WM5 not WM6, it is supported by Microsoft but I'm not sure whether it is recommended or not, and it was not on a JEDI radio .... But it never caused us problems, consistently improved performance by 5-6 seconds and it made the customer very happy and got them off my back ... in my book that spells "Worth a shot"!!! IJ

Ian, where did you get this info from? I searched ConnectDampingInterval and default value is 10, so setting it to 5 theoreticaly speeds this up in 5 seconds. And that's what it is doing. Look at: http://msdn.microsoft.com/en-us/library/ms892490.aspx I can't believe, after all those years!!

Anandakumar, Thanks for your guidance on this issue. It was a great help. One thing I'd like to point out though for the team. I was at the customers site running though these changes and found the following. - Updating the RFS6000 (AP300's dual radio with internal Ant) to 4.3.2.0-012R DID NOT make any difference to the throughput of the MC55's (WM6.1) - We needed to Disable APSD with your suggested Reg setting for this to work. - Also noticed that MC55's with WM 6.5 have APSD Disabled by default. (So no change is needed if anyone is deploying 6.5. On a side note, we've noticed that when the device goes into suspend mode it takes about 12-15 secs to re-establish WiFi connection when woken up. In comparrison other competitor devices (Intermec/Datalogic) they take about 5-8 secs. Customer has made it clear this is a concern to them. (Especially when our Photon Devices aka MC50 were about 8 secs as well). Anyone know if there is a reg change to make this "wake up" faster on our Jedi radio's? Thanks Regards Harry

I have been trying to speed up Fusion for almost 4 years, first on MC70 then on MC75, for Spanish Post (SPRs, GRIPs, etc). No way from the Fusion Public APIs side. Main problem is when actually powering the card. It takes a long time. Associating and authenticating is not the big issue. Then I once had some promising path to follow regarding some undocumented feature... But this eventually lead to nowhere. At Spanish Post's last RFP, MC75s took from 15 to 20 seconds to successfully get into the network (PEAP ms-chapv2 WPA/TkIP-Enterprise). CN3s did in 8 seconds. Then again, winner was MC75. Hopefully it will be on next RFP too. For this currrent RFP, Spanish Post also tested MC65. Connection times were also about 20 seconds. This is a log (my application's, not Fusion's) taken from one MC65: 16-12-2010;08:07:29;1;Enabling WIFI... 16-12-2010;08:07:29;1;Deleting Profiles... 16-12-2010;08:07:29;1;Profiles deleted, creating one... 16-12-2010;08:07:29;1;Profile created. 16-12-2010;08:07:29;1;Enabling adapter... 16-12-2010;08:07:39;1;Adapter enabled in (s) =(9)(0x9) 16-12-2010;08:07:39;1;Timeout set to (s) =(30)(0x1E) 16-12-2010;08:07:39;1;Start connection... 16-12-2010;08:07:49;1;All OK:  Fusion API Operation Success 16-12-2010;08:07:49;1;Associated in (s) =(10)(0xA) 16-12-2010;08:07:49;1;Signal Quality=(5)(0x5) 16-12-2010;08:07:49;1;Signal Strength=(-45)(0xFFFFFFD3) 16-12-2010;08:07:49;1;BSSID AP: 00:15:70:E0:07:C0 16-12-2010;08:07:50;1;IP  10.154.99.96 16-12-2010;08:07:50;1;Mask  255.255.255.128 16-12-2010;08:07:50;1;GW  10.154.99.10 16-12-2010;08:07:50;1;DHCP  10.154.99.11 16-12-2010;08:07:50;1;Active IP  10.154.99.96 16-12-2010;08:07:50;1;IP Time (s) =(0)(0x0) 16-12-2010;08:07:50;1;Total connection Time (s) =(20)(0x14) 16-12-2010;08:07:50;1;**--> Return Code =(0)(0x0) So it takes 9 seconds to power up and 10 to authenticate (to a remote radius server). I obviously then suppose that bottleneck is on fusion rather than on actual hardware (jedi, photon, proton, Higg's bosom whatsoever). My sincere recommendation is to make your customer think of all the real goodies about MC terminals and then let them forget about those sluggish connection times. By the way, what about WZC timings? I never tried them.

Thank for your honesty and recommendations. Issue we have is that the application is a Mobile POS one where it is directly customer interfacing. Hence when a customer says they want certain items the store staff bring up an order form and begin to scan/place items on it. Hence the delay (15 secs or so) is a long time when a customer is in front of you. Then if the device goes into suspend mode, customer needs to wait again. Only "sort of" solution is to have the suspend mode for 5+ mins but this doesn't help with battery life.  Send me an email if you find anything that helps minimise this time delay.

Anandakumar, As Chin mentioned - that's fantastic. Also do you know if there is any battery performance issues when making this change?   (FYI for the EWLAN team - There is nothing stated in the RFS6K 4.3.2 release notes about this also being a fix for the AP300's). We are happy to try both changes. 1. Upgrade the RFS6K 2. Make this reg change REgards Harry

Harry, battery performance should not change significantly due to this change. A solution for this problem was supposed to be part of Firmware version 4.3.2. I will check that and let you know.  If the firmware in switch is not updated, registry change can be used as a work around in the client.  Updating the firmware in the switch and not changing the registry key value in the client(i.e. APSD enabled) will have better performance than using the work around in the client.

Similar issue was reported on MC75 some time back. The problem occured when APSD was enabled in the client and AP300 was used at the infrastructure side. This issue was fixed in AP300. If you are using AP300, you have to upgrade the firmware to version 4.3.2 for a permanent solution.  If a work around is needed, you can disable APSD in the client using the following registry key value [HKEY_LOCAL_MACHINE\Comm\JEDI10_1\Parms] ;To enable WMM-UAPSD set APSDConfiguration = dword:000000FF "APSDConfiguration"=dword:00000000

Thanks Anandakumar, the reg resolved the issue.