Pirozeda-Hat

Nachdem der Pirozeda relativ beliebt ist habe ich ein neues Design erstellt, das ein paar Punkte in Angriff nimmt die mir bis jetzt nicht so gut gefallen haben:

Folgendes ist neu:

  • Entspricht (größtenteils) den Raspberry Pi HAT-Spezifikationen (inkl. EEProm)
  • Neben dem Optokoppler kann man nun auch einen ADUM1301 verwenden
  • …oder einfach Widerstände, wenn man sich der Sache sicher ist
  • Mit ADMUM1301 oder Direktverbindung können nun hardwareseitig einfach Firmware-Updates aufgespielt und der µC resettet werden
  • Am Mikrocontroller gibt es nun zwei Status-LEDs
  • Es gibt nun eine RTC (DS1307Z)

Wer die Design-Daten vorab haben will, kann sich gerne bei mir melden. Sobald sie aufgeräumt sind, kommt natürlich alles auf die Projektseite.

Was noch ganz cool wäre, aber hinsichtlich Platz wahrscheinlich nicht mehr geht: Steckplatz für ein kleines Display und eine Status-LED könnte auch mit dem Pi verbunden sein (um auf ersten Blick den Status der kompletten Verarbeitungskette zu sehen).

AI my ass

Rant.

Künstliche Intelligenz ist in aller Munde und wird trotzdem (oder gerade deshalb) meist missverstanden.

Viel zu oft kommt dann noch Marketing-Bullshit dazu, dann wird mit Begriffen um sich geworfen bis es einem die Haare aufstellt. Früher war etwas supergeil, wenn man „Laser“ dazuschrieb, heute muss es schon mehr sein. Artificial Intelligence, Machine Learning, Deep Learning, Neural Networks und wenn man alle haben will, muss noch Cloud und Blockchain und vielleicht noch Virtual und Augmented Reality dazu.

Und keiner weiß was überhaupt gemeint ist.

Das Von Leitner-Institut für verteiltes Echtzeit-Java titelte bereits:

Machine Learning bedeutet heute, was man früher unter Statistik führte. Wenn du Machine Learning im früheren Sinn meinst, sagst du heute Deep Learning.

Was bedeuten die Begriffe nun wirklich? Ich versuche es mal mit meinem gefährlichen Halbwissen:

Artificial Intelligence oder Künstliche Intelligenz ist einfach nur der Sammelbegriff. Wenn man an Gott Schöpfer glaubt hätte selbst der Mensch Künstliche Intelligenz, weil sie nicht auf natürliche Weise sondern eben durch Fremdeinwirkung geschaffen wurde. Der Begriff sagt nichts darüber aus, ob es sich um eine biologische (gibt es dazu Forschung?), mechanische oder elektronische Implementierung handelt. Auch nichts über Algorithmen und Verfahren.

Machine Learning ist da etwas konkreter: Es ist ein Verfahren auf dem Weg zur Artificial Intelligence. Kurz: man dreht Daten durch einen Algorithmus, der dadurch aus ihnen lernt. Daraus entsteht dann kein „Ich denke, also bin ich“ sondern eine üblicherweise undurchschaubare Datensuppe, mit denen ein weiterer/verwandter Algorithmus von Eingangsdaten, die nur noch Ähnlichkeiten zu den gelernten Daten aufweisen müssen auf die zugehörigen Ergebnisse schließen kann.

Wobei es auch hier verschiedene Möglichkeiten des Lernen gibt, z. B. kann man zu den Daten gewünschte Ergebnisse verknüpfen oder den Algo einfach nur blind lernen (und somit eigene Klassifikationen finden) lassen. Letzteres hat den Charme, dass zum Beispiel unerwartete Zusammenhänge gefunden werden können. Es gibt dazu interessante Vorlesungen IIRC der Caltech auf YouTube.

Deep Learning ist ein Verfahren des Machine Learning.

Neural Networks oder Neuronale Netze sind ein Modell für die Datenverarbeitung, grob kann man Neuronen mit Logikgattern vergleichen. Deren Netzwerke sind analog dazu ein „Gattergrab“.

