mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RFM02 die Xte


Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann liegt es wohl am Sender, den du zu früh stoppst, denn dieser hat 
ein 16bit FIFO.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Sender hat doch aber kein FIFO

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ausserdem sende ich im dauerbetrieb...
hab auch mal paar bitkombinationen ausprobiert immer das letzte bit.

MfG

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zum verständnis, es ist immer bit0 also das 8. von links

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eventuell ein Timingproblem beim Sender, dass dieser nicht nachkommt?

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sende auch immer nur ein byte

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeig mal deinen Code mit dem du den Empfänger ab und wieder ein 
schaltest.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also für rjmp prog2 stand als es nich ging, rjmp prog1

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian Patzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian Patzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die höchste Verstärkung ist 0. -14 usw. sind niedriger. Bei RSSI ist der 
kleinste Wert (also -103) am empfindlichsten.

Autor: Florian Patzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok danke. was für Übertragungsprotokolle empfehlen sich denn bei der 
ganzen sache zwecks Sicherheit?

Autor: Christian J. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, war für RFM01 (Sender) aber vielleicht hilft es. Ich benutze 
sonst nur RFM12.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das ist nicht normal.

Autor: Florian P. (eckel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal mei code vom empfänger

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hatte mein oszi dran hängen und ohne clk hat sich nich wirklich viel 
getan

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so hab jetz 3 nops eingefügt jedoch hat sich nix verändert

Autor: Florian P. (eckel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier nochmal der sender

Autor: Florian P. (eckel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und die aktuelle des empfängers

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Florian P. (eckel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du musst das aktuelle programm nehmen welches ich zuletzt gesendet hab

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aha
also am besten den fifo erst zurücksetzen wenn meinetwegen ein 
end-statement empfangen wurde

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat sich erledigt, hab d nfehler gefunden.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir jemand ne codierung oder andere verfahren empfehlen um die 
fehlerquote gering zu halten oder ist das nicht zwingend notwendig.

Autor: Florian P. (eckel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.