RFM12 Datenende erkennen?

[S.Pfiffig (Gast)]

Hallo,

ich habe mich gerade mal etwas mit dem RFM12 beschäftigt. Mit festen 
Übertragungspakten klappt auch soweit alles.
Mein Frage nun, was ist wenn man flexible Paketlängen nutzen möchte. 
Hilft einem das RFM12 irgwendwie beim Empfang zu erkennen wieviel bytes 
gesendet wurden? Da hab ich nirgends Infos zu gefunden.
Oder muss ich die Datenlänge selbst mit übertragen und das Byte dann 
während des Empfangs lesen und nach dieser Länge den Empfang selbst zu 
beenden?

lg
S.Pfiffig

[Karl H. (kbuchegg)]

Da technische Geräte nicht in die Zukunft sehen können
(woher weiß denn der Sender, dass vom Programm die nächste halbe Stunde 
kein Byte mehr kommt, welches es übertragen soll)
läuft es eigentlich immer darauf hinaus, dass du selbst dir durch das 
Protokoll eine Möglichkeit zurechtlegst, wie der Empfänger feststellen 
kann, ob er alle Daten hat, oder ob noch was fehlt.

[S.Pfiffig (Gast)]

Nun ich dachte das der Sender ja nach der bytefolge auf hört zu senden 
und das fehlende Signal irgendwie erkannt wird!

[Bastler (Gast)]

Und was machst du wenn das Datenpaket abreißt?

Bei mir bewährt hat sich:

Start|Type|Length|Data|CRC|Stopp


zusätlich einen Timer beim Empfang von "Start"  starten um ein Timeout 
ermöglichen, dass sich der Empfänger nicht blockiert.

[Karl H. (kbuchegg)]

S.Pfiffig schrieb:
> Nun ich dachte das der Sender ja nach der bytefolge auf hört zu senden
> und das fehlende Signal irgendwie erkannt wird!

Ob die Trägerfrequenz fehlt oder nicht, lässt sich beim Empfänger 
natürlich feststellen. Aber was hilft dir das?
War das jetzt Absicht oder ist beim Sender die Batterie leer? Ist da 
vielleicht irgendwo ein Kabel rausgefallen oder hat dir ein Bagger bei 
Erdarbeiten das Kabel zerrissen? Ist ein CB-Funker mit dem Auto 
vorbeigefahren und hat das Funksignal gestört?

Du siehst schon: Es ist immer schwer, eine Fehlersituation von einem 
gewollten beendigen der Datenübertragung zu unterscheiden, wenn du nicht 
mehr hast als: "Da kommt nichts mehr."

Es kann viele Ursachen dafür geben. Daher ist es am zuverlässigsten, 
wenn man vereinbart, dass der Sender in irgendeiner Form bekanntgeben 
muss, jetzt kommt nichts mehr.

Beispiel:
Du hast die Aufgabe die Zahl auszusprechen, die ich dir gleich 
'übertrage'
Ich: 34 ....
Du: vier-und....
Ich: 8
Du: grr. drei_hundert_und_acht_ ....
Ich: 9
Du: argh. drei_tausend_vier_hunde ....
Ich: 5, tschuldigung, musste aufs Klo
Du: Ach weißt du was. LMAA. Sag einfach Bescheid wenn du fertig bist
Ich: 7  Fertig
Du: Ja, jetzt. drei_hundert_acht_und_vierzig_tausend_neun_hundert_
        und_sieben_und_fünzig.
Ich: Stimmt
Du: Na siehst du. Geht doch. Musst halt nur was sagen.


Lass dich immer von der Prämisse leiten: Niemand, auch kein Computer 
kann in die Zukunft schauen. Wenn er im Vorfeld nicht weiß, was da 
kommt, dann musst du ihm die Info geben oder zumindest sagen, wann du 
alles übertragen hast.

[S.Pfiffig (Gast)]

Ok, das wollte ich wissen, danke!

[Jörg W. (dl8dtl) (Moderator)]

Karl Heinz Buchegger schrieb:
> Ob die Trägerfrequenz fehlt oder nicht, lässt sich beim Empfänger
> natürlich feststellen.

Naja, in hinreichender Entfernung kann man das schon nicht mehr so
sauber feststellen, ob man nun tatsächlich den Träger des gewünschten
Senders oder einen fremden Träger oder einfach nur Rauschen hat.
Daher ist eine Längeninformation und eine ordentliche CRC praktisch
Pflicht.

Ist halt die Kehrseite des Billig-IC-Konzepts wie beim Si4420 hier:
all diesen Kram muss man sich in der Software antun, die damit
entsprechend teurer wird.  Aufwändigere ICs implementieren sowas
wie eine Längeninformation und CRC in Hardware, die können dann
auch automatisch aufhören, den Frame zu empfangen.