IX5000 Touch 10故障排除

簡介

本文描述現場觀察到的不同場景，以及進行故障排除、隔離和收集資訊以解決問題的步驟。

IX5000是新一代思科網真沈浸式終端，它使用Touch 10而不是CTS和TX沈浸式系統使用的Touch 12。它使用與TC終端不同的使用者介面(UI)軟體；但是，它使用相同的Android基礎。

常見問題

即使整個系統成功啟動，觸控面板也不會開啟/啟動

觸控式螢幕成功啟動後，將顯示預設螢幕，如下圖所示。

1. 檢查乙太網電纜是否已連線到交換機埠並且交換機已通電。您開啟Touch 10的唯一方式是通過乙太網供電(PoE)。
2. 重新拔插乙太網電纜。嘗試使用另一根已知工作正常的乙太網電纜。
3. 嘗試交換機上的另一個乙太網埠。如果已經執行基本步驟，但Touch 10裝置仍顯示空白螢幕，或仍然處於維護模式，則可能是因為表中的交換機沒有從編解碼器接收其配置，從而導致Touch 10裝置沒有從交換機接收PoE。此情況需要您按以下步驟將交換器重設為出廠預設值並重新啟動編解碼器。 
   1. 按住Mode按鈕11秒。

      附註：Mode按鈕位於交換機的正面和底面，與電源插頭位於同一側。交換機LED在三秒後開始閃爍，七秒後停止閃爍。然後，交換器會重新啟動且遺失其組態。

   2. 要重新啟動編解碼器，請登入到IX5000管理圖形使用者介面(GUI)，然後按一下重新啟動/重置。GUI的預設IP地址為169.254.1.1，預設使用者名稱和密碼為admin/cisco。如果已配置編解碼器，則IP地址會有所不同。交換機將重新恢復其配置，Touch 10裝置成功初始化。

全新觸控無法升級 — 停滯在[維護模式]

所有全新的Touch都隨附出廠安裝的軟體包，這意味著基於TC的系統在連線到任何IX系統時需要立即升級到IX軟體包。因此，如果升級失敗，並且該UI掛起，顯示消息「maintenance mode...下載軟體」，面板永遠不會升級到IX系統使用的軟體。IX軟體不會顯示「維護模式」文本，而是顯示「下載/解壓縮/安裝」。 為了嘗試恢復面板，請重新啟動或重新啟動軟體。如果這不能解決問題，請使用出廠重置IX8.1.1代碼，該代碼與TC終端使用的代碼相同。較低版本使用不同的方法。

另一個故障排除選項，如果您擁有基於MX/SX的終端軟體TC7.1或更高版本，則可以重新連線Touch以獲取TC軟體，然後可以重新連線到IX。由於這有助於Touch恢復預設軟體，因此，當您將IX軟體連線到IX時，IX軟體可能會被再次覆蓋。

連線丟失 — UI中顯示[連線丟失]

與IX5000的連線丟失通常在UI中顯示為連線丟失。如果心跳丟失到IX5000,IX軟體會顯示此消息。心跳是每15秒向IX傳送的命令/響應。如果兩個心跳丟失（30秒後無響應），Touch單元將無法通過UI操作，因為命令不會傳遞到IX，也不會從IX檢索狀態更新 — 因此將顯示消息。此外，啟動Touch後，如果永遠無法與IX建立連線/配對，則會顯示消息。Touch將繼續嘗試建立與IX的連線，以便達到正常的可操作狀態。當再次建立連線時，消息將消失。

出現「Lost of Connection（失去連線）」資訊時，很少出現觸控裝置的問題，必須執行IX和連線觸控面板的表格開關的故障排除以解決問題。

如果房間裡的所有觸控者突然都收到了此資訊，但IX似乎工作正常，則案頭開關極有可能出現問題。在提取日志捆綁包時找到/nv/log/touch/資料夾的日誌。

日誌中的心跳示例

LOG_NOTICE(169.254.1.102):06-08 12:16:28.683 WARN com.cisco.telepresence.system.SystemService Tag:SocketThread #codec send:xcommand外圍裝置心跳ID:"88:43:E1:C6:54:51"超時："30" | resultId="18093" LOG_NOTICE(169.254.1.101):06-08 12:16:34.785 WARN com.cisco.telepresence.system.SystemService Tag:SocketThread #codec send:xcommand外圍裝置心跳ID:「88:43:E1:C6:52:8E」超時："30" | resultId="18476" LOG_NOTICE(169.254.1.102):06-08 12:16:43.718 WARN com.cisco.telepresence.system.SystemService Tag:SocketThread #codec send:xcommand外圍裝置心跳ID:「88:43:E1:C6:54:51」超時："30" | resultId="18094"

Android崩潰 — 例如[Phone App Has Stopped]

每當在進程/應用中引發未處理的Java異常時，通常通過帶有確認按鈕的標準消息{the_app has stopped}即可看到此異常。這並不一定妨礙系統的正常使用，並且可能沒有任何後遺症。然而，它們絕不能發生。

為了調試為什麼會發生此類故障，logcat將輸出回溯，只要在重現故障後儘快檢索日誌。可以拋出多種不同型別的異常，因此最好在日誌中搜尋FATAL或Exception。請記住，需要對IX上的每個檔案進行調查，才能找到崩潰。擷取日誌套件組合時，這些檔案位於/nv/log/touch/資料夾中。

