Ulanzi TC002 – Würdiger Nachfolger oder Rückschritt?

Die beliebte Pixel-Uhr Ulanzi TC001 war ein voller Erfolg für den Hersteller. Es hat sich eine Community rund um das Produkt entwickelt. Das war dank des verbauten ESP32-Mikrocontrollers möglich. So konnte man ganz einfach die Software auf dem Gerät austauschen und diese beispielsweise gegen Awtrix NG ersetzen. Die Hardware war nicht perfekt, aber dafür günstig. So hat Ulanzi versehentlich eine Nische in der DIY-Community getroffen und tausende Geräte verkauft. Mit dem Nachfolger namens TC002 möchte man das Software-Thema wohl besser machen. Klappt das? Oder entwickelt der Hersteller hier am Markt vorbei? Das klären wir in diesem Beitrag.

Zuerst die schlechte Nachricht: Das Gerät wird deutlich teurer. Zum Start bekommt man die TC002 zum Angebotspreis von gut 104 Euro inkl. Versand. Direkt aus dem Shop des Herstellers **. Sportlich, da der Vorgänger im Angebot teilweise für unter 40 Euro zu bekommen war. Auf Amazon.de ** ist sie aktuell sogar günstiger und für 95 Euro zu haben.

Ende September 2026 gibt es auf Amazon bereits einen 10%-Coupon, wodurch man auf 87,25 Euro kommt. Der Preis fällt also jetzt schon fleißig weiter!

Video: Ulanzi TC002 – Würdiger Nachfolger oder Rückschritt?#

Produkt-Empfehlung **

ULANZI TC002 Pixbar Smart Pixel Clock, WIFI Digitaler Tischuhr mit Magnetischer Ladestation, LED Pixel Art Anzeigetafel, Social Media Counter, Fokus Timer, Pomodoro Uhr Wetter Open-Source Customizable **

Auf Amazon.de kaufen

Die Hardware-Basis#

Ulanzi hat die TC002 nicht von Grund auf selbst entwickelt. Das Gerät besteht aus drei Schichten, die von drei verschiedenen Firmen stammen: Der Prozessor kommt von SigmaStar, das Betriebssystem samt Entwicklungsumgebung FlyThings von zkswe – und erst ganz oben sitzt die eigentliche Uhr-App von Ulanzi.

Vergleich mit dem Vorgänger#

Auf dem Papier ist die TC002 in fast allen Punkten das größere Gerät. Der wichtigste Unterschied liegt aber unter der Haube: Statt einem ESP32 werkelt hier ein SigmaStar SSD210 mit zwei ARM Cortex-A7 Kernen und einem eigenen Linux. Damit fällt der komplette Awtrix-Weg weg! Die Firmware lässt sich nicht mal eben austauschen.

Der SoC: SigmaStar SSD210#

Herzstück ist ein SigmaStar SSD210 (Codename Pioneer3). Das ist ein System on a Chip mit zwei ARM Cortex-A7 Kernen, welche mit 1 GHz takten. Also eine ARMv7 32-Bit-Architektur. Die 64 MB Arbeitsspeicher sind direkt im Chip-Gehäuse verbaut. Davon bleiben für Linux allerdings nur rund 35 MB übrig, da der Rest für Grafik- und Video-Funktionen reserviert ist, die auf der Uhr niemand braucht.

Eigentlich ist die Chip-Familie für Überwachungskameras und kleine Displays gedacht. Deshalb ist auch eine komplette Kamera-Pipeline mit an Bord, die hier ungenutzt bleibt. Die LEDs steuert der SoC gar nicht direkt an. Er schickt fertig berechnete Bilder per SPI an einen separaten Mikrocontroller, der sich um die LED-Matrix, die Tasten, das Drehrad und das Mikrofon kümmert. WLAN und Bluetooth übernimmt ein zusätzlicher Funkchip AICSemi AIC8800DC. Gespeichert wird alles auf 32 MB NOR-Flash.

• Package: QFN68
• Größe: 7×7 mm

Ein Entwicklungsboard mit diesem SoC ist beispielsweise der DongshanPI-PicoW.

