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.
Angehängte Dateien:
-
Beschaltung_RFM12b.png
6,1 KB
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
:
Bearbeitet durch User
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
q.e.d. RF_Sendbyte(check); // Checksumme RF_SendByte(0xAA); // Dummy, nachschieben als Pipelineputzer RF_SendByte(0xAA); // Dummy, nachschieben als Pipelineputzer
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.