• Hallo Zusammen, Aufgrund der aktuellen Situation setzten wir die Möglichkeit aus, sich mit Gmail zu registrieren. Wir bitten um Verständnis Das RCMP Team

Praxisbericht WEMOS D1 mini mit TFT RGB Display und NRF24l01

BAXL

Admin
Mitarbeiter
In den Berichten WEMOS D1 mini mit NRF24l01 und WEMOS D1 mini mit 240x320 2,4" TFT Display RGB habe ich die genannten Geräte getrennt an den WEMOS angeschlossen und erfolgreich in Betrieb nehmen können. Für beide Geräte wird der SPI-Bus zur Ansteuerung verwendet. Spannend war nun, ob beide Geräte gemeinsam am SPI-Bus laufen, weil einige WEMOS-Ports gemeinsam und einige Ports getrennt benutzt werden. Ich mußte zudem Anschlüsse des NRF24 auf andere Ports legen.

Die Programmanpassung (Verschmelzung) verlief relativ reibungslos. Lediglich der CSN-Pin vom NRF musste von D2 auf D8 gelegt werden weil der WEMOS-D2 Port vom Display als Chip Select-Anschluß benötigt wird. Unklar war, wie sich die eingebundenen Libraies untereinander vertragen, weil die Module beide den SPI-Bus nutzen, aber nur für das NRF24 die SPI-Lib eingebunden werden musste.

Das Display scheint dann die SPI-Lib nicht zu benötigen, weil das möglicherweise in den anderen Libs nachgebildet wird, ich habe mir aber noch nicht die Mühe gemacht, danach zu suchen.

Nach dem Kompilieren und Übertragen des neuen Programms auf den WEMOS konnten die übermittelten Daten vom Nano eingelesen werden, das konnte ich auf dem seriellen Monitor der Arduino IDE sehen. Allerdings war das Display weiß und regte sich nicht. Weder der Hintergrund wurde, wie definiert, blau eingefärbt, noch wurde ein Text angezeigt. Am naheliegensten war, dass ich beim Anschließen einen Fehler gemacht hatte, weil ich die Leitungen des Displays vom zweiten WEMOS auf den Ersten umgesteckt hatte.

Nach dem Vergleich der Anschlüsse und Ports konnte ich den Fehler schnell finden. Ursache war die Anordnung der WEMOS auf meinem Experimentierboard, beide WEMOS waren spiegelverkehrt auf dem Board und zwar punktsymmetrisch und nicht achsensymmetrisch. Darauf hatte ich in der erwartungsvollen Eile nicht geachtet.

Darum mein Tipp, immer alles in Ruhe und doppelt überprüfen. Der Fehler ist meist der Mensch!

Nachdem das behoben war, klappte es sofort. Das Display zeigte artig die per Funk übermittelte Statusänderungen am digitalen Eingangsport des Nanos an.

Die Belegung ist nun wie folgt:

WEMOS D1 miniNRF24l01TFT RGB Display
VCCVCCVCC und BLK
GGNDGND
D0
D1CE-
D2-CS
D3-RES
D4-DC
D5SCKCLK
D6MISO-
D7MOSIMOSI
D8CSN-

Damit bliebe der Port D0 und der Analogeingang A0 des WEMOS frei für andere Zwecke.

Das Program für den WEMOS, als Empfänger sieht so aus:
C++:
/**********************************************************************
Programm für WEMOS D1  mini, zum Testen des gemeinsamen Betriebes eines
ILI9341 TFT display (240x320 pixel)zusammen mit einem NRF24l01 2,4GHz
Sendemoduls.
Angeschlossen ist:

NRF24 D1 - CE, D5 - SCK, D6 - MISO, D7 - MOSI, D8 - CSN
TFT  D2 - CS, D3 - RES, D4 - DC, D5 - CLK, D7 - MOSI

**********************************************************************/

// Vereinbarungsteil NRF24

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

//create an RF24 object
//RF24 radio(D4, D8);  // CE, CSN geht
// RF24 radio(D2, D8);  // CE, CSN geht
RF24 radio(D1, D8);  // CE, CSN geht

