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");
  }
}

So ging es mir mit meinem Nokia 5110: Ich habe es damals geliebt. Es war eins der ersten Nokias mit Snake. Ein so einfaches Spiel, das zumindest die Älteren unter uns wahrscheinlich alle noch kennen. Bisher stand es etwas verloren in meinem Regal. Und somit war es der perfekte Kandidat für dieses Projekt: Ein mit LEDs versehener Fotorahmen, welcher die Innereien des Nokia 51110 so richtig zur Geltung bringen sollte.

Die Komponenten

• Fotorahmen „SANNAHED“, 25x25cm, 6,- Euro
• D1 Mini, ESP8266*, ca. 5,- Euro
• WS2812B-LED-Streifen, 5V, 60 LEDs/m, 9,- Euro
• Magentkontaktstecker, ca. 3,-/Stk.
• USB-Stromanschlussboard, ca. 1,- Euro
• Sperrdiode, ca. 0,50 Euro
• Selbstgestalteter Fotohintergrund, ca. 5,- Euro
• Klebepads oder 2-Komponentenkleber, zwischen 2,- und 5,- Euro
• etwas Kabel, Lötkolben, Schrumpfschläuche

*) Wie sich während der Arbeit rausstellte, endet in der nahen Zukunft die Unterstützung von ESP8266-Boards seitens der eingesetzten WLED-Software. Für neue Projekte werden deshalb ESP32-basierte Boards empfohlen, die sich preislich aber nur wenig unterscheiden dürften.

Das Exponat

Das Nokia lies sich recht einfach auseinandernehmen: Nachdem man die Batterie entfernt hatte, offenbarten sich auf der Rückseite einige Torx-Schrauben mit denen man schnell im inneren war. Dort ging es dann ebenso schnell weiter. Das muss natürlich bei jedem Gerät der Fall sein, auch wenn früher noch mehr Teile verschraubt statt verklebt waren. Anders als es heute oft gängige Praxis ist. Wenn euer Exponat da etwas widerspenstiger ist, habt bitte im Hinterkopf: Verletzt euch nicht! Displays können brechen, Batterien können auslaufen oder man kann beim Versuch etwas aufzuhebeln abrutschen. Denkt da an eure Finger und eure Gesundheit. Lest dazu bitte auch folgenden Absatz.

Vorsicht: Gefahr!

Eine Sache, die man unabhängig von eurem Bastelvorhaben nicht unterschätzen sollte, ist die potentielle Gefahr, die von alten Batterien und Akkus ausgehen kann. Ich war überrascht zu sehen, dass bereits in meinem Nokia 5110 von 1998 ein Lithium-Ionen-Akku verbaut war. Die sind heute überall und sehr sicher, dennoch weiß man nie ob im inneren bereits Zersetzungseffekte eingetreten sind. Ich will das Thema auch gar nicht zu sehr stressen, das Netz ist voll mit Artikeln zu dem Thema. So viel nur: Ich habe mich bewußt dazu entschieden, den Akku auf dem Wertstoffhof abzugeben und ihn nicht in den Fotorahmen zu kleben.

Der kreative Teil

Nachdem das Telefon in seine Einzelteile zerlegt war, ging es um die Positionierung. Beim Nokia 5110 kommen viele ähnlich große zum Einsatz. Wenige Kleinteile, was die Positionierung etwas erschwerte. Nachdem ich mich für ein Layout entschieden hatte, ging es ans „designen“ des Hintergrunds. Ich habe das Wort absichtlich in Anführungszeichen gepackt: Denn hier muss man wirklich kein Experte oder Grafiker sein. Die Hardware, illuminiert durch die LEDs, ist der eigentliche Hingucker. Mit ein paar kurzen Texten, Erklärungen oder einfachen grafischen Elementen kann man viel erreichen.

In meinem Fall habe ich mir folgende Fragen gestellt:

• Wo positioniere ich den Namen des Telefons prominient?
• Kann ich einen kurzen Text schreiben, der etwas über die Geschichte erzählt?
• Kann ich die einzelnen Komponenten (Logic Board, Tastenfeld, Cover, …) benennen?
• Kann ich mit Pfeilgrafiken auf bestimmte Bauteile oder Features hinweisen?
• Wo soll der Rahmen stehen und welche Farbe hat er: empfiehlt sich ein heller oder ein dunkler Hintergrund?
• Welche zeitgemäße, moderne oder zurückhaltende Schriftart verwende ich?

