Erfahrungen mit Nordic Semi nRF24L01+ Reichweite?

Hallo Matthias,

das hört sich nicht gut an! Ich habe mir ein paar Module vor einem Monat 
besorgt und wollte zur Jahreswende einige Tests mit ihnen machen.

Kennst Du die Seite http://blog.diyembedded.com/ ?

Dort gibt es viele Infos und Tutorials zum nRF24L01. Vielleicht ist das 
schon einmal hilfreich.

Gruß
kokisan

Hi Matthias!

Ich arbeite auch gerade mit dem nRF24L01+ und auch mit dem gleichen 
Modul, nur habe ich meines von Ebay, sieht aber genau so aus. Ich habe 
dann noch ein zweites Modul mit einer etwas anderen Antennengestaltung.

Ich habe leider noch keine Reichweitentest machen können da ich auf 
weitere Breadboards warte. Aber ich kann zumindest sagen, daß mir auf 
dem Schreibtisch keine Pakete verloren gehen. Allerdings arbeite ich 
auch mit Enhanced Shockburst. Ich frage auch die "resent packages" ab 
und da sehe ich auch, daß kaum ein Package wiederholt gesendet wird. Ich 
sende aber auch mit zwei Sendern gleichzeitig.

Wie schaut denn Dein Code für TX und RX aus? Wie viele Pakete schickst 
Du in welcher Zeit? Schon mal einen anderen Kanal ausprobiert? Schon mal 
RPD abgefragt? FIFO Full?

LG
Ernst

Noch eine Frage aus persönlichem Interesse: Wieso wird das eine many to 
many Übertragung? Ich kann mir gerade nicht vorstellen wieso eine 
Heizungssteuerung eine many to many Übertragung braucht?

Gerade Enhanced Shockburst ist doch der Bringer bei dem Chip? Eine 
Heizungssteuerung klingt jetzt nicht danach, als ob da extreme 
Datenmengen zeitkritisch übertragen werden müssen?

LG
Ernst

Hi,

Ja, das many-to-many steht derzeit auch auf dem Prüfstand. Dennoch 
bleibt bei der Stern-Architektur eine Beschränkung auf max. 6 
Teilnehmer. Das reicht mir allerdings sogar - nur etwas schade, soetwas 
speziell auf einen Chip auslegen zu müssen.

Jedes Paket, welches dir bei Enh. Shockburst als Resent angezeigt wird, 
ist bei mir verloren. Somit decken sich ja unsere 
Schreibtisch-Erfahrungen. Bei einer zweiten Schaltung mit nem Cortex M3 
verliere ich auch dort über 50%, das kann aber noch ein Softwarefehler 
sein (denn der AVR-Empfänger im Thermostat funktioniert dort recht gut).


Der Code ist derzeit noch nicht bei Github, daher erstmal ein paar 
Ausschnitte, vom Empfänger (Sender steht mir derzeit nicht zur 
Verfügung, dort geht aber vermutlich alles glatt). Flags werden keine 
weiteren überprüft. Empfangen im Interrupt:

1

void nRF24L01_IRQ(void)

2

{

3

  static uint8_t irqCount = 0;

4

  uint8_t status;

5

  uint8_t rpd;

6

  status = nRF24L01_command(NOP, 0, 0);

7

  displayBargraph(++irqCount * 2);

8

9

  if(status & (1 << TX_DS))

10

  {

11

    if(TxActive == 2)

12

    {

13

      RX;

14

      mirf_CE_hi;

15

16

    }

17

18

19

    TxActive = 0;

20

    displaySymbols(0, LCD_TOWER);

21

    nRF24L01_write_register(STATUS, 1 << TX_DS);

22

  }

23

#ifdef RX_CALLBACK

24

  if(status & (1 << RX_DR))

25

  {

26

    rxCallback();

27

  }

28

#endif

29

}

30

31

uint8_t nRF24L01_get_data(uint8_t * data)

32

{

33

    uint8_t len;

34

    uint8_t status;

35

    //status = nRF24L01_command(R_RX_PL_WID, &len, 1);

36

    len = 32;

37

38

    if(len > 32)

39

    {

40

      nRF24L01_command(FLUSH_RX, 0, 0);

41

      return 0;

42

    }

43

    nRF24L01_commandR(R_RX_PAYLOAD, data, len);

44

    nRF24L01_write_register(STATUS, (1 << RX_DR));

45

    /* todo: datasheet says we shall read FIFO_STATUS to check for more data */

46

47

    return len;

48

}

