FEC-Implementierung auf uC?

[ThSteier]

Hallo,

hat hier schon jemand konkrete Erfahrung mit FEC (forward error correction) gesammelt? Standards gibt es ja einige, ich bin nur arg am Grübeln, ob und welcher davon am einfachsten auf einem Controller umsetzbar wäre... Die ganze Geschichte läuft (ob nun zB Hammond, Reed-Muller oder ein anderes Verfahren zum Einsatz kommt) irgendwie immer auf Matritzenrechnung hinaus - und wie man das in der Praxis mit den (doch etwas beschränkten) Möglichkeiten eines Controllers realisieren könnte, liegt meilenweit jenseits meiner Kenntnisse.

Das an sich ganz interessante (und frei verwendbare) S.N.A.P-Protokoll beinhaltet zwar theoretisch auch eine FEC-Variante, allerdings finden sich dazu weder auf der HTH-Homepage noch im Netz konkrete Einzelheiten oder gar praktische Umsetzungen. Es sieht eher so aus, als sei das mal vorgesehen gewesen (steht hier TBD etwa auch für "to be determinated"?), aber irgendwie eingeschlafen
Oder ich bin einfach zu dämlich zum Suchen - aber Google auf eine Reihe von drei-Buchstaben-Kürzeln loszulassen, ist nicht wirklich hilfreich...

Lange Rede, kurzer Sinn: ich wäre mehr als dankbar, wenn mir jemand auf die Sprünge helfen könnte.

Viele Grüße,
Thomas

[ThunderD]

Für welche Anwendung würdest du das benötigen?
Vielleicht gibt es einfachere Methoden zur Fehlerkorrektur.
Wieviel Redundanz willst haben?

[ThSteier]

Ich bin noch beim Ideensammeln bzw dabei, herauszufinden, was überhaupt realistisch ist und was nicht... Kurz gesagt geht es nicht direkt um Robotik, sondern um eine Art bessere Wetterstation: eine kleine, robuste Plattform mit diversen Sensoren für Umgebungsdaten, die in freier Wildbahn möglichst lange autonom arbeiten und die gesammelten Daten paketweise per Funk übermitteln kann. Die Betriebsdauer ist hier auch der Knackpunkt - idealerweise soll der Sensorpack über Monate ohne Batteriewechsel usw auskommen, indem er normalerweise "schläft" und nur mittels RTC in regelmäßigen Abständen "geweckt" wird.

Daher auch die Idee mit dem FEC zur Übermittlung. Eine wiederholte Aussendung der Datenpakete (nach dem Motto "Wenn wir fünf losschicken, wird eins schon komplett durchkommen") wäre zwar möglich, allerdings erkauft man sich dort die Redundanz durch den relativ hohen Stromverbrauch des Senders gleich wieder gleich wieder mit erhöhtem Energieverbrauch.
Und auf eine bidirektionale Verbindung (CRC und Bestätigung des korrekten Empfanges) möchte ich gern verzichten, da der Sensorpack durchaus verloren gehen kann und daher möglichst preiswert und wenig aufwendig gehalten werden soll.

Wieviel Redundanz dabei wirklich notwendig ist, ist eine gute Frage... Von der Sache her macht es nichts, wenn mal ein Paket verstümmelt wird. Aber in Hinblick auf langfristige Zuverlässigkeit wäre es mir schon lieber, irgendeine Art von Fehlerkorrektur zu verwenden - nicht, daß ich nur noch Müll empfange, nur weil mal 'ne Spinne auf der Sendeantenne ein Netz baut.

Viele Grüße,
Thomas

[ThunderD]

Ah okey verstehe deine Problematik.
Meiner Meinung nach wäre bidirektional aber auch keinwirklicher aufwand oder? Senden ist in der Regel der aufwendiger wie empfangen und die Kosten würden sich nicht wirklich erhöhen.

Ansonsten könntest du auch Hammingcodierung verwenden.
Ist sehr einfach und du kannst 1Bitfehler korrigieren.
Wenn du dann noch alle Daten also Zeit,Temperatur usw. einzeln senden würdest, wären kurze Fehler auch nicht wirklich schlimm. Zudem wäre es noch möglich, wenn du die Werte in mehreren Packeten sendest, eine Art Raid zu programmieren. Also alle Packete mit Hamming + ein Packet zur Korrektur der anderen Packete.

Fraglich ob das einen Vorteil gegenüber des mehrfach sendens bringt.

Wenn mir weitere blöde Ideen kommen meld ich mich wieder

[ThSteier]

Na ja, das mit der bidirektionalen Übertragung ist vor allem eine Geldfrage: es sollte nicht allzusehr schmerzen, wenn mal ein Sensorblock wegkommt. Und da macht es doch was aus, ob ich zB einen TRX für knapp 40€ oder einen nackten TX für 15€ verbastele - der Rest der Elektronik hält sich kostenmäßig (noch) in Grenzen.

Ich überlege inzwischen schon, ob ich einfach das (Pseudo-) FEC aus dem im Amateurfunkbereich verwendeten AMTOR-Protokoll verwende: dort werden die Zeichen doppelt und nach dem Reißverschlußprinzip zeitversetzt verschachtelt übertragen. Der Rechenaufwand hält sich dabei in Grenzen, und die Zuverlässigkeit müßte eigentlich reichen. Na, mal schauen, was draus wird - das Problem ist immer die liebe Zeit...

Viele Grüße,
Thomas