Wer hat noch Ärger mit NRF24L01+ Funkmodulen?

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.

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

Wie sieht deine stromversorgung aus?

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.

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

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.

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