Die Plattform: FlyThings von zkswe#

Auf dem SoC läuft FlyThings bzw. zkOS – ein Linux-basiertes System des chinesischen Herstellers zkswe. Die Plattform ist als schlanker Android-Ersatz für Haushaltsgeräte, Zugangskontrollen und ähnliche Geräte mit kleinem Display gedacht. Deshalb findet man auf der TC002 viele Bausteine aus der Android-Welt (z. B. das Init-System, ADB und logcat), obwohl es sich nicht um Android handelt. Die Plattform-Bezeichnung für Geräte mit diesem SoC lautet bei FlyThings Z21.

Spannend wird es beim Blick auf die Versionsstände:

Der Kernel-Zweig 4.9 bekommt seit Januar 2023 überhaupt keine Updates mehr. Das ist bei solchen Plattformen leider typisch: Der Chiphersteller liefert sein SDK mit einem bestimmten Kernel aus, und weil die eigenen Treiber daran hängen, wird dieser nie aktualisiert.

Die Entwicklungsumgebung: FlyThings IDE#

Software für die Plattform entwickelt man mit der FlyThings IDE. Diese basiert auf Eclipse, läuft ausschließlich unter Windows und ist nur auf Chinesisch dokumentiert. Die aktuell von Ulanzi verlinkte Version stammt vom 26. Mai 2021. Programmiert wird in C++ gegen die (nicht quelloffenen) Bibliotheken von FlyThings. Die IDE kann direkt ein Firmware-Image (update.img) erzeugen, welches sich über den regulären Update-Prozess einspielen lässt.

Ulanzi hat dazu ein GitHub-Repository veröffentlicht. Darin liegt aber nicht die Firmware der Uhr, sondern nur ein Beispielprojekt, welches zeigt, wie man LEDs, Tasten, Audio, WLAN und Bluetooth anspricht. Die eigentliche Uhr-App ist nicht öffentlich. Wer die Uhr um eigene Funktionen erweitern möchte, kann also nicht auf der bestehenden App aufbauen, sondern muss eine komplett eigene schreiben.

Inbetriebnahme#

Im Standard öffnet das Gerät einen WiFi-Hotspot mit dem Namen U-Clock. Das Passwort lautet 12345678. Diesem WLAN kann man mit einem beliebigen Gerät beitreten und öffnet dann im Browser die Seite 192.168.100.1. Dort kann man nichts weiter tun, als Anmeldedaten für das eigene WLAN zu hinterlegen.

Klappt die Verbindung, wird READY angezeigt. Im Normalfall wird jetzt eine IP-Adresse von Deinem DHCP-Server vergeben. Rufst Du diese auf, bekommst Du eine chinesische Webseite angezeigt. Mein Gerät wurde mit MCU-Version 1.0.16 und SOC-Version 1.0.1 ausgeliefert. Nach einem Update war ich auf 1.0.17 und 1.1.1. Weiterhin nur auf Chinesisch.

Erste Daten per MQTT auf das Gerät senden#

Nachdem ich alle integrierten Apps (für Social Media und Co.) erstmal ausgeblendet habe, möchte ich mit MQTT neue Daten auf das Display senden. Einen MQTT-Broker (Mosquitto) habe ich dafür auf einem Raspberry Pi 5 vorbereitet. Dann kann man Daten einfach auf das Display schreiben. Das ist eigentlich die einzige Funktion, welche ich brauche.

mosquitto_pub -h 192.168.188.45 -u ulanzi -P 12345678 \
 -t ulanzi_a755/custom/erster_test \
 -m '{"duration":10,"text":[{"content":"haus","fontHeight":5,"x":1,"y":1,"color":"#e2671f"},{"content":"automation","fontHeight":5,"x":7,"y":7,"color":"#e2671f"}],"image":[],"draw":[]}'

# App löschen
mosquitto_pub -h 192.168.188.45 -u ulanzi -P 12345678 \
 -t ulanzi_a755/custom/erster_test \
 -m '{}'

Bilder per MQTT übermitteln#

