Hallo, sicherlich setzen viele diese Module ein mit einer der zahlreichen Libs, die es im Netz gibt. Der Chip ist ausreichend komplex, dass eigene Libs schon ausprobiert und getestet werden müssten. Fakt ist auch, dass alle Angebote in der Bucht und sonstigen Quellen nicht den Original Chip von Nordic verwenden, sondern einen China-Klon. Ich sah mal eine Seite wo die beiden Dies aufgeschliffen nebeneinander lagen. Sie sind ähnlich aber nicht gleich. Nun ist es bei mir im Dauerbetrieb so, wo kurze Datensätze jede Minute versandt werden, dass sporadisch Fehler auftraten beim Empfang. Das RX_Ready Bit im Status Register "klemmte", setze sich nicht zurück wenn ich die Payload auslas. es wurde dauernd angezeigt, da etwas in den Fifos ist. Der Chip hat keinen Reset, d.h. nach einem CPU Reset macht er den nicht mit. Blöd! Ich habe einfach Brute-Force mässig folgede Schritte geschrieben, damit er sich nicht mehr aufhängt. Diese werden nach dem Empfang und Auslesen eines Datensatzes ausgeführt. 1. Power Down damit niemand dazwischen funkt 2. Clear RX und TX Bit im Status (beide sind R/W) 3. Flush RX und TX Fifo 4. Und nochmal Clear RX und TX Bit 5. Power Up Damit läuft er jetzt nach jedem Empfang sauber durch. Für das Versenden großer Datenmengen halte ich den Chip nicht geeignet. 32 Bytes und das nicht zu schnell. Ich habe die kleinen, die mit Antenne und die Power Version mit 100mW Amp dran. Ist bei allen das Gleiche. Kennt ihr ähnliche Probleme?
Hallo Christian, wir setzen die Chips schon seit bestimmt 10 Jahren ein und haben keine Probleme. Allerdings haben wir die Firmware komplett selbst dafür geschrieben. Wir haben eine Datenübertragung so mit ca. 38 Kbyte/s. Ja Probleme kann es geben wenn die Reihenfolge nicht richtig eingehalten wird beim Auslesen, auch wenn mehrere Datapipes enabled sind. Wir haben nur ein Datapipe enabled. Was das Problem auch verursachen kann ist, wenn vorher nicht das Statusregister gelesen wird, welches Datenpipe eine Nachricht beinhaltet. Ich kenne das Problem, das ein Datenpipe die Sache klemmen kann, wenn nicht alle Bytes ausgelesen wurden, gerade bei Variabler Package Lengh. Deshalb muss vorher das Statusregister mit der Längenangabe gelesen werden. Und wenn alles nichts hilft Flush-RX Buffer geht. So nun bei Automatik Repeat und auto Ack. kann das einen anderen Grund haben. Der Sender sendet ein Package, Der Empfänger empfängt es und bestätigt das mit ACK. aber der Sender (Master) empfängt das ACK. nicht. Somit wird das Pachage schon aus dem Empfänger ausgelesen und ein zweiter Vorgang beginnt von neuem. Sowie ich das sehe ist der automatische Vorgang nicht ganz Fahlerfrei in den Chips. Es muss der Empfänger nach einem Empfang abgeschalten werden, dann das Datenpacket ausgelesen werden, der RX-Buffer (Flush) gelöscht werden und der Empfänger wieder eingeschalten werden. Gruß Sascha
Hi, Sascha schrieb: > Deshalb muss vorher das Statusregister mit der > Längenangabe gelesen werden. Wie meist du das? Ich weiss ja wie viele Bytes kommen. Und das Status Register lese ich im Polling Betrieb, ist das RC gesetzt lese ich genauso viele Bytes aus wie vorher defniert wurden beim Setup. Aber ich lese es nicht jedesmal neu aus. Ich gehe doch stark davon aus, dass nur Datensätze dort vorhandne sind, deren CRC stimmt und alles andere auch. Hast du da ggf. mal etwas Code? ich nutze nur eine Pipe, die Nr. 0. Hast Du schonmal versucht eine Anpassung der Sendestärken zu machen? Ich habs mal versucht über die Fehlerrate zu gehen, also 20 Sätze senden und wenn davon 15 geACKT wurden so lassen. Lief aber nicht gar nicht. Seitdem stelle ich immer auf Miaxmum 0 dbm.
Christian J. schrieb: > ich nutze nur eine Pipe, die Nr. 0. Hast Du schonmal versucht eine > Anpassung der Sendestärken zu machen? Ich habs mal versucht über die > Fehlerrate zu gehen, also 20 Sätze senden und wenn davon 15 geACKT > wurden so lassen. Lief aber nicht gar nicht. Seitdem stelle ich immer > auf Miaxmum 0 dbm. Habe ich jetzt Erscheinungen oder hast Du im letzten Post geschrieben, es sei jetzt alles O.K.? Beitrag "Re: Arduino: NRF24L01 2.4Ghz maniacbug Library" Ich habe da nicht weiter geschaut - aber wenn Du nur Pipe Nr. 0 nutzt kann ACK aus meiner Sicht nicht funktionieren, da diese Pipe als "ACK-Pipe" dient. Ich warte aktuell auf Lochraster-Platinen, da mein Steckbrett-Aufbau zu wacklig ist und ich nie weiß, ob meine Fehler vom Steckbrett oder aus der SW resultieren. So macht das keinen Spaß :-(
Dieter F. schrieb: > Habe ich jetzt Erscheinungen oder hast Du im letzten Post geschrieben, > es sei jetzt alles O.K.? Nein, er hängt sich immer wieder sporaisch auf und reagiert dann auf nichts mehr auch, kein flush etc. Ich werf den Stein bald raus, da mich das nur noch nervt, brauche was zuverlässiges. Intern ist der mir teilweise auch nur kryptisch.
Auch mit den clones, ich gehe davon aus, dass es welche sind, hatte ich noch keine Probleme mit falschen sendungen, wenn sie denn generell funktionieren
Max M. schrieb: > Auch mit den clones, ich gehe davon aus, dass es welche sind, > hatte ich > noch keine Probleme mit falschen sendungen, wenn sie denn generell > funktionieren Ich habe gestern mal debgugged und festgestellt, dass wenn er hängt nur 0x00 aus dem Status Register kommt. Egal welches Modul. Entweder er hängt sofort oder erst nach Minuten oder Stunden. Und er fängt sich teilweise auch wieder. Der Sender zeigt aber, dass kein ACK mehr erfolgt, der hat 2 LED, eine grüne und eine rote auf der ich das anzeigen lasse. Ich weiss nicht genau wie ich es machen soll ohne ACK zu arbeiten, die Lib für den STM32 ist darauf ausgelegt. Ohne dieses Problem wären die Teile echt gut :-(
Christian J. schrieb: > ... und festgestellt, dass wenn er hängt nur > 0x00 aus dem Status Register kommt. Bei mir war's das Config-Register, das permament 0x00 zurückgab. Alle andere Register hatten nachvollziehbare Werte. Das Problem war, dass ich die SPI-Clock-Frequenz zu niedrig gesetzt hatte; naemlich so um die 125 kHz. (Ja, ich weiss: nach dem Datenblatt müsste ich bis auf Null runtergehen können.) Nachdem ich auf 500kHz rauf bin, war der Spuk vorbei.
Mehmet K. schrieb: > Bei mir war's das Config-Register, das permament 0x00 zurückgab. Alle > andere Register hatten nachvollziehbare Werte. > Das Problem war, dass ich die SPI-Clock-Frequenz zu niedrig gesetzt > hatte; naemlich so um die 125 kHz. (Ja, ich weiss: nach dem Datenblatt > müsste ich bis auf Null runtergehen können.) > Nachdem ich auf 500kHz rauf bin, war der Spuk vorbei. Da habe ich schon dran gedreht, die kann ich am APB2 Bus von ca 1Mhz bis 45 Mhz einstellen. Tiefer als 1M aber nicht. Aktuell steht sie auf 4 Mhz. Evtl. drehe ich da noch mal dran. Stromverorgung ist natürlich stabil und gepuffert, das Modul empfängt eh nur und nur der ACK ist Senden. Ich tendiere dazu die Libs wegzuwerfen und auf den Basisroutinen, die nur Schreiben und Lesen von Registern vorsehen was Eigenes aufzusetzen, was ich auch komplett verstehe. Ich brauche ja nur eine Konfiguration und will keine Universal Lib schreiben, die alle Features bietet. Stur eine Payload mit definierter Größe senden. Mit oder ohne ACK. Und das ganze so, dass es kompatibel mit der Arduino MIRF Lib bleibt. Das war bei der I2C Lib auch die Lösung damals. Im Netz steht auch viel Schrott, Code mit vielen Fehlern drin usw.
Angehängte Dateien:
-
Unbenannt.JPG
81 KB
Dumme Frage: Diese Register sind 40 Bit breit? Und die nächsten dann wieder 8 Bit? Mich wundert es nur, dass das nächte Register dann 0B ist und nicht 5 Bytes weiter gezählt wird.
Christian J. schrieb: > Dumme Frage: > > Diese Register sind 40 Bit breit? Und die nächsten dann wieder 8 Bit? > Mich wundert es nur, dass das nächte Register dann 0B ist und nicht 5 > Bytes weiter gezählt wird. JA. Die Registernummern sind rein logisch und damit unabhängig von der Größe der Register.
Christian J. schrieb: > Der Chip hat keinen Reset, d.h. nach einem CPU Reset macht er den nicht > mit. Blöd! Da war auch das Erste, was ich bei genauerem Hinsehen rausfinden mußte. Da bleibt wohl tatsächlich nur, die Betriebsspannung vom µC mit einem Transistor o.ä. zu schalten. Oder eine ellenlange reset-Funktion zu schreiben, in dem alle Register auf ihre defaultwerte gesetzt werden. Wenn er aber irgendwo hängt, wohl doch nur POR...
Lutz schrieb: > Oder eine ellenlange reset-Funktion zu > schreiben, in dem alle Register auf ihre defaultwerte gesetzt werden. Ach :-) Genau das habe ich schon gemacht, schön aus Datenblatt alles rausgesucht....... seufz. Ob das wirklich ein echter Reset ist, der auch die Statemachine zurücksetzt, wenn die "spinnt" sei mal dahingestellt.
Christian J. schrieb: > schön aus Datenblatt alles rausgesucht Die Bank 0 ist bei allen Herstellern offenbar identisch zu initialisieren. Bei der Bank 1 habe ich heftige Unterschiede zwischen den diversen Datenblättern und Libs gefunden. HTH.
Georg G. schrieb: > Die Bank 0 ist bei allen Herstellern offenbar identisch zu > initialisieren. Bei der Bank 1 habe ich heftige Unterschiede zwischen > den diversen Datenblättern und Libs gefunden. HTH. Das Dumme ist ja auch, dass nur Klone auf dem Markt sind. Ich hätte gern einen Original Nordic aber bisher vergeblich gesucht. Bei den Nachbauten kann alles schief sein, das ist billiger Mist aus China.
Ich habe über 20 Chinateile, die Version mit + und ohne. Ich hatte eine eigene Lib dafür geschrieben weil das damalige Zeug viel zu gross war oder Hardware-SPI nutzten,... Dabei hatte ich auch immer wieder Probleme, bis ich merkte dass das Datasheet eine Vorabversion war, die gewisse Infos nicht beeinhaltete. Mit dem letzten Datasheet gab es dann keine Probleme mehr. Die nRFs sind zwar etwas strange was die Programmierung angeht aber sie haben halt schon vieles drinn was man bei nackten AFK-Modulen von Hand zusätzlich dazustricken muss wenn man ne saubere Übertragung haben will (CRC, Preamble,....) und sie sind schön kompakt (die "+" Versionen sind kleiner als die non-plus). Also die Dinger sind schon ok. Bestell einfach mal ne andere Charge die kosten ja praktisch nix.
Christian J. schrieb: > nur Klone auf dem Markt Ein Original habe ich auch noch nie gesehen. Aber die Clone laufen hier alle problemlos. Ich habe diverse Libs mir angesehen und dann was eigenes daraus gemacht, gleiche Gründe wie nRF-Freddy.
Hi, bin grad am coden der Lib bzw. auf meine Anwendung angepasste Routinen ohne Overhead ...... braucht man, wenn man nur empfangen will (mit Auto ACK) nur die Pipe 0 oder doch 2 Pipes? Die TXD Pipe ist ja nur einfach vorhanden und muss (hoffentlich) nicht benutzt werden. Mein Wetter-Barometer nimmt einfach nur von einem Außensensor einige Daten entgegen, sendet aber nie etwas irgendwo hin (wäre ja auch EMV Smog ;-) Und nochwas: Ich möchte erstmal feststellen, ob das Modul überhaupt da ist, wegen Wackelkontakt usw. Routinen, die nur schreiben sind mir nicht geheuer, eine offene Leitung an der SPI liefert auch immer 0xff zurück. Ginge das so?
1 | * Ist das Funkmodul ansprechbar ? |
2 | Dazu wird das Feature Register mit 0x07 beschrieben |
3 | */
|
4 | uint8_t RF_Available() |
5 | {
|
6 | CE_LOW; |
7 | |
8 | uint8_t backup = RF_ReadRegSingle(NRF24L01_REG_FEATURE); |
9 | RF_WriteRegSingle(NRF24L01_REG_FEATURE,0x07); |
10 | uint8_t val = RF_ReadRegSingle(NRF24L01_REG_FEATURE); |
11 | RF_WriteRegSingle(NRF24L01_REG_FEATURE,backup); |
12 | return (val == 0x07) ? SUCCESS:ERROR; |
13 | }
|
1 | void RF_ConfigureAsRX(uint8_t payload_size) { |
2 | |
3 | CE_LOW; |
4 | |
5 | /* Adressen setzen */
|
6 | RF_WriteRegSingle(NRF24L01_REG_SETUP_AW,0x05); |
7 | RF_WriteRegMulti(NRF24L01_REG_RX_ADDR_P0,MyAddress,0x05); |
8 | RF_WriteRegMulti(NRF24L01_REG_RX_ADDR_P1,MyAddress,0x05); |
9 | |
10 | |
11 | /* Auto ACK für Pipe 0 und 1 setzen */
|
12 | RF_WriteRegSingle(NRF24L01_REG_EN_AA,0x03); |
13 | |
14 | /* Erlaubte Pipes 0 und 1 setzen */
|
15 | RF_WriteRegSingle(NRF24L01_REG_EN_RXADDR,0x03); |
16 | |
17 | /* Payload Size für die Pipes setzen */
|
18 | RF_WriteRegSingle(NRF24L01_REG_RX_PW_P0,payload_size); // P0: Auto ACK Pipe |
19 | RF_WriteRegSingle(NRF24L01_REG_RX_PW_P1,payload_size); // P1: RX Pipe |
20 | RF_WriteRegSingle(NRF24L01_REG_RX_PW_P0,0); // P2: not used |
21 | RF_WriteRegSingle(NRF24L01_REG_RX_PW_P0,0); // P3: not used |
22 | RF_WriteRegSingle(NRF24L01_REG_RX_PW_P0,0); // P4: not used |
23 | RF_WriteRegSingle(NRF24L01_REG_RX_PW_P0,0); // P5: not used |
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.