Das Konzept der Sendung war damals recht einzigartig: Die Zuschauer konnten den kleinen Troll in kurzen Spielchen mit den DTMF-Tastentönen ihrer Telefon von Zuhause steuern. Auf dem Bildschirm sahen sie dann das Ergebnis ihrer Tastendrücke. Heute durch die stark unterschiedlichen Laufwege und -zeiten moderner TV-Verbreitungswege undenkbar – und auch damals schon nicht immer ganz problemlos.

Egal, vier Jahre lief das Ganze. Und ich wollte gerne mitspielen, hatte aber nie das Glück durchzukommen. Das plagt mich bis heute, wie ich auch in meiner Podcast-Episode zu Hugo kundtat. In der Episode gehe ich noch ein bisschen genauer auf das Spiel, die Sendung und die Produktion ein.

Pad One, Please! Der nächste Retro-Podcast

#005: Hugo trollt TV und Games

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 / 14:03

Amazon Apple Podcasts Deezer RSS Spotify

RSS Feed

Teilen

Link

Embed

Nun gibt es aber ja seit einer ganzen Weile Arduino- und ESP-Boards, mit denen man famose Dinge erschaffen kann wenn man dem Thema etwas Zeit widmet. Und da ich hier noch ein altes Telefon der Deutschen Bundespost rumfliegen habe, was den Retro-Charackter der Aktion nur noch weiter verstärkt, habe ich mich dran gemacht aus dem Telefon ein viel zu großes Numpad zu bauen, mit dem auch gleich noch Hugo Spielen kann.

Teileliste

Viel braucht es für dieses Projekt nicht, nämlich nur den ESP und das Telefon:

• Retro-Telefon „FeTAp“, hier ein FeTAp 0111 aus 1987
• ESP 32 S3 Zero
• optional: DIY Platine um Kabelwirrwarr zu vermeiden (siehe „Schaltplan“)

Naja gut, und natürlich Schraubendreher, einen Lötkolben und was man zu dessen Verwendung halt so benötigt.

Schaltplan

Damit das Ganze funktionieren kann, muss das Tastenfeld mit dem ESP32 verbunden werden. An dem Tastenfeld des Telefons ist ein kurzes Flachband. Also, genau genommen ist es auf der Platine des Telefons und muss von der befreit werden. Danach müssen folgende Pins entsprechend mit dem ESP32 verbunden werden.

Um es für mich etwas angenehmer zu gestalten, habe ich mir eine kleine Platine dafür gebaut. Ich bin immer noch begeistert für welche schmale Mark man heutzutage selbstgestaltete PCBs produzieren lassen kann. Ich pack hier mal meine Lösung in Form einer Gerber-File hin, mit der eine Nachbestellung möglich ist – Verwendung auf eigene Gefahr:

Funktionsweise

Das kleine ESP-Board ist in der Lage, als HID (Human Interface Device) über USB zu agieren. Damit gibt es sich in diesem Fall sozusagen als Keyboard aus. Drücke ich eine der Tasten auf dem Telefon, so wird ein Tastendruck (Keyboard.press()) ausgelöst, für 80 Milisekunden gehalten und danach wird die Taste wieder „losgelassen“ (Keyboard.release()).

Um den richtigen Tastendruck zu ermitteln, wird das Tastenfall in schnellen Intervallen auf Tastendrücke abgefragt – so wie es das Telefon selbst zuvor auch gemacht hat. Das Tastenfeld ist dabei als eine Art Matrix aufgebaut. Man kann Spannung dabei Zeilen und Reihenweise anlegen. Gebe ich also beispielsweise eine Spannung auf Spalte 2 und Zeile 3, so muss bei Druck der Taste 8 eine Spannung anliegen sofern diese gerade gedrückt wird. So funktioniert im Groben die Erkennung welche Taste gerade gedrückt wird. Simpel aber doch irgendwie faszinierend, wenn ich mir vorstelle in welchem flotten Intervall der ESP da über alle möglichen Konstellationen immer und immer wieder drüber ballert.

Software

Die Software besteht im Wesentlichen aus einer einzigen Datei. Ich entwickle in PlattformIO, entsprechend handelt es sich bei dem Projekt um ein solches. Ihr könnt den Code aber auch in die Arduino IDE kopieren, dann müsste ihr nur dafür sorgen dass ihr die entsprechend für den ESP32 S3 Zero konfiguriert. Außerdem müsst ihr vermutlich das #include <Arduino.h> rausnehmen und dem Sketch eine .ino-Dateiendung geben. Mehr dazu auch in der Readme. Das Projekt könnt ihr auf meinem GIthub-Profil auschecken oder runterladen.

Fazit

Das Projekt hier hat mir wahnsinnig Spaß gemacht. Ich hab keine Ahnung, ob es da draussen wirklich noch andere Verrückte gibt, die sich an sowas erfreuen. Aber falls ja: Hey, schön das du da bist und viel Spaß mit dem Projekt. Wer keine Lust auf basteln hat: Ich habe kürzlich erfahren, dass im Hi-Score in Hannover auch etwas ähnliches für jeden zum ausprobieren und Spielen stehen soll. Diese Werbung hier ist absolut freiwillig und unbezahlt, ich finde in der Retro-Community muss man zusammenhalten und gute Ideen teilen.

Und wenn ihr das Projekt mal umgesetzt haben solltet: Ich würde mich super über Rückmeldung freuen. Viel Spaß beim Zocken!

+ relativ günstig
+ kompakt
+ überschaubarer Stromverbrauch
+ optional mit GPS und Bluetooth
+ USB-Anschluss für schnellere Datenübertragung

– min. 5 V Versorgungsspannung (SIM800L lief auch mit 3.7 V)
– Status LED ungenau (moniert nicht verbunden zu sein, obwohl Daten gesendet und empfangen werden)

Videoanleitung

Hardware

Für mein Test-Setup verwende ich ein ESP32-WROOM-32D-Board. Andere Boards sind möglich. Ich verwende dieses Board aufgrund der Hardware-Serial, über die die Kommunikation zwischen ESP und A7670E-LTE-Modem läuft. Die Beschriftung auf dem Modem ist ein bisschen unübersichtlich. Auf meinem Board von oben nach unten:
G: GND, R: RXD, T: TXT, K: PWRKEY, V: VCC, G: GND, S-SLEEP

Für mein Setup genügt es, vom ESP TX/RX über Kreuz zu verbinden: Also: TX vom ESP auf RX vom Modem und umgekehrt. Außerdem teilen sich ESP und A7670E einen Ground. Das wars dann aber auch. Ich hatte zwischenzeitlich einen 2200μF-Kondensator verbaut, bis ich gesehen habe das genau für diesen Zweck bereits ein 4700μF-Kondensator auf dem Modem verbaut ist. Trotzdem kackte das Modem beim Einbuchen ins LTE-Netz ab und an ab – die Stromversorgung scheint da aber wohl dann nicht der Grund gewesen zu sein?!

Software

Getestet wurde das hier mit dem A7670E-Modul. Allerdings sollten die meisten Sketches auch mit anderen Boards von SIMCom funktionieren, sofern sie den gleichen Befehlssatz unterstützen.

Basis Sketch

Um es auch für Einsteiger verständlich zu halten, teile ich die einzelnen Funktion in kleine Snippets auf. So könnt ihr euch das raussuchen, was für euer Szenario am besten passt. Diese basieren auf folgender Basis, die zunächst nichts weiter macht als die Kommunikation mit dem A7670E sicherzustellen und die Antworten des Moduls im Serial Monitor euer (Arduino-)IDE anzuzeigen.

#include <Arduino.h>

#define RX_PIN 17 // RX-Pin des ESP-Boards
#define TX_PIN 16 // TX-Pin des ESP-Boards
HardwareSerial modem(2);

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT"); // AT = Attention, Modem muss mit "OK" antworten
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp); // Jede Antwort des Modems in der Serial gekennzeichnet ausgeben
    }
  }
}

Serial connection ready
Modem: AT
Modem: OK

Mobilfunkstatus Sketch

Um zu prüfen, ob das A7670E-Modul mit dem Mobilfunknetz verbunden ist, können wir es einfach selbst fragen.

#include <Arduino.h>

#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }

  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) { // Nach 2 Sekunden alle 20 Sekunden aktualisieren
    lastRun = millis();

    modem.println("AT+CSQ");      // Signalstärke
    modem.println("AT+CEREG?");   // LTE Netzregistrierung
    modem.println("AT+CGATT?");   // Datenregistrierung
    modem.println("AT+CGACT?");   // PDP Kontext aktiv? (Datenverbindung)
    modem.println("AT+CGPADDR");  // IP-Adresse
    modem.println("AT+NETOPEN?"); // Socket-Service Status
  }
}

Modem: AT+CSQ
Modem: +CSQ: 26,99
Modem: OK
Modem: AT+CEREG?
Modem: +CEREG: 0,1
Modem: OK
Modem: AT+CGATT?
Modem: +CGATT: 1
Modem: OK
Modem: AT+CGACT?
Modem: +CGACT: 1,1
Modem: +CGACT: 8,1
Modem: OK
Modem: AT+CGPADDR
Modem: +CGPADDR: 1,10.76.56.42
Modem: +CGPADDR: 8,0.0.0.0,254.128.0.0.0.0.0.0.194.209.178.131.245.194.29.154
Modem: OK
Modem: AT+NETOPEN?
Modem: +NETOPEN: 0
Modem: OK