Bilder (wie animierte GIF-Dateien) können als Base64-String an das Gerät übergeben werden. Man kann also Texte, Bilder und manuelle Zeichnungen in einer App kombinieren. Damit nicht so viele Daten übergeben werden, verkleinere ich das gewünschte GIF vorher mit ffmpeg auf einem anderen Linux-System (derselbe Raspberry Pi 5 von oben).

sudo apt install ffmpeg

ffmpeg -i input.gif -vf "scale=-1:16:flags=lanczos" output.gif
base64 -w 0 -i output.gif

mosquitto_pub -h 192.168.188.45 -u ulanzi -P 12345678 \
 -t ulanzi_a755/custom/bild_test \
 -m '{"duration":10,"text":[],"image":[{"data": "data:image/gif;base64,R0lGODlhHAAQAPcfAAAAACQAAEgAAGwAAJA...","position": [0, 0]}],"draw":[]}'

mosquitto_pub -h 192.168.188.45 -u ulanzi -P 12345678 \
 -t ulanzi_a755/custom/bild_test \
 -m '{}'

Zeichnen mit Formen#

mosquitto_pub -h 192.168.188.45 -u ulanzi -P 12345678 \
 -t ulanzi_a755/custom/farben_test \
 -m '{"duration":10,"text":[],"image":[],"draw":[{ "df": [0, 0, 52, 16, "#FF0000"] }]}'

Die integrierte HTTP-API#

Immerhin: Die TC002 bringt ab Werk eine lokale HTTP-API mit, für die man weder Cloud noch die Ulanzi Studio Software braucht. Sie läuft auf Port 80, spricht JSON und ist vollständig ohne Anmeldung nutzbar. Für die Bastelei ist das praktisch, für die Sicherheit ein Desaster – dazu gleich mehr.

Zwei Eigenheiten solltest Du kennen, bevor Du loslegst: Fehler kommen fast immer mit HTTP-Status 200 zurück – Du musst das Feld code im JSON auswerten, nicht den Statuscode. Und es gibt keine Teilabfragen: Jeder Getter liefert immer das komplette Objekt zurück.

Gerät und Einstellungen#

Anzeige#

Navigation und Eingabe#

System#

Ein Beispiel#

curl -s -X 'POST' 'http://192.168.188.90/setConfig' \
-H 'Content-Type: application/json' \
-d '{"brightness":{"level":"low","low":50,"mid":80,"high":100},"volume":0,"carouselSpeed":0,"scrollSpeed":7,"timezone":"UTC+8","dateFormat":"MM/DD","showWeek":true,"weekStart":1,"lowBatteryAutoSleep":false}'

Das Wichtigste für den Alltag ist /api/custom. Der Endpunkt nimmt dasselbe JSON entgegen wie das MQTT-Topic – Du brauchst also nicht zwingend einen MQTT-Broker, um etwas auf das Display zu bekommen:

curl -s -X POST 'http://<geräte-ip>/api/custom?name=hallo' \
  -H 'Content-Type: application/json' \
  -d '{"duration":10,"text":[{"content":"HALLO","fontHeight":10,
       "x":-1000,"y":3,"align":"center","rect":[0,0,52,16],
       "color":"#3EE08A"}]}'

Home Assistant Integration?#

Der offiziell dokumentierte Weg ist MQTT. Das Gerät verbindet sich als MQTT-Client, welchen man in den Einstellungen auf den eigenen MQTT-Broker (Mosquitto läuft beispielsweise als Home Assistant App) zeigen lässt.

Sicherheit: Root-Zugriff für jeden im Netzwerk (juhu?)#

Die TC002 ist kein Mikrocontroller mehr, sondern ein vollwertiger Linux-Rechner in Deinem Netzwerk. Und dieser Rechner ist ab Werk so konfiguriert, dass ihn jeder übernehmen kann, der im selben Netzwerk unterwegs ist.

Root-Shell über ADB – ohne Passwort, ohne Rückfrage#

Um die ADB-Verbindung zu testen, habe ich mir einen Raspberry Pi 5 mit Debian 13 (Trixie) aufgesetzt. Da würde natürlich jedes Linux-System funktionieren. Also auch ein Proxmox-Container oder Ähnliches.

