Transreflexives OBS-Display

Design & Entwicklung
#5

So, nun sollten auch die Schriften quasi so wie bei der bisher verwendeten Bibliothek sein.
Ich bin zunächst diverse bei U8g2 mitgelieferten Schriften ausprobiert, aber nur eine der kleinen (timR08) war auch so schmal wie die bisherige OpenSans, und diese hat mir aufgrund von Serifen nicht zugesagt. Daher habe ich die konvertieren OpenSans von @gluap probiert, hier waren aber die Schrifen zu groß. Offenbar ist die Einheit der Schriftgröße zwischen den beiden Displaybibliotheken verschieden.
Durch Ausprobieren und Rechnen kam ich dann aber auf gute Werte für TINY_FONT, SMALL_FONT, MEDIUM_FONT, LARGE_FONT. Nur bei HUGE_FONT bin ich mir nicht ganz sicher, da ich noch nicht herausfinden konnte, wann diese überhaupt verwendet wird.

Tatsächlich kann auch ich meinen PR auf Github nicht aufrufen, wenn ich nicht eingeloggt bin. Wohl irgendein Problem bei Github, das ich nicht lösen kann. Daher habe ich meinen Fork nun zusätzlich auf Codeberg gepusht: j000bs/OpenBikeSensorFirmware: Fork of https://github.com/openbikesensor/OpenBikeSensorFirmware/ - Codeberg.org

Man könnte wohl zur Erkennung des Displays beim Start der Firmware einen kurzen I2C-Scan der infrage kommenden Adressen machen, und falls keines gefunden wird SPI wählen. Da es bei SPI keinen Rückkanal gibt (MISO ist ungenutzt) gibt es hier jedoch keine Möglichkeit, das Display zu erkennen.

1 „Gefällt mir“
#6

Ich glaube @andreas meinte auch: Idealerweise müssten wir in der Firmware erkennen, ob wir mit einem transflexiven oder einem OLED-Display reden müssen, und dann den richtigen Codepfad wählen. Zumindest, wenn wir nicht zahlreiche verschiedene Firmwares gleichzeitig pflegen wollen. Eine Alternative wäre noch, das beim Firmwareupdate zu erkennen und im Buildprozess firmware für verschiedene Displayvarianten auszugeben, während die jeweils anderen codepfade z.B. aus-ge-ifdefed werden, aber optimal wäre natürlich eine Firmware, die merkt, ob sie i2c transflexiv, i2c oled oder i2c SPI macht, und dann das Display auf die richtige Art und Weise ansteuert.

#7

Ja, so hatte ich @andreas auch verstanden – tut mir leid ich das in meiner letzten Nachricht nicht klar formuliert habe.
Ich denke auch, dass es besser ist, wenn die Firmware automatisch das Display erkennen kann und zur
Laufzeit die entsprechende Ansteuerung wählt, dafür also nicht unterschiedliche FW-Versionen notwendig sind.
Die über I2C angeschlossenen Displays kann man relativ gut erkennen, da diese ja spezifische I2C-Adressen haben – somit kann man einfach einen Lesebefehl an die Adresse schicken, und schauen, ob eine Antwort kommt. Und wenn sie kommt eben dieses Display verwenden.
Das SPI-Display muss dagegen dann als Rückfalloption gewählt werden. SPI hat eigentlich eine separate Leitung als Kommunikation vom Gerät zum Host (MISO), diese ist aber bei dem JHD12864-G156-Display nicht vorhanden – bei einem Display reicht es ja grundsätzlich auch, wenn Daten nur in eine Richtung fließen können. Nur ist es dadurch eben dann nicht möglich, etwas an das Display zu schicken und anhand des Antwortverhaltens zu erkennen, ob bzw. welches Display angeschlossen ist. Solange wir aber nur ein SPI-Display haben ist das noch kein Problem.

Ich werde schauen, dass ich diese Logik in den nächsten Tagen in meinen Fork einbaue, und gebe dann wieder hier Bescheid.

1 „Gefällt mir“
#8

Cool, das schaut ja schon fertig aus ;). Bei weiteren Varianten müssten wir eventuell freie GPIOs verwenden um die Variante automatisch zu erkennen.

