Siemens Simpad support?

acheslow · Post by **acheslow** » Sun Feb 08, 2004 1:23 pm

I just picked up a Simpad on eBay. These have a SVGA touchscreen and I believe can run either Win CE 3.0 or CE.net 4.1. Has anyone successfully used one of these as a SW remote with HouseBot?

Thanks,

Alan

acheslow · Post by **acheslow** » Tue Feb 10, 2004 4:10 pm

Ok then can anyone tell if it should work? I don't have any experience with PPC devices and am not sure of the differences between CE, HPC, and PPC. I do know that the NetRemote folks were able to get the Simpad working but it requires some work-arounds.

This article describes how to run PPC programs on the Simpad. I know I could just wait until my Simpad arrives and try it out then but I'd like to spend the time doing some initial planning and configuration. If it works on HouseBot then I'll spend some time getting everything else setup, otherwise I'll spend the time on NetRemote.

Thanks,

Alan

Post by **ScottBot** » Tue Feb 10, 2004 8:45 pm

Alan,

I think it should work, but I've never tried it myself. I used to have an XPilot, which was an OEM version a device ViewSonic used to sell. I was able to get the HPC 2000 version of the SW Remote to run without a problem. I remember that there were issues with the video display management (screen blanking), but everything work ok.

I'm interested to hear how it works for you.

acheslow · Post by **acheslow** » Wed Feb 11, 2004 10:29 am

Thanks Scott - that's good enough for me. I've started configuring the system and will let you know how it works once the Simpad is delivered. By the way, I've noticed some nice improvements with HouseBot since I played with it a couple of versions ago. Nice work, especially all the documentation and samples.

Thanks,

Alan

Post by **ScottBot** » Wed Feb 11, 2004 11:33 am

acheslow wrote:By the way, I've noticed some nice improvements with HouseBot since I played with it a couple of versions ago.

I hope to release a beta of version 2.0 next week. So you can check out even more improvements (I hope).

acheslow · Post by **acheslow** » Wed Feb 25, 2004 11:15 am

OK I got my Simpad yesterday and it was loaded with CE.Net 4.10. I tried each of the software remotes and none of them worked. Then I loaded the fakedlls files into the windows directory to make the system pretend to be a PPC. After that the PPC version of SWRemote ran pretty much perfectly. I am having some connectivity issues but I think that is mostly due to my Wifi setup. However, sometimes the remote seems to just stop responding for a period of time and I notice that the server reports the client to be in the state "Sleeping" even when it's not. Sometimes all I can do to get the client back "In session" is to restart or wait for a long time. Sometimes it seems to go back "in session" by itself for no apparent reason. Often I will open a panel on the client and some of the controls never get updated because the server shows that it is sleeping. For instance, it will draw a list box but not display the contents of the list -- and sometimes after a few minutes the contents will appear. I don't think these problems are related to my Wifi setup because the server always shows the client connected, just usually in a sleeping state. Any ideas how I can fix this?

Thanks, Alan

Post by **ScottBot** » Wed Feb 25, 2004 11:42 am

Alan,

If the server shows the client/SWRemote as Sleeping, it is because the server has lost connection with the client. It can lose the connection if:

Someone turns off the device
A standby Theme button is pressed
Bad network connection.

The server will poll the client every minute or so to see if it is still alive. If it doesn't get a response, it puts the client to sleep. It will continue to poll the client once a minute to see if it is awake again, but only once a minute.

If the client initiates an action to the server (pressing a button or something), the server will realize the client is awake and reset it's state.

When a client is sleeping, the server will not send it any notifications (property changes, etc.). This is probably why your list is not getting updated.

I think the problem is likely due to your network. What kind of signal strength are you seeing at the client?

acheslow · Post by **acheslow** » Wed Feb 25, 2004 12:21 pm

The connection is listed as 'excellent' with a SNR between 25-35 however based on your response and my experience with the web browser I do think the problem is network related and not a HouseBot problem. Hopefully I can find and fix the problem with my Wifi connection.

Thanks, Alan

yaccri · Post by **yaccri** » Wed Feb 25, 2004 3:06 pm

I have a similar problem with a pocket PC. I know it is NOT a housebot problem because it also hangs when I browse with the PocketPC on another PC through the WiFi network.

