基于NI技術(shù)的OFDM發(fā)射接收系統(tǒng)的設(shè)計(jì)

　 基帶處理算法的設(shè)計(jì)與實(shí)現(xiàn)

　　基帶處理算法的實(shí)現(xiàn)

　　是基于LabWndows/CVI8.5的軟件平臺(tái)，它是一個(gè)交互式開發(fā)平臺(tái)，集成了標(biāo)準(zhǔn)C的編譯、鏈接、調(diào)試等，并且采用簡單直觀的用戶界面設(shè)計(jì)，用戶只需在函數(shù)面板上直接輸入?yún)?shù)，就會(huì)以事件驅(qū)動(dòng)回調(diào)函數(shù)的方式運(yùn)行整個(gè)程序，并可以將數(shù)據(jù)以圖形的形式在界面上顯示，提高了整個(gè)工程的運(yùn)行效率。圖2為本系統(tǒng)發(fā)端和收端的應(yīng)用界面。

圖2 OFDM發(fā)、收系統(tǒng)界面

　　對(duì)于單線程系統(tǒng)，一般分為數(shù)據(jù)的采集模塊、分析處理模塊、顯示存儲(chǔ)模塊。這三個(gè)模塊在時(shí)間上是順序執(zhí)行的，即后一個(gè)模塊需等待前一個(gè)模塊數(shù)據(jù)的到來時(shí)才開始工作。然而本系統(tǒng)對(duì)實(shí)時(shí)性要求比較高，比如在收端，USB聲卡的播放需要收端的音頻譯碼模塊在400ms內(nèi)處理完一幀，才能及時(shí)提供給USB聲卡樣點(diǎn)連續(xù)地播放聲音，這就需要音頻譯碼模塊前的所有基帶處理部分需要在400ms內(nèi)完成一個(gè)物理幀到音頻幀的解調(diào)。同樣在發(fā)端，USB聲卡每秒采集19200個(gè)樣點(diǎn)給音頻編碼模塊進(jìn)行編碼，每400ms輸出一音頻編碼幀，F(xiàn)EC、映射及OFDM成幀等模塊也必須在400ms內(nèi)處理完成，否則會(huì)出現(xiàn)丟幀和覆蓋的現(xiàn)象。可以肯定，用單線程這種順序化的執(zhí)行方式效率很低，每個(gè)模塊都要等待前一個(gè)模塊的數(shù)據(jù)，對(duì)于實(shí)時(shí)性要求較高和復(fù)雜性較高的系統(tǒng)不適用。

　　本系統(tǒng)使用的是多線程技術(shù)，可以將處理模塊拆分成多個(gè)線程，使多個(gè)線程并行運(yùn)行，只要保證每個(gè)線程的運(yùn)行時(shí)間小于音頻處理模塊，系統(tǒng)就會(huì)正常工作。其中發(fā)端算法用3個(gè)線程完成音頻編碼，F(xiàn)EC、映射、OFDM成幀等處理，并將OFDM數(shù)據(jù)寫到板卡RAM中。收端算法用6個(gè)線程完成從板卡RAM中讀取 OFDM基帶數(shù)據(jù)、同步、均衡、FFT、解映射、解FEC等處理，最后由音頻譯碼模塊將音頻幀送給USB聲卡進(jìn)行播放。

　　為了保證線程間數(shù)據(jù)傳遞有序進(jìn)行，CVI還提供了事件通知、安全隊(duì)列、線程優(yōu)先級(jí)等函數(shù)，保證線程間的同步和數(shù)據(jù)的傳遞。本系統(tǒng)使用的是全局BUFFER和安全隊(duì)列回調(diào)函數(shù)方式使兩個(gè)線程間獲得同步。即兩個(gè)線程間共享一個(gè)BUFFER和安全隊(duì)列，前一個(gè)線程將每次計(jì)算得到的數(shù)據(jù)寫到BUFFER中，并產(chǎn)生一標(biāo)志位 FLAG，寫入安全隊(duì)列，后一線程捕捉到安全隊(duì)列中的FLAG，判斷是否滿足回調(diào)函數(shù)的條件，滿足則啟動(dòng)該線程，并將BUFFER中的數(shù)據(jù)讀出，不滿足則繼續(xù)捕捉FLAG。通過對(duì)安全隊(duì)列中FLAG的讀寫，控制線程啟動(dòng)的時(shí)間，使得兩線程對(duì)數(shù)據(jù)的讀寫達(dá)到平衡。程序中控制流程如圖3所示。圖4為由 PXI5671輸出到頻譜儀E4440A的OFDM頻譜。