NRF2401 - Kurzsketch eigenartiges Verhalten

Auf nem Original ARDUINO MEGA 2560 mit nem nRF24L01 wird der Sendercode von Arduino NRF24L01 Funkmodul verwendet.

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>

const byte rxAddr[6] = "00001";
int counter = 0;
RF24 radio(8, 9);

void setup() {
Serial.begin(115200);
radio.begin();
radio.setPALevel(RF24_PA_MAX);
radio.setDataRate( RF24_250KBPS );
radio.setRetries(15, 15);
radio.openWritingPipe(rxAddr);
// Disable Receiver
radio.stopListening();
}


void loop() {
counter++;
String str = "count: "; 
str += String(counter);
//Serial.println(str);
int str_len = str.length() + 1; 
char char_array[str_len];
str.toCharArray(char_array, str_len);
radio.write(char_array, sizeof(char_array));
Serial.print("Actual Transmission: ");
Serial.println( char_array );
//Serial.println(counter);  // Wenn Kommentierung entfernt alles schick... ???
delay(250);
}

Und jetzt das Phänomen:
Auf dem SerMon kommt folgende Ausgabe:

Actual Transmission: count: 1
Actual Transmission: count: 2
Actual Transmission: count: 1
Actual Transmission: count: 2
Actual Transmission: count: 1

Bei Empfänger kommt aber an:

count: 1
count: 2
count: 3
count: 1
count: 2

Also wollte ich wissen, was da in counter steht und füge eine Zeile ein, die auf dem SerMon den Inhalt anzeigt. Oben im Code die Zeile 32 die auskommentiert ist.
Und jetzt wird es ulkig:
Wenn die Kommentierung entfernt wird, kommt auf dem SerMon der Counter fortlaufend:

Actual Transmission: count: 50
50
Actual Transmission: count: 51
51
Actual Transmission: count: 52
52
Actual Transmission: count: 53
53

Auch die Übertragung funktioniert jetzt mit dem Inhalt. Sprich der Inhalt bei Sender und Empfänger ist gleich.

Was passiert hier?

Das delay zu verändern bringt keine Änderung. Ebenso die Änderung der Reihenfolge Serial.print und radio.write nicht.
Auch den String str vor dem setup zu deklarieren und im loop nur noch zu beschreiben ebenfalls nicht.

Ich sehe nur einen derben Bock, in deinem Programm, so auf Anhieb!

Dir fehlt in setup() ein pinMode(SS,OUTPUT);

evtl. auch:

radio.setDataRate( RF24_250KBPS );
radio.setRetries(15, 15);

Reicht da die Zeit für 15 Wiederholungen?

Das fehlende pinMode scheint kein echtes Problem zu sein, sonst käme ja beim Empfänger nichts an.

Der Sender Sketch müsste funktionieren, obwohl er String und delay benutzt :face_vomiting:.

Wie sieht denn der Empfänger Sketch aus?

Das geht so leider nicht trocken nachzustellen.
Ich wollte nur meine neuen Module alle durchtesten.

Bitte nicht auf den Empfänger konzentrieren.
Der Sketch stammt ebenfalls von Arduino NRF24L01 Funkmodul (Mal die URL ohne https eingefügt) und läuft auf einem originalem ARDUINO UNO.
Das Problem ist nicht die Übertragung als solche - die funktioniert.

Der Inhalt auf der Senderseite wird anders ausgegeben als tatsächlich übertragen und zudem wird der Zähler nicht weiter als 3 hochgezählt.

Wird der counter auf dem SerMon ausgegeben, stimmt alles. Sonst nicht.

Auf Ratespiele habe ich keine Lust. Viel Erfolg.

Hmm...
Was sind denn für dich "echte" Probleme?
Egal: Für "mich" ist das ein "echtes" Problem.
Auch hatten schon einige dieses "echte" Problem, hier im Forum.
Plötzliches Versagen des SPI Transfers, nur wg. zu faul die SPI Doku zu lesen.
Lieber stundenlang rum eiern, an der falschen Stelle suchen, als der Doku zu folgen.

Ich behaupte:
Das steht nicht in der Arduino Doku und auch im nicht Datenblatt, weil da noch 7cm² Platz war, und der Platz unbedingt mit Müll geflutet werden musste.
Sondern, das steht da drin, weil es Sinn macht.

Auch:
Über ein Fehlverhalten des Senders/Empfängers zu jammern, ohne die Rückgabe von radio.write() zu prüfen, halte ich für ein "echtes" Problem.

OK, OK, vielleicht bin ich ja auch zu pingelig....
Also alles ok!
Weitermachen!

Das pinMode beeinflusst Master/Slave Verhalten, es ist sicher richtig, das zu korrigieren,
ich bezweifle aber, dass das der Grund für den Fehler ist.

Dass der Counter merkwürdig zählt, hat sicher nichts mit SPI zu tun.

Der Empfänger ist geheim, gibt aber ein falsches Ergebnis.
Klar, falsche Ergebnisse entstehen immer nur beim Sender.

Nein. Der Empfänger ist das selbe.
Nur an nem UNO. So zumindest habe ich das geschrieben.

Ich hab jetzt den MEGA durch einen UNO-Klone ersetzt.
läuft.

Damit kannst du recht haben!

Mir ist bewusst, dass einfache Fehler, schon schwer zu finden sein können.
Doppelfehler, viel schwerer, weil sie u.U. die tragischen verdecken.
Tripel Fehler sind mit die gemeinsten, wenn sie einen Fehler an völlig anderer Stelle vortäuschen.

Aus dem Grund sehe ich da nur den Weg, einen Fehler nach dem anderen abzuarbeiten.
Mit Sorgfalt und Disziplin.

Ach, sowas ignoriere ich meist noch nicht mal...
Ich denke dann: "Wer wesentlichen Code verheimlicht, will keine Hilfe!"
Oder: "Der will nicht, dass ich teste, der will nur jammern."

Was auch immer das bedeuten soll.

Nachtrag:
Habe mir die Seite gerade mal angesehen!
OHA!
Eins der gruseligsten Tutorials, welches ich je gesehen habe!
Und: Ein pinMode(SS,OUTPUT); kann da Schaden anrichten.
Die Verschaltung ist da wirklich unglücklich gelöst.

Ich kann nur jedem Unbedarften den Rat geben:
Kurz drüber schauen, und weiter gehen.

Ich sprach nicht davon, das Tut anzuwenden. Ich nutze nur die Sketche von da, mit eigenem Aufbau.

Hmmm....
Ja, der Aufbau, ist bedenklich.
Das Programm, auch.

Ich frage mich auch, ob ich meine "Meinung", zu dem Tutorial, Aufbau und den Programmen, mal begründen soll?
  • Blos nicht
  • In Form eines Berichtes
  • Ein subjektiver Verriss
0 voters

Anmerkung:
* dieses ist keine geheime Wahl *

Ich frage mich auch, ob ich meine "Meinung", zu dem Tutorial, Aufbau und den Programmen, mal begründen soll?

Oh, Abstimmung .... :open_mouth:

Ja, muss man/ich doch alles mal testen und durchprobieren!
Neues Forum, neue Features :innocent:

Ja :slight_smile:
Interessant finde ich, dass man (ich) seine Meinung (die Abstimmung) auch nachträglich noch ändern kann :slight_smile:
Habe zuerst abgestimmt mit "In Form eines Berichtes" und jetzt geändert auf "Blos nicht" :slight_smile: :slight_smile:

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.