In Affinity Photo habe ich daraufhin ein bisschen gebastelt, geschoben und experimentiert. Wenn ihr kein Grafikprogramm habt, könnt ihr euch das kostenfreie Tool GIMP besorgen, was in der Bedienung als Anfänger vielleicht etwas hakelig sein kann. Alternativ würde ich noch Canva ins Rennen werfen, was man eingeschränkt nach Registrierung kostenfrei nutzen kann.

Hardware & Software

Zum Einsatz kommen einmal mehr ein ESP8266-Board mit WLED-Software. Wie oben bereits angerissen, sollte man laut WLED-Website für neue Projekte inzwischen ESP32-Boards verwenden, da der 8266er-Chipsatz nicht mehr lange unterstützt werden wird.

Auf den ESP wird dann einfach die WLED-Software über den bekannten Webinstaller geflashed. Danach verbinde ich das zusätzliche USB-Board, an welches später das Netzteil angeschlossen wird, mit dem ESP und dem LED-Steifen. Dazwischen kommt noch eine Diode: Wird Strom an die externe USB-Buchse angeschlossen, soll dieser den ESP und den LED-Streifen versorgen. Schließe ich aber z.B. für ein Software-Update ein USB-Kabel an den ESP direkt an, soll dieser nicht den LED-Streifen mit Strom versorgen. Das könnte eine zu Hohe Last für den ESP oder euren USB-Anschluss am Rechner sein.

Apropos: Insbesondere wenn ihr sehr viele LEDs anschließen wollt, solltet ihr euch Gedanken um die Dicke eurer Kabel machen. Sind die zu dünn, können die sich auch entsprechend erhitzen und in Flammen aufgehen. Ich empfehle da immer den Rechner vom WLED-Projekt.

Danach habe ich die einzelnen LEDs mit dem Streifen verlötet. Dabei ist es wichtig auf die Reihenfolge zu achten! Auf den Streifen befindet sich ein kleiner Pfeil, welche die Laufrichtung anzeigt.

Um den Rahmen von seinem Innenleben trennen zu können, habe ich Magnetkontakte verwendet. Die hatte ich noch rumfliegen, boten sich an, sind aber komplett optional.

Komponenten befestigen

Nachdem das Foto auf dem Hintergrund aufgeklebt wurde, wurden die einzelnen Komponenten des 5110 wieder rum auf das Foto geklebt. Hierbei habe ich anfangs mit kleinen Klebepads gearbeitet. Die funktionieren auch gut, allerdings sollte man einerseits nicht zu wenige von ihnen verwenden und diese nicht in Türmchenbauweise zu hoch stapeln. Sowohl die Platine des Tastenfelds als auch das Cover der Front – beides große aber leichte Teile – kamen mir nach 1-2 Tagen entgegen.

Ich habe mich dann dazu entschieden, mit 2-Komponentenkleber aus dem Discounter weiterzumachen. Der war günstig, hält aber nach seinen 2 Stunden Trocknungszeit richtig gut. Als Abstandshalter verwende ich kleine Elemente aus dem 3D-Drucker. Da kann man aber auch sicher ein Stückchen Holz oder ähnliches verwenden, wenn man keinen 3D-Drucker zur Hand hat.

Im Nachgang würde ich definitiv immer wieder den Weg mit dem Kleber gehen. Es ist einfach super ärgerlich, wenn man 2 Tage später auf den Fotorahmen schaut und sich wundert, warum Teile plötzlich eine Etage tiefer liegen als erwartet und schlimmsten Falls noch etwas beschädigen.

Konfiguration

In der WLED-Oberfläche lassen sich nun unterschiedliche Segmente konfigurieren. In meinem Fall befinden neben dem LED-Streifen, der innen einmal um den Rahmen geht, 5 weitere LEDs unter der alten Hardware des Nokia. Über die Segmente ist mir mögliche, unterschiedliche Farben und Effekte für jede LED zu konfigurieren. So stelle ich ein:

• LED 1, Tastenfeld, Segment 1: Grün
• LED 2-3, Display, Segment 2: Weiß mit leichtem Blauton
• LED 4-5, Platine, Segment 3: Wechselnder, Bunter Farbeffekt

