Hallo zusammen, um meine Funkmodule der Reihe RFM69HW (433MHz) zu testen, habe ich zwei Stück mit jeweils einem Arduino UNO verbunden. Die Verbindung habe ich wie auf dem Hook-Up Guide von SparkFun durchgeführt. - https://learn.sparkfun.com/tutorials/rfm69hcw-hookup-guide/all Ich habe auch den von Sparkfun zur Verfügung gestellten Exampe Code auf beide Unos geladen und entsprechend angepasst. Den Code habe ich hier hochgeladen: - https://pastebin.com/qf1cDtBd Die Bibliotheken die verwendet werden, findet ihr hier: - https://github.com/LowPowerLab/RFM69 (Dabei im wesentlichen: RFM69.cpp, RFM69.h, RFM69registers.h) Zum Test habe ich beide Unos angeschlossen und für jeden den Seriellen Monitor geöffnet. In einem Monitor beispielsweise "Hello World" eingegeben. Diese Nachricht wird dann von einem Modul gesendet. In meinem anderen seriellen Monitor kommt dann auch die Meldung, welche Nachricht empfangen wurde und es wird ein ACK als Bestätigung zurückgesendet (siehe Bild Testnachricht mit ACK (1)). Somit hat sowohl das eine Modul einmal gesendet, die Nachricht, und auch das andere Modul das ACK. Wenn ich jetzt aber egal über welches Modul nochmal etwas senden möchte, funktioniert es nicht (siehe Bild Testnachricht mit ACK (2)). Daraufhin habe ich den Code in RFM69.cpp-Bibliothek genauer unter die Lupe genommen. Dabei habe ich an verschiedenen Stellen immer wieder Register auslesen lassen, um zu gucken was mit denen passiert. Letztendlich ist mir aufgefallen, dass BEIDE Module es nicht mehr schaffen, nach dem Modus RF69_MODE_TX der unter sendframe in Zeile 335 aufgerufen wird, es nicht mehr schafft in den RF69_MODE_STANDBY zurückzukehren. Beispielsweise behält REG_OPMODE den Wert 0x0C nach dem Senden, obwohl es wieder den Standby-Wert von 0x04 annehmen sollte. Außerdem hat beispielsweise REG_IRQFLAGS1 im ersten Durchlauf von der Funktion sendframe den Wert 0x80. Nach dem ersten Durchlauf kommt aber meistens nur noch der Wert 0x08 raus. Dementsprechen kann es bei der While-Schleife in Zeile 308 nicht weitergehen. Ich vermute, dass das ganze Problem daher rührt, dass das Modul aus dem Modus RF69_MODE_TX nicht mehr rauskommt. Denn nachdem wie in den Bildern gezeigt ein Modul was empfängt, es auch noch ein ACK zurücksenden kann, liegt es meiner Meinung nach nicht an dem RF69_MODE_RX. Hat vielleicht einer in der Hinsicht irgendwelche Erfahrungen oder weiß vielleicht einen Rat, wie ich das Problem beheben kann? Falls einer noch mehr Informationen benötigt, sagt einfach Bescheid! Viele Grüße Max
Angehängte Dateien:
Da der Sendevorgang bei beiden Modulen zu laufen scheint, denke ich nicht, dass etwas mit dem Anschluss nicht stimmt. Aber was man in dem Code ändern kann, weiss ich selber nicht so richtig
Angehängte Dateien:
-
RFM69__1_.jpeg
130 KB -
RFM69__2_.jpeg
190 KB
Kann mir echt keiner helfen? Ich brauche wirklich dringend eine Lösung und bin auch bereit einem Helfer gerne für seine Mühen zu entschädigen!!!! Im Anhang auch nochmal meine Verdrahtung. Auf zwei Weisen ausprobiert...immer der gleiche Fehler :(
:
Bearbeitet durch User
Hallo, also mit Arduino kenne ich mich nicht aus und die Low-Power-Lab-Vorlage war mir schon immer zu kompliziert gewesen da dort wohl vielfältige Variationen gezeigt werden sollen. Ich habe immer einen AT-Mega mit SPI benutzt und AVRGCC. Aufgrund der langen Drähte kann ein Keramik-C direkt am Modul zwischen + und - vielleicht nützlich sein. Mit Deiner Fehlersuche bist Du bei der Beobachtung der Statusregister aber schon an der richtigen Stelle angekommen. Erschwerend kommt hinzu, daß es vom RFM69 mehrere Varianten gibt und das Datenblatt an wichtigen Stellen nur ungenau darstellt. Vermeide am besten die Benutzung des AES und der Auto-modes. Mein Exemplar wollte die Auto-modes nicht richtig umschalten. Vielleicht kannst Du mit den Beispielen im Dateianhang etwas anfangen. Vollständigen Code möchte ich aufgrund des damals entstandenen Aufwandes nicht heraus geben, zumal ich derzeitig kaum brauchbare Vorlagen finden konnte. mfG
Maximilian S. schrieb: > Im Anhang auch nochmal meine Verdrahtung. Auf zwei Weisen > ausprobiert...immer der gleiche Fehler :( Da fehlt der Levelshifter, oder? Lesen und lernen: https://learn.sparkfun.com/tutorials/rfm69hcw-hookup-guide/all (wobei mir der dort verwendete Levelshifter, für den Zweck, nicht so gut gefällt)
Hier ist noch eine Variante: https://github.com/nurazur/TiNo?files=1 Der Autor hat vor allem auch die High Power RFM Variante korrigiert. Ich habe mit dem org Code auch gekämpft, gerade die Modus Umschaltung ist undurchsichtig weil jede Funktion für sich da rumfummelt. Ich habe es aber nicht für Arduino geändert. Cortex-M die man einfach debuggen kann spielen da ihren Vorteil aus. Beim Ack erinnere ich mich noch an ein Timing Problem: wenn der Empfänger das Ack schneller schickt als der Sender wieder auf Empfang umgeschaltet hat, dann hängt es.
Angehängte Dateien:
-
Serial_Monitor_TX.png
190 KB
Arduino Fanboy D. schrieb: > Da fehlt der Levelshifter, oder? Da ein arduino Uno einen 3,3V-Pin hat, braucht man keinen Levelshifter. Christian S. schrieb: > Mit Deiner Fehlersuche bist Du bei der Beobachtung der Statusregister > aber schon an der richtigen Stelle angekommen. Erschwerend kommt hinzu, > daß es vom RFM69 mehrere Varianten gibt und das Datenblatt an wichtigen > Stellen nur ungenau darstellt. > > Vielleicht kannst Du mit den Beispielen im Dateianhang etwas anfangen. > Vollständigen Code möchte ich aufgrund des damals entstandenen Aufwandes > nicht heraus geben, zumal ich derzeitig kaum brauchbare Vorlagen finden > konnte. Also ich habe mir deine Code-Fragmente angeguckt und finde diese wirklich gut und hilfreich. Meiner Meinung auch alles total logisch. Ich habe jetzt echt alles nochmal ausprobiert und es lassen sich alle Modi ansteuern und auch zurücksetzen - AUßER der TX Modus. Ich habe dabei alle Register ausgelesen von REG_IRQFLAGS1, REG_IRQFLAGS2 bis REG_OPMODE. Beispielsweise wechselt REG_OPMODE beim RX-Modus wunderbar zu dem Value 0x10 und REG_IRQFLAGS1 nimmt aucht den Wert 0xD8 an. Wandelt man die Hexa-Zahlen ins Binbärsystem um sieht man auch wunderbar, dass dort alles richtige gesetzt ist. ABER SOBALD TX einmal gesetzt wurde, spinnen alle Register rum und ich kriege die nicht wieder kontrolliert und kann demnach auch kein vernünftigen Modus mehr herstellen. Gibt es da irgendwas, was ich beachten muss, damit TX wieder vernünftig beendet wird? Hat denn dazu irgendjemand eine Idee??? Ich habe viel herumexperimentiert. Hier mal ein Beispielcode https://pastebin.com/53wR4Jmd Dazu das Ergebnis aus dem Serial-Monitor als Bild im Anhang. Man sieht auf jeden Fall, dass nachdem TX gesetzt ist, alles komplett durcheinander ist. HOFFENTLICH HAT EINER EINE IDEE....ICH HABE KEINE AHNUNG MEHR UND BIN TOTAL FRUSTRIERT, OBWOHL MIR DAS GANZE THEMA MEGA SPAß MACHT :(
:
Bearbeitet durch User
Maximilian S. schrieb: > Da ein arduino Uno einen 3,3V-Pin hat, braucht man keinen Levelshifter. Ja? http://www.farnell.com/datasheets/1870821.pdf Wo steht in dem Datenblatt, dass /CS und MOSI des RFM69HW 5V tolerant sind? Ich sehe es nicht.
Arduino Fanboy D. schrieb: > http://www.farnell.com/datasheets/1870821.pdf > Wo steht in dem Datenblatt, dass /CS und MOSI des RFM69HW 5V tolerant > sind? > Ich sehe es nicht. Aber die SPI-Verbindung funktioniert doch? Der FIFO lässt sich füllen vom RFM und auch die Register lassen sich auslesen. Wenn es mit den SPI-PINs irgendwelche Probleme geben würde, dann wäre das alles doch auch schon nicht mölich oder?
Maximilian S. schrieb: > Den Code habe ich hier hochgeladen: > - https://pastebin.com/qf1cDtBd Und warum nicht hier?
Maximilian S. schrieb: > Wenn es mit den > SPI-PINs irgendwelche Probleme geben würde, dann wäre das alles doch > auch schon nicht mölich oder? Was passiert, wenn der Chip außerhalb der Spezifikation betrieben wird, geht aus dem Datenblatt nicht hervor. Ein üblicher Effekt, in solchen Fällen, ist das teilweise oder vollständige Versagen. --- Natürlich kann es auch sein, dass du viel schlauer, als der Hersteller bist, und mehr weißt, als im Datenblatt steht. Aber verlassen, würde ich mich darauf eher nicht. Von mir weiß ich, dass ich nicht schlauer bin. Darum glaube ich dem Datenblatt mehr, als meinen Fantasien.
Arduino Fanboy D. schrieb: > Was passiert, wenn der Chip außerhalb der Spezifikation betrieben wird, > geht aus dem Datenblatt nicht hervor. > > Ein üblicher Effekt, in solchen Fällen, ist das teilweise oder > vollständige Versagen. Natürlich kannst du recht haben...letztendlich ist nur VCC mit den 3,3V verbunden und nicht die Datenleitungen. Umso mehr ich drüber nachdenke, umso mehr kann ich mir das vorstellen. Klar, kann was bei nicht korrektem Betrieb funktionieren und gerade habe ich auch noch auf Sparkfun folgendes Zitat gefunden "IMPORTANT! Do not power your RFM69 with 5V or connect the data lines directly to a 5V microprocessor. Doing so will damage the device." Da sonst eigentlich alles genauso ist, wie überall beschrieben, könnte das die Fehlerquelle sein. Ich werde heute noch einen Level-Shifter bestellen. Könnt ihr welche empfehlen? Würde sonst mich zwischen diesen beiden Angeboten entscheiden: https://www.amazon.de/KeeYees-Konverter-Bi-Direktional-Shifter-Arduino/dp/B07LG6RK7L/ref=sr_1_5?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=level+shifter&qid=1588507430&sr=8-5 https://www.amazon.de/AZDelivery-TXS0108E-Converter-Arduino-Raspberry/dp/B07N7FFY2Q/ref=sr_1_6?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=level+shifter&qid=1588507524&sr=8-6
Forist schrieb: > Maximilian S. schrieb: >> Den Code habe ich hier hochgeladen: >> - https://pastebin.com/qf1cDtBd > > Und warum nicht hier? Ist doch letztendlich egal, ob man es in der .INO macht oder in der .cpp. Habe halt einfach irgendwann dort angefangen zu schreiben, weil man dort auch schneller mal in die anderen Funktionen gucken kann
Maximilian S. schrieb: > Ist doch letztendlich egal, ob man es in der .INO macht oder in der > .cpp. Habe halt einfach irgendwann dort angefangen zu schreiben, weil > man dort auch schneller mal in die anderen Funktionen gucken kann Du hast die Frage (den Einlauf) nicht verstanden! Ich übersetze dir den Einlauf mal in Klartext: Ich stecke mir auch keine PasteBin Dinger in den Mund. Die fasse ich noch nicht einmal an. Bedenke auch: PasteBin löscht den Code nach einiger Zeit. Damit ist der Thread einer seiner Kerninformationen beraubt und wertlos für alle späteren Leser. OK, das mag dir egal sein, wenn dein Problem gelöst ist. Aber es ist dennoch eine arg egomanische Vorgehensweise. Und damit in Foren quasi generell unerwünscht.
Arduino Fanboy D. schrieb: > PasteBin löscht den Code nach einiger Zeit. Das wusste ich nicht. Ich bin noch nicht so lange in der Szene aktiv und habe mir nichts böses dabei gedacht. Mir wurde pastebin hier sogar mal in einem thread empfohlen. Aber vielen Dank für den Hinweis! Dann werde ich das in Zukunft auf jeden Fall bedenken und anders posten. SORRY an dieser Stelle! Ich wollte damit jetzt auch keinem auf den Fuß treten oder so, sondern möchte eigentlich nur das Problem weiter lösen und angehen. Also ich werde mir dann jetzt so einen Levelshifter kaufen! hat denn da einerne Produktempfehlung? Ich kann nur wiederholen, dass mir das ganze echt Spaß macht und ich auf jeden Fall eine Lösung finden will, damit auch andere nicht vielleicht mit diesem Thread was anfangen können :) An dieser Stelle auch mal ein DICKES Dankeschön an alle Mitwirker bisher ! Über alle weiteren Hinweise und Anregungen bin ich natürlich auch froh und dankbar!
Hallo, > ABER SOBALD TX einmal gesetzt wurde, spinnen alle Register rum und ich kriege >die nicht wieder kontrolliert und kann demnach auch kein vernünftigen Modus >mehr herstellen Genau dieses Problem hatte ich noch nie. Zur Verbindung mit der 5V-Welt habe ich immer Widerstände dazwischen gehabt. 1k vom uC zum RFM und 2,2k für die andere Richtung. Dabei die 3,3V so belastet, daß sie nicht durch die Signale hochgezogen werden können, wenn die internen Schutzdioden des RFM leiten. Das haben bisher alle überlebt. Andernfalls könnte die HF auf den Leitungen für eine stehende Welle sorgen, wenn der TX-modus lauft. Probiere doch mal, die Leitungslänge zu ändern, besser zu kürzer hin, da das Teil kaum richtig an GND liegt. MfG
Christian S. schrieb: > Genau dieses Problem hatte ich noch nie. Zur Verbindung mit der 5V-Welt > habe ich immer Widerstände dazwischen gehabt. 1k vom uC zum RFM und 2,2k > für die andere Richtung. Dabei die 3,3V so belastet, daß sie nicht durch > die Signale hochgezogen werden können, wenn die internen Schutzdioden > des RFM leiten. Das haben bisher alle überlebt. > > Andernfalls könnte die HF auf den Leitungen für eine stehende Welle > sorgen, wenn der TX-modus lauft. Probiere doch mal, die Leitungslänge zu > ändern, besser zu kürzer hin, da das Teil kaum richtig an GND liegt. Also zusammengefasst werde ich jetzt ändern: 1) Die Leitungen von SPI verkürzen. 2) Mittels eines Levelshifters die 5V-SPI-Leitungen auf 3,3V runtertransformieren 3) Zusätzlich noch Widerstände zwischen µC und RFM: - auf MOSI, SCK und SS jeweils 1kOhm - auf MISO 2,2 kOhm Falls ich etwas falsch verstanden habe, sagt Bescheid! Ansonsten hoffe ich bis Mittwoch alles ausprobiert zu haben!
Am einfachsten wäre wohl, einen Arduino mit 3,3V Betriebsspannung zu verwenden oder bist du aus anderen Gründen auf die vollen 16MHz und/oder die 5V angewiesen? Im Übrigen sollte ein nicht zu hochohmiger Spannungsteiler für 5V-Signal nach 3.3V Signal reichen und z.B. ein 74hct125 für die Gegenrichtung. Ein ATmega mit 5V erkennt saubere 3.3V Signale noch als high, wenn auch mit stark reduziertem Störabstand, also kurze Kabel und sauberes Massekonzept.
Hallo zusammen, nur schonmal ein kleiner Ausblick: Habe NUR SCK mittels eines einzelnen Shifters auf 3,3V transformiert und die Übertragung klappt gut!!! Hatte dann einmal MISO, MOSI und SS auch auf die 3,3V transformiert. In dieser Konstellation ging es leider nicht. Ich vermute es liegt an den einzelnen Levelshiftern. Die sind halt unidirektional und somit können zwar gut die 5V Signale vom µC auf die 3,3V geregelt werden, aber wenn das RFM antwortet, werden dessen 3,3V Signale nur auf ca. 2,8V Richtung µC transformiert. Ob der UNO diese dann als HIGH erkennt ist halt die Frage. Bei SCK wird der Takt ja quasi von dem UNO vorgegeben und es kommen keine Antworten vom RFM über diese Leitung. So erkläre ich mir das. Hier der Link zu meinen Levelshiftern: https://www.amazon.de/Pemenol-Converter-Adjustable-Transformer-Efficiency/dp/B07FSLGPR8/ref=sr_1_10?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=3%2C3V+to+5V&qid=1588742678&sr=8-10 Also ich bin schonmal froh, dass es so überhaupt funktioniert. Jetzt ist noch die Überlegung, ob ich mir etwas bidirektionales besorge. Sowas hier vielleicht: https://www.amazon.de/AZDelivery-TXS0108E-Converter-Arduino-Raspberry/dp/B07N7FFY2Q/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=AZDELIVERY+5+x+TXS0108E&qid=1588742882&sr=8-1-spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUEyR0xFRkRLSlZCUkZZJmVuY3J5cHRlZElkPUEwMjc3MzY4MVYzQzNFVDVURTkwOCZlbmNyeXB0ZWRBZElkPUEwNjk0MTc3M0k0NUNCTjdRMFpYQyZ3aWRnZXROYW1lPXNwX2F0ZiZhY3Rpb249Y2xpY2tSZWRpcmVjdCZkb05vdExvZ0NsaWNrPXRydWU=
SPI hat nichts bi-direktionales. SCLK: Arduino -> RFM MOSI: Arduino -> RFM MISO: RFM -> Arduino CS: Arduino -> RFM Der min. Levelshifter wären Spannungteiler an den Arduino-Ausgängen mit 1K zu 2K2, also grob 2/3 und 2K2 in der Rückleitung zu MISO. Dabei kommt die Hoffnung ins Spiel, daß der Arduino die >3V sicher als high erkennt.
Dein erster Link zu den "Levelshiftern" stimmt sicher nicht! Das sind Spannungsregler, die aus 5V 3.3V machen! Zum Down-Shiften reicht ein Spannungsteiler normalerweise aus. Was Aktives brauchst du nur, um den Pegel anzuheben.
> Falls ich etwas falsch verstanden habe, sagt Bescheid!
Hast Du richtig verstanden.
MfG
Hey Leute, ich habe seit heute den LevelShifter und Arduino mit Rfm69 läuft seitdem jetzt wie Butter!!! Richtig gut. Eure Tipps waren echt Gold wert! Jetzt kommt die letzte Hürde und zwar die Umstellung vom UNO auf einen ATTiny84. Das tolle dabei ist, die SPI-Verbindung zwischen Tiny und RFM habe ich schon einrichten können und sie funktioniert auch, was mir durch richtiges Registerauslesen gezeigt wird. Alles läuft demnach genauso wie bei der UNO-RFM-Konstruktion, außer dass ich jetzt mit meinem Empfänger nichts mehr empfange...also die Register werden richtig beschrieben, aber warum nichts ankommt weiß ich nicht. Hat da jemand vielleicht ne Idee? Wenn ich das mir eurer Hilfe noch irgendwie hinbekommen täte, wäre das einfach ein riesen Ding für mich! :)
Hallo, niemand weiß, ob für Dein Programm die 512 Bytes Ram des Tiny84 ausreichen, oder ob es an anderen Umständen liegt. Lauft das Programm fehlerfrei durch? MfG
Christian S. schrieb: > Lauft das Programm > fehlerfrei durch? Also das Programm läuft durchgängig fehlerfrei durch und ich kann auch in jedem Durchgang erneut die richtigen Registerwerte auslesen. Beispielsweis jedes mal im TX-Mode geht REG_OPMODE auf 12 und danach im STANDBY-Mode auf 4 zurück. Der ganze Code verbraucht 5054 bytes vom flash memory.
:
Bearbeitet durch User
Ist der Tiny der Empfänger oder wie bisher der Arduino, der offiziell als funktionierend angesehen wird? Warum sollte das Funkmodul bei gleichen Registereinstellungen und gleichem Ablauf nichts empfangen können, wenn es in der gleichen Konstellation vorher zum korrekten Empfang kommen konnte? MfG
Christian S. schrieb: > Ist der Tiny der Empfänger oder wie bisher der Arduino, der offiziell > als funktionierend angesehen wird? Also als Empfänger dient nach wie vor mein EmpfängerModul aus RFM+Uno und das hat auch wie gesagt, mit Sender RFM+Uno auch du funktioniert. Jetzt ist Sender RFM+Tiny. Warum da nichts empfangen wird verstehe ich auch nicht. Und über die serielle Auslesung der Registereinstellungen wollte ich ja nur prüfen, ob der Tiny das RFM richtig ansteuert. Da es korrekt aussieht, fehlt mir da gerade halt die Idee
Erich K. schrieb: > Also als Empfänger dient nach wie vor mein EmpfängerModul aus RFM+Uno > und das hat auch wie gesagt, mit Sender RFM+Uno auch du funktioniert. > Jetzt ist Sender RFM+Tiny. Warum da nichts empfangen wird verstehe ich > auch nicht. Und über die serielle Auslesung der Registereinstellungen > wollte ich ja nur prüfen, ob der Tiny das RFM richtig ansteuert. Da es > korrekt aussieht, fehlt mir da gerade halt die Idee Nicht wundern, habe diesen Beitrag vom Account eines Projektbeteiligten abgeschickt. Also der stammt auch von mir ! :)
Ich habe auch nochmal nachgeprüft und bei der RFM-Tiny-Konstruktion wird auch der FIFO beschrieben und nach dem TX-Mode auf Packetsend gesetzt. Also ist eigentlich alles korrekt...das kann doch nicht sein :S
:
Bearbeitet durch User
SOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO, ENDLICH GESCHAFFT!!!! ES FUNKTIONIERT MIT DEM ATTINY84 UND DEM rfm69!!!!!!!!!!!!!!!!!!! VIIEEELEN VIELEN DANK HIER AN ALLE!!!!!!!!!!!!!!!! BESONDERER DANK GEHT AN: Arduino Fanboy D. (ufuf) Christian S. (roehrenvorheizer) Carl D. (jcw2)
Warum ging es nun zu Schluß? Durch eine Korrektur eines erkannten Fehlers oder Zufall? Was ist das für ein Projekt? Schule? Uni?
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.