// Vereinbarungsteil Display
#include <Adafruit_GFX.h>       // include Adafruit graphics library
#include <Adafruit_ILI9341.h>   // include Adafruit ILI9341 TFT library
#define TFT_CS    D2     // TFT CS  pin is connected to NodeMCU pin D2
#define TFT_RST   D3     // TFT RST / RES pin is connected to NodeMCU pin D3
#define TFT_DC    D4     // TFT DC  pin is connected to NodeMCU pin D4
// initialize ILI9341 TFT library with hardware SPI module
//SCK (CLK) ---> NodeMCU pin D5 (GPIO14)
//MOSI(DIN) ---> NodeMCU pin D7 (GPIO13)
//BLK an 3,3V VCC

Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC, TFT_RST);

// NRF24 Variablen für die Datenkanaele
static const uint64_t pipe[6] = {0xF0F0F0F0C1LL, 0xF0F0F0F0D2LL, 0xF0F0F0F0C3LL, 0xF0F0F0F0B4LL, 0xF0F0F0F0A5LL, 0xF0F0F0F096LL};
byte ClientNummer = 1;    // Mögliche Werte: 1-6 Erstaz für Messstelle <<<<<<<<<<<<<<<<<<!!!!!!!!!!!!!!!!!!!!!!
// ANPASSEN              ^     auf den richtigen Wert der jeweiligen Messstelle
byte pipeNr = 0;

byte button_state = 0;        // Überprüfung des eingehenden Schaltsignals

void setup() {
  Serial.begin(9600);
  Serial.println("ILI9341 - NRF24l01 Test!");

// Setup Display
  tft.begin();
  tft.setRotation(1); // Anzeige um +90° drehen - Querformat
  tft.fillScreen(ILI9341_BLUE); // Bildschirm blau hinterlegen
  tft.setTextSize(2); // Schriftgröße einstellen 1 - 40 Zeichen pro Zeile, 2 - 20 Zeichen pro zeile, 3 - 13 zeichen pro Zeile
  // Schriftgroße 2 hat Hoehe x Breite = 14 x 10 Pixel
  // neue Zeile Texthöhe + 4 , Zeile zwei, Spalte 1 wäre ( 0, 18)
  // Zeile 2, 3, 4 ...  entspricht 18, 36, 54, 72, 90, 108 ...
  // tft.setTextColor(ILI9341_YELLOW); // Farbe nur der Schrift einstellen (Zeichenfarbe)
  tft.setTextColor(ILI9341_YELLOW, ILI9341_BLUE); // Farbe der Schrift einstellen (Zeichenfarbe, Hintergrundfarbe Zeichen)

// Setup für NRF24
  radio.begin();
  radio.setDataRate(RF24_250KBPS);// Übertragungsgeschwindigkeit setzen RF_1MBPS, RF_2MBPS
  radio.openReadingPipe(pipeNr, pipe[pipeNr]);   // Adresse1, auf dem die Empfangsdaten erwartet werden sollen
  radio.startListening(); // NRF24 auf Empfang schalten
  Serial.println("Lausche auf Signal");
  Serial.println(radio.isChipConnected());  // Prüfen, ob NRF24 angeschlossen ist
}


void loop(void) {

//Einlesen des Schalterzustandes vom Sender
  if (radio.available()) // Prüfen ob Datentelegramm empfangen wurde
  {
    radio.read(&button_state, sizeof(button_state));    //Einlesen des Schalterstatus vom Sender
    Serial.print("Schalter: "); Serial.println(button_state); // Ausgabe Schalterzustand auf seriellen Monitor
  }
  tft.setCursor(0, 0); // Cursor auf oben links setzen Spalte, Zeile in Pixel
  tft.print("Schalterstatus: "); tft.print(button_state); // Ausgabe Schalterzustand auf TFT Display
  delay(500);

}
Das Programm für den Nano ist das Gleiche in dem o.g. Thema WEMOS D1 mini mit NRF24l01

Ich füge das der Vollständigkeit halber aber bereinigt ein:

