In diesem Post zeige ich die ersten voll aufgebauten Lichtschrankenadapter für das Mobile Cassy.

Alle Daten zum Nachbauen sind bei Github verfügbar.

Errata

Zwischen der hier gezeigten Platine und der im github repository verfügbaren bestehen folgende Unterschiede:

• die Bezeichnung der Steckbuchsen J4/J5 ist zwischen beiden Board-Varianten unterschiedlich
• der Kondensator C2 ist falsch gepolt

Platinen

Hier sieht man beide Platinen-Varianten wie sie von JLCPCB geliefert wurden.

Bauteile

Die benötigten Bauteilen sind hier aufgelistet (Reichelt-Bestellnummern dienen nur als Beispiel):

Für die Steckverbinder kann man entweder das selbst zuzuschneidene Messingrohr (günstig aber aufwändig) oder die fertigen Buchsen nehmen.

Aufbau

Zuerst werden die drei SMD-Bauteile bestückt. Dabei ist der ESD-Schutz-Chip USBLC6 der schwierigste, weil er nur im SOT23-6-Formfaktor von Reichelt erhältlich ist.

Die beiden Entkopplugskondensatoren C1 (für USBLC6) und C3 (für ATTiny) sind hingegen recht einfach zu verlöten, da sie im 1206 Formfaktor vorgesehen sind.

Der ATTiny wird idealerweise in einen Sockel gesetzt, was das spätere Austauschen und neu programmieren erleichtert. Er kann aber auch direkt verlötet werden und sitzt dann auf C3 auf.

Oben sieht man gut den unter dem Sockel eingesetzten Kondensator.

Oben sieht man die Vertauschung von J5 und J4

Die weiteren Komponenten werden wie üblich eingesetzt und verlötet. Bei der Variante mit den Messingbuchsen hilft es, diese vorher mit einem kleinen Gasbrenner (z.B. Flambiergerät) vorzuwärmen, dann lassen sie sich leichter verlöten. Das Ausrichten der Messingbuchsen fällt tatsächlich schwer, gegebenfalls kann man sich eine kleine Ausrichthilfe per 3D-Druck erstellen.

Beim zuschneiden der Messingrohre (Innendurchmesser 4mm, Wandstärke 0,5mm) hilft ein einfacher Rohrschneider:

Programmierung

Programmiert wird der ATtiny mithilfe eines Arduino Uno. Schrittfolge:

• Zur Arduino IDE fügt man ATTinyCore als Board-Manager hinzu
• Aus dem Beispielbereich der Arduino IDE lädt man den ISP-Sketch auf den Uno
• Anschließend verbindet man den Arduino mit dem ATtiny (Details siehe Github)
• Der ATtiny wird mit “Bootloader brennen” vorbereitet (setzen der E-Fuses)
• Das Programm wird auf den ATtiny gespielt

Funktionsweise

Die Buchsen +5V und GND (rot und blau) können genutzt werden, um die Lampe einer Lichtschranke zu versorgen. Die zulässige Stromaufnahme ist seitens LD nicht dokumentiert, mit 100mA sollte man aber auf der sicheren Seite sein. LEDs sind in jedem Fall zu bevorzugen.

Die beiden Eingänge (schwarze Buchsen, J2 ist Lichtschranke 1, J3 ist Lichtschranke 2) werden wie folgt bedient:

• das Cassy zieht J2 auf 5V und J3 auf 3,7 V (der Unterschied muss durch die originale Lichtschranke bedingt sein)
• die an den Adapter angeschlossene Lichtschranke muss diese Spannung jetzt gegen Masse, mindestens aber unter 2V ziehen, um eine Verdunklung zu registrieren
• dafür funktionieren naturbedingt Fotodioden und Fototransistoren
• Fotowiderstände könnten bei richtiger Dimensionierung ebenfalls funktionieren

Test mit Fischertechnik-Lichtschranke

Da es von Fischertechnik kleine Glühlämpchen und Fototransistoren gibt, lohnt sich folgender Test:

Man beachte den Anschluss des Fototransistors (gelb) zwischen J2 und GND!

Gehäuse

Im Moment sind die Platinen zur “nackten” Benutzung vorgesehen, ein 3D-gedrucktes Gehäuse ist in Planung.

Hard- und Software

In diesem Beitrag kommt folgendes zum Einsatz

