測試3G手機的DigRF技術
接口以及為電路提供支持信號將會非常復雜;
在隔離與屏蔽能力有限情況下,在與這些敏感RF信號如此近的地方增加一個數字噪聲發(fā)生器,存在著更多的風險;
為每個器件負載板增加元件會使成本上升,延長測試開發(fā)時間。
作為另一種選擇,可以采用一臺提供嵌入實時功能的數字測試儀器,它可以在降低成本的同時簡化DIB復雜性。這種方案的缺點是缺乏測試工程師所需要的靈活性,因為他們要測試一組通信協議。只針對DigRF的解決方案是不實用的。
采用這種選擇時,當測試程序知道有RF接收數據時,就能在RxData總線上捕捉到大塊數據;這個塊必須放大到能可靠地捕捉足夠的數據包,從而有足夠數量的I/Q采樣用于后處理算法。數據從數字儀器的捕捉內存送至DSP引擎,在那里由一個預處理算法執(zhí)行一個三步處理:
找到每個包的起始索引;
分析每個包的頭;
順序地對有效載荷中的I/Q采樣進行去交錯操作,并保存在新的獨立數組中。
一旦數據完成預處理,就可以對所需的I/Q數據集執(zhí)行用戶定制的處理算法,或將數據集輸出到其它ATE軟件工具,測試EVM(誤差矢量幅度)等特性。
這一方法的成功與否取決定于數據移動時間,以及所需處理步驟的效率。盡量減少總測試時間的關鍵是避免與主控PC的不必要交互,因為這種交互要求測試程序暫停DUT測試的執(zhí)行。如果測試儀具有邊做模式捕捉邊移動數據的能力,則向DSP傳輸數據的整個時間都被隱蔽在后臺,測試時間是零損失。
如果測試儀沒有此項功能,則測試工程師就必須尋找能減少移動數據量的方法。一個選擇是只捕捉失效數據,但這會在DSP中增加一個重構原始數據的新處理步驟;單單這個不必要的步驟就會增加數毫秒的關鍵測試時間。
一個完整的DigRF解決方案需要完全在后臺執(zhí)行預處理算法和I/Q處理。因此,第三種選擇就需要測試儀架構能支持執(zhí)行數字信號處理算法的專用處理器,一旦DUT信號捕捉完成,測試程序就能立即開始下一個測試的設置。另外,多址測試也需要這種后臺處理的并行式高效率。
圖4表示這三種選擇對測試時間的可能影響。對第一種選擇,缺乏后臺處理而產生了一個串行的測試流,有最長的測試時間。第三種情況下,采用了實時處理,似乎最為理想,因為它用全后臺處理,以最高效的方式解決了測試挑戰(zhàn)。
圖 4. 這里顯示的三種測試選擇的測試時間開銷:(a) 串行執(zhí)行流,(b) 批量捕捉與后處理方案,(c) 實時處理。
不過,批量捕捉和后處理方案也可以有低的測試時間開銷,只要數據轉移是在后臺完成,并且高效地處理,沒有被浪費的步驟,并有獨立的多址并行處理器。有了適當的系統能力,八址程序的預處理器時間可以低至數毫秒,足以隱藏在一個典型RF測試時間中。
評論