+CSQ: 26,99: 26 ist die Signalqualität, Skala 0-31, 26 = ziemlich guter Empfang
+CEREG: 0,1: Erfolgreich im LTE-Netz eingebucht
+CGATT: 1: Datenverbindung aktiv
+CGACT: 1,1 & +CGACT: 8,1: Zwei Datenkontexte offen
+CGPADDR: 1,10.76.56.42
+CGPADDR: 8,0.0.0.0,254.128.0.0.0.0.0.0.194.209.178.131.245.194.29.154: IP-Adressen, die das Board erhalten hat

Ping Sketch

Ein grundlegender Test von Netzwerk-Kommunikation ist ein „ping“: Ein kleines Datenpaket wird an einen Server gesendet. Kommt das Paket an antwortet der Server und der Nutzer sieht, wie lange das Datenpaket auf Reise war.

#include <Arduino.h>

#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }

  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) {
    lastRun = millis();

    modem.println("AT+CPING=\"8.8.8.8\",1,4"); // 4 Pings an Google DNS senden
  }
}

Modem: AT+CPING="8.8.8.8",1,4
Modem: OK
Modem: +CPING: 1,8.8.8.8,92,130,114
Modem: +CPING: 1,8.8.8.8,92,40,114
Modem: +CPING: 1,8.8.8.8,92,15,114
Modem: +CPING: 1,8.8.8.8,92,30,114
Modem: +CPING: 3,4,4,0,15,130,40

AT+CPING=“8.8.8.8″,1,4: 8.8.8.8 ist die Ziel-IP-Adresse, 1 steht für IPv4 (2 wäre IPv6), 4 ist die Anzahl der Wiederholungen
+CPING: 1,8.8.8.8,92,130,114: 1: Ping erfolgreich, der vorletzte Wert (hier 130) ist die Laufzeit in ms, die anderen Werte bitte dem Manual entnehmen
+CPING: 3,4,4,0,15,130,40: Zusammenfassung über die 4 Pings

Daten via HTTP abrufen (HTTP GET-Request)

#include <Arduino.h>

#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }

  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) {
    lastRun = millis();

    modem.println("AT+HTTPINIT"); // HTTP-Service des Modems starten

    
    modem.println("AT+HTTPPARA=\"URL\",http://httpbin.org/get"); // Abzurufende Adresse
    modem.println("AT+HTTPACTION=0"); // 0 = GET, 1 = POST, 2 = HEAD, 3 = DELETE, 4 = PUT

    delay(2500); // Wir gehen davon aus, in 2.5s die Antwort zu erhalten. Vermutlich besser: AT+HTTPACTION auswerten, liefert die Content-Length

    modem.println("AT+HTTPHEAD"); // Ausgabe des Response Headers

    delay(200);

    modem.println("AT+HTTPREAD=99999"); // "Unsaubere Implementierung": Eigentlich AT+HTTPREAD? nutzen um Länge der Antwort zu ermitteln
    modem.println("AT+HTTPTERM"); // HTTP-Service nach Verwendung stoppen
  }
}

Modem: AT+HTTPINIT
Modem: ERROR
Modem: AT+HTTPPARA="URL",http://httpbin.org/get
Modem: OK
Modem: AT+HTTPACTION=0
Modem: OK
Modem: +HTTPACTION: 0,200,255
Modem: AT+HTTPHEAD
Modem: +HTTPHEAD: 226
Modem: HTTP/1.1 200 OK
Modem: Date: Fri, 05 Sep 2025 15:28:01 GMT
Modem: Content-Type: application/json
Modem: Content-Length: 255
Modem: Connection: keep-alive
Modem: Server: gunicorn/19.9.0
Modem: Access-Control-Allow-Origin: *
Modem: Access-Control-Allow-Credentials: true
Modem: OK
Modem: AT+HTTPREAD?
Modem: +HTTPREAD: LEN,255
Modem: OK
Modem: AT+HTTPREAD=99999
Modem: OK
Modem: AT+HTTPTERM
Modem: OK
Modem: +HTTPREAD: 255
Modem: {
Modem: "args": {},
Modem: "headers": {
Modem: "Accept": "*/*",
Modem: "C "origin": "80.187.118.156",
Modem: "url": "http://httpbin.org/get"
Modem: }
Modem: +HTTPREAD: 0

+HTTPACTION: 0,200,255: 0 = Type der Anfrage (GET), 200 = Statuscode des Servers, 255 = Länge der Antwort in Bytes
+HTTPHEAD: 226: Start Ausgabe des Headers, 226 Bytes
+HTTPREAD: LEN,255: Eine Response liegt vor, 255 Bytes
+HTTPREAD: 255: Beginn der Ausgabe des Response bis HTTPREAD: 0

Daten via HTTP senden (HTTP POST, PUT, PATCH)

Im vorangegangenen Beispiel beim Abruf der Daten via HTTP haben wir etwas „gefuttelt“ was die Antworten anging. So haben wir mit delay gearbeitet und gehofft, dass bis dahin eine Antwort da ist. Damit kommen wir jetzt nicht mehr durch. Um den Code weiter lesbar zu halten, habe ich die Logik in einzelne Funktionen aufgeteilt.

#include <Arduino.h>

#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);

String waitForURC(const char* token, unsigned long timeoutMs = 10000) { // URC: Unsolicited Result Code, Ereignisbasierte Melungen des Modems abfragen. In unserem Fall für die Antwort nach dem POST genutzt
  unsigned long start = millis();
  String buffer;

  while (millis() - start < timeoutMs) {
    while (modem.available()) {
      String line = modem.readStringUntil('\n');
      line.trim();

      if (line.length() > 0) {
        Serial.println("URC: " + line);
      }

      if (line.startsWith(token)) {
        return line;
      }
    }
  }
  Serial.println("Timeout beim Warten auf URC: " + String(token));
  return "";
}

void readHttpResponse() {
  modem.println("AT+HTTPREAD=99999"); // Wir lesen pauschal alles; Hier könnte man auch mit der genauen Zahl an Bytes arbeiten (was sauberer wäre), aber das LTE-Modul liefert nur solange Daten zurück, wie sie vorliegen.
  
  String response;
  unsigned long startTime = millis();

  while (millis() - startTime < 15000) {
    while (modem.available()) {
      String line = modem.readStringUntil('\n');
      line.trim();

      if (line.startsWith("+HTTPREAD:")) continue;
      if (line == "OK") {
        Serial.println("HTTP-Body:");
        Serial.println(response);
        return;
      }

      response += line + "\n";
    }
  }
  Serial.println("Timeout beim Lesen der Response!");
}

void httpPost(const char* url, const char* json) { // Methode speziell für den HTTP POST-Prozess
  modem.println("AT+HTTPINIT");
  modem.printf("AT+HTTPPARA=\"URL\",\"%s\"\r\n", url);
  modem.println("AT+HTTPPARA=\"CONTENT\",\"application/json\""); // Festsetzen des Inhalts auf JSON
  modem.printf("AT+HTTPDATA=%d,5000\r\n", strlen(json)); // Dem Modem mitteilen, dass gleich Daten kommen, die es für die Übermittlung aufzeichnen soll

  String dl = waitForURC("DOWNLOAD", 5000); // Warten bis das Modem mit "DOWNLOAD" antwortet, dann senden unseres JSON
  if (dl.length() > 0) {
    modem.print(json);
    if (waitForURC("OK", 5000).length() == 0) { // Im Anschluss auf die Bestätigung der Übertragung durch das Modem warten
      Serial.println("Modem or connection stuck, too many data sent or check wiring");
      return;
    }
  }

  modem.println("AT+HTTPACTION=1"); // 1 = POST
  String action = waitForURC("+HTTPACTION:", 15000); // Hier optimierter Ablauf: Sobald die Anfrage vom Modem versendet wurde, geht's weiter...

  if (action.length() > 0) {
    int method, status, len;
    if (sscanf(action.c_str(), "+HTTPACTION: %d,%d,%d", &method, &status, &len) == 3) {
      Serial.printf("HTTP Status: %d, Length: %d\n", status, len);

      if (status == 200 || status == 201) { // Status code 200/201 stehen für eine erfolgreiche Anfragen bei POST
        readHttpResponse(); // Auslesen der Antwort in einer eigenen Funktion dafür
      } else {
        Serial.println("Unexpected response");
      }
    }
  }

  modem.println("AT+HTTPTERM");
}

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }

  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) {
    lastRun = millis();
    const char* json = "{\"temperature\":25.3,\"battery_level\":\"83\"}"; // Unsere Daten verpackt in JSON

    httpPost("http://httpbin.org/post", json); // Start des HTTP Post
  }
}