Die Callback Funktion ruft dann getData auf.

Gesendet wird derzeit etwa mit 3-4 Paketen pro Sekunde, sodass der Fall, 
dass 2 Pakete gleichzeitig eintreffen nicht auftreten sollte (denn der 
empfangende AVR hat nichts zu tun). Selbst wenn: Ein geringer 
Paketverlust ist mir egal - das Problem hier ist ja eher, dass es auf 
3-5m schon richtig mau aussieht. Das scheint mir weniger ein 
Codeproblem.
RPD habe ich leider noch nicht überprüft, kommt noch.

Konfiguration nochmal:

1

#define DISABLE_ENHANCED_SHOCKBURST 1

2

3

/* Callback out of Interupt for incoming packet */

4

#define RX_CALLBACK 1

5

6

/* 1 Byte CRC */

7

#define DEF_CONFIG     ( (1<<EN_CRC) | (0<<CRCO) | (1 << MASK_MAX_RT))

8

9

/* no retransmission delay, up to 0 retransmissions */

10

#define DEF_SETUP_RETR ((0 << ARD) | (0 << ARC))

11

12

/* Channel Offset in MHz*/

13

/* ISM is 2,4-2,5 GHz, WLAN g */

14

#define DEF_RF_CH         65

15

16

/* Data Rate 2 MBps, maximum output power */

17

#define DEF_RF_SETUP ((1 << RF_DR_HIGH) | (3 << RF_PWR))

18

19

/* Dynamic Payload Length, Payload with Ack */

20

#define DEF_FEATURE (0)

21

22

/* Static Payload on all data pipes */

23

#define DEF_DYNPD (0)

24

25

nRF24L01_write_register(RF_CH, DEF_RF_CH);

26

  nRF24L01_write_register(CONFIG, DEF_CONFIG);

27

  nRF24L01_write_register(SETUP_RETR, DEF_SETUP_RETR);

28

  nRF24L01_write_register(RF_SETUP, DEF_RF_SETUP);

29

  nRF24L01_write_register(FEATURE, DEF_FEATURE);

30

  nRF24L01_write_register(DYNPD, DEF_DYNPD);

31

#ifdef DISABLE_ENHANCED_SHOCKBURST

32

  nRF24L01_write_register(EN_AA, 0);

33

#endif

34

35

  nRF24L01_write_register(EN_RXADDR, 0);  /* disable all rx pipes */

36

  nRF24L01_command(FLUSH_RX, 0, 0);

37

  nRF24L01_command(FLUSH_TX, 0, 0);

38

  nRF24L01_write_register(STATUS, (1 << RX_DR | (1 << TX_DS) | (1 << MAX_RT)));

Callback:

1

void funkRxDataAvailable(void)

2

{

3

  static uint16_t readCounter = 0;

4

  uint8_t rxData[32];

5

  uint8_t readLen;

6

  readLen = nRF24L01_get_data(rxData);

7

8

  readCounter++;

9

  displayWeekday(rxData[0]);

10

  displayNumber(readCounter);

11

}

(RX Pipe wird natürlich wieder aktiviert; Empfänger ist die ganze Zeit 
ohne Senden im RX Modus, alles andere an dem Controller ist deaktiviert 
und die Hauptschleife tut nichts. Paketkontrolle über Zähler auf 
Display, welcher aus der Empfangsroutine hochgezählt wird. Realisiert 
über itoa ist er zwar sicher nicht der schnellste, dürfte aber kaum mehr 
als wenige ms in Anspruch nehmen, 1 MHz Systemtakt)

Ich werde nachher/am WE nochmal Enhanced Shockburst testen, und eben die 
250 kBps. Rückmeldung gibts bis Sonntag, da nicht besonders viel Zeit :)

Vielen Dank für deine Unterstützung.

Hi Matthias!

Matthias Larisch schrieb:
> Ja, das many-to-many steht derzeit auch auf dem Prüfstand. Dennoch
> bleibt bei der Stern-Architektur eine Beschränkung auf max. 6
> Teilnehmer. Das reicht mir allerdings sogar - nur etwas schade, soetwas
> speziell auf einen Chip auslegen zu müssen.

Sollte es nicht ausreichen dann könntest noch immer beim Empfänger-µC 
zwei nRF24L01 betreiben und so zwei mal 6 Sender betreiben. Das sollte 
aufgrund moderaten Datenmenge die zu übertragen ist leicht zu 
bewerkstelligen sein.

