Teardown von Trådfri

Nachtrag 18.03.2019: Dieser Blogeintrag wurde mit mehr Details ins Wiki übernommen.

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.

Seid vorsichtig!

Es ist verdammt kalt draußen. Am 27.02.2018 um 20:40 Uhr zeigt das Thermometer -13 °C. Es ist verdammt trockene Kälte. Die Heizungen und Klimaanlagen leisten zusätzlich noch ihren Beitrag. In meinem „Empire of dirt“/“Nerdcave“ herrschen 19 % relative Luftfeuchte, so man dem Hygrometer überhaupt noch trauen kann. In der Arbeit waren es heute morgen (gleicher Sensor und Disclaimer) 17 % rH. Dank ESD-Schlappen und leicht ableitenden Böden hat es dort nie gebritzelt. Es wäre mitunter teuer wenn doch. Nur die Schleimhäute und Hände leiden massiv unter der extrem trockenen Luft.

Daheim habe ich aufgehört, die Entladungen zu zählen. Auch wenn momentan leider keine Zeit zum Basteln bleibt (zum Glück habe ich im vorletzten Beitrag kein Datum versprochen), musste ich nackte Elektronik anfassen und habe mich dementsprechend oft und gezielt entladen. Obwohl mein Kleiderschrank nur sehr wenige Kleidungsstücke mit Neigung zur Ladungstrennung beinhaltet, hat es bei fast jeder Berührung geknackt.

Daher kann ich nur raten: Seid aktuell vorsichtig beim Basteln! Macht nichts kaputt und ärgert euch so richtig, wenn es doch passiert. Ich hab euch gewarnt 🙂

Die Anschaffung einer ESD-Matte kann kann günstiger sein, als das was man im Zweifel kaputt macht und schont gleichzeitig den Tisch.

Es geht weiter

Zugegebenermaßen: es passiert hier so wenig, dass man in Hinblick auf den vorletzten Post schon fast von falschen Versprechen ausgehen könnte. Aber: Es passiert nicht nichts, es geht einfach nur verdammt langsam voran. (warum muss ich nur an das Zitat „es ist nicht undicht, es läuft über“ denken…?)

Um zu zeigen, dass es nicht ganz Schall und Rauch ist:

Aber das ist nicht alles. Bis wann die Software und der zugehörige Artikel fertig ist, kann ich noch nicht versprechen. Ein paar Wochen halte ich für realistisch 🙂

Das „Custom Programming Tool“ in Atmel Studio

Schon länger gibt es in Atmel Studio die Möglichkeit, ein eigenes Programming tool zu verwenden:

Hat mich bis jetzt nie wirklich interessiert, da ich entweder über einen in-circuit-Programmer (der direkt unterstützt wird) flashe oder FastBoot manuell startete.

Zu viele Klicks bzw. Tastaturakrobatik. Also doch mal mit dem bereits Vorhandenem spielen.

echo „foo“ macht was es soll:

Prima, also kann ich einfach die burn.bat im Projektverzeichnis einfügen und los geht’s!

Nope. Da passt wohl das Arbeitsverzeichnis nicht. Aber wie kommt man ins aktuelle Projektverzeichnis? Zunächst versuchte ich mich an den Platzhalter der „External Tools“. Allerdings wurde „$(ProjectDir)“ zu leer ersetzt.

Hmpf. Für die Buildautomatisierung gibt es noch die Build Events – klickt man dort auf „Edit #-build …“ und dann auf Show Macros, bekommt man eine längere Liste an Platzhaltern:

echo „$(MSBuildProjectDirectory)“ zeigt das aktuelle Projektverzeichnis 🙂

also schnell „$(MSBuildProjectDirectory)\burn.bat“ eingegeben und ab dafür!

Jaa-eein. Die Batch-Datei wird zwar ausgeführt, aber im falschen Arbeitsverzeichnis. Mist.