Serial connection ready
Modem: AT
Modem: OK
URC: AT+HTTPINIT
URC: OK
URC: AT+HTTPPARA="URL","http://httpbin.org/post"
URC: OK
URC: AT+HTTPPARA="CONTENT","application/json"
URC: OK
URC: AT+HTTPDATA=41,5000
URC: DOWNLOAD
URC: OK
URC: AT+HTTPACTION=1
URC: OK
URC: +HTTPACTION: 1,200,488
HTTP Status: 200, Length: 488
HTTP-Body:
AT+HTTPREAD=99999

Modem: +HTTPREAD: 488
Modem: {
Modem: "args": {},
Modem: "data": "{\"temperature\":25.3,\"battery_level\":\"83\"}",
Modem: "files": {},
Modem: "form": {},
Modem: "headers": {
Modem: "Accept": "*/*",
Modem: "Cache-Control": "no-cache",
Modem: "Content-Length": "41",
Modem: "Content-Type": "application/json",
Modem: "Host": "httpbin.org",
Modem: "X-Amzn-Trace-Id": "Root=1-68bd430d",
Modem: "url": "http://httpbin.org/post"
Modem: }
Modem: AT+HTTPTERM
Modem: OK
Modem: +HTTPREAD: 0

Dadurch das mit waitForURC auf ein Ereignis warten, verschieben sich hier die Ausgaben ein wenig.
AT+HTTPDATA=41,5000: Unsere zu sendenden Daten sind 41 Bytes lang, Timeout: 5 Sekunden
+HTTPACTION: 1,200,488: Die Übertragung war erfolgreich, 488 Bytes lang ist die Antwort
AT+HTTPREAD=99999: Wir lesen pauschal 99999 Bytes, das Modem liefert aber nur so viel Daten zurück wie vorhanden; Wir hätten hier auch die 488 aus der HTTPACTION-Antwort verwenden können. Das wäre sauberer gewesen, aber in manchen Fällen (bspw. „chunked“-Responses) liegt wieder Wert nicht vor. Wir haben es uns also einfacher gemacht
+HTTPREAD: 488: Beginn der Ausgabe der Antwort des Servers, enthält als Bestätigung unter „data“ das, was wir geposted haben

Besonderheiten bei HTTPS

Das 7670E-Modul ist dazu in der Lage Daten unverschlüsselt über HTTP, als auch verschlüsselt via HTTPS zu übertragen. Im besten Fall ist dazu nicht viel mehr nötig, als in den hier genannten Beispielen auf „http://“ ein „https://“ zu machen. Allerdings steckt der Teufel da gerne im Detail, denn HTTPS ≠ HTTPS.

Hier ein Mini-Exkurs: Werden im Netz Daten verschlüsselt übertragen, kommen dazu unterschiedliche Mechanismen zu tragen. So wird zum einen ein Verschlüsselungsalgorithmus zwischen Client und Server ausgehandelt., heutzutage oft TLS 1.2 oder größer. Neben diesem wird ein passendes Zertifikat benötigt. Gerade wenn es günstig sein soll, wird heute oft Lets Encrypt verwendet – mach ich auch so. Damit die Kommunikation aber wirklich sicher ist, müssen Betriebssysteme, Browser oder eben LTE-Module mit HTTPS-Support aber die Stammzertifikate der Anbieter kennen. Ein weiteres Thema ist Server Name Indication (SNI) in Verbindung mit virtuellen Hosts. Kurz um: Viele Dinge, die entweder eine vermeintlich sichere Verbindung unsicher machen können oder sie erst gar nicht zustand kommen lassen.

Wenn die Übertragung nicht gelingt…

…geht’s an Debugging. Folgende Sachen könnt ihr prüfen:

SNI aktivieren
Das Modul hat zur Laufzeit 8 SSL-Konfiguration im Speicher. Per Default ist da wenig konfiguriert, außer die Art der TLS-Verschlüsselung mit der Gegenseite automatisch ausgehandelt werden soll. Was dabei nicht konfiguriert wird ist Server Name Indication. Das kann aber essentiell sein, nämlich dann, wenn euer Server mit Virtual Hosts arbeitet. Aktiviert SNI vor dem AT+HTTPINIT mit:

modem.println("AT+CSSLCFG=\"enableSNI\",0,1")

SNI wird für den SSL-Kontext „0“ mit „1“ aktiviert. SSL-Kontext 0 ist der erste der genannten 8 möglichen und wird per default verwendet. Um die SSL-Kontext-ID anzupassen, kann man den Befehl AT+HTTPPARA=“SSLCFG“,2 nutzen, wobei hier die 2 symbolisch für die ID des Index steht, also 0-7.

HTTPACTION auswerten
Einen GET-Request starten wir ja mit AT+HTTPACTION=0. Das Modul gibt neben einem „OK“ auch weitere Informationen aus, im besten Fall sowas: +HTTPACTION: 0,200,81
Die 0 steht für die Art der Anfrage (GET), die 200 für den vom Server gesendeten Statuscode und 81 ist die Länge der Antwort. Ist die Antwort nicht erfolgreich, ist interessant was dort statt 200 steht. Eine 706 würden auf Probleme beim Lesen der Antwort hindeuten, aber gleichzeitig bekräftigen, dass der TLS-Handshake zuvor erfolgreich war, während eine 715 eben genau auf Probleme bei ebendiesem hinweisen würden. In dem Fall müsste man prüfen, ob der verwendete TLS-Standard auf deinem Server von dem LTE-Modul überhaupt unterstützt wird.

HTTP-Header auslesen
Mit AT+HTTPHEAD lässt sich nach dem Absenden der Anfrage der Antwort-Header auslesen. Hier können auch Hinweise auf das Problem aufgeführt sein, wenn man Glück hat. Das oben angesprochene SNI-Problem könnte beispielsweise hier benannt werden.

HTTPS GET Beispiel Sketch

Die oben genannte Punkte sind in diesem Beispiel berücksichtig, welcher bei mir erfolgreich funktionierte.

#include <Arduino.h>
 
#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);


String waitForURC(const char* token, unsigned long timeoutMs = 10000) {
  unsigned long start = millis();
  String buffer;
 
  while (millis() - start < timeoutMs) {
    while (modem.available()) {
      String line = modem.readStringUntil('\n');
      line.trim();
 
      if (line.length() > 0) {
        Serial.println("URC: " + line);
      }
 
      if (line.startsWith(token)) {
        return line;
      }
    }
  }
  Serial.println("Timeout beim Warten auf URC: " + String(token));
  return "";
}


void setup() {
  Serial.begin(115200);
 
  delay(1000);
  Serial.println("Serial connection ready");
 
  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");

  
}
 
void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }
 
  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) {
    lastRun = millis();
 
    modem.println("AT+CSSLCFG=\"enableSNI\",0,1"); // SNI für SSL config ID 0 aktivieren
    
    modem.println("AT+HTTPINIT");
    
    modem.println("AT+HTTPPARA=\"URL\",https://phil.cossnet.de/lte_modul_test.html"); // Kleine selbstgehostete Test-HTML-Datei
    modem.println("AT+HTTPACTION=0");
 

    String response = waitForURC("+HTTPACTION", 5000); // Auf Antwort warten, offenbar dauert es bei HTTPS länger als bei HTTP
    if (response.length() > 0) {
      modem.println("AT+HTTPHEAD");
      modem.println("AT+HTTPREAD=99999");
    }
 
    delay(200);
    modem.println("AT+HTTPTERM");
  }
}

Heute widme ich sozusagen der kleinen Version dieser Matrix: In meinem Gaming Room ist es bisher noch ein bisschen trist. Gerade im Kontext „Gaming“ darf für meinen Geschmack ein bisschen Farbe nicht fehlen. Deshalb habe ich für ein 8x8er WS2812B RGB-Modul, so wie sie bereits in der 16x16er-Matrix zu viert im Einsatz sind, entschieden und ein passendes Gehäuse drumrum gebaut.

Um zu schauen, welches PLA am besten passt, habe ich vier unterschiedliche Oberseiten gedruckt: schwarz, weiß, grau und transparent. Spoiler: Am Ende ist es für meinen Verwendungszweck den Raum generell etwas bunter zu illuminieren das transparente Cover geworden. Aber auch weiß und grau sehen gut aus, bei schwarz kommt wenig überraschend wenig Licht durch. Zumindest solang man die Lichtintensität nicht deutlich höher dreht, womit wir bei einem wichtigen Punkt sind:

Schaltung

Wichtiger Hinweis: Im Video sag ich es, hier sage ich es auch nochmal. Wenn ihr das Projekt nachbaut: Ich bin Hobby-Schrauber, kein Experte. Wenn euch Komponenten kaputtgehen, die Schaltung nicht optimal sein sollte oder ähnliches: Ihr seid schon groß, könnt selbst abwägen was ihr da macht. Besonders drauf hingewiesen sei, dass durch die Bauart des Gehäuses die Abwärme der LEDs nur schlecht abgeführt werden kann. Ergibt sich aus der gewünschten Form und der angestrebten Kompaktheit. Im Video zeige ich es: Lasst ihr die LEDs bei voller Intensität in weiß länger laufen, komme ich selbst bei offenem Gehäuse auf 55-60 °C. An der Stelle würde das PLA vermutlich zu einem Klumpen verschmelzen. Das Ganze ist also dafür ausgelegt, irgendwo mit mittlerer Intensität betrieben zu werden. So, genug dazu, auf ins Projekt.

