WIFI-Shields (nrf2401+) funktionieren nur sporadisch als Client

Hallo,

ich habe ein paar ganz einfache nrf2401+ (PCB Antenne).

Einer läuft als Server (Uno), zwei als Client (ProMini).

Der Server startet immer schnell.

Ich verwende die Bibliothek RF24Mesh (und RF24Network, RF24). Selbst die Beispiele Example (+ Example_Master) laufen nicht korrekt.

Die Clients laufen oft während mesh.begin(x); in einen Timeout, wenn nicht innerhalb von...30 Sekunden (?) erfolgreich. Dann läuft das Programm weiter, ohne dass die Verbindung aufgebaut wurde. Die LED 13 blinkt bis zum Timeout, danach leuchtet sie etwas gedimmt, so als würde Kommunikation stattfinden.

Die Shields werden durch die 3,3 Volt der Boards gespeist. An die Shields habe ich je einen 10 µF Kondensator zwischen VCC und GND gelötet.

Es sind dabei immer die Boards, die als Clients laufen, betroffen. Lade ich also die Konfiguration als Server auf eines der ProMini und lasse den Uno als Client laufen, funktioniert der Uno oft nicht.

Die ProMinis speiße ich, zu Testzwecken einer sauberen Eingangsspannung, mit Lipos (2S; 7,4 Volt) über RAW und GND.

Ich habe mehr als 3 Shields, daher habe ich noch weitere durchprobiert. Bei allen das gleiche.

Kennt ihr dieses Problem? Wie kann ich es beheben bzw. was kann ich Weiteres probieren?

:slight_smile:

AngelOfEffekt:
Einer läuft als Server (Uno), zwei als Client (ProMini).

AngelOfEffekt:
Die Shields werden durch die 3,3 Volt der Boards gespeist.

ProMinis haben keinen 3.3V Pin, oder?

Eine extra Stromversorgung wirkt oft Wunder.

Whandall:
ProMinis haben keinen 3.3V Pin, oder?

Richtig, ein ProMini hat keinen 3,3 Volt Regler on Board.

Es gibt ja auch die 3.3V 8MHz ProMinis, hoffentlich hat er die benutzt. :wink:

Whandall:
Es gibt ja auch die 3.3V 8MHz ProMinis, hoffentlich hat er die benutzt. :wink:

Ja, das stimmt, dann könnte es wieder passen.
Die haben den 3,3 Volt Regler OnBoard.
Aber da hat es dann sicher ein Problem mit der Verlustleistung des Reglers.

Das könnte dann auch sein Problem sein. Die Spannung (3,3 V) bricht zusammen.

Noch als Bemerkung für AngelOfEffekt:

NRF24L01+ Chips und WiFi 2.4MHz teilen sich den gleichen möglichen Frequenzbereich,
haben aber sonst nichts miteinander zu tun.

Shields sind Steckmodule die auf einen Arduino gesteckt werden können,
die NRF24L01+ sind überwiegend auf Module mit 2 x 4 Pin 2,54 mm Stecker montiert.

Was sind also deine "WIFI-Shields (nrf2401+)" ?

Bei mir zickten die Dinger auch oft rum. Vor allem die, die keinen Chip sondern nur einen schwarzen Klecks drauf haben. Hab nach ausgiebigen Tests 50% meines Bestandes entsorgt.

ElEspanol:
Bei mir zickten die Dinger auch oft rum. Vor allem die, die keinen Chip sondern nur einen schwarzen Klecks drauf haben.

Also nennst du die Module auch Shields?

Nein, sind keine Shields. module, Breakoutboards oder wie auch immer. Shields steckt man normalerweise auf eine Basiseunheit, wie z.B. Der Uno oder Mega

Das sehe ich genauso. Deshalb meine Verwirrung und Nachfrage. :wink:

Danke für die Rückmeldungen.

Ich hatte heute endlich mal wieder richtig Zeit zum basteln.

Ja, ich verwende die 3,3V Version.

Zu Testzwecken habe ich das Modul über 2xR6 Batterien als Spannungsversorgung versorgt (Minus zum Arduino geführt). Leider funktioniert es, wenn die Module sich mal mal wieder nicht verbinden können, auch dann nicht.

Mir fiel inzwischen auch auf, dass, wenn ein Modul zum Zeitpunkt der Tests nicht funktioniert, auch die anderen nicht funktionieren. Umgedreht genauso - wenn ein Modul eine Verbindung aufbauen kann, können bei Tausch andere Module es auch.

Ein bisschen frustrierend ist es schon, dass alles soweit klappt, jedoch die Verbindung nur sporadisch zustande kommt :frowning:

