Note: Add Audio Prompt

ADK 6.3 for Sink Application 的Audio Prompt 可以透過改 modules_configurations/sink_audio_prompts_module_def.xml 內的來實現

裡面的 ShortId 是之後會轉成.h/.c 用的 變數名稱欄位, Id 則是給tools看的顯示欄位
num_audio_prompt_languages <== 這代表Audio prompt 可以多語系支援

num_audio_prompts <== 這用來代表會有幾個Audio prompt, headset 下面的 Value=12, 代表有0.idx/0.prm ~ 11.idx/11.prm, 改成13後, 並且在 對應的目錄下有對應的檔案才能正確撥放, 單單放檔案是無法自動生成檔案的

可以透過 GAIA 內的 COMMAND_ALERT_VOICE, 傳入一個 uint16 的playload 指定, 撥放哪個檔案, 這樣可以用來做驗證測試, 不過很怪, 雖然說有多語的準備 但是在Sink Application 只檢查是否大於1的語系, 然後檢查是否小於 num_audio_prompts 就撥放了

基本上 module_configurations/*_def.xml 會被編譯前處理變成 *_def.h
例如 sink_audio_prompts_module_def.xml ==> sink_audio_prompts_config_def.h

上面的前處理是透過phython code 會產生一個 “config_build.log" 檔案, 相關的訊息可以透過該檔案找出關聯, 當然也可以使用 ADK Configuration Tool 去配置, 不用管底層機制, 不過個人習慣去直接改相關xml 並且把PSkey/LED/Button 相關設定一次改好

 

 

廣告

NOTE: setup Qualcomm ADK 6.3 development environment

之前因為某些因素拿到一張 Qualcomm QCC5120的開發版, 當時很順利的把開發環境建立起來, 可能那時一開始, 比較乖有讀文件吧, 中間經過開發電腦的SSD 跟OS 升級等因素, 而且中間開發的平台也一度換到 CSR 8675上面, 所以就沒有重建 QCC5120 的開發環境, 但是計畫趕不上變化, 最後又繞回來, 需要做QCC5120 的開發, 但安裝好 MDE 2.2.0 + ADK6.3 後 要開始Debugging 卻連不上開發版

先連接上Qualcom 的 CF376 (Carrier Board) + CF931(QCC5120)的開發版, 然後安裝 Qualcomm QCC5120 的USB debugging interface 的相關driver

要先到Win10 的DeviceManager 下面找到 一個 USB\VID_0A12&PID_4010 的HUB device 然後去掛 Qualcom 提供的Hub Filter driver

該driver 一般預設安裝到 “:\Program Files (x86)\QTIL\Drivers\Qualcomm_Driver_WIN_USBDebug_100.0.0″ 下面,  接著DeviceManger 還有一個Unknown device 一樣在掛一次前面路徑的driver 後, 就會看到 Qualcomm USB Hub Filter Device/Qualcomm USB Debug Interface

裝完後 這樣MDE 還不能正確認到 USB Debugging interface, 還需要透過下面的指令去寫一個unlock key 讓 MDE 知道不是透過TRB 而是USB
ADK 的tools\bin\TransportUnlock.exe writeunlockkey ..\..\..\unlock_usb.txt
unlock_usb.txt 我是用預設的 0000000000000000000000000000000 一共32字元的0去當unlock key

 

 

Note: nRF52x with Simple BLE link

Nordic 的Zigbee 雖然還是不成熟, 但如果採用OpenThread 的方案, 目前看起來還是可以用的, 不過 802.15.4 上面有太多版本, 日前研究了一下 802.15.4e 後有實際多一個除了CSMA-CA的選擇, 稱作 TSCH(Time Slotted Channel Hopping), 而6LoWPAN 則定義了一個6TiSCH , 目前參考實作則為 OpenWSN, 這個相關技術提高了傳輸的可靠性與減少碰撞的可能, 但是基於之前設計的Zigbee/Thread 目前都還沒應用這些技術, 但是還是有一個設定簡單建議就是設定使用的Channel 為(2.4GHZ) Ch15, Ch20, Ch25, Ch26, 可以剛好避開WIFI AP 最常見的預設頻道 Ch 1, Ch6, Ch11 可以參考下方頻段圖

而有時候應用場域相對簡單的地方, 可以直接採用BLE MultiRole的應用直接連線多個Device, nRF52x 應該一個BLE Central 可以連最大 20 Peripheral device, 這限制是其SoftDevice API的關係, 但是據說Zephyr 的Link Layer 由Nordic重寫的版本可以支持到 32 link, 上述的連線限制是因為保留的 LinkLayer的記憶體沒有預留那樣大的關係, 在Nordic 的PlayGround Github 有個example就是有個簡單範例這樣使用 nrf52-ble-multi-link-multi-role 情境

可能有人會想用Bluetooth 處理這樣的場景, 如果是非電池供電的話, 不在乎 Power Consumption 的情景才能用現在的Nordic的BLE Mesh SDK, 因為現在的設計是無法進入Sleeping, RF 的RX要隨時保持打開, 這樣估計會消耗掉接近 8 ~ 10mA/sec, 而非Mesh 的狀態, 或是採用OpenThread 的狀態會低於1mA, 只有實際需要TX/RX 才會消耗大電流, 不過Nordic跟Wirepas 有合作新的專有Mesh, Wirepas Pino, 據說可以解決耗電跟碰撞問題, Wirepas的Silicon Vendor 配合的也有Ti & Silicon Labs

Note: ADK Source – USB Dongle

最近掉進一個坑, 遇到一些不靠譜的人, 目前需要深入客製化某個Bluetooth應用, 但是給的文件都很片段的針對某個應用, 對於底層機制設計實際上著墨不多需要花大量時間研究, 目前看起來還是對岸有很多之前留下來資料, 就算到現在是ADK 6.3 時代也值得一讀, 畢竟最核心的基礎設計是沒變的, 基於XAP/ROM code, 本身應該是micro kernel 設計, 所以看到VM/DSP application 都是透過各種message id 傳遞觸發

而 Kalimba-DSP 的.asm 經過編譯會變成 .kap 的組譯檔案(文字格式的16進制)

ADK 2/3/4 中有一個 Audio Source  範例預設的 Audio source 是 USB , 另外可選的是Analogue/SPDIF

他獲取 USB audio data的方式應該是, 透過 ${ADK}\kalimba\apps\one_mic_example\main.asm 內的 audio_copy_handler
要切成其他音源的話應該只需要修改這邊的設定
ref.
ADK 2.0 Software Training
ADK 4.0 documents

Note: ADK 6

因為網友拿到一塊 CSR/Qualcomm, QCC5120 開發版註記一下東西, 這ADK看起來源自以前的BlueLab, 當然因為Bluetooth/BLE的蓬勃發展, 整個架構變得更大更複雜了, 但是一般如果開發基本的藍芽設備, 實際上已經有完整的template project, 而且用內建的選項它會複製一份code 並且可以直接搭VCS 的SCM tools 不過目前看起來內建選擇是svn與 Perforce, 沒有git 是比較奇怪的

MotherBoard (Carrier Board)
是 CF376
QCC5120 Board
是CFG212
版上的 QSPI 是WINBOND 25Q64FWS16G

編譯Sink Application 要選 HwVariant
QCC5124-AA_DEV-BRD-R2-AA

device name 與bdaddress的pskey 在

$(project)\apps\applications\sink\qcc512x_qcc302x\common\subsys1_config2.htf

基礎的設定要讀

80_CG040_1_AD_ADK_6_X_AUDIO_SINK_APPLICATION_USER_.pdf

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: GATT service with Bluetooth Low Energy

傳統的Bluetooth Device 透過 SDP service 使用Profile UUID 去讓兩者相連, 但是BLE則擴充了這個方法, 透過提供 GATT (Generic Attributes) Profile 去取代 SDP的功能,使用GATT Service 內的 Service/Characteristics 功能可以更方便跟分類各種服務跟屬性值, 並且透過GATT 可以自我宣告特定應用的Service與Characteristics 去創建自己的特殊應用 常見有iBeacon/Eddystone Beacon 或是 像是 TI SensorTags 可以參考這個 Andorid Source 去使用Ti 自定義的Barometers service

官方說法 from https://www.bluetooth.com/specifications/profiles-overview
For two Bluetooth devices to be compatible, they must support the same profiles. And while profiles generally describe the same use case behaviors, they are different for Bluetooth BR/EDR and Bluetooth Low Energy (LE) implementations. Compatibility between Bluetooth BR/EDR and Bluetooth LE implementations requires a dual-mode controller on at least one. For BR/EDR, a wide range of adopted Bluetooth profiles describe many different, commonly used types of applications or use cases for devices. For Bluetooth LE, developers can use a comprehensive set of adopted profiles, or they can use Generic Attribute Profile (GATT) to create new profiles. This flexibility helps support innovative new applications that maintain interoperability with other Bluetooth devices.