• Mobile Cassy WLAN von LD Didactic
• eine Lochrasterplatine (Einzelheiten siehe Aufbau & Schaltplan)
• ATTiny-Programm zum initialisieren des Cassy Mobile

Vorbemerkungen

Wie in den beiden Posts zu Hard- und Software des Relais M erläutert, reicht ein EEPROM der unter Adresse 00 die Katalognummer des Relais eingespeichert hat. Für bessere Flexibilität wird hier ein ATTiny25 genutzt, der per Arduino ISP und ATTinyCore von einem Arduino Uno programmiert wird.

Aufbau

Nachstehend Bilder von der (nicht ganz so ansehnlichen) Lochrasterplatine

Hinweis: Hier ist aus debugging-Gründen noch eine Power-LED angeschlossen. Der untenstehende Schaltplan sieht keine vor. In einer späteren Version wird ggf. wie beim Original noch ein ESD-Schutz für den Bus hinzugefügt.

Schaltplan

Die Schaltung besteht aus zwei Teilen: Dem ATTiny25-Schaltkreis und dem Relais-Schaltkreis.

Platine

Im verlinkten Repository sind alle Gerber- und Bohrdaten für die automatisierte Platinenfertigung zu finden.

ATTiny25

Der ATTiny ist zunächst an VCC und GND direkt über die Mini-DIN Buchse angeschlossen. Dabei ist grundsätzlich ein Entkopplungskondensator von 10µF in der Leitung sowie ein 100nF Kondensator unmittelbar zwischen beiden Pins auf der Unterseite der Fassung (es gibt auch Fassungen mit eingebautem 100nF-Kondensator).

SDA und SCL sind über jeweils einen 5,1K pull-up Widerstand an die Mini-DIN Buchse angeschlossen.

Relais

Das Relais hingt hinter einem BC557 PNP Transistor (Emitter an +5V, Basis über 1K Widerstand und 10µF Kondensator an SCK, Collector an Relais-Spule).

Die Ausgänge sind wie folgt beschaltet: im Ruhezustand sind schwarz-blau geschlossen, im Schaltzustand schwarz-rot.

Code

Das ATTiny-Programm ist denkbar kurz und realisiert nur, dass auf die entsprechende Abfrage mit der Katalognummer geantwortet wird.

Errata

08.09.2024: Mittlerweile sind die Platinen da und aufgabaut. Es zeigt sich, dass der Kondensator C3 überflüssig ist. Tatsächlich führt er in einigen Situation sogar dazu, dass das Cassy das Relais nicht mehr zuverlässig halten kann. Die entsprechende Stelle auf der Platine kann einfach gegen eine Drahtbrücke ersetzt werden:

In diesem Beitrag kommt folgendes zum Einsatz

• Mobile Cassy WLAN von LD Didactic und Relais M
• Digital Discovery und Waveforms von Digilent
• ein unter Aufbau gezeigtes Breadboard

Vorbemerkungen

In diesem Beitrag soll die Kommunikation zwischen dem Relais M und einem Cassy Mobile untersucht werden. Außerdem wird die Vermutung aus dem letzten Beitrag überprüft, dass das Relais per cleverem Hack an die Clock-Leitung des I²C Busses angebunden ist. Diese Funktion wird dann nachgestellt. Auf dieser Basis gibt es einen funktionstreuen Nachbau des Relais M der in diesem Beitrag eräutert wird.

Aufbau

Der Aufbau ist ähnlich zu dem aus dem Beitrag zum Mikrofon M. Hier ist bloß ein Relais hinter einem PNP-Transistor ergänzt (Basis an SCK), um die Vermutung zur Beschaltung des Relais zu prüfen.

Initialisierung

Nach der gleichen Methode wie bei dem Mikrofon M wird der Datenverkehr untersucht. Das Cassy Mobile fragt erneut an Adresse 50 das Register 00 ab, worauf das Relais antwortet:

40 00 08 00 9E

erneut stehen die letzten drei Byte für die Katalognummer des M Relais (524 446). Das erste Byte ist allerdings 40 statt 00 wie bei dem Mikrofon (ggf. ein Hinweis darauf, dass es ein Output ist bzw. den Eingang nicht belegt, damit dieser vom ADC getrennt wird?).

