serielle übertragung mit Funkmodulen

Torsten schrieb:

Hallo Torsten,

schau mal hier:

Freundliche Grüße aus dem Saarland Tom

Hallo Torsten,

100 m steht zwar überall drauf, in der Praxis wirst Du da aber wenig Freude haben, zumindest nicht mit den Modulen mit < 100 mW und irgendwelchen Krüppelantennen in beliebig ungeeignetem Terain.

Das ist normal, damit solltest Du auch rechnen und entweder über redundante Codierung oder Blockweise mit CRC nachdenken. Speziell in den freien Frequenzen musst Du immer mit Störsendern rechnen.

Vom Prinzip die gleichen Probleme

Ja, physikalisch schon, logisch selten. Es soll wohl Module geben, die ein UART transparent durchleiten, die müssen dann aber anderweitig zuvor inizialisiert worden sein.

Wenns schnell gehen soll, würd ich nach BT-Class1 Modulen schauen. Billig ist aber etwas anderes.

Marte

Hallo Torsten,

wir haben sehr gute Erfahrungen mit den DECT Modulen von Hoeft und Wessel gemacht, welche eine transparente serielle Schnittstelle (bis zu 115200 Baud) darstellen und so leicht zu integrieren sind, einzig die Spannungsversorgung des HF Teils mit 4,7 V etwas unhandlich. Die Teile sind leicht, zuverlässig und aber nicht ganz billig, glaub ich, wir haben sie jedenfalls direkt bei denen bezogen, soweit ich mich erinnere. ;)

Hier die URL zu dem Teil:

Schön Gruß!

Ulrich

Ulrich Langenbach schrieb:

Kann ich nur bestätigen, und mit externer Antenne (kleine Yagi) erreicht man beeindruckende Reichweiten, für DECT. Allerdings gibts für diese Anwendung meines Wissens keine Allgemeinzuteilung in Deutschland.

Gruß Dieter

Torsten schrieb:

Die sind schonmal um Welten besser als das ELV-Zeug. Bei RF-Solutions findest du auch noch richtig edle Module, sollte man über Farnell beziehen können. Transceiver haben den Vorteil, dass man bidirektional arbeiten kann, das vereinfacht die Fehlerkorrektur erheblich. Und optimale Reichweite gibts natürlich auch nur mit ordentlicher Antenne, PCB-Leiterschleife ist das definitiv nicht.

Gruß Dieter

Ich habe vor Ewigkeiten mal eine Funk-Uebertragung zwischen zwei AVRs realisiert. Dazu verwendete ich einen sog. "convolutional code". Der war sehr einfach zu implementierten (sehr kleines Programm) und hatte ausreichende Resistenz gegen einzelne Bitfehler und gegen Burstfehler. Nur besonders lange durchgehende Fehler oder mehrere besonders unguenstig zueinander liegende Fehler schlugen durch (Checksumme). Da kein bidirektionaler Kanal zur Verfuegung stand, habe ich dann jedes Paket zudem mehrmals abgeschickt und durchnummeriert.

Andere Kodierungsverfahren sind robust gegen waehlbar viele Fehler, aber dafuer auch wesentlich aufwendiger zu implementieren. Mein Projekt von damals lief in einem AVR 2313, was dank des UARTs die Kommunikation mit dem angeschlossenen PC erleichterte. Ein 1200 haette sonst locker ausgereicht.

Gruss, Marc

Für die Akten: Auf Deutsch "Faltungscode".

Wenigstens einen Viterbi im Empfänger?

Gruß Henning

Ich hatte da mal so eine DECT Einrichtung von Siemens gehabt. Ging immer gut, aber als etwas wirklich zuverlässigens würde ich es nicht betrachten. Gelegetlich ging die Verbindung (ca 70m, durch Wände und Beton) einfach ab, ohne einen ersichtlichen Grund.

War gut für zum Bsp Modemanbindung, also dann surfen in Internet. Als Anbindung für fixe serielle Rate von zum Bsp nur 4800 war es oft noch instabiler.

Ich hab da gerade mal eine dumme Idee,

und zwar denke ich auch momentan darüber nach, wie ich eine einfache Funkübertragung realisieren kann. Entfernung ca. 5m, geringe Datenrate und mehrfache Wiederholung des Paketes. Paketlänge ca. 5 Bytes, Übertragungsrate irgendwo zwischen 1K2 und 19K2... Es wird maximal jede Sekunde ein Datensatz, also ca. 50 Bytes bei 10 facher Widerholung übertragen. Also ca. 500 Bits pro Sekunde.

Problem bei den Funkmodulen ist die Übertragung des Gleichspannungsanteils, deswegen ja NRZ o.ä. NRZ hat nur den Nachteil, dass ich nicht einfach einen UART verwenden kann. Daher folgende Idee:

Ich nehme die einzelnen Bytes und teile die in 2 Halbbytes auf. Kopiere Bit 3 nach Bit 6, Bit 2 nach Bit 4, Bit 1 nach Bit 2. Also so, dass jeweils eine Lücke zwischen den einzelnen Bits entsteht. Dann kopiere ich Bit0* nach Bit1, Bit 2* nach Bit3, Bit 4* nach Bit 5, Bit6* nach Bit7. Damit eliminiere ich den Gleichspannungsanteil und sende diese verwurschtelten Halbbytes über ein normales UART auf den Transmitter. Das Empfangssignal kann ich dann ohne großen Aufwand über die COM-Schnittstelle eines PCs einlesen.

Da der Sender "dumm" ist, d.h. eigentlich nur auf Knopfdruck einen festen String übertragen soll, der fest im Programmspeicher oder im EEProm liegen kann, müssen die Bits nur auf der PC-Seite verwurschtelt bzw. entwurschtelt werden.

Um die 500 Bits pro Sekunde übertragen zu können, käme ich dann theoretisch mit 1K2 aus. Um etwas Reserve zu haben, würde ich dann mit

9K6 arbeiten...

Gruß

Stefan

Am Wed, 24 Jan 2007 08:52:45 +0100 schrieb Stefan Brröring:

Sicher?

Lutz

-- Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin auch für Nagios - Nachricht per e-mail,SMS und SNMP:

Kostenloser SNMP-Monitor für Windows:

für so kurze Entfernungen wäre ja Bluetooth sinnvoll, da sind weit höhere Datenraten möglich, wobei die Übertragung auch gleich gesichert ist. Wir haben das bei uns letztens mal gemacht mit USB-Blutooth-Stick auf der Rechnerseite und auf der Geräteseite den BTKit, der ein C't-Projekt ist und Meßdaten, analog und digital, übertragen kann. Nur bei 100m wird das wohl nicht mehr gehen und ich weiß nicht,ob es da so etwas wie Repeater wie bei DECT gibt. Das Problem beim BTKit war allerdings die schlechte Dokumentation (bzw. fehlende auf der Atmel-uC-Seite) und daß man sich ein Java-Programm schreiben muß, eben eher ein Bastlerprojekt.

Das hatte bei uns das Java-Programm gemacht, 500 Bit/s sollte selbst das schaffen, bei Byte bin ich da schon nicht mehr sicher.

mfg. Winfried

Ok, kommt drauf an...

bei AM dürfte das keine Rolle spielen. Bei FM sieht es allerdings etwas anders aus.

Ich die Module, die ich verwenden will, machen wohl AM, also insofern hast du Recht. Was ja auch nur eine dumme Idee ;-)

Gruß

Stefan

Ist für meinen Zweck ungeeignet. Ich will den Zeitpunkt, zu dem eine Taste gedrückt wird auf wenige ms genau bestimmen. Dazu sende ich nachdem die Taste gedrückt wurde mehrere Datentelegramme mit einer laufenden Nummer aus, so dass ich bei Bitfehlern anhand der laufenden Nummer aus dem ersten empfangenen fehlerfreien Telegramm den Zeitpunkt zurückrechnen kann, zu dem die Taste gedrückt wurde.

Auf der PC-Seite wird ein Symbol auf dem Bildschirm dargestellt und dann ein Startzeichen über COM1 an einen Microcontroller gesendet.

Der Microcontroller hat zwei serielle Schnittstellen und empfängt das Startsignal vom PC und das Funksignal und übermittelt dann die Zeitdifferenz an den PC.

Der resultierende Fehler ist dann die unbekannte Zeitdifferenz zwischen dem Erscheinen des Symbols auf dem Bildschirm und dem Aussenden des Startsignals durch den PC. Alle anderen Zeiten lassen sich dann mit hineichender Genauigkeit herausrechnen.

Mit Bluetooth hätte ich zwar eine gesicherte Verbindung, würde aber die Zeitinformation verlieren.

Gruß

Stefan

[Bluetooth]

Ich würde gerade der Latenz von einem normalen PC nicht trauen. (Inbesondere wenn dort ein richtiges Betriebssystem drauf läuft) Was spricht denn dagegen dem Sender eine Uhr mitzugeben und dann die Urzeit zu dem das Ereigniss statt fand mitzusenden? Mit DCF77 muss man das nicht mal syncronisieren.

Tschüss Martin L.

Es geht darum, die Zeitdifferenz zwischen dem Erscheinen einer Grafik auf dem Display und dem Drücken einer Taste zu bestimmen. Die absolute Zeit ist uninteressant.

Gruß

Stefan