2010-01-04 138 views
4

這個問題與微控制器編程有關,但任何人都可能會提出一個好的算法來處理這種情況。「投票」的最佳方式是什麼?

我有一箇中央控制檯和一套遠程傳感器。中央控制檯有一個接收器,每個傳感器都有一個發射器以相同的頻率工作。所以我們只能實現Simplex通信。

由於發射機的工作頻率相同,我們不能讓2個傳感器同時向中央控制檯發送數據。

現在我想編程傳感器來執行一些「輪詢」。中央控制檯應該對傳感器的存在有所瞭解(每個傳感器是否響應)

我可以想象幾種方法。

  1. 在每個傳感器的輪詢消息之間使用相同的間隔並隨機啓動傳感器。所以他們不會同時傳輸。

  2. 使用一些圓機制。傳感器1 5秒時爲10秒等開始輪詢所述第二方法1.

的更正式的版本的最大數據傳輸速率大約是4800bps的,所以我們需要考慮這一點。

有人可以想象通過較少使用通信鏈接來解決這個問題的好方法。請注意,如有必要,我們可以爲每個傳感器使用不同的輪詢間隔

回答

1

我推測您所描述的是傳感器和中央單元連接到一次只能傳遞一條消息的總線。

處理此問題的常規方法是進行碰撞檢測。這是例如據我所知,以太網如何運作。您嘗試發送消息;然後嘗試檢測碰撞。如果您檢測到碰撞,請等待隨機數量(打破關係),然後重新傳輸,當然再次進行碰撞檢查。

如果您無法檢測到碰撞,則不同的傳感器可能具有所有不同質數的輪詢間隔。這將保證每個傳感器都具有用於成功輪詢的專用插槽。當然還會有碰撞,但不需要檢測。這裏例如用素數5,7和11:

----|----|----|----|----|----|----|----| (5) 
------|------|------|------|------|----- (7) 
----------|----------|----------|-:----- (11) 
            * COLLISION 

值得注意不要緊如果傳感器開始「同相」或「異相」。

0

我認爲你需要研究一個碰撞檢測系統(一個以太網)。如果你有基於時間的同步,你依靠控制檯上的時鐘和傳感器永遠不會失去同步。如果它們連接到外部可靠的時間參考,或者如果你花費每個電池上的電池支持的RTC(昂貴的),這可能是確定的。

0

考慮使用全部或部分現有協議,除非協議設計本身就是目的 - 除了節省時間之外,您還可以降低協議產生罕見的不可重複錯誤的競爭條件的可能性。

這種情況下的很多協議都讓傳感器保持安靜,直到主控人明確要求他們獲得當前值。這使得避免衝突變得容易,而且如果主認爲錯過了數據包,或者它更關心與其中一個傳感器保持最新狀態而不是與其他傳感器保持同步,它便於主服務器請求重新傳輸。這甚至可以提供比基於碰撞檢測的系統更好的性能,特別是如果主站的命令比傳感器響應短得多。如果最終得到類似Alohanet的東西(請參閱http://en.wikipedia.org/wiki/ALOHAnet#The_ALOHA_protocol),您會發現不經常傳輸和碰撞太多的權衡會迫使您使用不到50%的可用帶寬。

0

是否可以爲每個傳感器分配一個唯一的地址?

在這種情況下可以實現一個主/從協議(像Modbus或類似的),與共享相同的通信鏈路的所有設備:

  1. 萬事達是能夠發起通信的唯一設備。它可以分別輪詢每個傳感器(逐個),將其地址廣播給所有從站。
  2. 只有被尋址的從屬設備纔會回覆。
  3. 如果在一段時間(超時)後沒有響應,則設備不可用並且主設備可以輪詢下一個設備。

參見:List of automation protocols

0

我與一些ZigBee系統工作了幾年前。它只有兩個傳感器,所以我們只是用不同的等待時間對它們進行硬編碼,並且始終對請求做出響應。但是由於Zigbee有系統但是,我們考慮了一些事情:

從控制檯發佈的消息開始吧「嘿,大家,讓我們建立一個網絡吧! 節點都試圖用「我是硬件地址x,我可以加入嗎? 起初它很瘋狂,但隨着一些隨機的重試時間,最終控制檯響應所有節點:'是的硬件地址x,你可以加入。你是#y節點,並且從收到你的數據請求開始,你將有一個等待時間爲z毫秒。'

然後它應該很容易。每次控制檯要求數據時,節點都會響應。假設所有數據的傳輸比您設置的輪詢週期花費的時間少。最好不要承認這些信息。如果控制檯無法響應,那麼當另一個節點嘗試發送數據時,節點很可能會嘗試重新發送數據,並將兩者混淆起來。然後雪球徹底失敗...

相關問題