>
> Jedes Paket, welches dir bei Enh. Shockburst als Resent angezeigt wird,
> ist bei mir verloren. Somit decken sich ja unsere
> Schreibtisch-Erfahrungen. Bei einer zweiten Schaltung mit nem Cortex M3
> verliere ich auch dort über 50%, das kann aber noch ein Softwarefehler
> sein (denn der AVR-Empfänger im Thermostat funktioniert dort recht gut).

Ich habe das nochmals probiert - wie gesagt, nur Tischvariante - und ich 
verliere bei zwei Sendern die gleichzeitig aktiv sind mit Enhanced 
Shockburst und versetzten Sendezeitpunkten kein einziges Paket. 
Testdauer waren ca. drei Stunden bei 2Mbps. Unsere Aufbauten sind halt 
insoferne nicht vergleichbar weil Du ohne Enhanced Shockburst arbeitest. 
Ich sende ja Pakete nochmals wenn kein Ack ankommt.



> Der Code ist derzeit noch nicht bei Github, daher erstmal ein paar
> Ausschnitte, vom Empfänger (Sender steht mir derzeit nicht zur
> Verfügung, dort geht aber vermutlich alles glatt). Flags werden keine
> weiteren überprüft. Empfangen im Interrupt:
>

1

> void nRF24L01_IRQ(void)

2

> {

3

>   static uint8_t irqCount = 0;

4

>   uint8_t status;

5

>   uint8_t rpd;

6

>   status = nRF24L01_command(NOP, 0, 0);

7

>   displayBargraph(++irqCount * 2);

8

> 

9

>   if(status & (1 << TX_DS))

10

>   {

11

>     if(TxActive == 2)

12

>     {

13

>       RX;

14

>       mirf_CE_hi;

15

> 

16

>     }

17

> 

18

> 

19

>     TxActive = 0;

20

>     displaySymbols(0, LCD_TOWER);

21

>     nRF24L01_write_register(STATUS, 1 << TX_DS);

22

23

Warum prüfst Du beim Empfänger das TX_DS? Ich nehme an, das sind noch Reste vom Sender-Code? 

24

25

>   }

26

> #ifdef RX_CALLBACK

27

>   if(status & (1 << RX_DR))

28

>   {

29

>     rxCallback();

30

>   }

31

> #endif

32

> }

33

> 

34

> uint8_t nRF24L01_get_data(uint8_t * data)

35

> {

36

>     uint8_t len;

37

>     uint8_t status;

38

>     //status = nRF24L01_command(R_RX_PL_WID, &len, 1);

39

>     len = 32;

40

> 

41

>     if(len > 32)

42

>     {

43

>       nRF24L01_command(FLUSH_RX, 0, 0);

44

>       return 0;

45

>     }

46

>     nRF24L01_commandR(R_RX_PAYLOAD, data, len);

47

>     nRF24L01_write_register(STATUS, (1 << RX_DR));

48

>     /* todo: datasheet says we shall read FIFO_STATUS to check for more

49

> data */

50

> 

51

>     return len;

52

> }

53

>

>

Da oben steht noch ein eventuell wichtiger Punkt denke ich. Du prüfst ja 
auf das RX_DR Bit ob ein neues Datenpaket angekommen ist. Probiere 
einmal noch zusätzlich den FIFO_STATUS zu  kontrollieren ob noch weitere 
Pakete im FIFO sind die aufs auslesen warten. Du hast recht, daß es 
unwahrscheinlich ist, daß da mehr warten aber so hast Du die Sicherheit, 
daß nicht Pakete wegen überlaufenden FIFOs verloren gehen.

Ich polle übrigens bei meinem Programm und lese die Daten nicht über den 
Interrupt aus. Aber das macht keinen Unterschied denke ich.

Du könntest auf das RX_DR Bit ja mal im Interrupt reagieren und die 
Payload auslesen und den FIFO-STATUS in der While Schleife auslesen und 
gegebenenfalls darauf reagieren.

> Die Callback Funktion ruft dann getData auf.
>
> Gesendet wird derzeit etwa mit 3-4 Paketen pro Sekunde, sodass der Fall,
> dass 2 Pakete gleichzeitig eintreffen nicht auftreten sollte (denn der
> empfangende AVR hat nichts zu tun). Selbst wenn: Ein geringer
> Paketverlust ist mir egal - das Problem hier ist ja eher, dass es auf
> 3-5m schon richtig mau aussieht. Das scheint mir weniger ein
> Codeproblem.
> RPD habe ich leider noch nicht überprüft, kommt noch.