Die dann folgenden LEDs sind Teil des Streifens. Auch hier konfiguriere ich unterschiedliche Farben, sodass die einzelnen Komponenten (bunt) und Texte (weiß) unterschiedlich beleuchtet werden. Für wen das zu theoretisch war: Im Video zeige ich das nochmal ganz genau. Im Video wie hier der Hinweis: Speichern nicht vergessen, dass geschieht nämlich nicht automatisch!

Fazit

Ich bin mit dem Ergebnis sehr zufrieden. Bei der Konfiguration der LEDs tobe ich mich vielleicht noch ein bisschen aus, das ist mir vielleicht einen ticken zu farbintensiv. Aber da hat man ja alle Möglichkeiten dank WLED. Ein bisschen Zeit und Geduld sollte man für das Projekt mitbringen. Es sind, abhängig von der Anzahl der verwendeten LEDs, schon einige Arbeitsschritte. Aber es lohnt sich. Was die Kosten angeht, stehe ich am Ende bei irgendwas um die 20-30 Euro. Einige der Komponenten hatte ich noch hier und das Nokia 5110 habe ich jetzt natürlich nicht in die Rechnung mit aufgenommen – das ist eh unbezahlbar.

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.

Im Kern kommen vier 8x8er RGB LED Matrixen und ein ESP32-WROOM-32D zum Einsatz. Ähnliche Komponenten wie wohl auch in der TC001 verbaut. Als Software verwende ich die „Awtrix 3“-Bibliothek (vormals „Awtrix light“, im Kern aber die gleiche Software). Das ist eine aktive OpenSource-Weiterentwicklung der Awtrix-Bibliothek, einer Software für eine inzwischen wieder eingestellte LED Matrix.

Um Geld zu sparen, kommt das Gehäuse aus dem 3D-Drucker. Es wurde selbst designed und ist extrem minimalistisch gehalten. Zentraler Punkt sind die Gitter, hinter welche die kleinen LED-Panels geklemmt werden können. Die Gitter selbst können dann mit kleinen Haken an der Ober- bzw. Unterseite ineinander gehangen werden. Das Ganze fügt sich dann wieder rum in das Gehäuse ein, welches dann durch eine dünne Front verkleidet wird. (Fast) Fertig ist LED-Matrix.

Auf der Rückseite habe ich den ESP32 festgeklebt und verlötet. Strom kommt über USB und geschaltet werden kann die Anzeige über einen kleinen Schalter an der Unterseite. Apropos Strom: Die Displays sind recht energiehungrig und emittieren je nach Helligkeit einiges an Wärme. Das sollte man im Blick haben: Zum einen damit das Gehäuse sich nicht verformt. Zum Anderen sollte ein entsprechend starkes Netzteil angeschloßen und im Querschnitt nicht zu dünne Kabel verwendet werden.
Da ich bei meiner günstigen Variante keine Schalter und Sensoren verbaue, fehlt der Software beim ersten Start somit auch die Information über die Raumhelligkeit. Entsprechend hell werden die Panels also beim ersten Start angesteuert.

Am Ende komme ich bei knapp unter 22,- Euro raus. Neben den reinen Elektrokomponenten einberechnet ist auch der Strom für den 3D-Drucker, der so ca. 17 Stunden lang gedruckt hat. Außerdem anteilig etwas für das PLA, die Kabel und den verwendeten Kleber um die beiden Hälften zu vereinen.

Am Ende bin ich echt zufrieden mit dem Ergebnis. Die Anzeige sieht schlicht aus, die Dot-Matrix-Ansicht sieht ordentlich aus. Wenn ich es mir wünschen könnte, hätte ich es gerne einen ticken schärfer an den Kanten gehabt. Aber das ist kein Problem, solange man nicht direkt mit der Nase vor der Anzeige steht.

3D-Druck & Dateien

In meinem Video seht ihr alles Wichtige zum Aufbau und der Konfiguration. Auch wie ihr die Displays ans Laufen bekommen könnt, wenn diese nach dem ersten Start nur Unfug anzeigen. Wenn ihr das Gehäuse selbst in euren 3D-Drucker packen wollt, findet ihr hier den Download. Bitte beachtet: Das ist natürlich jetzt absolut Custom-Made. Will sagen. Wenn eure LED-Panel bspw. leicht andere Dimensionen haben kann es sein, dass es schon nicht mehr passt und ihr den Druck selbst modifizieren müsst.

