Hallo,
ich habe schon seit knapp 2 Jahren diese Dinger im Einsatz bei einer
selbstgebastelten Wetterstation aber wie ich mich grad wieder
reinarbeite und neue Hardware baue fällt mir auf, dass diese billigen
Dinger mit der Ätzantenne auch mehr oder weniger zufällig mal was
empfangen. Der ACk für Shockburst Übertragung mit dyn. Payload kommt
dann öfter mal nicht an die Basisstation, je nachdem wie die Platine im
Raum gedreht ist, ob man die Hand über die CPU hält (EMV?) oder nicht.
Da tickert ein STM32F103 mit 72 Mhz in der Nähe, keine 4cm weiter weg.
Jetzt habe ich in der Bucht die hier gefunden, sicherlich auch China
Klone. Die Original Nordic Steine liegen ja bei ca 8 Euro nur der Chip.
http://www.ebay.de/itm/2-x-NRF24L01-PA-LNA-SMA-Antenne-Transceiver-Modul-2-4G-Antenna-Long-Range-/252713959128?hash=item3ad6ecfed8:g:Aj0AAOSwTglYl0hr
Sind die besser und zuverlässiger als diese mit der Ätzantenne?
Und da ist da noch die Sache mit der 5 Byte Adressierung. Ich habe
soweit festgestellt, dass man nicht jede Byte Kombination nehmen darf.
Hatte erst meine Telefonnummer genommen. Lief nicht. Bei einigen gibt es
jede Menge Datenmüll. Gibt es da Regeln welche gut laufen?
Christian J. schrieb:> ... fällt mir auf, dass diese billigen Dinger mit der Ätzantenne auch> mehr oder weniger zufällig mal was empfangen.
Das nennt sich Funk und hat was mit dem Rauschen der Welt zu tun.
Es ist eine reine Frage der Statistik, wie oft ein empfangenes
Rauschen/Störungen einem echten Signal so ähnlich ist, dass der
Empfänger es bis zum Ausgang durchprozessiert. Das nennt sich
Fehlerwahrscheinlichkeit. Du musst deine Daten inklusive Prüfsummen so
gestalten, dass die Wahrscheinlichkeit für solche Fehler so gering wird,
wie es für deine Anwendung nötig ist. Du könntest beispielsweise in
deinem Protokoll festlegen, dass die Daten innerhalb eines Zeitfensters
zwei mal richtig empfangen werden müssen, damit sie als gültig gewertet
werden.
Lutz schrieb:> Man soll möglichst viele Flankenwechsel haben. Bei den Adressen geht das> ja noch, bei den Nutzdaten wird es wohl schwierig...
Wieso soll das für Nutzdaten schwieriger als für Adressen sein?
Das ist eine reine Frage der Kodierung. Beispielsweise die
Manchesterkodierung sorgt genau für ausreichend viele Flankenwechsel im
Datenstrom.
W.A. schrieb:> Das ist eine reine Frage der Kodierung. Beispielsweise die> Manchesterkodierung sorgt genau für ausreichend viele Flankenwechsel im> Datenstrom.
Soweit ich weiss machen diese Super-Duper Steine aber genau das schon
intern. Da ist ja allerhand drin verbaut, was den Nutzdatensatz derart
verschwurbelt, dass dieser auch nahezu fehlerfrei ankommt. Mit den Daten
habe ich kaum Probleme, notfalls sorgt das protokoll dafür, dass diese
bis zu 15 Mal wiederholt werden bis der ACK sitzt.
Eine erste Abhilfe war es übrigens den Kanal auf höhere Werte zu ändern,
den meine Kinder für ihre WLAN Sucht ja ständig benutzen. :-)
Diese von dir verlinkten Module setze ich in einem Projekt ein. Zur Zeit
sind ca. 300 St. im Einsatz und laufen sehr zuverlaessig (Test über
mehrere Stockwerke verlief absolut fehlerfrei). Auf dem Feld überbrücken
sie Distanzen zwischen 40 und 120m; und schon mehrmals erhielt die
Firmware (ca. 25kB) via Funk ein Update.
Nichtsdestotroz ist mein Eindruck sehr zwiespaeltig. Die Software
dermassen fehlerfrei hinzukriegen war echt schmerzhaft: selbst die SPI
Clock-Frequenz hat einen Einfluss auf das Ganze.
Weiterhin weiss man nie, was man aus China erhaelt. Unser
Zwischenhaendler empfahl uns ein Modul, das etwa doppelt so teuer war
als die üblichen (so um die 7,50 USD). Wir bestellten 2 Muster - und in
der Tat waren diese in der Herstellung sehr professionel. Von der
Leistung her konnte ich aber keine Unterschiede feststellen.
Nichtsdestotrotz enschlossen wir uns, die teueren einzukaufen und
bestellten 100 St.
Keines dieser 100 St. hat funktioniert!
All jene Module zu Preisen so um die 3 USD funktionieren aber
einwandfrei; obwohl bei manchen erst mal Lötzinn-Kurzschlüsse entfernt
werden musste :)
Auch mit den Modulen, die eine PCB-Antenne haben, bin ich sehr
zufrieden. Ich habe sie zwar nur zu Testzwecken getestet, aber 2 (oder
3?) Mauern stellten kein Hindernis dar.
Was Deine Aussage hinsichtlich der Adresse betrifft, so ist sie korrekt.
Ich glaube, dazu gibt es auch einen Hinweis im NRF24L01-Manual.
Aber die Daten selbst (ich benutze 32 Bytes) verschicke ich
unverarbeitet.
Ich frickel grad am Schreibtisch mit den Dingern, habe rund 10 Stück
hier, kleinere und größere. Mit und ohne 10uF Elko am VCC. Gestern lief
es noch einwandfrei, der Master (Basisstation hängt an der Wand, holt
die Daten der Sensoren von draussen rein und sendet im ACK auch Befehle
für Sleep etc.) sendete die geforderten Daten, was ich am Blinken der
Led sehe und auch wenn er kein ACK bekommt, weil das dann länger ist.
heute morgen läuft es nicht mehr, es wird nur ein Datensatz empfangen,
danach sind die Module zu. Spannung weg, CPU gelöscht, anderes Modul...
alles geht wieder. Seltsamerweise klappt die Verbindung Arduino (1 Chip
Lösung, Arduino nur als Programmierhilfe) mit radiohead Lib einwandfrei
zum Cortex. Da liegen 2 Stück draussen in Butterbrot Dosen wetterfest
gemacht, funken seit einem halben Jahr mit 2 Mignon Zellen.
Sehr seltsam....
Christian J. schrieb:> Ich frickel grad am Schreibtisch mit den Dingern ...
Was mir dazu einfaellt: mit der Sendeleistung muss man bei solchen
Distanzen auf Minumum.
Christian J. schrieb:> Sind die besser und zuverlässiger als diese mit der Ätzantenne?
Das sind die PNA+LNA mit onBoard Verstärker die in Deutschland leider
über den zugelassenen Sendeleistungen senden wenn man nicht ein sehr
schwieriges Software Frequency-Hopping benutzt, da die keinen
integriertes FH haben.
Es gibt irgendwo auch Boards die einen kleinen SMT-Anschluss besitzen.
Mehmet K. schrieb:> Was mir dazu einfaellt: mit der Sendeleistung muss man bei solchen> Distanzen auf Minumum.
Jaja.... man darf auch keine Autos in Hamburg anzünden. Haben sie
trotzdem getan und sind straffrei ausgegangen. Das Land wird die paar
Millisekunden überstehen.... beim FPV Fliegen senden wir mit bis zu 2
Watt per Richtantennen.
Habe allerdings die Leistung der Ätz Version auch verbessert durch 2
kleine Dipol-Silberdrähte, statt der Spule. Deutlich bessere Ergebnisse.
Christian J. schrieb:> Mehmet K. schrieb:>> Was mir dazu einfaellt: mit der Sendeleistung muss man bei solchen>> Distanzen auf Minumum.>> Jaja....
Es ging darum, die Sendeleistung für Tests auf dem Schreibtisch zu
reduzieren, um die Empfänger nicht zuzustopfen ...
Christian J. schrieb:> Und da ist da noch die Sache mit der 5 Byte Adressierung.
Und da ist da noch die Sache mit der Frequenzgenauigkeit.
Das scheint niemanden zu interessieren bzw ist noch niemanden
aufgefallen.
Der verwendete Quarz als Zeitbasis ist 16MHz, der kann schon
mal im vervielfachten Ergebnis 200KHz daneben liegen. Mag
auch mehr sein, ich habe mir nur ein Exemplar angesehen.
Jedenfalls wird sich eine Abweichung von der Sollfrequenz
in einer Verringerung der Empfindlichkeit niederschlagen.
Im Extremfall kann ja auch Sender und Empfänger in
entgegengesetzter Richtung abweichen ....
Wenn man es genau nehmen und höchste Reichweite erzielen
will müsste man also die Quarze mit den Lastkapazitäten
auf die "optimale" Mittenfrequenz abgleichen.
Arduinoquäler schrieb:> Wenn man es genau nehmen und höchste Reichweite erzielen> will müsste man also die Quarze mit den Lastkapazitäten> auf die "optimale" Mittenfrequenz abgleichen.
Ich glaube wenn man es wirlich so genau nehmen will, dann kauft man sich
nicht für 1,50 Euro diese Dinger bei ebay sondern nimmt Industrieware.
Ich habe mit Bluetooth Modulen, die auch in Handys verwendet werden
beste Ergebnisse erzielt bei der Anbindung an einen RS232 Port von uC's.
Die sind abgeglichen, normenkonform und funktionieren einfach.
Du weisst ja nicht genau, ob der 16 Mhz für den RF Teil des Chip
zuständig ist, wo die die per PLL dann daraus 2,4Ghz machen. Das kann
auch Chip intern erzeugt werden und die 16 Mhz bedienen nur den
digitalen Teil. Diese Chips sind Imho festverdrahtete Statemachines ohne
Rechenkern.
Es gibt bei diesen Billigmodulen auch Unterschiede, manche lassen noch
mehr Beschaltung der Chips weg. Ich krieche da aber nicht hinein, sie
sollen nur funktionieren und das tun sie gerade ... mal wieder. Die
Software war schon aufwendig genug.
>Du weisst ja nicht genau, ob der 16 Mhz für den RF Teil des Chip>zuständig ist, wo die die per PLL dann daraus 2,4Ghz machen. Das kann>auch Chip intern erzeugt werden und die 16 Mhz bedienen nur den>digitalen Teil.
Ich glaube nicht, dass man die Sendefrequenz mit der notwendigen
Genauigkeit ohne Quarzreferenz erzeugen kann.
Heinz schrieb:> Hier gibts es nen langen Thread über gefälschte NRF24L01+:>> https://forum.mysensors.org/topic/1153/we-are-mostly-using-fake-nrf24l01-s-but-worse-fakes-are-emerging
Mag sein, aber chin. Halbleiter sind nicht schlechter als japanische.
Die Chips von Nordic sind recht teuer, habe da was von 8-10 Euro im Kopf
in kleinen Mengen.
Markus schrieb:> Ich glaube nicht, dass man die Sendefrequenz mit der notwendigen> Genauigkeit ohne Quarzreferenz erzeugen kann.
Unter der Annahme, dass sich bei einer PLL Fehler natürlich auch
vervielfachen, selbst wenn die PLL einen 0% Fehler aufweisen würde. 16
Mhz auf 2.4Ghz wäre schon eine sportliche Leistung. Aber das geht auch
durch temperaturstabile Schaltkreise, die nachträglich getrimmt werden.
So wird das ja auch bei RTC gemacht, da werden Korrekturzellen bespielt
kurz vor dem Ausliefern oder aber der Quarz wird durch Lasertrimmen eben
"gezogen".
Christian J. schrieb:> Du weisst ja nicht genau, ob der 16 Mhz für den RF Teil des Chip> zuständig ist, wo die die per PLL dann daraus 2,4Ghz machen. Das kann> auch Chip intern erzeugt werden und die 16 Mhz bedienen nur den> digitalen Teil.
Diese Annahme bezeichne ich hier mal locker als absoluten Käse.
Und bei diesem Käse wird es auch bleiben.
Christian J. schrieb:> Aber das geht auch> durch temperaturstabile Schaltkreise, die nachträglich getrimmt werden.
Auch diese Annahme bezeichne ich hier mal locker als absoluten Käse.
Und bei diesem Käse wird es auch bleiben.
Christian J. schrieb:> selbst wenn die PLL einen 0% Fehler aufweisen würde
Eine PLL hat bereits per Definition eine Frequenzabweichung
von null Prozent. Sogar null Promille.
Löten an Klöten kann Leben töten schrieb:> Die verlinkten Module haben z.T. Fehler im Layout des PCBs, wenn du> Pechhast bekommst du so eines angedreht.
Kurzer Nachsatz zu den verlinkten Modulen oben. Diese arbeiten
hervorragend! Ich sehe es an dem Bblinken der LED ja, wie oft und lange
ein Datensatz wiederholt werden muss, bevor er von der gegenstelle
akzeptiert wird. Quer durchs Haus einwandfreier Empfang, fast kein
Wiederholungen. Es scheint also, dass da doch eine Verbesserung
statgefunden hat gegenüber diesen Billigdingern mit der Ätzantenne.
Christian J. schrieb:> Kurzer Nachsatz zu den verlinkten Modulen oben. Diese arbeiten> hervorragend!
Kurzer Nachsatz zu deinen HF-Kentnissen zu diesem Modul
die ja hauptsächlich aus Käse-Vorstellungen zu bestehen
scheinen:
Die "neuen" Module funktionieren hauptsächlich deshalb
so gut (ähhh "hervorragend!") weil sie - gepaart verwendet -
im Übertragungsweg einen Gewinn von 30 dB gegenüber den
Modulen "mit Ätzantenne" bringen:
20dB auf der Senderseite durch Erhöhung der Sendeleistung
von 0dBm auf 20dBm.
10dB auf der Empfangsseite durch den zugeschalteten
Vorverstärker der vor dem NRF liegt.
Ich habe gerade beim Kisten sortieren 2 Versuchsplatinen
wiedergefunden.. die benutz ich noch manchmal als PPM to NRF24L01 im RC
Bereich.
Die Boards waren nicht viel teurer wie die Ätzantennen und komplett mit
Antenne.
Keine Ahnung woher, muss man nur 5 Minuten Bilderbuch bei Ali schauen.
Hallo,
weiss zufällig ein Spezi, wie man den TX FIFO maximal vollschreibt? Ich
habe bisher nur einen Datensatz (20 Bytes) reingetackert und dann
gesendet. Aber schneller geht es ja, wenn man gleich den TX FIFO ganz
voll macht mit 3 Datensätzen.
Wie schaut das denn codemässig aus?
Bei mir bisher:
Christian J. schrieb:> weiss zufällig ein Spezi, wie man den TX FIFO maximal vollschreibt?
Nein, ich weiss es nicht, aber ich hab ins Datenblatt geschaut.
Da steht:
------------------------------------------------------------------
The following FIFOs are present in nRF24L01+:
• TX three level, 32 byte FIFO
• RX three level, 32 byte FIFO
Both FIFOs have a controller and are accessible through the SPI by
using dedicated SPI commands. A TX FIFO in PRX can store payloads
for ACK packets to three different PTX devices. If the TX FIFO
contains more than one payload to a pipe, payloads are handled
using the first in - first out principle. The TX FIFO in a PRX is
blocked if all pending payloads are addressed to pipes where the
link to the PTX is lost. In this case, the MCU can flush the
TX FIFO using the FLUSH_TX command.
------------------------------------------------------------------
Daraus würde ich entnehmen dass ich in das FIFO solange hinein-
schreiben kann bis es voll ist, dann kann ich für jeden FIFO-
Inhalt einen TX auslösen, was zuerst reinkommt, kommt zuerst raus.
Moin,
weis zufällig jemand, wie man einen "optimalen" Kanal heraus finden
kann? Ich meine es geistert ja viel 2.4 Ghz Geraffel durch die zahllosen
WLAN in der Luft herum. Man müsste irgendwie rauskriegen wieviel
Störungen auf einem Kanal sind und dann den raussuchen der die wenigsten
hat.
Das mit dem FIFO ist recht tricky, ein 10us CE Puls haut nur 1 Fifo
Inhalt raus, hält man CE auf HIGH schiebt er alle raus bis leer.
Die Reichweite der LNA Module bekommt man deutlich besser, wenn man
denen mal Schirmung angedeihen lässt mit normaler ALU Folie.
Gruss,
Christian
Christian J. schrieb:> Du weisst ja nicht genau, ob der 16 Mhz für den RF Teil des Chip> zuständig ist, wo die die per PLL dann daraus 2,4Ghz machen.
Kann man im Datenblatt nachlesen, das es so ist. Der Quarz wird mit
tolerablen Abweichung von der Nennfrequenz spezifiziert.
Hast du eine Fritzbox? Die zeigt sehr schön die Belegung im
Frequenzbereich an. Aber der nRF kann doch auch den RSSI ausgeben, damit
müsste man auch einen Scanner bauen können.
Johannes S. schrieb:> ber der nRF kann doch auch den RSSI ausgeben, damit> müsste man auch einen Scanner bauen können.
Kann er nicht. Die einzige Anzeigemöglichkeit die er hat
ist ein Schwellwert von -64 dBm, ein Eingangs-Signalpegel
der entweder überschritten wird oder nicht.
Daraus einen RSSI abzuleiten - wie bei Handys oder WLAN Boxen
üblich - ist schon recht kühn.
Einfach schnell mal eine gewagte Information ins Forum
hinfetzen und gut is, gell? Jeden Tag eine "gute" Tat ....
Aus dem Datenblatt:
------------------------------------------------------------
6.4 Received Power Detector measurements
Received Power Detector (RPD), located in register 09, bit
0, triggers at received power levels above -64 dBm that are
present in the RF channel you receive on. If the received
power is less than -64 dBm, RDP = 0.
------------------------------------------------------------
Johannes S. schrieb:> Aber der nRF kann doch auch den RSSI ausgeben, damit> müsste man auch einen Scanner bauen können.
Woher stammt diese Information? Ich lese nur, dass es ein einziges Bit
gibt, was über einen Schwellwert Auskunft gibt. Und die Fritzbox zeigt
das zwar an, ist aber selbst ein Frequenzhopper. Das kann man ändern
aber da fasse ich lieber nichts an, da weitere 6 Boxen hier im Haus
aktiv sind.
Die einzige Chance, die man haben könnte ich eine Präambel als Schlüssel
zu wählen, die viele Störsignale durchlässt und damit die Kanäle zu
scannen. Leider erfährt man nicht, wann ein Störsatz kam, da dieser
direkt wieder verworfen wird.
Der nRF51822 hat eine RSSI Info, und da Nordic schreibt das der nRF24
kompatibel ist (+ integriertem Cortec-M0) hatte ich angenommen das der
nRF24L01 das auch ausgeben kann. Aber zum Glück gibt es hier Götter die
das gleich korrigieren können.
Im Nordic Forum findet man auch schnell die Antwort das der nRF24 keine
RSSI Anzeige hat.
Vielleicht lässt sich das ja doch benutzen. Wenn dieses Bit, unabhängig
von dem digitalen Zahelnsalat gesetzt wird heisst das ja, dass der Kanal
belegt oder frei ist. Da andere teilnehmer aber im Millisekundentakt die
Kanäle wechseln ist diese Info auch nicht viel wert. Ich stelle nur
fest, dass mein Slave viele Pakete erst beim 2.ten oder 3.ten Versuch
empfängt. Ich muss die Daten mehrfach senden, damit einer durchkommt.
6.4 Received Power Detector measurements
Received Power Detector (RPD), located in register 09, bit 0, triggers
at received power levels above -64 dBm that are present in the RF
channel you receive on. If the received power is less than -64 dBm, RDP
= 0.
The RPD can be read out at any time while nRF24L01+ is in receive mode.
This offers a snapshot of the current received power level in the
channel. The RPD status is latched when a valid packet is received which
then indicates signal strength from your own transmitter. If no packets
are received the RPD is
latched at the end of a receive period as a result of host MCU setting
CE low or RX time out controlled by Enhanced ShockBurst™.
The status of RPD is correct when RX mode is enabled and after a wait
time of Tstby2a +Tdelay_AGC= 130us + 40us.
Gähn....
nach einigem Testen in freier Luft hier hat sich dieses RPD Bit doch als
ganz nützlich erwiesen.
1
val=DWT->CYCCNT;
2
for(inti=0;i<128;i++){
3
RF_SetChannel(i);
4
Delay(200);
5
if(RF_ReadRegSingle(NRF24L01_REG_RPD)&0x01){
6
channels[i]=1;
7
RF_PowerUpRx();
8
}
9
}
Nach einer gewissen Zeit sieht man, dass sich die Kanäle um die
Masterfrequenz herum füllen der auf 40 sendet, also 37 bis 43 sind 1 und
auch diverse andere von den WLANs um mich herum. Es bleiben aber auch
genug frei.
Mit einer pfiffigen Routine lässt sich also ein freier Bereich
eingrenzen.
Nach jeder 1 Abfrage des Bits muss das 24L01 zurückgesetzt werden, also
Status löschen und Fifos. Sonst bleibt es 1.
Moin,
ich bastel immer noch mit diesem Stein herum und studiere das Datenblatt
zum x-ten Male. Was mir immer noch nicht ganz klar ist und das
vielleicht auch zu Datenverlusten führt (nur jedes 2-3 te Paket kommt
auch an) ist dieses:
Wie frage ich den TX Mode ab, ob er beendet ist? Funktioniert die SPI
Abfrage überhaupt in diesem TX Mode? Denn manche Befehle lassen sich nur
im Standby Mode einspielen. Ich lasse CE=1, da ich mir die Möglichkeit
offenhalten will den FIFO voll zuschreiben für fortlaufende Übertragung.
Ist das korrekt schon während der Sendephase laufend den Status zu
testen auf MAX_RT oder TX_DS?
Aktuell wiederhole ich jede Sendesequenz max. 5 Mal, da ich bemerkt
habe, dass oft der erste Satz nicht ge ACK'ed wird aber die
nachfolgenden schon.
Außerdem ist die Reichweite stark abhängig von dem Kanal: Von 1 bis ca
40 alles ok, reicht ein Mini-Modul für 1 Euro. Darüber ab ca Kanal 60
brauche ich ein LNA Modul mit Antenne, um noch ins Wohnzimmer zu kommen.
Sehr seltsam....
Datenblatt:
The nRF24L01+ stays in TX mode until it finishes transmitting a packet.
If CE = 0, nRF24L01+ returns to standby-I mode. If CE = 1, the status
of the TX FIFO determines the next action. If the TX FIFO is not empty
the nRF24L01+ remains in TX mode and transmits the next packet. If the
TX FIFO is empty the nRF24L01+ goes into standby-II mode. The nRF24L01+
transmitter PLL operates in open loop when in TX mode. It is important
never to keep the nRF24L01+ in TX mode for more than 4ms at a time. If
the
Enhanced ShockBurst™ features are enabled, nRF24L01+ is never in TX mode
longer than 4ms
1
/* TX und ACK Pipe setzen */
2
RF_WriteRegMulti(NRF24L01_REG_TX_ADDR,receiver,0x05);/* TX Pipe: Hier wird gesendet */
3
RF_WriteRegMulti(NRF24L01_REG_RX_ADDR_P0,receiver,0x05);/* RX Pipe: Hier wird ACK empfangen */
4
5
RF_PowerUpTX();
6
7
CSN_LOW;
8
/* Kommando Wort senden fuer Payload mit ACK*/
9
SPI_TransferByte(NRF24L01_CMD_W_TX_PAYLOAD);
10
/* Datenbytes in Pipe einspielen */
11
for(uint8_ti=0;i<len;i++)
12
SPI_TransferByte(*(ptr++));
13
CSN_HIGH;
14
15
/* RF Modul sendet jetzt... */
16
CE_HIGH;
17
Delay(11);
18
19
/* Ende der Übertragung abwarten... */
20
uint16_tto=50000;
21
do{
22
RF_GetStatus(&rf_status_reg);
23
if(!to--){
24
/* Timeout: Modul zurück auf Empfang vom Sensor setzen */