以下範例顯示儀表板應用崩潰，並顯示UI中的「儀表板已停止」消息：

2015-07-08 02:21:32.467 - FATAL EXCEPTION: main
2015-07-08 02:21:32.467 - Process: com.cisco.telepresence.dashboard, PID: 6825
2015-07-08 02:21:32.467 - java.lang.NullPointerException
2015-07-08 02:21:32.467 - at com.cisco.telepresence.dashboard.adapter.
MediaChannelListAdapter.
     
     
       (MediaChannelListAdapter.java:37) 2015-07-08 02:21:32.467 - at com.cisco.telepresence.dashboard.fragment. 
     
MediaChannelListFragment.configureAdapter(MediaChannelListFragment.java:76)
2015-07-08 02:21:32.467 - at com.cisco.telepresence.dashboard.fragment.
MediaChannelListFragment.onViewCreated(MediaChannelListFragment.java:30)
2015-07-08 02:21:32.467 - at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:904)
2015-07-08 02:21:32.467 - at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:1062)
2015-07-08 02:21:32.467 - at android.app.BackStackRecord.run(BackStackRecord.java:684)
2015-07-08 02:21:32.467 - at android.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1447)
2015-07-08 02:21:32.467 - at android.app.Fragment.performStart(Fragment.java:1721)
2015-07-08 02:21:32.467 - at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:918)
2015-07-08 02:21:32.467 - at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:1062)
2015-07-08 02:21:32.467 - at android.app.BackStackRecord.run(BackStackRecord.java:684)
2015-07-08 02:21:32.467 - at android.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1447)
2015-07-08 02:21:32.467 - at android.app.FragmentManagerImpl$1.run(FragmentManager.java:443)
2015-07-08 02:21:32.467 - at android.os.Handler.handleCallback(Handler.java:733)
2015-07-08 02:21:32.467 - at android.os.Handler.dispatchMessage(Handler.java:95)
2015-07-08 02:21:32.467 - at android.os.Looper.loop(Looper.java:136)
2015-07-08 02:21:32.467 - at android.app.ActivityThread.main(ActivityThread.java:5076)
2015-07-08 02:21:32.467 - at java.lang.reflect.Method.invokeNative(Native Method)
2015-07-08 02:21:32.467 - at java.lang.reflect.Method.invoke(Method.java:515)
2015-07-08 02:21:32.467 - at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
2015-07-08 02:21:32.467 - at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
2015-07-08 02:21:32.467 - at dalvik.system.NativeStart.main(Native Method)
2015-07-08 02:21:33.059 - LOG_NOTICE(169.254.1.8) :07-08 12:21:24.907 WARN 

UI狀態不一致

如果UI沒有反映系統的正確狀態，例如，（返回呼叫）條在呼叫外部可見，或者（返回呼叫）條在呼叫中不可見，這可能是由IX中的狀態更新不完整造成的。例如，如果呼叫突然中斷，則IX中斷、介質問題等。

如果狀態持續出現，則重新啟動或出廠重置Touch可以解決問題。

通過串列連線從Touch10獲取日誌

直接從有問題的Touch本身提取日誌是非常有益的，特別是在出現啟動/連線丟失/Touch軟體升級問題的情況下，因為沒有任何日誌可能會被傳輸到IX。可以從Touch提取日誌，將微型USB電纜連線到Touch背面（用於為基於Android的普通手機充電的電纜）和電腦。使用以下設定開啟串列終端：

波特率：115200 

Data/par/stop:8n1

外殼可用。在此外殼中輸入logcat以輸出完整的日誌。輸入bugreport以輸出日誌和其他硬體/網路資訊。必須從終端複製到檔案或儲存。日誌在引導後無法存活，因此在執行引導以進行恢復之前捕獲日誌非常重要。

復原程式

如果確定觸控式螢幕有問題，請完成退貨授權(RMA)。 嘗試在完成RMA之前恢復面板。

• 按照串列連線的說明，直接從「觸控」面板收集日誌。
• 通過重新通電重新引導Touch（重新連線Touch背面的網路電纜）。
• 按照本文檔所述執行觸控的出廠重置。
• 如果您有一個基於MX/SX的系統運行軟體版本TC7.1或更高版本，則可以連線Touch以恢復出廠包。這是通過重新同步而不是HTTP傳輸的，這可能是使觸控處於可操作狀態的最後手段。恢復後，將其連線回IX5000。

運行IX代碼的出廠重置觸控10

1. 從Touch10背面拔下電源/網路電纜。
2. 按住「Volume up（音量）」硬鍵並更換電源/網路電纜。
3. 等待靜音硬按鍵亮起（紅色） — 約10秒。
4. 放開「Volume up（調高音量）」按鈕，然後按一下「Mute hard（靜音）」按鈕。在步驟4之後，當「Mute（靜音）」按鈕上出現綠色閃爍確認時，已成功執行出廠重置。

運行TC/CE代碼的出廠重置觸控10

1. 按住靜音按鈕大約10秒，直到開始閃爍紅色為止。
2. 按兩次「Volume down（音量降低）」按鈕。
3. 靜音按鈕將變為常亮紅色並以出廠預設設定重新啟動