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.

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

Das erste iPhone war in sofern besonders, als das es auf eine Eingabehilfe wie den Stylus verzichtete. Stattdessen wurde das kleine Telefon über einen die Vorderseite füllenden Bildschirm einfach mit den Fingern bedient. Ein Stylus, welchen Steve Jobs in seiner PK mit einem „yaachh“ und der Frage „Who wants a Stylus?“ abtat, war nicht mehr nötig. Es dauerte noch bis zum November, als es dann auch hierzulande endlich verfügbar wurde. Exklusiv bei der Telekom die als erstes ihr 2G-Netzwerk um EDGE erweiterte hatte. Damit waren Übertragungsgeschwindigkeiten von 150-200 kbit/s möglich – so Wikipedia.

Was die Eingabemöglichkeiten anging war T-Mobiles MDA Vario III welcher von HTC produziert und außerhalb Deutschlands auch unter dem Namen HTC Kaiser oder HTC TyTN II bekannt war lange nicht so ausgereift wie das iPhone. Verstecken brauchte sich das Gerät zu seiner Zeit aber nicht, zumindest wenn man die blosen technischen Daten gegenüberstellt. So war Unterstützung für das teils noch in Aufbau befindliche 3G-Netz, also UMTS vorhanden. Sogar mit dem Downloadbeschleuniger HSDPA, welchen das HTC bis 3,6 Mbit/s unterstützte. Auch die verbaute Kamera war mit 3 Megapixel ein ganzes Megapixel besser als die des iPhones. Und, anders als dieses, hatte der MDA auch eine Frontkamera.

Das Display konnte hochgeschubst werden, darunter verbarg sich eine vollwertige kleine QWERTZ-Tastatur. Etwas, was sich so mancher heute vermutlich wieder wünschen würde. Mit einer mit 400 MHz betriebenen Qualcomm-CPU mit ARM-Befehlssatz war das Gerät auch gar nicht schlecht ausgestattet. Aber: Wirklich gezielt steuern lies sich das installierte Windows Mobile 6 dann leider doch nur mit „yaachh“-Stylus. Und wieviel „Spaß“ Windows Mobile damals gemacht hat, da muss sich vermutlich jeder selbst sein eigenes Bild von machen. Es ist eben ein „kleines“ Windows, welches für die mobile Nutzung aus heutiger Sicht hier und da doch etwas umständlich zu bedienen war.

So oder so: Spannende Zeiten waren das damals. War interessant dabei gewesen zu sein, als nach und nach Innovationen an unterschiedlichen Stellen auftaten, die Nutzererlebnis teils grundlegend änderten oder zumindest (oft) sinnvoll erweiterten. Aber es ist auch schön das wir heute an so mancher Stelle technisch schon ein bisschen weiter sind. In meinem (etwas länger gewordenen) Video zeige ich euch T-Mobiles MDA Vario III relativ ausführlich und wir versuchen in der Jetzt-Zeit in der es kein UMTS-Netz mehr gibt, mit dem MDA ins Internet zu gehen. Kann das klappen? Schaut es euch an!

So habe ich auch mit einer günstigen Kamera angefangen, konkret einer Nulaxy C900. Circa 30 Euro hat die Gute damals gekostet. Die Qualität fand ich anfangs auch ganz in Ordnung: Zusammen mit einem guten Freund habe ich auf Twitch gestreamt. Dabei waren wir beide nur klein zu sehen und der Hintergrund war mittels Software-Key entfernt. Funktionierte eigentlich ganz gut.

Für meinen Kram auf YouTube – insbesondere die Five Minutes of Lame – würde ich aber jetzt gerne etwas an der Qualität schrauben. Also habe ich jetzt, ein halbes Jahr später, nochmal was tiefer in die Tasche gegriffen und mir eine Logitech BRIO gegönnt.

In diesem Video berichte ich nun über meine ersten Erfahrungen und versuche, die beiden Kameras in drei Szenarien miteinander zu vergleichen: Beim „Putzlicht“-Test verwende ich nur die Raumbeleuchtung und schaue, wie die beiden Kameras mit den ungünstigen Lichtverhältnissen klarkommen. Im zweiten Szenario baue ich einen Greenscreen auf und versuche, mich in eine virtuelle Szene zu setzen. Und zuletzt folgt eine Abmoderation mit mehr oder weniger vernünftigem Licht.

Wie tief muss man in die Tasche greifen, um Videos für YouTube oder Twitch mit brauchbarer Qualität zu produzieren?