Hallo Leute, ich weiß man kann im Forum auch suchen doch trotz das ich dies getan habe konnte ich nix zu meinem Anliegen finden... Ich wollte einfach mal wissen wie ich erkenne das das Empfangsmodul was empfangen hat? Also soweit ich weiß ist der VDI Pin ja für die Qualität der Funkverbindung, wenn man in auf RSSI gestellt hat, da hab ich auch wie im Datenblatt beschrieben ein High Signal. doch bekomme ich weder einen Interrupt, noch irgendein zucken am FFIT Pin... Wie gesagt wäre froh wenn mir mal jemand die prinzipielle vorgehensweise zum erkennen von empfangenen Daten erklären könnte. MfG Flo
Meine Frage hat sich erübrigt. Meine Funkstrecke regt sich zumindest schonmal, jedoch kommte es meiner Meinung nach noch zu einem zu großen Datenverlust. Kann mir jemand einen Tip geben wie ich diesen Datenverlust bzw. das Empfangen von "Müll" verringern kann? Wäre eine Manchester Codierung solch eine Methode? MfG
Ich glaube Du hast den RFM02 noch nicht ganz verstanden. Jeder Empfänger empfängt Müll, weil er den nicht unterscheiden kann. Aber 0xD44D öffnet den Fofo Stack beim RFM02. Benutze den nur im Fifo Mode und reduziere LNA Gain etwas, dann hast Du solche Sorgen nicht.
Also die Sache mit dem Sync Word hab ich schon drin und das funktioniert auch. Schalte ich den Sender aus und resete den Empfänger bleibt der FIFO leer aber mit dem LNA das werd ich mal versuchen. Noch was und zwar kann ich meinen Empfänger nicht mehr starten wenn ich ihn einmal den RX Mode deaktiviert hab auch wenn ich die komplette anfangsinitialisierung nochma durchlaufen lass. MfG
Also der LNA Gain war bei mir auf Null und hab alle werte ausprobiert, doch hab ich immernoch das selbe Problem... Mir ist aber aufgefallen das es immer das letzte bit ist welches falsch übertragen wird.
Dann liegt es wohl am Sender, den du zu früh stoppst, denn dieser hat ein 16bit FIFO.
Ausserdem sende ich im dauerbetrieb... hab auch mal paar bitkombinationen ausprobiert immer das letzte bit. MfG
Also nochmal zu meinem Aufbau ich sende im dauerbetrieb und frage den empfänger-fifo auf inhalt ab das ganze läuft in ner schleife. wenn jetzt was im fifo ist dann hol ich das erste byte und löse mit dem pin vom µc ne negative flanke aus welche ich als triggerung für mein oszi nehme welches dann die daten am sdo pin aufzeichnet. ist das erste byte draussen lass ich ihn in ner endlosschleife anhalten. wenn ich den Controller resete dann wartet er wieder auf das erste byte.
Stimmt. Irgendwie komme ich mit dem Sender und Empfänger durcheinander, vor allem da hier die ganze Zeit über den Empfänger geredet wurde. Haben deine Daten zufällig viele 0en oder 1en am Stück?
teils teils an sowas hatte ich auch schon gedacht darum hab ich mal 0x55,0xaa,0xff,0xf1 geschickt und is immer das gleiche. die ersten 7 bits hauen hin und das letzte kommt an oder nich an, wenn ich das untere nibble auf null setze dann kommt auch manchmal ne 0 oder eins beim letzten bit.
Hab mal diese Schleife angehängt bis er den nexten stream anhängt und trotzdem kommt das gleiche problem. ldi r22,0xff ldi r23,0xff ldi r24,0xff prog2: dec r22 brne prog2 dec r23 brne prog2 dec r24 brne prog2 oder was meintest du mit timing?
Hab grad ma noch ein 2. byte angehängt und da funktioniert es, das erste byte wird 1a erkannt sollte wahrscheinlich noch am ende einen Dummy-Befehl hinterherschicken nach dem ende des Streams Hast du noch nen Tip wieso mein empfänger nachdem er abgeschaltet wurde nich sich nich mehr starten lässt?
prog1: cbi portb,chip_select ldi data,0xc0 ;Reciever Setting Command rcall funk_data ldi data,0xe1 rcall funk_data ldi data,0xce ;Output and FIFO Mode Command rcall funk_data ldi data,0x89 rcall funk_data ldi data,0xce ;Output and FIFO Mode Command rcall funk_data ldi data,0x8b rcall funk_data sbi portb,chip_select rcall fifo_test sbrs ctrl,fifo rjmp prog1 ldi temp,1<<fifo eor ctrl,temp sbi portb,chip_select ldi data,0xc0 ;Reciever Setting Command rcall funk_data ldi data,0xe0 rcall funk_data sbi portb,chip_select prog2: rjmp prog2
Von den Befehlen her sieht es gut aus. Nur eines würde mich stören: Du sendest mehrere Befehle ohne CS zwischendurch auf high zu legen. Dem Timiningdiagramm im Datenblatt nach setzen die immer CS nach jedem übertragenen Befehl auf high. Keine Ahnung ob man das muss, dem Datenblatt nach würde ich sagen ja.
ich werds mal ändern evtl. kanns ja daran liegen, werde dann mal bericht erstatten. Denke aber mal das die Sache mit dem Dummy-Byte interressant sein dürfte. Danke übrigens. MfG Flo
Hallo kann mir jemand erklären was LNA Gain, Bandbreite, RSSI, AFC und Data Filter eigentlich macht? Und wie errechnet ihr die Datenrate, komm da nich wirklich auf nen brauchbaren Wert... Hoffe ihr könnt mir das Erläutern damit ich auch mal verstehe was für Vorgänge in dem Mini Teil vorgehen. MfG Flo
Du redest jetzt vom RFM01? LNA Gain ist der Verstärkung des Eingangsverstärkers. Höhere Verstärker -> empfindlicher (aber auch empfindlicher gegenüber Störungen) Bandbreite ist eben Bandbreite. Für höhere Datenraten muss der Wert größer werden, allerdings ist der Empfänger dann empfindlicher gegenüber Störungen RSSI gibt die Signalstärke des empfangenen Signals an. RSSI Threshold gibt einen Mindestwert an, der erreicht sein muss ehe das Modul Daten akzeptiert. AFC stellt die Empfangsfrequenz automatisch an. Allerdings kann man hier auch schön Mist bauen, das sich das Modul aufhängt, wenn man diesen Modus falsch konfiguriert.
ok klingt plausibel. ist -14 oder -20 eine höhere Verstärkung? Bei RSSI was ist dort hoch -103 oder -61? Ja geht um das RFM01 Modul
Die höchste Verstärkung ist 0. -14 usw. sind niedriger. Bei RSSI ist der kleinste Wert (also -103) am empfindlichsten.
ok danke. was für Übertragungsprotokolle empfehlen sich denn bei der ganzen sache zwecks Sicherheit?
Hier hast Du einen getesteten C Code von mir, müsste verständlich sein. Vielleicht findest Du den Fehler. Du musst unbedingt ein paar Dummy hintersenden, damit der Fifo durchrutscht.
Sorry, war für RFM01 (Sender) aber vielleicht hilft es. Ich benutze sonst nur RFM12.
Also hab jetz noch ein neues Problem und zwar wird immer nur das erste Byte gesendet, das 2. kommt gar nich erst beim Empfänger an. Erst wenn ich das 2. Byte nach einem erneutem Sync. Word sende also als erstes byte wird es erkannt. Ist das normal???
habs vorher so gemacht das ich das FFIT Bit abgefragt hab und sobald das wieder 0 wurde hab ich den fifo gelöscht um wieder auf das sync. word zu warten doch es ist immer nur ein byte angekommen
rfm_receive1: sbi portb,clock cbi portb,clock inc temp cpi temp,16 brne rfm_receive1 rcall fifo_in Der Clock Impuls ist da sehr kurz. Laut Datenblatt darf der Takt maximal 2,5MHz betragen, wie symmetrisch das CLK Signal (beim Lesen des FIFOs) sein muss steht leider nirgends im Datenblatt. Versuch da mal noch ein paar nops zwischen sbi und cbi reinzumachen. fifo_test: cbi portb,chip_select cbi portb,data_out sbi portb,clock ldi temp,1<<fifo_full sbic pinb,data_in or ctrl,temp cbi portb,clock sbi portb,data_out sbi portb,chip_select Wieso sendest du da 1bit? Lass die CLK Leitung am besten auf Low liegen, das reicht um das FFIT Bit zu lesen.
So hab da mal noch ne Frage und zwar, mir is mit dem oszi aufgefallen das obwohl kein sync word mehr gesendet wird werden daten im fifo erkannt. auch nachdem ich den fifo resettet hab... woran kann das liegen?
Angehängte Dateien:
-
RFM01.GIF
12 KB
Hab zum besseren Verständnis und evtl. besseren Hilfe noch was
vorbereitet.
wenn ich diese daten sende
ldi data,0xaa
rcall tx
ldi data,0xff
rcall tx
kommt am sdo pin nur das 0xaa an und danach ist der pin noch für ca 20µs
auf high versteh das nich das 2. byte wird aber irgendwie nich erkannt
denn wenn ich dann den fifo abfrage ist der angeblich leer
nach dem 8 takten kommt die abfrage des fifo standes, und die hinteren
takte sind von der init des fifo.
MfG Flo
Florian Patzer wrote: > kommt am sdo pin nur das 0xaa an Du meinst SDI? Also AVR -> RF01? Ist das die TX Funktion die aufgerufen wird? Falls ja, dann vermisse ich da einen Takt. tx: ldi serial,0x80 tx1: push serial and serial,data cbi portb,data_out breq tx2 sbi portb,data_out tx2: sbrs ctrl,send rjmp tx2 ldi temp,1<<send sbrc ctrl,send eor ctrl,temp pop serial lsr serial brne tx1 ret
nein ich meine sdo denn ich lese ja den fifo vom rfm01=receiver aus. ein takt ist bei tx nich notwendig, ich nutze den vom irq pin.
Achso, jetzt versteh ich wie du das gemeint hast. Du sendest 0xAA am Sender, und das Bild zeigt das Signal am Empfänger. Wenn ich das richtig sehe, dann fragst du mit rfm_receive ja auch nur 1 Byte ab.
das ist richtig aber nachdem ich das erste byte abgeholt hab, frage ich den fifo status erneut ab wenn der immernoch voll ist dann frage ich da nächste byte ab oder ist das falsch? Nur dummerweise ist nach dem ersten byte der fifo immer leer. MfG Flo
wenn ich mir den sdo pin anschaue(gelb) dann ist der nach den 8 takten auf high. wenn ich jetzt als 2. byte anstatt ff hex 00 hex schicke dann sieht dieser block ---> ähnlich wie der peak rechts daneben aus
Das ist deine Empfangsschleife, oder? prog2: rcall fifo_test sbrc ctrl,fifo_full rcall rfm_receive sbrc ctrl,fifo_init rcall rfm_receive_init rjmp prog2 Was ich momentan nicht ganz verstehe: Woran erkennt die Software, dass ein rfm_receive_init aufgerufen werden muss?
Ja genau. Wenn du in das u-Programm fifo_test schaust da siehst du die abfrage des sdo pins. wenn der null ist dann springt da programm zu fifo_test1 und überprüft ob vorher der fifo voll war, wenn ja dann wird das init bit gesetzt. Das hat die bewandtnis das nicht jedes mal wenn der fifo als leer erkannt wird die init gestartet wird sondern nur nach einem empfang.
Das heißt, wenn einmal das FIFO leer ist, wird es zurückgesetzt? Aber das ist doch immer der Fall, denn nach einem gelesenen Byte muss der Empfänger erst mal das nächste Byte empfangen.
aha also am besten den fifo erst zurücksetzen wenn meinetwegen ein end-statement empfangen wurde
so hab das jetz mal geändert, nur kommt nich das richtige an... So ein ******. naja weiter probieren. haste evtl. noch ne ahnung woran das liegt das das nächste byte nicht korrekt übertragen wird?
Kann mir jemand ne codierung oder andere verfahren empfehlen um die fehlerquote gering zu halten oder ist das nicht zwingend notwendig.
Ahoi, bin nach ein paar tagen ruhe auf ein erneutes problem gestoßen, und zwar wir jeder 2. datenstream(6byte) falsch übertragen. Nun wollte ich in erster linie ersteinmal erfahren ob das bei diesen modulen die regel ist oder ob ich meine module falsch eingestellt hab
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.