Im Video gehe ich einmal über den Aufbau und den Anschluss der Komponenten. Kurz zusammengefasst: Der Strom kommt vom Micro-USB-Board und geht auf den 5V bzw. Ground des ESP8266-Boards. Zusätzlich geht’s direkt weiter auf die LED-Matrix. Somit läuft der Strom nicht über das ESP-Board, was zu dessen Langlebigkeit beisteuern sollte. Sauberer wäre es vermutlich, wenn man zwischen ESP-Board und Stromquelle noch eine Sperrdiode setzt. Da ich die Schaltung möglichst Anfängerfreundlich halten wollte, habe ich darauf verzichtet. Ich weiße aber darauf hin, dass man die WLED-Software am besten vor dem Zusammenbau installiert und nachdem alles verkabelt ist, keinen Strom mehr via USB-Kabel auf den ESP gibt. Zur Verdeutlichung hier nochmal ein Schaltplan:

Das WS2812-Modul kommt mit den 3.3V Pegel des ESP-Boards klar. Man benötigt also keinen Levelshifter, ist da sehr tolerant.

3D Druck

Das Ganze braucht natürlich noch ein Zuhause. Dafür habe ich ein einfaches Gehäuse gebastelt, welches die Komponenten umschließt. Wie bereits erläutert werden die LEDs warm und je nach Material kommt mal mehr, mal weniger Licht durch. Ich empfehle helle bis transparente Farben für die Oberseite. Solltet ihr es etwas lichtintensiver benötigen, kann PETG statt PLA eine Alternative sein, um Verformungen zu vermeiden. Hier der Download der Komponenten für euren 3D-Drucker:

Teileliste

Um das Projekt möglich einfach zu halten, habe ich mich auf die nötigsten Komponenten beschränkt. Neben den genannten braucht es natürlich Litze (nicht zu dünn, um den Querschnitt für euer Projekt zu berechnen könnt ihr sonst gerne auf den WLED Rechner zurückgreifen). Naja, und ein Lötkolben samt Zubehör sollten bereitstehen.

• D1 Mini-Board (z.B. hier, hier oder bei eBay)
• WS2812B 8×8 LED Matrix (z.B. hier)
• Micro-USB-Board (z.B. hier)

Hinweis: Mein Blog hier ist privat, es handelt sich NICHT um Affiliate-Links. Ihr könnt natürlich überall anders bestellen. Ich benenne die Komponenten explizit bei diesen Anbietern, da es manchmal kleine Unterschiede gibt was die Dimensionen der Bauteile angeht. Es ist aber wichtig, die passenden Komponenten zu verwenden, wenn man die 3D-Druck-Vorlagen verwenden möchte. Ich habe mir mit kleinen Margins gearbeitet, damit das Gehäuse möglichst kompakt bleibt.

Fazit

Ich bin mit dem Ergebnis sehr zufrieden, mein Gaming Room ist nun etwas farbenfroher. Mal schauen, welche Animation es am Ende wird, aber da bietet WLED ja einiges zur Auswahl. Aufgrund der wenigen Komponenten könnte das Projekt auch durchaus was für Einsteiger sein. Die Kosten halten sich am Ende mit etwa 15,- Euro auch durchaus im Rahmen. Und wenn man keinen 3D Drucker hat, so kann man sich vielleicht anders behelfen: Wie wäre es mit einem Rahmen aus schönen Holzkomponenten? Leicht lasiert? Jetzt wo ich so drüber nachdenke, vielleicht ist das ja was für ein kommendes Projekt.

Viel Spaß beim Basteln und experimentieren!

Wer sich mit dem Erstellen von Videos beispielsweise für Social Media auseinandersetzt, der oder die merkt schnell, dass man für schöne Aufnahmen manchmal etwas Zubehör benötigt. Sei es das passende Licht, die doch etwas teurere Kamera oder ein externes Mikrofon. Ähnlich ist es, wenn man gleichmäßige Kamerafahrten machen möchte. Da gibt es zum Beispiel Gimbal, die unrunde Bewegungen ausgleichen können. Um meine Projekte in Szene zu setzen, benötigte ich in der Vergangenheit aber häufig eher langsame und gleichmäßige Fahrten von links nach rechts oder vice versa.

Somit war die Idee für einen Kamera Slider geboren. Zugegeben: Sonderlich kreativ ist das nicht, gibt es im Netz doch bereits einige solcher Projekte. Aber da ich etwas auf dem Weg lernen wollte und die anderen Projekte alle eine gewisse Komplexität mit sich bringen, habe ich bei 0 angefangen. Eine Erkenntnis vorab: Viel weniger Komplex ist mein Projekt leider auch nicht geworden. Deshalb, solltest du den Slider nachbauen wollen, bedenke folgendes:

Das bekommst du:

• Alle 3D-Dateien, um den gezeigten Slider nachzubauen
• Infos zu allen von mir verwendeten Teilen
• Einen Schaltplan, wie alles zu verkabeln ist
• Zahlreiche Bilder in dem Beitrag hier, die zeigen wie ich alles zusammengesetzt habe
• Mit etwas Ehrgeiz am Ende einen Slider, der insbesondere bei langsamen Fahrten schöne und ruckelfreie Videos ermöglicht

Aber das solltest du mitbringen:

• Einen 3D-Drucker und Filament
• Etwas Elektronikerfahrung, damit verbunden Lötkolben und was man halt so braucht
• Und vermutlich muss man hier und da ein bisschen mitdenken und: Ich bin Hobbybastler, da ist also vermutlich hier und da Optimierungspotential

Wenn das passt: Viel Erfolg! Wenn nicht: Vielleicht kannst Du dir aus den Infos ja dennoch ein paar Informationen für dein eigenes Projekt rausziehen. Vielleicht willst Du ja auch etwas ganz anderes bauen.

Teileliste

Für den Druck habe ich beliebiges PLA-Filament verwendet. Nehmt einfach das, mit dem ihr am besten klarkommt. In meinem Fall hatte ich da keine besonderen Anforderungen dran.

Elektronikkomponenten

• ESP32 Wroom 32D
• ST7735 1.77″ TFT-Display
• KY-040 Rotary Encoder
• Nema 17 Schrittmotor
• TMC2208 V1.2 Schrittmotor-Treiber
• 4.7k Widerstände
• 100 μF Kondensator
• Sperrdiode (optional aber empfohlen, siehe Hinweistexte bei „Die Schaltung„)
• 2 Mikroschalter (Endschalter mit Rollenhebel)
• Buck-Konverter um 12V auf 5V zu bekommen
• Custom-PCB (siehe ebenfalls Abschnitt „Die Schaltung„)

Weitere Teile

• M3 & M5-Schrauben unterschiedlicher Länge
• M3 & M5 Muttern, selbstsichernd
• Magentkonnektoren (siehe mein Tiktok dazu)
• 1/4″ Zoll Kamera Befestigungsschraube
• 1/4″ Zoll Mutter für Stativbefestigung
• 3D-Druckerrollen mit Kugellager
• 3D Drucker Zahnriemen Satz
• Riemenscheibe mit 20 Zähne
• Nutensteine M5
• Diverse Litze

Die 3D-Teile

Alle Teile sind von mir selbst erstellt – bis auf den Aufsatz für den den Rotary Encoder KY-040. Da hab ich ehrlicherweise bei Thingyverse nach dem Erstbesten gesucht. Die Teile sind in einigen Fällen ohne, teilweise mit Supports zu drucken. Ich habe in der Regel ein Infill von 60% verwendet. Ich denke es geht auch weniger.

Ihr findet sämtliche der folgenden 3D-Designs in dieser ZIP-Datei zum Download:

Baseplate

Das ist der der Schlitten, auf dem dann ein Mobiltelefon (in passender Halterung) monitiert werden kann.

Hülse

Hiervon braucht es 4 Stück. Sie dienen als Abstandshalter zwischen Baseplate und den Rollen. Die Schrauben werden durchgeführt, die Rollen von unten aufgeschoben und dann wird alles mit einer selbstsichernden Mutter festgezogen.

Schraube

Diese übergroße Schraube dient dazu, den Riemenspanner auf Spannung zu halten.

Stepper Holder

Wird ans eine Ende des Steppers gebaut und mit 2 Schrauben festgezurrt. Wenn das Aluprofil kein Gewinde hat, muss dieses erst noch geschnitten werden. Auf der einen Seite kann dann der Nema 17 befestigt werden, auf der anderen Seite sind 2 Löcher um einen der Mikroschalter zu befestigen.

Spanner Holder

Das Gegenstück zur Seite mit dem Motor: Hier wird die Schraube und der Spanner eingesetzt, sowie der Pulley. Außerdem befinden sich erneut 2 Löcher an der Seite zur Befestigung des 2. Mikroschalters.

Pulley

Die Rolle über die der Riemen auf der Seite mit dem Spanner geführt wird.

Stativ Mount

Hiermit kann das Aluprofil zusammen mit 4 Nutsteinen und den passenden Schrauben auf einem normalen Stativ befestigt werden. Dazu wird noch eine 1/4″ Mutter benötigt, die einfach mittig in das 3D-Teil eingelegt wird.

