Hallo, ich benötige für ein Projekt ein protokoll, welches sowol für die Übertragung über funk als auch für die Übertragung per Kabel geeignet ist. Eigentlich wollte ich das selber entwerfen nachdem mir vorhandene Protokolle zu viel overhead haben. Da hat sich bei mir die Frage gestellt, was einfacher bzw. besser ist, ein Protokoll, welches immer eine bestimmte Blockbreite hat oder eines was die Blockbreite am anfang mitsendet und eine nahezu variable blockbreite bietet (mit maximallänge) was sind vor und Nachteile? Kennt sich dami jemand aus? Sönke
Für meine Projekte verwende je nach Bedarf 2 Protokolle, die beide eine variable Laenge haben. 1. Protokoll: STX StartByte SRC Source DST Destination CMD Command LO Low Byte Data-Laenge HI Height Byte Data-Laenge DATA Data CRC Low Byte CRC CRC Height Byte CRC 2. Protokoll: Bei 1:1 Verbindungen entfallen SRC und DST.
Hi also für die Funkdatenübertragung ist ein Protokoll mit variabler länge immer besser. In meiner alten Firma haben wir 2 Protokolle verwendet: ModBus und ein eigenes das auf ModBus auf setzte (MOP2). Wenn du dir ein Protokoll aussuchst muss du dir im klaren sein was die alles im Funk machen möchtest. ModBus ist nur ein P to P Protokoll und daher nur begrenzt einsetz bar oder für dich genau das richtige. mfg Stephan
aber was sind den vor bzw. nachteile? ich meine bür micht sehe ich nur den nachteil bei einer konstanten blockbreite, das ich einen imensen overhead an daten habe, was bei nem uC nicht spaßig ist, wenn man einigermaßen durchsatz haben will. was sind den noch vor/nachteile?
Bei Funk brauchst du ein preamble, bei Kabel (warscheinlich) nicht.
Wenn deine Daten immer die selbe größe haben ( zb. Temperaursensor, der immer den wert 2 Byte groß ausgibt ) ist nen FixPacketProtocol sinnvoll, da kannst du auch gleich erkennen wenn zu wenig ankommt das was nicht passt ( ersetzt auf keinen fall nen CRC o.Ä. ) Arbeite auch gerade an einer Wireless-App wo die Daten immer ne Fixe länge haben. mein Protokol sieht so aus: 1 Byte Header 1 Byte DeviceID ( Host = 0, Sensoren > 0 ) 6 Byte Daten 1 Byte XOR ( auf Header, DeviceID und Daten ) Da mein Empfänger eine Bit-Valid funktion hat kann ich bis zu 8 Fehlerhaften Bits empfangen und diese übern XOR wieder rausrechnen. Desweiteren hab ich noch einen Prebrust um den Sensor aufzuwecken und ein Preamble zur Triggerung der Messung/Übertragung
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.