Guten Abend, ich befasse mich schon seit Wochen immer mal wieder mit den Pollin bzw. Hope RF Funkmodulen für 433 MHz (Empfänger: RF01 / Sender: RF02). Als Mikrocontroller nutze ich einen ATMega168PA ebenfalls von Pollin. Hierbei habe ich sehr langsam angefangen und mir beispielsweise erstmal die Grundlagen zu SPI Schnittstellen angeeignet. Da ich den SPI schon zum Programmieren des uCs nutze, verwende ich den USART im SPI Modus. Als erste Übung habe ich dann beim RF02 das Statusregister erfolgreich ausgelesen und anschließend alle Register konfiguriert die der Sender braucht. Den uC habe ich dabei auf 16 kHZ und den USART auf die langsamste Baudrate gestellt, damit ich per LEDs an allen wichtigen Ports die Bits "beobachten" kann. Ich nutze Quellcodes aus dem Forum sowie Datenblätter u.a. von Hope RF. Hierbei ist mir aufgefallen, dass die Datenblätter von Pollin, Hope RF und was man sonst noch so im Internet findet sich teils stark unterscheiden. Ich würde gerne bei Probleme hier in diesem Thread nachfragen. Problem: Nachdem ich mit dem RF02 Sender keine Probleme hatte (ob er wirklich sendet erfahre ich wohl erst wenn der Empfänger klappt) wollte ich nun beim RF01 Empfänger ebenfalls das Statusregister auslesen. Dabei kann ich anhand der LEDs am SPI (bzw. USART) sehen, dass auf der MISO (bzw. RXD) Leitung Bits kommen, die nicht zum Takt passen. Ich sende nach Datenblatt 0xxxxxx... und der RF01 scheint auch zu antworten, allerdings nicht im Takt. Statt LED an oder LED aus, dimmt die LED bei manchen Status Bits. Bei diesem Problem weiß ich gerade überhaupt nicht weiter. Hat jemand eine Idee?
Angehängte Dateien:
-
signals.jpg
370 KB
Guten Abend, ich versuche es nochmal. Ich habe mir mittlerweile die Signale mal auf ein Oszi angesehen. Im Anhang ein Bild. Kann mir jemand sagen, wieso der RF01 nicht im Takt auf meinen Status Lese Befehl antwortet, sondern viel schneller?
Hallo, wie kommen da 15 SCK-Takte zustande? Wieso hat SDI so einen seltsamen Pegel wenn kein SCK taktet? Das Signal an SDO sieht auch nicht gerade sauber aus. Warum benutzt Du nicht den SPI des Mega168? Ohen Schaltplan und Quellcode kann man dazu nichts weiter sagen. Gruß aus Berlin Michael
:
Bearbeitet durch User
Sefco schrieb: > Ich habe mir mittlerweile die Signale mal auf ein Oszi angesehen. Probier mal auf dem Oszi einen vernünftigen Screen Shot. So sieht das gar grausig aus und insbesondere fehlt die Hälfte der Informationen.
Hallo Michael, ich sende 16x 0, damit mir der RF01 seinen Status ausspuckt. Das mann da nur 15 sieht ist a) egal und b) habe ich wohl nicht schnell genug am Oszi getriggert. Der seltsame Pegel am SDI liegt an einer LED am SDI. Scheinbar schafft der uC nicht die LED zu treiben. Wenn man sie wegnimmt, liegt SDI auch auf 5 V. War mir aber auch aufgefallen und habe ich bereits geprüft. Ändert nichts. Allgemein halten die Signale die 0,3*VCC = LOW und 0,7*VCC = HIGH Regel ein. Von daher sehe ich da kein Problem. Gruß
Hallo, wenn die Oszi-Einstellungen übereinstimmen ist das jedenfalls kein H-Pegel mehr. Warum bastelt man sich solche zusätzlichen Fehlerquellen ein? Eine LED ist mit 1mA schon gut erkennbar, das sind rund 3,3k Vorwiderstand, der AVR kann 20mA treiben und dabei bricht der PEgel noch nicht so ein, was hängt da also dran? Das chaotische Signal an SDO mit den diversen Spikes sieht auch alles andere als ok aus, SDO wechselt den Pegel nur 1x pro SCK (0/1 oder 1/0 Übergang) oder garnicht (Bit bleibt auch 0 oder 1). Gruß aus Berlin Michael
Das hängt nur eine LED dran. Ich habe kein Oszi Zuhause sondern muss mit den Mitteln arbeiten die ich habe. Wie ich bereits sagte, bleibt der Pegel auf 5 V wenn die LED ab ist (und sonst hängt das nichts dran). Ich mache morgen wenn ich Zugriff auf das Oszi habe einen besseren Screenshot und liefere einen Schaltplan nach. Mir ist es jedenfalls ein Rätsel, wieso ein SPI Device (Slave) nicht auf den Mastertakt hört.
Angehängte Dateien:
-
KompletterVerlauf.jpg
320 KB -
Zoom1.jpg
320 KB -
Zoom2.jpg
320 KB -
SCK.jpg
270 KB -
Sender_StatusReadCmd.jpg
350 KB
Hallo! Ich habe nun nochmal ein paar bessere Fotos von den Signalen gemacht (sorry, dass es kein richtiger Screenshot ist, aber das Oszi wollte den USB Stick nicht akzeptieren). Im Anhang befindet sich a) Der gesamte Signalverlauf für 16 bit b) Ein Zoom auf 4 Clock Zyklen c) Ein Zoom auf 1 Clock Zyklus d) Nur das Clock Signal (es ist sauber!) und e) Zum Verlgeich der Signalverlauf über 16 bit für den RF02 Sender, bei dem die Kommunikation scheinbar korrekt funktioniert (Achtung, hier muss man zum Status auslesen nicht 0xxxx... senden, sondern 1100110000000000! Ebenfalls angehangen mein Quellcode, der in der main() nur den StatusReadCmd sendet. Die Beschaltung ist oben im Quellcode notiert. Es fällt übrigens auf, dass der RF01 immer bei fallender SCK Flanke anfängt mehrere Bits zu senden. Außerdem sendet er nur, wenn nFFS auf High liegt. Ich vermute mein Problem hat irgendwas mit dem nFFS Anschluss zutun... Und nochmal meine Fragestellung: Wieso, ignoriert der RF01 den Mastertakt und antwortet so komisch?!?
Sefco schrieb: > Ich nutze den SPI nicht, weil ich den fürs flashen brauche. SPI ist ein Bus! Das kommt sich nicht ins Gehege, wenn du den CS des Slaves per Pullup hoch bindest. Oder Widerstände zwischen Slave und SPI des Masters hängst. Dazu gibts eine Appnote von AVR.
Gut ok, aber mein USART im Master SPI Modus scheint sich nach Oszi ja absolut korrekt zu verhalten. Was sollte sich also ändern, wenn ich statt USART den SPI verwende?
Sefco schrieb: > Was sollte sich also ändern, wenn ich > statt USART den SPI verwende? Das ist eine Fangfrage! Also keine Antwort da drauf! Außer: Du hast eine Behauptung aufgestellt, und ich habe sie dir widerlegt. Ähnliches vermute ich bei deinem Problem. Du behauptest: Das Modul sendet Schrottdaten. Das Oszi Bild bestätigt dich. Diese (vermutlich falsche) Annahme verdeckt die Ursache! Meine Glaskugel sagt: Schwingungen! Stütze die Versorgung des Moduls mit einem Elko. Direkt am Modul. Sorge für kurze und sichere Verbindungen.
Hallo, ist schon ein paar Jahre her, die RMF-Sachen. nFFS muß über 10k an + wenn der FIFO genutzt wird, angesteuert muß es dann garnicht werden. Ich habe nur kurz in Deinen Source geschaut: holst Du die Betriebsspannung für den RFM aus einen AVR-Port? Qwnn ja, was soll das? Die RFM können etliche Milliampere Impulse erzeugen und haben kein Verständnis für instabile Betriebsspannungen. Zum Stromsparen haben die einen PowerDown-Mode, da reicht bei mir eine CR2032 im Gefrierfach! für 6-9 Monate. Direkt am RFM-Modul ein 10µ Elko ist auch sehr zu empfehlen, manchmal wachen die sonst aus dem PowerDown nicht auf. Gibt es ein Bild von Deinem Aufbau? Vielleicht helgen Dir meine Machwerke von damals etwas weiter. http://www.avr.roehres-home.de/sensoren/index.html Einem RFM01 muß ich in den nächsten Tagen auch noch anwerfen. Gruß aus Berlin Michael
:
Bearbeitet durch User
Sefco schrieb: > ich befasse mich schon seit Wochen immer mal wieder mit den Pollin bzw. > Hope RF Funkmodulen für 433 MHz (Empfänger: RF01 / Sender: RF02). Als > Mikrocontroller nutze ich einen ATMega168PA ebenfalls von Pollin. > > Hierbei habe ich sehr langsam angefangen und mir beispielsweise erstmal > die Grundlagen zu SPI Schnittstellen angeeignet. Da ich den SPI schon > zum Programmieren des uCs nutze Nein, das tust du wahrscheinlich nicht. Was du tatsächlich benutzt, dürfte ISP sein. Das ist was anderes, auch wenn es bei vielen (aber nicht bei allen!) AVR8 teilweise über dieselben Pins abgewickelt wird. Aber genau das kann zum Problem werden, wenn du sowohl ISP als auch SPI verwenden willst. Dann muß nämlich der ISP-Programmer seine Füße zur Laufzeit still halten, was bei vielen Billich-Konstruktionen nicht gegeben ist. Da hilft dann nur: Programmer zur Laufzeit abziehen.
Ulrich F. schrieb: > Meine Glaskugel sagt: Schwingungen! > Stütze die Versorgung des Moduls mit einem Elko. > Direkt am Modul. > Sorge für kurze und sichere Verbindungen. 2,2 uF parallel zu 100 nF an VCC und... Michael U. schrieb: > holst Du die > Betriebsspannung für den RFM aus einen AVR-Port? Qwnn ja, was soll das? ...jetzt direkt vom Labornetzteil. Bringt nichts. Sendet immer noch Schrott. c-hater schrieb: > Nein, das tust du wahrscheinlich nicht. Was du tatsächlich benutzt, > dürfte ISP sein. Das ist was anderes, auch wenn es bei vielen (aber > nicht bei allen!) AVR8 teilweise über dieselben Pins abgewickelt wird. Ich habe versucht das Modul am SPI zu betreiben, während mein ISP Programmer daran hingt und es hat nicht funktioniert. Deswegen habe ich mich für den USART im Master SPI Modus entschieden. Michael ich wäre dir sehr dankbar, wenn du noch eine Idee hättest. Scheinbar hast du mit dem Modul ja schon gearbeitet. Ich habe nFFs über 10k an +.
Sefco schrieb: > Hierbei ist mir aufgefallen, dass > die Datenblätter von Pollin, Hope RF und was man sonst noch so im > Internet findet sich teils stark unterscheiden. Nimm die originalen von Hope, da ist so gut wie alles richtig. Ich würde gerne mal fragen, was du mit dem DCLK/CFIL/FFIT Pin anstellst. Diesen Pin lege ich in meinen Anwendungen auf einen soften Pullup (für zukünftige Spielereien auf einen Porteingang mit aktiviertem Pullup). So ein SDO Signal jedenfalls deutet darauf hin, das der Chip ernsthafte Probleme mit der Stromversorgung hat, oder du Glitches auf deiner SCLK hast, die das Oszi nicht auflöst. Für das Empfangsmodul ist es wichtig, das es eine saubere, verdrosselte Betriebsspannung bekommt und möglichst ein paar Dämpfungswiderstände in den Datenleitungen hat. Mit einem solchen Modul gehen dann auch mal 200m auf 868MHz, wenn man z.B. DECT Antennen aus alten Schnurlostelfonen benutzt. Ich kann dir gerne mal Arduino-kompatible Routinen posten, die aber in ASM sind, weil ich das damals toll fand. Allerdings nehme ich Bitbanging und keine USART oder SPI Peripherie - einfach deswegen, weil ich das Pollin Modul so verdrahtet hatte, das ich es direkt auf den Arduino aufstecken konnte und damit die Pins festgelegt waren. Ich löte bei allen RFM01/02 Modulen immer direkt einen 1 - 2,2µF Elko unten auf die Platine, um die Betriebsspannung abzublocken und habe damit gute Erfahrungen gemacht.
:
Bearbeitet durch User
Matthias S. schrieb: > Ich würde gerne mal fragen, was du mit dem DCLK/CFIL/FFIT Pin anstellst. DCLK/CFIL/FFIT Pin liegt bei mir offen, genau wie CLK, nRES und VDI, weil es Ausgänge sind. Ich habe jetzt testweise DCLK/CFIL/FFIT über 10k an + gelegt und dies führt dazu, dass über SDO keine Daten mehr kommen. Lege ich ihn über 1k an + dann kommen wieder Schrottdaten. Matthias S. schrieb: > Nimm die originalen von Hope, da ist so gut wie alles richtig. Habe ich auch gemacht. Wobei ich mich immer wieder über manche Dinge stark wunder. Zum Beispiel muss man die Clockpalarity ändern beim Statusregister auslesen (deswegen habe ich zwei Sendefunktionen in meinem Code oben implementiert) oder es werden Pinne beschrieben die es garnicht gibt. Ein tolles Datenblatt!
Sefco schrieb: > Zum Beispiel muss man die Clockpalarity ändern beim > Statusregister auslesen Hmm, davon ist mir nichts bekannt, allerdings benutze ich, wie gesagt, kein Hardware SPI. Ich hänge dir einfach mal eine funktionierende ASM Routine an, mögl. hilfts ja. Es ist wichtig, nach jedem erfolgreichen Empfang den FIFO zu resetten. Wenn mein Empfänger etwa 10s keine Daten empfängt, wird das auch ohne Empfang immer mal wieder gemacht. Beachte, das ich die 868Mhz Module benutze und nicht 433Mhz.
Hallo, ich werde morgen wohl mal den RFM01 anwerfen, von einer abweichenden Clock-Polarität ist mir nichts bekannt. Im Gegensatz zum RFM02 ist der RFM01 dem RFM12 recht ähnlich zu bedienen, die habe ich als Empfänger ohnehin in Benutzung. Das Original müßte der SiLabs Si4320 sein, ich habe dessen Datenblatt mal angehängt. Gruß aus Berlin Michael
Michael U. schrieb: > von einer abweichenden > Clock-Polarität ist mir nichts bekannt. Sorry, ich habe mich in den Begriffen geirrt. Ich meine die Clockphase. "...Data bits on pin SDI are shifted into the device upon the rising edge of the clock..." "The status information...Bits are shifted out upon the falling edge of CLK signal." Michael U. schrieb: > Das Original müßte der SiLabs Si4320 sein, ich habe dessen Datenblatt > mal angehängt. Vielen Dank! Sieht interessant aus! Das schaue ich mir mal näher an, wobei Hope das scheinbar nur kopiert hat. Bin mal gespannt was du rausbekommst, wenn du den RF01 anwirfst. Grüße aus Aachen!
Hallo, ich habe den RFM01 zwar schon statt des RFM12 raufgelötet, muß aber noch die Registerzuordnung und die Werte anpassen, das wird erst morgen was. Gruß aus Berlin Michael
Guten Abend, mir ist übrigens erst später aufgefallen, dass ich laut Datenblatt beim Lesen des Statusregisters Bits bei fallender Flanke senden muss. Wenn ich das tue, dann bekomme ich garkeine Antwort vom RF01. Die Schrottdaten kommen immer nur, wenn ich Bits bei steigender Flanke sende. Ich muss also eigentlich die Fehlerbeschreibung korrigieren: Eigentlich antwortet der RF01 garnicht. Oder kann es richtig sein, dass alle Status Bits 0 sind?
Sefco schrieb: > Eigentlich > antwortet der RF01 garnicht. Oder kann es richtig sein, dass alle Status > Bits 0 sind? Wenn du dir mein ASM mal anschaust, siehst du, das ich gar nicht weiter Status auslese, wenn das erste Bit null ist. Das bedeutet nämlich, das der RFM01 die 'Magic Bytes' (0x2D, 0xD4) nicht empfangen hat und im Rest nur Müll steht, bzw. unbrauchbare Hausnummern.
Hallo, ich hatte leider noch keine Zeit mit dem RFM01 weiter zu machen... Der RFM01 scheint sich ineine Punkt wie der RFM12 zu verhalten: das FIFO-Bit liegt statisch an. SDI und SCK auf Low, dann nSEL auf Low und man kann direkt an SDO den FIFO-Status lesen. Man muß also garnicht erst einen Takt schicken, Habe ich bei RFM12 auch so gemacht. Wenn man keine anderen Interruptquellen braucht, bleibt nIRQ dann auch frei. Gruß aus Berlin Michael
Hey, vielleicht habe ich doch irgendein EMV Problem. Manchmal sendet er auch Schrottdaten wenn ich den Befehl per fallender Flanke schreibe. Dies passiert sehr selten. Ich glaube auch schon 2 Mal richtige Daten gesehen zu haben, aber das ist alles nicht reproduzierbar. @Matthias: Ich danke dir für deinen Code, aber ich bin nicht sehr ASM fit. Deswegen bringt mir der Code nicht viel. Ich habe außerdem viele Beispielcodes zu dem Problem, daran scheint es nicht zu liegen. Da ich meinen Code hier auch angehangen habe denke ich, wenn ich was falsch gemacht hätte, hätte man mir das schon gesagt bei den schlauen Kollegen hier :D @Michael: Ich setze große Hoffnungen in deinen Versuch. Wenn du das nicht hinbekommst, werde ich die Module wohl in den Müll schmeißen müssen.
Hallo, naja, wegwerfen wäre auch schade... Ich habe im Moment das Problem, daß ich damals die RFM01 für den Empfänger nicht genommen habe sondern den RFM12, weil ich evtl. auch senden wollte. Ist aber nie eingebaut worden. In die Datenblätter und die Source habe seit über 5 Jahren nicht mehr reingeschaut, es gibt etliche Unterschiede zwischen den Registern und den Einstellungen zum RFM12. Einziger Vorteil ist, meine 6 Sensoren senden mir rund alle Minute ein Telegramm und mein Testmodul hat im Moment einen Mega8 und einen FTDI drauf, also reicht ein Terminalprogramm am PC für Debug und Datenausgabe. Die Routinen sind ohnehin Software-SPI, da ändert sich eigentlich kaum was. Empfänger einschalten, FIFO rücksetzen und neu starten und Empänger ausschalten haben aber auch andere Kommandos als der RFM12. Daten holen vom RFM01 ist auch anders als beim RFM12, der hat für FIFO Read ein extra Kommando. Deine Sourcen habe ich noch nicht im Detail angeschaut, es war mir vorerst zuviel Vergleiche mit dem Datenblatt. Gruß aus Berlin Michael
Hallo, @ClockneSo: um es jetzt mal direkt zu sagen: Blödsinn! SDI und SCK hängen an AVR-Ausgängen. Da gibt es keine undefinierten Pegel. Ausnahme ist, wenn man den AVR schlafen schickt. Dann muß aber ein PullUp beim RFM (egal ob 01/02/23) an nSEL, damit der RFM nicht aktiv werden kann. Dann sind ihm die Pegel an den anderen Leitungen egal. Dz kannst Dir meine Schaltungen gern auf http://www.avr.roehres-home.de/sensoren/index.html anschauen. Die laufen schon seit 2009 so. @Sefco: ich hoffe, daß ich die ZEit jetzt am Wochenede finde, den Rest anzupassen. Irgendwie stört das nahende Weihnachten etwas... ;-) Gruß aus Berlin Michael
Michael U. schrieb: > SDI und SCK hängen an AVR-Ausgängen. Da gibt es keine undefinierten > Pegel. ClockneSo schrieb im Beitrag #4395122: > Was hat der AVR-Ausgang mit den Pegelverhältnissen zu tun? Ein Ausgang ist entweder High oder Low, was ist daran denn undefiniert? Ich kann da deiner Argumentation nicht so ganz folgen. Wieso sollte ich die Leitungen zusätzlich irgendwo hinziehen? Mein SDO beispielsweise liegt wenn ich nichts sende auf High (sehe ich an einer LED die an ist). Wieso sollte ich da nochmal einen Pullup dranlöten? Michael U. schrieb: > @Sefco: ich hoffe, daß ich die ZEit jetzt am Wochenede finde, den Rest > anzupassen. Irgendwie stört das nahende Weihnachten etwas... ;-) Kein Problem, hauptsache du vergisst mich nicht :) Ich denke darüber nach, mir RF12 Chips zu kaufen. Mal sehen ob es damit besser klappt.
ClockneSo schrieb im Beitrag #4395084:
> Zum Beispiel nen "24C08" - dann läufts...
Du möchtest also einen I²C Bus EEPROM an SPI anschliessen? Das ist nicht
nur unsinnig, sondern kann auch wirksam den SPI Bus blockieren. Nein,
nein, sowas ist nicht nötig oder sinnvoll.
Um die Empfindlichkeit des Empfängers zu verbessern, kann man ein paar
Dämpfungswiderstände mit so 33-100 Ohm in die Leitungen legen, es geht
aber auch ohne. Wichtig ist eine saubere Betriebsspannung für das RFM
Modul, was man mit Verdrosselung und Abblocken (CLC- aka PI-Filter) gut
erreichen kann und eben die saubere Behandlung der SPI Kommunikation.
Das RFM01 arbeitet hier zusammen mit dem RFM02 seit Jahren ohne Störung
- es geht also.
:
Bearbeitet durch User
Hallo, mit der Betriebsspannung hatte ich nur das Problem, daß die RFM nicht immer aufwachen wenn sie aus einer §V-Li-Zelle betrieben wurden. ich habe dann dicht am Modul einen 10-22µ plaziert, das behob das Problem zuverlässig. Gruß aus Berlin Michael
Matthias S. schrieb: > Das RFM01 arbeitet hier zusammen mit dem RFM02 seit Jahren ohne Störung > - es geht also. Wieso hört das *****teil nicht auf meinen Takt? Das macht mich noch wahnsinnig...kann mir mal irgendjemand einen Schaltplan geben oder mir sagen was ich falsch mache?
82 Ohm bei SDI, SDO und SCK eingelötet. Weiterhin kommen entweder keine Daten oder Schrottdaten. Ist das eigentlich richtig, dass der nIRQ dauerhaft high ist?
Angehängte Dateien:
-
Screenshot.jpg
230 KB
Hallo, so, ich habe meinen Kram mal angepasst. Status-read habe ich nicht drin, ich habe die Sourcen meiner "Gegenstelle" mal mit rangehangen, die läßt sich auch ohne Sensoren mit wenig Anpassung in der config.h zum Testen mißbrauchen. Da ich gegenüber dem RFM12 wenig ändern wollte, lese ich den FIFO per FIFO-select an nFFS aus. Ich habe also nur die Init-Kommandos angepasst nach Datenblatt, außer Frequenz und Baudrate ist alles unverändert. Baudrate ist wegen eines uralten Fehlers irgendwas um 21000 Baud, sollte eigentlich 19200 werden... Ist nie aufgefallen, da ich ja bei allen meinen RFM die geliche Baudrateneinstellung genutzt habe. Ansonsten ist nur FIFO-Read an den RFM01 angepasst. Status Read ist nicht drin, kannst Du aber einfach nachrüsten, bleibt ja nur RFM01_FIFO (nFFS) auf High und es werden 16 Bit geholt. Nun darfst Du weiter fragen, jetzt bin ich wieder etwas drin. Schaltpläne sind ja auf meiner Webseite (Uni-Sensor und USB-Empfänger), beim USB natürlich den RFM01 statt des RFM12 nehmen und die Verbindung nFFS mit PC4 nachrüsten. Ach so: SPI ist Software, alle RFM-Pins müssen auf einem Port liegen oder Du mußt die Software umbauen, außerdem ist es für einen Mega8, mußt Du also auch anpassen. PS: sehe gerade im Screenshot, habe den Text nicht auf RFM01 geändert... Gruß aus Berlin Michael
:
Bearbeitet durch User
Vielen Dank für deine Mühe! Der RFM01 funktioniert also bei dir richtig? Ich werde in den kommenden Tage das Ganze mal mit Software SPI und deinem Code probieren. Ich habe ja noch nicht wirklich versucht etwas zu übertragen. Aufgrund der Tatsache das ich Schrottdaten erhalte gehe ich davon aus, dass etwas ganz massiv falsch läuft. Mich würde daher mal extrem interessieren, was passiert wenn du einfach mal den Status ausliest. Wenn du kein Oszi hast könntest du es ja wie ich mit einer LED prüfen. Ich denke du wirst genau wie ich garnichts zurückbekommen, weil deine Clockphase falsch ist. Wieso schickt eigentlich jeder der dieses Modul nutzt diesen Befehl
1 | RFM01_send_cmd(0x0000); // Status read |
und das ohne die Antwort auszuwerten. Bin ich der Erste der das probiert? Betreibst du den Mega8 @ 1 MHz?
Sefco schrieb: > Wieso schickt eigentlich jeder der dieses Modul nutzt diesen Befehl > RFM01_send_cmd(0x0000); // Status read > > und das ohne die Antwort auszuwerten. Bin ich der Erste der das > probiert Das ist der übliche Dummy Read, um etwaigen Müll im Register nach einem Power ON Zyklus rauszuschieben. nIRQ benutze ich beim RFM01 nicht, beim RFM02 benutze ich es als Sendetaktgeber, mit jedem Impuls wird ein Bit rausgeschoben, macht Michael auch in der 'rfm02_send_byte()'. Sefco schrieb: > Weitere 22 pF an VCC, nützt nichts. Mach da mal lieber 22µF oder wenigstens 2,2µF, dann wird da ein Schuh draus. Ich löte immer einen 2,2µF SMD direkt unten aufs Modul und speise über eine Drossel mit 22-100µH.
:
Bearbeitet durch User
Die RFM01/02 sind uralte Schinken, ich würde die nicht mehr verwenden, wenn es sich um mehr als kurzfristige Experimente handelt. M.E. könnten die jederzeit eingestellt werden. Es gibt zig neuere von Hope und die sind nicht relevant teurer.
Hallo, Status Read war in irgendeinem Software-Beispiel bei HopeRF mit drin, ich meine sogar, daß es in einem der Datenblätter ein Anmerkung dazu gab. Status lesen habe ich in der ASM-Version drin, geht auch, die C-Versionen waren damals meine ersten Versuche in C zu programmieren, ist mehr oder weniger die 1:1 Umsetzung der ASM-Version. Ich werde es mal nachher einbauen. Zum Zeitverhalten: Ruhezustand von SCK ist Low, die RFM ändern die Daten an SDO mit der fallenden Flanke von SCK, die sind stabil bis zur nächsten fallenden Flanke. Einlesen bei SCK auf H ist also richtig. Das trifft auch beim Lesen des FIFO mit nFFS auf Low beim RFM01 zu, Also genauso. Übernommen werden die Daten mit steigender Flanke von SCK und müssen für SCK High stabil bleiben. Die Timingsdiagramme sind da eindeutig. Was das FOFO-IT-Flag angeht: der RFM02 legt wie auch der RFM12 den Status auf SDO, wenn SDI und SCK auf Low sind ind nSEL auf Low geht. Ich warte dort auch nur auf diese Statusänderung, eigentlich empfiehlt der Hersteller, wenigstens die ersten 4 Bit vom Status zu lesen, mache ich aber hier nicht. Beim Lesen vom Staus werden etliche Status-Bits gelöscht, ein zweits Lesen ergibt dann also sowieso meisten alles 0. Ich hänge mal meine Logiganalyzer nacher mal ran, ich hoffe, der lebt noch. http://www.avr.roehres-home.de/logikanalyzer/index.html Oszi hänge ich auch mal an SCK und SDO, mal schauen, daß ich das nacher alles noch schaffe. Gruß aus Berlin Michael
Angehängte Dateien:
-
Status.jpg
240 KB
Hallo, habe Dir die Statusanzeige mal schnell eingebaut. Wenn Du in main() RFM01_read_fifo(data_buf, paket_len); und show_sensor(data_buf); auskommentierst bekommt Du nur das Statusregister ständig gelesen, macht zwar wenig Sinn, hilft aber vielleicht... Ich gehe jetzt mal in die Bastelbude messen. Gruß aus Berlin Michael
Angehängte Dateien:
-
Command-Send.jpg
230 KB -
Status-Read.jpg
230 KB -
FIFO-Read.jpg
240 KB -
Status-Oszi.jpg
240 KB -
Status-Oszi-Zoom.jpg
240 KB
Hallo, sorry, gibt jetzt nur Screenshots und Fotos, in meine LA-Software wollte ich eine Speicherfunktion einbauen, wollte... Der "Oszi" hat zwar USB und kann Bilder speichern, die Software ist aber nicht auf dem Notebook und auch nicht zu finden... Das Kommando, was ich erwischt habe, ist 0xC080 wie man abzählen kann. Im Oszi-Bild sieht man auch, daß der RFM01 die Daten mit der fallenden Clockflanke ändert. ist SCK und SDO, getriggert mit nSEL. Gruß aus Berlin Michael
:
Bearbeitet durch User
Hey Michael, wenn ich das richtig sehe, klappt bei dir das Status lesen. Es kommt etwas "normales" zurück. Ich habe folgendes getan: * SPI Bus hängt bei mir nun an PORT D und der Quellcode ist auf diesen Port umgebaut * Es sind Kondensatoren an VCC um die Spannung zu stabilisieren (am RFM01) * 82 Ohm Widerstände im Datenbus (SPI, SDO, SCK und nSEL) * nFFS hat zusätzlich einen 10k Widerstand an VCC * An beiden GNDs habe ich - Angeschlossen * An VCC ist + * Spannungen stimmen, ich habe nachgemessen (auch nSEL) * LEDs an SDI, SDO und SCK * Sonst alle Pinne offen * CPU Frequenz ist 16 kHz * In deinem Quellcode habe ich deine Temperatur und Luftfeuchtigkeitsfunktionen aus dem Quellcode entfernt * In der main() wird nur RFM01_init() ausgeführt und in der while()-Schleife rufe ich permanent status = RFM01_read_status() auf. Resultat: Der RFM01 antwortet mit Schrottdaten. Ich bin mit meinem Latain am Ende. Einen Hardwaredefekt habe ich bereits ausgeschlossen, weil ein zweites RFM01 was ich hier habe genau das selbe tut. Ich glaube, und das habe ich schon mehrfach im Forum gelesen, dass diese ICs alter Schrott sind. Die Tage werde ich als letzten Versuch probieren mit deinem Quellcode etwas zu übertragen. Wenn das nicht direkt funktioniert fliegt der Scheiß in die Tonne.
Angehängte Dateien:
-
Board1.jpg
240 KB -
Board2.jpg
240 KB -
Messen.jpg
240 KB
Hallo, also ich habe seit Jahren etliche RFM-Module im Einsatz und diese machen was sie sollen. Ich könnte natürlich auch sagen, ich mag alten Schrott. ;-) Was sind bei Dir "Schrottdaten"? Was sollen die LEDs? Sind die 16kHz Takt ernst gemeint? Widerstände in den SPI-Leitugnen sind überflüssig, wenn man die Leitungen nicht gerade einen halben Meter lang macht. Ich hatte nach dem Beitrag gestern noch den Effekt, daß der RFM nicht immer sicher startete wenn ich den Kram an den USB gesteckt habe, erst ein Reset des AVR half. Vermutlich war der Init zu schnell nach dem PowerUp des RFM01. Ich habe deshalb zwischen dem Setzen der Portbist und dem Senden des erstane Kommandos noch ein _delay_ms(200); eingefügt. Auf dem ersten Bild ist unten mein altes Modul, wo ich den RFM12 gegen den RFM01 getauscht habe und mit dem gemessen wurde. Oben ist meine Beschäftigung von gerstern aben, da ich ja nun schon dabei war: der RFM01 auf dem Steckbrett an einem NodeMCU-Modul. Die I/O-Zugriffe an den ESP8266 angepasst, mich mich einer Eigenart des ESP rumgeärgert und behoben und es läuft problemlos. Auf dem anderen Bild ein RFM12 868MHz, der seit Wochen die Daten meiner E3000 Funkenergiemeßsteckdosen einließt und anzeigt, hatte noch keine Zeit, daß sinnvoll weiterzumachen. Das dritte Bild zeigt den "Meßaufbau" mit dem Oszi dran von gestern, das Überschwingen dürften dadurch auch verstärkt worden sein, stört aber nicht die Funktion. Ich hatte ja schonmal gefragt, ob es ein Bild von Deinem Aufbau gibt, andererseits kannst Du die Dinger natürlich auch wegwerfen und Dich mit anderen Modulen runärgern. keine Ahnung, ob das erfolgreicher wird. Gruß aus Berlin Michael
:
Bearbeitet durch User
Angehängte Dateien:
-
Aufbau2.jpg
240 KB -
Aufbau.jpg
1,3 MB
Michael U. schrieb: > Was sind bei Dir "Schrottdaten"? Siehe oben die Oszi Bilder. Es kommen mehrere Bits, zwischen einem Clock-Pegel wechsel. Der RFM01 hört nicht auf meinen Mastertakt und schiebt irgendwelche Bits zu schnell raus. Michael U. schrieb: > Was sollen die LEDs? Sind die 16kHz Takt ernst gemeint? Ich habe dir doch bereits erklärt, dass ich kein Oszi Zuhause habe. Wie soll ich überprüfen ob die SPI Kommunikation richtig funktioniert. Ganz einfach: Ich stelle den Takt zu niedrig wie es geht, 16 kHZ (128 kHZ Int. Osz. + 8er Teiler per Fuses) und schaue den Bits zu. Nur so kann ich ohne Oszi feststellen was auf den SPI-Leitungen los ist. Ich wüßte auch nicht was bei genügend großem Vorwiderstand gegen LEDs spricht und schon garnicht gegen einen langsamen Takt. Außerdem habe ich die Messungen mit Oszi (siehe oben) ohne LEDs durchgeführt. Anbei Bilder von meinem Aufbau.
Hallo, warum traust Du einem µC und der Hardware nicht? Ein µC macht nicht immer was er soll, er macht aber immer, was man ihm sagt. Es gibt in den Datenblättern der RFM nur Angaben zu den minimalen Zeiten beim Zugriff, ich wäre mir da nicht sicher, was die bei SPI-Takten von wenigen kHz machen. Ich habe den Oszi nach vermutlich 2 Jahren nur wegen Deines Problems überhaupt angeworfen, auch den LA. Wenn ich Debug-Infos brauche gebe ich mir die an passenden Stellen per seriell am PC aus oder hänge eine LED an einen PIN und schalte die ein, wenn ich an der gewünschten Stelle angekommen bin usw. Hast Du einen Zähler um die Ausgangsfrequenz am Clock-Ausgang des RFm zu messen? Ich setze den auf 2,5MHz, Standard ist 1MHz nach Reset. Das ist meine Schnellkontrolle ob er überhaupt Kommandos empfängt. Wenn nicht und Du hast außer den beiden Teilen noch ws dann bau Dir einen mit einem mit einem Arduino und irgendeinem Display zusammen. Du mußt ja nur TTL-Pegel und um zwischen 1 MHz und 2,5MHz bracuht man kein Genauigkeit. Man kann den RFM auch auf 1,25MHz setzen, dann reicht ein Mittelwellenradio, um das zu testen, Träger auf 1MHz oder auf 1,25MHz. Meine Oma meinte immer "der Mensch kann noch so dämlich sein, er muß sich nur zu helfen wissen" ;-) Gruß aus Berlin Michael
Mir fällt bei den Bildern deines Aufbaus auf, das du die Masse des RFM Moduls nicht direkt zum MC führst - sie verschwindet aus dem Bild. Du solltest auf jeden Fall GND direkt vom Modul zum Arduino führen, so kurz wie möglich.
:
Bearbeitet durch User
Michael U. schrieb: > warum traust Du einem µC und der Hardware nicht? > Ein µC macht nicht immer was er soll, er macht aber immer, was man ihm > sagt. Was meinst du damit? Deswegen habe ich ja LEDs angelötet. Michael U. schrieb: > Es gibt in den Datenblättern der RFM nur Angaben zu den minimalen Zeiten > beim Zugriff, ich wäre mir da nicht sicher, was die bei SPI-Takten von > wenigen kHz machen. Ja genau das habe ich gesehen. Es wäre mir aber neu, dass ein Chip Probleme mit langsamen Taktraten hat. Welchen Takt hast du? Ich versuche mal 1 MHz und 8 MHz und prüfe die Daten mit dem Oszi auf der Arbeit. Michael U. schrieb: > Hast Du einen Zähler um die Ausgangsfrequenz am Clock-Ausgang des RFm zu > messen? Ich setze den auf 2,5MHz, Standard ist 1MHz nach Reset. Das ist > meine Schnellkontrolle ob er überhaupt Kommandos empfängt. Guter Tipp. Ich nehme das Teil mir zur Arbeit und messe mal den CLK Ausgang. Dann wissen wir mehr. Michael U. schrieb: > Ich habe den Oszi nach vermutlich 2 Jahren nur wegen Deines Problems > überhaupt angeworfen, auch den LA. Dafür bin ich dir auch sehr dankbar. Ich gehe aber mal davon aus, dass du a) auch daran interessiert bist zu erfahren, wieso der RFM01 meinen Mastertakt ignoriert und b) bei mir keinen Fehler erkennen kannst. Michael U. schrieb: > Meine Oma meinte immer "der Mensch kann noch so dämlich sein, er muß > sich nur zu helfen wissen" ;-) Ein guter Spruch ;) Deswegen ja 16 kHz und LEDS :D Melde mich morgen früh mit Messwerten. Gute Nacht!
Hallo, @Matthias Sch. (Firma: Matzetronics): stimmt, habe ich glatt übersehen. Ist so ziemlich unklar, wo die Spannungen eigentlich herkommen, ein halber Meter GND-Verbindung kann noch ganz andere Effekte erzeugen. Ich hoffe ja jetzt, es sind nicht 2 völlig getrennte Spannungsquellen... Gruß aus Berlin Michael
Matthias S. schrieb: > Mir fällt bei den Bildern deines Aufbaus auf, das du die Masse des RFM > Moduls nicht direkt zum MC führst - sie verschwindet aus dem Bild. > Du solltest auf jeden Fall GND direkt vom Modul zum Arduino führen, so > kurz wie möglich. Die Spannungen sind über Krokodilklemmen miteinander verbunden. Ich bin ja zu Beginn dieses Threads gerügt worden, weil ich den RFM01 durch den GPIO meines Atmega168PA gespeist habe, deswegen habe ich extra Kabel drangelötet. Michael U. schrieb: > Ich > hoffe ja jetzt, es sind nicht 2 völlig getrennte Spannungsquellen... Wenn du nach unseren ganzen Diskussionen denkst, dass ich so bescheuert bin, dann bin ich echt enttäuscht :D
Der uC und der RFM01 werden durch ein hochwertiges Labornetzteil, dass auf 5V steht gespeist.
Sefco schrieb: > Der uC und der RFM01 werden durch ein hochwertiges Labornetzteil, dass > auf 5V steht gespeist. Alles sehr schön, trotzdem hast du ohne direkte Masseverbindung zwei schöne lange Spulen durch die Speisekabel. Also zumindest Masse musst du direkt mit dem MC verbinden. Und dann sehen deine Signale schon ganz anders aus, wirste sehen.
Matthias S. schrieb: > Alles sehr schön, trotzdem hast du ohne direkte Masseverbindung zwei > schöne lange Spulen durch die Speisekabel. Also zumindest Masse musst du > direkt mit dem MC verbinden. Und dann sehen deine Signale schon ganz > anders aus, wirste sehen. Ich habe die ca. 4 cm langen + und - Kabel vom RFM01 nun direkt auf GND und VCC von meinem uC gelötet. Und ratet mal was die LED beim SDO macht: Schrottdaten anzeigen -_-
Hallo, Sefco schrieb: > Michael U. schrieb: >> Ich >> hoffe ja jetzt, es sind nicht 2 völlig getrennte Spannungsquellen... > > Wenn du nach unseren ganzen Diskussionen denkst, dass ich so bescheuert > bin, dann bin ich echt enttäuscht :D Nö, denke ich wirklich nicht, es gibt mir nur einige Rätsel auf. Zur Masse hat sich ja Matthias schon geantwortet. Das sind dann so Dinge, die ich übersehe, weil eben ganz selbstverständlich bei mir GND und auch Ub Verbindungen erstmal möglichst kurz realisiert werden, auch auf Steckboards, und der Rest im Laufe der Jahre schon nach Gefühl (und eben Erfahrung) möglichst günstig verbunden wird. Bei meinem Logikanalyzer gab es auch Diskussionen, schon bei 50MHz hieß es, das geht auf Lochraster nicht. Geht auch bei 80MHz stabil und nicht nur in einem Exemplar. Meine Bilder habe ich auch mehr als Anhaltspunkte gepostet, der RFM am NodeMCU läuft mit 3,3V wegen der ESP-Pegel, der Spannungsregler schafft die paar mA des RFM problemlos. Die Version mit dem Display hat einen üblichen USB-Ladeadapter 5V dran. Mein (geschenkt bekommenes Labornetzteil aus dem vorigen Jahrtausend ist zwar eigentlich richtig gut, allerdings etzen die Potis ziemlich aus und ich nehme es nur selten. Sollte ich mal reparieren. Andererseits brauch ich bei den Festspannungsteilen nicht aufpassen, ob die richtige Spannung eingestellt ist... Gruß aus Berlin Michael
Ich glaube es funktioniert!!! Scheinbar hat der RFM01 wirklich ein Problem mit niedrigen Taktraten und mag keine Delays zwischen Taktflanken. Ich habe auf dem Oszi sehen können, dass SDO immer wieder kurz den Pegel wechselt wenn ich den uC mit 16 kHz betreibe. Bei 1 MHz sehe ich das nicht. Ich habe auch ohne RFM01_Init() an CLK vom RFM01 1 MHz gemessen und nach RFM01_Init() 2,5 MHz =)=)=)=) Trotzdem bin ich noch nicht so ganz zufrieden. Von jetzt auf gleich, und ich habe nicht viel geändert, kommen keine Schrottdaten mehr. Vielleicht hatte es auch irgendwas mit den LEDs zutun...ich sollte mir wirklich mal einen LA bauen. Auch ist mir aufgefallen, dass unterschiedliche Antworten vom RFM01 kommen. Aber das kann ja durchaus sein. Als nächstes probiere ich tatsächlich das Funken und mal sehr gespannt ob es klappt :)
Sefco schrieb: > und > ich habe nicht viel geändert Mögl. sinds also doch die Masseleitungen. Hol dir auch die Vcc direkt vom Arduino.
Sefco schrieb: > Trotzdem bin ich noch nicht so ganz zufrieden Warum benutzt du 10 Jahre alte fehlerhafte Module wenn es inzwischen funktionierende gibt, die sofort funktionieren?
Matthias S. schrieb: > Sefco schrieb: >> und >> ich habe nicht viel geändert > > Mögl. sinds also doch die Masseleitungen. Hol dir auch die Vcc direkt > vom Arduino. Nein, das habe ich gestern Abend doch geändert. Daran lags definitiv nicht. Christian J. schrieb: > Sefco schrieb: >> Trotzdem bin ich noch nicht so ganz zufrieden > > Warum benutzt du 10 Jahre alte fehlerhafte Module wenn es inzwischen > funktionierende gibt, die sofort funktionieren? Welche z.B. in der selben Preis Kategorie?
Die sind aktuell, haben eine Dimension mehr Funktionen und mehr Power: http://www.pollin.de/shop/dt/Njk2OTgxOTk-/Bausaetze_Module/Module/Funkmodul_HOPERF_RFM69CW_868_MHz_TX_RX.html und kosten gerade mal 1 Euro mehr....
Christian J. schrieb: > 10 Jahre alte fehlerhafte Module Wieso fehlerhaft? Bei meinen RFM01 und RFM02 gabs nie Probleme, wenn man einmal das Datenblatt kapiert hat. Conny G. schrieb: > Die sind aktuell, haben eine Dimension mehr Funktionen und mehr Power: > http://www.pollin.de/shop/dt/Njk2OTgxOTk-/Bausaetze_Module/Module/Funkmodul_HOPERF_RFM69CW_868_MHz_TX_RX.html Achtung, 3,3V - mit 5V werden sie gegrillt. Und 45 mA Strom ist ja auch nicht gerade sparsam. Ein RF02 ist mit 14 mA angegeben und der RF01 mit 12mA.
Hallo, ich kann Dir nur zustimmen, ich habe keine Fehler bemerkt. Die 5V/3,3V Problematik war der Grund mir vor kurem noch einen RFM01 868MHz zu bestellen, natürlich sind Pegelwandler kein Problem, natürlich kann ich den AVR auch mit 3,3V betreiben. Nur wozu, wenn ich schon einen fertigen Drahtverhau hier habe und nur den RFM und die Software tauschen muß. Stromverbrauch ist das zweite Argunet, mein Sensor im Gefrierfach (der liegt da seit 6 Jahren, war nur ein Test für tiefe Temperaturen...) lebt mit dem RFM02 und einem Tiny45 an einer CR2032 ca. 6-9 Monate. Bei 45mA wäre schonmal eine andere Zelle fällig, die 2032 ist eigentlich schon außerhalb ihrer Daten. Sie weiß das aber nicht und spielt trotzdem. ;-) @Sefco: erstmal schön, daß es sich jetzt offenbar meldet. Im normalen Betrieb passiert mit den Status-Bits bei der jetzigen Initialisierung ohnehin nicht viel. Das AFC-Bit kann manchmal wechseln, der Rest bleibt meist durchgehend auf 0. Ich würde Wetten abschließn, daß selbst der Hersteller der Chips nie getestet hat, wie langsam man den ansprechen kann. Es reicht ja schon, wenn das Teil intern nicht komplett statisch ist. Dann ist ein passender Takt schon Pflicht, weil die Gate-Kapazitäten nachgeladen werden müssen. War schön bei dynamischen Rams, ohne Refresh hielten sie je nach Hersteller die Daten noch fast 1s, aber nicht alle... Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > Ich würde Wetten abschließn, daß selbst der Hersteller der Chips nie > getestet hat, wie langsam man den ansprechen kann. > Es reicht ja schon, wenn das Teil intern nicht komplett statisch ist. > Dann ist ein passender Takt schon Pflicht, weil die Gate-Kapazitäten > nachgeladen werden müssen. Ja das vermute ich auch. Der Hersteller scheint nicht mal zu wissen, ob man den Status nun per falling oder rising edge ausliest. Laut meinem Oszi hier auf der Arbeit ist es nämlich rising edge entgegen des offiziellen Datenblattes. Das versteht ich überhaupt nicht... Michael U. schrieb: > Das AFC-Bit kann manchmal wechseln, der Rest bleibt meist durchgehend > auf 0. Ich habe wenn ich die Bits richtig gezählt habe wohl mal ein korrektes Empfängersignal erhalten, mal nicht. Aber das kann ja sein wenn hier irgendjemand rumfunkt.
Hallo, ja, irgendwas funkt da immer rum. Zur Flanke: schau Dir das Timingdiagramm im Datenblatt an. Der RFM ändert seine Daten mit der fallenden Flanke, danach braucht er mindestens 10ns bis die neuen Daten an SDO stabil sind und gelesen werden können. Man kann also von fallender Flanke + 10ns bis zur nächsten fallenden Flanke irgendwo lesen um den gültigen Wert zu bekommen. Beim Schreiben muß SDI spätestens 5ns vor der steigenden Flanke gültig sein (tDS) und noch für min. 5ns nach der steigenden Flanke gültig bleiben (tDH). Die Dinger sind schnell, bedenke, daß ein mit 1MHz getakteter AVR für einen Taktzyklus 1000ns braucht... Ich beziehe mich auf das Diagramm und die Tabelle im Datenblatt des SI4320 Seite 11, das hatte ich wohl oben auch angehängt. Bedenke auch, der RFM kann maximal 50ns Clocktime, also 20MHz SPI-Takt... Ausnahme ist nur das Lesen des FIFO, da sind nur 2,5MHz SPI-Takt zulässig. Gruß aus Berlin Michael
:
Bearbeitet durch User
Hallo! Endlich mal Zeit gefunden an den Modulen weiter zu spielen. Ich habe deinen Code jetzt übernommen und teilweise Dinge entfernt und auf meine Hardware angepasst. Beim Senden scheint alles gut zu gehen, denn diese Zeilen werden erfolgreich abgearbeitet:
1 | while (nIRQ_isLOW()) // auf Ende sendes letztes Byte warten -> L/H |
2 | {
|
3 | }
|
4 | while (nIRQ_isHIGH()) // erledigt, wenn IRQ wieder -> H/L |
5 | {
|
6 | }
|
7 | while (nIRQ_isLOW()) // auf Ende Power Off warten -> L/H |
8 | {
|
9 | }
|
Leider empfange ich noch nichts. Der RFM01 hängt hier:
1 | while (SDO_isLOW()) // warten bis SDO 1 -> FFIL |
2 | {
|
3 | }
|
So ganz verstehe ich auch nicht, was dort passiert. Du setzt SCK_LOW(), SDI_LOW() und anschließend nSEL_LOW(). Das entspricht dem Beginn eines Status Read Befehls. Du liest also den Status aus wenn ich das richtig verstehe und prüfst in der while Schleife ob das erste Bit eins ist, denn dieses Bit zeigt an ob im Fifo was ist. Dort hänge ich dann weil scheinbar nichts empfangen wurde. Um aber zu prüfen ob das erste Bit 1 ist, sollte man den Status Read Befehl doch dauernt schicken oder nicht?
Hallo, nein, das ist vom Hersteller extra so gedacht, siehe Datenblatt (eins der echten ;)). Wenn obige Kondition an SCK, SDI anliegt und nSEL auf Low geht, liegt sofort der Status des ersten Bits an SDO, also FFIT. Man soll dann eigentlich (wenn FFIT H ist) die ersten 4 Bit des Statusregisters lesen, um die entsprecehnden Flags zurückzusetzen. Mache ich nicht, da die zugehörigen Funktionen von mir nicht genutzt werden. Gut. die Frage, ob der RFM wirklich sendet, ist schwer zu ermitteln. Bei einem analoger TV konnte er sich auf Sonderkanl 37 bemerkbar machen, ich habe mir damals so einen China-Frequnzmesser geholt (GY560 gibt es bei ebay immernoch). Ds Ding ist zwar nicht wirklich zu gebrauchen, aber die Antennen dicht beieinander reichten, damit der beim Senden des RFM kurz den Anzeigewert änderte... Gruß aus Berlin Michael
Hallo, alles klar, ich habe Zugriff auf einen Hand-Spektrumsanalyser. Ich checke mal ob der Sender auch wirklich sendet. LG
Angehängte Dateien:
-
rfm02_send_1.PNG
100 KB -
rfm02_send_0.PNG
92 KB
Der RFM02 sendet! Folgende Config verwende ich: 434 MHz Center, +/- 60 kHZ für 1/0. Im Anhang dazu zwei faszinierende Bilder!
Gestern ist es mir ein paar mal gelungen, dass er auch was empfangen hat. Durch eine LED weiß ich ob FFIT H ist. Aber so richtig klappt es noch nicht. Ich habe folgende Fragen: - Welchen Einfluss hat die Datenrate die ich eingestellt habe? Hat das etwas damit zutun wie oft ich mein Testword sende? - Welche Bandbreite beim Empfänger empfiehlst du? Ich habe gerade alles was geht damit ich die Peaks auch sicher empfange. - Wieso schickt man mehrfach 0xAA bevor man das Sync Word sendet? - Wieso ist das Spektrum doch so breit verschmiert?
Hallo, Sefco schrieb: > Gestern ist es mir ein paar mal gelungen, dass er auch was empfangen > hat. Durch eine LED weiß ich ob FFIT H ist. Aber so richtig klappt es > noch nicht. ok, ist alles erstmal besser als nichts. ;-) > > Ich habe folgende Fragen: > > - Welchen Einfluss hat die Datenrate die ich eingestellt habe? Hat das > etwas damit zutun wie oft ich mein Testword sende? Datenrate/Bandbreite/Frequenzoffset usw. hängen miteinander zusammen, ein paar Hinweise gibt es im Datenblatt, auch zur AFC usw. Bei +-60kHz auf 200kHz oder 240kHz stellen. Geringere Bandbreite erfordert kleineren Frequenzhub, die beiden Frequenzen müssen ja durch das Filter des RFM passen. Kleinere Bandbreite ist weniger Rauschen also größere Reichweite, läßt aber nur kleinere Baudraten zu. LAN-Gain kleiner macht ihn unempindlicher, auch gegen Störungen durch andere. Also nicht viel hilft viel, ist ein Kompromiß mit den Störern im Umfeld und der Reichweite. > - Welche Bandbreite beim Empfänger empfiehlst du? Ich habe gerade alles > was geht damit ich die Peaks auch sicher empfange. Siehe oben, meine Einstellungen sind hier zumindest seit Jahren stabil auch durch Wände und aus dem Keller. > - Wieso schickt man mehrfach 0xAA bevor man das Sync Word sendet? 0xAA oder 0x55 ist eine Folge 01010101 Pegelwechseln. Die dienen erstmal dazu, daß sich AFC und AGC des Empfängers einregeln können. Im allgemeinen reichen den RFM 3x 0xaa vorneweg. Ein Fehler, der in alten Sourcecodes gern zu finden ist, ist es, den Sender zu früh abzuschalten. Es gab da dann den hinweis, ein Dummy-Byte zusätzlich zu senden. Das ist Unsinn, man muß nach dem Schreiben des letzten Bytes natürlich warten, bis der RFM das auch gesendet hat, also wieder FIFO empty gemeldet wid. Dann darf man erst ausschalten. Ist eigentlich ja auch logisch... Der RFM hat ansonsten das gleiche Problem, daß alle Funkübertragungen haben. Der Bittakt wird im Empfänger aus den Datenflanken zurückgewonnen. Wenn man jetzt z.B. 3x 0x00 oder 0xFF sendet, gibt es keine Pegelwechsel, aus den die Empfänger den Bittakt syncron halten können. Meisr nbenutzt man deshalb eine Manchester-Codierung, die hat immer ausreichend Pegelwechsel innerhalb eines Bytes. Ich habe das bei mir nicht gemacht, sende meine Daten aber größtenteils als ASCII-Daten, damit ist zumindest immer 0x1100 vorn vorhanden, das reicht dem RFM sicher um syncron zu beleiben. > - Wieso ist das Spektrum doch so breit verschmiert? Keine Ahnung, hatte nie einen SA in meiner Nähe, wenn ich mit den RFm gespielt habe... Erwarten würde ich auch eher 2 Peaks in 120kHz Abstand bei Deinen +-60kHz. Für mich war damals immer nur wichtig, daß er überhaupt sendet. Es gibt nämlich geneug Fallen in den Einstellungen und der Reihenfolge, da macht er den Sender einfach garnicht an... PS: für die Mitleser: mir ist gerade aufgefallen, daß die uralten RFM12 das Kommandobit "nur ein Syncbyte" und das Kommando 0xCExx zum Setzen des Syncbyte kennen, obwohl es bei denen in keinem Datenblatt erwähnt wurde und erst beim RFM12B auftauchte. Interessanterweise steht bei den RFM12B als Betriebsspannungsbereich nur bis 3,6V drin mit der Anmerkung, daß sie mit 5V aber nicht kaputt gehen... Warum habe ich jetzt den Verdacht, daß die RFM12B der gleiche "alte Schrott" sind? ;-) Gruß aus Berlin Michael
:
Bearbeitet durch User
Wichtige Frage: Dem Sender schickst du einen Power Management Command bei dem du a1, a0 und ex setzt. Im Datenblatt steht aber: To enable the automatic internal control of the crystal oscillator, the synthesizer and the power amplifier, the corresponding bits (ex, es, ea) must be zero in the Power Management Command. Wieso also ex = 1?
Sefco schrieb: > Wieso also ex = 1? Weil es so im Datenblatt steht - direkt dadrunter, wenn du das vom SI4020 hast: • In microcontroller mode, the ex bit should be set in the Power Management Command for the correct control of es and ea. The oscillator can be switched off by clearing the ex bit after the transmission.
Hallo, vielleicht noch als Ergänzung: die ICs der RFm-Module können auch stand-alone betrieben werden, mit Tasten dran oder digital-Ausgängen für Fernbedienungen u.ä. Mit den RFM-Modulen geht das nur nicht, weil die zugehörigen Pins nicht rausgeführt sind. Gruß aus Berlin und guten Rutsch Michael
Na prima, wieder etwas was in den anderen Datenblättern nicht steht -_- Ich habe nun mal komplett deine Settings übernommen und leider hängt er wieder weil FFIT nicht 1 wird. Hast du noch eine Idee wodran es scheitern könnte? Guten Rutsch ins Neue Jahr!
Ich habe glaube ich langsam alles versucht was geht. Ich kenne das Datenblatt jetzt fast auswendig. Trotzdem empfängt das Teil sagen wir von 100 Sendezyklen gerade 10 Mal das SyncWord und mein gesendetes Wort finde ich dann im Datenbuffer nicht wieder. Tx und Rx liegen auf meinem Tisch ca. 20 cm auseinander. - Ich habe eine lamda/4 Antenne mit 17,3 cm dran, passt doch? - Ich habe beim TX verschiedene PLL Current probiert - Ich habe das Band und die Datenrate verändert - Ich habe beim RX unterschiedliche VDIs verwendet, unterschiedliche RSSI, LNA Gains, verschiedene AFC Setting...einfach alles. - Was bedeutet TX bit synchronisation? Im Originaldatenblatt gibt es das nicht (Si4020) - Was macht die Crystal Load Capacitance beim Tx und Rx? Welchen Einfluss hat das? - Wie wichtig ist es, dass ich nach Datenblatt exakt 2,2 uF, 10 nF und 220 pF an VCC nutze? Ich gebe nicht auf :P
Hallo, schönes neues Jahr noch. Hatte noch keine Zeit, mit den RFM weiterzumachen. Hattest Du Deine aktuellen Sourcen hier irgendwo reingestellt? Könnte ich ja mal flashen und einfach schauen. Sefco schrieb: > Ich habe glaube ich langsam alles versucht was geht. Ich kenne das > Datenblatt jetzt fast auswendig. > Trotzdem empfängt das Teil sagen wir von 100 Sendezyklen gerade 10 Mal > das SyncWord und mein gesendetes Wort finde ich dann im Datenbuffer > nicht wieder. Tx und Rx liegen auf meinem Tisch ca. 20 cm auseinander. Ich kann mich jetzt nicht erinnern, wie die Empfänger auf Übersteuerung reagieren, allerdings hatte ich auch keine Probleme, wenn meine Module zum Test ca. 50cm vom USB-Empänger lagen. Laufen aber auch nicht mit voller Sendeleitung und maximaler LNA-Verstärkung. > - Ich habe eine lamda/4 Antenne mit 17,3 cm dran, passt doch? Ja, die spielen auch ohne Antenne bei 20cm Abstand und bei der Sendeleistung bekommt auch der Sender keine wirklichen Probleme. > - Ich habe beim TX verschiedene PLL Current probiert > - Ich habe das Band und die Datenrate verändert > - Ich habe beim RX unterschiedliche VDIs verwendet, unterschiedliche > RSSI, LNA Gains, verschiedene AFC Setting...einfach alles. Habe ich damals sicher auch, habe allerdings seutdem an meinen Werten auch nichts mehr verändert. Die sind sicher auch nicht otimal, Änderungen bezogen sich darauf, daß ich nicht sicher die gewünschte Reichweite z.B. aus dem Keller hatte. > - Was bedeutet TX bit synchronisation? Im Originaldatenblatt gibt es das > nicht (Si4020) Kann ich im Moment nicht zuordnen. > - Was macht die Crystal Load Capacitance beim Tx und Rx? Welchen > Einfluss hat das? Man kann die Quarzfrequnet damit möglichst genau auf 10MHz ziehen, meine stehen alle auf 11,5pF, sollte auch erst bei sehr kleinen Bandbreiten und großer Reichweite eine wirkliche Rolle spielen. > - Wie wichtig ist es, dass ich nach Datenblatt exakt 2,2 uF, 10 nF und > 220 pF an VCC nutze? Garnicht. irgendwelche Kondensatoren, vermutlich 100nF, hat das Modul drauf, bei mir eben zusätzlich noch 10..22µF dicht am Modul. Ist aber auch relativ unkritisch, solange man die Module nicht fragwürdigen Batterien versorgt wie ich. > Ich gebe nicht auf :P Nö, warum auch? Wie gesagt, wenn Du die Sourcen hier nochmal ranhängst, jage ich die mal durch den Compiler und flashe sie. Steckbrettfähige RFM habe ich noch parat und 2 Arduinos finden sich auch immer. Ich kann nur nicht versprechen, daß es heute noch klappt. Gruß aus Berlin Michael
Dir auch ein frohes Neues Jahr! Anbei mal mein Sourcecode. Wie ich das deinen Kommentaren entnehme, muss das ganze relativ unempfindlich sein. Ich muss also irgendwo noch einen groben Fehler drin haben. Vielleicht sollte ich ja doch nochmal andere Module auflöten weil die evtl. einen mitbekommen haben. Habe die Module schon im Rucksack zur Arbeit mitgenommen^^ Bin mal gespannt, ob mein Code bei dir läuft.
Angehängte Dateien:
-
RFM-Test.jpg
240 KB
Hallo, so, ich habe aus Faulheit Deine Sourcen mal in die Arduino-IDE geworfen, die nötigen Anpassungen sind ja unwesentlich und betreffen nicht Dein Programm. War nur einfacher, es mal schnell auf 2 Arduino Nano zu flashen als den Dragon rauszukramen. Mit Deinen LEDs habe ich mich nicht allzusehr befasst, ich habe mir lieber schnell die UART-Routinen reingeklebt, will ja was zum Debug haben... Empfangen wurde immer, die Daten waren aber Schrott. Einzige Änderung in rfm01.c: [code] // if (SDO_isHIGH() == (1<<RFM01_SDO)) // Bit 1? if ((RFM01_PIN & (1<<RFM01_SDO)) == (1<<RFM01_SDO)) // Bit 1? [\code] Ich habe mir Deine Macros nicht zu Gemüte geführt, ich mag das nicht so sehr, ist aber wohl Geschmacksache. Ich habe mal provisorisch ein Array mit 0 1 2 3 4 5 6 7 8 9 gesendet, wird stabil alle Sekunden empfngen und über die serielle ausgegeben. Eigentlich müßtest Du die Sourcen so wie sie sind bei Dir compiliert bekommen. Keine Ahnung, ob Du einen UART-Adapter zur Hand hast, Einstellung ist 38400 8N1. Falls Du es mit Deiner IDE compilieren willst, mußt Du die RX-Test.ino und die TX-Test.ino wieder in main.c umbenennen. Die C++-Abfrage in den .h-Dateien sollte nicht stören, sonst eben wieder löschen. Gruß aus Berlin Michael
Da sag ich doch nochmal vielen Dank für deine Mühe! Michael U. schrieb: > Mit Deinen LEDs habe ich mich nicht allzusehr befasst Sind nur zwei LEDs, mehr nicht. Diese verwende ich als Statusanzeiger. Michael U. schrieb: > Empfangen wurde immer, die Daten waren aber Schrott. Habe ich also an der von dir aufgezeigten Code stelle was falsch gemacht. Michael U. schrieb: > Keine Ahnung, ob Du einen UART-Adapter zur Hand hast Leider nein. Michael U. schrieb: > Ich habe mal provisorisch ein Array mit 0 1 2 3 4 5 6 7 8 9 gesendet, > wird stabil alle Sekunden empfngen und über die serielle ausgegeben. Letztendlich funktioniert die Funkverbindung bei dir also 1A! Da bedeutet bei mir dann ganz klar ein Hardwareproblem. Ich werde beide Funkmodule austauschen und es dann erneut probieren.
Hallo, Habe mir die Ersetzung gerade mal genauer angeschaut: ich denke, da fehlt die Klammer um RFM01_PIN & (1<<RFM01_SDO) Wenn ich nicht irre, wird == vor & verarbeitet und dann wäre das Ergebnis nicht das erwartete. if (RFM01_PIN & (1<<RFM01_SDO) == (1<<RFM01_SDO)) bei Dir if ((RFM01_PIN & (1<<RFM01_SDO)) == (1<<RFM01_SDO)) bei mir. Hat schon einen Grund, weshalb ich solche #define-Geschichten nicht sonderlich mag. Ich glaube auch nicht so recht, daß Deine Module defekt sind, möglich ist zwar alles, aber so empfindlich sind die eigentlich nicht. Und leiste Dir beim netten Chinesen einen USB-TTL-serial-Adapter: http://www.ebay.de/itm/USB-2-0-to-TTL-RS232-3-3V-5V-ch340-Adapter-seriell-converter-Arduino-RX-TX-/221685456394?hash=item339d7b9e0a:g:MtsAAOSwHnFV1YXl FTDI232, oder CP2102 oder eben CH340/341 sind ok, Profilic ist nicht unbedingt zu empfehlen. Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > Wenn ich nicht irre, wird == vor & verarbeitet und dann wäre das > Ergebnis nicht das erwartete. Das erklärt dann, wieso ich zwar manchmal was empfange, aber nicht das Wort was ich gerne hätte. Nichts desto trotz empfange ich nur sehr selten was, weshalb ich langsam von einem Hardwaredefekt ausgehe. Ich fasse die verbundenen Pinne nochmal kurz zusammen und wenn dir was falsches auffällt sagste bescheid: RFM01: FFIT/SDO <-> GPIO DATA/nFFS <-> GPIO und über 10k auf VCC alle GNDs <-> GND VCC mit versch. C's <-> VCC nSEL <-> GPIO SCK <-> GPIO SDI <-> GPIO ANT <-> 17,3 cm langer Draht alle anderen Anschlüsse Not Connected RFM02: SDI <-> GPIO SCK <-> GPIO nSEL <-> GPIO alle GNDs <-> GND nIRQ <-> GPIO FSK <-> über 10k an GND VCC mit versch. C's <-> VCC ANT <-> 17,3 cm langer Draht alle anderen Anschlüsse Not Connected ___________________________________________________________________ Michael U. schrieb: > Und leiste Dir beim netten Chinesen einen USB-TTL-serial-Adapter: > Ebay-Artikel Nr. 221685456394 Kannst du mir verraten wie man sowas sinnvoll unter Windows 10 nutzen kann? Treiber, Tools, etc? Dann kaufe ich direkt so ein Ding.
Angehängte Dateien:
-
Term.jpg
160 KB
Hallo, für CH340 und CP2102 scheint es noch keine offiziellen Win10-Treiber zu geben (ich habe noch Win7 hier). Für den FTDI gibt es welche, mußt Du notfalls den nehmen: http://www.amazon.de/XCSOURCE-Serielles-Adaptermodul-Anschluss-TE203/dp/B00YMDN2Z6/ref=sr_1_1?ie=UTF8&qid=1451851091&sr=8-1&keywords=usb+ttl+ftdi den habe ich auch hier, spielt ansonsten problemlos. FSK habe ich nichtmal angeschlossen, habe ich auf meinen Sensoren über 10k an +. Der Pegel ist aber eigentlich egal bei unserer Betriebsart. Den Rest sieht man ja auf dem Steckbrettbild. GND ist 2x angeschlossen, an der Spannung hängt oben jeweils ein kleiner Elko, ansonsten kommt die vom Arduino Nano und damit vom USB. Liegt immernoch hinter mir auf dem Tisch und sendet und empfängt. Habe am Empfänger gerade mal Reset gedrückt für das Bild. Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > Und leiste Dir beim netten Chinesen einen USB-TTL-serial-Adapter: > Ebay-Artikel Nr. 221685456394 Gerade zwei Stück bestellt. Habe auch Win7 hier =) Morgen löte ich mal die anderen RFMs dran.
Gibt es eigentlich einen Unterschied zwischen RFM01 und RFM01S1 oder so ähnlich? Ich wollte nochmal neue Module bestellen. Die 4 die ich habe, sind von Pollin. Doch langsam scheinen die RFM01 und RFM02 überall aus dem Sortiment genommen zu werden. Wie sind deine Erfahrungen mit dem RFM12B? Sonst hole ich mir davon einfach welche.
S1 kennzeichnet die die Bauform. (Stiftleiste oder SMD-Bestückung) Der RFM12 kann Senden und Empfangen gleichzeitig. Auch ist dessen ansteuerung anders. Die RFM01, RFM02, RFM12-Module werden nicht mehr hergestellt. Der Hersteller empfielt die umstellung auf RFM69
Hallo, habe gerade einen 868MHz RFM12B bei Pollin bestellt für meine E3000 Energiemeßgeräte. Der Unterschied zum RFM12 dürften nur 2 Funktionen sein und daß er nur noch für 3,3V ist. Ob Du auf dieRFM69 unsteigst bleibt Dir überlassen, mir fehlt dazu gerade die Notwenigkeit. Was mir gestern noch aufgefallen ist: wie kommt man auf die be... Idee, per #define Makros zu definieren, die wie Funktionen aussehen??? Ist das der Versuch, ein Programm unlesbar zu machen, auch für Dich in einem Jahr? Wenn in einem Sourcecode if (SDO_isHIGH() == (1<<RFM01_SDO)) // Bit 1? auftaucht, dann erwarte ich (und vermutlich auch jeder andere), daß da eine Funktion SDO_isHigh() aufgerufen wird und der Rückgabewert der Funktion mit (1<<RFM01_SDO) vergleichen wird. Stattdessen ist es nur eine Präprozessor-Textersetzung, die ganz was anderes abliefert. Makros u.ä. sollte man schon irgendwie so benennen, daß sie im Source erkennbar bleiben, da gehören keinen "Tarnklammern" an den Namen ran. Vor allem wird der Compiler da auch nie meckern, der bekommt das ja so nie zu sehen. Gruß aus Berlin Michael
Michael U. schrieb: > Was mir gestern noch aufgefallen ist: wie kommt man auf die be... Idee, > per #define Makros zu definieren, die wie Funktionen aussehen??? Da kommt man aus dem selben Grund drauf, weshalb man LED_ON() verwendet. Mir ist LED_ON() wesentlich sympatischer ist als PORTB |= (1<<5). SDOisHigh() gibt 0 zurück wenn SDO nicht High ist und !=0 wenn SDO High ist. Das entspricht doch dem Verhalten einer Funktion oder nicht? Das ich da an dieser Stelle einen Fehler hatte, weil es eben keine Funktion ist sondern ein Makro ist natürlich blöd und gib dir recht. Aber deswegen würde ich das nicht als b.... Idee bezeichnen :(
Hallo,
die Klammer sind das Problem, es ist eben keine Funktion. Es wird auch
nicht 0 zurückgegeben, es wird vom Präprozessor nur der Text ersetzt.
Du hast
if (SDO_isHIGH() == (1<<RFM01_SDO)) // Bit 1?
Deine Präprozessoranweisung lautet:
#define SDO_isHIGH() RFM01_PIN & (1<<RFM01_SDO)
Der Präpozessor ersetzt jetzt
"SDO_isHIGH()" durch "RFM01_PIN & (1<<RFM01_SDO)"
Der Compiler bekommt also
if (RFM01_PIN & (1<<RFM01_SDO) == (1<<RFM01_SDO)) // Bit 1?
zusehen und übersetzt es.
Da wird nichts zurückgegeben, darum geht es mir.
Hättest Du
char SDO_isHIGH()
{
return RFM01_PIN & (1<<RFM01_SDO);
}
als Funktion erstellt, dann würde entweder 0 oder die getzte 1
zurückgegeben.
Hättest Du
#define SDO_isHIGH RFM01_PIN & (1<<RFM01_SDO)
benutzt, also ohne die Klammern, würde man beim Lesen von
if (SDO_isHIGH == (1<<RFM01_SDO)) // Bit 1?
entweder eine Variable oder ein Macro vermuten und bei einem Problem
eben auf die Suche gehen.
Ich habe mir Dein Programm nicht komplett angeschaut, ich habe nur den
Fehler gesucht. Laut Deiner LED ist an beiden Enden irgendwas passiert
(blinkte zumindest irgendwas syncRon auf).
Also habe ich mir den UART reingehängt und die gesendeten und
empfangenen Daten ausgeben lassen.
Gesendet wurde 0xAA, angekommen ist nichts oder 0xFF.
Dann habe ich in der Empfmagsroutine fest 0xc0 in das Array geschrieben,
das kam in Deiner main ordentlich an, also wurde byte im Empfang nicht
richtig eingelesen.
Ich habe das vorerst auch nicht weiterverfolgt, was Deine "Funktion" da
macht und zurückgibt, ich habe die Abfrage einfach nur schnell direkt
reingeschrieben und es lief sofort.
Alles andere habe ich mir erst hinterher angeschaut.
Meine "Maulerei" nur deshalb, weil mir sowas durchaus auch passiert und
ich mich im Nachhinein dann ziemlich ärgere, weil ich wegen solcher
Fehler ewige Zeit verbracht habe.
Hättest Du eine Funktion gebaut, hätte ich nichts gesagt, mache ich auch
gern, eine Funktion gibt was zurück, ein Makro aber nicht.
So, genug gemault, denk drüber nach oder auch nicht. ;-)
Ich hoffe, Du empfängst auch bald was.
Gruß aus Berlin
Michael
:
Bearbeitet durch User
Michael U. schrieb: > Hättest Du eine Funktion gebaut, hätte ich nichts gesagt, mache ich auch > gern, eine Funktion gibt was zurück, ein Makro aber nicht. Sehe ich ein! Danke für den Hinweis. Michael U. schrieb: > Ich hoffe, Du empfängst auch bald was. Das hoffe ich auch. Hast du deine Module von Pollin? Ich bin nicht sicher ob die einem nicht Schrott verkaufen. Die von Pollin verfälschten Datenblätter sind eine Frechheit. Dummerweise bekommt man die Module scheinbar nurnoch bei Pollin. Und der reduzierte Preis weißt darauf hin, dass die Dinger ausverkauft werden. Ich denke ich hole mir noch welche und auch auch RFM12.
Hallo, habe die RFM alle von Pollin. Als die damals auftauchten waren die Pollin-Unterlagen ziemlich das Einzige. Chinesisch oder so von HopeRF war da nicht so der Bringer. Ich will die Module auch nicht irgendwie hervorheben, damals gab es nichts in dieser Preisklasse, die waren konkurrenzlos. Pollin verkauft durchaus auch Schrott, den muß man ja nicht kaufen (speziell bestimmte "Wunderkisten" und Sortimente, Kann man trotzdem machen, mache ich manchmal auch und ärgere mich dann über mich selbst, auch wenn es nur 5€ waren. Ansonsten habe ich von Pollin noch kein einziges defektes Bauteil bekommen. Ja, es soll schon bereits programmierte AVR als neu gegeben haben. Vermutlich waren sie sogar "neu" von einem Hersteller, der die in der Fertigung nicht mehr eingesezt hat oder von Pollin selbst, weil z.B. nicht soviele NetIO verkauft wurden wie bereits AVR programmiert waren. Wird der eben gelöscht und fertig. Inzwischen sind die Unterlagen der RFM ja alle irgendwo aufgetaucht und die Module spielen eben, wenn man etwas nett zu ihnen ist. ;-) Such mal im Mikrocontroller-Net nach RFm12. Die ältesten Posts sind wohl von 2007, von mir habe ich 2008 was gefunden. Das Pollin später nichts an den Dokus mehr ändert ist normal. Was soll ich sagen? Mein Sensor friert sich auf dem Balkon bei -9 Grad die Antenne ab, das uralte AVR-NetIO von Pollin mit der Software von U.Radig spielt auch nach 5 Jahren noch zuverlässig. Warum sollte ich also umbauen? Einige RFM02 liegen noch rum, genauso die FOST02 von damals, falls ich noch ein paar Sensoren bauen will. Letztlich kommt es immer darauf an, was man vorhat. Um Temperatur und Feuchte zu übertragen oder einen Schalter abzufragen oder ein Relais anzusteuern reicht ein Tiny und ein RFM mir aus. Ich habe auch dei nRF24L01 hier rumliegen. Ich habe aber noch nicht getestet, ob ich auf 2,4GHz Probleme mit der Verbindung z.B. aus dem Keller bekommen. Einen wirklichen Vorteil hätten die aber auch nicht, die würden auch nur ein paar Byte Daten übermitteln. Gruß aus Berlin Michael
:
Bearbeitet durch User
Angehängte Dateien:
-
Schaltungen.jpg
230 KB -
send_1.PNG
280 KB -
send_2.PNG
300 KB
- Empfänger und Sender getauscht (nacheinander) - Tatsächlich sogar 2,2 uF, 10 nF und 220 pF nach Datenblatt als SMD an beiden Modulen - Verschiedene Spannungsquellen ausprobiert (auch USB 5V) - Im Anhang das Sendespektrum von beiden Sendemodulen die ich hier habe (sieht wie im Datenblatt aus) - Im Anhang ein Bild von meinem Aufbau - Der Quellcode wurde von mir nicht mehr geändert nachdem du ihn getestet hast Trotzdem funktioniert es nicht. Mal empfange ich hiereinander 3-4 Signal, dann eine halbe Stunde garnichts mehr. Langsam fällt mir wirklich nichts mehr ein.
So mal angemeldet :P Ich befürchte das doch etwas mit dem Sender nicht stimmen könnte, obwohl das Spektrum ja gut aussieht. Der Sender hängt sich teilweise beim Starten auf und ich muss den uC mehrfach resetten. Außerdem kommt es manchmal zu Bitfehlern, wenn mein Empfänger denn etwas empfängt.
Hallo, hat der ProMini noch seinen Bootloader? Falls nein füge mal vor dem RFM-Init ein delay ein, halbe Sekunde oder so. Mein Mini hat den Bootloader drauf, damit hat der RFM etliche Zeit für seine internen Abläufe bis das erste Kommando kommt. Könnte der Grund für die unsicheren Starts sein. Die Antennen mußt Du auch nicht aufeinanderlegen, das ist eine schöne kapazitive Kopplung und der Empfänger wird so sicher übersteuert. Ein paar cm Abstand sollten das schon sein. Sorry, ich habe im Moment keine Idee, meie Steckbretter hier starten jedesmal und melden sich. Ich hatte ja nach meiner Erinnerung an Deinem geposteten Code nur diese eine Zeile geändert. Die RFM-Test, die ich oben angehängt hatte, sollten auch so spielen, eben nur die xxx.ino wieder in main.c umbenennen. Der UART stört nicht, der sendet ja nur. Gruß aus Berlin Michael
Michael U. schrieb: > Falls nein füge mal vor dem > RFM-Init ein delay ein, halbe Sekunde oder so. Delays von 500 ms hatte ich bereits nach RFM-Init, jetzt habe ich noch 1 s davor. Nützt auch nichts. Michael U. schrieb: > Die Antennen mußt Du auch nicht aufeinanderlegen Das habe ich nur fürs Foto gemacht. Ist alles egal, ob die nun 20 cm oder 50 cm oder 1 cm auseinander liegen. Michael U. schrieb: > Sorry, ich habe im Moment keine Idee, meie Steckbretter hier starten > jedesmal und melden sich. Ich habe auch keine Idee mehr. Wird wohl Zeit für RFM12B oder RFM69.
ICH HABE DEN FEHLER GEFUNDEN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! CPU Frequenz von 1 MHz reicht nicht aus! Auf 8 MHz gestellt und jedes Bit kommt an...ICH GLAUBS NICHT! Dem Sender RFM02 reichen 1 MHz scheinbar nicht aus! Dem Empfänger RFM01 schon. Das soll jetzt mal einer verstehen!? Sefco schrieb: > Welchen Takt hast du? Mist, die Frage hast du nie beantwortet :D Ihr glaubt nicht, wie schön das ist den Bits beim Übertragen zuzusehen!
:
Bearbeitet durch User
Hallo, ich rechne jetzt nicht nach. Wie hoch ist die Baudrate des RFM eingestellt? Wie lange braucht die SPI-Ausgabeschleife um die Bits rauszuschieben? Vermutlich länger als der Sender Zeit zum Senden des Bits hat. Deine Frage danach habe ich wohl wirklich übersehen. Bei mir hängt meist ein 16MHz Quarz dran, Ausnahme ist nur, wenn ich Strom sparen will. Meine Sensoren laufen mit 8MHz internem Takt. Der Empänger hat einen 16bit-FIFO, der Sender nicht. Grrr, außer zum LED blinken o.ä. habe ich wohl noch keinen AVR mit 1MHz intern laufen gehabt. Meist kommt schon wegen Debug-UART ein Quarz ran. Sefco schrieb: >Ihr glaubt nicht, wie schön das ist den Bits beim Übertragen zuzusehen! Doch, glaube ich Dir aufs Wort, geht mir durchaus auch heute noch so. Wie war mein Lieblingsspruch: Kaum macht man es richtig, funktioniert es... ;-) Gruß aus Berlin Michael
:
Bearbeitet durch User
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.