Hallo,
ich versuche derzeit verzweifelt den RFM12B (868Mhz Band) mit dem ATmega
168 zum Laufen zu bringen.
Der Sender funktioniert bereits. Wenn ich Daten in den FIFO schiebe,
reagiert nIRQ.
Den Empfänger möchte ich interruptgesteuert programmieren. Doch leider
bleibt der nIRQ dauerhaft auf logisch 1.
Ich habe im Anhang meinen C-Code und den Schaltplan für beide Geräte
angeführt. Habt ihr vielleicht eine Idee, an was das liegen könnte, bzw.
was man noch ausprobieren könnte?
Ich habe auch schon diverse Initialisierungen ausprobiert, doch leider
ohne großen Erfolg :/
Vielen Dank!
Schöne Grüße
Bernd
Ps: Was ich noch dazu sagen möchte: Das Grundgerüst des C-Codes stammt
von hier: http://www.joachim-neu.de/post/70/rfm12b-868/
Da ich eine interruptbasierende Lösung wollte, habe ich einige
Adaptionen durchgeführt.
Bernd schrieb:> Den Empfänger möchte ich interruptgesteuert programmieren. Doch leider> bleibt der nIRQ dauerhaft auf logisch 1.
Es ist jetzt 6 Jahre her, dass ich mich mit dem Ding befasste und selbst
Code für den PIC schrieb aber ich hatte damals auch Probleme und diese
hatten die Ursache darin, dass die RFM12b Chips Bugs hatten. Irgendein
Flag wollte sich ums Verrecken nicht setzen.
Hier mal mein Code für PIC (mit CCS) von damals. Es funktionierte nur
mit Polling, die INT Geschichte lief nie.
Aufgrund des Alters > 8 Jahre würde ich die Steine nicht mehr einsetzen,
es gibt heute bessere Lösungen wie zb auf der 2,4Ghz Frequenz die
NRF24L01 Nodule.
Hallo,
danke für die Antwort.
Ich habe heute weitere Versuche unternommen und dabei folgende
Erkenntnisse gewonnen.
- Die Senderoutine habe ich erneut angepasst. Anbei die aktuelle
Version.
- Dann habe ich das CLK Signal überprüft. Mir ist aufgefallen, dass sich
die Frequenz des Signals während des Betriebs ändert. Eingestellt ist 1
Mhz und plötzlich sind es 4Mhz. Einige Minuten später messe ich am CLK
Ausgang wieder 1 MHz.
Mein Microcontroller wird überigens über einen externen 4MHz Quarz
versorgt.
- Die Feldstärkespannung am Empfänger beträgt 0,35V. Laut der Kurve im
Datenblatt müssten es bei optimalem Empfang allerdings 0,45V sein.
Hat vielleicht jemand zu diesen Punkten eine Idee? Der nIRQ Ausgang
müsste doch trotz Polling auf logisch 0 fallen, sobald der FIFO Daten
erhält.
Schöne Grüße und vielen Dank
Bernd
Hallo Bernd,
bei mir war es ein Hardwareproblem.
Lösung:
Am Empfänger ein 100p Kondensator an nIRQ zu GND. Alles bestens.
Zum Programm kann ich nichts sagen. Schreibe in Bascom.
Zitat:
Hat vielleicht jemand zu diesen Punkten eine Idee? Der nIRQ Ausgang
müsste doch trotz Polling auf logisch 0 fallen, sobald der FIFO Daten
erhält.
Ich bin der Meinung umgedreht.
In Bascom sieht es so aus.
Config Int1 = Rising ‘wenn Int1 von 0 nach 1 dann Unterprogramm aufrufen
On Int1 Rfm_funkirq
Stelle ich es so ein
Config Int1 = Falling
Funktioniert es nicht.
Gruß
Fred
Hallo Fred,
vielen Dank für deinen Input!
Ich habe heute deinen Tipp mit dem 100p Kondensator ausprobiert. Doch
leider war das nicht die Ursache des Problems. :(
Auch habe ich den Interrupt testhalber einmal auf die steigende Flanke
programmiert.
Wenn ich mit dem Oszilloskop den nIRQ PIn ansehe, bleibt dieser
dauerhaft auf 1.
Ich habe heute übrigens nochmal die ARSSI Spannung beim Kondensator auf
der Empfängerseite gemessen. Diese scheint optimal zu sein - ich habe
mich gestern geirrt!
Man sieht - bei sekündlichem Senden einiger Bytes- wie die Spannung auf
1,1V ansteigt und anschließend wieder auf 0,4V absinkt.
Schöne Grüße
Bernd
Warum schaltest du nach jedem einzelnen Byte den Transmitter ab bzw.
aktivierst den FIFO-Puffer neu?
Du solltest nach der Aktivierung des Transmitters im richtigen Timing
(jeweils warten auf die fallende NIRQ-Flanke) die Bytes nacheinander in
den Puffer schreiben und erst dann den Transmitter abschalten.
Beim Receiver ist es genauso: Receiver einmalig aktivieren, FIFO leeren
und dann einfach die Bytes nacheinander im richtigen Timing abholen.
Hallo zusammen,
vielen Dank für eure Hilfe und gleichzeitig sorry für meine späte
Antwort.
Ich habe die letzten Abende unzählige Experimente mit dem Dingern
gemacht.
@Felix: Danke für den Hinweis mit dem FIFO. Nachdem ich das angepasst
habe, kamen zumindest Daten auf der Empfängerseite an. nIRQ geht nach
dem Erhalt der beiden Synchronisationsbytes ständig auf low.
Leider ist es nun so, dass der Empfänger nur Müll empfängt. Im
angehängten Empfängercode sperre ich das FIFO nach 2 Bytes.
(Empfängerseitig werden auch nur 2 gesendet)
Dennoch geht nIRQ ständig auf low. Es scheint, dass irgendwelche
Störungen das FIFO füllen und dann den Interrupt request generieren.
Kann das wirklich sein? Was kann man in diesem Falle anpassen?
Vielleicht hat ja jemand noch eine Idee :)
Vielen Dank für eure Hilfe!
Schöne Grüße aus Wien
Bernd
Bernd schrieb:> Leider ist es nun so, dass der Empfänger nur Müll empfängt. Im> angehängten Empfängercode sperre ich das FIFO nach 2 Bytes.> (Empfängerseitig werden auch nur 2 gesendet)> Dennoch geht nIRQ ständig auf low. Es scheint, dass irgendwelche> Störungen das FIFO füllen und dann den Interrupt request generieren.> Kann das wirklich sein? Was kann man in diesem Falle anpassen?
Was heißt "der Empfänger empfängt nur Müll"? Du erwartest beim Empfänger
0x20 an der Stelle receive[1], meiner Meinung nach müsste es aber doch
in receive[0] stehen, oder?
Wie du dem Datenblatt auf Seite 30 entnehmen kannst, solltest du vor dem
Abschalten des Senders nach der tatsächlichen Payload noch ein (ich
selbst nehme zwei, um ganz sicher zu gehen, dass auch alles versendet
worden ist) Dummy-Byte in den Sendepuffer schreiben. Der Sendepuffer
kann zwei Bytes aufnehmen und schickt nur dann das ältere der beiden
raus, wenn er voll ist. Wenn du also kein Dummy-Byte hineinschreibst,
wird das letzte Byte deiner Payload nicht gesendet.
Mein übliches Vorgehen zum Vermeiden von Störungen ist, dass ich direkt
nach dem FIFO-Schlüssel 0x2DD4 eine Längenangabe schicke, wie viele
Bytes jetzt noch folgen werden. Dann weiß der Empfänger, wie lange er
zuhören muss und wann er einfach den Puffer zurücksetzen kann. Zudem
sichere ich das auch noch mit CRC ab, um sicher zu gehen, dass alles
richtig übertragen wurde.
Bernd schrieb:> Vielleicht hat ja jemand noch eine Idee :)
Ehrliche Antwort?
Wieso schlägst du dich mit 8 Jahre alten Chips herum, die
erwiesenermaßen noch Bugs hatten? Der Empfänger empfängt immer Müll und
wenn da zufällig 2DD4 dabei ist füllt er den Fifo.
Da komme ich mit einem normalen 3Euro 433 noch schneller zum Ziel, 15
Minuten, Radio Head Libary und die Daten laufen.....
Ich habe auch Funkmodule in Betrieb, 2.4 Ghz und XBee, vollautomatische
Frame Erzeugung, CRC usw ..... tun genau das was sie sollen. grunz
Hallo zusammen!
Ich möchte mich nochmal ganz herzlich für eure Mithilfe bedanken.
Speziell bei dir Felix!
Nach fast 2 Wochen mühsamer Fehlersuche habe ich die Dinger tatsächlich
zum Laufen gebracht :)
@Felix: Du hattest recht, es braucht die Dummy Bytes am Ende der
Nutzdaten. Der gepostete Code ist so natürlich unbrauchbar, das stimmt.
Aber zum Testen wollte ich ihn möglichst einfach halten.
Ich habe heute Nachmittag bereits ein Protokoll mit CRC implementiert.
Ich stelle den Code hier frei zur Verfügung. Er eignet sich zum Testen
der Module und vielleicht hilft er ja jemandem.
Ganz schöne Grüße
Bernd
Beschaltung_RFM12b.png
(6,1 KB)
