SX20 Touchpad loses connection to codec

[jcromwell]

Hi all and thanks for looking.

We have a SX20 deployed with the touchpad connected to the same VLAN, but it's constantly losing connection to the codec.  We have to reboot the touchpanel and repair it to the codec everytime.  Is there a setting/config that we are missing?  Both the SX20 and the touchpanel have static IP's on the same VLAN.

Thanks in advance for any insight!

[Danny De Ridder]

Hello,

could you attach the current logfile bundle of your SX20?

http:///wsgi/logs/bundle/current

There's a file in that bundle named touchdevice.log which could hopefully give some clues.

[jcromwell]

Thanks, logfile is now attached.

[Danny De Ridder]

To me it looks as if the code on the touch is crashing and restarting.

I see :

Feb  8 17:23:36 localhost --: MARK --

Feb  8 17:43:36 localhost --: MARK --

Feb  8 18:03:36 localhost --: MARK --

Feb  8 18:23:36 localhost --: MARK --

Feb  8 18:24:18 localhost kernel: touch: reset (2, 7, 1): 0 0 0 0 0 13 22 136 105 21 13 20 0 0 0 : 0 19 27 40 50 76 148 66 55 51 47 40 36 31 26 21 21 14 11 0 0 0 0 0 0 0 0

Feb  8 18:24:18 localhost kernel: touch: reset (2, 8, 1): 0 0 0 0 0 0 19 139 103 18 10 0 0 0 0 : 0 12 25 36 47 83 147 59 50 48 45 41 35 31 27 23 19 16 12 0 0 0 0 0 0 0 0

Feb  8 18:24:56 localhost kernel: touch: reset (1, 4, 1): 0 0 0 0 0 0 0 0 10 14 88 27 0 0 0 : 0 0 0 0 11 14 19 23 27 31 33 37 40 45 60 115 44 34 29 20 14 0 0 0 0 0 0

Feb  8 18:24:56 localhost kernel: touch: reset (1, 4, 1): 0 0 0 0 0 0 0 0 0 12 84 38 0 0 0 : 0 0 0 0 10 14 18 22 28 30 35 36 40 44 61 116 46 32 29 19 14 0 0 0 0 0 0

Feb  8 18:24:56 localhost kernel: touch: reset (1, 6, 1): 0 0 0 0 0 0 0 0 0 13 86 40 0 0 0 : 0 0 0 0 12 15 21 25 30 34 39 42 47 49 68 122 52 38 33 23 15 0 0 0 0 0 0

Feb  8 18:24:56 localhost kernel: touch: reset (1, 6, 1): 0 0 0 0 0 0 0 0 0 14 86 40 0 0 0 : 0 0 0 0 10 14 21 24 30 36 39 43 47 51 72 125 52 40 33 23 18 0 0 0 0 0 0

Feb  8 18:24:56 localhost kernel: touch: reset (1, 5, 1): 0 0 0 0 0 0 0 0 0 10 81 36 0 0 0 : 0 0 0 0 0 14 19 23 27 33 35 37 41 43 64 118 45 36 28 20 19 0 0 0 0 0 0

Feb  8 18:24:57 localhost kernel: touch: reset (1, 1, 3): 0 0 0 0 0 0 0 0 0 0 15 79 17 0 0 : 0 0 0 0 0 10 10 13 11 0 11 0 0 0 15 53 0 0 0 0 0 0 0 0 0 0 0

Feb  8 18:24:59 localhost kernel: touch: reset (2, 4, 1): 0 0 0 0 0 0 0 0 33 68 0 32 74 10 0 : 0 0 0 0 0 0 0 0 0 12 13 16 18 80 44 23 78 60 12 0 0 0 0 0 0 0 0

Jan  1 00:00:07 localhost kernel: CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

Jan  1 00:00:07 localhost kernel: Machine: OMAP3 Endeavour Board

The MARK messages are good. These are some keepalive of some sort. However, the kernel messages following are not that good I think.

Feb  8 18:24:18 localhost kernel: touch: reset (2, 7, 1): 0 0 0 0 0 13  22 136 105 21 13 20 0 0 0 : 0 19 27 40 50 76 148 66 55 51 47 40 36 31 26  21 21 14 11 0 0 0 0 0 0 0 0

And then the touch/kernel restarts.

Jan  1 00:00:07 localhost kernel: Machine: OMAP3 Endeavour Board

Let me run this by engineering.

[jcromwell]

As for dates, we've installed this codec about 1 or 2 months ago.  So for dates, I would focus on anything happening since July or August.

Thanks again for your help!

[Danny De Ridder]

Hello,

the latest timestamp in the touchdevice logs is :

Feb  8 21:37:12 localhost --: MARK --

Feb  8 21:57:13 localhost --: MARK --

Feb  8 22:17:13 localhost --: MARK --

Feb  8 22:37:13 localhost --: MARK --

Feb  8 22:57:13 localhost --: MARK --

So the timestamp in those logs does not really match with current date...

[Danny De Ridder]

Can you also check your ntp server settings?

You are using tick.hersheys.com

Is that ntp server reachable ?

[dderidde-ex90-home:/var/log] $ ping  tick.hersheys.com

ping: unknown host tick.hersheys.com

[dderidde-ex90-home:/var/log] $

Can you check ntp via root access to the codec ?

[dderidde-ex90-home:/var/log] $ ntpservers

pool.ntp.org

[dderidde-ex90-home:/var/log] $ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

LOCAL(0)        .LOCL.          10 l   5h   16    0    0.000    0.000   0.000

*vcxen01.bw.phl. 128.118.25.5     2 u  345  512  377  118.683    0.042   1.742

[dderidde-ex90-home:/var/log] $

[Danny De Ridder]

Hello,

the log messages "localhost kernel: touch: reset" are printed when there are "phantom" touch events detected, e.g. when I press 2 different areas of the touch using 2 fingers, the message gets generated. Explanation from engineering on this is :

"The kernel log you point to shows that the touch controllers are reset due to more than one finger touch (or noise, or whatever)." Now noise can be EMC. There's a Administrator setting to configure EMC resilience. See snapshot of the config on the touch. In any case, we have no evidence that these message are the cause of the touch losing contact with the codec, but it would not hurt to try the EMC resilience mode to verify whether the kernel touch messages disappear.

[jcromwell]

I checked the touch... EMC resiliance mode was already set to 'ON.'  Should we set it to 'OFF' to see what that does?

Thanks.

[Danny De Ridder]

Changing the setting to off would increase the sensitivity even more, so I would think more "phantom" touches would be noticed. I found a ddts with regards to the error messages you see in the logs. CSCub15405 - Touch Panel erratic -behavior caused by electrical interference. These events should not result in touch losing its pairing. Did you have chance to look at the NTP server which the codec points to?

[Danny De Ridder]

We recently discovered an issue where a touchpanel can act as you described.

"Every morning we come in at 7AM and the touchpad is blank/non-responsive. 
We power cycle it, the touchpad  reboots and resumes being paired to the codec.

The setting on the codec which might cause such behaviour is :

*c xConfiguration Security Session InactivityTimeout: 10

If the session InactivityTimeout is set to a value other than the default value of 0 the touch might turn dark and seems to be unresponsive. Could you please check this value on your codec. If set to any other value than 0, please set it to 0 and reboot the codec.

If the current value is 0, the issue lies elsewhere.

[Marius Nedregaard]

How often do you see this issue? Do you have an SR# for us to share?

Sent from Cisco Technical Support iPhone App