Ich habe hier 2 Module nRF24L01+ mit Leiterbahnantenne und 2 Module nRF24L01+ PA+LNA mit Verstärker und Stabantenne. Außerdem habe ich ein AD8318 Modul mit logarithmischen Detektor und Stabantenne, welches mir die Funkpakete auf dem Oszi zeigt. Als Sender hängt ein nRF24 an einem ATmega328, sendet jede Sekunde ein Datenpaket. Als Empfänger hängt ein nRF24 an einem Raspberry, der zeigt die empfangenen Pakete an. Die Übertragung läuft mit Enhanced ShockBurst, AutoPaylen, Acknowledge und AutoRetransmit, CRC ist ein. Das funktioniert soweit auch wunderbar, wenn Sender und Empfänger die einfachen nRF24L01+ sind, inklusive Acknowledge, und ich sehe im Oszi die gesendeten und gleich darauf die Acknowledge-Pakete. Ersetze ich den Empfänger am Raspi durch einen nRF24L01+ PA+LNA, ohne irgendwas am Programm zu ändern, werden die Daten auch empfangen, aber es wird kein Acknowledge gesendet. Der Sender schickt darauf die Daten bis 15mal erneut raus, bevor er mit einem Max Retransmits abbricht. Komischerweise werden die Daten aber korrekt empfangen, der richtigen Pipe zugeordnet, die Paylen stimmt und der Inhalt stimmt. Ok, dachte ich dass halt der Sender am nRF24L01+ PA+LNA kaputt ist und er nur empfangen kann. Also habe ich nRF24L01+ PA+LNA und nRF24L01+ getauscht, so dass jetzt der nRF24L01+ PA+LNA am ATmega hängt und sendet. Funktioniert aber auch, die Daten werden korrekt empfangen, alles stimmt, am Oszi ist der Signalpegel etwa doppelt so hoch (logarithmisch) wie ohne PA... aber jetzt schickt der nRF24L01+ der das vorher ganz brav gemacht hat kein Acknowledge zurück. Häh? Also hab ich an ATmega und Raspberry je ein nRF24L01+ PA+LNA gesteckt und... tada, es wird wieder normal übertragen mit Acknowledge. Also Kurzform: Sender nRF24L01+ und Empfänger nRF24L01+: Daten werden übertragen, und Acknowledge Sender nRF24L01+ und Empfänger nRF24L01+ PA+LNA: Daten werden übertragen, aber kein Acknowledge Sender nRF24L01+ PA+LNA und Empfänger nRF24L01+: Daten werden übertragen, aber kein Acknowledge Sender nRF24L01+ PA+LNA und Empfänger nRF24L01+ PA+LNA: Daten werden übertragen, und Acknowledge Jetzt weiss ich nicht weiter: - elektrisch: sollte ok sein, Daten gehen problemlos, 10µF Keramik an den Modulen ist nachgerüstet - Kanal: stimmt, sonst würden keine Daten übertragen - Adresse: stimmt, Daten landen in der richtigen Pipe - CRC: bei beiden gleich, sonst würden keine Daten in die Pipe geschrieben - Sendeleistung: Änderung bringt bis auf eine andere Amplitude am Oszi keinen Effekt - Datenrate: stimmt auch, sonst würden ja keine Daten empfangen Woran kann das liegen, dass gleichartige Module sich ein Acknowledge zusenden, gemischte aber nicht. Woher weiss denn ein nRF24L01+ PA+LNA am Raspi, dass am ATmega nur ein nRF24L01+ hängt. Obwohl in Dtland gekauft und nicht über Ali kann ich nicht ausschließen, dass die Module keine Fakes sind. Der Aufdruck ist zwar nRF24L01+, leicht unterschiedlich, aber überprüfen kann ich das nicht.
Karl K. schrieb: > Woran kann das liegen, dass gleichartige Module sich ein Acknowledge > zusenden, gemischte aber nicht. Woher weiss denn ein nRF24L01+ PA+LNA am > Raspi, dass am ATmega nur ein nRF24L01+ hängt. Ich spekuliere auf zu grossen Frequenzversatz zwischen Modulen mit und ohne PA/LNA. Das kann man herauskriegen indem man einen Spektrum-Analysator oder einen Frequenzzähler nutzt um die genaue Frequenzlage der Module zu ermitteln. Siehe auch Beitrag "Re: NRFL24L01+ - Immer Ärger mit den Paarungen" wo das Problem sehr ähnlich liegt (meiner "Spekulation" nach).
Karl K. schrieb: > Jetzt weiss ich nicht weiter: Versuchshalber (um den Verdacht des Frequenzversatzes zu bestätigen oder zu entkräften) könnte man (nur) auf der Sendeseite oder (nur) auf der Empfangsseite die Frequenz um +- 1 bis 2 Frequenzschritte verstimmen.
Arduinoquäler schrieb: > könnte man (nur) auf der > Sendeseite oder (nur) auf der Empfangsseite die Frequenz > um +- 1 bis 2 Frequenzschritte verstimmen. Wie verstimme ich die Frequenz? Ich hab mal die Kanäle drüber oder drunter versucht, aber da kommt gar nichts an. Mir würde jetzt nur einfallen, mal mit Eisspray auf den Quarz zu halten. Es sind auf beiden Typen echte 16MHz Quarze verbaut, einmal als HC49 und einmal als 3mm SMD.
Karl K. schrieb: > Wie verstimme ich die Frequenz? Nur mit der Kanalnummer wie du schon beschrieben hast. Quarz mit Temperatur ziehen hilft nicht da gerade Quarze dafür berüchtigt sind nicht viel Temperaturdrift zu haben. Am ehesten kann man die Lastkapazitäten der Quarze ändern, aber das ist Stochern im Nebel solange man keine Frequenz- messung machen kann. Wie bereits erwähnt - alles nur meine Spekulation. Vielleicht haben die Chips aus den unterschiedlichen Chargen ganz unterschiedliche "Macken".
Naja, der Witz ist ja, dass die Datenübertragung ganz sauber und störungsfrei läuft. Selbst mit 32 Byte Payload kommen die Daten reproduzierbar an. Keine Ausfälle, keine gekippten Bits. Auch wenn ich die Max Retries verringere, kein Problem. Nur das Ackn wird nicht zurückgeschickt.
Karl K. schrieb: > Naja, der Witz ist ja, dass die Datenübertragung ganz sauber und > störungsfrei läuft. Keine Sorge, ich habe das schon zur Kenntnis genommen .... Ein letzter Gedanke: Die zusätzlichen Verstärker brauchen eine ganze Menge Strom um bei 2.4GHz die 20dBm Lesitung zu erzeugen. Hier sollte man besonders auf eine sehr stabile Versorgung achten. Ich würde daher den Versorgungen erst einmal misstrauen und daraus folgernd, testhalber eine hochstabile, separate Versorgung austesten. Ein 100uF Elko in der Nähe der NRF24-Module wird sicher kein Nachteil sein .... Und wenn es mir um jeden Preis darum ginge den Fehler zu finden würde ich einmal die Chips untereinander tauschen (auslöten/ einlöten)
Arduinoquäler schrieb: > Ich würde daher den Versorgungen erst einmal misstrauen und > daraus folgernd, testhalber eine hochstabile, separate Versorgung > austesten. Hab mir die Spannung direkt am Vcc des Power-nRF angesehen: Absolut sauber, obwohl er an den 3.3V des Raspi hängt. Das Verblüffende ist ja, dass der Empfänger - und das sehe ich im Oszi - sich nicht mal bemüht das Ackn zu senden, obwohl er gültige Daten empfangen, ausgewertet und in die Pipe einsortiert hat. Und mit einem anderen Sender dann das Ackn verschickt. <VT>Als ob der Hersteller da noch eine Kennung eingebaut hat, dass nur seine Chips miteinander kommunizieren, und der Fake-Chinese das Gleiche für seine Chips gemacht hat.</VT>
Karl K. schrieb: > Als ob der Hersteller da noch eine Kennung eingebaut hat, dass nur > seine Chips miteinander kommunizieren, und der Fake-Chinese das Gleiche > für seine Chips gemacht hat. Ja leider ist das eine plausible Erklärung .... Vielleicht ist das Handshake-Flag (Auto Ack) irgendwo in einem anderen Register versteckt worden.
Möglicherweise hab ich hier eine Erklärung gefunden: https://forum.mysensors.org/topic/3956/possible-bug-using-authentic-nordic-nrf24l01-module/10 ... info that I got from Nordic Tech Support "The re-marked nRF24L01P (+) clones are not 100% register compatible. The issue with the counterfeit devices is that when they enabled “Dynamic Payload Length” (EN_DPL) in the “FEATURE” register, one bit get’s activated in the on-air payload (the NO_ACK bit) This bit should be active high (according to the Nordic datasheet), but it’s actually implemented the other way around. When EN_DPL is activated, the NO_ACK bit get reversed in the real nRF-devices. They did such a good job of cloning they cloned the datasheet error into the device!!! Der letzte Satz ist witzig. Nur: Kann ich das jetzt in der Software kompensieren? Entweder dynamic Payload ausschalten - ist blöd - oder auf Ackn verzichten - ist auch blöd. Zumal ich mit dem AutoAckn auch Nachrichten an den Sender zurückschicke. Oder nackte Chips kaufen, die Fakes runterschneiden und die Echten drauflöten. Wobei hier das Problem ist, woher die Originale nehmen? Farnell scheint welche zu haben. Bei fertigen Modulen scheint man auch bei Kauf im Lande keine Chance zu haben Fakes auszuschließen.
Ja, interessant .... Karl K. schrieb: > Entweder dynamic Payload ausschalten Na das wäre billig. Sind ja eh nur 32 Bytes maximal.
Na toll, und wenn dieser Beitrag stimmt sind auf meinen beiden Power-nRFs die Echten (eckige Marke aus 4 Streifen) und auf den 5 einfachen nRFs die Fakes (runde Marke, andere Schrift).
Karl K. schrieb: > When EN_DPL is activated, the NO_ACK bit get reversed > in the real nRF-devices. Das wars: Ich hab auf Static Payload umgestellt und die Originale kommunizieren mit den offenbar Fakes. Also Dynamic Payload und AutoAckn zusammen gehen nicht. Dummerweise gilt das auch für die Ackn Payload. Jetzt habe ich wieder die berühmten 3 Probleme: Entweder ich stelle Ackn Payload auch auf Static. Dann kann ich zwar eine Payload zurückübertragen, aber es passen immer nur 3 Payloads in den Sendebuffer. Wird Ackn für mehr als 3 Pakete benötigt, muss ich also den Buffer immer schnell genug wieder füllen. Und es passen nur Payloads für 3 Adressen in den Sendebuffer. Mit 6 Geräten arbeiten ist also schonmal unmöglich. Ist der Buffer leer, schickt der Empfänger zwar auch ein Ackn, aber ohne Payload, und das wird wegen falscher Länge vom Sender nicht akzeptiert. Oder ich stelle Ackn Payload auf Dynamisch - dann funktionieren aber wieder die verschiedenen Module nicht zusammen. Oder ich sende keine Payload mit dem Ackn. Mist.
Hallo Karl, deine Module sind den RFM70 und RFM73 sehr ähnlich. Da hast Du eine echt böse Falle entdeckt. Da Du ja eine Fallunterscheidung benötigst, um je nach Partner den passenden Modus beim Sender zu verwenden, wäre es vielleicht eine Idee, die Partner anhand eindeutiger Adressen passend zu den Pipes zu unterscheiden und weil ja zur Adresse deren Eigenschaften bekannt sind, entsprechend den passenden Sendemodus auszuwählen, damit die Empfänger das Paket mit ACK-Anforderung erkennen und ACK zurück senden können. Übersichtlicher wird die Sache mit mehreren Teilnehmern natürlich nicht. MfG
Christian S. schrieb: > Da Du ja eine Fallunterscheidung benötigst, um je nach Partner den > passenden Modus beim Sender zu verwenden Genau das ist leider nicht möglich. Das Ackn-Bit im Datenstrom wird in Hardware generiert und ausgewertet. Und wenn Payload Länge auf Dynamisch gesetzt wird, wird dieses Bit invertiert - oder auch nicht, je nachdem ob es ein Fake oder ein Original Nordic ist. Nun könnte ich mit statischer Payload leben - wenn nicht die Ackn-Payload dynamisch wäre, je nachdem ob da was im Sendebuffer steht oder nicht. Per Software was umschalten geht leider nicht. Dann müsste ich den ganzen Ackn und Retransmit Kram in Software machen. Ich schwanke jetzt zwischen zwei Möglichkeiten: Auf die Ackn-Payload zu verzichten, obwohl ich die schon gern hätte, oder meine Module auf Original Nordic Chips umzulöten. Allerdings hab ich als einzige Quelle für Original Nordic nRF24L01+ Chips Farnell gefunden (was ok wäre), bei allen anderen weiss man wieder nicht was man bekommt bzw. gibts gar keine Einzel-Chips. Und neue Module kaufen - da weiss man auch wieder nicht, was man bekommt.
"Genau das ist leider nicht möglich. Das Ackn-Bit im Datenstrom wird in Hardware generiert und ausgewertet. Und wenn Payload Länge auf Dynamisch gesetzt wird, wird dieses Bit invertiert - oder auch nicht, je nachdem ob es ein Fake oder ein Original Nordic ist." Ja, das war verständlich dargelegt und kann für zukünftige Anwendungen von Bedeutung sein. Gut, letztendlich benötigst Du wohl eine ausreichende Menge gleicher Module. Warum nicht mehrere kaufen und selektieren nach diesen zwei Gruppen? Oder besteht eine Serienproduktion bevor, die dann nicht mehr beherrschbar sein wird, je nach Quelle? Fürs Hobby eine überschaubare Menge ließe sich doch anhäufen, oder? MfG
:
Bearbeitet durch User
Christian S. schrieb: > Warum nicht mehrere kaufen und selektieren nach diesen zwei Gruppen? Ich habe zwei Power-Module, die ich auch nutzen möchte, vor allem wegen des Eingangsverstärkers, die Sendeleistung kann ich reduzieren. Das sind offenbar Originale, und die waren mit Verstärker und Antenne auch etwas teurer. Davon brauch ich aber nur 2 für zwei unabhängige Netze. Ich hab 5 einfache Module, die offenbar Fakes sind. Nun sollen gerade die aber mit den Power-Modulen kommunizieren, tun das aber nur untereinander. Da müsste ich perspektivisch auch noch welche zukaufen. Dumm halt, dass man auch bei höherpreisigen einfachen Modulen anscheinend nicht davon ausgehen kann, dass da "echte" Nordic Chips drauf sind. Also bleibt wieder nur probieren. Dann kann ich die aber nur zurückschicken, weil untereinander kommunizieren sollen die ja nicht, sondern mit meinen vorhandenen Power-Modulen. Sonst wärs ja leicht... ;-)
Bei machen nRF24L01+PA hängt der enable Pin des PA am CE Pin des nRF..
So liebe Chinesen. Hab jetzt von Farnell 5 originale nRF24L01+ Chips bestellt, die alten Chips runtergefräst, die Platine gesäubert, die neuen unterm SteMi aufgelötet, getestet, funktionieren alle - mit meinen Power-Modulen. Danke für garnix. Wo bekommt man Module mit originalen nRF24L01+ Chips? Bei Watterod bin ich mir unsicher, Conrad weiss nichtmal ob sie 01 oder 01+ verkaufen, bei Farnell gibts nur die Chips, bei Amazon und Ebay gibts alles Mögliche, und wenn man die Händler fragt, bekommt man nur: Jaja, gehtgeht, kein Problem.
Angehängte Dateien:
-
nRF24L01good-bad.png
330 KB
Hallo Karl, Hast du inzwischen Module mit originalen nRFs gefunden? Ich habe einige mit den 1808AHs bei mir (siehe im Bild unten), alle haben den 2401C Verstärker-Chip und die Reichweite sowie Signalstabilität ist grottig... trau mir allerdings das umlöten nicht wirklich zu.
Nö. Die letzten die ich bestellt habe waren wieder nicht kombatibel, die Nordic Chips von Farnell sind schon da zum umlöten.
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.