protokoll feste blockbreite vs variable blockbreite

[Sonke A. (soeni)]

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

[Mehmet K. (mkmk)]

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.

[Stephan (Gast)]

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

[soenke (Gast)]

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?

[chris (Gast)]

Bei Funk brauchst du ein preamble, bei Kabel (warscheinlich) nicht.

[lightninglord (Gast)]

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