背景介紹
紅外線與藍芽傳輸的差異比較
實際測試 實作及成果整合
結論
實作及成果整合
開發環境及需求
我們這一組實作的目標是希望能夠利用藍芽做電腦和手機檔案的傳輸，提供多樣化的服務給使用者，以下是我們每個階段的實作過程
開發環境
所需配備及模組
所需library
藍芽內部協定實作
啟用本地端裝置並搜尋手機
圖8：電腦及手機之資訊
將原先處於DOWN的裝置啟用，可得到本地端的BD address，使用BlueZ-Utils之function搜尋之後可得到手機之位置及名稱。
確認手機處於可回應狀態
圖9：手機回傳資訊
使用l2cap協定來ping剛剛得到的手機位置，以確認手機是在可回應的狀態。
取得手機傳輸協定資訊
圖10：手機傳輸協定資訊
圖11：手機傳輸協定資訊
由於每隻手機內部可支援的傳輸協定都不一樣，所以我們利用BlueZ-SDP瀏覽手機的傳輸協定後才能決定我們所要使用的管道。如圖10代表使用Dial-up Networking之channel為1，Fax為3。而圖11所提供的一項協定OBEX Object Push則是我們後來在傳輸檔案時所使用的協定，所使用的channel為10。
建立實體連線通道
圖12：建立連線通道
接著我們利用rfcomm協定來建立連線，如圖12，rfcomm show顯示出0這個cannel所連接的位置為T39手機的BD位置。確定此協定無誤後再將連接切斷。
檔案傳輸：client端（電腦->手機）
經過以上幾項步驟確認之後，我們使用OBEX協定傳輸，在OBEX的基礎上，藍芽支援各種數據對象的交換與同步，如vCard、vCalendar、vNote和vMessage等。並用rfcomm協定建立管道，以藍芽協定的角色來看，將電腦作為master端，T39手機作為slave端，輸入參數依序為檔名、-b（代表使用藍芽）、T39的BD address、OBEX協定的cannel number（T39為10）。
圖13：程式測試結果（電腦master傳至手機slave）
圖14：程式流程圖（電腦master傳至手機slave）
如圖13及圖14依序輸入參數之後，顯示已用rfcomm協定建立通道，接著用OBEX協定建立client端，將檔案大小為444bytes的圖檔1.gif傳送到手機端接收。
成果整合
現在在一般市場上，常會見到有網頁提供待機圖案和手機鈴聲下載，但是都還是需要經過付費或是基地台來做傳輸，於是我們將之前的功能和網頁做整合，希望藉由藍芽技術提供使用者作為下載的途徑，此藍芽傳輸頁面可以在此台機器十公尺之內都能有效的接收到所點選的檔案。
圖15：首頁
圖16：搜尋裝置及選擇服務
頁面一開始的畫面如圖15，是一個活潑歡迎介面，點選welcome to Bluetooth即可進入正式的服務介面。如圖16，使用者需將手機的藍芽功能開啟，按下立即搜尋，如有搜尋到藍芽手機即會顯示出device address和device name，點選back連結可回到首頁。
圖17：無搜尋裝置 圖18：已搜尋裝置名稱
當沒有開啟搜尋功能或是附近沒有藍芽裝置時，如圖17畫面會在device address和device name顯示no device告訴使用者搜尋失敗，當有搜尋到裝置時，如圖18會顯示出相關資料。在完成裝置搜尋後，可在圖16中的服務項目中選擇所需服務，包括背景圖案和手機鈴聲。
圖19：下載背景圖案
圖19是背景圖案的下載頁面，只要在選定的圖案後面點選下載，即可立即傳送圖案到手機上，利用back的連結可回到主頁面選擇其他服務。
圖20：藍芽手機接收頁面
圖20是藍芽手機的接受頁面，使用者在點選所需背景圖案後，傳送成功的訊息會顯示在手機螢幕上，並詢問是否要儲存此張背景圖案，要立即儲存只需按下確定即可。
圖21：下載手機鈴聲
圖21是手機鈴聲的下載頁面，只要在選定的鈴聲後面點選下載，即可立即傳送鈴聲到手機上，利用back的連結可回到主頁面選擇其他服務。
圖22：藍芽手機下載頁面流程圖
遭遇問題及解決方案
在一開始的時候我們是打算使用架設藍芽網路卡的方式，來進行實作及傳輸的工作，但是驅動程式卻有無法支援的情況產生，在無法突破的情況下，我們只好選擇更換儀器。將儀器更換為Bluetooth
USB Dongle後，很令人感到振奮的是，微軟在今年五月時，對外發表微軟視窗介面將會開放支援藍芽，同時也公布了開發藍芽所需環境的一些設定，這對之前一向對藍芽抱著觀望態度的微軟，可說是一大突破，所以我們決定試試看這個嶄新的環境。但是由於這些還算是在開發中的套件，對於環境的要求也非常嚴苛，經過測試後，發現我們所使用的USB
Dongle在windows並無支援，於是又將目標轉為對於藍芽已有成熟技術的linux，這才使得環境得以順利的架設。
而在實作過程，除了在電腦建立client端傳送檔案到手機外，我們也曾試過以電腦為server端，接收由手機傳送的檔案，例如像是電話簿或是名片。但是server端建立起來之後，卻一直無法將手機傳送的檔案接收成功，我們試過Ericsson
T39及Ericsson T68兩隻手機來做傳送，Ericsson T39的情況是有偵測到USB Dongle但卻無法順利傳送，Ericsson T68則是連裝置都無法偵測到。
由於在傳輸上始終不順利，所以無法在頁面上做出原先想要的功能，我們整理出了一些發生問題的可能性，首先是現有藍芽晶片穩定度不高，在整合頁面的傳輸的過程中，常會發生程式執行後，藍芽裝置無法順利傳送出去，更嚴重時會有裝置停用的情況發生。還有是各手機間的整合問題，由於現階段各個手機廠商所開發出來的藍芽手機都還是屬於各自為政的情況，在傳送的內部格式上也有差異，這在對使用者使用藍芽裝置時還要考慮相容性的問題，就會造成在使用上的困擾，而這些硬體方面的因素只能期待在未來幾年能開發出更穩定的裝置。
再來要提到的就是藍芽接收器的品質問題，藍芽PC接收器的品質完全取決於控制軟體。像TDK的軟體則號稱是完美軟體的模範，該款由Widcomm開發的控制軟體，巧妙的融合在類似Windows檔案總管的外觀中，讓任何習慣於Windows的使用者都能夠輕鬆上手。使用者能夠在同一個環境下，使用到該轉接器的所有功能，包括搜尋其他設備、與其他設備連線或是複製檔案等等。
在Anycom這家公司則提供了3個獨立的程式。以印表機來做說明：一個用來控制轉接器與建立連線，一個用來作列印工作，另一個則用來複製檔案。雖然說這幾個程式都很容易使用，不過把它們分成3個卻是件很糟的事情，尤其因為程式並不會自動切斷已經與其他設備建立的連線，導致會阻礙其他連線的建立。
我們所規劃的程式是比較類似Anycom公司，不同的功能在不同的程式獨立操作，一直到目前為止我們還是沒有找出檔案無法從手機傳至藍芽接收器的真正原因，只能藉由測試結果加上自己的推論，整合了一些軟硬體方面可能產生問題的原因，當然也希望在未來的研究過程能夠找出解決的辦法。
採用CQDDR（Channel Quality Driven Data Rate）方案提高藍芽設備抗干擾性能是現階段的一個目標，因為藍芽裝置在突發噪音下會受到非常大的影響，利用CQDDR可選擇DH（高數據率）或DM（中等數據率）數據封包類型的特性，可大大提升傳輸的效率。
未來整合方向
我們現在完成的頁面功能是只屬於GSM手機和電腦的傳送機制，在未來的整合方向，是希望能夠朝各種裝置都能下載並上傳檔案的功能來努力，例如PDA、PHS都能夠在藍芽支援下，順利將自己所需檔案下載，也可上傳電話簿或名片在電腦server端提供的頁面方便做整理，我想這是在未來可以努力的方向。
圖23：未來整合方向