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 ?
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
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.
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 :(