Eine kurze Suche bei Stack Overflow lässt in das richtige Verzeichnis wechseln:

cmd /k pushd $(MSBuildProjectDirectory) & burn.bat

It verks!!1!

Jetzt steht in der dämlichen Batchdatei halt noch der feste Pfad zum Binary und es wird immer die Debug-Config über den UART geschoben. Ein bisschen mehr Makro-Magic und ein %1 an der richtigen Stelle (die zu flashende Datei) mit folgendem Command erledigt den Job:

cmd /k pushd $(MSBuildProjectDirectory) & burn.bat „$(Configuration)\$(OutputFileName).hex“

Da in der burn.bat in meinem Fall eh nicht mehr als ein Aufruf von fboot.exe ist, kann die Batch-Datei auch komplett weggelassen werden:

cmd /k pushd $(MSBuildProjectDirectory) & fboot /B57600 /C1 /P“$(Configuration)\$(OutputFileName).hex“

Jetzt müsste man nur noch die Ausgabe des Build und des Custom programming tool gleichzeitig anzeigen können, dann wäre ich richtig happy 😉

PS: Bitte beim Copy & Paste der Befehle die Anführungszeichen manuell ersetzen, WordPress macht sie typografisch korrekt aber funktional kaputt.

Es bewegt sich was

Aber leider etwas langsam.

Ich hab aktuell ein paar Baustellen offen. Zum einen bin ich daran, ein Reverse Engineering an einem Autoradio durchzuführen, um Fehler – die der Hersteller tunlichst nicht fixen will – zu beseitigen. So gut wie alle relevanten Teile des Schaltplans sind rekonstruiert, dabei wurden sogar noch ein paar Designfehler entdeckt.

Leider blockt mich gerade ein wenig die Tatsache, dass die meisten Datenblätter unter NDA liegen und die I2C-Kommunikation zwischen Application Processor und Audioprozessor nicht ganz trivial ist.

Baustelle 2 ist beim Prozeda-Decoder. Nachdem die Anfrage reinkam, ob das auch mit einem Raspberry Pi funktioniert, dachte ich mir: Warum auch nicht? Mit echter Hardware auf dem Tisch, die mir freundlicherweise von einem Besucher bereitgestellt wurde, konnte ich mir ein paar Dinge nochmal genauer ansehen. Es gab auf jeden Fall einen Erkenntnisgewinn, jetzt muss ich es „nur noch“ dokumentieren.

Für den Minichirp gibt es hoffentlich auch bald ein Update, nachdem die ersten Versuche an der Hard- und Software vielversprechend sind. Nur so viel: der aktuelle Projektname lauter „ChirpRF“.

Als ob das nicht schon genug wäre, möchte ich jetzt endlich diese verdammte Wetterstation angehen, nachdem es im Sommer an den nRF-Modulen bzw. deren Durchdringung gescheitert ist, soll es jetzt ein CC1101 richten. Um mit diesem und den Sensoren schneller zu Rande zu kommen, gibt es zusätzlich Randprojekte: USB auf I2C und SPI. Das allerdings mit den Wandlerchips von Microchip, zu denen ich eine gewisse Hassliebe pflege. Beide funktionieren (irgendwie), es fehlt aber auch hier noch die Doku.

Es wird also nicht langweilig. Bis dahin für euch leider mal wieder Warteschleifenmusik…

…und er loggt doch.

Nachdem ich gestern nun die Dose des Neo geöffnet habe, gab es nichts mehr zu verlieren.

Da die Leiterbahn zum (de-)aktivieren des externen Flashs auch unter dem GNSS-Chip mit Masse verbunden ist, muss der erst einmal runter. Ich habe zwar schon einen BGA mit knapp 1200 Balls und extremer thermischer Masse erfolgreich getauscht, allerdings mit entsprechendem Equipment. Bei Tausch von kleinen QFNs habe ich mich bis jetzt aber erstaunlich blöd angestellt. Entweder zu viel Flussmittel oder zu viel Lötzinn. Dabei tanzt der Chip beim Erhitzen lustig vor sich hin, senkt sich aber nicht richtig ab. Dann ist ein Re-Rework fällig. Schlecht fürs Material aber meistens klappt es.