Zum Download stelle ich zwei Dateien. Der erste Download enthält eine STL-Dateien mit dem gesamten Modell. Im zweiten ZIP-Archiv befinden sich alle Elemente einzeln. Nutzt, womit ihr besser klar kommt.

Ansteuern der Awtrix 3

Nachdem das erste Video mit dem Zusammenbau der Matrix viele Leute interessiert hat, erkläre ich in einem zweiten Video betont anfängerfreundlich, wie die Matrix angesprochen wird. Mit dabei Infos, wie man eigene Apps gestaltet oder die eingebauten Effekte nutzt. Teil des Videos sind auch die folgenden Scripte, welche den Funktionsumfang eurer Matrix mit nützlichen Infos erweitern und vielleicht der Einstieg in eigene Erweiterungen sein könnten.

Python-Script: YouTube Abos

In diesem Zustand fungiert die Matrix rein als Display. Mit anderen Worten: Sie kann nix, abgesehen von der Uhrzeit und Datumsanzeige. Inhalte können aber ja einfach über die HTTP-API oder mittels MQTT überspielt werden. Für meinen Fall – ich möchte die Abozahlen meines YouTube-Kanals anzeigen – hilft mir dafür folgendes Python-Script:

import requests
import time

# YouTube API Informationen
youtube_api_key = "xxx"
channel_id = "xxx"

# Awtrix Light Matrix Informationen
awtrix_ip = "192.168.xxx.xxx"


def get_subscribers_count(api_key, channel_id):
    url = f"https://www.googleapis.com/youtube/v3/channels?part=statistics&id={channel_id}&key={api_key}"
    response = requests.get(url)
    data = response.json()
    subscribers = int(data["items"][0]["statistics"]["subscriberCount"])
    return subscribers

def send_app_to_awtrix(app_name, text, icon, duration):
    headers = {"Content-Type": "application/json"}
    data = {
        "text": text,
        "icon": icon,
        "duration": duration
        "lifetime": 600
    }

    awtrix_url = "http://"+ awtrix_ip + "/api/custom?name=" + app_name
    response = requests.post(awtrix_url, json=data, headers=headers)
    
    if (response.text != "OK"):
        print(response.text)

    time.sleep(duration * 4)

def host_available():
    try:
        result = subprocess.run(['ping', '-c', '1', awtrix_ip], capture_output=True, text=True, timeout=5)
        return result.returncode == 0

    except subprocess.TimeoutExpired:
        print(f"Timeout: {awtrix_ip} is not reachable")


def main():
    while True:
        try:
            if host_available:
                subscribers = get_subscribers_count(youtube_api_key, channel_id)
                send_app_to_awtrix("youtube", f"{subscribers}", 7320, 15)
            
            time.sleep(300)
        except Exception as e:
            print(f"Fehler: {e}")
            time.sleep(60)

if __name__ == "__main__":
    main()

In dem Code wird ein Icon mit der ID 7320 verwendet. Dazu sei gesagt: Über das Webinterface der Awtrix Light-Bibliothek lassen sich unter dem Punkt „Icons“ vorgefertigte Grafiken importieren. Diese stammen von developer.lametric.com, können dort ausgewählt und nutzerfreundlich eingespielt werden. Ach ja, und um die YouTube-API nutzen zu können, müsst ihr euch zunächst für die Nutzung bei Google freischalten. Kostet aber nix.

Python-Script: Wetter via OpenWeatherMap

Nicht jeder unterhält einen YouTube-Kanal, aber bei überall gibt’s Wetter! Und so möchte man vielleicht Informationen wie die aktuelle Temperatur oder ob sich Regen nähert auf der Matrix anzeigen. Als Datenquelle kann dafür super die OpenWeatherMap dienen. Wer es nicht kennt: OWM ist inzwischen ein alter Hase wenn es darum geht, über eine (für die kleine Nutzung) kostenfreie API Wetterdaten für beliebige Standorte zu liefern. Einfach kurz mit E-Mail-Adresse anmelden, API-Key kopieren und los geht’s. Folgendes Python-Script holt sich Wetterinformationen von einem bestimmten Standort mittels Geo-Koordinaten und sendet das aktuelle Wetter mit Icon und Temperatur an die Awtrix:

import requests
import time

# OpenWeatherMap API Informationen
api_key = "..."
lat = "50.93"
lon = "6.95"

