Note: Project Celadon

之前Android-IA For UpBoard/Apollo Lake 提到有Intel 的計畫Android IA, 結果Intel 最近直接把該計畫全砍掉, 改稱 Project Celadon Github account 也看得出來是從Android IA轉移過來, 不過現在有比較清楚的Release Note

看起來就是Intel NUC 為基準平台, 但是從result 看來, 還有不少bugs

廣告

Note: Windows 裝置製造流程

之前任職某公司會有聽到製造端的需求, 需要更快的測試流程安裝流程等等, 甚至提出讓軟體幫它們客製化測試OS, 那時主管來問, 就請它們去看WinPE 但是過了一陣子沒回應, 結果之後提出讓軟體部門幫它們開發專用測試OS, 但是公司產品實際上是小量多樣化的設計, 反應無效後請對方找出使用的Device Driver or Datasheet 然後負責幫它們寫測試工具, 直到這樣才讓高層與工廠認同這樣是不切實際的, 畢竟公司規模不夠大, 供應商根本不可能提供一些它們認為的敏感資料, 或是公司內部有足夠人力資源與時間去完成驅動程式的開發.

不過今天一找, 實際上Microsoft 有針對這個製造流程有一些建議的實作方式,  主要透過Windows ADK/WinPE 等去配合產生安裝用的Image與裝置QC用的測試影像檔.

https://docs.microsoft.com/en-us/windows-hardware/manufacture/index

Note: Android Comms Test Suite的硬體控制模塊

Android Comms Test Suite是一個用來驗證Android Device各種無線互連機能是否能通過一般正常使用的測試架構, 它裡面有使用到一個Monsoon 的Power Monitor, 不過如果是本來做手機平板設計的公司本來就會購置測試用的BatterySimulator 去測功耗, 該裝置一般也是可以透過USB或是LAN遠端操作, 可以寫一個對應的Python 模塊去替換,, 基本上可以參考 monsoon.py這個裝置可以看到是用USB ACM裝置透過Serial port 去下命令的, 但是其他例如基站模擬它們使用Anritsu 的 MD8475A, 然後干擾的信號產生器 MG3710A, 然後配合的衰減器 是aeroflex  跟microcircuits 這兩家到是國內RF常見的設備, 然後上面都是透過socket 控制
還有用FTDI 去做Relay Board, BT Speaker/Headset 等於全套自動化交互測試都靠這些搭建起來

基本上控制用的模組代碼都在下面
https://android.googlesource.com/platform/tools/test/connectivity/+/master/acts/framework/acts/controllers

目前Google自己的TestCase 在 https://source.android.com/devices/tech/connect/connect_tests/google

看了一些TestCase 想到以前做Windows Mobile 進行 LTK (Logo Testing Kit certification) 時有做過不少類似的Case 去驗證裝置的基本穩定度

ref. https://source.android.com/devices/tech/connect/connect_tests

Note: Android Bluetooth HCI Req.

Android 從 4.3 開始導入 Bluetooth Low Energy, 但是因為總總原因API 直到5.0之後才算相對穩定, 所以想要在Android 導入BLE相關應用最好是 Android 5.0 and later 當然現在2018年應該不是啥大問題了, 但是個人覺的真的要有成果要等Android Oreo (8.0)普及後才會比較廣泛的使用到新的Bluetooth 5 的新增的功能.
之前有遇過使用的Bluethooth module 對BLE支援有問題的情況, 這時要依據module 支援的BT版本與使用的Android 版本去驗證, Android 有提供HCI Requirements 文件可以使用

分別是 Android 5.0 HCI Requirements , Android 6.0 HCI Requirements , 然後現在線上版本的Oreo

ref.

Note: NFC LLCP

根據NFC LLCP (Logical Link Control Protocol) 的定義, 使用資料鍊路情況有下面兩種情況

分別是 Connectionless transport 與 Connection-Oriented 兩種, 雖然他是對應OSI 的Layer 2/Data link layer , 但是用TCP/IP的 UDP 與TCP 的類比會好懂點, 雖然規格說會到Connectionless 一樣會到遠端的LLC

根據裝置支援這兩種資料鍊路服務可以分為三個級別, 分別是

  1. Class 1: only support Connectionless transport
  2. Class 2: only support Connection-Oriented transport
  3. Class 3: Both support Connectionless & Connection-Oriented

而一個LLCP PDU(Packet/Payload Data Unit) 的基本結構如下
llcp_pdu

一個最小的PDU 只有 16bits, 就是 DSAP+PTYPE+SSAP而已, 按照規格提到的SYMMERTY(SYMM), 就是 16bits fill 0, 表示目前沒有需要傳送Data/PDU

而規格內稱為 unnumbered PDU,  簡單說就是沒有Sequence  field