sudo apt update
sudo apt full-upgrade
sudo apt install adb

Das Gerät hat einen offenen ADB-Port 5555. ADB ist eigentlich die Android Debug Bridge, aber der Daemon lässt sich auch auf ein normales Embedded-Linux setzen. Genau das hat der Plattform-Hersteller hier gemacht. Zwei Befehle genügen:

adb connect 192.168.188.90:5555
adb shell

Es gibt kein Pairing und kein Passwort. Man landet direkt auf dem Gerät. Eine Rechteverwaltung existiert ebenfalls nicht, auf der TC002 läuft schlicht alles als root.

An dieser Stelle könnte man die Ulanzi-Software (also MQTT, HTTP-API, Weboberfläche usw.) einfach abschalten. Ebenfalls per ADB:

adb shell setprop ctl.stop zkswe

Genauso können alle Dateien gelesen und teilweise auch geschrieben werden (je nach Ziel, vieles ist readonly).

Größeres Sicherheitsrisiko#

In der Shell führt der erste Weg zu /data/setting.ini. Diese Datei hat die Rechte 0666, ist also für jeden les- und schreibbar. Darin stehen im Klartext:

• Dein WLAN-Passwort
• Die Seriennummer des Geräts
• Die OAuth-Tokens Deiner verknüpften Social-Media-Konten
• Die Cloud-Zugangsdaten des Geräts

Zusätzlich schreibt das Gerät das WLAN-Passwort beim Einrichten wörtlich ins Log (Saving WiFi - SSID: %s, pwd = %s), zusammen mit dem Cloud-Secret-Key. Das Log wiederum liest jeder über dieselbe ungeschützte ADB-Verbindung mit adb shell logcat.

Die Kette ist damit ziemlich kurz: Wer in Dein Netzwerk kommt, bekommt ohne jede Hürde eine Root-Shell – und damit Dein WLAN-Passwort und andere Zugangsdaten.

HTTP-API komplett ohne Authentifizierung#

Auf Port 80 läuft eine HTTP-API, die jede Einstellung ausliest und schreibt. Ohne Login, ohne Token, ohne TLS. /getCalendar gibt Kalender-Passwörter im Klartext zurück, /getSocial die OAuth-Tokens.

Dazu kommt, dass das Gerät den Origin-Header ignoriert und POST im CORS-Preflight erlaubt. Im Ergebnis kann jede beliebige Webseite, die Du im Browser öffnest, Befehle an die Uhr in Deinem Netzwerk schicken – Konfiguration zurücksetzen, WLAN- und MQTT-Einstellungen überschreiben oder das Display mit beliebigen Inhalten bespielen. Der Browser versteckt zwar die Antwort, aber das Gerät hat den Befehl da längst ausgeführt.

Alles unverschlüsselt in die Cloud#

Wetter, Social-Media-Zähler, Kalender und der Update-Check laufen über unverschlüsseltes HTTP zu api.ulanzistudio.com. Wenn Du einen CalDAV-Kalender einrichtest, gehen dessen Benutzername und Passwort ebenfalls im Klartext über die Leitung. Die Geräteregistrierung in der Cloud benötigt nur Seriennummer und MAC-Adresse – und beides sendet die Uhr sekündlich als Broadcast ins gesamte Netzsegment.

Was tun?#

• Das Gerät in ein separates IoT-VLAN oder eine eigene SSID mit Client-Isolation packen
• Den Internetzugang blockieren, wenn Du die Cloud-Apps nicht brauchst
• Keine Kalender- oder Social-Media-Konten mit echten Zugangsdaten verknüpfen
• Ein WLAN-Passwort verwenden, das Du nirgendwo sonst benutzt

Das ist Schadensbegrenzung, keine Lösung. Ärgerlich ist vor allem, wie leicht das vermeidbar gewesen wäre. Und der Vergleich zum Vorgänger fällt hier besonders bitter aus: Bei der TC001 brauchte man physischen Zugang und ein USB-Kabel, um an der Firmware zu drehen. Bei der TC002 genügt die Netzwerkverbindung.

Software austauschen#

