Hallo allerseits, mich würde mal interessieren, wann man für eine FSK-Übertragungsstrecke welches CRC-Polynom auswählen sollte. Warum bietet so ein käufliches Funkmodul beispielsweise diese vier Varianten zur Auswahl an? Nur zur Anpassung an bereits vorhandene Teilnehmer? Wann sollte man die CRC nur über die Nutzdaten gehen lassen und wann zusätzlich über die Headerbytes beispielsweise. Normalerweise möchte man doch alles fehlerfrei übertragen bekommen. Wo könnte man darüber etwas lesen? CCITT, CRC-16 (IBM), IEC-16, Biacheva Danke im Voraus Mit freundlichem Gruß
Beine Beobachtung bei selbst implementierten CRCs. Wenn man das Polynom angibt, kann man zuviel falsch machen. Das gibt dann Fragen an den Support. Daher sollte man immer die effektive Prozedur in Kontext des Messagebocks mitgeben. Bei einem Geraet, das mit anderen moeglicherweise Fremden Geraeten arbeiten soll, kann man auch verschiedene CRCs zur Auswahl stellen. Moeglicherweise haben die zur Verfuegung gestellen CRCs auch technische Unterschiede, im Sinne von, fuer welche Fehlerarten andere charkteristiken bestehen. Allenfalls mal Guurgel dazu befragen..
Hi, Christian, > mich würde mal interessieren, wann man für eine FSK-Übertragungsstrecke > welches CRC-Polynom auswählen sollte. Ein wichtiger Auswahlparameter ist die Länge des Datenpakets, die gesichert werden soll. Ist es zu lang, wurde es bei jedem Übertragungsversuch unterbrochen durch andere Sender, die dazwischen funken. Ist es zu kurz, müssen zu viele Pakete gesendet und die Quittungen empfangen werden. Über "das beste Polynom" habe ich Arbeiten gesehen, da geht es unter anderem um die Freiheit von Gleichspannungsanteilen. So was kommt er nach der Bastelei und dem ersten erfolgreichen Empfang. Ciao Wolfgang Horn
Hallo, was die Länge angeht wird es vorerst 64 Bytes nicht überschreiten. MfG
Wolfgang H. schrieb: > Über "das beste Polynom" habe ich Arbeiten gesehen, da geht es unter > anderem um die Freiheit von Gleichspannungsanteilen. Gleichspannungsfreiheit wird doch auf einem Level der Übertragung direkt über der physischen Ebene sicher gestellt. Was hat das mit dem CRC-Polynom zu tun?
Hallo, außerdem möchte ich gerne noch wissen, wann man "data whitening" einsetzen sollte oder ob man dies nur aus Prestige zuschaltet. Was es bewirkt wird hier ansatzweise beschrieben: Radio operation is optimized when the data bits being transmitted are random and DC-free, not only because this gives a smooth power distribution over the occupied RF bandwidth, but also because random and DC-free data prevents the possibility of data dependencies in the receiver control loops" "The 9-bit pseudo-random number (“PN9”) generator is shown in the top of Figure 1. The generator is described by the polynomial x9 + x5 + x0. The PN9 generates all the values between 1 through 511 (inclusively) in a pseudo-random order as it is clocked. The latches are all set to ones at the start of a whitening operation." https://www.google.com/url?sa=t&source=web&rct=j&url=http://www.ti.com/lit/an/swra322/swra322.pdf&ved=2ahUKEwjZmufPiNzdAhVGUlAKHcK_B3sQFjABegQICRAB&usg=AOvVaw12R2HdMNqs_n5FbjwgIgI7 mfG
Christian S. schrieb: > außerdem möchte ich gerne noch wissen, wann man "data whitening" > einsetzen sollte oder ob man dies nur aus Prestige zuschaltet. Du wirst wohl kaum eine "1FF" aus dem PRN-Generator direkt auf eine Datenstrecke geben, bei der der Gleichspannungsanteil ein Kriterium ist. Guck dir auch gleich das Kapitel "Bit-stuffing" an.
Hi, W.A., >> Über "das beste Polynom" habe ich Arbeiten gesehen, da geht es unter >> anderem um die Freiheit von Gleichspannungsanteilen. > > Gleichspannungsfreiheit wird doch auf einem Level der Übertragung direkt > über der physischen Ebene sicher gestellt. So macht man das seit einigen Jahrzehnten, und das ist gut. Konkret erinnere ich mich an Datenfunksysteme, die mit CRC versehen wurden, damit ja kein Bit-Pattern die PLL im Empfänger irritiert. Sondern die CRC verhinderte Pausen in der Übertragung des Taktes. Diese Pausen habe ich mit "Gleichspannungsanteil" umschrieben. Die handelsüblichen Produkte sind über das Problem längst hinaus. Ciao Wolfgang Horn
Wolfgang H. schrieb: > Sondern die CRC verhinderte Pausen in der Übertragung des Taktes. > Diese Pausen habe ich mit "Gleichspannungsanteil" umschrieben. Üblichweise werden zu lange Pausen in der Taktinformation per Bit-Stuffing verhindert, was einem dann gegenüber Manchester-Kodierung die Bandbreitenerhöhung erspart. Wenn man natürlich durch geschickte Wahl der CRC die Sicherung der Datenübertragung und das But-Stuffing unter einen Hut bekommt, spart man sich ein paar zusätzliche Bits und hat vielleicht noch den Vorteil einer konstanten Datenlänge auf dem untersten Übertragungslevel.
Ach, Wolfgang, >> Sondern die CRC verhinderte Pausen in der Übertragung des Taktes. >> Diese Pausen habe ich mit "Gleichspannungsanteil" umschrieben. > > Üblichweise werden zu lange Pausen in der Taktinformation per > Bit-Stuffing verhindert, Wollen wir noch das Fass der synchronen Netze aufmachen, nur damit Du "ich hatte doch recht!" sagen kannst? Ich habe dazu keine Lust. Aus meiner Sicht hat bisher keiner etwas deutlich Falsches geschrieben. Ciao Wolfgang Horn
Danke für die Zuschriften. Es eröffnet sich wieder ein neues Vertiefungsgebiet. Zumindest gelingt bisher die Übertragung zufriedenstellend, wenn auch die Geheimnisse der Feinheiten noch nicht gelüftet sind. MfG
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.