Das Problem ist
a) Nötige Kanalcodierung (evtl. werden manche Zeichen häufiger gesendet als andere)
b) Fehlersicherheit
Und das ist nicht so einfach. Natürlich kann man einfach die Daten Huffman-Codieren, das erschlägt a weitestgehend.
Aber b ist ein echt kniffliges Problem, und kommt auf die typische Einsatzumgebung an.
Entweder man nimmt ein Standardverfahren wie Parität, Blocksicherung o.ä. Aber diese sind nicht sehr effizient. Besser wäre ein optimierter Code, der die ganzen Probleme (die da wären: Synchronisation/Taktrückgewinnung, Burst-Störungen, Rauschen, Echos, Verzerrungen etc.) auf einmal erschlägt. Faltungsencoder dafür sind keine schlechte Idee, aber nicht einfach.
Und ganz nebenbei, so einfach wieist es nicht, u.U. bekommt der µC das nicht mit, weil er ja schon sendet... Und was ist bei mehreren Teilnehmern, die alle senden wollen? Blöd ist vor allem, wenn sich nicht alle Teilnehmer hören können...Einfach eine Master Richtung setzen (z.B. PC-> µC). D.h. Wenn der µC empfängt darf er nichts senden.
Ich will hier keine Werbung machen, aber ich würde mir einen Standard-Bluetooth-Dingens für Kurzstrecken und was WLAN-artiges für größere Entfernungen holen - das funktioniert und man hat keinen Ärger damit, obendrein kann man es einfach an den PC koppeln.
Sonst braucht man immer noch ein Funkmodem am anderen Ende.
Natürlich kann man damit Bilder übertragen. Blos nicht unbedingt in "Echtzeit"Könnte man damit auch ein Bild übertragen?
So eine Walkie-Talkie-Lösung wäre vor allem aus Kostengründen interresant...
Lesezeichen