Cloud ist eine größere Ansammlung von Wassertropfen. In der Informatik sind es die Computer, in aller Regel sehr viele, anderer Menschen von denen man nicht weiß, wo sie geografisch, politisch und in Sachen Datenschutz sowie -sicherheit stehen. ML kann darauf ausgeführt werden, im Endeffekt ist es aber „Sharks with lasers“.

Blockchain ist, soweit ich es verstanden habe, ein kryptographisches Verfahren zum Manipulationsschutz von Informationen, indem diese in Listen und Verschlüsselung verkettet werden. (ja, ich müsste für eine verständliche Definition bei Wikipedia spicken). Der ganze Fuzz um Blockchain in einer Formel: hash_neu = hashfunktion(hash_alt + daten). Hat nichts mit AI/ML/NN zu tun.

VR und AR hat so gut wie nichts mit alledem zu tun.

Man darf sich einfach nicht verarschen lassen, wenn mit Fachbegriffen um sich geworfen wird. Auch wenn man selbst keine Ahnung hat, ist es oft amüsant entlarvend, wenn man die einfache Frage stellt: „Was ist denn der Unterschied zwischen x und y?“

Dann kann man sich oft nur zurücklehnen und genießen.

Für mich ist künstliche Intelligenz übrigens, wenn man dem Computer ein Netzwerkkabel einsteckt und er im Nebenraum das Licht ausschaltet. Oh nein, das richtige Wort lautet Malware.

Wie gut sind COB-LEDs?

Chip on Board-LED-Module – mittlerweile in Flutern sehr weit verbreitet und sehr günstig zu beschaffen.

Da ich bei einer Aufräumaktion eine Schreibtischleuchte (noch mit Leuchtstofflampen und fehlendem Treiber) ergattern konnte war der erste Gedanke: Umrüsten auf LED.

Im Asiamarkt (ok, eBay) gab es 4 Module – 2x warmweiß und 2x kaltweiß – für nicht ganz 6 Euro bei nicht einmal 2 Wochen Versand:

Leider sind Module mit 2700 K Farbtemperatur eher selten, also ca. 3250 K und 6250 K. Aber warum überhaupt verschiedene Werte? Kaltweiß ist besser, um Farben neutral zu sehen, warmweiß ist angenehmer für’s Auge. Allerdings muss man dazu sagen: es ist nur die halbe Wahrheit. Ein wichtiger ist der CRI. Echte weiße LEDs gibt es nicht, es handelt sich in aller Regel um blauen LEDs, die bestimmte Farbstoffe anregen und je nach Material ist das Spektrum und damit die Farbwiedergabe unterschiedlich – aber das nur am Rande.

Um die Spannung und Ströme der Streifen gering zu halten, sind die LEDs in mehrere Stränge, meist mit der Länge 3 angeordnet. Bei einer Flussspannung von 3,2 Volt sind das 9,6 Volt, mit einem Vorwiderstand haben die meisten Streifen eine Betriebsspannung von 12 Volt. Das ist bei den meisten COBs meist nicht der Fall. 4 LEDs in Reihe, mehrere dieser Stränge parallel und fertig. Durch Fertigungstoleranzen schwanken die Vorwärtsspannungen ein bisschen, das kann man im Griff haben aber das kostet natürlich. Bei einigen hundert LEDs für 6 Euro: never ever.

Aber wie schlecht sind sie wirklich? Der Test funktioniert relativ einfach: LED an eine Spannungsquelle anschließen und die Spannung so weit erhöhen, bis sie leicht zu glimmen anfangen – bei den gekauften Exemplaren war das bei 9 Volt:

Montage von 4 Fotos bei gleicher Belichtungszeit

Die Belichtung wurde so eingestellt, dass möglichst keine Übersteuerung der Farbkanäle stattfindet, hat auch fast geklappt.

Man sieht gewisse Ungleichmäßigkeiten, not too bad, not too good either. Richtiges Binning hat auf keinen Fall stattgefunden.

Die Leuchtpunkte der unteren LED wurden ausgeschnitten, ausgerichtet und durch ein kleines Python-Script (mit pillow statt pil) gejagt:

from PIL import Image
im = Image.open('P1120207.png', 'r')
width, height = im.size
pixel_values = list(im.getdata())

y = 8