Aber zuerst muss der IC runter. Mit Heißluft bei etwa 380-400 °C und niedrigem Luftstrom (damit es keine anderen Bauteile wegpustet) um die Bauteile kreisen um die Komponenten nicht zu schnell zu erwärmen. Kurz nachdem das noch vorhandene Flussmittel verflüssigt, sieht man auch eine leichte Glanzveränderung am Lötzinn – der „sweet spot“ zum Herunterpicken der Bauteile ist kurz danach.

Nach etwas Geduld zum Abkühlen der Leiterkarte sieht man, dass nur ein einziger verdammter Pin mit der Massefläche verbunden ist. Man muss nicht raten, welcher das ist:

Mit etwas Flussmittel und Entlötlitze kommt das bleifreie Zeug zunächst runter, um es anschließend mit einer dünnen Neuauflage Sn60Pb40 zu ersetzen. Dabei habe ich den Pads außenherum mehr Zinn gegeben als der Massefläche unter dem Chip. Natürlich darf das Auftrennen der Masseverbindung zu Pin 29 nicht fehlen. Wer den Unterschied zwischen bleifrei und bleihaltig nicht kennt: Bildvergleich – bleifrei (oben) ist ziemlich matt, bleihaltig glänzt deutlich stärker:

Zwischen dem Verzinnen und wieder Bestreichen mit Flussmittel einmal mit Isopropanol waschen – Beim Ent-, Ver- und wieder Entzinnen entsteht Zunder und manchmal backt das Flux fest – das will man nicht unter Bauteilen haben. Anschließend ist der Chip dran, der ebenfalls vom Bleifrei-Lot befreit wird. Mit dopptelseitigem Klebeband auf dem Tisch bleibt er auch nicht am Lötkolben hängen.

Hier im Prozess: vertrocknetes Flux und noch nicht ganz verzinnte Pins. kleine Zinnkleckse auf der Massefläche (hier rechts oben) sollten entfernt werden, da sie den Lötprozess stören.

Nun kann der IC wieder platziert und verlötet werden. Wieder mit Heißluft mit wenig Pust und schön warm. Das Ergebnis ist gut aber nicht perfekt – der Käfer ist etwas verschoben, was aber kein Problem sein sollte:

Um vorab zu testen ob der Empfänger noch funktioniert, habe ich Pin 29 wieder gebrückt und das Modul mit Strombegrenzung (!) an den PC angeschlossen. Alles kommt hoch und nach ein paar Minuten habe ich einen GPS-Fix. Zu Glonass-Empfang lässt sich das Teil aber nicht bewegen, vielleicht aufgrund des fehlenden Shieldings?! 😉

Ok, Grundlegend funktioniert es also, aber wird der Empfänger auch mit externem Flash spielen? Ich konnte einen QSPI-Flash von Winbond ergattern. Mal schauen, ob es funktioniert.

Laut Hardware Integration Manual des UBX-G7020 (!) ist die Anschlussbelegung wie folgt (ob sie auch mit dem M8030 funktioniert?):

  • PIO0 (25) -> DI/IO0
  • PIO4 (26) -> CLK
  • PIO2 (27) -> !WP/IO2
  • PIO1 (28) -> DO/IO1
  • PIO5 (29) -> !CS
  • PIO3 (30) -> !HOLD/!RESET/IO3

GND sollte klar sein, Vcc habe ich aus Ermangelung anderslautender Tatsachen einfach an die Versorgung des Chipsatzes geklemmt.