I believe that something is wrong with the WiFi settings, but I can't tell what.

If you find a solution that works for you, please post it.

Thanks,

Yoram.

acheslow · Post by **acheslow** » Wed Feb 25, 2004 3:19 pm

OK I'm pretty happy now. I did some more research on Google and found this post that referred to a newer driver for my card. The link in the post didn't work for me, I had to go through the site to this page.

My Wifi connection is damn near perfect now and HB works much better. The only problem I have now is with the client going to 'sleep' after the screen blanks. I guess this is by design but when it wakes up it doesn't immediately reconnect to the server; I have to manually go to a new panel first. Here is what I've seen:

After 15 seconds my screen blanks (set in client configuration)
After another 1 minute the server shows the client in the 'sleeping' state
After another 15 seconds the client disappears from the server's software remote list
After I touch the screen or a button to bring the screen out of blank mode the client is still there but not updated
After I select a panel change button the server shows the client as 'initializing'
After just a couple of seconds the server shows the client as 'in session' again and the remote refreshes

As I mentioned I guess this is by design but I would much prefer for the client to continue receiving updates even when the screen is blank. I believe the Wifi card is still on so its not saving any power is it?

Thanks, Alan

Post by **ScottBot** » Wed Feb 25, 2004 3:33 pm

Alan,

When the screen blanks on the client, it shouldn't show as 'sleeping' at the server and it should not disappear from its SW Remote list. The idea is for the screen to blank and have the network still active. The server continues to communicate with the client even if the screen is blank. This saves a lot of time when the screen un-blanks as the client does not have to re-connect to the server.

Only if the client goes into 'standby' will it show as sleeping. It will enter standby if someone presses a Theme 'Standby' button, or if the battery % is below the value set in the client config. I doubt that either of these two things are happening to you. However, what you are describing sounds like the client lost its connection with the server for some reason.

In your client configuration, enable tracing. This will generate a trace file on the client that may have some useful info.

You may also want to enable tracing at the server. You can do this by checking the 'Server Socket' in the Tracing Profiles.

Also, if you wifi card has an LED on it, does it continue to blink when the client screen is blank?

acheslow · Post by **acheslow** » Wed Feb 25, 2004 3:49 pm

Scott, here's the trace file from my client. The time it took to sleep and then disappear was much less this time. The Wifi card's traffic light was blinking the whole time.

Code: Select all

8/1/2002 13:18 - Last Heart Beat At 

8/1/2002 13:18 - BATTERY IDLE TIMEOUT = 300

8/1/2002 13:18 - OEM INFO = Siemens Switzerland AG

8/1/2002 13:18 - PLATFORM TYPE = Jupiter

8/1/2002 13:18 - WAKEUP IDLE TIMEOUT = 60

8/1/2002 13:18 - Attempting to connect to the server

8/1/2002 13:18 - Client is attempting to connect to the server

8/1/2002 13:18 - Battery Percentage = 20, Sleep Timeout = 15

8/1/2002 13:18 - Logging in to Server

8/1/2002 13:18 - Connected to the server

8/1/2002 13:18 - Login Successful.

8/1/2002 13:18 - Checking Theme file for updates...

8/1/2002 13:18 - Loading Config File

8/1/2002 13:18 - Checking Theme file dependencies for updates...

8/1/2002 13:18 - Loading Theme

8/1/2002 13:18 - Initializing Panel [Main Menu]

8/1/2002 13:18 - Initializing Panel [A/V]

8/1/2002 13:18 - Initializing Panel [Lights]

8/1/2002 13:18 - Initializing Panel [Caller ID]

8/1/2002 13:18 - Initializing Panel [Weather]

8/1/2002 13:18 - Initializing Panel [Radar]

8/1/2002 13:18 - Initializing Panel [Satellite]

8/1/2002 13:18 - Initializing Panel [Den]

8/1/2002 13:18 - Initializing Panel [News]

8/1/2002 13:18 - Video Power Management is NOT supported

8/1/2002 13:18 - Activating Skin [Caller ID]

8/1/2002 13:18 - Activating Skin [Main Menu]

8/1/2002 13:19 - Display is now OFF

8/1/2002 13:19 - Video Power Management is NOT supported