for x in range(0, width):
px = pixel_values[width*y+x]
print(str(px[0]) + "\t" + str(px[1]) + "\t" + str(px[2]))

Das Script spuckt die RGB-Werte der 8. Zeile aus. Auch wenn der blaue Farbkanal am ehesten heraussticht, ist es besser den grünen zu verwenden – weniger Clipping und durch Chroma-Subsampling (besser kein JPEG verwenden) und des Bayer-Pattern ist grün einfach besser ;).

Aus Excel kam dann folgendes Diagramm:

Mit ein bisschen Phantasie erkennt man die Stranglänge. Die Aussagekraft des Diagramms ist zugegebenermaßen etwas eingeschränkt: Es ist kein kalibriertes System sondern eher ein Schätzeisen aber es reicht für einen groben Vergleich: Es gibt einen ausreißenden Strang (nach oben) und einige LED-Chips in den Stränge, die deutlich darunter liegen. Grundlegend ist die Bewertung mit dem Diagramm aber etwas besser möglich als durch das Ansehen der Bilder, da der Faktor subjektive Wahrnehmung verringert wird und Nuancen in Helligkeitsunterschieden besser erkennbar sind.

Mal sehen, wie sich die Streifen dann im tatsächlichen Einsatz machen…

MCP2221 mit C# – aber schnell.

Nachdem die Python-Lib ganz gut funktioniert (ein paar Bugs habe ich bereits gefunden, Fixes stehen noch aus), wollte ich die Implementierung auch in C# umsetzen. Zwar gibt es von Microchip schon eine Lib, allerdings ist diese nicht Native und auch nicht open source und dadurch auf bestimmte .NET-Versionen eingeschränkt.

Um das Rad nicht neu erfinden zu müssen, wollte ich zumindest für die USB-HID-Kommunikation eine fertige Bibliothek verwenden. Bei der Suche bin ich auf HidLibrary gestoßen, die zwar nicht mehr so aktiv gepflegt wird – aber das muss nicht unbedingt viel bedeuten. Ja, auch Software kann mal fertig sein 😉

Heruntergeladen und die ersten Funktionsblöcke geschrieben. Als ersten Test habe ich i2c_detect portiert und laufen lassen. Für 127 Adressen dauert der Scan knapp über 17 Sekunden. Mit Microships MCP2221 I2C/SMBus Terminal sind es nicht ganz 11 Sekunden und mit meiner Python-Lib unter 0,7 Sekunden. Was ist da los?

Im ersten Schritt habe ich mit System.Diagnostics.Stopwatch die Schreib und Lesezeiten gemessen – jeweils braucht die Lib im Schnitt 21 ms, für jeden Probe einer Adresse sind zwei Schreib-/Lesezyklen erforderlich, kommt kein ACK für eine Adresse ist ein weiterer Zyklus für ein i2c_cancel erforderlich. Macht für einen Proben einer nicht genutzten Adresse ca. 126 ms, für 127 Adressen sind das bisschen über 16 Sekunden – kommt also hin.

Visual Studio kann Performance-Analysen und der schuldige ist schnell gefunden:

Es hängt also am HidLibrary.HidDevice::IsConnected bzw. EnumerateDevices.

Auf GitHub gibt es (Stand November 2018) auch Bugs zum Thema Performance.

Die Tickets existieren seit 2011, 2014 und 2016 – also besteht offenbar kein Interesse, das zu fixen. Ein User namens kaczart hat eine Lösung gefunden.

Um im ersten Schritt nicht zu viel zu verbasteln, habe ich einfach mal „IsConnected“ ein einstweiliges „return true;“ verpasst. Nun benötigt ein Schreibvorgang um die 3,4 ms und ein Lesevorgang knapp 2,3 ms. Unterm Strich dauert der Scan nun 2,5 Sekunden. Besser aber noch nicht gut genug.

In anderen „Projekten“ hat mir in Sachen Timing gerne mal der Debugger in die Suppe gespuckt, also mal als Release ausgeführt und Tadaa: 0,78 Sekunden. Fast so schnell wie die Python-Implementierung.

Um es nochmal genau zu wissen habe das „return true;“ aus HidDevice::IsConnected wieder entfernt und als Release ausgeführt: 14 Sekunden.