Wieder ans Netzteil mit Strombegrenzung geklemmt: Keine Auffälligkeiten – was aber noch nicht heißt, dass es auch funktioniert. Die Wahrheit erfährt man erst, wenn man den Speicher nutzen kann, also ran an den PC und u-center wieder öffnen. Die Firmware findet sich – im Gegensatz des vollen Datenblatts – auf der Website von u-blox. Nach Anstoßen des  Updates und nicht ganz einer dreiviertel Minute warten liegt schon fast ein NEO-M8N auf dem Tisch (wären da nicht die Fädeldrähte):

Nun funktioniert auch das Logging – Mission accomplished! 🙂

u from the blox

Ich wollte schon immer mal mit GNSS-Modulen von u-blox arbeiten. Mittlerweile liegen auch ein paar Module herum. Beim „aktuellsten“ sollte es ein NEO-M8N werden, hauptsächlich, weil es relativ stromsparend in den internen Flash loggen kann und auch ansonsten relativ viel zu bieten hat.

Da die Module zwar direkt vom Hersteller erhältlich, in kleinen Stückzahlen aber sehr teuer sind, ein Blick auf eBay. Mit Antenne, kleiner Leiterkarte und und Versand mit dem Namen „GY-GPSV3-NEO“ gibt es sie schon für um die 12 Euro, also her damit! Bis es der Empfänger aus China hierher geschafft hat dauert zwar 4-8 Wochen, ohne besonderen Leidensdruck kann man das aber gut abwarten.

Packung auf und mit einem USB<>UART-Adapter an den PC – nach kurzer Zeit gibt es einen Fix und ich kann zusehen, wie die Position im Umkreis von ein paar Metern umher eiert, so weit, so gut.

Als ich in u-center (der Software zum Testen und Konfigurieren der Empfänger) Logging testen wollte passierte – nichts.

Ok, vielleicht ist eine alte Firmware drauf. Es gibt eine neuere, diese lässt sich aber nicht flashen, auch mit verschiedenen Einstellungen. Hmpf. Bin ich einem Fake aufgelaufen?

Wie sich herausstellt: ja!

Schaut man sich das Label auf dem Modul an, fällt auf, dass das Firmenlogo ausgefranst und alle runden Symbole nicht wirklich rund sind. Die Schrift passt ebenfalls nicht. Hmm, warum hat das Modul auf der eBay-Seite eigentlich die genau gleiche Seriennummer? Ist das die Nummer für die gesamte Serie?!? Klickt man sich durch die Google-Bildersuche sticht ins Auge, dass alle Module eine Datamatrix haben. Mein Modul dagegen hat einen QR-Code. Was steht da eigentlich drin? Kurz mit dem Handy gescannt: „NEO-6M-0-0001 […]“ – ich dachte, das wäre ein M8N? Nanu? Gibt man dem Modul Strom, nachdem es per UART am PC angeschlossen ist, bekommt man Infos vom Bootloader. Dort steht wiederum M8:

$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
$GNTXT,01,01,02,HW UBX-M80xx 00080000 *43
$GNTXT,01,01,02,ROM CORE 2.01 (75331) Oct 29 2013 13:28:17*4A
$GNTXT,01,01,02,PROTVER 15.00*01

eBay-Käuferschutz zum Glück bekomme ich, nachdem mich der Händler dann doch nochmal versucht abzuziehen („Bitte den Fall schließen, damit wir das Geld auszahlen können“ – ja ne, is klar), kam das Geld zurück. Aber was nun mit dem Modul? Richtig nutzlos ist es nicht, aber doch irgendwie – weil es eben die Funktionen, für die ich es gekauft habe, nicht kann.

Aber wenn da schon ein M8 drin ist, dann sollte das doch grundsätzlich funktionieren. Gleichzeitig wäre auch interessant, was da überhaupt drin ist. Im Forum von u-blox konnte ich zumindest ein Foto mit Original und Fälschung finden. Auf dem Original sitzt ein 25Q16DV (QSPI-Flash) von Winbond, auf dem Fake nicht.

Also runter mit dem Kopf! Aber bitte so, dass es danach noch funktioniert.