# OpenWeatherMap Icon -> Awtrix Icon
condition_mapping = {
    "01d": 1630,
    "01n": 962,
    "02d": 2286,
    "02n": 54631,
    "03d": 12246,
    "03n": 12246,
    "04d": 12294,
    "04n": 12294,
    "09d": 2284,
    "09n": 2284,
    "10d": 2416,
    "10n": 2416,
    "11d": 2981,
    "11n": 2981,
    "13d": 1673,
    "13n": 1673,
    "50d": 17056,
    "50n": 17056
}

# Awtrix Light Matrix Informationen
awtrix_ip = "192.168.xxx.xxx"


def get_weather(api_key, lat, lon):
    url = f"http://api.openweathermap.org/data/2.5/weather?lat={lat}&lon={lon}&appid={api_key}&units=metric"
    response = requests.get(url)
    data = response.json()

    if response.status_code == 200:
        icon = data["weather"][0]["icon"]
        temperature = data["main"]["temp"]
        return temperature, icon
    else:
        return None, None

def send_app_to_awtrix(app_name, text, icon, duration):
    headers = {"Content-Type": "application/json"}
    data = {
        "text": text,
        "icon": icon,
        "duration": duration
    }

    awtrix_url = "http://"+ awtrix_ip + "/api/custom?name=" + app_name
    response = requests.post(awtrix_url, json=data, headers=headers)
    
    if (response.text != "OK"):
        print(response.text)

    time.sleep(duration * 4)

def host_available():
    try:
        result = subprocess.run(['ping', '-c', '1', awtrix_ip], capture_output=True, text=True, timeout=5)
        return result.returncode == 0

    except subprocess.TimeoutExpired:
        print(f"Timeout: {awtrix_ip} is not reachable")


def main():
    while True:
        try:
            if host_available:
                temperature, icon = get_weather(api_key, lat, lon)

                if temperature is not None and icon is not None:
                    send_app_to_awtrix("owm", "{:.1f}°C".format(temperature), condition_mapping.get(icon), 15)
                else:
                    print("Failed to retrieve weather information.")

            time.sleep(300)

        except Exception as e:
            print(f"Fehler: {e}")
            time.sleep(60)

if __name__ == "__main__":
    main()

Teileliste

Die Anzahl der verwendeten Komponenten ist bei diesem Projekt recht überschaubar:

• 1x ESP32-Wroom-32D Entwicklerboard*
• 4x 8×8-RGB-LED-Panel, 5V, WS2812B, ca. 71 x 71 mm** (wie z.B. bei AliExpress)
• 1x Wippschalter I/O, 11×15 mm
• 1x Micro-USB-Board (wie z.B. bei Amazon)
• 1x USB-Netzteil, USB-Anschlusskabel und etwas Litze zur Verkabelung der Matrixen, des Boards, Schalters und des Micro-USB-Boards***
• „ecoPLA Weiß“ von 3DJake für das Gehäuse, Noname schwarzes PLA für das Pixel-Gitter im inneren
• Noname 2-Komponent-Kleber um die Gehäuse-Hälften miteinander zu verbinden

*) Mit großer Wahrscheinlichkeit funktionieren auch ESP-Boards ohne den Zusatz „D“. Ich habe die D-Variante im Video erwähnt, da diese zum einen meines Wissens in der TC001 verbaut ist und somit wohl die größte Kompatibilität gewährleistet ist. Außerdem benötigt euer ESP-Board GPIO-Pins bis 35, zumindest wenn ihr auch Licht- und Temperatursensoren verbauen wollt. Sonst immerhin bis GPIO-Pin 32, denn dort wird die Matrix angeschlossen. Wenn ihr ein Board ohne „D“-Zusatz habt welches aber die benötigten GPIO-Pins mitbringt, könnt ihr im Zweifel einfach „blind“ die Awtrix-Bibliothek flashen. Gelingt die Installation und könnt ihr danach auf das Webinterface zugreifen, so ist die Wahrscheinlichkeit relativ hoch, dass auch der Rest funktionieren sollte.

**) Ich habe genau dieses Modell bestellt, allerdings befürchte ich, dass die Module nicht immer die exakt 100% gleiche Größe haben werden und daher besser oder schlechter in die von mir designte Fassung passen. Es kann sein, dass hier Nacharbeiten eurerseits nötig werden. So fiel mir z.B. bereits auf, das die versprochenen 71 x 71 mm bei meinen Modulen nicht eingehalten werden. Am Ende zählt hier aber jeder Millimeter, da ich keine Abstände zwischen den einzelnen Matrixen haben und das Gehäuse so kompakt wie möglich halten wollte.

