Ein Pulsmessgerät

Hintegrund

Burkhard hatte mich Ende Mai 2020 angesprochen, weil er auf meine Webseite zur Pulsüberwachung mittels Ohrclip gestoßen ist. Er hatte sich aus Brocken eines ziemlich teuren Ergometers ein neues Fitnessgerät gebaut, das soweit funktioniert, aber keine Pulsüberwachung hat. Seine Idee war, einen eigenständigen Beat Counter mit meiner Pulsdetektor-Schaltung zu verknüpfen. Dieser Beat Counter (etwas das ich bis dahin noch nicht gekannt hatte) ist ein kleines Gerät mit einer Taste und einem 4-stelligen Display -- man drückt die Taste im Takt der Musik und das Display zeigt einem an, wie viele BPM (Beats Per Minute) das sind. Allerdings fehlten ihm die notwendigen Kenntnisse, um meine Schaltung entsprechend anzupassen. Das Ganze klang also nach einem klassischen Hardware-Hack zu dem ich nicht nein sagen konnte. Mein Vorschlag war, den Taster des Beat Counters mit einem Reed-Relais zu überbrücken und dieses direkt vom OpAmp-Ausgang treiben zu lassen.

Die erste Version der Schaltung hatte nicht funktioniert und die Ferndiagnose war zu schwierig, weshalb Burkard die Brocken dann Ende Oktober entnervt in die Post geworfen hat, damit ich mir die Sache aus der Nähe ansehen konnte. Es war letztendlich ein kleiner Fehler im Aufbau, der leicht zu beheben gewesen wäre. Aber bei näherer Betrachtung des Beat Counters wurde mir bewusst, wie rudimentär die Lösung geworden wäre und ich habe Burkhard vorgeschlagen, mit ihm gemeinsam eine "richtige" Schaltung zu entwerfen. So entstand dann Ende Januar 2021 dieses Projekt. Ja, es war eine bewusste Entscheidung so gemächlich vorzugehen, bevor jemand fragt. ;-)

Die Anforderungen

Zuerst haben wir uns über die Anforderungen unterhalten und kamen zu diesen Must-Haves:

Die letzte Anforderung ist durchaus ernst gemeint: das Gerät soll einfach tun; Einschalten, los geht's. Kein langwieriges Konfigurieren, Button-Rumgedrücke oder sonstwas. Ich war da anfangs etwas skeptisch ob der vielen verschenkten Optionen, aber konnte mich dem Wunsch nach kompromissloser Simplizität dann doch irgendwann gut anschließen.

Dem geneigten Bastler wird gleich auffallen, dass die ersten beiden Punkte natürliche Feinde sind: eine 7-Segment-Anzeige frisst Strom, Batterien haben eine begrenzte Ladung. Primärzellen waren daher ziemlich schnell vom Tisch. Bei den Überlegungen bezüglich Akku und Ladetechnik kamen wir dann überein auf eine USB-Powerbank zu setzen. Damit ist die Ladetechnik gekapselt und die stabilisierten 5 Volt sind genau das, mit dem sich eine kleine AVR-Schaltung am wohlsten fühlt.

Ich konnte Burkhard dann noch zu ein paar weiteren Features "überreden", damit der Mikrocontroller wenigstens ein bisschen was zu tun bekommt:

Anfangs war noch die Idee im Gespräch, die Glättung der Messergebnisse ein- und ausschaltbar zu machen, aber dieses Feature hatten wir dann zur Status-LED umgemodelt. Die Notwendigkeit für diese ist mir nämlich bei ersten "Produkttests" aufgefallen -- ohne ging es einfach nicht. Das Problem mit den Ohrclips ist, dass sie ziemlich gut sitzen müssen, damit sie sinnvolle Ergebnisse liefern. Ohne direktes Feedback gelingt das allerdings schlecht: wenn man nur einen extrem geglätteten Anzeigewert hat, dann ist schwer abzuschätzen, ob alle Schläge erkannt wurden, oder ob da zwischendrin etwas "stolpert". Eine LED, die exakt im Takt des (erkannten) Herzschlags blinkt, ist jedoch sehr leicht mit der Positionierung des Ohrclips in Verbindung zu bringen.

Die Hardware

Burkhard ist ein sehr begabter Bastler was die mechanische Bearbeitung von Materie angeht. Wir hatten uns grob über die Dimensionen unterhalten und wie das Ganze aussehen soll (er hatte schon ein Gehäuse im Blick gehabt). Danach habe ich mich an den Entwurf einer Leiterplatte gemacht und wir haben uns iterativ angenährert. Am 16. März haben wir dann die Leiterplatte beim Platinenbelichter in Auftrag gegeben und Burkhard hielt sie schon am 30. März in den Händen. Mitte Mai war das Gerät dann hardwaremäßig aufgebaut und auf dem Weg zu mir, damit ich dem Mikrocontroller das Leben einhauchen konnte.

[Foto vom Hardware-Aufbau]