Spanner

Dient als Halterung um den Riemen auf Spannung zu halten: Am einen Ende wird die Schraube eingeführt, durch die die Spannung aufgebaut werden kann. Die beiden Arme halten den Pulley, der mit einer Schraube und selbstsichernder Mutter festgehalten wird.

Bottom Case

Da der Motor 12V Spannung benötigt verwende ich ein 12V-Netzzeil. Ein Buck-Konverter macht daraus 5V für das ESP32-Board. Um Platz zu sparen, habe ich mich für diese Plugin-Lösung entschieden. Der Buck-Konverter wird hier eingelegt und dann unter das Control Unit-Case geklippt.

Control Unit Case

Das Gehäuse bietet ein sicheres Zuhause für das Custom PCB. Außerdem kann es von unten mit 4 Nutsteinen samt schrauben von unten am Aluprofil befestigt werden. Oben befindet sich eine Öffnung um die Kabel raus- bzw. reinzuführen. Auf der Hinterseite befinden sich Öffnungen für 2 Magentkontakte, über die die Mikroschalter angeschlossen werden.

Plug lower

Um den Magnetschaltern ein Zuhause zu geben, habe ich dieses Gehäuse entworfen: Unterseite

Plug upper

Um den Magnetschaltern ein Zuhause zu geben, habe ich dieses Gehäuse entworfen: Oberseite

Cover

Die Abdeckung für die Steuereinheit. Hat Aussparungen für Display, Rotary Encoder, Kühlkörper und Motoransteuerung.

Die Schaltung

Im Video hab ich es erwähnt: Ich bin immer wieder fasziniert davon, wie günstig man heute qualitativ hochwertige, selbst erstellte PCBs bestellen kann. Wenn ihr selbiges tun möchtet, biete ich euch hier gerne das Gerber-File ein, mit dem ich beim Hersteller eurer Wahl bestellen könnt. Für alle, die lieber selbst die einzelnen Komponenten verlöten möchten (so viele sind es ja am Ende nicht) haue ich hier aber auch einen Schaltplan rein.

Beachtet: Wenn ihr die Schaltung nachbaut, macht ihr das auf eigene Gefahr!
Lest bitte auch folgende Hinweise!

Hinweis: Anders als im Schaltplan angegeben, habe ich noch eine Sperrdiode zwischen die 5V (im Schaltplan U10) und den daran angeschlossenen Buck-Converter gesetzt um sicher zu sein, dass die 5V auch nur in Richtung des ESP32-Boards fließen. Ohne die kann es sein, dass der Strom über das ESP32-Board zurück in Richtung Stepper-Treiber fließt und das Board oder die dahinter befindliche Stromquelle überlastet!

Hinweis 2: Das ganze ist ein Hobby für mich, ich hab den Kram nicht gelernt. An der Schaltung kann mit Sicherheit einiges optimiert werden. Ich kann nicht garantieren, dass das alles sicher umgesetzt ist. Ich bin für konstruktives Feedback offen und erinnere: Wenn ihr das nachbaut, macht ihr das auf eigene Gefahr!

Die Software

Bei dem Projekt handelt es sich um ein Arduino-Projekt welches mit PlatformIO entwickelt wurde. Entsprechend sind die verwendeten Bibliotheken in der Konfiguration des Projekts enthalten. Ihr könnt euch das Projekt von meinem Github-Account ziehen, lokal mit PlatformIO bauen und auf das ESP32-Board flashen. Ein fertiger Build, wie ich das bei anderen Projekten teils anbiete, existiert hier leider bisher nicht.

Bilder: Im Detail

Bilder sagen oft mehr als tausend Worte. Insbesondere wenn man ein etwas umfangreicheres Projekt wie dieses vor der Brust hat und keine Step-by-Step-Anleitung geliefert bekommt. Deshalb habe ich den Slider an allen Ecken einmal im Detail abfotografiert.

Fazit

Ihr merkt, das Ganze ist kein 08/15-Projekt welches man mal eben schnell nachbaut. Ihr benötigt so einiges an Komponenten, einen 3D-Drucker und etwas Geduld und Hirnschmalz beim Zusammenbauen. Um ehrlich zu sein: Ich war mir anfangs unsicher, ob ich überhaupt ein Video oder diesen Blogbeitrag zu dem Kamera Slider schreiben will. Habe mich dann aber doch dafür entschieden. Denn vielleicht kann sich der Eine oder die Andere bei der Verwirklichung des eigenen Projekts irgendwas abschauen. Und dann wär es doch bereits ein Erfolg. In dem Sinne, danke für’s Lesen, viel Spaß und vielleicht sieht und ließt man sich ja mal auf meinem YouTube-Kanal.

Getauft auf den Namen „EchoTrack“ prüft dieses kleine und bunte Gadget kontinuierlich eure Internetverbindung, in dem es einen von euch definierten Host vier Mal pingt und euch danach den errechneten Mittelwert daraus anzeigt. Neben dem Host der angepingt werden soll könnt ihr zudem 2 Warnstufen definieren. Werden diese überschritten, so blinkt das Tool hektisch in orange oder rot um euch sofort zu informieren, dass der aktuelle Hinterhalt in Fortnite, Tarkov, Quake 3 Arena oder was ihr auch immer gerade zockt vielleicht nach hinten losgehen könnte – und es dann nicht (nur) am Skill gelegen hat.

Schaltplan

Um die Verkabelung ein bisschen transparenter zu machen, habe ich folgendes Schema für euch zusammengebastelt. Doc Brown würde sagen „mir fehlte die Zeit, es ist nicht ganz Maßstabsgetreu“: Statt einer 4-Digit-Anzeige verwendet natürlich wie im Video eine 6-Digit-Anzeige. Ich hab in meinem Tool einfach nicht die passende gefunden, die Anschlüsse sind aber natürlich die gleichen.

Die Teileliste

Wie auch bei den letzten Projekten, ist das hier auch recht günstig und mit wenigen Teilen zu realisieren. Wenn ihr das Gehäuse auch so drucken wollt, braucht ihr natürlich einen 3D-Drucker. Die Dateien dazu findet ihr weiter unten.

• 6-Stellen 7-Segment-Anzeige (z.B. bei eBay, Suche nach „TM1637 6-stellig 7-Segment“)
• D1 Mini ESP-Board (z.B. im Makershop oder bei Aliexpress noch günstiger)
• 5V WS2812b LED-Streifen (z.B. bei Amazon, achtet darauf dass die LEDs nah beieinander sind und der Streifen mit 5 Volt betrieben wird)
• Kapazitiver Touch-Sensor (sucht nach „TTP223“)
• PLA nach eurer Wahl, natürlich ist weißes oder durchsichtiges für die Rückseite von Vorteil
• Kabel/Litze und natürlich das passende Werkzeug wie Lötkolben oder Abisolierzange

Die Software

Damit aus Hardware mehr als nur ein Klumpen Einzelteile wird benötigt es natürlich auch die passende Software. Im Fall von EchoTrack habe ich die selbst geschrieben und dazu zum ersten Mal mit den Webtools von ESPHome experimentiert. Das ermöglicht eine – sofern ich alles richtig gemacht habe – einfache Installation über euren Browser. Vorausgesetzt ihr seid mit Chrome, Microsoft Edge oder Opera unterwegs. Wenn dem ist, findet ihr unter https://esp.datort.de den Installer. Wie das genau funktioniert, könnt ihr euch natürlich auch nochmal in meinem kleinen YouTube-Werk anschauen.

Der Installer funktioniert aktuell nur mit ESP-Boards mit 8266er-Chipsatz. Wenn ihr ein anderes Board verwenden möchtet, nutzt gerne den Quellcode aus meinem Github-Repository und erstellt euch einen eigenen Build.

3D-Dateien

Wie häufig bei diesen Projekten stelle ich die 3D-Dateien als STL wieder zum Download bereit. Ihr könnt die gerne modifizieren und für eigene Kreationen nutzen, wie es euch beliebt. Gedruckt habe ich in meinem Fall mit Cura. Bei den Einstellungen habe ich das Profile „Dynamic Quality – 0.16mm“ verwendet. Das Infill habe ich auf 100% gestellt. Supports sind nicht nötig, wenn ihr die Objekte so dreht, dass das „Front“-Modell nach mit der Vorderseite nach unten zeigt. Die Rückseite sollte ebenfalls auf dem Rücken liegen, dann passte das bei mir.

Wie genau der Zusammenbau lief und wie das ganze in Aktion aussieht, könnt ihr gerne dem Video entnehmen. Viel Spaß!

Neben der Awtrix 3 gibt es mit WLED ein zweites bereits seit Jahren bekanntes und etabliertes OpenSource-Projekt, welches RGB-LED-Matrixen oder auch LED-Streifen unterschiedlichster Art mit Inhalten versorgen kann. Das können dann einfach bis komplexe Animationen sein, teils sogar an Umgebungsgeräusche wie Musik angepasst. Oder eben auch bunte Pixelkunst, die dann auf der Kommode dazu beiträgt, einem Raum etwas mehr Farbe zu verleihen und damit eine andere Atmosphäre zu verschaffen.

