www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RFM12 sendet nicht richtig


Autor: Matthias D. (marvin42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo auch,

vielleicht ist mein Problem kein neues, aber in über 1000 RF12-Beiträgen 
ist mir das evt. entgangen...

Ich verwende einen ATtiny45 an einem RFM12B-868 Modul zum Senden von 16 
Bytes (zB 0123456789ABCDEF). Der Empfänger (ATmega8 mit RFM12) empfängt 
aber die 16 Bytes verstümmelt (zB 01.456..AB.F....) - so als kämen die 
Bytes schneller als der Empfänger sie auswerten könnte, ich verliere 
mittendrin einzelne Bytes. Ich benutze Software-SPI bei 4800 bps, beide 
verwenden FIFO.

Über einen anderen Thread kam ich auf die Idee, dass ich die Datenbits 
evt. genau mit 4800 bps in den RFM12 hineintakten muss, damit der 
Empfänger das auch versteht - also schnell ein paar NOPs in den Code 
geschummelt, mit dem Oszi kontrolliert und siehe da, der Empfänger sieht 
plötzlich (fast immer) den richtigen Bytestrom.

Dann hab ich im Datenblatt gelesen, dass o.g. Vorgehen aber nur den RF01 
betrifft, nicht aber den RF12, weil dieser ein TX-Senderegister hat. Nur 
scheint das bei mir nicht zu funktionieren. Inzwischen habe ich eine 
ganze Menge an verschiedenen Einstellungen probiert, aber ohne Erfolg.

Kann mit jemand dabei weiterhelfen ? Beachtet der RF12 beim Senden die 
programmerte Datenrate, oder nicht ? Aus dem Datenblatt von Hope werde 
ich nicht schlau,

schon mal Danke vorab
Matthias

Autor: markusj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

ich habe längere Zeit mit dem RFM01 und RFM02 gekämpft und dabei auch 
viel in den Datenblättern des RFM12 gewälzt.
Du hast es im Grunde schon selbst gesagt: Die RFM12 haben einen FiFo, 
wenn du den benutzt solltest du normalerweise keinen abreißenden 
Datenstrom bekommen.
Auf welchen Wert hast du den FiFo-Level eingestellt? Typischerweise 
stellt man den auf 8 Bits und schiebt dann immer ein Byte nach dem 
anderen zum Funkmodul.
Falls du keine extremen Timing-Probleme hast, würde ich darauf Tippen, 
dass du evtl. Probleme bekommst weil dein Mustersignal zu wenig 01 bzw 
10 Flanken aufweist - wobei 4800 Bit/s da eher unproblematisch sind.
Ach ja, darüber stolpere ich gerade: Dein SPI läuft auch auf 4800 Bit/s? 
Dann könntest du unter Umständen Aussetzer durch einen leichten 
Zeitversatz bekommen. Warum drosselst du dein Soft-SPI so stark?
Laut Timing-Spezifikation für die SPI-Schnittstelle könnte dein SPI-Takt 
theoretisch bis zu 20 MHz betragen.
Inwiefern sich das mit der Spezifikation "FiFo-Zugriffe mit max. 
f_res/4, also 2,5 MHz" verträgt, ist mir schleierhaft, aber selbst mit 
2,5 MHz bist du weit jenseits von 4800 Bit/s

mfG
Markus

Autor: R. W. (quakeman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias du solltest dir das Leben einfacher machen und nicht versuchen 
vom Controller genau mit 4800 Bps die Daten an den RFM12 zu schicken. 
Der RFM12 besitzt für soetwas eine busy Abfrage, welche du nach jedem 
gesendeten 16Bit Wert einfach abfragen kannst. Sobald er nicht mehr 
beschäftigt ist kannst du den nächsten Wert schicken. Denn sobald dein 
Timing auch nur im geringsten schneller ist kommen solche Fehler 
zustande wie du sie beschrieben hast.
Ich verwende mit busy Abfrage als SPI Takt zum RFM12 460kBps ohne 
Probleme und ohne Datenverlust.

Die einfachste Methode ist direkt auf SDO (MISO) zu prüfen. Der Ablauf 
ist recht simpel:
1. NSEL = 0 zum aktivieren des RFM12
2. 16Bit Wert an RFM12 senden
3. Warten bis SDO=1 (Solange SDO=0 ist der RFM12 beschäftigt)
4. wieder bei 2. anfangen
5. Sobald fertig NSEL = 1 zum deaktivieren des RFM12

Ciao,
     Rainer

Autor: Matthias D. (marvin42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer: danke für den Hinweis, das hat mir geholfen. Im Prinzip 
war mein Code ok, aber der Compiler hatte eine while(..)-Anweisung 
wegoptimiert, weil ich ein _volatile vergessen hatte ...

Ich habe mir nochmal das RF12-Datenblatt durchgelesen (das 'neue', das 
weniger Fehler hat) und anstelle nach dem Senden auf SDO zu warten, 
prüfe ich vor dem Senden nIRQ und warte ggf - das funktioniert erst mal.

Matthias

Autor: R. W. (quakeman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias D. schrieb:
> Hallo Rainer: danke für den Hinweis, das hat mir geholfen. Im Prinzip
> war mein Code ok, aber der Compiler hatte eine while(..)-Anweisung
> wegoptimiert, weil ich ein _volatile vergessen hatte ...
Das ist dann natürlich ärgerlich. :)

> Ich habe mir nochmal das RF12-Datenblatt durchgelesen (das 'neue', das
> weniger Fehler hat) und anstelle nach dem Senden auf SDO zu warten,
> prüfe ich vor dem Senden nIRQ und warte ggf - das funktioniert erst mal.
Gibt es von dem Datenblatt mal wieder eine neue Version?
Also ich habe mir immer gleich das Datenblatt von dem IA4420DS 
angeschaut, da dies der verbaute Chip ist. Die Datenbläter von HopeRF 
fand ich nie sehr gut. Aber wenn es da mal wieder ein neues gibt würde 
ich da auch mal reinschauen.

Ciao,
     Rainer

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.