Hi Leute ich weiß es gibt unzählige Beiträge zum RFM aber ich komm
trozdem nicht hinter mein Problem.
Also wie schon gesagt empfange ich nichts, mein Sender klappt auf jeden
fall das weiß ich.
Im Anhang ist der Schaltplan
> Also wie schon gesagt empfange ich nichts
Was hast du denn schon versucht um doch etwas zu empfangen?
> mein Sender klappt auf jeden fall das weiß ich.
Woher weist du das?
ich hab mir von einem freund eine fernbedinung ausgeliehen die mit dem
RFM12 läuft, und die funktioniert bei ihm, daher weiß ich das, und den
code davon hab ich auch.
Du solltest mal den Code aufräumen..:
> DDRD |= (1<<RFXX_DATA);> DDRD &= ~(1<<RFXX_NIRQ);
^- das ist in der init() besser aufgehoben, wobei sich mir der Sinn von
DATA noch nicht recht erschliesst. Laut Schaltplan (und wenn ich mich
recht erinnere, dann auch laut Erinnerung) ist das dauerhaft auf High
gezogen.
> while(1)> {> while(!(PIND&(1<<RFXX_NIRQ)))//wartet darauf das RFXX_NIRQ gelöscht ist
^- das schreit geradezu nach einem aussagekräftigen Makro
:-)
> {> RF_RXBUF[i++]=RF01_RDFIFO();//lese FIFO Daten> uart_putc(RF01_RDFIFO());
^- ?? sollte da nicht "RF_RXBUF[i-1]" (Achtung
Array-Grenzen!!!!) stehen?
Deklaration und Definition von RF_RXBUF hab ich nicht gefunden, kann Dir
also nicht sagen, ob die while-Bedingung im Kontext sinnvoll ist. Das i
wird auch nicht zurückgesetzt, das hat am Anfang obiger while-Schleife
noch den Wert 5 - ist das beabsichtigt??
HTH
der code ist der beispiel code von pollin an dem ich eigentlich nur die
pins geändert habe, mit RFXX_DATA geb ich dir recht mir auch nicht
schlüssig wozu das da sein soll, denn der ist nicht angeschlossen oder
sonst was.
RF_RXBUF ist in der define.h daklariert.
So, ich hab mir mal den Code von Pollin [1] angesehen, da gibts
tatsächlich ein Beispielprogramm..
> mit RFXX_DATA geb ich dir recht mir auch nicht schlüssig wozu das da> sein soll, denn der ist nicht angeschlossen oder sonst was.
Laut deren Pinout ist er angeschossen.. Bei Dir nicht. Hab eben mein
Modul rausgekramt (868MHz), dort ist er (so wie bei Dir) per Pullup auf
+Vcc (und es funktioniert) -> im Code entfernen.
>> Das i wird auch nicht zurückgesetzt, das hat am Anfang obiger while->> Schleife noch den Wert 5 - ist das beabsichtigt??
Ich mach mal die Ingrid nachdem Du nicht drauf eingegangen bist: Nein,
es ist nicht sinnvoll </WinkMitDemZaunpfahl> ;-)
In Deinem Code sind Sender und Empfänger (etwa.. siehe weiter unten) 5
Bytes Phasenverschoben. Wär schon ein großer Zufall, wenn die Checksumme
dann trotzdem mal passen würde..
Achja nochmal die Ingrid: Das mit dem doppelten FiFo-Lesen ist natürlich
auch Mist. Dein Code bewirkt etwa folgendes:
1. Die Phase um 5 Bytes verschieben (am Anfang)
2. Das erste Byte aus dem FiFo lesen und an der sechsten(!) Stelle
Speichern
3. Müll aus dem wahrscheinlich noch nicht wieder vollständig gefüllten
FiFo lesen und über uart verschicken.
4. Warten auf neue Daten
5. Das zweite Byte (respektive Müll - gerne bitweise Phasenverschoben,
falls bei 3. schon wieder ein paar 'echte' Bits im FiFo waren) aus dem
FiFo lesen und an siebter(!) Stelle speichern.
6. Wieder Müll über uart schicken..
7. D.C.ad.lib.
HTH
[1] http://www.pollin.de/shop/ds/MjU5OTgxOTk-.html - Downloads zu
RFM01-433
> Also ist der Code eigentlich völliger müll wenn ich das richtig verstehe
Depends. Der von Reichelt funktioniert afair. Abgesehen von der geräte-
und anwendungsspezifischen Initialisierung kann man den schon nehmen zum
Testen. Nur hast Du ein paar Copy/Paste-Fehler reingebaut, die das
Erfolgserlebnis erstmal erfolgreich verhindern. Aber nicht aufgeben, der
hardwarenahe Teil sollte ja klappern, der Rest wird schon noch.
Achja eine etwas ausführlichere Doku zu den Chips gibts beim Hersteller
[1] s.v. RF01 und RF02 (ohne 'M'), hat mir damals doch weiter geholfen
:-)
HTH
[1] http://hoperf.com/
ja danke die hab ich auch schon gefunden :)
aber ich wollte erst mal den von pollin nehmen weil da alles in c ist
und in dem anderen ist aich asm drin das hätet mich verwirrt.
Ich werds mal weiter versuchen, aber angeschlossen hab ich doch alles
richtig oder also liegt der fehler auf jeden fall im programm.
Der Rest sieht gut aus so weit. Bau mal die angesprochenen Fehler aus,
dann sollte zumindest schon mal was ankommen.
Ich seh bei mir gerade im Code, dass ich bei den Kommandos 'fifo_off'
und 'fifo_on' die Werte 0xCE84 und 0xCE87 schicke (bei Dir: 0xCE88 und
0xCE8B). Schau nochmal ins Datenblatt, ob du wirklich 'reserved' haben
willst als fifo-fill-start-condition (★Zaunpfahlwinker★). Bei mir steht
das auf 'sync word' und es funktioniert einwandfrei :-) (Hint: Das
Syncword ist 0x2DD4). Kannst je nach Anforderung natürlich auch 'VDI'
oder 'always' nehmen. Nur 'reserved' würde ich mir für später aufheben..
;-)
HTH
also bei mir im daten blatt steht 0xCE88 und
0xCE8B. aber könnten wir vielleicht mal über icq oder so schreiben ich
denke das geht schneller schick mir wenn möglich einfach ne nummer oder
was weiß ich an (r e f l e x _ n o . 1 @ w e b . d e) natürlich alles
zusammen.
> also bei mir im daten blatt steht 0xCE88 und 0xCE8B.
In der Tat, es gibt eine neuere Version des Datenblatts.. und dort steht
geschrieben zum LSNibble:
1 0 x x fifo-fill-start-condition 'VDI & sync-word'
..gabs bei mir damals(tm) (Anfang April diesen Jahres) noch nicht.. Aber
man lernt ja nie aus :-)
HF beim Debuggen
also ich habe in meinem code jetzt mal RFXX_DATA gelöscht, und
uart_putc(RF_RXBUF[i-1]); benutzt, aber es tut sich nix, denn der müsste
mir doch eigentlich auch den "müll" anzeigen können, allso es sollte ja
wenigstens irgendwas kommen.
leider kommt aber nix
Tja, jetzt wirds langsam eng.. ein paar Kleinigkeiten hätt ich noch,
wenn das nicht hilft, dann heissts klassisch debuggen - mit dem Oszi
(auf SCK, SDI, SDO - ob sich da was tut) so anwesend, behelfsweise
'led-blinken in den Schleifen', 'uart-flooding bei Aktivität', ..
Was käme noch in Frage:
- startup zu schnell. Der Compiler könnte - abhängig vom
Optimierungsgrad - deine Delay_ms() wegoptimieren. Ich verwende
stattdessen die _delay_ms() aus <util/delay.h> (zzgl. F_CPU).
Zwischenfrage: Die uart-Nachrichten aus der Initialisierungsphase kommen
aber schon an, oder?
- erst 'Output' setzten, dann 'hi/lo'? ..bei mir immer in dieser
Reihenfolge, im Datenblatt zu $avr hab ich mal was dazu gelesen..
irgendwo.. in weiter Ferne.. könnte signifikant sein, kann mich aber
auch täuschen.. da müsste im Datenblatt zu Deinem AVR auch was drin
stehen..
- ich ziehe SDI regelmäßig auf low (am Anfang und am Ende von
write_command()), weiss aber nicht mehr genau, ob ich das wegen
Stromsparen eingebaut hab oder wegen der Kommunikation.
- achja wäre es denkbar, dass Sender und Empfänger auf unterschiedliche
Funkparameter eingestellt sind? Ich erinnere mich vage, dass sich die
Kommandos damals(tm) erheblich unterschieden haben für RFM01 und RFM02..
Viel Erfolg!
P.S.: Antennen sind schon eingesteckt, oder? ;-)
Moin!
Da fummeln ja noch andere an dem RFM01/02_Pärchen rum... :-)
[quote]In der Tat, es gibt eine neuere Version des Datenblatts.. und
dort steht
geschrieben zum LSNibble:
1 0 x x fifo-fill-start-condition 'VDI & sync-word'[/quote]
Beim Hersteller der Chips (Silicon Labs) steht das schon ziemlich lange
so drin.
Hope kauft die Chips bei Silabs und bastelt die auf ihre Module. Beim
Kopieren der Datenblätter schaffen es die Jungs tatsächlich, Fehler
einzubauen...also besser die Originale nehmen (TX = Si4020, RX =
Si4320).
Bei Silabs gibt es einiges an Literatur zu den Chips, z.B. ein recht
gutes Tutorial zum Ermitteln der geeigneten HF-Parameter. Ich finde es
sinniger, das zu lesen und die Datenblätter zu studieren (und
verstehen), als irgendwelche Konfig-Parameter aus dem Netz zu nehmen. Da
ist eine Menge Unfug unterwegs.
An den OP: versuche doch erstmal, den Fifo wegzulassen und zu sehen, ob
der VDI "schnackelt".
So weit habe ich meinen RFM01 jetzt.
Das Mistding wird bald aufgeben... :-)
Viel Glück!
Ralph
soo ich hab jetzt was anderes versucht
von hoperf gibt es ja auch codes die hat mein freund auch benutzt
ich hab den auch mal benutzt der code sieht auf jeden fall besser aus
aber leider passiert immer noch nicht so viel, kann es denn vielleicht
echt daran liegen das ich keine antenne habe ?
ich zeig mal den code.
Ad Drahtstummel: Ich hab meine noch nie mit ohne Antenne betrieben. Aber
ein guter Grund, dass es nicht geht wäre es auf jeden Fall :-)
Ad Silabs: Ui krass, endlich anständige Datenblätter :-) Das hat mich
damals(tm) vielleicht Nerven gekostet.. aber zum Laufen hab ich sie dann
doch noch hingeprügelt.. mit viel Trial and Error..
Ich bin dann mal Literatur wälzen :-)))) Besten Dank für den Hinweis
:-))
Nochmal ad Antenne: Ich hab (für 868MHz) sehr gute Erfahrungen gemacht
mit einem einfachen Stück Litze, 8.6cm lang direkt an das PCB gelötet.
Ein einfachster ƛ/4-Strahler halt :-) Und zum Testen sollte es sowieso
langen. (Bei 433MHz wären das dann etwa 17.3cm, nur der Vollständigkeit
halber)
So, jetzt aber zurück in den Datenblattstapel :-))
Also ich hab das datenblatt auch mal überflogen und gesehen das die in
der mindestbeschaltung nirq angeschlossen haben, was ich bei mir ja auch
habe.
jedoch wird es im code überhaupt nicht benutzt.
aber der muss doch immer auf low stehen wenn er etwas empfäng also muss
ich doch vor jedem empfangen den stauts low abwarten oder ?
[ nIRQ ]
Im ursprünglichen Code hast Du das benutzt (und ich habs angemosert ob
da nicht ein Makro hüpscher wär), in der neueren Version steht
stattdessen 'return falls SDO zu lange low '.. das sollte wohl auch eher
'warten auf nIRQ low' sein.
Eine Anmerkung möchte ich noch loswerden: Das Warten war in ersterem
Fall erfolgreicher gelöst. Genau genommen gehts aber noch etwas besser,
zumindest wenn man nicht realtime-artig auf eine 'Antwort' wartet:
- RX initialisieren
- RX FiFo zurücksetzen (z.B. mit Länge 8 Bit)
:warten_und_teetrinken
- irgendwann geht nIRQ auf low
- eine FiFo-Füllung abholen (z.B. 8 Bit)
- ein Datenpakt vollständig ? { selbiges verarbeiten; FiFo
zurücksetzen(!) } : nop
- goto warten_und_teetrinken
Das Warten kann man per busy-waiting totschlagen oder per IRQ (letzteres
hab ich an einem attiny2313 per PCINT nicht zum laufen bekommen.. aus
einem mir bisher nicht bekannten Grund hat der tiny den PCINT nicht
aufgezeichnet.. obwohl das Oszi die Pegeländerung sauber(tm)
protokolliert hat.. und falls er ihn doch mal mitbekommen hat, dann zu
langsam, da war die Millisekunde dann schon vorbei..)
HTH
ich hab gesehen das in dem code darauf gewartet wird das SDO auf low
geht, aber ich habs auch mal mit nIQR versucht leider klappt es nicht.
ich werde wohl echt mal versuchen ne antenne anzuschließen
so ich hab mal ne antenne angeschlossen
leider tut sich noch nichts, könnt ihr euch vielleicht noch mal den code
genau angucken und mir sagen was daran falsch ist, ich verzweifel
langsam echt.
wäre echt super
Kannst Du mal deinen vollständigen Code anhängen(!)? Wenn möglich
inklusive build-Skripten/Makefile/.. Ansonsten kann ich Dir anbieten,
dass Du mal meinen (alten) Code ausprobierst, der ist allerdings an ein
paar (wenigen, hier unwesentlichen) Stellen tiny2313-spezifisch.
Aber erstmal noch eine wichtige Frage zum Hardwaredebuggen: Hast Du ein
Oszi zur Hand? Schau mal auf SCK, SDI und SDO, ob sich da irgendwas tut.
Mit einem Multimeter kannst auch auf nIRQ schauen, ob das (bei zu
erwartendem Empfang) auf low geht. Falls sich am nIRQ nix rührt, dann
hast Du ein Problem mit dem Empfang (falsch konfiguriert,
Stromversorgung, ..aaah, da fällt mir grad was ein: Ich hab dem
RFM0[1,2] einen extra Elko (100u-universal-totschlag-Elko) spendiert,
obwohl (oder gerade weil?) die Stromversorgung aus einer Batterie
stammt. Und immer wenn was gekommen ist (über Funk), dann hat das RFM*
einen reset gemacht.. da bin ich aber erst mit dem Oszi draufgekommen..)
Wo war ich.. genau, also wenn sich an SDO was rührt, dann wär das schon
mal was. Wenn sich nIRQ bewegt und es tut sich nix an SCK (und SDI),
dann liegts sicher an der Software.
Viel Spaß beim messen :-)
zur hand hab ich leider keins, nur in der schule kann ich morgen aber
mal nach gucken (ja morgen ^^ tag der offenen tür) aber erstmal muss ja
der code stimmen :)
wegen dem resetproblem hab ich den reset pin über 10k an vcc, genau
damit der nicht fröhlich vor sich hin resetet.
den code kann mal anhängen ja.
Der erste böse Schnitzer war zwar schon mal angesprochen, ist aber
immernoch drin:
1
void rf01_rxdata( [..] )
2
[..]
3
while (!(RF_PIN&(1<<SDO)))
4
{
5
TimeOut++;
6
_delay_us(1);
7
if (TimeOut == 250)
8
return;
9
} // wait until data in FIFO
10
[..]
Du wartest als allererstes auf SDO, da kann aber nix kommen, solange du
kein SCK ausgibst. Korrekt müsste das etwa so heissen:
1
#define RFNIRQ_IS_HIGH() ( RF_PIN & (1 << IRQ) )
2
[..]
3
// busy-wait for nIRQ low
4
while (RFNIRQ_IS_HIGH())
5
{ [.. Timeout zählen oder auch nicht ..] }
Falls Du den timeout wirklich brauchst, dann kannst ihn natürlich auch
da in die Schleife reinpacken. Wobei 250µs schon recht kurz sind bei so
niedrigen Übertragungsraten: Wenn der Code 'richtig'(TM) ist und Du 9600
baud setzt, dann dauert die Übertragung eines einzelnen Bytes immerhin
(mindestens) 1/9600*8 Sekunden, da wären in Zahlen etwa 833µs(!). Bei
einem so kurzen Timeout würdest Du also höchstens immer das erste Byte
erwischen, der Rest wär noch nicht mal im Äther..
Das mit dem Elko(!) bei mir hatte übrigens keinen Zusammenhang mit einem
eventuell nicht vorhandenen Reset-Pullup (der ist sowieso obligat). Bei
mir hat das Funkmodul(!) resettet (und das hat als Folge gelegentlich
auch den tiny mitgezogen). Also einfach mal einen Elko dazustecken falls
Du alle anderen Fehlerquelle ausschließen kannst..
Noch zwei Verbesserungsvorschläge: In uart.c:
1
#include <avr/io.h>
2
#include <avr/iom8.h>
Das ist böse, korrekterweise steht da nur das Include für io.h, das muss
langen. Der Rest kommt automagisch via -mmcu=$typ.
Und in die Header-Dateien (*.h) macht man üblicherweise ein
1
#ifndef include_eindeutiger_dateiname_h
2
#define include_eindeutiger_dateiname_h
3
4
[.. Inhalt ..]
5
6
#endif // include_eindeutiger_dateiname_h
aussen rum, das spart versehentliche doppelte Includes mit u.U.
unverhersehbaren Nebeneffekten.
Viel Spaß mit dem Oszi morgen, aber korrigiere vorher noch obigen Bug!
HTH
so vielen danke erstmal das du dir überhaupt die zeit für das alles
nimmst :)
ich hab jetzt mal soweit ausgebessert, sieht bei mir jetzt so aus
1
#define RFNIRQ_IS_HIGH() ( RF_PIN & (1 << IRQ) )
2
[...]
3
while(RFNIRQ_IS_HIGH())
4
{
5
return;
6
}
das include iom8.h hab ich jetzt rausgekommen, ich hatte das nur drin
weil ich mit den UART probleme hatte aber naja jetzt ging das auf jeden
fall auch noch.
so aber da hatte sich nix getan
dann hab ich einfach mal verscuht hier bei dem if auch RFNIRQ_IS_HIGH()
reinzusetzten weil der da auch auf SDO=high gewartet hat, das ging aber
auch nicht dann hab ich diese sache wieder rückgängig gemacht.
Beim 'zweiten' ist das RFNIRQ natürlich fehl am Platze, schließlich
liesst Du da den SDO aus - der RFNIRQ ist nur der Anzeiger, dass was im
FIFO steht. Also wenn RFNIRQ low, dann ist was im FIFO, also SCK
rausschicken und FIFO reinlesen..
Was sagt das Oszi zum RFNIRQ? Bekommst Du da was? Bleibt er dauerhaft
high (dann hast Du keinen Empfang (Hardwarefehler, falsche
Konfiguration, ..))? Geht er auf low und bleibt dort (dann bekommt der
µC den Wechsel nicht richtig(tm) mit oder er setzt den FIFO nicht
korrekt zurück)? Was Du sehen willst (bei Dauersenden/-empfang) ist ein
schönes Rechtecksignal auf dem RFNIRQ. Alles andere ist (bei Verwendung
des FIFO) ein guter Indikator für die Fehlerstelle.
HTH und viel Spaß beim Debugg0rn :-)
Moin,
User schrieb:
> Was sagt das Oszi zum RFNIRQ? Bekommst Du da was? Bleibt er dauerhaft> high (dann hast Du keinen Empfang (Hardwarefehler, falsche> Konfiguration, ..))?
Hm, jein, man kann noch eine Stufe tiefer ansetzen und nur den VDI
begucken. Wenn der im Rythmus des Senders zappelt, wird schon mal etwas
empfangen. Der Nirq muß dann noch nicht klappen...in dem Stadium bin ich
jetzt (wieder).
Vor einiger Zeit war ich schon so weit, bis dann ploetzlich nichts mehr
ging. Heute fand ich die Ursache: ein Flachbandkabel vom Steckbrett zum
RFM-Adapter (beide Seiten ordentlich mit Steckern kontaktiert) hatte ne
Unterbrechung...grmpff&%&$§$&%&%§$!!
Was ich neulich vergessen hatte: bei http://www.controller-designs.de
gibt es ein paar nette Java-Tools (unter "Projekte") zum Umrechnen der
Parameter in Hex.
Inzwischen habe ich mir aber angewöhnt, die Parameter binär in den
Quelltext zu schreiben; finde ich übersichtlicher.
Viel Erfolg bei der Fehlersuche!
Ralph
</User>*Account anleg*<g457>
> [ ..] bis dann ploetzlich nichts mehr ging [..] hatte ne> Unterbrechung...grmpff&%&$§$&%&%§$!!
★eg★, das kenne ich.. ..Und Du wirst es kaum glauben, aber genau das
selbe ist mir jetzt auch passiert, als ich mein
RFM01-Labor-Testplattform-Platinen-Lochrasterkarten-Dings wieder in
Betrieb nehmen wollte - es ging genau garnichts. Muss sich wohl eine
kalte Lötstelle schlussendlich doch noch durchgesetzt haben. Zum Zwecke
des Schonens der eigenen Nerven hab ichs jetzt stattdessen auf einem
Brotbrett aufgebaut (und hey, es läuft bei 18.432MHz µC-Takt und
868kommairgendwas MHz Empfangsfrequenz einwandfrei). Vielleicht komm ich
die Tage mal dazu, des Delinquenten Quellcode auf meinen hiesigen Aufbau
zu portieren. Vielleicht hilfts ja.
Ad VDI: note to self: VDI verkabeln :-)
Hallo,
da dieser Thread ganz brandaktuell ist und genau mein Problem ist,
möchte ich mich kurz nach Eurer Erfahrung bekunden:
Aufbau RFM01 <-> RFM02 von Pollin
Ich nutze PIC-µC, aber trotzdem sollten die Teile ja laufen :-)
Mein Problem ist folgendes:
Sender sendet, Empfänger bekommt auf dem analogen Pin
(Filter-Kondensator RSSI (?)) auch ein Signal.
Aber er synct überhaupt nicht, das heißt der Empfänger stellt sich
eifnach tot: keine Daten am Fifo. Meine Einstellungen habe ich von
Benedikt in asm übertragen. SPI am Empfänger geht auch, habe 10Mhz am
CLK-pin.
Meine Frage: Woran könnte es liegen, wenn ich an besagtem Kondensator
nur die An-und Abschaltvorgänge des Senders, aber nicht die Daten des
Senders sehen kann?
Die Amplitude an dem Pin beträgt etwa 0,5V. ich sehe exakt die An-und
abschaltvorgänge, die ich am Sender vornehme...
Funktioniert auch wenn der Sender im Nebenraum ist. Verbindung scheint
also irgendwie zu stehen.
Bild: Low= Sender aus, High=Sender an und sendet
Habt Ihr Vorschläge / Ideen?
Gruß Hannes