***) Ich habe hier ein altes 5W-USB-Netzteil verwendet, was in meinem Fall völlig ausreichend ist. Am Ende sind Stärke der verwendeten Litze sowie des Netzteils von der Frage abhängig, mit welcher Helligkeit ihr die Matrix betreiben möchtet. Je heller, desto mehr Strom muss das Netzteil liefern und die Kabel aushalten können. Ich betreibe das Display mit einer Helligkeit von 20 (Bereich: 0-255), was in meinem Fall völlig ausreicht. Dabei bleibe ich unter den genannten 5 Watt. Wird die Grenze überschritten fangen die LEDs an zuflackern und wahrscheinlich hängt sich das ESP-Board irgendwann auf.

Wichtige Hinweise

Bitte bedenke: 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 oder mehr. 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 keine Expertise besitzt, aber geht clever vor: Informiert euch abseits meines Blogs, lasst eure Errungenschaften nicht unbeaufsichtigt laufen usw. Man lernt nie aus.

Aber worum geht es überhaupt? Für alle denen der WiC64 nichts sagt: Es handelt sich bei der kleinen Platine um eine Erweiterung für den C64, C128, SX64 und VIC20. Das Modul ist derzeit für 35,- Euro zu haben. Ganz ohne Lötkolben kommt man dabei nicht aus, denn der Userport-Stecker muss vom Käufer noch aufgelötet werden. Danach ist das Modul einsatzbereit und man kann loslegen.

Nachdem man die bereitgestellte Software für den Commodore gestartet und sein WLAN konfiguriert hat, stehen einem im Hauptmenü vier Kategorien zur Auswahl: Online Games, Chat and Communication, File Area und Internet. Hier hat man die Möglichkeit, sich in einigen Spielen mittels Highscores online zu messen. Mittels Chat und Messageboard kann man mit anderen Nutzern in Kontakt kommen. Über die File Area lassen sich diverse Apps oder Spiele nutzen. Und in der Internet-Sektion kann man Google Maps auf dem C64 nutzen (ja, wirklich!) oder mittels Telnet auch im Jahre 2023 weltweit alte BBS ansteuern. Das war für mich schon ein besonderes Erlebnis. Auch schön: Über das WiC64 Radio kann man sich SID-Tunes direkt auf den Commodore streamen lassen und in eigenen Playlists verwalten. Oder einfach nur lauschen.

Herzstück des WiC64 ist ein ESP32-Entwicklerboard, was zum einen über den eingebauten Wifi-Chip die Kommunikation mit dem Netzwerk herstellt. Zum anderen kommuniziert es mit dem C64 über den Userport. Die nötige Software findet man auf der Website des Projekts. Sie kann dann ganz normal z.B. über ein SD2IEC-Device geladen werden.

Der WiC64 erweitert den C64 mit der Möglichkeit ins Netz zu kommen um nützliche Funktionen. Dinge wie das Ansteuern der Mailboxen beispielsweise sind natürlich auch mit jedem anderen modernen Modem möglich. Von denen gibt es inzwischen ja eine gewisse Auswahl. Mit dem Portal macht es der WiC64 aber einfach, direkt loszulegen sobald das WLAN einmal eingestellt ist. Somit ist das (abgesehen vom Löten vielleicht) auch durchaus was für Leute, die in all den Jahren im Umgang mit dem C64 etwas eingerostet sind.

Ganz Problemlos ist die Erfahrung aber auch nicht: So hatte ich in meinem Test erst Probleme, den WiC64 mit meinem WLAN zu verbinden. Außerdem liefen nicht alle der Anwendungen immer ganz fehlerfrei. Aber hey, man darf nicht vergessen, dass wir es hier mit einem Projekt einiger Enthusiasten zu tun haben die da viel Herzblut reingesteckt haben. Und ganz ehrlich: Respekt für eure Arbeit!

Mein Video ist ein kleiner Zusammenschnitt der quasi einmal von Anfang an zeigt, wie das Modul in Betrieb genommen wird und was man in den unterschiedlichen Bereichen des Portals so machen kann.

• WiC64.de
• BBS Outpost