Wie beim letzten Projekt wollte ich auch diesmal wieder alles selbst machen bezogen auf das Gehäuse. Entsprechend kommen erneut alle Teile aus dem 3D-Drucker. Dieses Mal habe ich mich dabei für ein graues PLA entschieden. Ich wollte gerne einen Kontrast zu der weißen Umgebung, in der das Ganze später stehen soll. Der „Trick“ ist der derselbe wie zuvor: Die Front des Gehäuses wird auf einen Rahmen aufgesetzt in dem die 8x8er-Matrixen festgezurrt sind. Dabei ist die Frontfläche nur 0.4mm stark, oder: Nur zwei Schichten PLA. Dadurch ist sie flexibel, aber stabil genug und lässt vor allem noch genug Licht durch. Nur zu heiß sollte es nicht werden.

Die Teileliste

Die Anzahl der Komponenten ist recht überschaubar, die LED-Matrixen kommen dabei wieder aus China. Die Preise dort sind einfach unschlagbar.

Disclaimer: Die Links sind KEINE Affiliate-Links. Ich verdiene nichts daran (hier ist eh alles privat), sie sollen euch nur zum schnellen Finden der verwendeten Komponenten dienen, die ihr natürlich überall anders ordern könnt.

• 4x 8×8 WS2812B LED Matrix (5V) (=> Aliexpress)
• 1x ESP8266 D1 Mini (Clone) (=> Makershop)
• 1x Ein-/Aus-Schalter, 11×15 mm (z.B. bei eBay)
• 1x USB-Breakoutboard zur Spannungsversorgung (=> Amazon)
• 8x 1.4×3.5er Schräubchen

Neben diesen Teilen kommt natürlich noch Kabel zum Einsatz. Achtet darauf, dass dessen Durchschnitt nicht zu dünn ist, denn je nach Konfiguration können die LED in Gänze ein paar Ampere schlucken. Bedenkt dabei auch, dass ihr ein PLA-Gehäuse vor euch habt: Der verbrauchte Strom wird zu nicht kleinen Teilen auch in Abwärme verteilt. Betreibt die Matrix also bitte eher gedimt. Ich habe in der Software ein Verbrauchslimit von 850 mA konfiguriert, damit bin ich bisher gut gefahren.
Außerdem noch verwendet: PLA in grau und schwarz, 2-Komponenten-Epoxidharz zum befestigen von Front- und Rückseite, div. kleine Kabelbinder

Schaltplan

Um den Nachbau etwas zu vereinfachen, findet ihr hier einen Schaltplan zum Anschluss der Komponenten, so wie ich sie im Video verbunden habe.

3D-Druck: STL Download

Hier alle Dateien die ihr benötigt, möchtet ihr das Projekt nachdrucken. Alle Dateien wurden mit „dynaschmischer Qualität“ in 0.16mm gedruckt, bis auf die Front. Diese wurde in „Standardqualität“ mit 0.2mm gedruckt. Für den Rahmen sind Supports nötig. Ich habe es so gedruckt, dass die Rückseite unten liegt. Ich habe versucht die Form so zu optimieren, dass sich die Supports im Nachgang einfach entfernen lassen und würde behaupten, dass mir das gelungen ist. Das Gitter in dem die LED-Matrixen befestigt werden druckt auf dem Kopf liegend, also so das die Pins zum befestigen der LED-Module zuletzt gedruckt werden. Diese Pins sind sehr fragil weil filigran. Dadurch, dass mein Drucker sie nicht perfekt abrunden kann, lassen sich die Boards etwas schwer einsetzen, wie man ja auch im Video sieht. Geht da vorsichtig vor, dann geht das klar.

Links

• WLED Installationstool
• Pixel Art Converter-Dokumentation
• Pixel Art Converter Github Repository
• „Piskel“ Online Pixel Editor zum Design eigener Pixelart

Wichtige Hinweise

Bitte beachte: Es handelt sich um ein privates Bastelprojekt eines Hobbyschraubers. Will sagen: So wie gezeigt funktioniert das Ganze gut, aber es bestehen auch Gefahren: Bspw. kann von zu dünnen Kabeln bei hoher Stromaufnahme der LEDs eine Brandgefahr ausgehen oder durch Abwärme das PLA verformen. Bei Fehlanschluss des ESP-Boards kann selbiges Schaden nehmen. Heißt: Baut meine Sachen gerne nach, aber ihr handelt eigenverantwortlich. Ich will jeden ermutigen sich auch Themen anzunehmen, in denen er oder sie bisher kein Expertise besitzt, aber seid clever: Informiert euch abseits meines Blogs, lasst eure Errungenschaften nicht unbeaufsichtigt laufen usw. Lernen, machen, clever sein!

Die Älteren unter euch können sich bestimmt noch daran erinnern: Früher gab es in der Regel nur ein Telefon zuhause. Das stand (zumindest bei uns) in der Diele und war natürlich kabelgebunden. Unseres war Bordeauxrot und hatte immerhin schon ein Tastenfeld. Einziges Feature neben dem Wählen von Nummern und natürlich dem Telefonieren selbst: Ein kleiner Nummernspeicher für die Wahlwiederholung. Früher war nicht alles besser aber manches einfacher.

Die Telefone wurden von der Deutschen Post bereitgestellt und trugen das Kürzel „FeTAp“. Dahinter verbirgt sich, wen wundert es, ein deutsch-bürokratisch stemmiges Wort: Der Fernsprechtischapparat. Ein Traum eines Produktnamens – man weiß sofort was das Teil kann. Dennoch ist das Ding für mich mega nostalgisch: Ich erinnere mich gut, wie abends lange mit meinen Freunden gequatscht habe. Abends deshalb, weil dann der Gebührenzähler deutlich langsamer lief. Ich meine 23 Pfennig für 4 Minuten für ein Ortsgespräch. Wilde Zeiten.

Für 5,- Euro wiederum kann man heute auf eBay so ein FeTAp ab und an ersteigern. Mein Modell hier ist zwar beige, das tut der Freude aber keinen Abbruch: das Tippen auf dem Tastenfeld und das Geräusch das der Hörer bei Abnehmen oder Auflegen macht wecken freudige Erinnerungen. Theoretisch könnte man das Telefon jetzt einfach an die Fritz Box anschließen, sofern die noch einen alten Analogen Telefonanschluss hat und direkt los telefonieren. Da die aber im Keller steht und das ganze nicht mehr Zeitgemäß ist, war das nächste Bastelprojekt geritzt: Aus dem FeTAp 0111 sollte der FeMAp 2000 werden:

Der Fernsprechmobilapparat 2000!

Teile aus dem 3D Drucker

Eine Prämisse bei meinen Bastelaktionen mit alter Hardware ist, diese möglichst unversehrt zu lassen. Glücklicherweise bieten diese Telefone viel Raum, um die vorhandene Hardware einfach zu überbauen oder bestehende Komponenten zu erweitern. So konnte ich mittels eines kleines Hebels an der Höhrerauflage und einer Halterung für einen Mikroschalter, die festverschraubt werden konnte eine Vorrichtung einbauen, mit der sich erkennen lässt ob der Hörer aufliegt oder abgenommen ist. Für die neue Hauptplatine konnte eine Halterung gedruckt werden, die einfach auf der alten Hardware aufliegt. Da das Mikrofon nicht mehr kompatibel mit der neuen Technik war, wurde die alte Kapsel vorsichtig entfernt und das neue Kondensatormikrofon in eine ebenfalls 3D-gedruckte Fassung eingesetzt.

Das erste eigene PCB

Eine tolle Erfahrung war die Entwicklung eines eigenen PCB, also einer eigenen Platine nur für dieses Projekt. Hier hatte ich bisher so gar keine Erfahrung mit und hab mich für das Projekt in das Thema eingearbeitet. Rausgekommen ist eine mit rund 8 Euro für 5 Exemplare recht günstige Platine, die die unterschiedlichen Komponenten gut vereint. Natürlich habe ich 2 Fehler eingebaut: Eine Diode fehlte, welche verhindert dass das SIM-Modul Strom vom Raspberry Pi Pico bezieht wenn dieser programmiert wird. Außerdem habe ich Depp einen Widerstand vergessen. Ärgert mich beides derbst, aber kann wohl beim ersten Projekt mal passieren.

Zu den Komponenten im Detail: Für die mobile Kommunikation ist ein SIM800L-Modul verantwortlich. Das Modul gibt es für unter 10,- Euro. In der Theorie ist der Anschluss recht simpel: Das Board bekommt eine normale SIM-Karte verpasst. Außerdem brauch es ca. 3.7 Volt Spannung. Die Steuerung erfolgt über eine UART-Schnittstelle. Die Kommunikation erfolgt in beide Richtungen und findet über Modembefehle statt. Zusätzlich werden noch ein Mikrofon und ein Lautsprecher angeschlossen. In unserem Fall natürlich die im Hörer. Das Ganze bringt zwei Herausforderungen: Das Modul ist beim Verbindungsaufbau mitunter sehr gierig und braucht laut Hersteller im Peak bis zu 2A! Stehen die nicht bereit, resetet sich das Modul und man kommt in einen Connect-Loop. Das nervt, kann aber durch einen (in meinem Fall vermutlich überdimensionierten) Kondensator aber aufgefangen werden. Die andere Herausforderungen besteht in Abschirmung gegen Interferenzen bei Telefonaten. Erinnert ihr euch noch, wenn früher ein Anruf auf eurem ersten Handy einging und eure Boxen im Auto oder von der Stereoanlage den Anruf bereits lautstark ankündigten? Holla die Waldfeh, diese alten Vibes haben wir hier auch in voller Ausprägung. Da gibts noch Optimierungspotential.