Wie bekommen wir das am besten auf Github, idealerweise auch den PR für u8g2.

#9

Ja, theoretisch ist es quasi fertig, aber ich kann es erst Mitte nächster Woche mit den Displays testen. Daher noch die Todos im Code.
Ich habe es gerade nochmal mit Github probiert, 2-Faktor-Auth aktiviert und den PR neu erstellt, will aber immer noch nicht. Vielleicht ist über den Github-Support noch etwas zu machen, könnte ich nächste Woche mal probieren.
Ich bin aber auch bereit meine Patches unter CC0 / Public Domain zu stellen, dann könnte jemand mit funktionierendem Github-Zugang die Branches auf seinen Account pushen und die PRs erstellen.

1 „Gefällt mir“
#10

Ich denke, die git-native Methode wäre, dass jemand lokal @j000bs’ codeberg repo als zusätzliche remote zu einem ausgecheckten github-fork von OpenBikeSensorFirmware hinzufügt, den branch holt und auf github pusht und wir dann von diesem Branch den PR machen können. Ich bin nicht ganz sicher, wie man pull requests zwischen unterschiedlichen git-hostern sonst angehen würde. Von welchem gh-account + Repo kommt denn der nicht funktionierende PR?

In meinem fork von OpenBikeSensorFirmware ging das so::

git remote add j000bs https://codeberg.org/j000bs/OpenBikeSensorFirmware.git 
git pull j000bs u8g2-displaylib
git checkout u8g2-displaylib
git push origin u8g2-displaylib

Ein test-PR auf diesem Weg hat für mich funktioniert.

#11

…oder im Zweifel ein gutes altes diff erzeugen? Das kann jeder einfach einspielen.

1 „Gefällt mir“
#12

Das wäre dieses Repo und dieser PR. Liefert bei mir aber beides, wenn ich nicht eingeloggt bin, ein 404.

Ich habe heute noch die Display-Invertierung gefixt und mit allen drei Displays getestet. Ich denke, dass nun alles geht.
Dennoch ist es wahrscheinlich (noch) nicht sinnvoll, meinen Branch so zu mergen, da der OBS Pro ja aller Voraussicht nach doch eine separat gebaute FW-Variante bekommt (siehe hier), und damit die automatische Displayerkennung ja gar nicht mehr notwendig oder sinnvoll wäre.
Es sei denn, dass wir doch noch das transreflexive I2C-Display (JHD12864-G98BTW) mit unterstützen wollen…

Ansonsten könnten wir aber überlegen, ob wir schon den Wechsel auf U8g2 machen wollen. Ich habe dafür gerade mal schnell einen neuen Branch erstellt, auf dem nur die fünf Commits für den Wechsel auf U8g2 drauf sind, aber noch nicht die Unterstützung für die beiden anderen Displays.

Welche der beiden genannten Möglichkeiten zum Übertragen der Änderungen auf Github wir nehmen, ist mir egal. Mir ist im Prinzip auch egal wer am Ende als Autor da dran steht.

1 „Gefällt mir“
#13

Wieder in Absprache mit @fabian habe ich ein PCB für das SPI-Display (JHD12864-G156BT) entworfen, welche mit der aktuellen OBSPro-Version (2.0) verwendet werden könnte. Das Ergebnis findet sich wieder auf Codeberg.

Die Orientierung ist in KiCAD quasi um 180° um die X-Achse gedreht. Die Anschlüsse und der Schiebeschalter für die Hintergrundbeleuchtung sind also unten, sodass das Gehäuse nur da eine Öffnung bräuchte und ansonsten die Elektronik halbwegs vor Wasser schützen kann.

Ich habe mich entschieden, den Push-Button nicht auf dem PCB vorzusehen. Es hätte sonst ein recht flacher werden müssen, in wasserdicht habe ich da nichts passendes gefunden. Stattdessen hat das PCB nun eine Buchse, über die dann mit Kabeln ein Button angeschlossen werden kann. Damit dieser ggf. direkt neben dem Display sitzen kann habe ich auf beiden Seiten der Platine Einkerbung vorgesehen.