C++:
//Include Libraries
#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>

//create an RF24 object
RF24 radio(8, 9);  // CE, CSN

//address through which two modules communicate.
static const uint64_t pipe[6] = {0xF0F0F0F0C1LL, 0xF0F0F0F0D2LL, 0xF0F0F0F0C3LL, 0xF0F0F0F0B4LL, 0xF0F0F0F0A5LL, 0xF0F0F0F096LL};
byte ClientNummer = 1;    // Mögliche Werte: 1-6 Erstaz für Messstelle <<<<<<<<<<<<<<<<<<!!!!!!!!!!!!!!!!!!!!!!
// ANPASSEN         ^     auf den richtigen Wert der jeweiligen Messstelle
int button_pin = 7;               // Signalpin zum Einlesen des Schaltsignals (Taster, Bewegungsmelder etc.)
byte button_state = 0;
void setup()
{

// Daten senden
  Serial.begin(9600);
  pinMode(button_pin, INPUT);     // Port zum Einlesen des Schalterzustandes konfigurieren
  delay(500);

  radio.begin();
  radio.setDataRate(RF24_250KBPS);// Übertragungsgeschwindigkeit setzen RF_1MBPS, RF_2MBPS
  //set the address
  radio.openWritingPipe(pipe[ClientNummer-1]); // Setzen der Sendeadresse zur Übermittlung der Daten
  //Set module as transmitter
  radio.stopListening();

  Serial.println("Initialisiere die Datenübertragung");
  Serial.println(radio.isChipConnected());

}

void loop()
{
// Daten senden 
  button_state = digitalRead(button_pin); // Einlesen des Schalterzustandes
  Serial.println(button_state);           // Kontrollausgabe des Schalterzustandes am PC-Monitor

  Serial.println("Start");
  radio.write(&button_state, sizeof(button_state));  //Senden des Schalterstatus zum Empfänger
  bool ret =  radio.write(&button_state, sizeof(button_state));  //Senden des Schalterstatus zum Empfänger
  Serial.print("Sendeergebnis: ");
  Serial.println(ret);
  delay(500);
}
Fotos folgen asap
 
Zuletzt bearbeitet:

BAXL

Admin
Mitarbeiter
Leider hat die Datenübertragung mit dem NRF24l01 nicht komplett funktioniert, es werden unauswertbare Datentelegramme empfangen und ich habe noch nicht herausgefunden was die Fehlerursache ist, darum ist diese Aktivität vorübergehend auf Eis gelegt. Ich kann zwar den Schalterzustand empfangen, aber nicht die Temperaturen. Viele Versuche den Fehler einzugrenzen sind leider fehlgeschlagen. An der Hardware liegt es nicht. Ich könnte nur mutmaßen, dass die Spannungsversorgung zu schwach ist um die Leistungsaufnahme des NRF bei den Empfangsvorgang zu decken. Vorübergehend habe ich deshalb einen Fallback auf einen Nano gemacht und das Display über einen Pegelwandler angeschlossen. Da funktioniert die Kommunikation wieder fehlerfrei. Siehe Arduino Nano mit DollaTek 2,4" TFT SPI LCD-Farb-Modul ILI9341
 

Papa-Romeo

Mitglied
Hallo BAXL,