Hier mal eine kleine und überaus dilettantische Collage des Shieldings von allen vier Seiten:

Am gleichmäßigsten geht es wohl runter, wenn man alles mit Heißluft erwärmt und dann den Blechdeckel abhebt. Bei meinen Fähigkeiten rutscht es in der Regel aber erst mal zur Seite und nimmt ein paar SMD-Komponenten bei denen man nie wieder herausfindet, wie sie mal drauf waren.

Nachdem das Shielding nur an ein paar Punkten aufgelötet ist, geht es auch mit dem Lötkolben. Lötzinn als Wärmebrücke auf das Blech, Schraubendreher in den Spalt einklemmen und anschließend erhitzen und vorsichtig hebeln. Leider lässt sich die Leiterkarte erstaunlich leicht delaminieren, hat es aber augenscheinlich ganz gut überstanden:

Kein Flash. In den Unweiten des Internets lässt sich keine Pinbelegung des M8030-KT finden. Wohl aber des Vorgängers G7020 (im Hardware Integration Manual, um zumindest ein Suchwort zu geben). Die Chips gleichen sich der Beschaltung ziemlich stark – warum sollte man auch ein bestehendes – durchaus komplexes – Design ohne Not ändern?

Wie auch immer, Pin 25-30 (rechts oben am Chip im Bild) sind IOs und werden – zumindest beim 7020er – für externen Speicher genutzt. Pin 29 definiert, wenn auf GND gezogen, dass nur der interne ROM verwendet wird. Die 3 Pins darunter legen in dieser Konstellation ein paar Konfigurationen fest. Das Bild im u-blox-Forum korreliert zumindest soweit man es erahnen kann mit dieser Information. Wäre nicht dieser dämliche Pin 29 mit der Massefläche verbunden. Bleibt zu hoffen, dass er das nur von außen und nicht auch von hinten ist. Ich befürchte aber, …

Ein Schnitt mit dem Skalpell später und „pieeep“ sagt das Multimeter – meh. 🙁

Ende für Teil 1.

Kein Funk ist auch keine Lösung

Die nRF24L01P sind beliebt und günstig, weshalb hier seit längerem auch ein paar Module mit den Chips herumliegen.

Getrieben durch das Vorhaben eine Wetterstation zu bauen habe ich zwei jeweils an einen Mikrocontroller gehängt.

Nachdem die Übertragung (endlich) funktionierte, ging es daran die Reichweite zu testen. Im ersten Einfach-Programm ließ ich im Sender jede Sekunde ein Paket mit Counter und den Werten des bereits angedengelten Luftfeuchte- und Temperatursensor senden.

Auf der Gegenseite lediglich eine LED, die bei jedem empfangenen Paket toggelt. Bei 1 Mbit/s und 0 dBm war schon im Treppenhaus schluss, ich hoffte aber noch, dass es im Garten noch bzw. wieder klappt, da quasi Sichtkontakt besteht. Nichts. Grmpf.

Laut Datenblatt gewinnt man mit 250 kbit/s gegenüber 1 Mbit/s 9 dB an Sensitivity, was ein wenig Quell der Hoffnung war. Leider hat das auch nicht so wirklich geklappt.

Um zumindest einen Erkenntnisgewinn zu haben, ging es in den Park nebenan um dort auszuloten, wie weit es überhaupt geht. Im ersten Versuch schaffte ich knapp 190 Meter im freien Feld und bei gut aufeinander ausgerichteten Antennen. Ohne Ausrichtung war bei etwa 70 Meter gerade noch zuverlässiger Empfang möglich.

Allerdings hatte ich keine Information, wie oft tatsächlich übertragen werden musste, um Daten von A nach B zu bekommen. Schließlich verwenden die Module Handshaking mit Retransmission. Eine Anzeige musste her. Also schnell das alte und zerkratzte Nokia-Display ausgegraben und angeschlossen. Der eingestaubte Code funktionierte auch fast auf Anhieb.

Da der Empfänger von sich aus nicht wissen kann, wie viele erfolglose Übertragungen es gab werden die Werte im Sender kumuliert in den Sendepuffer geschrieben und nach einer erfolgreichen Übertragung wieder zurückgesetzt. Auf dem Display sieht es dann wie folgt aus:

Ob es wirklich sinnvoll ist, die Temperatur und Luftfeuchtigkeit darzustellen, sei mal dahingestellt, aber warum wegwerfen, was der Sensor hergibt?

Neuer Tag, neues Glück? Mitnichten. Vielleicht lag es am Wetter, vielleicht an der Verdeckung durch Parkbesucher oder am Display – die Reichweite war niedriger. Zuverlässige Datenübertragung ohne Antennenausrichtung war bis knapp 55 Meter möglich, mit (und mit etwas Glück) etwa 85 Meter.

Die Verbindung zwischen geplanten Aufstellorten von Sender und Empfänger war nach wie vor nicht möglich.

Nächste Schritte? Am liebsten würde ich die nRF-Module verwenden. Die Software läuft und die Hardware ist schon da. Interessant wäre, wie sich die Antennen verbessern ließen. Ohne eine vernünftige Möglichkeit, die abgestrahlte Leistung oder das Stehwellenverhältnis zu messen wird es schwierig. Durch den Park laufen tut zwar gut ist aber nicht so richtig vergleichbar. Messequipment für solch einen Zweck zu kaufen steht in keiner Relation. Vielleicht muss ich mal mit ein paar bekannten HAMs reden.

Piep

Meine Mutter hat einen Vogel. Also jetzt keinen mit Federn und so und er bzw. sie – weil es gleich zwei sind – gehen so ziemlich allen außer ihr so ziemlich auf die Nerven.

Nein, natürlich nicht wie ihr meint. Das hier ist gemeint:

vogel1

Sobald man dem Teil vorbeigeht, fängt es an zu zwitschern. Sehr laut und vor allem sehr lang. Naja, wenn nicht gerade die Batterien wieder leer sind. Obwohl der Vogel relativ groß ist, enttäuscht das Batteriefach:

vogel_batteriefach1

Zweimal LR44. Laut Wikipedia haben die stolze 145 mAh. Das Geflügel könnte locker zwei AAA-Zellen aufnehmen, immerhin mit ca. 1200 mAh nicht mehr so ganz un-ökologisch wie die Knopfzellen.

Nachdem AA-Zellen herumliegen und knapp doppelt so viel Energie fassen, sollten es diese werden. Also dem Tier eine Leine verpasst…:

vogel_batteriefach2

…und Batterien gelötet:

vogel_batterie

Batterien löten? Ja, das macht man nicht. Auf einer Skala zwischen Dumm und Ar…blöd ist es außerhalb der Skala bei: „Wie bescheuert kann man überhaupt sein?“ – Batterien mögen keine Hitze, schon gar nichts über 300 °C. Beim Löten können sie allerhand Unsinn machen – deswegen werden sie wenn dann mit Punktschweißen mit Leitern verbunden. Da wirkt die Hitze so kurz, dass sie gar nicht so richtig in die Zelle eindringen kann. Aber selbst das kann ordentlich schief gehen. Trotzdem habe ich es getan. Grund: Dummheit, einige Jahre Löterfahrung und eine geregelte Lötstation mit ordentlich Leistung und einer geeigneten Lötspitze. Die Lötdauer war etwa eine Sekunde und dadurch nicht ganz so „heiß“. Gut ist es aber trotzdem nicht.

Abschließend wurde das Akkupack noch in ordentlich Isolierband eingewickelt – das hässliche braune:

vogel2

Jetzt kann der Piepmatz wieder eine Weile schreien – mein Vorschlag, das Innenleben zu ersetzen und vernünftige Sounds zu verwenden fand leider wenig Anklang.