Bis auf die Platzierung von den 0603-Bauteilen und dem Routing ist die Platine aus meiner Sicht fertig. Bin aber auch noch für Änderungen offen, auch noch, nachdem ich vrstl. morgen das Routing gemacht habe.

EDIT: Das Routing ist nun auch fertig. Ich habe dabei nochmal die Position vom Schiebeschalter und Button-Stecker getauscht, da sich das fürs Routing als günstiger herausstellte.

#14

Das sieht doch schon mal gut aus.
Was mir jetzt noch nicht so ganz klar ist: Wir hatten ja darüber gesprochen das Kabel abnehmbar zu machen und deshalb schaut die 8-pol Buchse über die Platine hinaus. Aber warum sitzt die Buchse für den Button an der gleichen Stelle? Dann kommt das Kabel doch auch aus dem Gehäuse raus, oder?

#15

Was die Wasserdichtigkeit angeht habe ich jetzt auch keine gute Idee. Aber nen schicken SMD-Taster findet man schon - immer noch besser als tausend von den Dingern krimpen zu müssen. Bei Reichelt wäre z.B. „KAPPE 1ZCS SW“ in Kombination mit „MEC5E SMD“ ne schöne Lösung, finde ich.

#16

Meine Überlegung war zum einen, dass die Displayeinheit halbwegs wassergeschützt sein sollte, also zumindest kein Regenwasser durch oder am Button vorbei zum PCB laufen können sollte. Daher hatte ich auf LCSC nach Button geschaut, die einen entsprechen IP-Schutz haben. Da gibt es zwar auch ein paar wasserfeste SMD-Taster, aber die gegen das Gehäuse abzudichten schien mir dann schwieg.
Daher schien mir dann ein größerer Button, der separat ist (also etwa neben dem PCB im Gehäuse), die bessere Lösung zu sein. Ein dafür infrage kommender Button wäre dieser.

Wenn man diese JST-Stecker schon fertig mit mit Kabeln kauft müsste man wahrscheinlich doch „nur“ die Buttons mit dem Kabel verbinden?

Wir könnten natürlich auch auf Wasserschutz fürs erste ganz verzichten und zugunsten einfacherer Herstellung so einen SMD-Taster mit Kappe verwenden. Wäre dein Vorschlag, die über Reichelt zu beziehen, oder war das nur ein Beispiel?

Ich hatte auch noch die Idee, eine Möglichkeit vorzusehen, den Button separat am Fahrrad montieren zu können. Dann könnte der z.B. in Griffnähe sein, das Display aber mittig am Lenker. Zusammen mit der Überlegung zum Wasserschutz folgte daher für mich die Position der JST-Buchse unten neben 8-Pol-Anschluss zur Hauptplatine.

#17

Hmm, ok. Wenn man den fest verbaut im gleichen Gehäuse, könnte man natürlich auf die Buchse auf der Platine verzichten und einfach direkt einlöten. Sind halt ne Menge mehr Arbeitsschritte als nur den Dome drauf zu drücken. Vom externen Button würde ich erst mal weit Abstand nehmen wollen :wink:

Wenn wir es wasserdicht hinbekommen wollen, müssen wir aber das Display auch dicht bekommen. Entweder mit Klebestreifen zwischen Display und Gehäuse - keine Ahnung ob man das so wasserdicht bekommt - oder nen Glas ins Gehäuse einkleben. Letzteres wäre vermutlich sogar möglich, ich bekomme Montag meine CNC-Fräse mit der man nen Polycarbonat-Fenster zurechtfräsen könnte. Ein schneller Check mit der Uhu-Klebeberatung sagt aber, dass das nicht so einfach ist (keine Ergebnisse).

Dazu kommt: Wenn das Display wasserdicht ist, macht es keinen Sinn den Stecker am Display zu haben. Das Kabel soll ja am ehesten am Rad bleiben.

#18

Noch was: Wenn man den Stecker von LCSC dafür nimmt, könnte man es trotzdem so machen, dass der durch die Platine durch geht und diese gleichzeitig fest hält. Also von oben nach unten: Stecker, Gehäuse-Deckel, Platine, Mutter.