Anscheinend wurde der EEEPROM hardwareseitig permanent in den “sequential read” modus gebracht, wodurch er beginnend ab der abgefragten Adresse solange weiter die folgenden Bytes ausgibt, bis der Host die I²2-Stop-Bedingung auslöst, d.h. den Datenverkeht abbricht (vgl. Kap. 9.3 des Datenblatts von Mikrochip).

Weitere Kommunikation gibt es nicht.

Schaltvorgang

Nachstehend ein Bild aus dem Logikanalysator. Die Intialisierung ist darunter noch einmal vergrößert zu sehen.

Klar erkennbar sind die ausgelösten Schaltvorgänge am Pegel von SCK. Das auf dem Breadboard angeschlossene Relais schaltet zeitgleich mit.

In diesem Beitrag kommt folgendes zum Einsatz

• Relais M von LD Didactic

Vorbemerkung

Am Beispiel des Relais M soll gezeigt werden, wie durch sorgfältige Analyse des Hardware-Aufbaus eines Sensors bereits Rückschlüsse auf seine Funktion gezogen werden könne.

Überblick

Auf der Platine ist folgendes verbaut:

• ein Relais mit 5V Spulenspannung
• ein EEPROM 34LC02 (2kBit)
• ein USBLC6-4 ESD-Schutz für den Mini-DIN-Anschluss
• (vermutlich) ein Transistor im SOT 23 Package mit Beschriftung “MP3 Z4” (Datenblatt war nicht auffindbar)
• einer LED
• zusätzlicher Beschaltung, wie Kondensatoren, Widerständen und Brücken (0-Ohm-Widerstände)

Bemerkenswerter aber: verbaut ist kein Microcontroller oder SoC. Das bedeutet, dass die I²C Kommunikation nicht aktiv gesteuert wird. Wie in einem früheren Post vermutet, handelt es sich um einfache Registerabfragen - in diesem Fall Speicherregister des verbauten EEPROM, der darauf mit dem unter dieser Adresse gespeicherten Daten reagiert.

Anschaulich könnte man sagen: Das Relais hat einen Tag (vergleichbar mit einem RFID-Tag an hochwertigen Produkten im Supermarkt oder an Kleidungsstücken), der separat vom restlichen Sensor die Identifikation übernimmt.

Hier ein Bild des EEPROMs auf der Platine:

Ansteuerung des Relais

Spannend ist also die Frage: Wie wird das Relais zum Auslösen gebracht?

Verfolgt man die Leiterbahnen der Spule, so führt diese zuerst über den (vermeintlichen) Transistor und dessen Basis über einen Kondensator zum SCK (Clock)-Anschluss des I²-Busses. Da der Bus im Ruhezustand durch pull-up Widerstände high (+5V) ist, steuert der (nach Messung) PNP-Transistor nicht aus. Er schaltet erst, wenn seine Basis negativ gegenüber der Versorgungsspannung ist.

Dies wird aber gerade durch herunterziehen des Clock-Signals erreicht. Dies führt zum Abfallen der Basisspannung und damit zum Aussteuern des Transistors.

Leybold betreibt hier gewissermaßen I²C-Hacking. Die hoch-frequenten (250 kHz Bustakt) Signale der “normalen” Kommunikation werden nicht ausreichen, um ein Schalten zu erreichen und das Ansteuern des Relais wird von den I²C-Geräten als ungültig gewertet, da die entsprechende Start-Bedingung nicht erfüllt ist (schließlich wird nur SCK aber nicht SDA für das Relais verwendet, sodass SDA dauerhaft high bleibt). Sehr clever!

Überprüft werden soll das im nächsten Beitrag an den zwei logischen Konsequenzen:

• Schaltbefehle müssten mit dem Zustand von SCK korrellieren
• Beim Anschalten müsste die Kommunikation der Sensorerkennung zum kurzzeitigen Auslösen führen (ggf. nicht lang genug für das Relais, aber die LED müsste aufleuchten)

In diesem Beitrag kommt folgendes zum Einsatz

• Mobile Cassy WLAN von LD Didactic und Sensor Mikrofon M
• Digital Discovery und Waveforms von Digilent
• ein unter Aufbau gezeigtes Breadboard
• Arduino-Programm zum simulieren einer angeschlossenen Lichtschranke M

Vorbemerkung

Die nachfolgenden Überlegungen wurden vom Autor von uranmaschine.de angeregt. Ziel soll es sein, eine Art Trigger-Board zu entwerfen, die das Mobile Cassy in den “Lichtschranken-Modus” versetzt und die Beschaltung einer externen Lichtschranke dann über Pins 2 und 6 zu realisieren.

