Hallöchen, Ich arbeite zur Zeit an dem Versuch mir in meinem Haus ein Sensornetzwerk mittels NRF24L01+ aufzubauen. Wie Ihr sicher schon erahnen könnt, funktioniert das auf dem Tisch bis ca. 2-3 Meter Reichweite sehr gut. Weitere Distanzen sind leider nicht drin und erst gar nicht durch Decken oder Wänden. Ich verwende fertig aufgebaute Module (aus China) des selben Typs auf dem Sender under der Empfängerseite. Die NRF24L01 sind jeweils auf selbst entworfene Platinen eingelötet und schauen mit der kompletten Antenne seitlich über die jeweiligen Trägerplatinen. Gepuffert sind sie mit jeweil 22uF Kerko direkt in unmittelbarer Nähe. Ich habe auch schon versucht noch weitere 10uF und 100nF Kerko parallel zu schalten aber ohne Verbesserung. Die Spannungsversorgung sieht für mich auch soweit stabil aus, wie auf dem PNG zu sehen. Direkt nach der obigen Flanke beginnt ein Kommunikationszyklus mit dem NRF24L01+. Im Moment ist die Payload noch auf das maximum (32 Bytes) eingestellt, aber ich denke das sollte ja auch mit 32 Bytes weiter als 3 Meter klappen. Die Datenrate habe ich von Anfang an auf 250KB und die Sendeleistung auf Maximum stehen. Als Channel habe ich auch schon quer Beet ausprobiert um den Einfluss vom WLAN auszuschließen. Retrys und Wartezeit zwischen diesen steht ebenfalls auf Maximum. Ich wäre dankbar, wenn der ein oder andere noch einen Hinweis hätte was ich noch vergessen haben könnte. Ich lese und suche nun schon mehr zwei Wochen im Internet nach möglichen Ursachen aber so langsam gehen mir die Ideen aus. Wenn Ihr noch weitere Infos von mir benötigt würde ich diese nachreichen. Gruß, Markus
Kaufe originale bei TME oder so. Und nimm die mit aufschraubbarer Antenne. Solche Probleme habe ich damit gelöst!
Markus S. schrieb: > mit jeweil 22uF Kerko direkt in unmittelbarer Nähe. Unter "in unmittelbarer Nähe" verstehe ich direkt am Pin des NRF24, das ist aber nicht der Fall. Eher kilmometerweit entfernt. Solange du nicht auch den Schaltplan zeigst halte ich mich mit (weiteren) Spekulationen zurück.
Markus S. schrieb: > nrf24l01_send.png Immer das Gleiche. In den Thread irgendwas reinmüllen ohne die Zusammenhänge klar darzustellen. Wo wird denn da gemessen? Markus S. schrieb: > Die Spannungsversorgung sieht für mich auch soweit > stabil aus, wie auf dem PNG zu sehen. Wenn das die Spannungversorgung sein soll, dann nein (Schwankung um fast ein halbes Volt). Paar Millivolt wären ok.
Ach so, Trace 2 hat 2 Volt pro Div, dann ist alles ganz anders. Dann nehme ich alles zurück und behaupte das Gegenteil.
Chregu schrieb: > Kaufe originale bei TME oder so. Und nimm die mit aufschraubbarer > Antenne. Solche Probleme habe ich damit gelöst! Ja das schreiben immer viele als erste Lösung, aber es gibt auch eine große Menge die die China Teile gut im Griff haben. Also muss es dafür eine Lösung geben. NRF Tester schrieb: > Unter "in unmittelbarer Nähe" verstehe ich direkt am Pin des > NRF24, das ist aber nicht der Fall. Eher kilmometerweit entfernt. > > Solange du nicht auch den Schaltplan zeigst halte ich mich mit > (weiteren) Spekulationen zurück. Du hast recht, die Info bin ich schuldig geblieben und den Schaltplan hänge ich hier an. Ja der eine 22uF Kerko liegt nicht direkt an den Pins, aber die zwei zusätzlichen 10uF und 100nF habe ich direkt an die Pins vom NRF modul gelötet. NRF Tester schrieb: > Immer das Gleiche. In den Thread irgendwas reinmüllen ohne > die Zusammenhänge klar darzustellen. Wo wird denn da gemessen? Sorry ich war davon ausgegangen, dass man das direkt am Modul misst und das es deswegen nicht erwähnenswert wäre. deltaY mit den Cursern gemessen sind 132mV unterschied. Du hast recht es gibt noch leichte widerkehrende Spikes zu sehen die den Unterschied auf diesem Bild auf knappe 0,5 Volt treiben. Ich habe diese schon versucht genauer zu Messen da kommt dann grob 260mV raus. Zudem konnte ich mir noch nicht erklären, wo diese genau herkommen. Sie treten immer im 11er Paket auf und von Spike zu Spike gemessen haben sie im Paket eine Frequenz von ca. 30kHz. Vielleicht hast du dazu eine Idee.
Mir fallen mehrere Sachen auf, aber auf die Schnelle: wenn dein Oszilloskp einen Einschalt-Sprung von 2V anzeigt dann stimmt doch was nicht? Oder kläre mich auf was ich nicht sehe.
NRF Tester schrieb: > Mir fallen mehrere Sachen auf, aber auf die Schnelle: wenn dein > Oszilloskp einen Einschalt-Sprung von 2V anzeigt dann stimmt > doch was nicht? Oder kläre mich auf was ich nicht sehe. Ist kein Einschaltimpuls, das hätte ich wahrlich besser sofort dabei schreiben sollen. Ich habe auf dem Kanal 2 einen Trigger gesetzt damit ich genau die Zeit erfasse wo über das Modul gesendet wird. Ist also nur ein Triggersignal.
Markus S. schrieb: > Du hast recht es > gibt noch leichte widerkehrende Spikes zu sehen die den Unterschied auf > diesem Bild auf knappe 0,5 Volt treiben. Ich habe diese schon versucht > genauer zu Messen da kommt dann grob 260mV raus. Zudem konnte ich mir > noch nicht erklären, wo diese genau herkommen. Im Bild "spikes3.png" sieht es so aus als ob dein Controller oder Funkmodul zu diesen Zeitpunkten gerade Strom zieht und der 3.3V StepDown Wandler dort nachregelt. Was für nRF24L01+ Module hast du denn gekauft? Es gibt da einerseits die blauen Module die nachgemacht sind und dann auch noch die Originalen Module. Ich nutze nur noch die mini-Module, die besitzen einen SMD-Quarz, sind etwas kleiner und haben die Kontakte an einer Seite der Platine. Hier sind die Bilder im Größenvergleich: https://www.mikrocontroller.net/attachment/261631/nRF24L01P_sd_mini_normal.jpg Bei den großen Modulen ist es öfters mal so dass sie nicht ordentlich gelötet worden sind, manche funktionieren einfach nicht! Ich habe die großen dann einfach noch mal ordentlich mit Heißluft verlötet. Bei manchen Modulen reichte es das verzinnte Pad auf der anderen Seite der Platine, unter dem Chip mit Flussmittel und Lötzinn zu benetzten, damit das Pad richtig an der Platine gelötet wird. (die haben danach jedenfalls funktioniert) Bei den neueren Modulen dieser Art gibt es dieses verzinnte Pad nicht mehr, entweder man müsste da etwas frei kratzen oder man versucht es einfach erst mal mit Heißluft. So ein Quarz im Metallgehäuse kann dadurch kaputt gehen dass man ihn auf einen harten Boden fallen lässt. Wegen dieser Empfindlichkeit bin ich zu den SMD-Versionen gewechselt. (ein kleines Gerät in der Größe eines Schlüsselanhängers oder einer Streichholzschachtel fällt gerne mal runter)
Mike J. schrieb: > Im Bild "spikes3.png" sieht es so aus als ob dein Controller oder > Funkmodul zu diesen Zeitpunkten gerade Strom zieht und der 3.3V StepDown > Wandler dort nachregelt. Funkmodul ist es nicht. Ich habe auch schon nach und nach viele Funktionen des Controllers deaktiviert, aber ich bin noch nicht auf die Lösung gekommen. Werda da aber nochmal etwas Zeit rein investieren. Dann kann ich auch noch ein paar Infos ergänzen. Mike J. schrieb: > Was für nRF24L01+ Module hast du denn gekauft? Meine sind schwarz vom lieben Chinesen neben an. Es sind die normalen (großen) Module mit normalen Pin Header. Mike J. schrieb: > Bei den großen Modulen ist es öfters mal so dass sie nicht ordentlich > gelötet worden sind, manche funktionieren einfach nicht! Was meinst du mit funktionieren einfach nicht? Falsche oder schlechte Funktion oder gar keine? Bei mir ist es ja so dass sie bis ca 3 Meter zuverlässig funktionieren und erst darüber gibt es Verbindungsabbrüche.
Markus S. schrieb: > Ja das schreiben immer viele als erste Lösung, Warum wohl > aber es gibt auch eine > große Menge die die China Teile gut im Griff haben. Bestimmt ist das so. Dein konkretes Modul evtl. nicht. > Also muss es dafür eine Lösung geben. Evtl. ist das Antennendesign bezogen auf die Parameter der verwendeten Platinen nicht korrekt, evtl. ist auch das Anpassnetzwerk vor der Antenne mit falschen/unpassenden Komponenten bestückt. Als dritte Möglichkeit bleibt noch ein mangelhaftes Design in der Chipkopie. Aaaaalso, Es MUSS also eine Lösung geben? --> Stimmt! 1. Platine neu & richtig designen, Komponenten umlöten, testen. Gehts? Ja, es war die Platine. Nein, weiter gehts: 2. Komponenten im Anpassnetzwerk tauschen/ausmessen: Gehts? Ja, es waren die Komponenten. Nein, weiter gehts: 3. Chip gegen Original tauschen. Gehts? Ja, es war der Chip, Nein? 4. Um einen Mix aus allen Fehlerquellen auszuschließen bitte jeden Test nochmal unabhängig durchführen.
Harald schrieb: >> aber es gibt auch eine >> große Menge die die China Teile gut im Griff haben. > Bestimmt ist das so. Dein konkretes Modul evtl. nicht. Ja da magst du recht haben, zumindest habe ich verschiedene Module aus verschiedenen Chargen ausprobiert, aber das selbe Ergebnis erhalten. Leider habe ich keinen orginalen NRF24L01+ vorrätig sonst wäre es natürlich einfacher von vornerein zu kontrollieren ob es am Modul liegt oder Fehler woanders zu suchen ist.
Markus S. schrieb: > Was meinst du mit funktionieren einfach nicht? Ich hatte zum Beispiel zwei Module an jeweils einen AVR angeschlossen und den hatte ich dann über den USB-COM-Port-Adapter angeschlossen. Der erste Test war einfach die Module anzusprechen und das Status-Register abzufragen. Das ging bei beiden Modulen. Dann will man ja auch mal die Module entsprechend einstellen und dann ein Zeichen verschicken. Das ging nicht. Ich hatte zum Glück ein 10er Pack der Module gekauft. Eines der Module war einfach defekt und wie ich dann mitbekommen habe auch noch zwei weitere. Man konnte mit den Modulen über SPI kommunizieren, aber der Funk hat eben nicht funktioniert. Nach dem ich unten an den Chip den Lötkolben gehalten habe und alles ordentlich heiß gemacht habe, da ging es plötzlich. Vielleicht hatte das Modul keine ordentliche Verbindung zu GND? Was immer es war, das Lötzinn ein mal ordentlich mit Heißluft flüssig machen hat es behoben. Mit den Modulen habe ich Entfernungen von leicht über 100m erreicht, aber nur mit Sichtverbindung. Wenn Wände dazwischen sind, dann kommt es darauf an, vielleicht ein oder zwei Wände kann das Modul durchdringen. Ich hatte von den Chinesen schon LED-Lampen bekommen die glänzende Lötstellen hatten, aber nachdem sie eingebaut worden sind und sie warm wurden ... da sind die LEDs langsam abgefallen. Die Lötpaste wurde einfach nur extrem kurz verlötet, so dass nur die Oberfläche ein wenig flüssig wurde. Die haben die Maschinen schneller laufen lassen und sich nicht an Temperaturprofile gehalten, einfach um schneller Geld machen zu können. Bei LEDs hatte ich bemerkt dass die Bond-Drähte andauernd kaputt gehen, da war richtig viel Arbeit und ärgerlich. Die Drähte hielten einfach nicht auf dem Chip. Der Gold-Draht selber ist nicht kaputt gegangen, sie hatten einfach die Maschinen offenbar etwas schneller gestellt um mehr Durchsatz zu bekommen. Diese LEDs haben wirklich gute und tolle, große Chips ... nur sind sie durch den systematischen Bondingfehler vollkommen wertlos. Jede einzelne dieser LEDs kann jederzeit ausfallen und bei Nennstrom betrieben fallen die ersten innerhalb von etwa 3 Tagen (3x 1h Betriebszeit) aus und dann immer mal wieder ein oder zwei bis schließlich keine mehr leuchtet.
:
Bearbeitet durch User
Markus S. schrieb: > Ist kein Einschaltimpuls, das hätte ich wahrlich besser sofort dabei > schreiben sollen. Ja, super, immer schön die Salamitaktik pflegen, gell. Bloss nicht die geneigte Leserschaft mit zuviel nützlichen Tatsachen belästigen. Das könnte ja zuuu schnell zu einer Lösung führen. Markus S. schrieb: > Ich habe auf dem Kanal 2 einen Trigger gesetzt damit > ich genau die Zeit erfasse wo über das Modul gesendet wird. > Ist also nur ein Triggersignal. Ja und wie erzeugt man bitte in solch einer Digitalschaltung die mit 3.3V läuft einen Spannungssprung von knapp zwei Volt?
NRF Tester schrieb: > Ja und wie erzeugt man bitte in solch einer Digitalschaltung > die mit 3.3V läuft einen Spannungssprung von knapp zwei Volt? In dem man einen Teil der Schaltung missbraucht um ein Triggersignal zu haben, in diesem Fall eine LED an der das Triggersignal abgenommen wurde. Ansonsten kann ich mich nur für die fehlende Information des Triggers entschuldigen, ich hatte diesen im Kopf und wollte ihn eigentlich dazuschreiben, aber es ist mir irgendwie durchgegangen. Verstehe das dies für die Personen die helfen möchten ärgerlich ist und mitunter auf die völlig falsche Fährte führen kann.
NRF Tester schrieb: > Ja und wie erzeugt man bitte in solch einer Digitalschaltung > die mit 3.3V läuft einen Spannungssprung von knapp zwei Volt? Er wird den Ausgang, der ihm anzeigt dass sein Modul gerade sendet, über einen Widerstand auf eine rote LED gelegt haben. Er wird jetzt einfach die Spannung an der LED abgegriffen haben, anstatt die Klemme direkt am I/O-Pin zu befestigen. Er nutzt die LED einfach um den Sendestatus mitzubekommen. Mit der Leuchtdauer kann er auch sehen wie lange das Modul sendet und eben auch wann genau es damit anfängt. So habe ich das auch gemacht, ist logisch so zu arbeiten. P.S.: Markus hat ja gerade alles erklärt ... und ich hatte Recht :-)
:
Bearbeitet durch User
Markus S. schrieb: > Verstehe das > dies für die Personen die helfen möchten ärgerlich ist und mitunter auf > die völlig falsche Fährte führen kann. OK, das ist akzeptabel, dagegen reden sich manche Leute um Kopf und Kragen .... Zunächst, um die Module auf Schwächen hin auszuschliessen, möchtest du nicht mal die Testprogramme versuchen? Dazu bräuchte man aller- ding mindestens zwei Arduinos. Wäre aber sehr nützlich da man damit auch eine potentielle Stromversorgungs-Problematik verändern bzw. ausschliessen könnte. Beitrag "NRF24L01+ test program for Arduino Uno" Beitrag "NRF24L01+ test program for Arduino Mega"
NRF Tester schrieb: > OK, das ist akzeptabel, dagegen reden sich manche Leute um Kopf > und Kragen .... Wenn man Fehler macht, sollte man Manns genug sein diese auch einzugestehen. Ausreden für selbst vergessenes zu suchen kosten nur Zeit und endet in Diskussionen oder weniger Personen die bereit sind am Ende noch weitere Hilfe zu leisten. NRF Tester schrieb: > Zunächst, um die Module auf Schwächen hin auszuschließen, möchtest > du nicht mal die Testprogramme versuchen? Dazu bräuchte man aller- > ding mindestens zwei Arduinos. Wäre aber sehr nützlich da man damit > auch eine potentielle Stromversorgungs-Problematik verändern bzw. > ausschließen könnte. Ja ich glaube das ist sinnvoll, mit ein paar wenigen Änderungen sollte ich deine Beispiele auch mittels Arduino auf einem Bluepill Board zum laufen bekommen, davon habe ich noch genug hier rum liegen. Arduinos auf ATMega Basis habe ich leider nicht, bin vor langer Zeit von ATMega auf STM32 umgestiegen.
NRF Tester schrieb: > Beitrag "NRF24L01+ test program for Arduino Uno" > Beitrag "NRF24L01+ test program for Arduino Mega" Ich habe gerade festgestellt, dass in den verlinkten Artikeln nur die HEX Files verfügbar sind. Gibt es irgendwo auch den Source, damit ich diesen auf den STM32 portieren kann oder wenn nicht, gibt es eventuell schon eine fertige Portierung auf den STM32F103C8T6 (BluePill)?
Die Sources werde ich nicht herausrücken da dort eine gehörige Menge Arbeit drinsteckt die ich nicht in irgendeiner Weise in Gegenleistungen zurück bekomme. Das sind keine einfach mal so aus dem Internet schnell zusammengehackte freie Sourcen sondern alles eigene Kreationen. Aber - tatsächlich - es gibt bei mir bereits seit längerer Zeit eine F103 basierte Version des Testprogramms. Ich werde nochmal drüberschauen und dann einen ausführbaren Code dafür veröffentlichen. Ein guter Anlass dafür ist nun aktuell vor- handen obwohl ich es schon längst hätte machen können.
Markus S. schrieb: > eine fertige Portierung auf den STM32F103C8T6 (BluePill) Ich sehe gerade dass ich bei der F103 Version noch keine USB Kommunikation implementiert habe. Wenn du also an die Rx/Tx Pins (10, 9) selbst etwas sinnvoll anschliessen kannst so bekommst du sehr schnell einen aus- führbaren Code.
>Die Sources werde ich nicht herausrücken da dort eine gehörige >Menge Arbeit drinsteckt die ich nicht in irgendeiner Weise >in Gegenleistungen zurück bekomme. Sehe ich auch so.
NRF Tester schrieb: > Wenn du also an die Rx/Tx Pins (10, 9) selbst etwas sinnvoll > anschliessen kannst so bekommst du sehr schnell einen aus- > führbaren Code. ... aber ich würde schon gerne vorher wissen für welchen Weg du dich entscheiden willst. Für die Rx/Tx Pins brauchst du RS232- oder USB- Konverter um an den PC zu kommen.
Ich hatte mich damals an dem hier orientiert: https://www.youtube.com/watch?v=8vbsod1bLFA&list=FLnT-6b7FQX3iK9asULfcEYQ&ab_channel=DavideGironi http://davidegironi.blogspot.com/2012/09/avr-nrf24l01-library-running-on-atmega.html Den Code hatte ich damals dann genommen: https://nrqm.ca/nrqm.ca/nrf24l01/index.html Das hier ist aber auch nicht schlecht, basiert auf dem Code von "Neil MacMillan": https://github.com/dougszumski/nRF24L01
Fällt mir dazu noch ein: Markus S. schrieb: > mit ein paar wenigen Änderungen sollte > ich deine Beispiele auch mittels Arduino auf einem Bluepill Board zum > laufen bekommen Das ist leider auch ein bisschen blauäugig bzw. unerfahren gesprochen. Einfach mal die Sourcen wie sie für AVRs geschrieben sind in eine STM32-Entwicklungsumgebung hineinklatschen und compilieren, das ist wohl nicht gaaaaanz so einfach wie du dir das denkst.
NRF Tester schrieb: > ... aber ich würde schon gerne vorher wissen für welchen Weg > du dich entscheiden willst. Für die Rx/Tx Pins brauchst du > RS232- oder USB- Konverter um an den PC zu kommen. Der ist mehrfach vorhanden und sollte auch der Weg sein NRF Tester schrieb: > Das ist leider auch ein bisschen blauäugig bzw. unerfahren > gesprochen. Einfach mal die Sourcen wie sie für AVRs geschrieben > sind in eine STM32-Entwicklungsumgebung hineinklatschen und > compilieren, das ist wohl nicht gaaaaanz so einfach wie du dir > das denkst. Vielleicht haben wir uns da missverstanden, ich wollte nicht irgendeine STM32 Entwicklungsumgebung verwenden um dann daran was zu adaptieren. Mein Plan wäre es gewesen das schon mittels Arduino IDE zu lösen, soweit das dort drin überhaupt entwickelt wurde. Das Bluepill Board ist ja dort integrierbar und wurde auch schon auf diese Weise von mir verwendet um damals die ersten Test mit dem NRF24L01 zu machen. Sollte es in einer anderen IDE entwickelt worden sein, gebe ich dir Recht ist der Aufwand deutlich höher. NRF Tester schrieb: > Aber - tatsächlich - es gibt bei mir bereits seit längerer > Zeit eine F103 basierte Version des Testprogramms. Ich werde > nochmal drüberschauen und dann einen ausführbaren Code dafür > veröffentlichen. Ein guter Anlass dafür ist nun aktuell vor- > handen obwohl ich es schon längst hätte machen können. Das würde mir ja schon vollkommen reichen und ich würde dann gerne für dich mit dem F103 das Testkaninchen spielen und eventuelle auftretende Probleme zurückspielen. NRF Tester schrieb: > Die Sources werde ich nicht herausrücken da dort eine gehörige > Menge Arbeit drinsteckt die ich nicht in irgendeiner Weise > in Gegenleistungen zurück bekomme. Das sind keine einfach > mal so aus dem Internet schnell zusammengehackte freie Sourcen > sondern alles eigene Kreationen. Das glaube ich, und natürlich ist es bei so einer Sache mit Gegenleistungen bekommen schwer. Du hast ja auch die Binaries veröffentlicht um anderen die Möglichkeit zu geben zu testen und von deiner Entwicklung zu patezipieren. Die STM32 Version wäre dann natürlich auch wieder an dich zurückgeflossen. Aber da du ja selber schon in die Richtung gearbeitet hast ist das ja nicht mehr wirklich notwendig. Dann bleibt mir an dieser Stelle dir nur zu danken, dass du eine solch rundes Testpacket erstellt hast und es breitwillig mit der Community teilst.
:
Bearbeitet durch User
Ich schätze es sehr dass du dich so ausführlich erklärst und nicht - wie so viele andere - kurze zusammenhanglose Sätze in die Beiträge wirfst. Ein "User" dem man gerne hilft. Markus S. schrieb: > Vielleicht haben wir uns da missverstanden, ich wollte nicht irgendeine > STM32 Entwicklungsumgebung verwenden um dann daran was zu adaptieren. > Mein Plan wäre es gewesen das schon mittels Arduino IDE zu lösen, soweit > das dort drin überhaupt entwickelt wurde. Das Bluepill Board ist ja dort > integrierbar und wurde auch schon auf diese Weise von mir verwendet um > damals die ersten Test mit dem NRF24L01 zu machen. Nein, die Testsoftware hat mit Arduino gar nichts zu tun ausser dass der Controller mit USB Anbindung verwendet wird. Zufällig ist diese Hardware eben weit verbreitet vorhanden, daher kann man sie leicht für diesen Zweck nutzen. Also kein "Setup", "Loop" und "DigitalWrite" etc. Auch eine vielleicht vermutete Arduino NRF24 Lib habe ich nicht verwendet. Markus S. schrieb: > Der ist mehrfach vorhanden und sollte auch der Weg sein Gut, dann wirst du ja sehr bald testen können. Ein bisschen Lötarbeit zum NRF24 bleibt dir aber nicht erspart. Bald wirst du mehr sehen ....
Hier meine Anordnung zum Testen eines NRF24L01+ mit einem BluePill Controller. Diese vorläufige Version arbeitet noch mit der USART- Schnittstelle des STM32F103C8T6, daher ist noch ein USB/Serial Konverter angeschlossen der mir das Entwickeln ohne Rücksichtnahme auf die USB Schnittstelle ermöglichte. Die USART-Schnittstelle ist auf 115200 Baud konfiguriert und verwendet die BluePill Pins Tx Port A Pin 9 Rx Port A Pin 10 Masseverbindung nicht vergessen. Der NRF24 wird so verdrahtet: ------------------------ (Bluepill) NRF24 STM32F103C8 Pin ------------------------ PA2: 8 IRQ PA3: 3 CE PA4: 4 CSN PA5: 5 SCK PA6: 7 MISO PA7: 6 MOSI Gnd 1 Gnd 3.3V 2 Vcc ------------------------ Man kann durchaus die Versorgung des BluePill Boards zum Speisen der NRF24 mitverwenden. Obwohl der NRF ja anspruchsvoll in der Peak-Stromaufnahme ist klappt die Versorgung sogar über den angeschlossenen USB/Serial Konverter. Man achte auf die zusätzlichen Abblock-Kondensatoren 22uF Elko und 100nF KerKo. Die sollten auf jeden Fall im Aufbau - möglichst wie gezeigt - vorgesehen werden. Dann sollte der NRF24 problemlos und ungestört funktionieren.
NRF Tester schrieb: > Einfach mal die Sourcen wie sie für AVRs geschrieben > sind in eine STM32-Entwicklungsumgebung hineinklatschen und > compilieren, das ist wohl nicht gaaaaanz so einfach wie du dir > das denkst. Muss man ja nicht https://circuitdigest.com/microcontroller-projects/getting-started-with-stm32-blue-pill-development-board-stm32f103c8-using-arduino-ide
NRF Tester schrieb: > Hier meine Anordnung zum Testen eines NRF24L01+ mit einem BluePill > Controller. Und hier nun der Code zum Programmieren des Bluepill Boards. Dazu noch ein Screenshot vom Testen der Kommunikation mit einem NRF24 am Druckerport und der dazugehörigen Windows-Applikation. (Beitrag "NRF24L01 - Testprogramm für Windows PC")
NRF Tester schrieb: > Und hier nun der Code zum Programmieren des Bluepill Boards. Danke für deine Arbeit, hatte am Wochenende leider kaum Zeit, aber ich versuche es mir diese Woche mal zu Gemüte zu führen und zwei Testboards mit deiner Software aufzubauen. Sobald ich daraus Ergebnisse generiert habe, melde ich mich wieder und wir können diskutieren woran es letztendlich liegt oder im schlechtesten Fall sind die Module einfach für die Tonne …
Markus S. schrieb: > im schlechtesten > Fall sind die Module einfach für die Tonne … Du gehst aber noch mal mit Heißluft rüber bevor du sie ganz abschreibst?
Die Kompensation am Schaltregler IC2 ist nicht angeschlossen, d.h. im Layout nicht geroutet. Es fehlt die Verbindung von C8 nach R10. Im Layout-Screenshot sieht mal das Airwire... Machst du keinen DRC?
Thorsten S. schrieb: > Machst du keinen DRC? Doch, der wird gemacht. Die Airwire ist mir nicht aufgefallen, da R10 und C8 direkt aufeinanderliegen (TOP+BOT). Der DRC schlägt da nicht an, selbst wenn ich die Komponenten auseinanderziehe, so dass die Airwire sichtbar wird läuft der DRC durch und gibt den Fehler nicht an. Mal abgesehen von den gebilligten Fehlern, wo dieser aber nicht bei ist. Sehr komisch.
Mike J. schrieb: > Markus S. schrieb: >> im schlechtesten >> Fall sind die Module einfach für die Tonne … > > Du gehst aber noch mal mit Heißluft rüber bevor du sie ganz abschreibst? Ja werde ich auf jeden Fall probieren. Erst einen Test so wie sie sind und schauen was als Ergebniss rauskommt. Dann nochmal das selbe mit Heißluftbehandelten Modulen.
Markus S. schrieb: > Mal abgesehen von den gebilligten Fehlern, wo dieser aber nicht bei ist. > Sehr komisch. Ohne den genauen Inhalt deiner SCH+BRD-Dateien und die von dir verwendete Version von Eagle zu kennen, ist es schwierig, dir da weiter zu helfen.
Ich würde links und rechts neben der Antenne die Kupferflächen weg lassen. Auch Bauelemente sollte es dort nicht geben. Zur Erprobung könnten man den Modulstecker um zwei, drei Zentimeter verlängern, so dass die Modulantenne über die Leiterplattenkante steht. Was empfiehlt der Modulhersteller? Beilage als Beispiel.
Mike J. schrieb: > Du gehst aber noch mal mit Heißluft rüber bevor du sie ganz abschreibst? Heißluft halte ich für ungeeignet da man als Hobby-Elektroniker erfahrungsgemäss keine Kontrolle über die Temperatur hat. Da kann es sehr schnell zu heiss werden und Bauteile gehen kaputt. Dann kann es noch passieren dass man an den heissen Lötstellen die Bauteile mit der Heissluft einfach wegbläst. Voller Erfolg! Bei diesen kleinen Modulen gibt es ja nicht viel Bauteile, da kann man mit einer feinen Lötspitze schnell mal alles nachlöten. Sogar die Pins des QFN-Gehäuses sind damit noch erreichbar.
Gerald K. schrieb: > Beilage als Beispiel. Sieht bei mir nicht viel anders aus, die Antenne schaut sauber über den Platinenrand. NRF Tester schrieb: > Heißluft halte ich für ungeeignet da man als Hobby-Elektroniker > erfahrungsgemäss keine Kontrolle über die Temperatur hat. Da gebe ich dir in soweit recht, dass man nicht den normalen Heißluftfön aus dem Werkzeugkeller nehmen sollte. Aber ich hatte mir mal vor Jahren eine Rework Station aus dem fernen Osten besorgt. Damit lassen sich die Platinen prima löten und Bauteile habe ich bisher nicht weg geblasen.
NRF Tester schrieb: > Heißluft halte ich für ungeeignet da man als Hobby-Elektroniker > erfahrungsgemäss keine Kontrolle über die Temperatur hat. Merkwürdig, ich stelle da einfach die gewünschte Temperatur ein.
Cyblord -. schrieb: > Merkwürdig, ich stelle da einfach die gewünschte Temperatur ein. .... so man Einstellmöglichkeiten hat ....
NRF Tester schrieb: > Cyblord -. schrieb: >> Merkwürdig, ich stelle da einfach die gewünschte Temperatur ein. > > .... so man Einstellmöglichkeiten hat .... Sorry ich gehe nicht davon aus, dass jemand der noch ein wenig Grütze in der Birne übrig hat, mit einer ungeregelten Baumartpistole auf Elektronik losgeht. Denn einstellbare Heißluftstationen fangen bei 40EUR an. Die von mir zitierte Aussage ist und bleibt somit humbug.
Markus S. schrieb: > Sieht bei mir nicht viel anders aus, die Antenne schaut sauber über den > Platinenrand. Ist erst mit dem Modul ersichtlich. Aber : Ist auf Trägerplatine eine durchgehende Kupferfläche unter dem Funkmodul? siehe Layout2.jpg Hinweis links unten. Ist zwar eine anderer Funkmodul, aber ich nehme an es gelten die gleichen Regeln.
:
Bearbeitet durch User
Gerald K. schrieb: > Ist auf Trägerplatine eine durchgehende Kupferfläche unter dem > Funkmodul? Kann ich nur mit jain beantworten, ja wie auf dem Bild im ersten Post zu sehen, ist die Kupferfläche auch nach dem PinHeader ausgespart, aber nicht in dem Maße wie es deine Zeichnung vorgibt. Allerdings wird bei deiner Zeichnung das Modul wie es ausschaut direkt auf die PCB gelötet, meine Module stehen Bauartbedingt ca. 10mm über der Trägerplatine.
Markus S. schrieb: > meine Module stehen Bauartbedingt ca. 10mm über der > Trägerplatine. Es bei meinem Melder auch der Fall. Man kann die Wirkung leicht mit einer Kupferfolie ausprobieren. Vielleicht hilft es. Die Antenne braucht die Massefläche als Gegenpol. Ist diese über lange Leitungen angeschlossen, dann sinkt die Abstrahlung der Antenne. Ich habe mich an die Layoutvorgabe gehalten , auch wenn der Funkmodul gesteckt ist und ein Abstand zu dieser Massefläche besteht. Wurde die Fläche freigehalten um die Beschriftung durchzuführen? Man hätte diese invers auch am Kupferlayer durchführen können. Welchen Zweck hat die Unterbrechung der Kupferfläche sonst?
:
Bearbeitet durch User
Hallo zusammen, sorry für die lange Zeit in der keine Rückmeldung von meiner Seite gekommen ist. Corona und zwei Quarantänen haben wenig bis keine Zeit gelassen mich weiter um mein Projekt zu kümmern und so musste alles auf meinem Basteltisch liegen bleiben. Am Wochenende habe ich dann endlich mal wieder Zeit gefunden die versprochenen Testaufbauten von NRF Tester zu tätigen um meine Module mit seiner Software zu testen. Und was soll ich sagen, ich verstehe danach noch weniger was los ist. Über zwei Etagen hinweg bekomme ich super Empfang und habe kaum Paketloss. Selbst über drei Stockwerke funktioniert es teilweise noch wenn auch es dort zunehmend von der Positionierung des Modules abhängt. Der sonstige Test mit der Kupferfolie unter dem NRF Modul steht noch aus und wird heute Abend in Angriff genommen, allerdings verspreche ich mir davon nicht all zu viel, denn in dem Testaufbau steht das NRF Modul auch komplett frei ohne eine Kupferfläche als Gegenpol. Wenn also von Euch noch jemand eine Idee hat warum es mit der geätzten Platine nicht genauso gut funktioniert wie mit dem Testaufbau immer her damit. Gruß, Markus
Andere Parameter bei der Initialisierung? Ich kann mit meinem China Clonen >300m machen durch 1x Wand und 1x Baum. *Mit Spiralantenne ... die Dinger können richtig gut sein. Wenn ich aber die Parameter bei der Initialisierung nur leicht ändere geht es nur noch im gleichen Raum bei sauberer Ausrichtung.
leser schrieb: > Andere Parameter bei der Initialisierung? > > Ich kann mit meinem China Clonen >300m machen durch 1x Wand und 1x Baum. > > *Mit Spiralantenne ... die Dinger können richtig gut sein. > > Wenn ich aber die Parameter bei der Initialisierung nur leicht ändere > geht es nur noch im gleichen Raum bei sauberer Ausrichtung. Wärest du so nett, deine Einstellung mit mir zu teilen. Dann würde ich probieren meine Module identisch zu konfigurieren um dann erneut zu testen ob das Reichweitenproblem damit gelöst werden kann. Zur Zeit betreibe ich meine mit voller Sendeleistung und auf 250Kbaut. An Kanälen habe ich schon in allen Bereichen probiert. Im Bezug zur Sendeleistung habe ich mit dem Testaufbau und der Software von NRF Tester gemerkt, dass diese keine riesen rolle spielt. Selbst wenn ich die Leistung komplett gedrosselt habe hatten diese noch ne 1a Verbindung zu einander.
Fuer analyse gibt es viel extra um die statistics aus zu lesen, zB NrOfRetries. Damit kann man viel besser sehen ob es beinah falsch geht. Auch haette ich mal die situation das NrOfRetries nie der fall war, immer 4 oder mehr. Da hab ich dann herausgefunden es war ein Software-fehler, wenn ich mich gut erinnere dauerte der interrupt routine zu lange dauerte. Dabei ist es gut ein spezieller testmode zu haben der da mehr details gibt. Patrick aus die Niederlaende
Markus S. schrieb: > An Kanälen habe ich schon in allen Bereichen probiert. Es wurde schon mal in einem anderen Thread spekuliert ob nicht die Auswahl der Adresse(n) eine gewisse Auswirkung auf den Erfolg der Übertragung hat. Man könnte sich ja vorstellen dass viele Einsen oder viele Nullen in Folge sich ungünstig bzw. schlechter beim Empfänger erkennen lassen.
Hi, ich habe einiges an NRF24L01p Sensoren verbaut und mittlerweile auch das Problem mit der Distanz recht gut im Griff. Hier mal meine Basics: 1.) Ein Tantal von min 100uF (besser 220uF) und einen MLCC von 100nF so nah an das Modul wie möglich. Bei den großen kann man einen 1206 MLCC oder kleiner recht komfortabel zwischen VCC und GND Pin löten. Je nach Schaltung und was sonst so an der Spannungsquelle hängt kann auch noch ein 10nF oder 1uF MLCC helfen. Ich habe einen RasPi als Basis Station und wenn ich da eine externe SSD angeschlossen habe, hat mein NRF nichts mehr empfangen. Danach habe ich mit verschiedenen Kondensatoren getestet und mit dem Trio 100nF + 1uF + 220uF super Ergebnisse erziehlt. 2.) Bei den Sensoren nutze ich einen Attiny1614 bzw. Attiny84 und asynchrones senden. Dann wird der MC wärend des sendens in stand by gesetzt und durch den interrupt zurück geholt. Bei den kleinen einfachen SMD chips schaffe ich gute 10m durch ein bis zwei Wände, allerdings nicht durch die Stahlbeton Decke. Die etwas größeren mit PA und LNA haben überall empfang. Ich nehme mitlerweile fast nur noch die Module mit PA und LNA. Für die Basis Station habe ich ein Modul mit externer Antenne. Wenn Du Zeit hast such mal bei Ali nach Ebyte. Ich nutze folgende Module: E01-ML01SP4, E01-2G4M13S, E01-ML01DP5 Aber auch die "GT-24 SMD" oder die mit Keramik Antenne funktionieren recht gut. Ich hoffe das hilft etwas.
Michael W. schrieb: > Ein Tantal von min 100uF (besser 220uF) und einen MLCC von 100nF so > nah an das Modul wie möglich. Bei den großen kann man einen 1206 MLCC > oder kleiner recht komfortabel zwischen VCC und GND Pin löten. Je nach > Schaltung und was sonst so an der Spannungsquelle hängt kann auch noch > ein 10nF oder 1uF MLCC helfen. Meine Rede seit Jahrzenten :) Und bei den "Anderen" funktionierts auch immer ganz ohne. Faszination Technik.
NRF Tester schrieb: > Meine Rede seit Jahrzenten :) Ich habe es nie in Abrede gestellt, dass eine gute Spannungsversorgung mit einer der Schlüssel zum Erfolg mit den NRF24L01 sind. Mittlerweile habe ich viel rum probiert, aber ich komme mit meiner Software und der geätzen PCB nicht annähernd auf die selben Ergebnisse wie mit dem Testaufbau. Um der Sache auf den Grund zu gehen, habe ich auch schon angefangen mit einem Logic Analyzer die SPI Kommunikation von beiden Aufbauten zu vergleichen. Da alle bisher getesteten NRF Module mit dem Testaufbau gleiche Ergebnisse liefern, bin ich gerade dabei die Software neu zu implementieren und auf IRQ umzustellen. Bisher habe ich immer die notwendigen Register gepolt und darüber die Kommunikation gesteuert. Die Software von NRFTester hat mich motiviert noch den zweiten Ansatz per IRQ auszuprobieren, denn dort wird ja im Terminal beim Verbindungstest von IRQ geschrieben. Hoffe ich bekomme mit der zweiten Softwareimplementierung bessere Ergebnisse. @NRFTester: Könntest du dir vorstellen, die Daten der Kommunikation zwischen zwei Modulen mit deiner Software offen zu legen bzw. zu beschreiben. Dann könnte man eine eigene Softwareimplementierung auch gegen deine Testsoftware testen.
Markus S. schrieb: > Sieht bei mir nicht viel anders aus, die Antenne schaut sauber über den > Platinenrand. Gerald K. schrieb: > layout2.jpg Dein Antennenfußpunkt liegt nicht an der Kante der Gnd-Fläche (Maßangabe 0,47")
Markus S. schrieb: > Könntest du dir vorstellen, die Daten der Kommunikation zwischen zwei > Modulen mit deiner Software offen zu legen Dazu bleibt nur das zu sagen was ich bereits früher gesagt habe: NRF Tester schrieb: > Die Sources werde ich nicht herausrücken da dort eine gehörige > Menge Arbeit drinsteckt die ich nicht in irgendeiner Weise > in Gegenleistungen zurück bekomme. Das sind keine einfach > mal so aus dem Internet schnell zusammengehackte freie Sourcen > sondern alles eigene Kreationen. Der einzige der dadurch noch "Gegenleistungen" bekommt ist der Forums-Betreiber. Aber ich kann - auf längere Sicht betrachtet - eine Test- Implementierung für deine Hardware anbieten. Du schickst mir eine fertige Leiterplatte und ich teste sie aus. Auch für diesen Fall würdest du keine "offenen" Sources von mir bekommen. Dennoch liessen sich dadurch Schwächen (wenn vorhanden) in deiner Hard- ware entdecken die sonst durch Ferndiagnose im Forum nicht leicht zu finden sind. Ich würde mir jedenfalls dafür nicht die Finger wund schreiben. Markus S. schrieb: > Da alle bisher getesteten NRF Module mit dem Testaufbau gleiche > Ergebnisse liefern, bin ich gerade dabei die Software neu zu > implementieren und auf IRQ umzustellen. Bisher habe ich immer die > notwendigen Register gepolt und darüber die Kommunikation gesteuert. Die > Software von NRFTester hat mich motiviert noch den zweiten Ansatz per > IRQ auszuprobieren, denn dort wird ja im Terminal beim Verbindungstest > von IRQ geschrieben. Die Abtastung des IRQ habe ich auch "nur" gepollt implementiert. Jedoch teste ich schon die IRQ-Leitung direkt als Abfrage eines Bits, nicht durch Lesen des Status Registers. Das würde eine deutlich längere Zeit beanspruchen. Diese Aussagen gelten für die PC-Software als auch für die Controller-Firmware. Also ich helfe gerne, nur nicht in dem Maße wie sich das so manch einer vorstellt.
NRF Tester schrieb: > Markus S. schrieb: >> Könntest du dir vorstellen, die Daten der Kommunikation zwischen zwei >> Modulen mit deiner Software offen zu legen > > Dazu bleibt nur das zu sagen was ich bereits früher gesagt habe: Ähm, ich glaube jetzt haben wir uns Missverstanden. Das mit deinen Sourcen habe ich verstanden und respektiere das. Die Frage ging auch diesmal keineswegs in Richtung der Sourcen sondern in Richtung der übertragenen Daten. So dass man die Möglichkeit hat in der eigenen Softwareimplementierung den selben Payload in Richtung deiner Software los zu schicken um darüber etwaige Probleme aufzudecken. Ich könnte mir Vorstellen, dass der Payload ja meist identisch sein wird und vielleicht einen inkrementierenden Counter enthält. NRF Tester schrieb: > Also ich helfe gerne, nur nicht in dem Maße wie sich das so > manch einer vorstellt. Volles Verständnis und habe damit auch kein Problem. Wie oben erwähnt glaube ich dass wir in der letzten Frage nach Offenlegung der Kommunikation von verschiedenen Dingen ausgegangen sind.
Markus S. schrieb: > So dass man die Möglichkeit hat in der eigenen Softwareimplementierung > den selben Payload in Richtung deiner Software los zu schicken um > darüber etwaige Probleme aufzudecken. Ich könnte mir Vorstellen, dass > der Payload ja meist identisch sein wird und vielleicht einen > inkrementierenden Counter enthält. Da gibt es eigentlich gar nichts weiter offenzulegen. Die Adressen sind bekannt, die Art zu kommunizieren auch (ACK abfragen). Zuletzt die Payload, sie ist immer auf 32 eingestellt da dies zum einen den anspruchvollsten Transfer bedeuted (es können am ehesten Fehler auftreten) und zum anderen die Grösse gebraucht wird um den leicht lesbaren String mit Numerierung voll zu übertragen. Es gibt also keine Geheimnisse, das PC Programm zeigt alles, und im Menü des F103 Testprogramms kann man sich auch alle notwendigen Parameter zeigen lassen (hab ich was übersehen? ich wüsste nicht). Wenn noch was fehlen sollte, frage bitte nach. Diesbezüglich gibt es nichts zu verbergen. Als letzter Gedanke: zum Thema IRQ ist mir eingefallen dass ich ja während einer Paket-Übertragung sender- als auch empfänger- seitig nichts am SPI Bus mache. Wenn man also beim Warten auf Empfang dauernd per SPI das Status-Register pollt würde man per SPI-Busverkehr eine Störung auf die Schaltung bringen die sonst (nur lesen des IRQ Bits) nicht auftritt. Das könnte zu einer gewissen Beeinträchtigung des NRF24-Empfängers führen.
Bitte 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.