Arduino Uno NRF24L01+ Test Code -------------------------------- (c) NRFTestGuy 07'2016 Free for private non-commercial usage. Also works with the Windows App NRF24_Tester available here: Beitrag "NRF24L01 - Testprogramm für Windows PC" Prerequisites --------------- - Arduino Uno (Arduino Micro, Arduino Nano) must be set up to run at 16 MHz The Arduino as a board is not absolutely required. You can use a naked ATMega328p running at 16 MHz with RS232 connection to your computer. Just use the port pins PB0-PB5 (as documented in the Fritzing schematic) and the RX/TX lines. - USB Connection to Arduino's USB Port - NRF24L01+ wired to the Arduino (see Fritzing schematic) - A Terminal Application on your PC (connect at baud rate 115200 baud, 8 bit, 1 stop, no parity) - A Programmer (such as AVRDude) to put the HEX file via USB connection on your Arduino - program the hex file in your ATMega328 This is how the terminal output should look like: Arduino Uno - NRF24L01+ Test Version 0.10 (c) NRFTestGuy (Build xxx xx xxxx xx:xx:xx) ----------------------------------- T: Transmit Data R: Receive Data F: Fast Transmit G: Fast Receive L: NRF24 Loopback Test O: Continuous Loopback Test S: Show Parameters A: Required Pin Assignments config:0x2D status:0x0E mem:127 ----------------------------------- >
Angehängte Dateien:
-
Arduino_Uno_NRF24_wiring.png
110 KB
...also ein SPI-RS232-USB-VirtualCom Konverter mit Funktionsgarantie für NRF24. Interessant. Funktioniert das auch performant mit 1Mbit und 2Mbit? HW/Handshake beim RS232?
:
Bearbeitet durch User
Lars R. schrieb: > ...also ein SPI-RS232-USB-VirtualCom Konverter Nein. Ein Arduino (Mega328-) Code zur prinzipiellen Funktions- überprüfung. Man lese den Titel (--> Test Program) Lars R. schrieb: > mit Funktionsgarantie für NRF24. Willst du ein Zertifikat? Lars R. schrieb: > Funktioniert das auch performant mit 1Mbit Ja. Im Fast Mode werden Pakete nicht angezeigt sondern nur ein minimalistischer Funktionsablauf gezeigt der das Senden/ Empfangen von Paketen bestätigt. Die Netto-Datenrate (payload) liegt bei 1 Mbit etwa bei 1200 Paketen (a 32 Bytes) pro Sekunde. Mit Arduino-Lib wird das wohl nicht so funktionieren. Im nicht-fast Mode wird das empfangene Paket angezeigt. Durch die Ausgabe via Terminal wird die Transfer-Rate heruntergebremst. Lars R. schrieb: > und 2Mbit? Nein weil Bitrate festverdrahtet ist auf 1 Mbit.
NRFTestGuy schrieb: > Lars R. schrieb: >> mit Funktionsgarantie für NRF24. > > Willst du ein Zertifikat? Nein, so war das nicht gemeint. > Lars R. schrieb: >> Funktioniert das auch performant mit 1Mbit > > Ja. Im Fast Mode werden Pakete nicht angezeigt sondern nur > ein minimalistischer Funktionsablauf gezeigt der das Senden/ > Empfangen von Paketen bestätigt. Die Netto-Datenrate (payload) > liegt bei 1 Mbit etwa bei 1200 Paketen (a 32 Bytes) pro Sekunde. > Mit Arduino-Lib wird das wohl nicht so funktionieren. Ein Mehrwert (der ursprünglich nicht von Dir absichtigt war), entsteht, wenn man das NRF24 komfortabel über UART oder virtualCOM konfigurieren kann und dann eine transparente UART-Verbindung hat. Wobei die Verbindung auch nicht komplett transparent sein braucht; nur so, dass man auf einfache Weise eine Datenverarbeitung anbinden kann. 2Mbit müssen es für mich nicht sein, aber weniger als 1MBit Over-the-air ist für manche Anwendungen zu wenig. Da geringen Datenraten sind dann die RFM performanter. > Lars R. schrieb: >> und 2Mbit? > > Nein weil Bitrate festverdrahtet ist auf 1 Mbit. Wo? Bei der Beschaltung des nrf24?
:
Bearbeitet durch User
Lars R. schrieb: > Wo? Bei der Beschaltung des nrf24? Auch eine Software kann "festverdrahtet" sein. Im Gegensatz zu konfigurierbar oder parametrisierbar. Lars R. schrieb: > wenn man das NRF24 komfortabel über UART oder virtualCOM konfigurieren > kann und dann eine transparente UART-Verbindung hat. Das war absolut nicht Sinn der Übung. Du würdest sicherlich auch bei Kommunikation Wert darauf legen einen zuverlässigen Partner jederzeit zur Verfügung zu haben. Dieses Stück Programm erfüllt genau diesen Anspruch.
..."fest kodiert", um Verwirrungen vorzubeugen; gerade bei HW-bezogenen Projekten. ...schon klar, wie geschrieben. Ich wollte nur noch einen anderen Weg aufzeigen. Wie im anderen Thread bereits geschrieben wurde: Wenn man sich für die Nutzung eines NRF24 selbst in das NRF24 einarbeiten muss, weil Dein Projekt für die Nutzung nicht vorgesehen ist, dann braucht man Dein Projekt auch nicht, weil man sich ohnehin selbst einarbeiten muss. Natürlich war das Projekt sinnvoll für Dich. Nur, wenn die Projekteigenschaften derart sind, dass dieses Projekt nur für Dich einen Vorteil hatte und haben kann und dies auch so bleiben soll, so stellt sich die Frage, warum Du das Material dazu hier überhaupt online und zur Diskussion stellst. Vielleicht ist mir das entgangen. Etwa für den Fall, dass man ein paar NRF24 herumliegen hat, sich nicht einarbeiten will, weil man ohnehin die Nutzung nicht plant, aber trotzdem mal schauen will, ob sie noch funktionieren?
Lars R. schrieb: > so stellt > sich die Frage, warum Du das Material dazu hier überhaupt online > und zur Diskussion stellst Ich stelle es zur Verfügung. Zur Diskussion stelle ich es nicht, (wo wäre diese Bemerkung zu finden?) habe nicht dazu aufgerufen, habe aber auch nichts dagegen.
Angehängte Dateien:
-
NRF24_Test_Adapter_Circuit_on_Uno_Shield_-_DSCN7432.jpg
59 KB -
NRF24_Test_Adapter_Circuit_on_Uno_Shield_-_DSCN7433.jpg
65 KB -
NRF24_Test_Adapter_Circuit_on_Uno_Shield_-_DSCN7434.jpg
48 KB -
NRF24_Test_Adapter_Circuit_on_Uno_Shield_-_DSCN7435.jpg
51 KB -
Arduino_to_NRF24_Test_Adapter_back_-_Dscn7412.jpg
56 KB -
Arduino_to_NRF24_Test_Adapter_front1_-_Dscn7413.jpg
64 KB -
Arduino_to_NRF24_Test_Adapter_front2_-_Dscn7414.jpg
51 KB -
Arduino_Uno_and_NRF24_Test_Adapter_-_Dscn7410.jpg
59 KB
Hier zwei Beispiel-Aufbauten welche einwandfrei funktionieren (entsprechend der Eingangs gezeigten Schaltung). Hervorzuheben wären die jeweils vorhandenen Abblock- Kondensatoren die den NRF24 erst auf den Arduinos funktionssicher machen. Man darf sich keinesfalls alleine auf die Stabilisierung und Entstörung der Versorgung von den Arduinos zum NRF24 hin verlassen. Diese Aussage mag nur teilweise zutreffen da es bekanntlich eine grosse Auswahl von mehr oder weniger verschieden hergestellten Arduinos gibt (Bauteil- bzw Layout-Streuungen). Aber zwei zusätzliche Kondensatoren kosten nichts und geben die Sicherheit dass an dieser Stelle nichts im Argen liegt.
NRFTestGuy schrieb: > Im nicht-fast Mode wird das empfangene Paket angezeigt. Durch > die Ausgabe via Terminal wird die Transfer-Rate heruntergebremst. Darf ich noch einmal darauf zurück kommen? Auf welchen Wert wird die Transfer-Rate bei Ausgabe via Terminal aktuell heruntergebremst? Kannst Du abschätzen, was mit Deinem Design mit einem STM32-Arduino (32Bit, 72MHz, HW-SPI) möglich ist? > Ja. Im Fast Mode werden Pakete nicht angezeigt sondern nur > ein minimalistischer Funktionsablauf gezeigt der das Senden/ > Empfangen von Paketen bestätigt. Die Netto-Datenrate (payload) > liegt bei 1 Mbit etwa bei 1200 Paketen (a 32 Bytes) pro Sekunde. 1200*32*8=0.3Mbit Ist diesbezüglich trotz deaktivierter Terminalausgabe das Bottleneck der ATMega328p?
Lars R. schrieb: > Darf ich noch einmal darauf zurück kommen? Ja sicher. Lars R. schrieb: > Auf welchen Wert wird die Transfer-Rate bei Ausgabe via Terminal aktuell > heruntergebremst? Das ist nicht relevant, auch schlecht messbar. Dahingehend habe ich nichts optimiert, daher ist ein Rückschluss auf das maximal Mögliche nicht ermittelbar. Lars R. schrieb: > Kannst Du abschätzen, was mit Deinem Design mit einem STM32-Arduino > (32Bit, 72MHz, HW-SPI) möglich ist? NRFTestGuy schrieb: > Die Netto-Datenrate (payload) > liegt bei 1 Mbit etwa bei 1200 Paketen (a 32 Bytes) pro Sekunde. Das trifft es schon ganz gut. Die Begrenzung liegt an der SPI Datenrate mit der man den NRF speisen darf. Und die liegt zufällig bei den 8...10 MBit/s die ein AVR kann. Eine leichte Verbesserung wird man noch mit SPI-DMA auf einem ARM erreichen können, und das "Umkopieren" des Datenblocks mag auch noch etwas schneller vonstatten gehen. Also alles in allem vielleicht 1500-2000 Pakete/s ..... Lars R. schrieb: > 1200*32*8=0.3Mbit So darf man nicht rechnen, denn der Overhead den der NRF braucht ist enorm (siehe Timing-Diagramme). Und man darf nicht übersehen dass bei jedem Paket ein Acknowledge dabei ist, eine Garantie dass die Daten korrekt, fehlerfrei angekommen sind. Wenn man das nicht braucht geht es ohne Ack nochmal schneller. Lars R. schrieb: > mit Deinem Design hat das nicht viel zu tun (ich schliesse ja den NRF auch nur an das SPI an) ausser dass ich schon immer Speed wollte und ich dahingehend vielleicht etwas "optimierend" arbeite, keine Arduino-Lib auch nur anrühre ...
NRFTestGuy schrieb: > Eine leichte Verbesserung wird man noch mit SPI-DMA auf einem ARM > erreichen können, und das "Umkopieren" des Datenblocks mag auch > noch etwas schneller vonstatten gehen. Also alles in allem > vielleicht 1500-2000 Pakete/s ..... > > Lars R. schrieb: >> 1200*32*8=0.3Mbit > > So darf man nicht rechnen, denn der Overhead den der NRF braucht > ist enorm (siehe Timing-Diagramme). Und man darf nicht übersehen > dass bei jedem Paket ein Acknowledge dabei ist, eine Garantie dass > die Daten korrekt, fehlerfrei angekommen sind. Wenn man das nicht > braucht geht es ohne Ack nochmal schneller. Das hatte ich nicht bedacht, weil ACK für mich nicht wichtig ist. Ja, es ist dann schon performant wenn 1500-2000 Pakete mit ACK übertragen werden und ohne ACK mehr.
Um mal zu sehen was beim NRF24 theoretisch "geht" hier eine Abschätzung zur Datenrate: Ein gesamtes Paket besteht aus Preamble 1 Address 5 Packet control field 2 (9 bit, unklar) Payload 32 CRC 2 --------------- Summe 42 Bytes 42 x 8 = 336 bits 336 bits @ 1MBit/s --> 336 usec wenn man annimmt dass die Codierung auf dem HF-Träger nicht redundand ist. Hinzu kommt eine interne Verarbeitungszeit der Maschine für ein Paket die offensichtlich fest 130usec dauert. Das Mindeste für einen ACK-Transfer von 32 Bytes bei 1MBit/sec wären also 466usec, Overhead des Mikrocontrollers nicht mitgerechnet. Zurückgerechnet auf die maximal mögliche Datenrate wären das 2145 Blöcke/s (à 32 Bytes netto ergibt 68640 Bytes/s) rein bezogen auf das was der NRF24 zu leisten vermag. Bei 2 MBit/sec kann man das nochmal etwas schneller werden aber die 130usec Verarbeitungszeit bleiben wohl fest. Für Das "Abholen" (oder Senden) eines Blocks mit dem Mikrokontroller (beschränkt durch die SPI Datenrate 10MBit/sec des NRF24) wären dann noch mindestens 25usec zusätzlich erforderlich. Nehmen wir mal für SPI Kommandierung und Interrupt-Latenz noch 5usec dazu ergibt das für ein gesamtes Paket 466+30usec = 496usec oder umgerechnet 2016 Blöcke/s (ergibt eine Netto-Datenrate von gut 64 KBytes pro Sekunde). Falls ich etwas nicht richtig betrachtet habe korrigiert mich.
In Deiner Kalkulation habe ich keinen Rechenfehler gefunden. Falls man jedoch die Shockburst-Features und ACK nicht benötigt, so ist die minimale Packetgröße: Preamble 1 Address 3 Payload 32 ============ 36 Byte = 288Bit http://yveaux.blogspot.de/2014/07/nrf24l01-sniffer-part-1.html Mit Shockburst und ACK in Bits: Preamble 8 (1 Byte) Address 24 (3 Byte) Packet control field 9 Payload 256 (32Byte) CRC 8 (1 Byte) --------------- 305 Bits Die Variante ohne Shockburst finde ich nicht deshalb interessant, um die letzten Prozente an Performanz heraus zu holen, sondern weil man ohne Shockburst auch Pakete mit fehlerhaftem CRC empfangen kann.
> Falls ich etwas nicht richtig betrachtet habe korrigiert mich.
Die Quelltexte fehlen (mir).
Lars R. schrieb: > sondern weil man > ohne Shockburst auch Pakete mit fehlerhaftem CRC empfangen kann. An welche Anwendung (mit ohne ACK) denkst du da? Mir fällt da momentan nur Audio Streaming ein wo es nicht auf das letzte Bit ankommt, oder Nahfeld-Kommunikation beliebiger Art wo die Übertragung an sich sowieso sicher(er) ist. Mir leuchtet nicht so recht ein was man mit geschrotteten Empfangspaketen machen kann .....
Anmerkung: Vielleicht wird ein Teil der 130usec auch für das Shockburst-Protokoll und die CRC-Berechnung benötigt.
Lars R. schrieb: > Vielleicht wird ein Teil der 130usec auch für das Shockburst-Protokoll > und die CRC-Berechnung benötigt. So ist es wohl.
NRFTestGuy schrieb: > Lars R. schrieb: >> sondern weil man >> ohne Shockburst auch Pakete mit fehlerhaftem CRC empfangen kann. > > An welche Anwendung (mit ohne ACK) denkst du da? > https://hackaday.io/project/11942-antenna-diversity-receive-and-transmit Ich würde die Algorithmen und die praktische Nützlichkeit gern erst einmal am PC testen. Daher der Wunsch nach einem UART-Umsetzer.
Hier wurde mit dem ESP8266 erwartungsgemäß gemessen und visualisiert, dass der Empfang von 2.4GHz-Signalen je nach Umgebung (die sich ggf auch noch verändert) lokal stark schwankt: https://youtu.be/aqqEYz38ens?list=PLDRymMFQl3Nktk_pjlUP_wbLIXre3sody&t=168 Eine Antenne kann zu einem Zeitpunkt aber immer nur an einer Stelle sein...
Lars R. schrieb: > Daher der Wunsch nach einem UART-Umsetzer. Nimmst du die Arduino-Lib und schreibst deinen "Dreizeiler" zum Kommunizieren mit der RS232.
NRFTestGuy schrieb: > Lars R. schrieb: >> Daher der Wunsch nach einem UART-Umsetzer. > > Nimmst du die Arduino-Lib und schreibst deinen "Dreizeiler" > zum Kommunizieren mit der RS232. Diesbezüglich ergeben sich Fragen: Ist die Lib für den Betrieb ohne Shockburst vorgesehen? Ist die Lib auch performant genug und holt wirklich jedes Paket aus dem NRF? Nutzt sie dafür den IRQ? Gibt es diesbezüglich Stolpersteine mit dem Arduino, die eine hohen Durchsatz verhindern können? (Habe noch nichts mit Arduino gemacht) Am Besten ist wohl der Betrieb am STM32-Arduino für 2,50EUR von Ebay? Wahrscheinlich benötige ich auch noch eine einmalige Synchronisation zwischen den Empfangern. Mein Eindruck war, dass es mit einem "Dreizeiler" nicht getan ist. Daher habe ich das erst einmal liegen lassen.
Lars R. schrieb: > Diesbezüglich ergeben sich Fragen: .... die ich dir nicht beantworten kann, die sich aber durch ein Studium der (offenen) Quellen und der Arduino-API klären lassen können. Lars R. schrieb: > Mein Eindruck war, dass es mit einem "Dreizeiler" nicht getan ist. Dafür habe ich ja auch nicht Dreizeiler geschrieben sondern "Dreizeiler". Bei der Arduino Gemeinde ist alles immer soooooooo einfach .....
Eben deshalb. Die Lib ist dafür nicht vorgesehen. Es geht nicht mit einem Dreizeiler und auch nicht mit einem "Dreizeiler" ;) Achso. Oder meintest Du die ganze Aussage ironisch? Falls ja, dann Zustimmung.
:
Bearbeitet durch User
NRFTestGuy schrieb: > Lothar schrieb: >> Die Quelltexte fehlen (mir). > > Soll ich dir das PDF vom NRF24 hier reinkopieren? Ja.
Du wirst mit RS232-Umsetzung vermutlich sowieso nicht die "Performanz" (gibt's das?), Performance herausholen können die du dir wünschst. Nicht einmal mit einem FT2232 der direkt SPI könnte, denn das USB Protokoll lässt nur einzelne Transfers (mehrere Kommandos + IRQ Polling + 1 Nutzdatenblock) im 1ms-Zeitraster zu die die ganze Kommunikation stark ausbremsen. Alles selbst schon durchgemacht. Deshalb habe ich diesen Ansatz schon mal nicht umgesetzt, nicht zuletzt wegen des Aufwands ein Testinterface mit FT2232 aufzubauen.
NRFTestGuy schrieb: > Du wirst mit RS232-Umsetzung vermutlich sowieso nicht die > "Performanz" (gibt's das?), Performance herausholen können > die du dir wünschst. > > Nicht einmal mit einem FT2232 der direkt SPI könnte, denn > das USB Protokoll lässt nur einzelne Transfers (mehrere > Kommandos + IRQ Polling + 1 Nutzdatenblock) im 1ms-Zeitraster > zu die die ganze Kommunikation stark ausbremsen. > > Alles selbst schon durchgemacht. Deshalb habe ich diesen > Ansatz schon mal nicht umgesetzt, nicht zuletzt wegen des > Aufwands ein Testinterface mit FT2232 aufzubauen. Da sehe ich kein Problem, zumindest nicht beim Empfangen. Die Daten landen im Buffer. Beim Senden kann es sein, das man mit dem Schreiben von lediglich 32Byte nicht die volle Performance erzielt. Aber dazu gibt es Optionen im Treiber. Vielleicht könnte man ja auch mehrere Pakete auf einmal schicken? Ein paar Byte SRAM hat der uC schließlich auch. Der Ablauf wäre wie folgt: PC sendet "C" (oder ähnliches): Es folgen Konfigurationsdaten PC sendet "T": Es folgen 32 Byte Daten Idealerweise hat der uC HW-Handshake für UART. Dieses kann man am PC auswerten. Falls der uC kein Handshake hat (AtMega), so müsste der uC jedesmal ein "R" für Ready schicken. Alternativ legt man fest, dass der uC eine bestimmte Menge Daten pro Zeit auf jeden Fall vom PC empfangen und über NRF24 wegsenden kann. Beim Empfänger würde der uC einfach alles auf den UART schreiben. Der PC muss es eben schnell genug aus dem Buffer holen. Das sollte bei diesen Transferraten passen. (Auch hier bestünde zusätzlich die Möglichkeit für Handshake, wenn es der uC könnte. Ich denke jedoch, dass es auch ohne geht) USB->SPI->NRF24 sehe ich auch nicht.
Anmerkung: Die Idee, dass der uC dem PC jede Übertragung mir "R" bestätigt, wird wohl nix. Aber selbst ohne hardware-Handshake-Funktionalität könnte der uC die entsprechende Handshake-Leitung des USB-Uart-Interfaces über einen IO schalten, wenn sein Buffer fast voll ist und er mit dem Wegsenden der Daten über das NRF24 nicht hinterher kommt.
NRFTestGuy schrieb: > Lothar schrieb: >> Ja. > > Mach ich aber nicht. Kannst du dir bei Nordic selbst abholen. > NRFTestGuy = Arduinoquäler War nicht anders zu erwarten.
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.