8/1/2002 13:19 - Activity received while blanking window is up.  Blanking window up at 1028222348.  Now is 1028222366

8/1/2002 13:19 - Video Power Management is NOT supported

8/1/2002 13:19 - Display is now ON

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - send() failed: error 

8/1/2002 13:19 - Client determined server has disconnected because recv() returned -1

8/1/2002 13:19 - The Server has Disconnected.

8/1/2002 13:19 - Activating Skin [Caller ID]

8/1/2002 13:19 - Attempting to connect to the server

8/1/2002 13:19 - Client is attempting to connect to the server

8/1/2002 13:19 - Logging in to Server

8/1/2002 13:19 - Connected to the server

8/1/2002 13:19 - Login Successful.

8/1/2002 13:19 - The Client is closing and disconnecting from the server.

8/1/2002 13:19 - IP Client Thread has terminated

8/1/2002 13:19 - Client determined server has disconnected because recv() returned 0

acheslow · Post by **acheslow** » Wed Feb 25, 2004 3:56 pm

Those 'video power management' lines got me thinking. I switched the power management setting on my Wifi card from Off to On and now the client is staying 'in session' while the screen is off. This setting had the exact opposite effect that I had expected but now it is working perfectly.

THIS IS AWESOME!!

Thanks! Alan

acheslow · Post by **acheslow** » Mon Mar 08, 2004 9:43 am

Scott, after some more usage and experimentation I've found some more disconnect problems. For instance, here is a typical scenario:

Last night I started up SWRemote at 11:30pm and left it on a screen that shows the current time. When I woke up this morning the screen showed the time stopped at 12:43am. The last lines in the TraceLog were "3/7/2004 23:29 - Video Power Management is NOT supported; 3/7/2004 23:35 - Battery Percentage = 100, Line Status = 1". I was running on AC power and my SWRemote settings were "Seconds before screen is blanked=-1; % of battery device will switch to standby=5". If I do a 'netstat -n' it shows a TCP connection from port 35335 on the Simpad to port 37139 on my HouseBot server in the ESTAB state. The HouseBot server shows no software remotes connected. When I exit the SWRemote the final lines in TraceLog are "The Client is closing and disconnecting from the server; IP Client Thread has terminated; Client determined server has disconnected because recv() returned -1; send() failed: error; send() failed: error"

It seems this type of 'freeze' will typically happen between a few minutes and an hour after my last button press. If I toggle back between two panels a couple of times it will normally reconnect.

Can you tell if this type of behavior is typical or if there might be something wrong? Is there any way to provide an option for a more aggresive 'keep-alive'? If I can manually reconnect the client to the server by pressing a few buttons can this be automated somehow so that the client tries to reconnect to the server by itself?

Thanks,

Alan

Post by **ScottBot** » Mon Mar 08, 2004 10:18 am

acheslow wrote:Can you tell if this type of behavior is typical or if there might be something wrong?

I've been running two software remotes at my house for about three years and I've never seen the behavior you are seeing. I've also not heard of this from others, so I don't think it's typical. It truly sounds like a networking issue. Maybe it's just a glitch, or some network card power management feature gone wild, but from what you've described it sounds like the client just loses its network connection to the server.

Is there any way to provide an option for a more aggresive 'keep-alive'? If I can manually reconnect the client to the server by pressing a few buttons can this be automated somehow so that the client tries to reconnect to the server by itself?

There really isn't any 'keep-alive' logic now. The server will 'ping' the client to make sure it's still alive, but it won't attempt to revive it (not that it could). The client will connect to the server if it needs to, but it's not proactive in keeping the connection option.

I assume that the message "The Client is closing and disconnecting from the server" that you see is after the problem time and more likely just the result of you exiting the SW Remote. If you are seeing this message during operation (not at the time you are closing the SW Remote), then let me know as this is a problem.

Do you see any "The Server has Disconnected" or "Client Wakeup is causing a reconnection" messages in the log? The client will attempt to re-connect to the server if it knows it has been disconnected, but will not, otherwise, try and establish an automatic connection to the server. Also, is this 100% reproducible (does it happen every night?)? Are there any other commonalities that you have noticed, like does it happen only when the screen is blanked?

I could implement some kind of keep-alive logic, but my concern is that it would be a band-aid over whatever the real issue is and my not resove it properly.