Recently i bought a never before used Standing Desk via Kleinanzeigen. My goal was to have a quick and cheap solution for some remote work from home.
It is a Flexispot E1 with the basic controller which only features two buttons for manually driving the table up or down.
So… if u are me, u probably already dissembled the controller while i write this up…
Loctek HCB107A-1
Normally with the more expensive height adjustable tables, you would find two drive units with a motor controller on each. The button controller then just talks some serial protocol with them.
Many projects on the web hijack this serial communication for adding remote capabilities to the table.
So i was hoping for some open unused UART Pins, but i was disappointed.
Reverse Engineering
If there is no open interface for me to play with, i have to understand the device from ground up. For this let me first introduce you to the features of the table.
it can drive upwards
it can drive downwards
it stops it’s downward movement before colliding within the leg
it stops it’s upward movement before losing the legs
it knows it’s height after power loss
it resets the bottom position, if u press down for longer, by driving in to a collision
And that’s pretty much it!
As a next step i poked the controller with some measurement devices while using it. This way i was able to identify each function for a section of the circuit. There is:
A voltage regulator circuit
A very obviously swd port
The controller is powered by a STM32L011F4P6
Two buttons which pull to Gnd if pressed
The motor interface which lists
GND
5V
HALL1
HALL2
M1
M1+
Two relays can switch each motor pin between Gnd or +30V
An op amp lm358 amplifies current sensing of the motor
Filtering for the hall sensors
It then was an ease to identify the mcu pins.
STM32L011F4 Pinout for Loctek HCB107A-1
Lisa and i sat on the table. While she was driving i measured the motor current voltage and the hall sensor outputs with my scope. It seems, that the controller only takes the motor current in account, while re calibrating its height (reset). There is nothing like a collision detection or weight limitation or other safety function behind it. For the hall sensors i suppose a quadrature encoder interface.
SWD Interface on Loctek HCB107A-1
For now i soldered some cables to the swd port, screwed the controller back together and mounted it under the table.
Ja dieser Blog ist tot. Und nein er war eigentlich auch nie wirklich am Leben. Als wir 2020 in Corona gestartet sind hatte ich aus Lust und Laune die Domain „nerds.cool“ geschossen und unter gleichen Namen haben Tom, Stefan und ich dann die Digitale Weinmeile veranstaltet. Pläne zu nerds.cool gab es nie in ausgefeilterer Form als einer Skizze.
Seit dem ich die Universität verlassen habe und mich als Freiberufler für Lichtgestaltung und Entwicklung betätige, fallen mir erstaunlich viele Projekte in die Finger, welche ich nun endlich mal dokumentieren möchte. Aus diesem Blog wird also eine Art öffentliches Entwicklertagebuch.
Jasper hat vor 2 Jahren angefangen Pixelbars zu bauen. Seit dem gibt es verschiedene Varianten: 1m, 2m, Ecken, … mit einer Pixeldichte von 60Pixeln/m.
Die Pixel Bars im Einsatz – Zuspiel via Resolume
Wir haben jeder für sich / wie auch zusammen nun schon viele Touren mit den Lampen hinter uns. Doch als ich neulich für I „Spy With My Litle Eye“ auf dem somaFest im Cologne Gamelab unseren gewohnten Aufbau zerlegen musste, um den Raum hübsch zu machen, stieß ich auf Grenzen.
Setup
WS2811B Controller chips sprechen ein asynchrones serielles Protokoll welches über eine Datenleitung (im Bezug zu Ground) übertragen wird. Mit Pegeldefinitionen halten sich die Hersteller gut zurück. Zur Kommunikation zwischen eigener Hardware und den 2811ern gibt es verschiedene Ansätze, der geläufigste ist das Verbiegen von SPI-Peripherien oder SPI-Controllern. Dabei wird ein Bit auf mehrere Bit aufgepustet und etwas mit der SPI-Clock gespielt.
ArtNet-SPI-Controller
Bei uns übernimmt das so ein chinesischer Art-Net Controller. Das Gerät verfügt über vier 4-Port SPI-Controller die von einem STM32F4 mit Daten bespielt werden. Die Systemspannung beträgt 12Volt und wird von mehreren Netzteilmodulen neben dem Controller bereit gestellt.
Die Pixelbars selbst sind extra gefertigte Aluminiumprofile mit besagten LED-Streifen. Als Stecker hat sich Jasper für XLR entschieden. Die Pinbelegung ist
1 – Masse 2 – +12V 3 – Signal.
Als Kabel verwendeten wir immer DMX-Kabel. Über die Zeit stellten wir aber fest, dass dem Kabelquerschnitt schnell die Luft aus geht und die Spannungsabfälle in den Leitungen zu hoch sind. Mit kleinen Netzteilmodulen kann die Spannungsversorgung in der Installation wieder sicher gestellt werden.
Jasper bat mich für ihn noch Kabel auf Basis von 3G1,0 Gummileitung zu fertigen. Diese hatte ich naiv ungetestet mit nach Köln genommen.
Die Pixelbars können in Reihe geschaltet werden. Maximal 4 Meter sind möglich.
Das Problem
Reihenschaltung… „na Prima“ dachte ich mir in Köln, als ich die Pixel Bars einzeln im Raum verteilte, „dann brauch ich ja nicht so viele Kabel ziehen“. Was wir aber nicht wussten, dass zwischen dem Ausgang einer Pixel Bar und dem Eingang der nächsten kaum mehr als 2 Meter Kabel funktionieren. Alles darüber hat zu Fehlsignalen und letztlich dem falschen Licht geführt. In diesem Moment habe ich das erste mal genauer über die Signalführung im System nachgedacht und mir wurde direkt klar: Das kann nicht gehen.
Noch deutlicher wurde es dann mit den bereits erwähnten 1mm²-Kabeln. Ja der Leitungswiderstand ist geringer und das ist Prima für die Stromversorgung. Jedoch haben wir auch eine bedeutend höhere Leitungskapazität, bei der selbst der ArtNet-Controller Schwierigkeiten bekommt ein gescheites Signal ans andere Ende des Kabels zu schieben.
Und dann gibt es ja noch die Reflektionen die solch ein Signal am Hochohmigen Eingang eines Schaltkreises verursacht.
Erste Hacks
Ein Regelbarer Serienwiderstand 🙂
Mein erster Gedanke war also noch vor Ort: Da muss ein Serienwiderstand rein! Dieser hilft eigentlich immer ganz gut gegen Reflektionen, da er die reflektierte Energie durch den Ausgangstreiber abbauen kann. So einfach sollte es aber nicht sein. Ca. 330Ohm haben zwar dafür gesorgt, dass die Pixelbar irgendein Signal bekommt, jedoch war dessen Inhalt auch nicht mehr der gewünschte. Und so habe ich also meine Installation neu verkabelt und die Problemlösung hinter den Job geschoben.
Untersuchungen
Zuhause habe ich dann also etwas Material mit zum Schreibtisch gebracht und fing an zu messen.
Auch die zweite Pixel Bar sollte rot leuchten. (15m XLR-Kabel)
Wie sieht denn das Ausgangssignal einer Pixelbar aus? Also habe ich mal mein Oszi an den Datenausgang einer Lampe gehalten und verschiedenes dahinter angeschlossen.
Ohne angeschlossene Last
Mit 15m DMX-Kabel
Mit 20m 1mm² Gummileitung
Man erkennt schon an den Signalpegeln eins: Der Datenausgang eines 2811er ist kaum in der Lage eine längere Leitung zu versorgen. Besonders witzig das dritte Bild, hier geht gar nichts mehr.
Eingangs scherzte ich über die Signalpegeldefinitionen. Die scheint es nicht zu geben, da sich der Signalpegel an der Versorgungsspannung des Chips orientiert. 12Volt Spitze messe ich. Gleichzeitig ist das Signal auch alles andere als rechteckig. Wie wirkt sich das auf den Signaleingang eines WS2811 aus? Das kann man nur raten. Auch hier.. keine Pegelangaben.
Wir halten also Fest: Der Datenausgang eines WS2811 reicht von einer LED auf dem Streifen zur nächsten und weit darüber hinaus.
Wie sieht es denn mit den Ausgängen des ArtNet-Controller aus? Hieran spielten die 20m 1mm² Gummileitungen auch nicht. Ich messe wieder ohne „Last“, nur das Kabel.
Mit 2m XLR-Kabel
Mit 20m XLR-Kabel
Mit 20m 1mm² Gummileitung
Der Pegel beläuft sich auf 5 Volt. Das ist eher erwartbar. Mit zunehmender Länge des XLR-Kabels wird aber auch hier das Signal immer schmutziger. Bis hin zur Unkenntlichkeit mit der Gummileitung.
Was bleibt mir da als Fazit? Das ist nichts. Und irgendwie hatten wir auch einfach sehr viel Glück mit den Pixel Bars. Das Protokoll der WS2811 scheint ausreichend Robust, dennoch habe ich mit dem neuen Wissen nur wenig Vertrauen in das System.
Verbesserungsvorschläge
Als erstes wäre da eine Verstärkerstufe in die Ausgänge der Pixel Bars zu bauen. So könnte man ohne größere Systemeingriffe eine Verbesserung erzielen. Natürlich gibt es dafür auch schon kommerzielle Lösungen.
Als Zweites: Schuster bleib bei deinem Leisten! Wenn man in der Lichttechnik seit Jahrzehnten differentielle Datenbusse durch verdrillte Aderleitungen schickt und das DMX nennt, ja warum nutzen wir das denn nicht für die Pixel Bars? Auch hier stelle ich wieder eine kommerzielle Lösung vor. Ein RS485 Transceiver am Anfang und Ende jeder Pixelbar würde Signale weit über 100 Meter reichen lassen. Leider müssten wir dann aber auch die gesamte Verkabelung überdenken. Mein Favorit sind bis jetzt USB-Kabel welche neben der verdrillten Datenadern auch zwei dickere Adern für die Stromversorgung mitbringen. Wenn man die Pixel Bars dann noch via Schaltregler auf 48 Volt Systemspannung umrüstet, erwarte ich solide Versorgung von einem zentralen Controller aus.
Wir werden sehen wann dieser Post seinen Nachfolger findet. Wenn wir uns entscheiden die Pixel Bars zu überarbeiten, dann folgt hier als nächstes sicher ein Konzept.
Seit 1999 gibt es in einer unserer Heimaten, dem Saale-Unstrut-Tal, die Weinmeile. Seit 2012 (oder so) macht Klötzi dort jedes Jahr mit zwei Freunden Straßenmusik. Dieses Jahr dann Corona, wird wohl nix mit Spaß beim Stagediving zu ranziger Straßenmucke (und mit viel Wein).
28. April, knapp über vier Wochen bis zum Weinmeilen-Wochenende. WhatsApp-Nachricht – von Kathi, Projektmanagerin beim heimischen Tourismus-Verein. Ob wir in einem Social-Media-Livestream spielen wollen. Safe. Und lass doch einfach wieder bisschen übertreiben.
Screenshot vom Chatverlauf von Kathi & Stefan
Und zack, waren wir nach einem Konzeptions-Wochenende voll in einer digitalen Großübung – Gesamtkonzept inkl. Website from Scratch inkl. 12-h-Online-Festival inklusive Weinpaket zum Nach-Hause-Bestellen inklusive exklusiver Livestream-Watchparty auf eigener Video-Chat-Plattform inklusive Online-Content-Produktion. Mehr könnt ihr in folgenden Artikeln lesen:
Wieder mal pure Leidenschaft und ein bisschen Größenwahn, wieder mal kein Geld, wieder mal viel Spaß und wieder mal viel gelernt. Merci. Tom hat ’nen Kater, Paul kann das nächste eskalative Projekt schon wieder kaum erwarten und Klötzi ist nicht komplett unzufrieden. Passt.
Das Ganze kann man sich nach wie vor auf www.weinmeile-at-home.de anschauen. Vielleicht nerden wir in nächster Zeit auch noch mehr darüber hier ab. Aber jetzt erstmal schlafen. Viel. Schlafen.
Wir alle sind faul und ich ganz besonders. Und so tippe ich mir im Folgenden meine Rechercheergebnisse darüber zusammen, wie andere Nerds Jitsi skalierbar machen.
Yasen Pramatarov hat für den Youtube-Channel des Jitsi Projekts ein Video über die Skalierung von Jitsi mit Hilfe der AWS veröffentlicht. In den folgenden Abschnitten erläutere ich das Konzept und die Bestandteile der Lösung.
Wie wir bereits wissen, bildet die Jitsi-Videobridge den Dreh- und Angelpunkt für die Videostreams aller Teilnehmer. Jitsi Meet (die WebApp) kann seine Nutzer aber auch auf mehrere Videobridges verteilen und so liegt es nahe, proportional zu den Nutzerzahlen immer mehr Videobridges zu starten. Damit stellt sich uns eine neue
Aufgabe: Wie lassen wir die Google Cloud automatisiert mehr VM-Instanzen starten?
Sauce: frame out of https://www.youtube.com/watch?v=Jj8a6ZRgehI
Unsere Jitsi-Instanz hat also mehr Puste, wenn es darum geht Videostreams für viele Räume zu behandeln. Doch was ist, wenn die Jitsi Meet WebApp nicht mehr mit den Nutzerfragen hinterher kommt?
Sauce: frame out of https://www.youtube.com/watch?v=Jj8a6ZRgehI
Yasen Pramatarov empfielt an dieser Stelle eine HAProxy-Instanz vor mehrere Jitsi-Meet-Instanzen zu klemmen…
Sauce: frame out of https://www.youtube.com/watch?v=Jj8a6ZRgehI
und gibt uns eine skizzenhafte Konfiguration für den HAProxy mit.
Da ich im Titel ja die Umsetzung mit den Google Cloud Tools versprochen habe, werde ich in den folgenden Abschnitten aufzeigen, was HAProxy eigentlich macht. So können wir im Anschluss die gleiche Funktionalität mit Google nachbilden.
Was macht HAProxy?
HAProxy, which stands for High Availability Proxy, is a popular open source software TCP/HTTP Load Balancer and proxying solution […].
Oder einfacher gesprochen: Mit dem HAProxy stellt ihr einen Proxy-Server vor eure Web-Server, der Anfragen an diese Annimmt und gleichverteilt an diese weiter gibt.
Über die Konfiguration des HAProxy legt ihre fest, wo eure Backend-Server stehen, wie Anfragen auf diese verteilt werden und wie sich der HAProxy im Frontend gegenüber dem Nutzer präsentiert.
HAProxy stellt ein Frontentd namens jitsi_meet_frontend, welches an Port 433 gebunden wird und dessen ssl-Zertifikat unter gegebenen Pfad zu finden ist. Damit ist HAProxy die Endstelle für die SSL/TLS-Verschlüsselung, so dass diese Aufgabe nicht mehr bei den Jitsi-Meet Servern im Backend liegt.
mode http
option httpclose
option forwardfor
Im http-Modus kann HAProxy auf Basis der Inhalte ankommender HTTP-Requests entscheiden, wie mit der Anfrage umzugehen ist. Da HTTP im Layer 7 — der Anwendungschicht — des OSI-Modells angesiedelt ist, liest man auch manchmal von Layer-7-Mode.
Das Schlüsselwort option beschreibt Optionen zum konfigurierten Modus: httpclose veranlasst HAProxy dazu, nach jeder beantworteten Anfrage die Verbindung zu schließen. Warum macht man das? Ich weiß es auch nicht. fordwardfor belässt den originalen X-Forwarded-For header in der HTTP-request und stellt so sicher, dass Jitsi Meet immer weiß, wo der Nutzer denn nun ist.
Da sich die HAProxy mit den Backend-Server via HTTP unterhält, diese aber aus Gewohnheit HTTPS-Anfragen erwarten, wird der Request ein X-Forwarded-Proto Header angefügt, der den Backend-Servern signalisiert, dass Sie hinter einem load balancer hängen. Als default_backend wird „jitsi_meet“ angegeben, welches hier definiert wird:
backend jitsi_meet
mode http
balance roundrobin
server shard1 shard1.example.com:443 check
server shard2 shard2.example.com:443 check
Dem Backend sind zwei Server angeschlossen, sie sollen shard1 und shard2 heißen und werden mit dem keyword check von HAProxy auf ihre Gesundheit geprüft.
Was in dieser Skizze einer Konfiguration aber noch fehlt, ist die Entscheidungsgrundlage für HAProxy, welche Anfragen wohin geroutet werden.
Wohin mit den Anfragen?
Da eine einzelte Videobridge weiterhin den Knotenpunkt einer Jitsi-Konferenz bildet, müssen Anfragen für einen konkreten Raum auf die selbe Jitsi-Meet-Instanz geleitet werden. Daraus definiert sich eine neue
Aufgabe: Wie konfigurieren wir den Load Balancer so, dass er in Abhängigkeit des Raumnamens aus der URL arbeitet?
Solltet ihr eine überregionale Bereitstellung planen, so kann es sinnvoll sein, die Entscheidung von der Region des Anfragenden abhängig zu machen. Doch Achtung: Am Ende landen alle Teilnehmer auf der gleichen Videobridge und so ist mindestens der Raumersteller nah an der Videobridge. Google Cloud versichert uns aber, überregionale Distanzen mit deren Netzwerk abfedern zu können.
Fazit & Ausblick
In diesem Post konntet ihr einen Überblick über die Möglichkeiten zur Leistungssteigerung eurer Jitsi-Instanz gewinnen. Im nächsten Post dieser Serie gehe ich auf die lastabhängige Bereitstellung zusätzlicher Videobridges in der Google Cloud ein. Stay tuned: folgt uns doch einfach bei Twitter!
In dieser Artikelserie nehme ich euch auf meinem Weg mit, eine hochverfügbare und auto-skalierende Jitsi-Instanz mit Hilfe der Google Cloud Dienste aufzusetzen.
Gegenwärtig sprießen überall im Leben Videokonferenzen aus unseren Endgeräten: Zoom, Skype, MS Teams, Skype for business — Die letzten zwei natürlich untereinander inkompatibel. Sag mal siehst du dich noch, Microsoft? — und auch Jitsi Meet teilen sich den Markt um die Anwender. Alle? Nunja, nicht ganz. Jitsi ist ein Open Source Projekt und hegt keinen Anspruch auf Lizenzgebühren oder ähnliches. Und so kommt es, dass Jitsi dank seines Hintergrund die datenschutzfreundlichste und einfachste Lösung ist.
Warum nutzen wir denn dann nicht alle Jitsi? Nun, dank big old C ist die ganze Welt auf einmal gezwungen gewesen, sofort belastbare und nutzerfreundliche Videokonferenzsysteme an den Start zu bringen. Unter diesem Zeitdrunk sind Unternehmen mit keinen bis kleinen IT-Abteilungen gezwungen, Dienste wie zoom & co. für Geld — und vor allem für Sicherheit — einzukaufen, da man für das Hosten einer Jitsi-Instanz selber Kraft aufbringen muss.
Wenn ihr also interessiert seit und eine stabile Jitsi-Instanz starten wollt, die euch vor eurem Chef nicht wie ein Hobby-Nerd aussehen lässt, dann bleibt dran.
In Kürze folgt ein Post außerhalb dieser Serie, in dem ich euch das Zusammenspiel aller Jitsi-Projekte erläutere. Damit sollten dann die Grundlagen für das Ziel — Skalierung — geschaffen sein.