bin jetzt rein zufällig auf dieses Forum gestossen, da ich zum Modellbau irgendwie nicht mehr so richtig komme und meinen beiden Drohnen und die 3 Hubschrauber auf den Regalen verstauben.
Aber das ist Nebensache, jetzt zum Thema...
Ich habe mich auch schon eine geraume Zeit mit dem obigen Thema beschäftigt, da ich für meine Reinwasserfüllanlage so eine Art "Fernüberwachung" benötigte.
Da kam mir der ArduiTouch von AZ-Delivery gerade gelegen. Touch-Screen (Touch nutze ich allerdings hier nicht) und ein WEMOS verbaubar. Der NRF überträgt mir, von der im
Keller stehenden Füllanlage, Daten wie pH-Wert, Restfüllzeit, Welche Flaschen (0.7, 2 oder 5 Liter) auf den Füllplätzen stehen, welchen Zustand die Flaschen haben (leer, Füllstand, gefüllt, Befüllung abgebrochen oder vergessen den Deckel ab zu machen usw.), ins EG, damit nicht immer nachgeschaut werden muß, ob eine neue Flasche auf die Füllanlage gestellt werden muß.
Am Anfang hatte ich auch Probleme bei der Datenübertragung. Aber halbwegs nachvollziehbare. Der letzte Wert wurde nicht richtig übertragen und sprang für ein paar Sekunden immer wahllos um den Wert 128 hin und her. Warum das so ist oder war, weiß ich zwar immer noch nicht, aber ich konnte das Problem über den Sketch eliminieren, sodass jetzt eine saubere Datenübertragung von statten geht.

Bild 0.JPGBild 1.JPG


LG
Papa RomeoBild 0.JPGBild 1.JPG
 
Zuletzt von einem Moderator bearbeitet:

BAXL

Admin
Mitarbeiter
Hallo Papa-Romeo,

das hört sich interessant an, weil ich offensichtlich Probleme hatte und gerne Hilfe annehmen würde.
Könntest Du Dein Projekt vielleicht als eigenes Thema vorstellen, am liebsten auch mit Schaltplan und Sketch :), das wäre super:thumbsup:

Gruß
BAXL
 

Papa-Romeo

Mitglied
Hallo BAXL,

ok, dann muß ich mir die Sachen mal zusammensuchen. Die Bilder stammen ja vom Prototyp. Für den Einbau in das ArduiTouch hab ich mir eine Platine gemacht, auf der der NRF und der BME280 Platz finden und die GPIO´s vom Touch und dem WEMOS so zugeordnet werden, dass es funktioniert.
Den Sketch werd ich auch soweit kürzen, wie es für die Datenübertragung erforderlich ist. Ich denke damit wird der wesentlich übersichtlicher, da mit dem kompletten Sketch, wie ich ihn nutze, eigentlich niemand etwas anfangen kann, da er speziell für das "Ding" im Anhang geschrieben ist.

LG
Papa RomeoIMG_1488.JPG
 

Papa-Romeo

Mitglied
… sodale … fast ein Jahr vorbei (…schäm) … und jetzt endlich mal dazugekommen … aber das Projekt, das ich vorgestellt habe, für welches ich den Aufbau nutze passt irgendwie nicht in dieses Forum … aber ich habe inzwischen ein weiteres Projekt am Laufen, wo ich genau diese Hardware auch nutze.

Bei diesem Projekt geht es um Akkus, welche doch einen wesentlichen Bestandteil im Modellbau darstellen und hier vielleicht eher Interesse findet.
Hauptsächlich geht es bei diesem Projekt um die Vitalitäts- und Kapazitätsmessung von Akku´s. Für die Kapazitätsmessung gibt es dazu auf dem Markt zwar schon kleine,
kostengünstige Module, wie z.B. das ZB2L3. Diese haben aber folgenden Nachteil: lt. Datenblatt max. 3 A Belastung bei einer maximalen Akkuspannung von 15 Volt, wobei der verbaute SMD-Dual-FET den 3 A nicht Stand hält und sich schon bei längerer Belastung mit 2 bis 2.5 Ampere verabschiedet.

Bei meinen Recherchen bin ich aber auf ein weiteres kostengünstiges Modul gestoßen, das mit ein bisschen „Umbau“ auch für diesen Zweck genutzt werden kann. Dieses Modul nennt sich PZEM-003 oder PZEM-017 und schlägt mit so ca. 10 € zu buche. Einen Umbau mit einer „wireless“ Anbindung der Messdaten habe ich hier https://forum.fhem.de/index.php/topic,107480.msg1203286.html#msg1203286
beschrieben. Da es aber immer ein Sicherheitsrisiko birgt, WLAN-Daten „außer Haus“ zu tragen, habe ich den Umbau inzwischen um einen NRF24l01 erweitert.