#19

Ich würde eigentlich die Variante mit einer Kunstoffglasplatte bevorzugen. Neben Polycarbonat kämen vieleicht auch noch Acrylglas, Plexiglas oder andere infrage – da kenne ich mich aber leider nicht aus.
Es gibt auch diverse Anbieter, die einem solche Platten zuschneiden – bei den ersten, die ich online gefunden habe (expresszuschnitt.de, kunststoffplattenonline.de, plattenzuschnitt24.de) ist die Mindestgröße aber 50x50 mm. Wir brauchen wohl ca. 38x33.5 mm, und max. 1 mm dick. Ich würde nochmal nach anderen Anbietern suchen.
Ich denke, dass sich da auch ein geeigneter Kleber für findet.

Stimmt, man müsste dann eigentlich keinen Stecker mehr rausführen, sondern könnte eher einen Kabeldurchgang unten im Gehäuse machen. An der Platine selbst würde ich aber schon noch einen (einfacheren) Stecker vorsehen und das Kabel nicht direkt anlöten, sodass es z.B. einfach möglich ist etwas zu tauschen.

Vermutlich meinst du statt Stecker den (oben verlinkten) Button? Welchen Vorteil hätte es, den auch durch die Platine hindurchzuführen?

#20

Ja, da wird man auch jemanden finden der kleine machen kann. Einfach schneiden reicht aber nicht. Das muss schräg geschnitten werden oder besser mit ner Kante drin, damit das Glas wirklich drin sitzt und der Kleber es nur in Position hält. Also ist da nichts mit einfach ausschneiden/lasern.

Ja, meinte ich. Vor allem etwas Platz-Ersparniss weil man kein Abstand von Platine zu Mutter braucht. Und evtl. könnte es den Zusammenbau erleichtern, wenn man zwei Schrauben weniger rein drehen muss.

#21

@fabian und ich haben uns nochmal außerhalb dieses Threads ausgetauscht.
Plan ist nun, die Displayeinheit mit dem Button unter dem Display zu entwerfen. Als Button soll der oben verlinkte, wasserfeste von LCSC, eingesetzt werden.
Das 8-polige Kabel geht dann unten heraus und wird evtl. ebenfalls noch abgedichtet. Auf einen Schalter für die Display-Hintergrundbeleuchtung wollen wir verzichten, um den nicht auch Abdichten zu müssen, da die max. 5 mA Strombedarf auch nicht wirklich ins Gewicht fallen.

Ich werde im laufe der Woche den PCB-Entwurf entsprechend anpassen und dann wieder hier schreiben.

3 „Gefällt mir“
#22

Ich konnte doch erst heute wieder richtig daran weiter machen und habe nun die Schalter für die Hintergrundbeleuchtung aus dem Schaltplan gestrichen. Ein Test mit dem Display ergab, dass 2 mA für die Hintergrundbeleuchtung völlig ausreichend sind, sodass ich entsprechend einen 1.5 kΩ -Widerstand vorgesehen habe.
Wie besprochen sitzt nun der bekannte Push-Button unter dem Display und geht durch das PCB hindurch, entsprechend ist eine größere Aussparung dafür im PCB.
Für die Verbindung zur OBSPro-Hauptplatine habe ich nun einen Pinheader im 2.54mm-Raster vorgesehen.
Den JST-Stecker für den Button habe ich fürs erste drauf gelassen – Platz ist da, und muss ja nicht bestückt werden. Alternativ zu dem Stecker gibt es noch die Pads J4 und J5.

Der aktuelle Stand wieder auf Codeberg.

#23

Sehr schick!
Gibt’s nen Grund, dass die Bohrungen für die Befestigung nur 2,2mm sind? Hätte da jetzt wie bislang auch überall auf M3 gesetzt.

#24

Hatte nur den Grund, das ich nicht wusste das sonst M3 eingesetzt wird. Habe es gerade schnell zu M3 geändert.
Das Routing würde ich vrstl. morgen angehen.

2 „Gefällt mir“