Gesteuert wird das Ganze von einem Raspberry Pi Pico. Den habe ich lieb gewonnen während der Entwicklung der Software. Entwickelt habe ich mit der Arduino IDE. Das Board wird da sehr gut unterstützt. Der Pico zeichnet sich durch seine Vielzahl an GPIO-Ports aus. Außerdem bietet er mit seinen 2 Kernen Unterstützung für Multithreading. Die UART-Kommunikation lief direkt problemlos, der kleine OLED-Screen wird zuverlässig mit Infos befeuert. Alles top, und das für einen wie ich finde echt fairen Preis. Wird nicht das letzte Projekt mit dem Pico gewesen sein.

„Kannst Du mich hören?“

Zur Wahl von Rufnummern musste noch das Tastenfeld „reverse engineered“ werden. Wobei der Begriff schon fast ein bisschen übertrieben ist: Die Tasten sind als Matrix geschaltet. Gibt man einen Stromimpuls auf die erste Spalte der Matrix, zeitgleich auf Reihe 2 und fließt Strom, so muss in diesem Moment die Taste 4 gedrückt werden. Das im Milisekundentakt abgefragt und mit einer Logik für Debouncing erweitert: Schon funktioniert das Tastenfeld.

Mit eingelegter SIM-Karte konnte dann auch bald der erste Anruf durchgeführt werden. Und tatsächlich: Es funktionierte! Jedoch: Aller Anfang ist schwer wenn man mein eigenes Mobiltelefon „entwickelt“. So war das Gespräch insbesondere auf Seiten des Angerufenen von Interferenzen geprägt. Hier gibt es noch Optimierungspotential durch bessere Schirmung der Mikrofonleitung und/oder durch eine Anpassungen der Schaltung.

„Natürlich ist da Snake drauf!“

Kein Telefon welches die Zahl 2000 im Namen trägt wäre komplett ohne ein ganz bestimmtes Spiel: Snake. Es ist so simpel wie gut. Und ich weiss gar nicht, wieviel Zeit man damals in dieses so triviale Spiel versenkt hat. Aber: Wir hatten ja nix! Bei aufgelegtem Hörer und Druck der *-Taste wird Snake gestartet. Da kommen schon echt Erinnerungen auf.. Übrigens: Wer nur den Part mit Snake nachbauen will, sollte einen Blick in vmednis Github Repository werfen. An dem Code habe ich mich bedient und für meine Zwecke angepasst. Danke für das OpenSource-Projekt an dieser Stelle.

Die Downloads

Zugegeben, das Projekt baut man nicht in 5 Minuten nach. Aber das muss man ja auch gar nicht. Es gibt bestimmt noch 1.000 andere Möglichkeiten, mit dem SIM800L-Modul oder anderen ein eigenes Mobiltelefon zu kreieren. Oder es kann eine ganz andere Funktion für solch ein altes Gerät gefunden werden. Und vielleicht kann der Kram hier ja einfach nur als Inspiration dazu dienen. Deshalb hier alles, was ihr vielleicht brauchen könnt:

Die Dateien

Den Code findet ihr wie immer in meinem Github-Profil.

*) Achja, der Akku fehlt noch. Aber: Es ist alles vorbereitet dafür!

Herausgekommen ist dabei ein „Command Control Center“. Der Name ist völlig übertrieben, ich weiss. Das Gehäuse ist eigens von mir skizziert und mittels 3D-Drucker selbst gedruckt. Wichtig war mir, dass es gut an meinen Schreibtisch (ein weit verbreitetes Modell eines schwedischen Möbelherstellers) passt und drei Taster beherbergen kann. Zusätzlich, um der Mächtigkeit des Begriffs „Command Control Center“ näher zu kommen, befindet sich im Gehäuse Platz für einen Schlüsselschalter, der die Spannungszufuhr für das verbaute D1 Mini ESP-Board steuert. Man hätte das mit Sicherheit auch anders lösen können, aber: Et soll ja auch Spaß machen!

Die Taster bieten neben ihrer eigentlichen Aufgabe des als Taster fungieren noch die Möglichkeit, einen LED-Ring leuchten zu lassen. Der symbolisiert ob die entsprechende Lampe ein- oder ausgeschaltet ist. In meinem Beispiel sind zwei Taster mit weißer und einer mit blauer LED verbaut. Die Taster sind mir im Nachgang etwas zu klein zum Drücken, dennoch mag ich sie und mit rund 4,- Euro waren sie recht günstig. Außerdem sind sie mit einer Eingangsspannung von 3 bis 9 Volt für die LED recht flexibel einsetzbar.

Im Inneren arbeitet ein D1 Mini Clone-Board, also ein ESP8266 der direkt Wifi onboard hat. Das ist wichtig, da die Homebridge, die bei mir als zusätzliche Ebene zu Apples Homekit im Einsatz ist, über API-Aufrufe über das lokale Netzwerk gesteuert wird. Von dem D1 Mini-Board brauch es 6 Pins: 3 für die Statusanzeige, also die jeweilige LED. Und eben 3 weitere für die Erkennung der Tastendrücke.

Das ist es im Wesentlichen dann auch schon. Natürlich muss die Software noch angepasst werden. So müssen sogenannte „uniqueId“ hinterlegt werden. Dabei handelt es sich um eine eindeutige Identifikation eines jeden Geräts, welches über Homebridge geschaltet werden kann. Tastendrücke lösen dann entsprechende API-Anfragen aus, welche diese „uniqueId“ übermitteln, bzw. sie verwenden um in regelmäßigen Abständen nach dem Status (Licht an oder aus) bei der Homebridge nachfrage. Denn es könnte ja auch sein, dass eine Lampe oder Steckdose auf anderem Weg geschaltet wird.

Meinen Code stelle ich euch natürlich frei und als Open Source auf Github zur Verfügung. Die Datei für den 3D-Druck des Gehäuse findet ihr hier:

Den Code habe ich auf mein Github-Profil gepackt. Von dort könnt ihr alles einfach herunterladen oder via Git auschecken.

Damals hatte ich sowohl auf Mastodon als auch unter dem Video den Tipp erhalten, mir mal den BME280 oder den DS18B20 anzuschauen. Diese Sensoren seien deutlich besser als der DHT22. Gesagt getan: Den BME280 gab es für ca. 6 Euro im 5er Pack aus Fernost, den DS18B20 habe ich für so ziemlich denselben Preis bei einem deutschen Händler bestellt.

Alle drei Sensoren sind im Detail ein bisschen anders. So ist der DHT22 der Klassiker, er ist nicht ganz schmal, sehr gut mit Bibliotheken für Android oder ESP-Boards unterstützt und liefert neben der Temperatur auch die relative Luftfeuchte.

Der BME280 ist, nimmt man nur den Sensor für sich, sehr klein. Er wurde von Bosch entwickelt vor dem Hintergrund dort verbaut zu werden, wo wenig Energie und wenig Platz zur Verfügung steht. Neben Temperatur und relativer Feuchte kann er auch den Luftdruck ermitteln. Es gibt auch ein Modell, welches auf den Namen BMP280 hört. Dieser ist hingegen nicht in der Lage, die Luftfeuchte zu ermitteln. Auch für diese Sensoren gibt es einige gute Bibliotheken, welche die Verwendung relativ einfach machen. Allerdings muss man wissen, auf welcher Adresse der Sensor mittels I²C zu erreichen ist: In diesem Fall ist es 0x76, bei anderen 0x77.

Der DS18B20 ist gefühlt der Vielseitigste was seine unterschiedlichen Bauformen angeht. Neben der von mir verwendeten Variante gibt es u.a. auch in einer Wasserdichten Version. Allerdings kann er, anders als der DHT22 oder der BME280 rein die Temperatur ermitteln, nicht die Luftfeuchte. Übermittelt werden die Daten mit dem 1-Wire-Protokoll. Dabei handelt es sich um eine serielle Datenübertragung welche von der Firma Dallas Semiconductor entwickelt wurde. Der Name ist Programm: Es wird eben neben der Spannungsversorgung nur ein weiteres Kabel benötigt. Wobei, das stimmt nicht ganz: Für die Schaltung wird zudem ein Pull-Up-Widerstand benötigt. Sonst funktioniert das Ganze nicht. Keine große Herausforderung, wenn man es noch nie gemacht hat, sollte man sich dem Thema einmal annehmen.

