Seamless Connectivity for a WinCE 4.2 .NET device

arsham11 · 07-17-2005

Here is the problem, we have a handheld device used as a home control device with an integrated 802.11 module. Every time the device goes into suspend mode and resumed, for about 15~30s there is a complete blackout period where the device is going through the authentication and ... process. This is considered an issue since this device is used in home connectivity and the end user expects results right away.

Does any one know of a solution where the driver is actually saved as the OS state image before the suspend, so that when the device is resumed it can start working with no delay? I have been looking for a workaround for a while, this would be the last try before we are forced to consider a Non-802.11 RF solution!

Thank you in advance for your comments,

Thorn · 07-17-2005

What's the device's OS, the authenication, band (b/g/a), etc.?

Some devices just take that long to wake up, and you might be better off with something turning of Power Saving/Suspend. The tradeoff is less battery life, of course.

arsham11 · 07-17-2005

The OS is built specifically for us using the WinCE 4.2 .NET platform builder which based on Microsoft's comment and actually seen in the performance tests is capable of resuming the system in less than a second. The module used at this time is an integrated small footprint b sol. We can specify the Auth method for the best end user exp.

Now the problem is unlike other drivers, module's driver is un-loaded before the suspend and has to be initialized after resume. I am not looking for a wake-on-LAN solution, but a way to possibly have the module's state saved as part of the OS image before suspend. This way, the module will think it never went into suspend and will resume work without a need for re-association.

Thorn · 07-17-2005

Quote:

Originally Posted by arsham11

The OS is built specifically for us using the WinCE 4.2 .NET platform builder ... Now the problem is unlike other drivers, module's driver is un-loaded before the suspend and has to be initialized after resume. ...

If you're building the OS, can't you control the load/unloading of the driver? i.e. Tell the OS to specifically keep that driver in memory as it writes the image.

arsham11 · 07-17-2005

Quote:

Originally Posted by Thorn

If you're building the OS, can't you control the load/unloading of the driver? i.e. Tell the OS to specifically keep that driver in memory as it writes the image.

Yes, but that would be of no use if the solution does not support it. In our case the current solution(WiFi module) is driven by the CPU and does not have this capability and can not be initialized based on a saved state.

I guess a better way to ask this question would be: is there an off-the-shelf small-foot-print 802.11 b or g solution which would support this?

In regards to preventing the device from going into suspend mode, that is actually the workaround we have suggested for the time being and since our solution has a fairly good PS mode with sleep intervals of 100ms to 1s we are able to make up for the battery usage to an extent, but that does kill the battery life as you pointed out, and hence we are trying to find a better solution as this just seems to be a H@ck!

Thorn · 07-17-2005

Quote:

Originally Posted by arsham11

I guess a better way to ask this question would be: is there an off-the-shelf small-foot-print 802.11 b or g solution which would support this?

Personally, I don't know of any that fit that requirment. It is probably going to vary widely according to each device/driver. My suggestion would be to start talking to various OEMs' technical sales reps.

arsham11 · 07-17-2005

Quote:

Originally Posted by Thorn

Personally, I don't know of any that fit that requirment. It is probably going to vary widely according to each device/driver. My suggestion would be to start talking to various OEMs' technical sales reps.

Thanks for your input, I was hopping someone here had already faced such a problem and knew of a sol. Based on our research so far this has not been a requirement since this idea is a fairly new implementation of the technology.

Thanks again

c0rnholio · 07-21-2005

Hi,

if the CE.NET device is stationary, then once chance would be to use one of these tiny APs in 'Wireless Bridge' mode. Then you only need an ethernet-nic in your CE device wich is connected to the AP. The AP(Bridge) itself will keep the connection to your main AP. So when you switch on your device, and you use fixed IP-adresses, there should only be a small delay to initialize the ethernet connection.

Just a thought...

Cheers

arsham11 · 07-21-2005

Quote:

Originally Posted by c0rnholio

Hi,

if the CE.NET device is stationary, then once chance would be to use one of these tiny APs in 'Wireless Bridge' mode. Then you only need an ethernet-nic in your CE device wich is connected to the AP. The AP(Bridge) itself will keep the connection to your main AP. So when you switch on your device, and you use fixed IP-adresses, there should only be a small delay to initialize the ethernet connection.

Just a thought...

Cheers

Thanks, but the device is actually a Universal Control End point and WiFi is one of its main sale points!

07-17-2005	#1 (permalink)
arsham11 <-121-> Join Date: Mar 2004 Location: California Posts: 29	Seamless Connectivity for a WinCE 4.2 .NET device Here is the problem, we have a handheld device used as a home control device with an integrated 802.11 module. Every time the device goes into suspend mode and resumed, for about 15~30s there is a complete blackout period where the device is going through the authentication and ... process. This is considered an issue since this device is used in home connectivity and the end user expects results right away. Does any one know of a solution where the driver is actually saved as the OS state image before the suspend, so that when the device is resumed it can start working with no delay? I have been looking for a workaround for a while, this would be the last try before we are forced to consider a Non-802.11 RF solution! Thank you in advance for your comments, __________________ <-arS-121-Ham->

07-17-2005	#2 (permalink)
Thorn Did you do the math? Join Date: Apr 2002 Location: Villa Straylight Posts: 10,008	What's the device's OS, the authenication, band (b/g/a), etc.? Some devices just take that long to wake up, and you might be better off with something turning of Power Saving/Suspend. The tradeoff is less battery life, of course. __________________ Thorn Sex and Violence. You can't enjoy one, if you don't survive the other. (And that works both ways...)

07-17-2005	#3 (permalink)
arsham11 <-121-> Join Date: Mar 2004 Location: California Posts: 29	The OS is built specifically for us using the WinCE 4.2 .NET platform builder which based on Microsoft's comment and actually seen in the performance tests is capable of resuming the system in less than a second. The module used at this time is an integrated small footprint b sol. We can specify the Auth method for the best end user exp. Now the problem is unlike other drivers, module's driver is un-loaded before the suspend and has to be initialized after resume. I am not looking for a wake-on-LAN solution, but a way to possibly have the module's state saved as part of the OS image before suspend. This way, the module will think it never went into suspend and will resume work without a need for re-association. __________________ <-arS-121-Ham-> Last edited by arsham11 : 07-17-2005 at 01:28 PM.

07-21-2005	#8 (permalink)
c0rnholio cd /pub && more beer Join Date: Jun 2002 Location: Germany Posts: 160	Hi, if the CE.NET device is stationary, then once chance would be to use one of these tiny APs in 'Wireless Bridge' mode. Then you only need an ethernet-nic in your CE device wich is connected to the AP. The AP(Bridge) itself will keep the connection to your main AP. So when you switch on your device, and you use fixed IP-adresses, there should only be a small delay to initialize the ethernet connection. Just a thought... Cheers __________________ You mean...there is life outside my lab?

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode