Gruß an Euch! habe jetzt nach laaaaaangen probieren eine Verbindung zwischen RFM01 und RFM02 aufbauen können (Pollin Module 433MHz). Ich schleuse nach erfolgreicher Initialisierung (Hardware SDI) der Module einen Datenstrom mit 4800 bps extern (USART) über den FSK-Pin am RFM02 in den Mischer ein. Auf der Empfängerseite wird der Datenstrom aus dem DATA bin ausgelesen und über USART weggeschickt. Das ganze klappt ganz gut ich habe sehr guten Empfang mein Oszi zeigt mir ein wunderbares Signal sowohl vor Sender und nach dem Empfänger. Mein Problem sind Bitfehler die ohne jedes System auftauchen und mir meinen Datenstrom (bzw. einzelne Zeichen) unbrauchbar machen. Beim Datenstrom handelt es sich um ein GPS-Signal nach NMEA-0183 Standard. In jeder Zeile des Protokolls tauchen mind. ein Zeichenfehler auf der auf einer Bitverfälschung basiert (im ASCII-Code binär angeschaut). Da meine Übertragung auf Kabel beruht schließe ich Einstrahlungen aus. Auch ist mein Signal-Rauschabstand sehr groß... Ist die PLL bzw. die FSK Modulation zu billig für einen ständigen Datenstrom? Und meiner Erfahrung nach treten Bitfehler mit 10^-6 Wahrscheinlichkeit auf, bei mir viel zu häufig. Bin dankbar für jede Idee von Euch.
stoney wrote: > Und meiner Erfahrung nach treten Bitfehler mit 10^-6 Wahrscheinlichkeit > auf, bei mir viel zu häufig. Ähmmm - du kriegst über eine ISM Funkstrecke einen Bitfehlerrate von 1ppm und bist unzufrieden? Probleme gibt's... Stichwort heisst hier: fehlerkorrigierenden Code verwenden.
Gruß, nein nein nicht 1ppm bei mir... Ich meinte nur ich erwarte eine Fehlerrate in dieser Größe. Meine liegt bei circa 1 Fehler pro 10 Zeichen (80 bit). Das ist mir zu hoch! Eigentlich würde ich gerne von Euch wissen, ob das für die beschriebene Strecke als normal anzusehen ist oder ob da was falsch läuft... Da das Datenformat ja 8n1 und fest ist, kann ich nicht mit Redundanz oder Parität arbeiten ohne den Protokoll Standard zu verletzen. Ich bekomme zwar ne Prüfsumme mit aber die sagt mir ja nur das was falsch ist. @Andreas: woran genau denkst du da? (ich arbeite gerade an einer Software-Lösung die mir mit Hilfe von einer Maske die ich vorgebe (an Stelle x muß eine Ziffer stehen...) den String überprüft und wenn ein Fehler gefunden wurde mit einem gepufferten gleichen String (da alle 1s der neue Datensatz aus dem GPS kommt) vergleicht und ersetzt))
Wie gross ist die Entfernung ? Ich habe etwa 1 fehlerhafte Uebertragung alle 1kByte bei 10m quer durchs Haus mit 20kBaud.
Hast Du genug Taktwechsel im Code? Oder ist es sowieso Manchester codiert? Ansonsten kannst Du doch vor dem Funkkanal Redundanz einfügen und damit Fehler nachher herausrechnen. Braucht zwar u.U. noch einen uC vor dem Funkmodul - aber wenn es Dir so wichtig ist, wird es anders nicht gehen. Viele Grüße, Martin L.
Gruß, erstmal danke für Eure Antworten. @Benedikt: also die Entfernung über Kabel ca. 30m Sende mit ca. -10dbm. Habe das ganze schon mal mit 60dB gedämpft da war immer noch die gleiche Fehlerrate wie wenn ich ein 1m langes Kabel verwende. (Kabel ist ein 50 Ohm Koaxkabel mit SMA-Steckern). Hast du noch irgendwelches schaltungstechnischen Aufwand betrieben? Sendest du mit Präambel jedes Byte einzeln oder auch so wie ich einen kontinuierlichen Datenstrom von extern? @Martin: Also USART bzw. EIA-232 ist NRZ kodiert. Wenn ich mir meine Daten anschaue sind da reichlich Pegelwechsel vorhanden. Sender und Empfänger haben ja die selbe Datenrate mit der sie das Signal abtasten da geht, glaube ich, nichts verloren. Wenn daß so wäre, müsste ich mit bestimmten Zeichenfolgen (viele Nullen) ja den Fehler reproduzieren können. Er ist aber zufällig verteilt. Der uC ist schon vom initialisieren vorhanden (PIC 16FXX) und könnte auch benutzt werden... werde mal überlegen was sich da machen lässt. falls noch jemand mit ähnlichem Aufbau arbeitet: Ich bin an Euren Fehlerraten interessiert und an Euren Erfahrungen im Umgang mit Bitfehlern.
stoney wrote: > also die Entfernung über Kabel ca. 30m Nur damit ich das richtig verstehe: Du hast die RFM ueber Kabel verbunden, nicht per Funk ? > Hast du > noch irgendwelches schaltungstechnischen Aufwand betrieben? Sendest du > mit Präambel jedes Byte einzeln oder auch so wie ich einen > kontinuierlichen Datenstrom von extern? Ich sende die Daten direkt ueber das RFM12, ganz ohne Manchester oder aehnliches. Nur nach einem Byte mit dem Wert 0x00 oder 0xFF wird 0xAA gesendet, damit nicht ueber laengere Zeit keine Pegelwechsel vorhanden sind. UART hat ja mindestens 2 Flanken auf 10bit, das sollte eigentlich reichen.
Hallo, bin auch etwas verwundert. 4800 Baud gehen über 30m auch mit Klingeldraht und RS232 Pegel ohne Fehler... Welchen Sinn soll da eine HF-Übertragung haben? Gruß aus Berlin Michael
Ja Ihr habt mich richtig verstanden. Ich sende mit dem RFM über Kabel, der Sinn mmh... also ich übertrage das SAT-Signal vom meiner Antenne (mit ZF ca 950 bis 2GHz) auf einem Kabel mit dem GPS Träger von 433 MHz. Das ganze geht dann runter zu mir und wird dort wieder in SAT+GPS zerlegt. Aber da ich momentan ja nur GPS mit dem RFM übertrage und noch gar keine SAT-ZF dazu, kommt es nicht zu Störungen durch Überlagern der Bänder. Mal zu den RFM01/02 Einstellungen, vielleicht hab ich da was falsch verstanden: RFM02(Sender) gleiche Frequenz und Baudrate wie RFM01, Sendeleitung eben so das ca. -11dbm rauskommen, +/- 90 KHz Modulationsabstand vom Träger, Clk für PIC 10Mhz, 15pF load Kapazität, Sleep, Power und Wake up erstmal aus, TX bit sync brauche ich ja für den Übertragungsmodus nicht? RFM01(Empfänger) gleiche Frequenz und Baudrate wie RFM02, 200 Khz Bandbeite, RSSI- Schwelle bei -61 (LNA Gain 0), Wake up/low duty erstmal aus, AFC aus, Digitales Filter ohne clock recovery und ebenso 10 Mhz und Kapazität wie oben. Grüße!
Bastel mal ein Dämpfungsglied rein. Ich vermute Du mutest dem Empfänger einen viel zu hohen Pegel zu ...
Hallo, irgendsowas hatte ich geahnt, macht Sinn... ;) Ansonsten würde ich auch Übersteuerung des Empfängers vermuten, die Kabeldämpfung ist ja merklich kleiner als die Dämpfung über eine Luftstrecke. Gruß aus Berlin Michael
Gruß, @Michael: Das klingt schon logisch an Übersteuerung hab ich auch schon gedacht, werde auf jeden Fall mal mit der Dämpfung experimentieren... Mir stellt sich jedoch die Frage: Wo kommen die Bitfehler den her? Die Modulation verhindert definitiv Bitverfälschungen auf dem Weg zum Empfänger. Und vor dem Sender bzw. hinter dem Empfänger hab ich nur noch einen MAX232 Wandler für die TTL-Pegelanpassung. Also: Sender oder Empfänger sind die wohl die Fehlerquelle. Ist der VCO der PLL zu langsam oder wie? Hat da jemand von Euch ne Idee wo die Fehler liegen?
Hallo, vom Prinzip sind die Funkmodule auf Daten angewiesen, die möglichst keinen Gleichspannungsanteil haben. Deshalb Manchester-Codierung o.ä. Wenn Du normale UART-Daten schickst und z.B. eine 0 sendet, dann gibt es nur eine H/L-Flanke am Begin des Startbits, dann ändert sich über alle Bitzeiten garnichts bis das Stopbit beginnt. In dieser Zeit konnen Regelung, PLL, was-weiß-ich machen, was sie wollen. Auch durcheinanderkommen... Vielleicht wäre eine primitive Modulation einfacher gewesen, Oszillator mit den UART-Daten tasten ond zum Empfang einen NE567? Frequenz irgendwo bei 200-300kHz? Allerdings weiß ich nicht, ob da Filter nötg werden, falls Sat-Receiver/LNB/Multiswitch diesen Bereich noch kurzschließen. Gruß aus Berlin Michael
Gruß, @Michael: im Prinzip verstehe ich ja worauf du hinaus willst. Jedoch tritt dieses Problem bei jedem Zeichen auf. Wenn ich also vor dem Empfänger einen Rechner, und nach dem Sender einen Rechner über UART mit den Modulen verbinde und über HyperTerminal einfach mal ein Zeichen (ASCII) mit vielen Bitwechseln schicke kommen die selben zufälligen Fehler wie wenn ich Zeichen mit wenig Flankenwechsel schicke. z.B: "j" (01101010) selbe Fehlerrate wie "0" (01100000) und das mit zufälligen Abständen zwischen den Fehlern.
Bei zu großen Leistungen am Empfänger kommt es durch Nichtlinearitäten zu der sogenanten Intermodulation. Besonders schilmm sind die Intermodulationsprodukte dritter Ordnung. (Hat was mit der aproximation der Nichtlinearität in einer Taylorreihe zu tun.) Diese verfälschen das Signal und verschlechtern das SNR. Und das erhöht dann wieder die Bitfehlerwahrscheinlichkeit. Viele Grüße, Martin L.
Sendest du immer nur jeweils ein Zeichen, oder mehrere hintereinander ? Wenn du immer nur eines schickst, dann liegt das ganz einfach daran, dass sich der Empfänger erst auf das Signal einstellen muss, da dieser ein Hochpass eingebaut hat. Versuche also mal mehrere Zeichen direkt aufeinander zu schicken, und schau ob dann immer noch in jedem Zeichen Fehler auftreten.
Gruß, nochmals Danke für Eure Hilfe, @Martin: Das Intermodulationsproblem ist mir bekannt, ich werde mal schauen ob ich mit Dämpfung etwas erreichen kann. @Benedikt: Nun das kommt auf die Definition von "direkt aufeinander" an ich habe die Wiederholrate der Tastatur schon mal mit langsam und schnell ausprobiert und dann einfach eine Taste gedrückt gelassen. Folge: keinerlei Veränderung sowohl bei ca. 1 Zeichen pro Sekunde als auch ei max. Geschwindigkeit treten die Bitfehler mit gleicher Verteilung auf. Wie gesagt ich werde mit der Dämpfung vom Empfänger nochmal etwas rumspielen, vielleicht bringt das ja doch was. Ich melde mich sobald ich was rausgefunden habe!
stoney wrote:
> Nun das kommt auf die Definition von "direkt aufeinander" an
Direkt aufeinander heißt: Direkt nach dem Stopbit eines Zeichens kommt
Lückenlos das Startbits des nächsten Zeichens.
Wenn du die per Hand sendest, dann ist das viel zu langsam.
Gruß, Problem gelöst. Nach 3 Tagen probieren habe ich die Frequenzauslenkung des Senders mal auf 60 Khz reduziert, und siehe da, es funktioniert fehlerfrei. Vielen Dank an alle die sich um mein Problem gekümmert haben. Ihr wart echt SUPER! P.S.: Da ich in der Firma die entsprechenden Messgeräte habe --> falls jemand irgendwelche Verläufe oder Graphen von dem RFM01/02 braucht einfach hier anfragen.
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.