AngelOfEffekt:
....
Mir fiel inzwischen auch auf, dass, wenn ein Modul zum Zeitpunkt der Tests nicht funktioniert, auch die anderen nicht funktionieren. Umgedreht genauso - wenn ein Modul eine Verbindung aufbauen kann, können bei Tausch andere Module es auch.

Ein bisschen frustrierend ist es schon, dass alles soweit klappt, jedoch die Verbindung nur sporadisch zustande kommt :frowning:

Dann würde ich den Fehler doch mal am Netzwerk (Router o.ä.) oder Sketch suchen.

HotSystems:
Dann würde ich den Fehler doch mal am Netzwerk (Router o.ä.) oder Sketch suchen.

Ich muss hier Whandall nochmal explizit Recht geben. Es handelt sich nicht um WiFi etc., sondern nur die gleiche Sendefrequenz. Die haben somit nichts mit dem WLAN der Router am Hut.

Einen Fehler im Code hatte ich inzwischen ausgeschlossen, da ich mich mit diesem bereits recht ausgiebig beschäftigte.

Ich poste hier nochmal mein Startscript, runtergebrochen auf das, was für den Start (wo es bereits klemmt) relevant ist...

HA.h

#include <HA_SetUp.h>
#include <Arduino.h>
#include <RF24.h>
#include <RF24Network.h>
#include <RF24Mesh.h>
#include <Ethernet.h>
#include <SPI.h>

#ifdef master
#include <EEPROM.h>
#endif

#ifndef HA_Code
#define HA_Code

//Requestschema vom µC:
//http://192.168.0.9/Client/SubControl/Action
// ^Addresse immer gleich
// ^entspricht dem Wert von eHANodeTypes
// Wenn der Wert -1 übergeben wurde, wird nichts gesetzt, sondern die Status aller Clienten zurück gegeben
// ^Identifier, falls Client mehrere Objekt verwaltet
// ^Wert, der gesetzt werden soll. Sollte irgendetwas zwischen 0 und 100 sein.
// Wenn der Wert -1 übergeben wurde, wird nichts gesetzt, sondern nur der Status ausgelesen


//Definiert die Stationarten.
//Danach richtet sich, wie sich der Knoten verhält (Server oder Client)
enum eHANodeTypes { Master, Woodlamp, Flexenlamp, CorridorNight };
//Definiert die Funktionsmodi.
enum eHANodeModes { Server, Client };

class HA
{
private:
 
protected:

public:

 RF24 radio;
 RF24Network network;
 RF24Mesh mesh;

 eHANodeModes mode;
 eHANodeTypes type;

 long refreshTimer = 0;

 //Die letzte Stelle wird durch den INT-Wert des eHANodeTypes ersetzt.
 byte macAddress[6] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0x01 };

 String debugMessages = "_";
 HA(eHANodeTypes nodeType);
 void Init();
#ifdef debugPrintDebugMessage
 void printDebugMessage(const String& text, bool newLine);
#endif
};

#ifdef master
class ServerFunctions : public HA
 {
private:
 EthernetServer server;
 IPAddress ipAddress;
 
public:
 ServerFunctions(eHANodeTypes nodeType);
 void Init();

};
#endif

#endif

HA.cpp

#include <Arduino.h>
#include <HA.h>
#include <RF24.h>
#include <RF24Network.h>
#include <RF24Mesh.h>
#include <Ethernet.h>
#include <SPI.h>

#ifdef master
#include <EEPROM.h>
#endif

HA::HA(eHANodeTypes nodeType)
 : radio(7, 8), network(radio), mesh(radio, network)
{
#ifdef debugStart
 debugMessages += "HA:";
#endif
 type = nodeType;
 mode = (nodeType == Master ? Server : Client);
 macAddress[5] = (int)nodeType;
 
#ifdef debugStart
 debugMessages += "Done\n";
#endif
}
void HA::Init()
{
#ifdef debugStart
 printDebugMessage("WLAN Mesh starten:", false);
 printDebugMessage("Type:", false);
 printDebugMessage((String)((int)type), false);
#endif
 mesh.setNodeID((uint8_t)type);
 mesh.begin();
#ifdef debugStart
 printDebugMessage(" done;", true);
#endif
}

#ifdef master
ServerFunctions::ServerFunctions(eHANodeTypes nodeType)
 : HA(nodeType), ipAddress(192,168,0,9), server(80)
{
#ifdef debugStart
 debugMessages += "Konstrukutor ServerFunctions;\n";
#endif
}
void ServerFunctions::Init()
{
#ifdef debugStart
 printDebugMessage("Ethernet und Server starten:", false);
#endif
 Ethernet.begin(macAddress, ipAddress);
 server.begin();
 refreshTimer = millis();
#ifdef debugStart
 printDebugMessage("Done;", true);
#endif
 HA::Init();
}
#endif