Ich hatte dann schnell gesehen, dass Burkhard eine andere Vorstellung bezüglich des Anschlusses der Display-Platine entwickelt hatte. Eigentlich hatte ich vorgesehen, ein 10-poliges Flachkabel direkt von der Oberseite her einzulöten und durch eine Aussparung an der Platinenseite nach hinten zu führen, um es dort mit einem Pfostenstecker auf der Hauptplatine anzuschließen. Durch die Art der Montage war das nun nicht möglich, aber Burkhard hatte einen Pin-Header auf die Platinenunterseite gelötet, mit dem die Verbindung auch möglich war -- nur halt mit spiegelverkehrter Pinbelegung.

[Belegung der beiden Pin-Header]

Der Pin-Header für den Programmieradapter hat zwei Funktionen: zum einen halt zum Programmieren des Controllers, zum anderen aber auch als Steckfeld für die Jumper zur Einstellung der "Blink-Schwelle" und für die Status-LED. Wie bereits gesagt war die Status-LED vorher auch als Eingang für einen weiteren Jumper gedacht, weshalb in dieser Fassung der Hardware dort ein Pulldown-Widerstand von 10k sitzt (der Pin nebendran ist VCC, während bei den anderen Pins der Nachbar jeweils GND ist und somit die internen Pullup-Widerstände des AVRs genutzt werden können). Man könnte ihn einfach auslöten, aber das habe ich nicht gemacht; der Strom ist so klein, dass die Status-LED im Aus-Zustand nicht einmal glimmt.

Die Software

Auf der Software-Seite habe ich mal was Neues probiert. Ich habe ein GPIO-Modul geschrieben, das "GPIO Items" bereitstellt. Diese werden über eine ID referenziert (GpioItemId) und können Werte liefern oder annehmen, wobei der Witz darin besteht, dass diese Werte mehrere Bits umfassen können. Das heißt der Aufrufer muss sich keine Gedanken darüber machen, wie viele Pins dazugehören und wo sie physikalisch liegen -- stattdessen kann er z.B. über die ID GPIO_ITEM_SEGMENTS einen Zahlenwert zwischen 0 und 127 schreiben, der ein Bitmuster für die Ansteuerung eines 7-Segment-Moduls darstellt. Danach kann über GPIO_ITEM_DRIVER_1 der Treiber für Display-Modul 1 aktiviert werden. In UML sieht das ungefähr so aus:

Von der Idee her ist das so ähnlich wie bei meinem avr-classes-Projekt, aber mit den Sprachmitteln von C umgesetzt. Leider ist damit einiges konzeptionell etwas hässlicher geraten, insbesondere dass häufiger IDs übergeben werden müssen, wo in einer objektorientierten Sprache das aufgerufene Ding wüsste, welche Instanz angesprochen ist. Auch die Teilung der Zuständigkeiten ist bei diesem Ansatz nicht so stark ausgeprägt bzw. nur mit Disziplin vorhanden und durch die Funktionsnamen sichtbar. Ein Vorteil ist, dass sich sehr viel über Tabellen ausdrücken lässt, und sich diese via PROGMEM im ROM ablegen lassen. Somit ist der RAM-Bedarf dieser Lösung sensationell niedrig, was bei einem so schmalen Controller wie dem ATtiny2313A extrem hilfreich ist (insgesamt 128 Byte RAM, für Stack und Variablen).

Die restliche Architektur ist eher traditionell gestaltet:

Ich konnte bei dieser Software fast komplett auf statische Variablen verzichten, lediglich die Message-Queue liegt als solche vor, weil sie aus verschiedenen Kontexten genutzt wird. Die einzelnen Komponenten legen ihren Zustand in einer Instanz-Struktur ab, die vom Aufrufer angelegt und bereitgestellt wird. Allerdings hat dieser keinen Einblick, die Datenstrukturen werden nur über von den Modulen bereitgestellte Funktionen manipuliert (Blackbox-Prinzip). Gerne hätte ich die Struktur-Definitionen komplett verborgen, aber da der Aufrufer den Speicher bereitstellen muss, müssen die Strukturen auch inhaltlich bekannt sein.

Die Symmetrie im Komponenten-Diagramm ist zwar hübsch, aber tatsächlich auch mit etwas Zufall zustande gekommen -- die Abhängigkeiten zu "config" ergeben sich z.B. daraus, dass ich hier auch symbolische Namen für Größen wie CFG_UPDATES_PER_MINUTE abgelegt habe. Was aber systematische Gründe hat und damit für das Design typisch ist:

Die Software belegt in Release-Konfiguration XXXX Byte Flash-Speicher und XX Byte RAM. Damit ist der ATtiny2313A recht gut befüllt.

Downloads

Version Datum Änderungen Datei Beschreibung
1.0 2021-xx-xx Erstes Release pulsmesser-1.0.zip Schaltplan im Eagle-Format (Version XXX), Software

Zurück zur Hauptseite