Hallo allerseits, ich benutze ein RFM12 als Empfänger im FIFO-Mode ohne Mustererkennung. Als Füllschwelle habe ich 1000b also 8Bit eingestellt. Die Daten werden ausgelesen sobald der Pin nIRQ auf Low geht. Nun ist das aber leider immer der Fall, also wird nur Mist ausgelesen. Die Ereignisse welche den Interrupt auslösten könnten habe ich deaktiviert (nINT als Ausgang, Brownoutdetection deaktiviert) Den Sender betreibe ich übrigens auch indem ich den nINT-Pin abfrage und Daten in den Sendepuffer lade. Dort funktioniert es auch einwandfrei. Ich habe auch schon den Sende- und Empfangscontroller vertauscht um auszuschließen dass es an den Modulen liegen könnte. Was könnte noch einen Interrupt auslösen ?
Ich habe derzeit auch ein Problem mit dem Empfangen, jetzt möchte ich überprüfen ob es vl. doch am Sender liegt. Kann man vl. irgendwie überprüfen das der Sender wirklich sendet?
Wenn man im 'Data Filter Command' den Filter auf Analog stellt (Bit4=1) und am Data-Ausgang einen Verstärker anschliesst kann man die Daten im Empfänger hörbar machen. Bit3 und 5 in diesem Kommando sollten aber 0 sein und nicht 1 wie im Datenblatt steht, das ist offensichtlich falsch.
Hallo Jörg, ich sende im Sekundentakt und frage das DRSSI-Bit des Statuswortes im Empfänger ab. Beim Senden ist es High und bringt mir dadurch eine LED zum Leuchten. Welches Problem hast du mit dem nINT-Signal ?
Hallo, ich habe auch gerade das Problem, dass nIRQ im Normalzustand low ausgibt - gibt es für dieses Problem mittlerweile eine Lösung bzw. Erklärung?
Dann löst noch ein anderes internes Modul eine Interruptanfrage aus. Schau mal in die Doku, welche Module alle auf die nIRQ Leitung zugreifen können.
Also ich hatte mit dem RFM12 so ziehmlich das gleiche Problem, nach dem ich dann alles mögliche ausprobiert hatte von software emuliertes SPI und fast jedem source code den ich irgendwo zu dem Thema finden konnte, weil ich mir absolut sicher war das sich kein Fehler in die Verkabelung eingeschlichen hatte, war die Lösung eher ein glücklicher Zufall. Die RFM dinger sind anscheinend SEHR empfindlich was ihre Versorgungsspannung angeht. Ich hätte niemals gedacht das es mit sowas zu tun hat, aber nachdem ich einen 22µ elko genau über VDD und GND am Modul gelötet hatte klappte auf einmal das senden und empfangen auf anhieb und bis heute! Aber leider hatte ich erstmal 2-3 Monate "rumgedoktert" bis ich auf die Idee gekommen bin, schöne Zeitverschwendung. Ansonsten bin ich echt überrascht von den RFMs, kann im Haus über 2 Stcokwerke hinweg ohne Probleme mit 38KBaud senden und empfangen. Benutze sie als Fernsteuerung für nen e-Helikopter und bis jetzt hatte ich auch noch keine Störungen durch irgendwelche Funkwetterstationen unserer Nachbarn die auch auf 433MHz senden oder Garagentoröffner etc. mfG Grobi
Hardware: Pollin RFM12s Rev:3.0 ich habe lange gesucht, hier meine Lösung: Ich benötige beim RFM12 den PIN nIRQ für den Wake-Up Timer (Batteriebetrieb). Leider wird nIRQ auf LOW gesetzt und blockiert, nachdem ein Byte erfolgreich gesendet wurde (d.h. Statusbit RGIT => 1 und nIRQ => 0). Im RF12 Datenblatt S.24 geht nIRQ->High nach "clearing et bit" Das fubktioniert bei meinem Modul nicht! Wird jetzt der Wake-Up Timer gestartet, bleibt nIRQ die ganze Zeit auf LOW. Das Wake-Up Event wird korrekt im Statusregisterbit WKUP angezeigt, nur der nIRQ ist leider blockiert. Ich habe keine Befehlsequenz gefunden, die den nIRQ sauber wieder freigibt. Ich habe getestet: - Lesen der Statusregister (0x0000) - das Bit et im Power-Managemant gelöscht und gesetzt, wie im Handbuch unter "12. wake-up timer" beschrieben - Alle Varianten den Chip schlafen zu legen (0x8201) und wieder aufzuschalten. Als einzigen dirty Workaround habe ich gefunden, ein zusätzliches dummy Byte zu senden und den Sender sofort stromlos zu schalten (0x8201) bevor das Statusbit RGIT/FFIT Erfolg meldet und nIRQ wieder auf LOW geht. ------------------- NACHTRAG -------------------- Jetzt bin ich beim Stöbern in den Datenblättern von RF12 IA4421 Si4421 auf folgenden UNTERSCHIED gestoßen: - Im Datenblatt vom RF12 / IA4421 wird nach Tx der nIRQ freigegen mit et=0. - Im Datenblatt vom Si4421 wird nach Tx der nIRQ freigegen mit et=0 (zB 0x8201) und anschließend el=0 (zB 0x8057). Der CODE für den Si4421 funktioniert bei meinem Pollin Modul :-) !!! Da ich alle viele Codefragmente aus mikrocontroller.net erfolglos getestet hatte (meist wird nach Tx nur ein 0x8201 gesendet) nehme ich an, dass verschiedene RFM12 Module im Umlauf sind!
Hallo Gast! Danke, das war der entscheidende Hinweis. Auch bei mir bleibt nIRQ nur dann high, wenn ich das el bit lösche! Danke, habe auch Stunden gebraucht um das rauszufinden. Grüße
Hi! Ich habe vermutlich das gleiche Problem mit dem rfm12-Code von Das Labor. Kann mir jemand helfen, den Code zu ändern? Als Anfänger bin ich verloren. Gruß, Chris
Hi! Welche revision des si4421 datenblattes hast du (und von wo her?). Ich finde hier[0] auf Seite 28 nur folgendes: > WKUP: both the nIRQ pin and status bit can be cleared by the read status command Ich frage, denn den transmitter ab- und wieder anzuschalten würde den doch wieder in seinen ursprungszustand versetzen und ggf. aus dem takt bringen - ich kann mir jedenfalls vorstellen das der auch eine gewisse zeit braucht um sich einzuschwingen. Werde gleich mal damit rumexperimentieren und schauen ob das zuverlässig klappt. Grüße vom Sörn --- 0: http://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/Si4421.pdf&src=ProductMatrix
Hi Sörn, ich habe in den letzten Tagen immer mal wieder gesucht, aber auch keine anderen Datenblätter gefunden.... werde wohl auf die Wakeup-Funktion verzichten müssen. Hast du noch etwas herausgefunden? Gruß, Chris
Wenn man folgende Dinge beachtet, sollte es keine Probleme mit dem IRQ geben. - nach dem Einschalten geht nIRQ auf low wegen POR und/oder EXT IRQ - am Ende vom Init des RFM den Status lesen löscht diese IRQ - Senden: nachdem das letzte Byte an den RFM geschickt wurde, sofort et=0 setzen. Sonst wird RGIT IRQ wieder aktiv und nIRQ low. Dies kann nicht durch Lesen des Status gelöscht werden, nur durch Übertragen eines Bytes in den TX-Puffer. Gilt natürlich nur wenn der TX-Puffer verwendet wird. - Empfangen: nachdem das Letzte Byte aus dem FIFO geholt wurde, sofort FIFO abschalten bzw. FIFO Reset ausführen. Sonst wird der FFIT IRQ gesetzt und nIRQ wird low. Dieser kann nur durch Auslesen des FIFO gelöscht werden. Nachdem der FIFO einmal die Sync Bytes erkannt hat, liefert er auch ohne aktiven Sender noch Daten (zufällige Werte). Durch den FIFO Reset wird wieder auf Sync Bytes gewartet - wake-up timer: Lesen des Staus Registers löscht den WKUP IRQ und nIRQ wird wieder high
Angehängte Dateien:
-
Logik.png
280 KB
Hallo Leute,
ich habe das selbe problem mit dem Low am int. Will
Senden...Funktioniert auch manchmal ;) ... der interrupt pfuscht
dazwischen vermute ich.
Also:
hab alles durchprobiert...löschen aller register ... in verschiedenen
kombinationen. Einen Logik-Analyser hab ich auch dazu geholt ;) ...
kommunikation wie gewünscht!
ich bekam am Anfang immer ein 0x8000 Status. Wie ich dies aber
interpretieren sollte wusste ich erst nicht. bit nummer 16 nennt sich
FO? Warum Fifo out? ich will doch nur senden :(
Dieser Code schiebt die daten ins fifo.
Ist aus ner LIB und befindet sich in der Interruptroutine die auf INT0 =
LOW reagiert.
if(RF12_status.Tx)
{
rf12_trans(0xB800 | RF12_Data[RF12_Index]);
if(!RF12_Index)
{
RF12_status.Tx = 0;
rf12_trans(0x8208);
}
else
{
RF12_Index--;
}
}
Anbei das aktuelle out...
wie werd ich dem den Herr?
Bitte helft mir :(
UM Himmeles WILLEN! entschuldigt meinen verzweifelten Ausbruch ;) ich habe das register Falschherum gelesen...0x8000 bedeutet ich solle das TX-Register beschreiben ... meine güte. entschuldigung!
Johannes dein screenshot von deinem (ich nehme an) pc-oszillosop sieht sehr praktisch aus. ich quele mich hier immer mit meinem 2-kanal uni-t oszi... kannst du mir vllt mal den produktnamen von dem teil sagen? sieht sehr praktisch aus mit dem langen zeitausschnitt, den vielen kanälen und der wertanzeige. würde mich freuen! und ja ich hänge auch an nIRQ-immer-low fest! der elektor kam in seinem artikel oder nIRQ aus SDO springt ja scheinbar zu selben zeit wie nIRQ? ich habe schon etliche stunden (ingesamt sicher tag) am schreibtsich vertüfftelt. hab bisher trotzdem noch noch nicht ein Byte richtig übertragen :/ wenn mir jemand mal einen funktionierenden Quellcode senden würd oder sich meinen code mal anschauen würd, wäre ich sehr erfreut! dafür das die teile so leicht anzusteuern sein sollen, ist es erstaunlich schwierig mit der menge an verschiedenen und scheinbar unvollständigen und fehlerhaften datenblättern. Zumindest für mich. viele grüße Peter
Christian Peskov schrieb: > Johannes dein screenshot von deinem (ich nehme an) pc-oszillosop sieht > sehr praktisch aus. ich quele mich hier immer mit meinem 2-kanal uni-t > oszi... > kannst du mir vllt mal den produktnamen von dem teil sagen? > sieht sehr praktisch aus mit dem langen zeitausschnitt, den vielen > kanälen und der wertanzeige. > würde mich freuen! http://www.saleae.com/ Hab ich auch. Das Ding ist absolut genial! Aber es handelt sich um einen Logic Analyzer, kein Oszi.
Hallo zusammen. Genau. Das war der Logik 8. Liegt im Moment bei knapp 130€. Sehr nützlich und ein muss wenn man experimentel programmiert :)
Ach so einen LA braucht man eigentlich immer, wenn man digitale Schaltungen entwickelt. Merkt man aber erst wenn man einen hat ;-) Und nach Europa versenden die über UK, also keine Probleme wegen Zoll.
ja besten dank!! als ich den screenshot sah, bin ich auch begeistert gewesen :-) und nach dem cyblord mir noch in der nacht antwortete, habe ich auch gleich eins bestellt :) 130 euro ist ja echt fair find ich... zumal ich mich bisher mit meinem 400€ oszi gequält habe. ich hoffe es kommt die woche. ich bin ja ehr n leie und dachte immer die usb oszis sind doch nie so gut wie die digitalen dedizierten geräte... aber es ist ja kein oszi :)) bin echt gespannt, das sieht so praktisch aus ^^ so jetzt noch mal zu dem eigentlichen thema: also mein nIRQ im empfänger blieb auch immer auf low sobald alle receiver bits gesetzt wurden. bei mir geht nIRQ erst auf high zurück, wenn ich: nach dem auslesen des FIFOS, 0x0000 sende UND anschliesend 0xca85 (kann auch 0x80a7 gewesen sein, hab gerade beides im code stehen) an das RFM sende. Aber es kann doch nicht sein, dass nach jedem ausgelesenen FIFO-Byte den ganze receiver ausgeschalten muss?!? desweiteren hab ich folgendes gravierendes Problem. ICh hoffe das bei euch erfahrenen das auch schon auftrat und ihr mir die lösung preisgibt: ^^ ich versuche ja noch die rudimentäre funkverbindung hinzubekommen. 2mal rfm12b auf 2 Pollin-Funkboards. Bestückt mit atmega32. wenn der Sender ausgeschaltet ist, empfängt mein revceiverboard das rauschen auf der antenne. also ich bekomme zufällige zahlen ausgegeben. das freute mich auch erstmal :) sobald der sender eingeschalten wird, empfange ich nur noch Nullen! :/ a) erfreulich, weil fernwirkung statt findet. b) unerfreulich, weil funzt ja nicht richtig xD das war auch der stand der dinge als ich es vpr 1,5 jahren schon versuchte. jetzt hab ich mich an neuen beispielen gehalten und wieder das gleich bild :/ das hat doch bestimtm auch schon wer von euch mitgemacht?! hat wer nen tipp für mich? ich danke euch ^^
Hallo Christian Peskov, >ich versuche ja noch die rudimentäre funkverbindung hinzubekommen. >2mal rfm12b auf 2 Pollin-Funkboards. Bestückt mit atmega32. >wenn der Sender ausgeschaltet ist, empfängt mein revceiverboard das >rauschen auf der antenne. also ich bekomme zufällige zahlen ausgegeben. >das freute mich auch erstmal :) >sobald der sender eingeschalten wird, empfange ich nur noch Nullen! :/ >a) erfreulich, weil fernwirkung statt findet. >b) unerfreulich, weil funzt ja nicht richtig xD >das war auch der stand der dinge als ich es vpr 1,5 jahren schon >versuchte. jetzt hab ich mich an neuen beispielen gehalten und wieder >das gleich bild :/ Die Probleme hatte ich auch. Habe mir die Platinen und Software vom RF SOAP Projekt hier im Forum besorgt. Sehr gut gemacht. Das hat mir in sehr kurzer Zeit ein grundlegendes Verständis des RFM12 gebracht. Vor allem: es lief auf anhieb. Gut angelegtes Geld finde ich. Mit diesen Grundlagen habe ich ein eigenes Projekt auf die Beine gestellt und funktioniert gut. Das Projekt nim Sensordaten vom Barometer und Hygrometer auf und sendet diese per Funk an eine Basis. Bei Interesse PN an mich. Der Receiver ansich ist unproblematisch. Der Transmitter macht da deutlich mehr Schwierigkeiten. Da Datenblatt von Silabs (Si4420 für den RFM12) und das Tool WDS3 von Silabs sind eine enorme Hilfe. Man muss das Datenblatt wirklich mehrmals sehr gründlich lesen (Auch mir sind nach mehrmaligem Lesen die vielen Stolperfallen klar geworden). Karsten
Danke für deine antwort! so sehe ich gerade dass das hier noch offen war. Also mien problem war (und das war scheinbar schon vor 2 jahren der haken) das die printfanweisungen welche ich zu debuggen einfügte, sowohl in der Sende als auch empfangsfunktion war. das hat wohl alles zu lange gedauert so das nie was ordenlichen eingelesen wurde. printf überall rausgehauen und schwupp lief es :) sensationell! ich wäre heute viel weiter wenn ich damals schon dies idee gehabt hätte. danach hab ichs nämlich erst mal in die ecke gehauen :-/ auf deine angebot karsten, werde ich bei zeiten aber zurück kommen danke! jetzt guck ich mir erstmal dein genanntes projekt an. funken tun wir nun cshon und auch testweise mal ein relais angehangen. überlegen uns zur zeit noch en geeignetes protokoll.. viele grüße
ufff äääh könnte das wer ganz kurz zusammenfassen in ein paar zeilen code? interrupt abfangen, zeichen lesen, interrupt löschen ... im polling geht alles aber beim interrupt schnippsel ich mir hier schon solange code zusammen und passiert nix :(
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.