Benutzer-Werkzeuge

Webseiten-Werkzeuge


project:hgg:hardware:interface

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
project:hgg:hardware:interface [2012-01-03 12:40] 2.208.62.151project:hgg:hardware:interface [2016-01-13 09:26] (aktuell) – [Proposal for a dataformat for communication between groundstations and their connected computers] 87.17.102.42
Zeile 2: Zeile 2:
  
 Basically what I was thinking about was mostly the tracking of things, but I wanted to build a protocol in a way that the groundstations stay compatible for a deployment stage that enables them to send. This will surely not be the case for a while but still i'd like to think ahead. The main idea was that this kind of frame can be received and sent to the groundstation. For communication among groundstations over a satellite at least some kind of from adress field needs to be added. Basically what I was thinking about was mostly the tracking of things, but I wanted to build a protocol in a way that the groundstations stay compatible for a deployment stage that enables them to send. This will surely not be the case for a while but still i'd like to think ahead. The main idea was that this kind of frame can be received and sent to the groundstation. For communication among groundstations over a satellite at least some kind of from adress field needs to be added.
- 
  
 ===== Dataformat ===== ===== Dataformat =====
  
 ^ Position ^ Length ^ Name    ^ Meaning                                                        ^ ^ Position ^ Length ^ Name    ^ Meaning                                                        ^
-          |  32       | magic       | magic id = bytes, 'HGG!'                           | +          |  32       | magic       | magic id = bytes, 'HGG!'                           | 
-           64       | rcpnt       | hardware adress of the receipient                    | +  4          16       | protocol    | protocol to be used in the payload                   | 
-|  12         |  16       | protocol    | protocol to be used in the payload                   | +  6         |  16       | size        | size of payload                                      | 
- 14         |  16       | size        | size of payload                                      | +  8         |  32       | chksum      | checksum of payload (??)                             | 
- 16         |  32       | chksum      | checksum of payload (??)                             | +|  12         |  16       | modno       | the receiving module that has generated this request | 
-|  20         |  16       | modno       | the receiving module that has generated this request | +|  16         |  n        | payload     | payload goes here, variable size                     |
-|  22         |  n        | payload     | payload goes here, variable size                     |+
  
 No idea if a magic would be really needed. Basically it's a simple frame format that can be used to implement sending and receiving with the groundstations and should thus be capable of handling different stages in the project. The frames can bei either sent over a serial cable or other device types (like ethernet, firewire or anything else) but still allows to control hardware inside the groundstation directly. No idea if a magic would be really needed. Basically it's a simple frame format that can be used to implement sending and receiving with the groundstations and should thus be capable of handling different stages in the project. The frames can bei either sent over a serial cable or other device types (like ethernet, firewire or anything else) but still allows to control hardware inside the groundstation directly.
  
  
-===== Hardware Adresses ===== 
  
-Since we want to have a distributed network, we also need to think about how to send something over several hops and look into routing strategies in p2p networks. Knowledge about p2p networks and their protocol design is needed for this. I've been imagining a hardware adress based on the groundstation position and some random component - no idea if that'll work. 
  
 ===== Protocols ===== ===== Protocols =====
Zeile 26: Zeile 22:
 Here are a few possibilities Here are a few possibilities
  
-  * 0 = Tracking  (from = 0, rcpnt = own hw id)  +  *   0 = Tracking  (from = 0, rcpnt = own hw id)  
-  * 1 = hardware ping (for finding out about other groundstations) +  *   1 = hardware ping (for finding out about other groundstations) 
-  * IPv4 +  *   2 groundstation diagnostics and control options 
-  * IPv6+  * 128 Networking (Ethernet Frames go here)
   * ...   * ...
  
  
project/hgg/hardware/interface.1325590817.txt.gz · Zuletzt geändert: 2012-01-03 12:40 von 2.208.62.151