Der Hund liegt also definitiv in der Lib begraben. Workaround, Fixen, nach Alternativen suchen oder selber machen (oder einfach eine Weile abhängen lassen und etwas anderes machen)?

Mal sehen.

Was der MCP2221 sonst noch kann

Es gibt Dinge, die Zeit verschwenden, nicht richtig funktionieren und schlussendlich nicht einmal einen Sinn ergeben. Manche nennen das sogar Hobby.

Nachdem mir im Zuge der MCP-USB-Bridges keine Python-Implementierung so richtig gefallen habe, bin ich gerade dabei, selbst eine zu schreiben und mehr oder weniger ausgiebig zu testen.

GPIOs, ADC funktionieren so wie es aussieht genz gut, heute war der DAC dran.
So richtig toll ist er nicht, aber besser als nichts. Um Seine Leidensfähigkeit zu zeigen, musste ein kleines Beispiel her.

Warum nicht einfach so etwas ähnliches wie einen Hellschreiber implementieren? Nur halt extrem ranzig.

In Python geht das ordentlich schnell und einfach:

txt = "Hallo Welt!"

vals = [22,20,18,16,14,12,10,8]

meh = []
for c in txt:
    meh.extend(font[ord(c)-32])
    meh += [0]

for col in meh:
    for reps in range(4):
        curcol = col
        for y in range(8):
            if curcol & 1 == 1:
                dev.dac_setvalue(vals[y])
            else:
                dev.dac_setvalue(0)
            curcol >>= 1
            time.sleep(0.003)

Die Font liegt in als Liste vor, die alle wichtigen Zeichen ab dem Leerzeichen enthält. Vals beinhaltet die Analogwerte der jeweiligen Bits der Zeichen (in der Höhe). Der Text wird sprichwörtlich in eine Bitmap umgewandelt und einfach über den DAC rausgejagt. Damit die Zeichen etwas besser lesbar sind, werden sie 4 mal wiederholt. Die kurze Pause ist nötig, weil sich sonst der MCP verhaspelt.


Ist das nun Kunst oder kann das weg? 😉

Trusted Recursive Resolver

Aus der Kategorie: wir ersetzen etwas kaputtes durch etwas noch viel kaputteres:

DNS soll gegen DNS over HTTPS (kurz DoH, oder eher d’oh) ersetzt werden, so zumindest der Plan von Mozilla. Einmal Fefe, einmal Heise.

Symbolbild:

Ich hab übrigens seit mehreren Monaten einen Blogpost „on hold“, bei dem ich etwas Angst habe ihn zu veröffentlichen, da ich sonst als paranoid dastehen könnte. Titel: „Ein paar unangenehme Prognosen“. Eine davon war (leider zu dem Zeitpunkt nicht aufgeschrieben): „DNS-Anbieter loggen und verwerten Anfragen, verkaufen sie u.a. an die Werbebranche“.

Ein anderer Punkt: „Es kommt das Zeitalter der Tivial-Bugs –
Die root-Lücken in macOS letztes Jahr werden ein Witz dagegen sein. Kategorie: Encryption von Drahtlosnetzen (WiFi/5G/…) und Protokollen wird durch Bug mit dem Niveau eines Bitflips weitestgehend ausgehebelt.“

Ach, übrigens: WPA2 ist so gut wie tot. (ok, war kein Bitflip)

Es muss ziemlich geregnet haben

Warum ist der Boden nass?

Nein, ich hab keine Haustiere, auch zeige ich noch keine Zeichen von Inkontinenz. Trotzdem waren der Basteltisch, Schreibtisch, ein paar Unterlagen und vor allem der Fußboden patschnass. Auch das Dachfenster war geschlossen.

Hilft aber nix, wenn das Dach bzw. der Rollo und dessen „Wartungsklappe“ undicht wird:

Das teurere Zeug hat zum Glück nichts abbekommen. Auch die Backup-Festplatte blieb – wenn auch knapp – trocken. Hier muss ich mir wohl einen etwas besseren Schutz vor Umwelteinflüssen einfallen lassen.