In der verlinkten Darstellung sollte die Bezeichnung “Timer E” bzw. “Timer F” mit etwas Vorsicht genossen werden. Experimente mit dem hier benutzten Mikrofon M legen nahe, dass es sich eher um einfache Analogeingänge handelt und die bei Anschluss der Lichtschranke M lediglich binär abgefragt werden (über Schwellwert -> high, sonst low). Tatsächliche Hardware-Timer wie etwa noch im Cassy-E verbaut wurden, sind hier nicht mehr zu erwarten. Die Zeitmessung wird wohl der ARM-Prozessor im Mobile Cassy übernehmen.

Aufbau

Hier ist der Aufbau, der Digital Discovery Logikanalysator ist an Pins 1 und 5 geklemmt:

Ein kurzer Blick zeigt, dass es sich offensichtlich um einen I²C Bus handeln muss, mit Pin 1 als Datenpin (SDA) und Pin 5 als Takt (SCK):

Initialisierung

Es ist klar zu sehen, dass das Mobile Cassy auf dem I²C Bus grundsätzlich Adresse 50h abfragt. Dabei läuft der erste Austausch so, dass das Mobile Cassy die Abfrage:

00

sendet, worauf das Mikrofon M antwortet

00 08 00 9A

Dezimal lautet diese Antwort 524 442, was der Katalognummer des Sensors entspricht.

Simulieren eines Sensors

Ein einfaches Arduino-Programm ist also in der Lage, auf diese Anfrage mit der Katalognummer zu reagieren. Im Bild oben wird eine Lichtschranke simuliert. Der Arduino bedient dabei gleichzeitig Pin 2 (“Timer E”) und schaltet diesen im 750ms Rhythmus um, sodass die angezeigte Periodendauer von 1,5s entsteht.

Weitergehende Bemerkungen

• Beim Experimentieren mit dem I²C Bus hat das Mobile Cassy Werte auch ohne Beschaltung der Pins 2 und 6 Werte an. Auch Versuche mit anderen Sensoren legen nahe, dass Messwerte auch rein über den I²C Bus übertragen werden können. Das Cassy Mobile versucht unter anderem auch Adresse 14h auf dem Bus zu erreichen - ggf. gibt es reservierte Adressen für diese Messdaten und die allgmeine Adresse 50h für die “Verwaltung”.
• Die übrige Kommunikation, insbesondere Konfiguration von Messbereichen ist noch unklar.

In diesem Beitrag kommt folgendes zum Einsatz

• Cassy Lab und Cassy Sensor 1 von LD Didactic
• Digital Discovery und Waveforms von Digilent
• ein unter Aufbau gezeigtes Breadboard
• cassyspoof zum abfangen und verändern der Kommunikation zwischen Cassy Sensor und Cassy Lab

Aufbau

Hier ist der Aufbau zum Sniffen an der seriellen Schnittstelle des Cassy Sensor 1:

Verwendet wird der Logikanalysator “Digital Discovery” von Digilent, der hinter einem MAX232 (setzt die Pegel auf TTL um) an RX und TX der seriellen Schnittstelle hängt. Das Ergebnis sieht so aus:

Bitrate

Sucht man sich das kürzeste Signal raus und ermittelt die Zeitdifferenz kann man daraus die Baudrate bestimmen. Im Startzustand scheint das Cassy Sensor 1 mit 38,4 kbps. Aufmerksame Leser der Cassy Lab Dokumentation wissen, dass das für die höheren verfügbaren Abtastraten der Sensoren nicht ausreichen kann. Daher kann per Befehl eine höhere Bitrate verhandelt werden. Dazu später mehr.

Initialisierung

Wählt man den COM-Port an, sendet Cassy Lab

1B FF 01

was das Sensor Cassy mit 01 01 06 beantwortet. Die Bedeutung ist noch unklar (ggf. sicherstellen, dass es nicht “irgendein” serielles Gerät ist). Anschließend sendet Cassy Lab eine Reihe von Nachrichten, die vom Gerät mit 01 quittiert werden. Vermutlich handelt es sich dabei um Konfigurationen / Setzen von Registern. Mindestens eine davon wird nur durch die unregistrierte Version von Cassy Lab gesendet, um den internen Zähler des Cassy Sensor hochzuzählen (und ein dauerhaftes Benutzen ohne Aktivierung zu verhindern).