Was Du eben noch machen könntest mal einen anderen Kanal zu probieren. 
Vielleicht ist zufällig der Kanal auf den Du sendest durch W-Lan und 
Konsorten bei Dir besonders verseucht.

Noch was ist mir eingefallen: Hast Du die Standard-Adressen vom nRFL01 
übernommen oder eigene gewählt?

> Vielen Dank für deine Unterstützung.

Gerne.

LG
Ernst

Ernst B. schrieb:
> Sollte es nicht ausreichen dann könntest noch immer beim Empfänger-µC
> zwei nRF24L01 betreiben und so zwei mal 6 Sender betreiben. Das sollte
> aufgrund moderaten Datenmenge die zu übertragen ist leicht zu
> bewerkstelligen sein.

Das führt eben wie beschrieben zur Abhängigkeit von genau diesem Nordic 
Chip (Enh. Shockburst mit Adressierung eben generell), das würde ich 
gerne vermeiden, werde es aber nun wohl doch erstmal so machen, da das 
Projekt langsam mal "life" gehen muss - ne Heizungssteuerung im Sommer 
bringt mir nicht viel :). Für mich selbst reichen 3-4 Nodes zusätzlich 
zur Basis, das passt also.


> Ich habe das nochmals probiert - wie gesagt, nur Tischvariante - und ich
> verliere bei zwei Sendern die gleichzeitig aktiv sind mit Enhanced
> Shockburst und versetzten Sendezeitpunkten kein einziges Paket.
> Testdauer waren ca. drei Stunden bei 2Mbps. Unsere Aufbauten sind halt
> insoferne nicht vergleichbar weil Du ohne Enhanced Shockburst arbeitest.
> Ich sende ja Pakete nochmals wenn kein Ack ankommt.

Ich hatte dich so verstanden, dass du mal den ARC_CNT in OBSERVE_TX 
ausgelesen hattest. Der ist Paket-individuell (muss also vorm nächsten 
Versand gelesen werden), und ich verstand dich weiter so, dass der nicht 
bei 0 war.

>
> Warum prüfst Du beim Empfänger das TX_DS? Ich nehme an, das sind noch
> Reste vom Sender-Code?

Jede Node bei mir kann senden und empfangen. "Empfänger" schrieb ich 
deswegen, weil das Teil eben zum Test nur als Empfänger genutzt wurde.


>
> Du hast recht, daß es
> unwahrscheinlich ist, daß da mehr warten aber so hast Du die Sicherheit,
> daß nicht Pakete wegen überlaufenden FIFOs verloren gehen.

Deswegen schrieb ich: Es ist mir erstmal egal, ob ich 20% Paketverlust 
habe. Aber 90% sind nicht akzeptabel. Diese können eben nicht vom 
Fifo-Überlauf stammen, zumal ich ja auf dem Schreibtisch nur etwa 1-2% 
der Pakete verliere.

>
> Was Du eben noch machen könntest mal einen anderen Kanal zu probieren.
> Vielleicht ist zufällig der Kanal auf den Du sendest durch W-Lan und
> Konsorten bei Dir besonders verseucht.

Das könnte ich nochmal tun, ja. Zumindest Wlans sind in dem 
Frequenzbereich (Kanal 8-13) jedoch nicht stärker als -82 dBm (laut 
Notebook auf dem Schreibtisch) empfangbar. Das sagt natürlich nichts 
über die eigentliche Feldstärke aus - RPD war allerdings immer 0, 
solange nicht mein eigener Sender gesendet hat.
>
> Noch was ist mir eingefallen: Hast Du die Standard-Adressen vom nRFL01
> übernommen oder eigene gewählt?

Nein, eigene. Dabei habe ich versucht, mich von der Preambel etwas zu 
unterscheiden und trotzdem möglichst viele Bitwechsel einzubauen:
0xA7, 0x5B, 0xCD, 0x14, 0x15

Wobei mir gerade jetzt einfällt, dass ja das rechteste Byte das MSByte 
ist (das 0xA7 sende ich zuerst zum Chip), in Gedanken hatte ich das 
genau andersherum konstruiert.

