Freaky-blue
::Matschbombe::
- Registriert
- 8. Mai 2013
- Reaktionspunkte
- 5.160
Unsere Beiträge haben sich überschnitten, aber ich seh da folgendes "Problem":
Softwareunterstützter Laufradbau mit günstigen Bauteilen von Aliexpress
- Ersteller dunkelfalke
- Erstellt am
-
- Schlagworte
- aliexpress laufradbau speichen
Unsere Beiträge haben sich überschnitten, aber ich seh da folgendes "Problem":
Anzeige
dunkelfalke
Schraubär
Sobald die Grundfunktionalität komplett läuft, werde ich die Berechnung einstellbar machen, und alle Ideen, die zur besseren Berechnung führen, werden als Option da sein.
dunkelfalke
Schraubär
Kleiner Zwischenstand: seit gestern Abend hatte ich keine Updates auf dem github weil ich versucht habe, die Arduinosoftware auf ESP32 zu portieren - ESP32 ist 100 mal performanter, hat Bluetooth, viel Speicher usw. Mir ging es vor allem um Bluetooth, damit zwischen dem PC und dem Spokeduino kabellose Verbindung da ist. Dachte, das wäre keine große Sache, mache ich mal eben in einer halben Stunde.
Nun ja, die reine Portierung und die Bluetoothanbindung haben auch wirklich nur so lange gedauert, aber dann hat es sich herausgestellt, dass die analogen Eingänge vom ESP32 Mist sind - rauschen zu sehr. Habe dann probiert, einen Signalverstärker aus den Bauteilen zu bauen, die ich noch in der Grabbelkiste habe, damit ich die digitalen Eingänge nutzen kann. Funzt aber trotzdem nicht und der Messuhr scheint der Verstärker nicht zu schmecken - die resettet sich jede 30 Sekunden auf 2.54mm.
Lange Rede, kurzer Sinn, Bluetooth wird erstmal pausiert, bis ich Bauteile für einen vernünftigen Verstärker habe.
Nun ja, die reine Portierung und die Bluetoothanbindung haben auch wirklich nur so lange gedauert, aber dann hat es sich herausgestellt, dass die analogen Eingänge vom ESP32 Mist sind - rauschen zu sehr. Habe dann probiert, einen Signalverstärker aus den Bauteilen zu bauen, die ich noch in der Grabbelkiste habe, damit ich die digitalen Eingänge nutzen kann. Funzt aber trotzdem nicht und der Messuhr scheint der Verstärker nicht zu schmecken - die resettet sich jede 30 Sekunden auf 2.54mm.
Lange Rede, kurzer Sinn, Bluetooth wird erstmal pausiert, bis ich Bauteile für einen vernünftigen Verstärker habe.
Anhänge
dunkelfalke
Schraubär
Bei den Sensoren ist es ja üblich, falls die rauschen, mehrmals einen Messwert zu nehmen und einen Durchschnitt daraus zu bilden - das gleicht das Rauschen etwas aus. Würde es denn was bringen, wenn möglich, die gleiche Speiche mehrmals zu messen, besonders, wenn ich die in mehreren unterschiedlichen Längen habe, und dann einen Durchschnitt aus den Messungen zu bilden?
Freaky-blue
::Matschbombe::
- Registriert
- 8. Mai 2013
- Reaktionspunkte
- 5.160
Ich hätte folgende Vorschläge, die ich als komfortabler ansehen würde.
Wenn ich mir deine Eingabemaske ansehe, hätte ich da folgende Punkte:
1
Ich würde die Messunkte nicht fix vorgeben. Also nicht 300, 400, 500... sondern die Möglichkeit offen lassen den Wert einzutragen, den die Zugwaage eben gerade anzeigt. Ob das exakt 700N sind oder 683N oder 726N sind, spielt für die Erstellung der Ausgleichskurve absolut keine Rolle, solange der angezeigte Tensiowert zu dem Anzeigewert der Zugwaage passt.
2
Ich würde auch nicht fix einen Messbereich von 300N bis 1600N vorgeben. Je nach getesteter Speiche könnte das schon sehr viel sein und auch gar nicht nötig. Wenn eine windige Speiche eh nur vorne rechts oder hinten links zum Einsatz kommen soll, dann reicht da auch ein geringerer maximaler Wert.
3
Ich würde auch keine Reihenfolge für die Messwerte vorgeben. Wenn man die Speiche spannt würde ich logischerweise beim geringsten Wert von um die 300N beginnen und mich dann schrittweise bis zu meinem angestrebten Maximalwert vorarbeiten. Wenn die Speiche nun aber schon mal gespannt ist, dann würde ich auf dem "Rückweg" zum entspannten Zustand der Speiche auch nochmals Messpunkte abfahren.
4
Meinen nächsten Punkt hast du schon genannt:
5
Ich würde bei der Eingabe eine Möglichkeit zur Umschaltung zwischen kgf und N schaffen, falls eine Zugwaage nur kg anzeigen kann. So umgeht man eine händische Umrechnung und man kann in der Maske gleich den Wert für kgf zusammen mit dem Tensiowert eingeben. Intern würd ich aus Gründen der Gewohnheit immer mit Newton rechnen und nur bei der Eingabe von kgf dies Umrechnen. Ebenso die Ausgabe der Daten, falls jemand sich die Speichenspannung in kgf anzeigen lassen wollen würde.
Praktisch würde ich das so gestalten, dass in der Eingabemaske noch keine Eingabewerte vorhanden sind. Im Kopf kann die Eingabe zwischen kgf und N umgestellt werden.
Über ein Butten "+" kann dann ein Datensatz hinzugefügt werden.
Im ersten Feld wird dann die Kraft der Zugwaage eingetragen, und ins zweite Feld wird dann der Tensiowert übergeben oder eingegeben.
Dann den Tensio von der Speiche abheben und nochmals ansetzen und weitere Tensiowerte für die gleiche Speichenspannung in die Maske einlesen.
Aus den oben genannten Gründen diese Werte auch nicht mitteln sondern einzeln verwalten. Wenn man dann genug Werte für einen Messpunkt hat, dann die Speichenspannung erhöhen und über den "+" Button einen weiteren Datensatz für die nächste Speichenspannung hinzufügen. Und so weiter.
Über "Löschknöpfe" oben rechts an jedem Eingabewert können falsch übergebene oder eingetragene Werte schnell aus einem Datensatz entfernt werden.
Über die Mülltonne können auch ganze Datensätze zeilenweise entfernt werden, falls die ganze Messreihe z.B. auf Grund falscher Speichenspannung falsch sein sollte.
Wenn dann alle Messwerte ermittelt und in die Maske übertragen wurden, dann das ganze per Bubble Sort noch in Form bringen und über den Calculate Button den Algorithmus für die Erstellung der Ausgleichskurve über die Daten laufen lassen und die so errechneten Parameter für die Kurve zusammen mit allen Daten abspeichern.
Auf keinen Fall dürfen Speichen unterschiedlicher Länge auf deine Art und Weise in einem Satz kalibriert werden. Das verhunzt die ganze Messung.
Und um ganz ehrlich zu sein, bin ich mir nicht mal sicher, ob die Kalibrierung so überhaupt korrekt ist. Aber zu dem Problem hab ich noch keine abschließende Lösung.
Wenn ich mir deine Eingabemaske ansehe, hätte ich da folgende Punkte:
1
Ich würde die Messunkte nicht fix vorgeben. Also nicht 300, 400, 500... sondern die Möglichkeit offen lassen den Wert einzutragen, den die Zugwaage eben gerade anzeigt. Ob das exakt 700N sind oder 683N oder 726N sind, spielt für die Erstellung der Ausgleichskurve absolut keine Rolle, solange der angezeigte Tensiowert zu dem Anzeigewert der Zugwaage passt.
2
Ich würde auch nicht fix einen Messbereich von 300N bis 1600N vorgeben. Je nach getesteter Speiche könnte das schon sehr viel sein und auch gar nicht nötig. Wenn eine windige Speiche eh nur vorne rechts oder hinten links zum Einsatz kommen soll, dann reicht da auch ein geringerer maximaler Wert.
3
Ich würde auch keine Reihenfolge für die Messwerte vorgeben. Wenn man die Speiche spannt würde ich logischerweise beim geringsten Wert von um die 300N beginnen und mich dann schrittweise bis zu meinem angestrebten Maximalwert vorarbeiten. Wenn die Speiche nun aber schon mal gespannt ist, dann würde ich auf dem "Rückweg" zum entspannten Zustand der Speiche auch nochmals Messpunkte abfahren.
4
Meinen nächsten Punkt hast du schon genannt:
Ich würde die Möglichkeit schaffen, für einen Messpunkt mehrere Tensiowerte einzulesen, um die von dir schon erwähnten Messungenauigkeiten zu minimieren. Da würde ich dann aber keinen Mittelwert der Messwerte nehmen, sondern die Rohdaten so in den Algorithmus für die Erstellung der Ausgleichskurve übernehmen, da dieser Ausreiser weniger stark berücksichtigt.
5
Ich würde bei der Eingabe eine Möglichkeit zur Umschaltung zwischen kgf und N schaffen, falls eine Zugwaage nur kg anzeigen kann. So umgeht man eine händische Umrechnung und man kann in der Maske gleich den Wert für kgf zusammen mit dem Tensiowert eingeben. Intern würd ich aus Gründen der Gewohnheit immer mit Newton rechnen und nur bei der Eingabe von kgf dies Umrechnen. Ebenso die Ausgabe der Daten, falls jemand sich die Speichenspannung in kgf anzeigen lassen wollen würde.
Praktisch würde ich das so gestalten, dass in der Eingabemaske noch keine Eingabewerte vorhanden sind. Im Kopf kann die Eingabe zwischen kgf und N umgestellt werden.
Über ein Butten "+" kann dann ein Datensatz hinzugefügt werden.
Im ersten Feld wird dann die Kraft der Zugwaage eingetragen, und ins zweite Feld wird dann der Tensiowert übergeben oder eingegeben.
Dann den Tensio von der Speiche abheben und nochmals ansetzen und weitere Tensiowerte für die gleiche Speichenspannung in die Maske einlesen.
Aus den oben genannten Gründen diese Werte auch nicht mitteln sondern einzeln verwalten. Wenn man dann genug Werte für einen Messpunkt hat, dann die Speichenspannung erhöhen und über den "+" Button einen weiteren Datensatz für die nächste Speichenspannung hinzufügen. Und so weiter.
Über "Löschknöpfe" oben rechts an jedem Eingabewert können falsch übergebene oder eingetragene Werte schnell aus einem Datensatz entfernt werden.
Über die Mülltonne können auch ganze Datensätze zeilenweise entfernt werden, falls die ganze Messreihe z.B. auf Grund falscher Speichenspannung falsch sein sollte.
Wenn dann alle Messwerte ermittelt und in die Maske übertragen wurden, dann das ganze per Bubble Sort noch in Form bringen und über den Calculate Button den Algorithmus für die Erstellung der Ausgleichskurve über die Daten laufen lassen und die so errechneten Parameter für die Kurve zusammen mit allen Daten abspeichern.
Auf keinen Fall dürfen Speichen unterschiedlicher Länge auf deine Art und Weise in einem Satz kalibriert werden. Das verhunzt die ganze Messung.
Und um ganz ehrlich zu sein, bin ich mir nicht mal sicher, ob die Kalibrierung so überhaupt korrekt ist. Aber zu dem Problem hab ich noch keine abschließende Lösung.
Zuletzt bearbeitet:
Warum würden unterschiedlich lange Speichen die Messwerte verhunzen?
Es wird doch im Tensiometer die Durchbiegung einer immer gleich langen Strecke gemessen. Diese sollte bei einer bestimmten Speichenspannung immer gleich sein.
Im Laufrad ist die zu messende freie Speichenlänge ja auch nicht immer gleich zur Messung beim Kalibrieren (je nach Menge der Kreuzungen und Berührungspunkte).
Freaky-blue
::Matschbombe::
- Registriert
- 8. Mai 2013
- Reaktionspunkte
- 5.160
Ist sie aber (leider) nicht...
dunkelfalke
Schraubär
Vorschlag 1 und 2 sind bereits seit Freitag in Arbeit.
Vorschlag 3 ist schon drin, die Reihenfolge kann man einstellen und auch durcheinander in die Tabelle eingeben. Da ist die Reihenfolge nur wichtig, damit die Steuerung mit dem Fußspedal korrekt funktioniert.
Vorschlag 4 ist auch schon drin, man kann für eine Speiche mehrere Messungen hinterlegen und nachher für die Berechnung eine Messreihe auswählen. Was nicht so einfach geht, ist die Möglichkeit, eine Speiche mehrmals gleichzeitig zu messen - das geht nur, wenn man für die Messung mehrere unterschiedliche Tensiometer auswählt, damit man die Daten parallel einpflegen kann. Wegen 1 wird das Ganze jetzt eh komplett überarbeitet, da es die Sache um einiges komplizierter macht - mal sehen, wie das am besten funktioniert.
Vorschlag 5 ist längst drin, Newton, KgF oder LbF können eingestellt werden. Intern arbeiter die Software in Newton und rechnet alles um. Auch einen Einheitenumrechner habe ich eingebaut.
Hier ist der letzte funktionsfähige Stand
Vorschlag 3 ist schon drin, die Reihenfolge kann man einstellen und auch durcheinander in die Tabelle eingeben. Da ist die Reihenfolge nur wichtig, damit die Steuerung mit dem Fußspedal korrekt funktioniert.
Vorschlag 4 ist auch schon drin, man kann für eine Speiche mehrere Messungen hinterlegen und nachher für die Berechnung eine Messreihe auswählen. Was nicht so einfach geht, ist die Möglichkeit, eine Speiche mehrmals gleichzeitig zu messen - das geht nur, wenn man für die Messung mehrere unterschiedliche Tensiometer auswählt, damit man die Daten parallel einpflegen kann. Wegen 1 wird das Ganze jetzt eh komplett überarbeitet, da es die Sache um einiges komplizierter macht - mal sehen, wie das am besten funktioniert.
Vorschlag 5 ist längst drin, Newton, KgF oder LbF können eingestellt werden. Intern arbeiter die Software in Newton und rechnet alles um. Auch einen Einheitenumrechner habe ich eingebaut.
Hier ist der letzte funktionsfähige Stand
Und warum (Abgesehen von Messabweichungen)?
dunkelfalke
Schraubär
@Freaky-blue
Deine Vorschläge sind komplett implementiert. Sieht zwar nicht ganz genauso aus, wie du es dir vorgestellt hast, funktioniert aber genauso.
Deine Vorschläge sind komplett implementiert. Sieht zwar nicht ganz genauso aus, wie du es dir vorgestellt hast, funktioniert aber genauso.
dunkelfalke
Schraubär
So langsam kommt das alles zusammen. Und ja, ich habe das Diagramm von Freaky-blue schamlos abgekupfert.
Freaky-blue
::Matschbombe::
- Registriert
- 8. Mai 2013
- Reaktionspunkte
- 5.160
Wenn ich mir den Datensatz links im Fenster anschaue, dann sind das die letzten Messungen der Pillar DB1415. Wenn ich die in meine Berechnung reinklopfe, dann ergibt sich folgendes Diagramm:
Man sieht zwar, dass unsere Abweichungen in einem ähnlichen Fenster von ±20N liegen, dennoch sind sie anders verteilt. Mich würde daher interessieren, wie du die Formel für die Ausgleichskurve ermittelt hast und was für diesen Datensatz die Werte für a, b und c sind.
Bei deinem Datensatz hat es den Anschein, als würde dein Bubblesort jeweils nach der ersten von Null verschiedenen Stelle sortieren statt nach dem tatsächlichen Wert.
dunkelfalke
Schraubär
Ja, da funktioniert noch einiges nicht so, wie ich es gerne hätte. Aber das kommt alles noch. Die Ausgleichskurve lasse ich von numpy berechnen:
coefs = np.polyfit(tensions, deflections, fit_type.value)
Auf dem Screenshot ist ein Polynom dritten Grades eingestellt, ich kann mittlerweile zwischen mehreren unterschiedlichen Berechnungstypen umschalten - linear, Polynome 2 bis 4 Grades, Splines und noch einige mehr, wobei vermutlich nicht alle davon sinnvoll sind. Herausnehmen kann ich die Optionen nach dem Testen immer noch. Jetzt ist aber das Radardiagramm für die Speichenspannungen an der Reihe, der Feinschliff wird erst danach gemacht. Dss ist auch der Grund, weshalb ich immer wieder die gleichen Messungen verwende - keine Zeit für die Messungen gehabt, einen nutzbaren Stand zu erreichen hat Priorität.
coefs = np.polyfit(tensions, deflections, fit_type.value)
Auf dem Screenshot ist ein Polynom dritten Grades eingestellt, ich kann mittlerweile zwischen mehreren unterschiedlichen Berechnungstypen umschalten - linear, Polynome 2 bis 4 Grades, Splines und noch einige mehr, wobei vermutlich nicht alle davon sinnvoll sind. Herausnehmen kann ich die Optionen nach dem Testen immer noch. Jetzt ist aber das Radardiagramm für die Speichenspannungen an der Reihe, der Feinschliff wird erst danach gemacht. Dss ist auch der Grund, weshalb ich immer wieder die gleichen Messungen verwende - keine Zeit für die Messungen gehabt, einen nutzbaren Stand zu erreichen hat Priorität.
dunkelfalke
Schraubär
Auch das geht jetzt mehr oder weniger, ist aber leider furchtbar langsam - eigentlich gar nicht benutzbar so wie es ist. Werde da noch vieles optimieren müssen.
dunkelfalke
Schraubär
So, die Geschwindigkeit ist jetzt gut, die Änderungen im Diagramm werden schon beim Eintippen der Werte in Echtzeit sichtbar, genau wie die berechnete Spannung, allerdings musste ich das Diagrammbild etwas vereinfachen. Im Prinzip ist die Software damit bereits nutzbar zum Überprüfen der Spannungsgleichmäßigkeit. Aber fertig ist sie noch lange nicht.
dunkelfalke
Schraubär
Brauchst dann noch nen Arduino Nano. Und am besten ein Pedal dazu:
https://www.aliexpress.com/item/32873374924.html
https://www.aliexpress.com/item/32873374924.html
dunkelfalke
Schraubär
So, die Sortierung ist auch gefixt
Freaky-blue
::Matschbombe::
- Registriert
- 8. Mai 2013
- Reaktionspunkte
- 5.160
Jetzt wo du es sagst, ist mir deine Überschrift vom Diagramm auch aufgefallen. Ich hatte "nur" ein Polynom zweiten Grades verwendet. Daher die relativ großen Abweichungen. Hier mal meine Berechnungen mit ebenfalls einem Polynom dritten Grades.Nun liegen unsere Kurven nur noch ein bis zwei Newton auseinander. Das ist extrem gut. Dein Algorithmus zur Erstellung der Ausgleichskurven bekommt von mir daher grünes Licht...
Das ist natürlich absoluter Overkill. Aber lieber so rum, dann hat man mehr Möglichkeiten.
Wieviel Vorschläge verträgst du denn noch?
Anhänge
dunkelfalke
Schraubär
Keine Sorge, ich vertrage noch eine Menge Vorschläge. Wenn du also weitere Ideen hast, nur her damit.
Will übrigens auch in Zukunft einen Speichenrechner und eine Visualisierung der Einspeichung einbauen - wenn ich mich daran erinnere, dass ich zu dämlich war, 3x/4x einzuspeichen, könnte das durchaus sinnvoll sein.
Will übrigens auch in Zukunft einen Speichenrechner und eine Visualisierung der Einspeichung einbauen - wenn ich mich daran erinnere, dass ich zu dämlich war, 3x/4x einzuspeichen, könnte das durchaus sinnvoll sein.
dunkelfalke
Schraubär
Ich habe das Arduinozeugs auf PlatformIO umgestellt (kompiliert deutlich schneller). Außerdem einen neuen Anlauf für ESP32 gestartet (einmal mit zwei Transistoren pro Messuhr, einmal über den Analogeingang, da es anscheinend doch gehen soll), weil ESP32 Bluetooth hat und weil ich auch die Unterstützung für diese Kranwaage hier einbauen will. Die ist zwar ein Paar Euro teurer, als die Kranwaage, die hier sonst für die selbstgebauten Kalibriergeräte genommen wird, hat dafür aber BLE, so dass ich die Daten für die Speichenmessungen direkt von der Waage übernehmen könnte, ohne dass sie manuell abgetippt werden müssen. Sollte die Messungen einfacher und präziser machen.
Und ich bin mir jetzt auch absolut sicher, dass man das Laufrad direkt in dem Ständer zentrieren kann, auch ohne das Rad umzudrehen - sobald auch nur eine Stelle an der Felge einer Schiebelehre überprüft genau zentriert ist, kann man die laterale Messuhr an dieser Stelle auf 0 kalibrieren.
Und ich bin mir jetzt auch absolut sicher, dass man das Laufrad direkt in dem Ständer zentrieren kann, auch ohne das Rad umzudrehen - sobald auch nur eine Stelle an der Felge einer Schiebelehre überprüft genau zentriert ist, kann man die laterale Messuhr an dieser Stelle auf 0 kalibrieren.
dunkelfalke
Schraubär
Okay, das analoge Auslesen auf dem ESP32 funzt nun. Aber die Analogeingänge rauschen wirklich extrem. Das sind die Werte, bei denen die Messuhr einfach nur auf 0 steht - innerhalb von etwa 15 Sekunden kommt das da raus:
0.00
5.12
0.00
0.04
0.66
5.12
0.00
5.94
0.00
0.02
5.12
0.36
0.00
0.80
10.24
0.80
0.00
0.32
0.00
0.16
0.00
0.04
0.00
0.32
0.02
0.00
5.28
0.00
5.28
0.00
0.32
0.00
0.32
0.00
5.28
0.00
5.92
0.00
13.12
0.00
0.66
5.12
0.06
0.02
0.00
0.01
0.02
0.05
0.00
0.32
0.00
2.56
0.04
0.02
0.00
0.16
0.00
-0.04
0.05
Das ist, so wie es ist, nicht zu gebrauchen. Ich werde schauen, ob ich das Rauschen irgendwie durch besseren Code (Plausichecks, höhere Schwellen) verringern kann, ansonsten bleibt wohl nur noch der Weg über zusätzliche Bauelemente. Theoretisch reicht dann ein Transistor und zwei Widerstände pro Kanal (eine Messuhr hat zwei Kanäle), ich hab's mit einem Transistor, drei Widerständen und zwei Kondensatoren gemacht, damit das Ganze sauberer läuft. Ich werde das außerdem mal damit probieren:
https://www.aliexpress.com/item/32309390020.html
Das sind die zwei Widerstände und ein Transistor pro Kanal wie in der Minimallösung, allerdings schon fertig gebaut.
0.00
5.12
0.00
0.04
0.66
5.12
0.00
5.94
0.00
0.02
5.12
0.36
0.00
0.80
10.24
0.80
0.00
0.32
0.00
0.16
0.00
0.04
0.00
0.32
0.02
0.00
5.28
0.00
5.28
0.00
0.32
0.00
0.32
0.00
5.28
0.00
5.92
0.00
13.12
0.00
0.66
5.12
0.06
0.02
0.00
0.01
0.02
0.05
0.00
0.32
0.00
2.56
0.04
0.02
0.00
0.16
0.00
-0.04
0.05
Das ist, so wie es ist, nicht zu gebrauchen. Ich werde schauen, ob ich das Rauschen irgendwie durch besseren Code (Plausichecks, höhere Schwellen) verringern kann, ansonsten bleibt wohl nur noch der Weg über zusätzliche Bauelemente. Theoretisch reicht dann ein Transistor und zwei Widerstände pro Kanal (eine Messuhr hat zwei Kanäle), ich hab's mit einem Transistor, drei Widerständen und zwei Kondensatoren gemacht, damit das Ganze sauberer läuft. Ich werde das außerdem mal damit probieren:
https://www.aliexpress.com/item/32309390020.html
Das sind die zwei Widerstände und ein Transistor pro Kanal wie in der Minimallösung, allerdings schon fertig gebaut.
dunkelfalke
Schraubär
Der bessere Code hat zwar das Rauschen etwas verringert, aber nicht behoben. Bleibt nur der Weg über die Pegelwandler. Meine Analyse hat gezeigt, dass das Rauschen nicht mal vom ESP32 kommt, sondern direkt von der Messuhr:
Beim Arduino Nano stört das nicht so, weil da der Comparator, der verwendet wird, anscheinend extrem kurze Signale hardwaremäßig wegoptimiert. ESP32 hat das aber leider nicht und das in der Software abzubilden wird schwierig.
Beim Arduino Nano stört das nicht so, weil da der Comparator, der verwendet wird, anscheinend extrem kurze Signale hardwaremäßig wegoptimiert. ESP32 hat das aber leider nicht und das in der Software abzubilden wird schwierig.
Zuletzt bearbeitet:
Oder den Nano 33 nit BL testen...aber ja, super nervig.
dunkelfalke
Schraubär
Ja, den Nano an den ESP zu hängen war auch mein erster Gedanke vor 2 Monaten, aber da dachte ich noch, ich kriege das auch so schon irgendwie hin. Aber anscheinend nicht.
Alternativ ginge auch ein Schmitt-Trigger. 74LVC14 sollte gut passen - 3.3V, perfekt für den ESP32, und 6 Kanäle, genau passend für drei Messuhren (zwei am Zentrierständer und eine am Tensiometer). Das Problem ist, den Käfer als DIP zu finden - kann zwar bis zu einem gewissen Grad SMD löten, aber nicht auf eine Lochrasterplatine.
Alternativ ginge auch ein Schmitt-Trigger. 74LVC14 sollte gut passen - 3.3V, perfekt für den ESP32, und 6 Kanäle, genau passend für drei Messuhren (zwei am Zentrierständer und eine am Tensiometer). Das Problem ist, den Käfer als DIP zu finden - kann zwar bis zu einem gewissen Grad SMD löten, aber nicht auf eine Lochrasterplatine.
Bitte beachte unsere Verhaltensregeln beim Antworten. Danke 🙂