而 SYMM 設計是用來檢查 Target 是否還在, 跟給Target 一個機會傳送資料, 可以參考
規格的這段

Typical NFC MACs operate in Normal Response Mode where only a master, called the
Initiator, is allowed to send data to and request data from the slave, called the Target. The
LLCP enables Asynchronous Balanced Mode (ABM) between service endpoints in the two
peer devices by use of a symmetry mechanism. Using ABM, service endpoints may initialize,
supervise, recover from errors and send information at any time.

基本上就是把整各規格讀過一遍, 把PTYPE跟Parameter 讀一下(Chapter 4), 然後了解一下協定的起始順序(Chapter 5), 預設的資料大小是MIU (Maximum Information Unit) 是128Bytes, 可以用PAX (Parameter Exchange)去調整

ref.

 

Note: 台北公車上的行車記錄器

上週五搭公車去某公司面試, 觀察了一下現在車上的行車紀錄器(新店客運)的約莫是7″ LCD, 然後在路線上顯示同時有大概7~8ch的輸入的設計。當公車靠站會自動切換靠車門的鏡頭, 算是有打到需求。鏡頭解析度應該還是D1以內規格

然後我就好奇了這樣的硬體設計要怎樣成本壓低, 想到可以用DragonBoard 410c 接兩路DSI Camera, 一路負責4 ch, 但是這樣的設計要需要有一個搭配CVBS (Colour, Video, Blank, and Sync) to DSI 的convertor/bridge 查了一下 Intersil  ISL79987 剛好適合, 而且NXP有一個for Linux 的patch camera surround view solution

這樣應該可以比較容易的設計出類似的需求而且可以相對壓低成本, 當然要便宜選Rockchip RK3288W 可能更合適

如果要導Automotive Ethernet 到是可以直接考慮 Allwinner T2 去當做Input source Bridge 成本會高一點但是可以更模組化設計擴充, 每顆T2 自帶有四個VideoInput, 配256/512MB RAM應該就夠了 不過如何作到 robust 倒是學問

 

ref.
1. 對岸倒是有直接推出用T2做比較低階的4 input 版本的設計N970WA(T2)
2. NXP 的IMX6 MIPI CSI2 文件 AN5305 講解了 CSI的DATA ID/Virtual channel
3. Backup – my collect
4. CVBS (Colour, Video, Blank, and Sync): Composite Video Signal

Note: 某公司可能的問題

今天早上跟某公司電話溝通一下某職位內容, 該職位會需要NFC相關知識, 從溝通內容聽起來好像使用上有遇到一些問題, 細節我就不清楚, 但是有問一下使用的Transceiver廠商是哪一家的, 然後查了一下該廠商好像只有一個型號, 基於我之前NFC應用經驗, 我第一個會懷疑是NFC本身RF相關問題, 然後看到只有兩檔Output power 可以選, 最大還只有200mW, 就有點發涼, 雖然我沒摸過它家產品, 但是基於該產品是需要防碰撞的設計, 可想而知本身的Housing 應該是有一定厚度才能作到安規需求

跟朋友聊一下它常見的問題, 個人評估有兩種可能一種是真的電極接觸問題, 一種是NFC Output Power 輸出衰退造成的, 當然實際不清楚, 沒看到Failed log 只能這樣憑空臆測, 查了一下其他晶片廠商應該有更好的選擇

200mW的應用情境按照我之前的經驗比較合適是1~3cm感應距離的, 實際上因為應用環境因素可能會縮短感應距離。

後來又查了一下該公司產品資訊好像近期有爆出使用狀況, 感覺是想找人進去救火

做了一下午案例研究
雖然手上沒資料 但是從各種網路使用者反應的現象, 估計是NFC傳輸已經出問題, 造成斷電或是後續更新變成降出功率, 這個現象應該是有80%是 NFC Tx的功率已經開始降低造成
因為是已經運行了兩年, 不知道它們設計的通訊間隔多久, 有做好產品壽命管理嗎? 這個本身是賣服務的公司應該要確保服務品質
又研究一下
如果要處理現在問題, 一個可能方案是透過RSSI去偵測檢測是否有開始有異常
有朋友跟我說跟NFC Power本身無關, 這就好奇了
因為網路上看來的案例應該多多少少有關是NFC連線問題
當然有可能是link reliability的問題, 這實際上跟它產品規格有關, 無線通訊天生在reliability 這個關卡就是需要多下功夫, 但是也跟它應用規格有關, 最糟的情況要透過降低某些規格來權衡系統的穩定度
例如採用Tech , NFCA, 106kbits 應該是相對穩定的狀態, LLCP(Logic Link Control Protocol) 可能要改寫, 採用 Passive mode P2P, 這一切都要系統性的確認與檢查還有模擬實際使用情境, 才有辦法做系統優化