Meine Erkenntnis gab allerdings auch eher, dass die Pakete korrekt 
erkannt wurden, jedoch aufgrund der CRC verworfen wurden, da ich ohne 
CRC deutlich mehr Pakete erhalte, welche jedoch gekippte Bits aufweisen.

Ich bin leider derzeit nicht in der Lage, weitere Tests durchzuführen. 
Bis morgen Abend wird das allerdings nachgeholt und dann melde ich mich 
nochmal mit den neusten Erkenntnissen :)

Gruß & ein schönes Wochenende,

Matthias

Matthias Larisch schrieb:

> Das führt eben wie beschrieben zur Abhängigkeit von genau diesem Nordic
> Chip (Enh. Shockburst mit Adressierung eben generell), das würde ich
> gerne vermeiden, werde es aber nun wohl doch erstmal so machen, da das
> Projekt langsam mal "life" gehen muss - ne Heizungssteuerung im Sommer
> bringt mir nicht viel :). Für mich selbst reichen 3-4 Nodes zusätzlich
> zur Basis, das passt also.
>
Ah, verstehe. Abhängig macht man sich immer in irgendeiner Form, den 
Code kannst eh nicht weiter verwenden wenn Du ein anderes Modul 
einsetzt. Und wenn ich mir die Probleme ansehe die bei den RFM-Modulen 
hier immer nachgefragt werden dann scheint mir doch der nRF24L01 ein 
wunderbares Produkt im Vergleich.

Produkte die kein Enhanced Shockburst bzw. ähnliches onchip bieten sind 
dann ja doch schwieriger und mühsamer zu programmieren weil man sich um 
diese Dinge selbst kümmern muß.

Sollte ein Paket trotz resent nicht ankommen stellst eh über MAX_RT fest 
und dann schickst es halt nocheinmal. Bis es halt angekommen ist.

Ich würde jetzt gar nicht so viel Energie da rein stecken wie es ohne 
Enhanced Shockburst geht sondern mal schauen wie es mit läuft. Was nicht 
heißt, daß ich Deine Neugier nicht verstehe. :-))

> Ich hatte dich so verstanden, dass du mal den ARC_CNT in OBSERVE_TX
> ausgelesen hattest. Der ist Paket-individuell (muss also vorm nächsten
> Versand gelesen werden), und ich verstand dich weiter so, dass der nicht
> bei 0 war.

Da hast mich schon richtig verstanden. Ich wollte auch durch Deine 
Erfahrungen mal schauen ob ich bei aktiviertem Enhanced Shockburst 
Pakete komplett verliere über eine längere Zeit. Bei dem Versuch habe 
ich resent nicht mitgeloggt. Für mich persönlich ist wichtig, daß die 
Pakete schlußendlich ankommen. Und mein Projekt ist ganz ähnlich, ich 
messe die Zimmertemperatur und Feuchte in weiterer Folge. Nur steuere 
ich (noch) keine Heizung damit.

> Deswegen schrieb ich: Es ist mir erstmal egal, ob ich 20% Paketverlust
> habe. Aber 90% sind nicht akzeptabel. Diese können eben nicht vom
> Fifo-Überlauf stammen, zumal ich ja auf dem Schreibtisch nur etwa 1-2%
> der Pakete verliere.

Ja, mich wundert das auch, daß Du da gleich so viele Pakete verlierst.

> Das könnte ich nochmal tun, ja. Zumindest Wlans sind in dem
> Frequenzbereich (Kanal 8-13) jedoch nicht stärker als -82 dBm (laut
> Notebook auf dem Schreibtisch) empfangbar. Das sagt natürlich nichts
> über die eigentliche Feldstärke aus - RPD war allerdings immer 0,
> solange nicht mein eigener Sender gesendet hat.
>>

Bin schon gespannt ob das eine Änderung bewirkt. Auch auf Deine Versuche 
mit 250k bin ich neugierig. Teste doch auch mal 1Mbps, wenn ich das 
richtig im Kopf habe belegt das nur 1 Kanal im Vergleich zu 2Mbps.

> Nein, eigene. Dabei habe ich versucht, mich von der Preambel etwas zu
> unterscheiden und trotzdem möglichst viele Bitwechsel einzubauen:
> 0xA7, 0x5B, 0xCD, 0x14, 0x15
>
> Wobei mir gerade jetzt einfällt, dass ja das rechteste Byte das MSByte
> ist (das 0xA7 sende ich zuerst zum Chip), in Gedanken hatte ich das
> genau andersherum konstruiert.
>