Dafür bist Du hier, oder? Schauen wir mal, was die Community bisher so getan hat, um die Probleme der Software in den Griff zu bekommen.

Ersatz für das chinesische Web-Frontend#

Auf GitHub gibt es von atomicstack ein Projekt, welches mehrere Probleme löst. Der erste Ansatz ist eine alternative WebUI, welche nicht auf dem Gerät selbst läuft, sondern nur mit der Standard-HTTP-API spricht. Ich nutze dafür wieder meinen Raspberry Pi 5:

sudo apt install git python3

git clone --branch v0.1.0 https://github.com/atomicstack/tc002-customisation.git
cd tc002-customisation/panel-/
python3 serve.py 8777

Der Nachteil ist hierbei natürlich, dass immer ein weiteres System laufen muss, auf dem diese Webseite ausgeliefert wird.

Das originale Update-Image anpassen#

Die Nutzer aquarat und atomicstack haben mittlerweile sogar den kompletten Update-Prozess analysiert. Damit kann das originale update.img entpackt, geändert und wieder eingepackt werden. Ich habe beispielsweise die Dateien der Weboberfläche ins Englische übersetzt (sieht man im Video) und das Update dann angestoßen.

Eine komplette technische Dokumentation des Update-Prozesses gibt es auf GitHub.

sudo apt install -y python3 squashfs-tools mtools

# Image-Tool aus dem Repository holen
wget https://raw.githubusercontent.com/atomicstack/tc002-customisation/main/tc002-update-img.py
chmod +x tc002-update-img.py

# Image prüfen -> "the device would accept this image"
./tc002-update-img.py inspect update.img

# Image entpacken
./tc002-update-img.py unpack update.img res.sqsh
sudo unsquashfs -d res res.sqsh

# JETZT Dateien in res/ ändern 

# Image packen
sudo mksquashfs res res-new.sqsh -comp xz -b 128K -noappend -force-uid 1000 -force-gid 1000
./tc002-update-img.py pack res-new.sqsh my_update.img --template update.img
./tc002-update-img.py inspect my_update.img

# flashen
adb push my_update.img /tmp/update.img
adb shell setprop sys.zkupgrade.dir /tmp
adb shell setprop sys.zkupgrade.flag 255
adb shell setprop ctl.restart zkswe

Ersatz für die Ulanzi-Software temporär starten#

Im offiziellen Repository gibt es ein Beispiel, wie man eine eigene Anwendung für die FlyThings-Z21-Plattform bauen kann (siehe Z21_TC002_Demo). Diese würde für Debug-Zwecke temporär geladen und würde bei einem Neustart des Gerätes nicht mehr laufen.

Normalerweise braucht man für so eine Anwendung die Entwicklungsumgebung (FlyThings IDE) des Herstellers, welche auch nur unter Windows läuft. Aber: Der GitHub-User qzz0518 hat einen Weg gefunden, wie man das Projekt auch ohne diese IDE in einem Docker-Container bauen kann.

Die komplette Anwendung im Image austauschen#

Wir haben nun gelernt, dass man eigene Images bauen kann. Und in dieses Image kann man logischerweise auch komplette eigene Software legen, welche für diese Umgebung gebaut wurde. Hier ist das Projekt von atomicstack aktuell am weitesten. Er nutzt allerdings nicht das offizielle Framework von FlyThings und deren IDE (wie im Abschnitt vorher), sondern zig als Programmiersprache.

Um diese Anwendung zu bauen, muss als Erstes zig installiert werden, damit die Binaries überhaupt kompiliert werden können. Laut Doku wird 0.16.0 vorausgesetzt. Mittlerweile gibt es zwar eine neuere Version, aber ich halte mich an genau diese. Installation auf dem Raspberry Pi (aarch64):

cd ~
wget https://ziglang.org/download/0.16.0/zig-aarch64-linux-0.16.0.tar.xz
tar -xvf zig-aarch64-linux-0.16.0.tar.xz
rm zig-aarch64-linux-0.16.0.tar.xz

sudo mv zig-aarch64-linux-0.16.0 /opt/zig-0.16.0
sudo ln -sf /opt/zig-0.16.0/zig /usr/local/bin/zig