Der PC hatte nur an der Frontblende ein paar Wassertropfen. Trotzdem: Aufschrauben, nachschauen und dabei mal wieder den CPU-Kühler vom Staub befreien. Wenn tatsächlich etwas in die Kiste gelaufen wäre, hätte mein Prinzip „kein Standby-Stromverbrauch“ (der PC + Peripherie werden vom Strom getrennt, wenn ich ihn nicht verwende) vermutlich größere Schäden verhindert.

Wie dem auch sei, zu früh gefreut. Nach dem Einschalten bekomme ich ein Konzert mit Bühnenshow:

Mit usbview, der Knipse und Handyapp im Fernauslöser-Modus (Livebild auf dem Handy) mit Blick auf den Bildschirm hinter den PC gekrochen und probeweise USB-Geräte abgestöpselt. Keine Änderung.

Irgendwann komme ich drauf, dass das Gehäuse ganz unten noch zwei USB-Buchsen hat. An der einen funktioniert der USB-Stick, an der anderen nicht. die funktionierende ist in usbview direkt über der „spinnigen“. Mangels Druckluft in der Mietwohnung (sollte ich jemals bauen, gibt’s neben GbE auch Druckluftkupplungen – zumindest in der Werkstatt, Büro und Wohnzimmer) kommt die Lunge zum Einsatz. Nun macht der PC nur noch beim USB-Stick plüm-plim.

Wie viel es geregnet hat: keine Ahnung. Meine bevorzugte Wetterseite geht nicht weiter als ein paar Stunden zurück und die lokale Wetterstation liegt in unfertigen Einzelteilen auf dem Tisch. Ironischerweise blieb der Regenmesser trocken.

Lehrgeld anderer Art

„Lehrgeld bezahlen“ ist üblicherweise eine Redensart, dass man eine schmerzhafte (und in aller Regel teure) Erfahrung macht. Nicht selten, indem man etwas kaputt macht.

Ich habe nun zweimal (zum Glück nicht allzu teuer) bezahlen „dürfen“ und dabei gelernt. Der Unterschied: wäre ich jeweils nicht so voreilig gewesen, hätte ich Geld gespart (und nicht unnötig etwas herumliegen).