Gut, dann fällt da mein Gedanke auch aus, daß es an den Bitwechseln 
liegt.


> Ich bin leider derzeit nicht in der Lage, weitere Tests durchzuführen.
> Bis morgen Abend wird das allerdings nachgeholt und dann melde ich mich
> nochmal mit den neusten Erkenntnissen :)

Ich kann heute leider auch nix testen. Bin aber auf Deine nächsten 
Erkenntnisse schon sehr gespannt.

>
> Gruß & ein schönes Wochenende,
>
> Matthias

Wünsche Dir auch ein schönes Wochenende,

LG
Ernst

Hallo Matthias,

gibt es schon neue Erkenntnisse zu diesem Thema?

Gruß
kokisan

Jein:

Ein Teil der Probleme (die Erkenntnisse mit den gekippten Bits) beruhen 
auf einer fehlerhaften Versorgungsspannung (Billig-LM1117, welcher > 300 
mVpp output ripple erzeugt hat). Über Weihnachten bin ich anderweitig 
beschäftigt (wer ist das nicht) - daher ruht das Projekt großteils 
erstmal.

Somit: Keine wirklichen neuen Erkenntnisse. Aber ebenso wie zum 
"Sparmatic Thread" werde ich auch hier wieder weiterschreiben, wenn es 
weitergeht :)

Schöne Feiertage an alle!

Hi Zusammen!

So, ich habe ein paar News nachdem ich heute endlich ein paar Tests 
machen konnte die über die Tischplatte hinaus gingen.

Es sind schnelle Tests gewesen ich kann das Ergebnis also nicht genau 
quantifizieren.

Es ging ja um die Reichweite und ich habe folgendes festgestellt:

Mit diesem Sender 
http://www.ebay.at/itm/2PCS-NRF24L01-2-4GHz-Wireless-Transceiver-Module-/230684823300?pt=UK_Computing_DesktopComponents_RL&hash=item35b5e30f04 
wurden die Tests durchgeführt. Es ist nicht der gleiche Sender wie ihn 
Matthias verwendet. Die Ausführung von Matthias habe ich auch hier aber 
damit noch keine Tests gefahren. Das folgt noch denn ich plane meinen 
Endausbau mit der anderen Version welcher auch der Empfänger ist in 
diesem Fall. 
(http://www.ebay.at/itm/Mini-2-4Ghz-Wireless-NRF24L01-Transceiver-Module-/320608404697?pt=LH_DefaultDomain_0&hash=item4aa5c004d9)

Enhanced Shockburst ist aktiviert mit 15 Wiederholungen falls kein Ack 
zurückkommt. Datenrate 2Mbps.

Durch zwei Wände mit einer Entfernung von ca. 7m verliere ich kaum ein 
Paket.

In einer Entfernung von nur 5m aber durch eine Glasfront (senden vom 
Balkon) verliere ich doch einige Pakete. Möglicherweise liegt das aber 
am Metalltisch auf dem der Sender stand? Hat mich doch ziemlich 
überrascht.

3m innerhalb eines Zimmers verliere ich kein Paket und alle Pakete 
kommen sofort an.

Für mich bedeutet das, daß ich meinen Code erweitern werde da ich nur 
alle 5 Minuten Daten übertrage. Bei erreichen der maximalen 
Wiederholungen werde ich die Daten nochmals auf die Reise schicken. 
Außerdem werde ich noch langsamere Übertragungsraten ausprobieren wobei 
ich soweit eigentlich zufrieden bin mit dem wie es funktioniert.

Das war es mal kurz,

lg
Ernst

So, wieder News von mir:

Das verändern des Kanals sowie die Geschwindigkeit auf 250kbps setzen 
brachte den Durchbruch.

Damit kommen viele Pakete an, sogar von meinem Sorgenkind dem Balkon.

Getestet wird inzwischen nur mit diesem Modul: 
http://www.ebay.de/itm/ws/eBayISAPI.dll?ViewItem&item=320608404697&clk_rvr_id=303038203596

Mir kommt vor, daß das insgesamt besser ist als das andere Modul. (Siehe 
Beitrag davor)

Als nächstes werde ich mit dem nRF mal einen "Scanner" programmieren, 
vielleicht kann man so jene Kanäle herausfiltern wo besonders viel 
Verkehr lauert.

LG
Ernst