Ein Projekt... mmhh, ja es ist eines geworden. Ich betreibe es schon länger. Und jetzt soll es auch endlich zum Ende kommen. Somit ist die Zeit gekommen, das Projekt in Worte zu fassen, Taten sind schon zu genüge erfolgt.
Ein Wort richte ich an eine besondere Klientel. Kritik ist jederzeit herzlich willkommen, wenn sie nicht aus dem Munde eines Oberlehrers kommt, dessen Einfallsreichtum darin besteht, dass seine Ideen die besten sind. Darüber hinaus hat das Projekt aus der Sicht der Hardware einen Stand erreicht, der keine Änderungen mehr zulässt, wer das nicht bedenkt, beteiligt sich daran, Eulen nach Athen zu tragen.
Eigentlich hatte ich der Elektrotechnik schon längst Adieu gesagt und beinahe wäre aus diesem Projekt auch nichts geworden, wenn ich nicht dem Teufel in letzte Sekunde von der Schippe gesprungen wäre. Und das ist auch gleichzeitig der Haken, an dem dieses Projekt aufgehängt ist, da ich um meine weitere Rehabilitation bemüht bin. Ein Ergometer, wie ich es unter medizinischer Betreuung kennengelernt habe, wäre zwar super, ist aber für den normalen Hausgebrauch unerschwinglich, zumindest nicht für Leute, die nur über ein normales Taschengeld verfügen. Bleiben noch die üblichen Händler oder dass was der Gebrauchtmarkt so hergibt.
Was die Mechanik des erworbenen Ergometers betrifft hab' ich wohl ein Schnäppchen machen können, die Elektronik ist dagegen entsprechend dem Zeitgeist flickernd, blickend und glitzernd ausgelegt, Consumer-Elektronik der billigsten Machart. Die Bedienung ist alles andere als einfach. Mein Sohn wusste um meine Talente und war der Meinung, die Elektronik durch einen Raspberry Pi ersetzen zu können. Das war zwar im generell blauäugig, er hatte schließlich auch den RasPi und einen Bildschirm herumliegen, Teile, die er auf diese Art und Weise einer sinnvollen Verwendung zuzuführen gedachte. Ich habe mich darauf eingelassen, für eine Umkehr ist es mittlerweile zu spät.
So habe ich ein Projekt gestartet und bin schnell zu dem Ergebnis gekommen, ohne zusätzliche Hardware, würde das Projekt nicht realisierbar sein. Der vorgesehene Bildschirm war in der Art ausgelegt, dass der RasPi auf der Rückseite des Bildschirms aufgesteckt wird, womit der Zugang zu freien GPIOs schon aus physischer Sicht unmöglich war.
Den Bedarf der zusätzlichen Hardware hatte ich schnell skizziert. Und es stellte sich sehr bald heraus, dass die Zwangsehe, die zwischen Raspberry Pi und dem Bildschirm von Waveshare geschlossen wurde, nur dem Funktionieren des Touchpanels geschuldet war, das über ein SPI und einem IRQ mit dem Raspberry Pi kommunizierte. Die folgende Darstellung gibt einen Gesamteindruck der Hardware wieder, die für dieses Projekt erforderlich wurde.
Das Elektroschema ist das CAD-Ergebnis des Paketes von DipTrace, aus dem dann später auch das PCB-Layout entstanden ist. Die verschiedenen Abschnitte werde ich noch ausführlich beschreiben. Das Elektroschema ist aber kein gewöhnliches, sondern dahinter verbirgt sich ein nicht unbeträchtlicher Anteil an Organisation, mit der das spätere PCB-Layout realisiert wird. Hinter jedem Schaltzeichen verbirgt sich der Footprint eines Bauteils, hinter jeder Verbindung steht eine Zuordnung zu Attributen eines Netzwerks.
Für den Betrieb der Kombination aus Raspberry Pi und Bildschirm hätte ich zwei Netzgeräte vorsehen müssen, der kombinatorische Betrieb via nur einer Speisung über die Mini-USB des Raspberry PIs führte zu Fehlfunktionen.
Ich habe daher eine zentrale Stromversorgung vorgesehen und das vom Hersteller beim Raspberry Pi realisierte Speiseprinzip abgekupfert, um so die für den Raspberry Pi vorgesehenen Schutzfunktionen nicht zu unterlaufen. Die Bauelemente D101 und F101 zählen dabei zu den wesentlichen Teilen. Über die Buchsenleiste X101 (2 x 20 Kontakte) wird nun die Zusatzplatine mit dem Raspberry Pi verbunden. Über die Pins (+5V) wird nun der Raspberry Pi "rückwärts" mit Energie versorgt. Die Spannung an den Pins (+3,3V) der Buchsenleiste X101 stammt dagegen jedoch selbst aus dem Raspberry Pi und wird für weitere, aber eingeschränkte Zwecke verwendet. Da die ganze Unternehmung sich eigentlich immer noch im Stadium des Prototyping befindet, habe ich z.B. mit ST102 für einen stabilen Messpunkt gesorgt, der auch mal ein Fliegenbein verträgt.
Die Beschriftung der Buchsenleiste X101 habe ich nach der vorgegebenen Ordnung vorgenommen und je nach Bedarf durch weiter Begriffe ergänzt. Ich habe die Schnittstelle des Hardware-PWMs aus der Bibliothek pigpio verwendet, dies sind die beiden Pins GPIO12/PWM_fwd und GPIO13/PWM_rev. GPIO0 und GPIO1 sind bei mir "deprecated", ich habe sie in der ganzen Zeit der Erprobung nicht dazu bewegen zu können, sich meinem Willen unterzuordnen.
Dadurch dass das Touchpanel eine SPI des Raspberrys schon in Beschlag genommen hat, war ich natürlich gezwungen, die Unterscheidung zu einer zweiten SPI herbeizuführen. Das Touchpanel ist über GPIO10/TP_SI, GPIO9/TP_SO, GPIO11/TP_SCLK und GPIO7/TP_CS verbunden, zusätzlich meldet sich das Touchpanel über GPIO25/TP_IRQ noch beim Raspberry Pi, wenn eine Bedienung über das Panel erfolgt ist.
Soweit notwendig werden weitere GPIOs später noch detailliert beschrieben.
Wie bereits an anderer Stelle erwähnt, habe ich eine zweite SPI aufgemacht, ohne dabei auf Systemfunktionen des Raspberrys zugreifen zu müssen. Diese Schnittstelle wird gebildet aus GPIO4/MISOx, GPIO14/SLCKx, GPIO15/MOSIx, GPIO17/CSx0 (chip select des ADC) und GPIO27/CSx1 (chip select des EEproms). Für das EEprom hätten ggf. 2 weitere GPIOs vorgesehen werden können, jedoch habe ich bei dem Hold-Eingang darauf verzichtet.
Beim EEprom habe ich es schon angesprochen, dessen SPI dient auch zur Kommunikation mit dem AD-Wandler. Nur die CS-Leitung ist eine andere. Ganz wichtig, das habe ich ernsthaft mit Franky07 diskutiert, war die Versorgung des ADCs mit einer "sauberen" Spannung, daher die Anbindung an "Power (2)", auf die ich später noch zu sprechen komme. Es gibt außerdem noch den Jumper J141, dem eigentlich nur in der Phase des Routens eine Aufgabe zufällt. Durch diesen "Trick" soll verhindert werden, dass sich "digitaler Schmutz" auf dem "AGND"-Potential ansammeln kann, weil durch seine separate Führung niemals digitale Ausgleichsströme auf analogen Pfaden fließen können.
Zwei Kanäle des MCP3204 nutze ich intern
- zur Abfrage eines Potentiometers
- zur Abfrage eines RC-Netzwerkes, das einer Impulsstufe nachgeschaltet ist.
Um eine spätere Verwendbarkeit der zur Zeit nicht genutzten Kanäle nicht auszuschließen, sind diese auf 3-polige Stiftleisten gelegt, die leicht nachgerüstet werden können.
Obwohl der Raspberry PI auch seine selbst erzeugten 3,3 Volt anbietet, habe ich mich dazu entschlossen, unabhängige Referenzen zu bilden:
- das Potential "Ref 3.3"
- die beiden Powerlinien "Power (2)" und "Power (3)"
"Ref 3.3" dient ausschließlich dazu den Pin "VRef" des MCP3204-Bausteins zu versorgen. Der Sinn dieser Übung liegt darin, den Pin dieses Bausteins von anderen Einflüssen frei zu halten. Alles was sonst noch mit dem ADC zu tun hat, wird über "Power (2)" gespeist. Ein 1-facher OPV hätte es auch getan, doch die Gehäuseform des 2-fachen OPVs gleicher Grundtype ist bei einem Pitch von 1,27 mm deutlich besser zu handhaben als 0,76 mm, wenn man auf manuelles Löten angewiesen ist. Und so musste ich nicht lange suchen, um einen Verwendungszweck für "Power (3)" zu finden.
Der Bildschirm mit Touchpanel wird nach gleichem Muster versorgt, wie auch der Raspberry Pi. Bei der Kombination aus D131 und F131 handelt es sich um eine TVS-Surpressordiode und eine selbst rückstellende Sicherung PPTC. Bei der 26-poligen Buchsenleiste sind effektiv nur die näher bezeichneten Pins belegt. Trifft die 26-polige Buchsenleiste auf die 40-polige Stiftleiste des Raspberry Pi, so wird klar, dass keine Chance besteht, auf einem einfachem Wege die freien GPIOs des Raspberry Pi zu nutzen. Das Touchpanel ist auf die +3,3 Volt aus dem Raspberry Pi kommend angewiesen, um das SPI (TP_SO) und den Interruptrequest (TP_IRQ) zu bedienen, die anderen Signale (TP_SI, TP_SCK, TP_CS) sind aus der Sicht des Raspberry Pi aktiv.
Rein vorsorglich habe ich die meisten der noch frei verfügbaren GPIOs auf eine 2-reihige Pinleiste (X104) verschaltet. Jedem so verfügbarem GPIO liegt ein GND-Pin gegenüber. Sollte sich jemals ein Bedarf ergeben, so sollte es keine Schwierigkeiten bereiten, eine Anwendung auch wirklich ohne mechanische Schwierigkeiten durchzuführen.
Ein bisschen Strom muss schließlich auch über ordentlichem Wege an das System gelangen können. Dazu habe ich eine 10-polige verriegelbare Steckvorrichtung vorgesehen. Jeder Kontakt ist gut für 5 A, das wirkt zwar etwas übertrieben. Aber angesichts der Tatsache, dass der Raspberry Pi schon gute 2,5 A für sich alleine beansprucht, wobei sich Waveshare dagegen über jegliche Verbrauchsangabe vornehm ausschweigt, die Erfahrung aber gezeigt hat, dass auch Waveshare gut versorgt sein möchte, so habe ich je 2 Kontakte für die Energiezuführung vorgesehen. Über 3 weitere Kontakte wird ein Potentiometer angeschlossen, 1 Kontakt übermittelt die Impulse zur Erfassung der Trittdrehzahl und last but not least braucht es noch 2 weitere Kontakte um das Motörchen der Seilwinde betreiben zu können. Mit dem Messpunkt ST101 biete ich einen stabilen Zugriff auf das Massepotential an.
Ursprünglich hatte ich vorgesehen, die Impulse zur Erfassung der Trittdrehzahl direkt auszuwerten. Doch mein mangelhaftes Vertrauen in Python hat mich davon abgehalten. Spätere Versuche mit dem Raspberry Pi unter Python eine stabile Frequenz zu erzeugen haben mein Misstrauen bestätigt. So habe ich die Idee entwickelt, mit den Impulsen, die an Tretkurbel des Ergometers erzeugt werden, seinerseits Impulse mit konstanter Dauer zu erzeugen, die am Ausgang des TCL555 über den Widerstand R153 die beiden Kondensatoren C155 und C156 aufladen. Über das nachgeschaltete Filternetzwerk gelangt der Ladezustand dieser Kondensatoren an den Eingang des AD-Wandlers, der ohnehin zur Erfassung eines Potentiometers vorgesehen war. Die gesamte Schaltung hatte ich zuvor in Spice simuliert. Bei konstanter Trittdrehzahl von 60 Umdrehungen in der Minute, muss der Impulseingang ein Signal mit einer Frequenz von 24 Hz liefern. Zwecks Abgleich gibt es die 3-polige Stiftleiste X151 mit der ich die Signalquelle umschalten kann. Auf "In1" liegt dann ein Frequenzsignal, das vom Raspberry selbst erzeugt wird. Die Frequenzkonstanz dieses Signals war allerdings sehr ernüchternd. Aus dieser Erfahrung ist im letzten Augenblick der Anschlusspunkt X152 entstanden.
Auf lange Sicht werde ich überlegen, die Anwendung von Python zu verwerfen. Sollte sich das bis jetzt in Python entworfene System nicht bewähren, wird ein Wechsel auf C/C++ die unausweichliche Folge sein. Aber bis dahin werden noch einige Tage vergehen. Ich hoffe aber, dass ich mit diesem 555er-Trick, das inkonsistente Verhalten von Python überwunden habe.
Die Sache mit der Trittdrehzahl ist von immens wichtiger Bedeutung, was den gesamten Aufwand ein wenig erklärt. Beim Ausdauertraining geht man davon aus, dass eine bestimmte Leistung über einen bestimmten Zeitraum erbracht werden soll. Ändert sich die Trittdrehzahl, ändert sich auch die erbrachte Leistung, wenn nicht der Gegenwiderstand über die tatsächliche Drehzahl nachgeführt wird, so dass die Leistung, die man als Anwender auf dem Ergometer erbringen muss konstant bleibt. Dieser Regelkreis, der sich dahinter verbirgt, erfordert eine einwandfreie Erfassung der durchschnittlichen Trittdrehzahl. Die Anforderungen sind dementsprechend hoch.
Mein Motörchen für die Seilwinde benötigt 12 Volt. Ein extra Netzteil wollte ich dafür nicht spendieren, da war es sofort klar, dass ich einen Step-Up-Wandler spendieren würde. Die Schaltung habe ich verschiedene Male schon erprobt und liefert maximal 1000 mA. Das Motörchen hat eine Nennleistung von 4 Watt, das macht rein rechnerisch 333,33 mA. Wenn ich die physischen Gegebenheiten berücksichtige, werde ich von der zur Verfügung stehenden Nennleistung nur einen Bruchteil, also weniger als 1% in Anspruch nehmen. Die Schaltung ist also reichlich überdimensioniert. Versorgt wird dieser Zweig auch wieder über die bekannte Kombination aus D201 und F201.
Bei diesem Teil der Schaltung habe ich einen meiner Grundsätze über Bord geworfen, keine Bauteile zu verwenden, die schon abgekündigt sind. Der Baustein ZXBM52 hat mir so gut gefallen, dass ich von meinen Grundsätzen abgerückt bin. Franky07 hat mich auf den Pfad der Tugend zurückgebracht und davon abgeraten, den Raspberry Pi direkt den Tücken eines Gate-Durchschlages auszusetzen. Aus diesem Grunde steuert der Raspberry Pi den Baustein über Optokoppler an.
Der Eingang "Vm" wird von der Spannung gespeist, die mittels des Step-Up-Wandlers aus dem vorhergehenden Abschnitts erzeugt wird. Am Eingang "VRef" liegt zwar eine "edle" Spannung an, sie wird aber dort nur aus der Sicht des Pegels gesehen, die Qualität ist nicht entscheidend, weil der Baustein in einem Modus betrieben wird, in dem das PWM-Signal bereits an die Eingänge "FWD" bzw. "REV" geführt wird.
So bleibt zum Schluss noch die Geschichte über den Empfänger für die Werte des Plusschlages. Ursprünglich hatte ich vorgesehen, den Pulsschlag mittels Bluetooth ins System einzuspeisen. Es hätte verschiedene Möglichkeiten unter Python geben sollen, das Vorhaben auch zu realisieren. Gescheitert ist dies letztendlich an vielen profanen Kleinigkeiten - Inkompatibilitäten der verschiedensten Python-Versionen oder Bluetooth-Libs, die veraltet waren. Ich habe dann den Entschluss gefasst, die 5,3 kHz Technik anzuwenden, dazu gab's schließlich auch einen Schaltungsentwurf, den ich realisiert hatte. Alleine mir fehlte zum Schluss die Geduld den Resonanzkreis zum Laufen zu bringen. Beim China-Ali hatte ich seinerzeit einen RF-Empfänger bestellt, der jetzt zum Tragen kam. Und ich somit die Entwicklung abschließen konnte. UPS hat mir gerade mitgeteilt, dass mich die neue Platine Montag erreichen wird.
Wenn ich die zurückliegende Zeit überdenke, waren es vielfach Klippen, die mir als Nichtkenner der Raspberry-Szene und dabei besonders als Nichtkenner der Python-Scene einige Mühen bereitet haben. Einige Anlässe dieser Art waren unnötig, da sie sich ausschließlich auf oberflächliche Formalitäten bezogen haben. Ich habe Fortschritte in Python gemacht, ob ich aber bei Python bleibe, erscheint mir eher zweifelhaft. Der angebliche Vorteil einer höheren Abstraktionsebene, kann der Interpreter nicht mehr wett machen. Bei einer deterministischen Vorgehensweise schmilzt dieser Vorteil wie Eis in der prallen Sonne.
Nun gut, zunächst werde ich das gesamte Projekt noch in Python vorstellen.
