Zweifel an der Implementierung eines einfachen Protokolls für XBee Comms

Ein System, das ich entwickle, wird XBee-Module für eine Punkt-zu-Punkt-Verbindung zwischen einem Mikrocontroller und einem PC verwenden. Daten werden nur in eine Richtung gesendet - Mikro zum PC und mit 10-20fps. Der Datenteil jedes Rahmens beträgt 4 Bytes. XBee-Module werden (zumindest am Anfang) im transparenten Modus ausgeführt. Auf der PC-Seite verwende ich Python, um die Daten von der seriellen Schnittstelle abzurufen.

Anfangs habe ich ein sehr einfaches Python-Programm geschrieben, um Daten 4 Bytes gleichzeitig von der seriellen Schnittstelle abzurufen, was beim Testen mit einer virtuellen COM-Verbindung gut funktionierte (ich habe jedoch noch keine Tests in der realen Welt durchgeführt), aber ich entschied mich zu experimentieren und implementierte schließlich eine einfache Rahmenstruktur wie diese.

sync_flag | Payload_length | frame_number | payload

Nach einiger Recherche entdeckte ich HDLC und überlege nun, etwas Ähnliches zu implementieren, wenn auch einfacher. Bevor ich mich darum bemühe, würde ich gerne hören, was andere zu sagen haben.

Wann ist ein solches Protokoll verdient?

Was haben Sie getan, als Sie Ihre XBee-Netzwerke implementiert haben?

Da ich in diesem Bereich etwas neu bin, bin ich sicher, dass einige relevante Einzelheiten ausgelassen wurden, aber gleichzeitig wollte ich die Frage nicht zu eng / systemspezifisch stellen, aber wenn nötig, werde ich die Frage aktualisieren.

Um Ihr Datenformat zu testen, können Sie simulieren, was das Radio damit macht. Lassen Sie zufällige Bytes fallen und drehen Sie zufällige Bits um. Auf diese Weise sollten Sie in der Lage sein, Ihre Synchronisierungs- und Prüfsummensysteme zu testen

Antworten (3)

Ich werde Xbee-Module verwenden. Ich werde versuchen, ein Punkt-zu-Mehrpunkt-Netzwerk zu verwenden.

Im Moment plane ich Senderkennung, Payload-Typ, Payload-Länge, Payload und Prüfsumme - das würde in etwa so aussehen:

Field            Type    Description   
transmitter_id   uint8   Identifies the transmitting module (0-255)
type             uint8   Type of data (GPS coordinates, hit status, etc.)
length           uint8   Length of payload in bytes
payload          -       Actual payload
checksum         uint16  CRC16 of everything before

So stelle ich es mir vor, das Format kann sich ändern, aber dies wird das verwendete Basisprotokoll sein.

Danke, das ist die Art von Informationen, die ich suche. Wie werden Sie den Start des Frames identifizieren?
Verwenden Sie wahrscheinlich eine Sequenz wie 0xff 0x00 0xff 0x00, oder ich könnte nur eine serielle Schnittstelle verwenden (Xbees überträgt bis zu 8-Bit parallel) und eine Leitung haben, um anzugeben, wann ein Radio spricht.

Wenn Sie den transparenten Modus verlassen, gehe ich davon aus, dass XBee Ihrer Anwendung die Nutzlast von 802.15.4- Frames zur Verfügung stellt. Es ist jedoch möglich, dass Ihre Daten auch in einen ZigBee APS/NWK-Rahmen gepackt werden.


(Quelle: freaklabs.org )

Daten werden in Paketen gesendet – es ist also kein Sync-Header erforderlich

Es gibt bereits ein 2-Byte-Prüfsummenfeld (FCS) - Sie müssen also kein eigenes hinzufügen

Die maximal zulässige Nutzlastgröße beträgt weniger als 128 Byte

Frame-Lieferung und -Empfang sind unzuverlässig

Die XBee-API ermöglicht es Ihnen möglicherweise, die Sequenznummern aus den zugrunde liegenden Paketen zu lesen. Wenn nicht, benötigen Sie eine inkrementierende Sequenznummer und einen Wiederholungsmechanismus.

Danke, einige nützliche Punkte, wenn ich am Ende den API-Modus verwende.

Meine Situation ist etwas komplexer (Hausautomationssystem), daher ist dies möglicherweise ein Overkill für Sie, aber ich habe mich für das binäre JSON -basierte Protokoll entschieden. Es ist flexibel, erweiterbar und wirklich einfach zu implementieren.

Zweifel an der Implementierung eines einfachen Protokolls für XBee Comms
AntwortenHierDatenschutz-Bestimmungen1y, 0v