Somit kann man die WLAN-Funktion des ESP12 deaktivieren und die Messdaten über diesen NRF an ein Anzeige-Gateway senden, welches aus einem AZ-Touch 2.8 Zoll, bestückt mit einem ESP12, einem NRF24l01 und einem BME680 (optional) besteht, wobei wir dann auch beim eigentlichen Thema des Threads wären.

WEMOS D1 mini mit TFT RGB Display und NRF24l01

Die Verbindung vom NRF und dem TFT-LCD mit dem ESP entspricht im Prinzip der von BAXL schon getesteten Verdrahtung. Ich habe lediglich den Touch und einen i2C-Bus integriert.

Wie von BAXL schon erwähnt gibt es bei der Übertragung der Daten Probleme. Diese haben sich bei mir in der Art geäußert, dass egal, ob ich nun 3,4,5 oder 20 Datensätze übertrage bzw. sende, immer der letzte empfangene Datensatz nicht dem entsprach, was auf der anderen Seite gesendet wurde. Nach langem versuchen und testen bin ich auf folgenden Lösungsweg gekommen, wie ich dieses Problem entgegnen kann. Ich erzeuge einfach einen „Dummy“, also einen Datensatz mit einem willkürlichen Inhalt. Dieser Datensatz wird aber auf der Empfangsseite nicht benötigt und auch nicht ausgewertet. Somit kann hier drin stehen was da will und stört die Übertragung nicht.

Ich hänge die Beispielsketche für den Transmitter und den Gateway mit an. Für den Transmitter gibt es zwei Sketche. Einmal mit und einmal ohne WiFi. Beim Gateway habe ich den Touch (Sketchanteil stammt von hier: https://www.hwhardsoft.de/deutsch/projekte/arduitouch-esp/) mal zum Testen so weit integriert, dass mit der PIN-Eingabe nur der Ausgabebildschirm freigeschaltet wird. Betätigt man den Touch im Ausgabemodus, kommt man wieder zurück zur PIN-Eingabe. PIN ist 1234. Eine Übertragung der Daten über MQTT ist vorbereitet wird aber noch nicht ausgeführt.

Für das Projekt habe ich mal vorerst zwei Anwendungsfälle im Sinn.
  • Akku-Kapazitätsmessung
Mittels des Schaltausganges wird über einen FET oder ein Relais dem Akku ein Entladewiderstand bis zum Erreichen der Ladeschlussspannung zugeschaltet und die entnommene Energie gemessen.
  • Akku-Vitalitätsmessung (Innenwiderstand)
Mittels des Schaltausganges wird der Akku für ca. 100 us mit einem sehr niedrigen Lastwiderstand (R ~ 0.05 – 0.1 Ohm) belastet. Während dieser Belastung wird der Strom und die Klemmenspannung gemessen und darüber der Innenwiderstand und der max. Kurzschlussstrom ermittelt.

Für den AZ-Touch habe ich schon eine Platine erstellt, um die PIN´s der Module entsprechend zuzuweisen. Funktioniert auch tadellos. Eine Platine für den ESP12 und den NRF im PZEM ist zwar entwickelt, aber noch nicht produziert. Im Moment läuft das noch über „Freiluftverdrahtung“. Die Sketche sind natürlich noch nicht fertig. Hier gibt es noch Potential für Erweiterungen, dass über den Touch z.B. die Ladeschlussspannungen oder ähnliche Vorgaben an den Transmitter übermittelt oder verschiedene Modi geschaltet werden können, da GPIO 01 und GPIO 16 auch noch Aufgaben übernehmen könnten.
Auch die Überwachung einer Autobatterie ist denkbar, mit z.B. einem fest verbauten modifizierten PZEM-Modul im Fahrzeug… usw. … usw.



LG
Papa RomeoWiFi-Manager_1.JPGWifi_Manager_2.JPGAdapterplatine_1.JPGTransmitter.JPGTouch.JPGGateway.JPGAdapterplatine_2.JPG
 

Anhänge

Zuletzt von einem Moderator bearbeitet:
Top Bottom