Akt 1: die Handytasche. Da das Handy so gut wie immer in der gleichen Hosentasche wie das Schlüsselbund ist (und um Staub in Buchsen und anderen Öffnungen zu vermeiden, habe ich eine passende Lederhülle. Vorübergehend „hatte“, denn nach dem letzten Wohnungsputz war sie plötzlich wie vom Erdboden verschluckt. Ich hab die ganze Bude mehrfach abgesucht, ohne Erfolg. Nach einer Woche und der vorübergehenden Benutzung einer (frischen!) Socke habe ich zähneknirschend eine neue bestellt.

Sonntag ist bei mir meistens mit einer Runde in der Hängematte verbunden, die die restliche Zeit um einen Balken gebunden ist. Als ich sie wieder aufhing, hatte ich mir am lie Stein in den Hintern gebissen. Keine zwei Stunden nachdem die Bestellung rausging, lag das blöde Ding vor mir. Am so ziemlich einzigen Ort, den ich nicht gecheckt hab. Hmpf.

Akt 2: seit einiger Zeit habe ich CC1101-Module herumliegen, die ich, nachdem sich die nRF-Module als dafür ungeeignet erwiesen haben, für die Wetterstation verwenden möchte. Dank RTL-SDR konnte ich zumindest sehen, dass etwas gesendet wird. Beim Empfänger kam – wenn überhaupt – immer nur Mist an. Das Evaluation Kit für die Module wäre zwar sicher ideal um das Zeug zum Laufen zu bekommen, ist aber für Bastler unverhältnismäßig teuer. Auf der Suche nach einem zum rfsmart Studio kompatiblen Adapter bin ich auf ein Modul von „Novate“ gestoßen. Nachdem nun wirklich viele Versuche erfolglos waren, habe ich bei dem Händler aus Hongkong doch auf „Buy“ geklickt.

Na ratet mal. Keine zwei Stunden später hats mir die FIFO vom Empfänger gefüllt. Verdammte Axt.

Immerhin muss ich jetzt nicht die üblichen 7 bis 20 Tage (oder eher mehr) warten und habe dann etwas, das ich auch mal mit den offiziellen Tools ausprobieren kann. (Update: war nicht mehr lieferbar, somit hat es der Händler storniert – auch ok)

Das waren jetzt nur zwei Beispiele aus einer Woche – kennt ihr dieses Phänomen auch?

Teardown von Trådfri

Eigentlich habe ich mich nur in der Ausfahrt vertan – was bin ich nur für ein Dussel. Weil ich aber schon dort war, habe ich mir etwas mitgenommen: Die billigste verfügbare Lampe mit Funkanbindung (GU10 mit 400 lm, 803.652.70) und einen drahtlosen Dimmer (003.478.31), der eine relativ interessante Funktionsweise hat: Man kann ihn in quasi beliebiger Raumlage drehen (liegend oder an der Wand klebend) – die Halterung braucht man dafür nicht. Daher meine Vermutung: Da muss ein mindestens ein Drehratensensor (Gyroskop) oder gar ein Kompass drin sein.

Der Hauptgrund des Einkaufes war – zumal es in meiner Wohnung keine Leuchten mit GU10-Lampen – eher ein Teardown, da ich online bis jetzt noch nichts finden konnte.

Nimmt man das „User-servicable“ Gehäuse vom Dimmer ab, bekommt man folgendes zu Gesicht (klick macht wie immer groß):

Die Typenbezeichnung ist also neben der Ikea-Nummer ICTC-G-1. Obwohl das Gehäuse den Anschein macht, als wäre es Ultraschall-verschweißt, ist es nur geklipst. „Built to a price“, das Schweißen wäre ein zusätzlicher Produktionsschritt und die Spritzguss muss sowieso ran. Mit einem Schraubendreher lassen sich die Gehäuseteile vorsichtig trennen.

Das Rückteil ist weniger spektakulär – ein Magnet und eine Kontaktfeder für die Batterie. In der anderen Hälfte steckt die „Magie“:

Der Codename für das Leiterkärtchen ist allen Anschein nach „Nebula_1F“. Ich bin kein Trekkie, aber ist das eine Anspielung auf eine Schiffsklasse? Halbwegs futuristisch ist die Bedienung immerhin…

Hirn und Herz ist ein Silabs EFR32 MG1P132GI. Für ein Datenblatt sollte man den Suchbegriff auf „EFR32MG1“ einschränken: „Mighty Gecko Mesh Networking Wireless SoCs for Zigbee and Thread“-Produkt-Familie beim Hersteller.

Leider hört es da auch schon fast auf. der IC rechts unten (mit der Aufschrift „I4BEB2 P10343“) dürfte ein EEProm sein (nachdem der Gecko wohl keinen internen hat), bei den oberen beiden (Aufdruck „S2 636“ und „628“) dürfte es sich vermutlich um Magnetometer und Gyro handeln. Letzteres vermutlich eher links oben, da diese Komponenten meines Wissens etwas höhere Pulsstromaufnahmen (schließlich muss die Mikromechanik angeschubst werden) haben.

Schön an den Geckos ist, dass man die Pins ziemlich komfortabel auf die gewünschten Funktionen routen kann, für’s Reverse Engineering ist das allerdings nicht so ganz schön.

Wenn man die Leiterbahnen etwas verfolgt erkennt man, dass es die Leiterkarte mehr als 2 Lagen hat, halbwegs erstaunlich, bei der vergleichsweise geringen Komplexität. Bei der Leiterkartenproduktion wurde das aber wieder reingeholt: Die Leiterkarte ist gestanzt statt gefräst und das Material sieht eher billig als günstig aus. Immerhin sind die Kontakte vergoldet und es wurden einige Testpunkte spendiert – da wird sicher ein I²C dabei sein.

Objekt 2 ist, wie oben geschrieben, eine GU10-Lampe:

Der Deckel bzw. die Optik geht erstaunlich leicht runter, Innen sieht es erstaunlich unspektakulär aus:

Ein herumflatterndes Kupferfähnchen? Sieht nach einem late fix zum Bestehen der EMV-Prüfungen aus. Das LED-Modul hat keine Wärmeleitpaste im Rücken und die leicht verklebte Metallplatte lässt sich mit sanfter Gewalt (mit dem Schraubendreher am Schraubloch hebeln) herausnehmen. Dahinter begrüßt einen die Elektronik – oder zumindest das Funkmodul.

Es sieht besser aus als es ist. Ich bin mir nicht sicher, ob das Shielding seinen Namen verdient hat, es wackelt wie ein Kuhschwanz. Eine saubere elektromechanische Verbindung sieht auf jeden Fall anders aus. Ein bisschen mehr hebeln und das Innere erblickt das Tageslicht:

Das Silabs-Logo lässt sich erahnen, links unten sitzt auch ein „alter Bekannter“. Bin mir ziemlich sicher, dass es sich hier um einen EEProm handelt. Im Bild sieht man auch, dass das Modul by design eher bescheiden eingelötet ist: unter der linken Kante sitzt ein SMD-Widerstand, unter der rechten nicht. Da man sowas maschinell nicht vernünftig gelötet bekommt: Messer rein, Gedärme raus. Natürlich: Modul rein, Lötzinn-Raupe drüber.

Mit ein bisschen Zug kommt auch das Netzteil + Controller raus. Es ist hinten nicht verlötet und sieht von oben zwar sehr eng gepackt aber dennoch halbwegs ok-ish aus:

Von unten sollte man es – zumindest wenn man Elektroniker ist und einen schwachen Magen hat – besser nicht ansehen. Verdammt viele Handlötungen, mehr Lötzinn als mir lieb ist und noch mehr ekelhafte Flussmittelrückstände:

Der 5-Beiner oben ist mit ZR7IB beschriftet (kein Datenblatt auffindbar). Das Beuteil im SO-8-Gehäuse heißt BEH7JB (auch nix zu finden). Die Qualität dieser Leiterkarte ist leider nicht wirklich rühmlich.

Einen High-Pot-Test würde ich angesichts solcher Lötstellen nicht unbedingt machen:

Chirp mag keine Staunässe

Eine längere Zeit überwachten Chirp zwei meiner Topfpflanzen.

Nachdem Topf 2 deutlich größer (und vor allem tiefer) ist, zirpte der Sensor sehr früh, weshalb ich nach dem Prinzip „aus zwei mach eins“ die Sensorfläche deutlich vergrößerte.

Funktionierte etwas besser aber nicht ganz so gut wie erhofft. Dazu kommt, dass die Pflanze an einem eher schattigen Plätzchen steht, wodurch eher geblinkt als gezirpt wurde.

Irgendwann war ich dann mal im Urlaub und Mutti hat das Gießen übernommen und anscheinend (vielleicht war’s auch ich) die Elektronik mitgewässert.

Also: gar kein Zirpen/Blinken mehr, also wieder nach Gefühl (viel zu viel) gegossen aber den Sensor in der Erde gelassen. Irgendwann hab ich ihn dann doch herausgezogen und dann war auch klar, warum das Teil nicht mehr funktioniert:

Der Grund für die zwei Flachbandkabel: das eine – klar – das Programmierinterface (das hier auch für die Stromversorgung mit zwei AA-Zellen verwendet wurde), das andere zu einem NR24L01+-Modul. Ja, die Chirps haben funken gelernt, sind aber noch nicht in einem Zustand, in dem ich es veröffentlichen möchte.

Am Batterieclip lag die ganze Zeit Spannung an und dementsprechend ist das Teil sprichwörtlich abgefault:

Auch auf der anderen Seite haben sich an der Stromversorgung Kristalle gebildet:

Leider war ich in Chemie nie ’ne Leuchte, könnte also nicht sagen was zu was reagiert hat.

Erstaunlicherweise hat sich der Lötstopplack so ziemlich nur auf dem Kupfer gelöst:

Das Kupfer darunter war noch erstaunlich blank:

Trotzdem, da muss ich mir überlegen, wie das Teil besser vor dem Milieu im Blumentopf geschützt werden kann.

Deckel über die Elektronik geht nicht, wegen der LED a. k. a. Lichtsensor, Coating geht auch nicht, weil sonst die Batterie nicht mehr getauscht werden kann.

Für die Sensorfläche wäre die Frage: Welcher Lack ist naturverträglich und hat möglichst wenig Einfluss auf die kapazitive Messung? Hmm.