Für meinen Vergleich habe ich mir auf meinem Steckfeld 3 Teststrecken gebaut. Beide sind vom Aufbau identisch: Von jedem Sensor existiert pro Teststrang ein Exemplar. Angeschlossen sind sie an einen D1 Mini Clone, welcher die Daten an meine InfluxDb und damit an an ein Grafana-Dashboard sendet über das die Auswertung stattfindet. Den Code stelle ich euch gerne bereit. Auch wenn man vermutlich dieses Setup so nicht benötigt, kann man sich vielleicht für eigene Projekte etwas abschauen wenn man neu in der Materie ist:

#include <Wire.h>
#include <SPI.h>
#include <Adafruit_BME280.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#include <ESP8266WiFi.h>
#include <InfluxDbClient.h>
#include "DHT.h"
#include "secrets.h" // Einfache Konstanten-Sammlung für Credentials


#define ONE_WIRE_BUS 2 // GPIO PIN 2

InfluxDBClient influx(INFLUXDB_URL, INFLUXDB_ORG, INFLUXDB_BUCKET, INFLUXDB_TOKEN);
Point bmeSensor("bme_1");
Point dsSensor("ds_1");
Point dhtSensor("dht_1");


Adafruit_BME280 bme;
Adafruit_Sensor *bme_temp = bme.getTemperatureSensor();
Adafruit_Sensor *bme_humidity = bme.getHumiditySensor();

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature ds18b20(&oneWire);

DHT dht(14, DHT22); // GPIO PIN 14

void setup() {
  Serial.begin(9600);

  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASSWORD);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("");
  Serial.print("Connected to ");
  Serial.println(WiFi.SSID());
  Serial.print("IP address:\t");
  Serial.println(WiFi.localIP());


  
  Serial.println(F("BME280 Sensor event test"));

  // Erzwinge Adresse 0x76 statt 0x77, nutzt die SCL/SDA Pins des D1 mini
  if (!bme.begin(0x76)) { 
    Serial.println(F("Could not find a valid BME280 sensor, check wiring!"));
    while (1) delay(10);
  }
  
  bme_temp->printSensorDetails();
  bme_humidity->printSensorDetails();

  ds18b20.begin();

  dht.begin();

  influx.setInsecure();
}

void loop() {
  sensors_event_t temp_event, pressure_event, humidity_event;
  bme_temp->getEvent(&temp_event);
  bme_humidity->getEvent(&humidity_event);
  
  Serial.print(F("BME280 Temperature: "));
  Serial.print(temp_event.temperature);
  Serial.println(" °C");

  Serial.print(F("BME280 Humidity: "));
  Serial.print(humidity_event.relative_humidity);
  Serial.println(" %");

  bmeSensor.addField("temperature", temp_event.temperature);
  bmeSensor.addField("humidity", humidity_event.relative_humidity);
  if (!influx.writePoint(bmeSensor)) {
    Serial.print("InfluxDB write failed: ");
    Serial.println(influx.getLastErrorMessage());
  }

  ds18b20.requestTemperatures();
  Serial.println("DS18B20 Temperature: " + String(ds18b20.getTempCByIndex(0)) + "°C");

  dsSensor.addField("temperature", ds18b20.getTempCByIndex(0));
  if (!influx.writePoint(dsSensor)) {
    Serial.print("InfluxDB write failed: ");
    Serial.println(influx.getLastErrorMessage());
  }

  Serial.println("DHT22 Temperature: " + String(dht.readTemperature()));
  Serial.println("DHT22 Humidity: " + String(dht.readHumidity()));
  dhtSensor.addField("temperature", dht.readTemperature());
  dhtSensor.addField("humidity", dht.readHumidity());
  if (!influx.writePoint(dhtSensor)) {
      Serial.print("InfluxDB write failed: ");
      Serial.println(influx.getLastErrorMessage());
    }

  delay(1000);
}

Für meinen Test habe ich das ganze Setup kurz in die „Kälte“ gestellt. Das sollte dazu dienen um zu sehen wie schnell die Sensoren der Raumtemperatur annähern. Als Referenz diente ein Thermometer, was mehrere Stunden im Raum stand. Zugegeben: ist wieder nicht hochgradig wissenschaftlich, aber für die Stichprobe in meinen Augen ausreichend.

Am Ende bestätigten sich eure Aussagen: Sowohl der DS18B20 als auch der BME280 sind weniger träge als der DHT22. Der DS18B20 ist bei der Disziplin das Rennpferd. Nach etwa 2-3 Minuten hatte er sich bereits bereits wieder angeglichen. Der BME280 war mit 5 Minuten unwesentlich langsamer, während der DHT22 ca. 10 Minuten brauchte. Hinzu kommt die Frage nach der Güte der Daten. Zwischen den drei DHT22 Sensoren lagen am Ende mehr als 1 Grad Unterschied. Auch hier waren beide andere Sensortypen deutlich besser mit ca. 0.2 Grad beim DS18B20 bzw. nur ca 0.1 Grad beim BME280. Der BME280 war auch der Sensor, der am nächsten am Standthermometer lag. Und das sowohl in Bezug auf die Temperatur als auch auf die relative Luftfeuchte.

Somit ist das auch mein persönlicher Testsieger, wenngleich der DS18B20 unmittelbar danach kommt. Der DHT22 ist mit Sicherheit kein schlechter Sensor, aber mit dem Wissen ist seine Zeit bei mir zu Hause wohl vorbei. Ich werde ihn zeitnah gegen die BME280er tauschen.

Mit dem CCS811 ist bereits seit einigen Jahren ein Sensor auf dem Markt, mit dem sich dies per se realisieren lassen sollte. Mein Exemplar lag bisher (einmalige Verwendung ausgenommen) ungenutzt in der Ecke. Zeit also, mal genauer zu schauen was der Sensor so kann – und eben vielleicht auch nicht!

Im „Bastelbedarf“ kommt der Sensor oft fertig aufgebaut auf einem kleinen Board, welches die Handhabe mit ihm erleichtert. Wie genau, das mag von Board zu Board etwas unterschiedlich sein. Ich beziehe mich hier auf ein fertiges Platinchen von Adafruit, welches die Verwendung in 2 Punkten erleichtert:

• Pull-Up-Widerstände: Für die Kommunikation mittels I²C sind diese nötig und bereits auf dem Board verlötet. Dies vereinfacht die Verkabelung in unserem Setup, zumindest wenn sonst nichts auf der I²C-Leitung kommuniziert
• Level-Shifting: Egal ob wir ein Development Board mit 3.3V oder 5V Spannung an den I/O-Ports verwenden, dieses Sensor-Modul kommt mit beidem klar

Bleiben am Ende also noch 4 Kabel nötig, um das Board zu betreiben: 3.3V oder eben 5V, Ground, sowie SDA und SCL für die Kommunikation.

Viel Code ist ebenfalls nicht nötig, da es unterschiedliche Bibliotheken gibt die einem die Arbeit erleichtern. Ich nutze in meinem Beispiel die passende Bibliothek zum Board: „Adafruit_CCS811„. Die ist vorab über die Arduino IDE zu installieren. Hier der Code aus meinem Video:

#include "Adafruit_CCS811.h"

Adafruit_CCS811 ccs;

void setup() {
  Serial.begin(115200);

  if (!ccs.begin()) {
    Serial.println("Keine Kommunikation mit Sensor, Verkabelung prüfen");
    while(1);
  }

  while(!ccs.available());
}

void loop() {  
  if (ccs.available() && !ccs.readData()) {

    Serial.print("CO2: ");
    Serial.print(ccs.geteCO2());
    Serial.print("ppm, TVOC: ");
    Serial.println(ccs.getTVOC());

  } else {
    Serial.println("Keine Daten empfangen");
    delay(5000);
  }

  delay(1000);
}

Wie man hier sieht ist es möglich mit der Methode getTVOC() die Gesamtzahl der sogenannten Volatile Organic Compounds (VOC) abzurufen. Übersetzt sind das flüchtige organische Verbindungen wie Kohlenwasserstoffe oder Alkohole die sich durch die Luft bewegen. Treffen solche Partikel auf den Sensor, so „zählt“ dieser sie. Mit der Methode geteCO2() lässt sich zudem das sog. equivalent carbon dioxide, also ein CO2-Äquivalent abfragen. Hierbei sollte man jedoch wissen, dass der Sensor nicht in der Lage ist CO2 zu messen. Der ausgegebene Wert ist eine Berechnung, die auf den TVOCs basiert. Entsprechend kann man sich die Frage nach der Güte der ausgegebenen Werte stellen.

Für einen groben Indikator in wie weit sich die Qualität der Luft in einem Raum über die Zeit verändert ist der Sensor aber allemal gut und in Form eines solchen fertig aufgebauten Boards auch für Einsteiger einfach nutzbar. Um die für diesen Sensor bestmöglichen Ergebnisse zu erhalten, sollte man zudem 2 Dinge beachten:

• Vor der ersten Verwendung, sollte der Sensor eine 48 Stunden lange „Burn-In“-Phase durchlaufen. Ergo: Er soll einfach „arbeiten“. Nach 48 Stunden ist er dann „eingebrannt“ und soll vernünftige Ergebnisse liefern
• Vor jeder Verwendung benötigt der Sensor etwa 20 Minuten, bis er „betriebswarm“ ist. Zuvor sind die Ergebnisse ungenau