#ifdef debugPrintDebugMessage
void HA::printDebugMessage(const String& text, bool newLine) {
 Serial.print(text);
 if (newLine) {
 Serial.print("\n");
 }
}
#endif

HA_SetUp.h

//#define master
#define flexenlamp
//#define corridornight








#define debugUpdateConnectedDevices
//#define anyDebug

#ifdef anyDebug
#define debugForewardRequest
#define debugGetStatesEthernetResponse
//#define debugGetNodeAddressByID
//#define debugGetValueAtIndex

//#define debugStart
#define debugUpdate
#define debugSendData
#define debugGetStates
//#define debugSetStates

//#define debugInternalInput

//#define debugSerialInput
#endif

#if defined anyDebug || defined debugUpdateConnectedDevices
#define debugPrintDebugMessage
#endif

#ifndef master
#define MESH_NOMASTER
#endif

#if ((defined woodlamp || defined corridornight) && defined master ) || (!defined flexenlamp && !defined corridornight && !defined master)
#error lol
#endif

automation.ino

#include <HA.h>

#ifdef master
  ServerFunctions automation(Master);
#else
  #ifdef woodlamp
  HA automation(Woodlamp);
  #elif defined flexenlamp
  HA automation(Flexenlamp);
  #elif defined corridornight
  HA automation(CorridorNight);
  #endif
#endif

void setup()
{
  Serial.begin(9600);
  
  Serial.println(automation.debugMessages);
  automation.Init();
  

  Serial.print("Knoten ");
  #ifdef master
  Serial.print("master");
  #elif defined flexenlamp
  Serial.print("flexenlamp");
  #elif defined corridornight
  Serial.print("corridornight");
  #endif
  Serial.println(" gestartet");
}

void loop()
{
 //automation.Update();
}

Die ino bindet HA ein, erstellt das Objekt automation aus der Klasse (Master/Flexen/Corridor; im akutellen Falle für Flexen) und führt die schlussendliche Bindung etc. im Setup durch automation.Init() durch.

Flexen und Corridor sind Clients, Master ist der Server.

Ist das noch irgendwie verständlich?

Mir ist gerade aufgefallen, dass ich den Server im Problemfall während der Lösungsversuche bisher nie richtig von der Stromversorgung getrennt habe, sonder immer nur per Reset zurück gesetzt.

Das habe ich gerade (vermutlich das erste mal) gemacht und auf Anhieb habe ich wieder ein Verbindung zum Client.

Das werde ich die kommenden Tage beobachten

Wenn wir bereits beim Thema Code sind...
Ist es, wie in den Beispielen dargestellt, tatsächlich notwendig, in jedem Durchlauf von Loop mesh.DHCP(); (Server) und mesh.update(); (Server und Client) aufzurufen?

Zum solche Hardware Probleme austesten, nimmt man am besten immer Beispielsketches der Libs.

Vielen Dank für eure Rückmeldungen. Schön, dass ich jetzt auch mit den Begrifflichkeiten sicherer bin :slight_smile:

Das Problem trat tatsächlich immer dann auf, wenn ich den Master nicht komplett von der Spannungsversorgung trennte,sondern nur mit Reset zurück setzte (zumindest bis jetzt).

Ich hatte nebenbei auch das Problem, dass sich der Client nicht mehr richtig am Master anmeldete, wenn der Master (in welcher Weise auch immer) zwischenzeitlich offline war. Der Client konnte dann zwar wieder kommunizieren und die Pakete wurden vom Master auch entgegen genommen, nur tauchte der Client nicht mehr in der Adressliste des Masters auf. Dadurch konnte der MAster keine Anfragen mehr zum Client senden.

Auf dem Weg zum dahin, die Bibliothek dahingehend zu ändern, dass die Einträge in solchen Fällen wieder eingetragen werden, fand ich einen interessanten Beintrag:

Ein einfaches CheckConnection clientseitig reicht bei mir nicht, da der Client aus seiner Sicht ja auch tatsächlich verbunden ist. Nur der Server kommt nicht auf Stand.
Also sendet der Client jetzt alle 15 Sekunden ein Request mit dem Command TestConnection. Der Master prüft bei diesem Command, ob die Adresse des eingeheneden Requests gelistet ist. Wenn nicht, sendet er ein Command Reset zurück. Der Client führt ein RenewAddress aus und schon ist er wieder gelistet.


Aktuell habe ich das Problem, dass der Server immer erst dann einen eingehenden Request über network.available() erkennt, wenn bereits ein weiterer gesendet wurde. Also ist somit der letzte Request immer in der Warteschleife, bis der nächste kommt. Das hat auch als Auswirkung, dass Statusabfragen wie Licht an? etc. nach einer Änderung erst zur 2. Anfrage danach den akutellen Wert sendet.

Sollte ich dafür besser ein neues Thema aufmachen?