NRF24L01+ Reichweitenproblem

[Markus S. (acepilot)]

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

[Chregu (Gast)]

Kaufe originale bei TME oder so. Und nimm die mit aufschraubbarer 
Antenne. Solche Probleme habe ich damit gelöst!

[NRF Tester (Gast)]

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.

[NRF Tester (Gast)]

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.

[NRF Tester (Gast)]

Ach so, Trace 2 hat 2 Volt pro Div, dann ist alles ganz anders.

Dann nehme ich alles zurück und behaupte das Gegenteil.

[Markus S. (acepilot)]

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.

[NRF Tester (Gast)]

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.

[Markus S. (acepilot)]

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.

[Mike J. (emjey)]

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)

[Markus S. (acepilot)]

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.

[Harald (Gast)]

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.

[Markus S. (acepilot)]

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.

[Mike J. (emjey)]

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.

[NRF Tester (Gast)]

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?

[Markus S. (acepilot)]

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.

[Mike J. (emjey)]

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 :-)

[NRF Tester (Gast)]

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"

[Markus S. (acepilot)]

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.

[Markus S. (acepilot)]

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)?

[NRF Tester (Gast)]

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.

[NRF Tester (Gast)]

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.

[Christian S. (roehrenvorheizer)]

>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 (Gast)]

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.

[Mike J. (emjey)]

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

[NRF Tester (Gast)]

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.

[Markus S. (acepilot)]

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.

[NRF Tester (Gast)]

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 ....

[NRF Tester (Gast)]

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.

[my2ct (Gast)]

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 (Gast)]

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")

[Markus S. (acepilot)]

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 …

[Mike J. (emjey)]

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?

[Thorsten S. (thosch)]

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?

[Markus S. (acepilot)]

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.

[Markus S. (acepilot)]

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.

[Wolfgang (Gast)]

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.

[Gerald K. (geku)]

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.

[NRF Tester (Gast)]

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.

[Markus S. (acepilot)]

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.

[Cyblord -. (cyblord)]

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.

[NRF Tester (Gast)]

Cyblord -. schrieb:
> Merkwürdig, ich stelle da einfach die gewünschte Temperatur ein.

.... so man Einstellmöglichkeiten hat ....

[Cyblord -. (cyblord)]

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.

[Gerald K. (geku)]

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.

[Markus S. (acepilot)]

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.

[Gerald K. (geku)]

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?

[Markus S. (acepilot)]

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

[leser (Gast)]

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.

[Markus S. (acepilot)]

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.

[Patrick C. (pcrom)]

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

[NRF Tester (Gast)]

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.

[Michael W. (micha_we)]

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.

[NRF Tester (Gast)]

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.

[Markus S. (acepilot)]

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.

[Wolfgang (Gast)]

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")

[NRF Tester (Gast)]

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.

[Markus S. (acepilot)]

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.

[NRF Tester (Gast)]

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.