Damit kann man dann eigene Anwendungen bauen und diese hochladen. Man muss allerdings einiges beachten:

1. WLAN-Treiber aic8800 laden, falls nötig
2. wpa_supplicant starten, wenn init.svc.wpa_supplicant nicht läuft
3. Einen DHCP-Client starten (statisches udhcpc) mit Renew-Skript
4. sys.zkapp.state = running binnen ~15 Sekunden nach dem Boot setzen

Das würde normalerweise das Framework von FlyThings selbst erledigen.

Noch tiefer: einen eigenen Kernel?#

Die App auszutauschen heißt, auf der alten Plattform zu bleiben – Linux 4.9.84, gebaut 2021 mit dem OpenWrt-GCC 9.1.0. Die naheliegende Frage: Kann man nicht gleich einen frischen Kernel flashen? Technisch liegt er offen in mtd1 (1,9 MiB), und Module ohne Signatur lassen sich laden. Der Haken steckt woanders:

Der SoC ist ein SigmaStar SSD210 / Pioneer3 / Ikayaki (compatible = "sstar,pioneer3") – und der ist im Mainline-Linux schlicht nicht angekommen. Das Community-Projekt linux-chenxing hat die verwandten SigmaStar-SoCs (Infinity, Infinity2m/SSD20x) in Mainline gebracht, Pioneer3 aber nicht. Es fehlt also nicht ein Treiber, sondern die SoC-Basis: Clock-Tree, Pinmux-Tabellen und ein passender Device Tree für genau diesen Chip.

Interessant wird es beim Blick auf den Device Tree des Geräts (/proc/device-tree). Der SSD210 ist eigentlich ein IP-Kamera-Chip – über die Hälfte der aktiven Hardware-Knoten bedient Kamera, ISP und eine Video-Pipeline, die eine Pixel-Uhr überhaupt nicht braucht (csi, isp*, vpe, disp, gop, usw.). Genau dieser proprietäre Media-Stack (die mi_*-Module) ist der Teil, den niemand je portiert hat – und den man einfach weglässt. Die LED-Matrix hängt an SPI und GPIO, nicht an der Display-Engine.

Was übrig bleibt, ist überschaubar – und fast alles davon existiert für die Schwester-SoCs bereits in Mainline:

Ein moderner Kernel ist damit kein unmögliches, aber ein echtes Portierungsprojekt an der Wurzel des SoC – deutlich mehr als App-Basteln. Für den Alltag bleibt es beim originalen 4.9.84, über den man nur die Anwendungsschicht tauscht.

Wer es dennoch versuchen will, muss nicht bei null anfangen. Drei Projekte für die verwandte SoC-Familie liefern zusammen ein brauchbares Gerüst – keines zielt auf Pioneer3, aber sie senken die Hürde deutlich:

Der verbleibende harte Kern bleibt in jedem Fall derselbe: das Pioneer3-Bring-up (Clocks, Pinmux, Device Tree) und der Out-of-Tree-Treiber für den aic8800.

Kommt Awtrix NG doch noch für die TC002?#

Auf Discord spricht Blueforcer bereits darüber, dass er von der neuen Plattform zwar nicht begeistert ist, aber wegen der großen Nachfrage doch mal nach einem Weg für Awtrix NG schauen möchte. Ziel sollte natürlich sein, die Software komplett in die Hand zu nehmen. Also inklusive eigenem Kernel und einer gemeinsamen Software-Basis von Awtrix NG für den ESP32.

»Kommt Awtrix NG für die TC002?«

Update Oktober 2026: Mittlerweile gibt es Awtrix NG für die TC002

Fazit#

Die höhere Auflösung ist der einzige wirklich große Fortschritt. Alles andere ist Geschmackssache – oder sogar ein Rückschritt. Denn der Tausch des ESP32 gegen eine Linux-Plattform nimmt genau der Community den Boden weg, die den Vorgänger erst groß gemacht hat.

Positiv#

• Höhere Auflösung (16 x 52 Pixel)
• Ein vernünftiger integrierter Lautsprecher
• Integriertes Mikrofon (z. B. für Audio-Visualisierung)
• Mehr Rechenleistung als ein ESP32

