Forum: Mikrocontroller und Digitale Elektronik Viele (200+) NRF24L01 nebeneinander?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mike (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

für das nächste Projekt plane ich den Einsatz von vielen NRF24L01 um mir 
ein bisschen Verkabelungsaufwand zu sparen.

Viele bedeutet mindestens 50 Stück, maximal so 255 Stück (wegen 8bit 
Addressen lol) in einem Raum mit ca. 40m².

Noch ein paar Informationen zur Anwendung:
- Es sendet immer der gleiche Master, alle anderen Devices "hören" nur.
- Datenrate ist nicht so kritisch(?). 500kbit wären schön, mindestens 
brauche ich ~50kbit.
- Abstand zwischen den Devices ist mindestens 100mm.

Hat jemand sowas schon gemacht? Sind hier irgendwelche Probleme zu 
erwarten?

Danke und einen schönen Sonntag noch!

von funkie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> - Abstand zwischen den Devices ist mindestens 100mm.

Wenn immer nur einer sendet könnte es funktionieren.
Aber nicht unbedingt wenn einer auf 2,410 und der andere auf 2,420 GHz 
sendet...

von Mike (Gast)


Bewertung
0 lesenswert
nicht lesenswert
funkie schrieb:
> Mike schrieb:
>> - Abstand zwischen den Devices ist mindestens 100mm.
>
> Wenn immer nur einer sendet könnte es funktionieren.
> Aber nicht unbedingt wenn einer auf 2,410 und der andere auf 2,420 GHz
> sendet...

Ne, das war anders gemeint:
Es sendet immer der gleiche NRF Chip. Alle anderen hören nur zu und 
empfangen immer die gleichen Daten. Quasi ein "Broadcast" von einem Chip 
zu vielen Chips.
Oder gibt es da Probleme wenn alle mit gleicher Addresse empfangen wegen 
Handshakes, ACKs, etc.?

von NRF Tester (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> Oder gibt es da Probleme wenn alle mit gleicher Addresse empfangen wegen
> Handshakes, ACKs, etc.?

Wenn du eine Empfangsbestätigung haben willst (also ACK) dann
musst du jeden Chip einzeln deine Message senden unter einer
eigenen Adresse. Echte Broadcasts werden nicht funktionieren,
es sei denn du brauchst nicht die Zuverlässigkeit einer
Rückmeldung. Aber gerade das zeichnet ja die Funktionalität
der NRF Chips aus. Ok, die programmierbaren 433MHz Module
können das auch.

Mike schrieb:
> wegen 8bit Addressen lol

Die Adressierung der NRF24L01 Chips ist nicht auf 8 Bit
beschränkt, da geht sehr viel mehr, siehe Datenblatt.

von Mein name ist Hase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was für ein Funktprotokoll verwendest du? BT / BLE oder was anderes?
Was für einen Standard bit es für den? 4 oder schon 5?

Sollte doch mit BLE mit Observer und Broadcaster realisieren lassen?
Ok die 100m könnten problemtaisch werden je nach dem was da alles 
dazwischen steht. Klasisches Beacon Prinzip?

ggf ist die erhöte reichweite von 5.x mit niedriger bandbreite 
interresant (125kBit dafür erhöte reichweite)
ggf über einen der nachfolger 52/53 und BLE 5.x nachgedacht?

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
100 mm, nicht 100 m.

von Mike (Gast)


Bewertung
0 lesenswert
nicht lesenswert
NRF Tester schrieb:
> Wenn du eine Empfangsbestätigung haben willst (also ACK) dann
> musst du jeden Chip einzeln deine Message senden unter einer
> eigenen Adresse.

Ne, egal. Brauch ich nicht.

Im Moment sieht der Plan wie folgt aus, vielleicht hätte ich das im 
Eingangspost inklduieren sollen:
- Alle NRF bekommen die gleiche Adresse
- Alle NRF empfangen deswegen die gleichen Daten
- Jedes Device hat eine eigene Addresse und verarbeitet nur die für sich 
relevanten Daten weiter.

Meinst du das geht? Ansonsten kauf' ich einfach mal ein paar NRF und 
probiers aus.

NRF Tester schrieb:
> Die Adressierung der NRF24L01 Chips ist nicht auf 8 Bit
> beschränkt, da geht sehr viel mehr, siehe Datenblatt.

Ist mehr so eine interne Beschränkung von meiner Applikation. Mehr 
brauch ich auch nicht :-)

NRF Tester schrieb:
> Echte Broadcasts werden nicht funktionieren,
> es sei denn du brauchst nicht die Zuverlässigkeit einer
> Rückmeldung. Aber gerade das zeichnet ja die Funktionalität
> der NRF Chips aus. Ok, die programmierbaren 433MHz Module
> können das auch.

Gibt es eine bessere Alternative? NRF ist halt billig und einfach, 
deswegen ist es für mich auch ok, einige Features brach liegen zu 
lassen.

Mein name ist Hase schrieb:
> Was für ein Funktprotokoll verwendest du? BT / BLE oder was anderes?
> Was für einen Standard bit es für den? 4 oder schon 5?

Glaube BLE wird mir hier zu kompliziert. Ausserdem reichen mir doch da 
die Datenraten nicht ganz?


Ich glaube, dass ich das Protokoll, etc. ganz gut in den Griff bekomme. 
Worauf ich in meinem Eingangspost eigentlich hinauswollte:
Gibt es Probleme, so viele Empfänger nebeneinander zu betreiben? Nicht, 
dass dann für einige die Feldstärke nicht mehr ausreicht oder so.
Ich habe von RF leider nicht so den Plan, sorry, wenn das keinen Sinn 
macht :D

von WLAN-Kabel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> Gibt es Probleme, so viele Empfänger nebeneinander zu betreiben? Nicht,
> dass dann für einige die Feldstärke nicht mehr ausreicht oder so.

Im Nahfeld (d<10λ) gibt es den Effekt, IIRC.

Außerdem  senden manche Empfänger auch ein klein wenig (f+-ZF ?)

Am besten mal in https://www.mikrocontroller.net/forum/hf nachfragen...

von Mein name ist Hase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich kenn das BT Clasic protokoll nicht. Aber wenn da ein ACK drin ist, 
dann senden das alle mehr oder weniger gleichzeitig, ... was dem 
empfänger vermutlich nicht ganz so gut bekommt wenn das nich 1000% 
synchron statfindet. Weiter müsten dann auch die kanalwechsel alle 
synchron statfinden. Host und client ändern ja glaube ich alle 625µs den 
kanal.

ggf ist eines der anderen 2.4Ghz Protokolle besser geeignet. Nordic hat 
da ggf auch einen passenden Stack dafür. Oder du must dir den Stack 
selber zusammenpatchen, ...

BLE 5.x kann 125kBit  500kBit  1MBit / 2MBit wobei nRF 500kBit nur 
empfangen kann nicht senden.

Nordic  hat auf den ersten blick ein sehr umfangreichen und gut 
aussehenden Software support. Ich darf mich gerade in das Connect SDK 
einarbeiten. Ja das framwork ist umfangreich. Mit west, devicetry, 
kconfig, ninja, zephyr ... nicht ganz einfach zu verstehen, (da kämpf 
ich mich grad durch) aber jede menge beispiele die auch laufen.

von Mike (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mein name ist Hase schrieb:
> Ja das framwork ist umfangreich. Mit west, devicetry,
> kconfig, ninja, zephyr ... nicht ganz einfach zu verstehen, (da kämpf
> ich mich grad durch) aber jede menge beispiele die auch laufen.

Klingt nicht so, als obs das richtige für mich ist :D
Soll eigentlich möglichst schnell laufen, deswegen dachte ich an die 
NRF24L01, die ja wesentlich einfacher zu bedienen sind.

WLAN-Kabel schrieb:
> Im Nahfeld (d<10λ) gibt es den Effekt, IIRC.

Wäre ja bei 2.4G ca. 1,20m!

WLAN-Kabel schrieb:
> Außerdem  senden manche Empfänger auch ein klein wenig (f+-ZF ?)

Macht irgendwie auch Sinn.

Ich bestelle mal ein paar NRF Receiver und probiere es aus!

Danke euch!

von Mein name ist Hase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es sind ja jede menge beispiele dabei, die auch wirklich super laufen.
Connect SDK installieren, ... da ist IDE, Compiler, Debugger, ... alles 
enthalten. IDE lizenzieren muss man sich noch besorgen (ist für nRF 
einsatz kostenlos) Projektauswählen, Compilieren, fläschen, läuft, ...

Es ist halt nur das da für mich jetzt mehr oder weniger alles neu ist, 
...
WEST kann man sich damit beschäftigen, ... muss man ggf nicht und es 
einfach nur nutzen. oder über die IDE verwenden.

RTOS hab ich schon benutzt, ... zephyr noch nie, Wobei das mit dem 
Devicetrie / treibermodell ganz interresant ist und wie sie es 
hinbekommen ein Beispiel für verschiedne Bords bereitzustellen. Ohne if 
then else im code. (STM32x  nRF  ... )

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.