1B FF 1C

1B FF 22 00 00 00 00 00

1B FF 23 00 00 00 00 00

1B 00 2F 00 64

1B FF 2B 00

1B FF 2C 64

Sensorerkennung

Anschließend sendet Cassy Lab einige Nachrichten, die mit 01 FF quittiert werden:

1B FF 10

1B FF 11

Diese werden gehäuft beim Benutzen der Sensoreingänge abgefragt und scheinen das Cassy Sensor zu fragen, ob es Sensoren an den DB-12 Schnittstellen hat. Diese Vermutung wird dadurch bestätigt, dass ein Antworten etwa mit 01 22 zum Erkennen eines Drucksensors führt. Ein Blick in die hilfreiche Tabelle auf uranmaschine.de zeigt, dass Sensor 34 (also hexadezimal 22) in der Tat ein Drucksensor ist.

Demo-Zähler

Danach fragt (das unregistrierte) Cassy Lab nach unserem internen Zähler:

1B FF 0E 00

der mit zwei Bytes beantwortet wird - 01 und der Anzahl der bereits erfolgten Zählimpulse (bis maximal hexadezimal 20, also 32). An dieser Stelle kann z.B. cassyspoof genutzt werden um das zweite Byte 20 abzufangen und durch 01 auszutauschen.

Firmware-Version

Schließlich fragt Cassy Lab noch nach unserer Firmware-Version mit

1B FF 02

Cassy Sensor antwortet mit 01 01 und der Firmware-Version (bspw. wird 1.37, gelesen als 137 zu 01 01 89).

Unbeantwortete Nachrichten

Bemerkenswert ist, dass alle (bis auf eine) beantworteten Nachricht mit 1B FF beginnen. Denn Cassy Lab sendet weitere, unbeantwortet Nachrichten regelmäßig:

1B FE 01

1B FF 01

FE als zweites Byte ist sonst nirgendwo zu sehen - gegebenfalls handelt es sich hier um Abfragen über den Cassy Bus (s.u.), um etwaige andere Geräte zu entdecken?

Einfache Sensorabfragen und Cassy-Bus

Klickt man in Cassy Lab einen der Sensoreingänge an (hier: U_A), so sendet der PC folgende Anfrage

1B FF 12 C8

die standardmäßig (keine Beschaltung an U_A) wie folgt beantwortet wird:

03 00 01

Ändert man diese Antwort probeweise mit cassyspoof in eine zeitegsteuerte Sinuswelle, so zeigt Cassy Lab entsprechend Spannungen zwischen -12 V und 12 V an. Allerdings ist hier Vorsicht geboten - die Cassy Sensoren abreiten mit einer Messtiefe von 12bit und nicht 16bit. Ein Setzen des zweiten Bytes auf FF liefert also immer Werte, die außerhalb des eingestellten Messbereichs liegen.

Eine Änderung in Cassy Lab auf Spannung U_B führt zu der geänderten Abfrage

1B FF 13 48

sodass das dritte Byte anscheinend der Messkanal und das vierte (ggf.) das konkrete Gerät am Kanal spezifiziert. Im Fall des fiktiven Drucksensors von oben ändert sich das letzte Byte etwa in 08.

Weitergehende Bemerkungen

• Die hier gezeigte Form der Messwertsimulierung liefert Werte, die vom eingestellten Messbereich abhängen. Das Cassy Sensor scheint also relative Angaben zu liefern. Um die vollen 12bit Messtiefe auzuschöpfen wäre das auch nur sinnvoll.
• Alle tatsächlich vom Cassy Sensor beantworteten Anfragen beginnen mit 1B FF. Da das direkt folgende Byte die Sensoradresse ist und Cassy Lab zusätzlich Anfragen mit 1B FE 01 bis 1B FF 01 sendet, die unbeantwortet bleiben, ist davon auszugehen, dass es sich hierbei um die Adressierung etwaiger weiterer Geräte auf dem (von mir hier so genannten) Cassy Bus (grauer 20 pol. Anschluss) handelt. Das legt nahe, dass die RS232 (und in Konsequenz die USB Schnittstelle an Cassy Sensor USB bzw. Cassy Sensor 2) eher als Router zu diesem Cassy Bus und nicht so sehr als direkte Anbindung des konkreten Geräts zu verstehen ist. Das bleibt aber zu überprüfen.