Negativ#

• Deutlich höherer Preis (aktuell für 95 Euro im Angebot)
• Tasten und Drehrad fühlen sich sehr billig an
• Weiterhin ein Akku verbaut
• Das Dock bleibt nicht stehen, wenn man das Gerät anhebt
• Weboberfläche im Standard auf Chinesisch
• Dokumentation und Repositories ebenfalls auf Chinesisch
• Unterstützt nur 2,4-GHz-WLAN
• Linux-Kernel-Basis 4.9.84 extrem veraltet
• Es gibt keine RTC
• NTP zwingend notwendig, aber nicht konfigurierbar

Glossar#

Produkte#

• TC002 bei Amazon.de **
• TC002 bei Ulanzi **

Gerät zerlegen / Akku entfernen#

Um das Gerät auseinanderzubauen, kann man das Display am oberen Rand etwas herausdrücken (geklipst). Allerdings muss man dann einen Anfang finden, um die beiden verklebten Teile zu trennen! Erst wenn man die vordere Scheibe gelöst hat, werden unten vier Schrauben sichtbar. Sobald diese gelöst sind, kann man den unteren Teil aus dem Gehäuse nehmen.

Bitte versuche nicht, das Frontpanel mit Gewalt zu entfernen. Ich dachte Anfangs auch, dass das ganze Frontteil nur eingesteckt ist. Dass weitere Schraubverbindungen zwischen den beiden verklebten Teilen zu finden sind, ist nicht besonders schön gelöst.

Ich habe mich daher dazu entschieden, die Schrauben nicht wieder einzusetzen. Es reicht, wenn man die beiden Hälften wieder mit Sekundenkleber zusammenklebt und dann einfach einklipst. Dann kommt man auch in Zukunft leichter an das Innere. Ganz ohne Klebstoff. Und es hält trotzdem alles.

»Ulanzi TC002 Teardown – Display«

»Ulanzi TC002 Teardown – 4 Schrauben«

»Ulanzi TC002 Teardown – Überblick«

»Ulanzi TC002 Teardown – SoC SSD210«

»Ulanzi TC002 Teardown – SPI Verbindung«

Betrieb ohne Akku#

Auf den ersten Blick läuft alles auch ohne Akku. Das ist schonmal ein deutlicher Fortschritt zur ersten Generation. Allerdings blinkt dann die LED an der Seite die ganze Zeit rot (auch im ausgeschalteten Zustand). Die Steckverbindung vom Akku ist zusätzlich verklebt, welche sich aber mit einer Pinzette relativ einfach abziehen lässt (in einem Stück). Etwas Wärme schadet dabei sicherlich auch nicht.

3D-Druck Erweiterungen#

Nachdem viele in die Kommentare geschrieben haben, dass sie das orange Drehrad auf der Oberseite nicht besonders schön finden, habe ich eine schwarze Variante entworfen. Diese habe ich mit einer 0,2 mm Nozzle und Fuzzy Skin auf einer Smooth Plate gedruckt, sodass die Oberseite schön glatt ist, aber der Rand eher griffig.

Das Modell findest Du auf Makerworld.

»Ulanzi TC002 Teardown – Neues Drehrad«

Credits#

Danke an Matt / atomicstack, Aaaron / aquarat, Zerah / qzz0518 und Daniel Nashed für die extrem starke Reverse-Engineering-Vorarbeit und die top Dokumentation des Gerätes!

Links

• Ulanzi Dokumentation – Ulanzi Studio
• Ulanzi – Pixelgrid Studio im Browser
• GitHub Repository – TC002 Customisation
• GitHub Repository – Offizielle TC002-Beispiele (cn)
• GitHub Repository – Offizielle TC002-Beispiele (en)
• GitHub Repository – TC002 Tools
• FlyThings-Pakete für die Z21-Plattform
• linux-chenxing – Mainline-Linux für SigmaStar-SoCs
• openwrt-ssd20x – OpenWrt für SSD201/202
• DongshanPI Buildroot – SigmaStar SDK mit Buildroot

FAQ (häufig gestellte Fragen)