@andreas ist unser Firmwarespezialist.
Hi 
- die GPS Daten werden geschrieben, wie sie vom GPS Modul kommen. Das Modul „weiß“ das wir mit dem Rad Unterwegs sind und verwirft daher selber (eigentlich) unplausible Änderungen der Position. Wichtig ist bei der Auswertung auch auf den HDOP Wert zu achten.
Die Includes sollten kein Problem beim verstehen der Firmware machen? Das ist etwas „gewachsen“ und bisher hat sich keiner die Zeit genommen aufzuräumen. Gerne helfe ich unklare Teile besser verständlich zu gestalten.
Hi, beim Verständnis ist das schon hinderlich. Ich will ja schließlich wissen wo ich sagen hinzufügen kann. Klar kann ich das jetzt irgendwo machen und das wird auch funktionieren, eine Struktur mag ich aber nur bedingt erkennen und dementsprechend auch nur bedingt umsetzen.
Ja, der HDOP geht auf 99.9 und die Sats auf 0, wenn ich mich jetzt recht entsinne, angezeigt wird der Kram im Portal aber trotzdem.
Gerne die Imports aufräumen.
Wenn nicht klar ist wo was neues hin soll, eventuell in eine eigene Klasse.
In OpenbikeSensorFirmware CPP ist die Loop und alles was noch keinen anderen Platz gefunden hat. In configServer ist die Sammelstelle für den Server Modus. Der Rest macht weitgehend das, was der Name erwarten lässt.
Moin allerseits!
Long time no see… ich hatte in den letzten Monaten etwas mehr zu tun und der OBSPro ist da leider hinten runter gefallen. Das hat sich aber nun geändert! 
Ich habe heute noch mal Experimente und vor allem Messungen mit dem Ultraschall gemacht und ein paar nicht ganz optimale Dinge gefunden und größtenteils behoben. Vor allem war der Gain der RX-Stufe zu gering. Prinzipiell wäre da ein logarithmischer Verstärker interessant, aber das wäre eine andere Baustelle.
Naja, TLDR: Es scheint nun in etwa zu funktionieren. Ich konnte problemlos überholende Autos bis 2,5m und meistens auch bis 3m (die 25cm vom Sensor sind schon abgezogen!) messen. Das sollte ja grob ausreichend sein.
Was noch ein Problem ist, ist dass die Sensoren scheinbar ein recht großen Öffnungswinkel haben. Wenn ich etwas schräg gefahren bin (15-20° Neigungswinkel würde ich sagen), sieht der Sensor den Boden und misst halt ein paar 60cm. Da werde ich noch mal über einen kleines Horn (Trichter? Wie heißt das für Akustik?) nachdenken, der ins Gehäuse integriert wird. Das würde auch gleich ein paar andere Probleme mit dem aktuell recht/zu dünnen Gehäuse lösen, wenn das wieder 4-5cm breit wird. Mit 5cm Breite könnte man es so hinbekommen, dass dann auch noch ne 18650er reinpassen würde. Dafür könnte man auch direkt passende Lötpunkte für einen Halter auf der Rückseite vorsehen.
Als nächstes werde ich jetzt noch ein paar Feinjustierungen der US-Sensoren machen und die Änderungen auch für die anderen übernehmen. Anschließend wäre ein neues Gehäuse dran, damit man mit den zwei Prototypen mal ein paar echte Testfahren machen kann und evtl. auch mit dem bestehenden Sensor vergleichen kann. Dann würde ich den Schaltplan und das Layout nochmal aktualisieren und alle Fehler beseitigen. Evtl. würde ich auch noch mal eine Runde machen, um die Anzahl der Bauteile auf der Platine zu reduzieren. Dann würde eine Version mit automatischer Bestückung folgen. Hier könnte man nachdenken direkt 10 Stück zu machen und die an ein paar Tester zu verteilen.
Schönen Rest-Sonntag noch allerseits!
10 „Gefällt mir“
Und noch mals moin allerseits!
Ich habe ein bisschen was am OBSPro gemacht und wenn alles nach Plan läuft, werde ich demnächst da noch deutlich mehr Zeit reinstecken können. Wer mehr dazu wissen will, möge sich am kommenden Community-Treffen am 09.10. beteiligen: https://forum.openbikesensor.org/t/2023-10-09-community-treffen-am-09-oktober-2023/1863
Grober Plan wäre es bis März/April 20 Sensoren fertig zu haben, die dann auf die Straße gehen können.
Bei meinen Arbeiten habe ich u.a. mal den groben Materialkosten-Preis des Sensors mit den aktuellen Bauteilen abgeschätzt. Dieser beläuft sich auf rund 56€ bei nur 20 Stück Abnahme und dem gutem GPS, wo alles drin sein müsste, bis auf die MwSt.
Technisch sind wir so weit, dass wir die zwei Prototypen haben und diese auch bis auf drei (hoffentlich) Kleinigkeiten funktionieren. Die sollen in den nächsten Wochen final fertig gemacht und auf die Straße gebracht werden.
12 „Gefällt mir“
Hallo allerseits,
ich sitze gerade an einem überarbeitetem Schaltplan und habe dazu eine Frage an die Experten @gluap oder @andreas: Wird die SD Karte im SD oder SPI Modus betrieben? Es geht um die Frage, ob man an den SPI noch weitere Dinge hängen kann. Das ginge nur im SPI mode, da dann der Pin CD/DAT3 als Chip-Select fungieren würde.
Und hier auch die Frage, warum die SD-Karte nicht am SD-Karten-Interface des ESP hängt? Will da jetzt ungern groß was umbauen, aber das sind halt schon eine Menge verschenkter Pins.
Die neue Revision geht zwei Schritte weiter: Es sollen zwei PGA460 für den Ultraschall-Teil sowie ein anderes Display zum Einsatz kommen, alle drei brauchen SPI. Leider hat der PGA460 auch kein Chip-Select, weshalb die wohl auf nen extra SPI kommen oder per bit-bang betrieben werden.
1 „Gefällt mir“
Hallo @fabian,
Wir benutzen die Karte im SPI Modus denke ich - das SD-Modul, das wir nutzen wird per an SPI angeschlossen und ist auch so beschriftet. Wir nutzen softwareseitig SD (spi basierte lib), nicht SD_MMC (glaube das wäre die library für den native SD modus von espressif).
Der Grund dürfte weniger eine bewusste Entscheidung sein, sondern mehr, dass der SPI Modus im Arduino Universum der bestdokumentierte Modus ist, in dem man auf die SD Karte zugreifen kann - weil nicht alle Microcontroller ein SD-Karten Interface haben. Und die OpenBikeSensor Firmware im Arduino Universum geboren wurde.
Falls für den nativen SD-Modus mehr Pins benötigt werden, könnte es auch sein, dass das SD-Modul, was im OBS Classic verwendet wird dafür gar nicht geeignet ist.
Das Problem mit dem SPI wäre dann evtl. doch noch ein Argument für die I²C variante des displays, je nach dem, wie lange das noch erhältlich ist.
Moin,
danke für die Infos.
Also wenn die SD Karte aktuell im SPI Modus läuft, kann man das Display da ja einfach parallel hängen - hatte irgendwann mal im Hinterkopf dass der SPI Modus bei modernen SD Karten schon seit einigen Jahren nicht mehr funktioniert.
@j000bs hatte vor das mal zu testen, für Ergebnisse wäre ich dankbar.
Aktuell sehe ich eh nicht mehr, dass die Firmware für den OBSPro kompatibel zum classic bleiben kann bzw alles automatisch erkannt wird. Von daher könnte ich die SD jetzt halt ans SD interface hängen, müsste mich aber drum kümmern das ans laufen zu bringen.
Es wäre halt gut wenn SD und Display an einem Hardware SPI hingen, um bessere Performance zu haben. Die US-Sensoren können ruhig per bit-bang betrieben werden, da passiert ja fast nichts.
Fabian
Hmm, irgendwie haut das mit dem SPi-Modus nicht so ganz hin. Warum geht der MOSI pin denn auf SD_CMD? Oder habt ihr irgend ein alternatives Pin-Muxing verwendet?
Hallo,
Ja, nächsten Dienstag bin ich wieder bei der Hardware und kann mal testen, ob ich Display und SD-Karte gleichzeitig verkabelt und richtig angesprochen bekomme.
Wenn ich das richtig sehe sind im Schaltplan des OBS 0.03 als Pinbezeichnung für die SD-Karten die SD-bus-modus-Bezeichnugen verwendet, angeschlossen sind sie dann aber an den SPI-Bus.
Der englische Wikipedia-Artikel hat dafür zwei Tabellen. Der physische SD-Pin 2 bzw. Micro-SD-Pin 3 ist also bei SPI DI / MOSI, beim SD-Bus-Modus dagegen CMD.
Schau mal in den Branch wip-simplify so wie es im readme steht. Dort ist die Versionsnummer 1.0.0-alpha.2
Danke, den Branch hatte ich nicht auf dem Schirm.
Die Bezeichnungen und Anschlüsse von der SD-Karte sehen für mich aber gleich zur Version 0.03 aus.
Danke für die Infos, das mit den anderen Pin-Bezeichnungen hatte ich auch gerade rausgefunden. Ich konnte aber nach etwas Suche im Source-Code nicht herausfinden ob/wie/wo der Chip-Select definiert wird. Der SPI scheint hardware-seitig nur einen dedizierten zu haben. Die Frage ist jetzt, ob ich die SPI-Schnittstelle einfach parallel mit einem GPIO als CS für anderen Krams verwenden kann. Die Hardware kann das sicher, aber ich blick durch die verwendeten Bibliotheken nicht durch. Die Variable/Instanz SD fällt im Code einfach vom Himmel.
Die SD-Instanz kommt aus der Header-Datei der SD-Bibliothek, bei mir liegt die in ~/.platformio/packages/framework-arduinoespressif32/libraries/SD/src/SD.h.
Bei der SD.begin()-Funktion, die an verschiedenen Stellen in der OBS-FW vorkommt, kann optional der CS-Pin angegeben weden – gerade wird keiner angegeben und somit der default-Pin gewählt. Ich denke es sollte daher ohne Probleme möglich sein, für SD und SPI-Display separate CS-Pins zu nehmen. Ich fände es, damit die FW nicht komplizierter wird, dennoch sinnvoll, beim Standard-CS-Pin für die SD zu bleiben, und einen separaten Pin als CS für das Display zu nehmen (was U8g2 ja unterstützt).
Hat geklappt. Ich habe dafür GPIO 12 als CS, GPIO 13 als D/C und GPIO 14 als Reset genommen, da die drei beim OBS Rev. 1.0.0-alpha2 noch frei sind.
Danke für die Info. Bin gerade dabei die letzten Sachen an der neuen Platine zu machen und ich hoffe, dass ich die heute noch raus schicken kann. Welcher GPIO für den CS ist ja eigentlich egal? Oder ist das nen besondere Pin-Muxing?
Ich lege da jetzt keinen Wert mehr drauf großartig kompatibel zu sein. Es wird so vieles etwas anders, dass man in der Firmware sowieso ne Pin-Map erstellen muss je nach Hardware-Version. Da habe ich lieber entspanntes routen.
Ich denke welchen Pin man genau nimmt sollte egal sein, solange er als Output fungieren kann (wenn ich das das Datenblatt des ESP richtig lese ist das bei den Sensor-Pins GPIO 36 und 39 ja nicht der Fall).
Kann aber auch anbieten, nochmal schnell andere Pins zu testen (heute Abend bin ich noch ein paar Stunden online).
Dann gäbe es also für den OBS Pro eine separate Firmware-Varianten, die man etwa durch bedingte Kompilierung erzeugt?
Aus meiner Sicht okay, könnte sogar etwas Speicher sparen. Heißt nur auch, dass die Infrastruktur für die Auslieferung der Software (https://install.openbikesensor.org/ und der FUOTA-Server) eben mehrere Varianten anbieten können müssten. Soweit ich das einschätzen kann aber kein riesiger Aufwand.
Das mit den Pins 4/5 (SENSOR_*) habe ich aufm Schirm
Ich denke wir kommen da nicht drum rum zwei Firmware-Versionen anzubieten. Klar kann der das Display automatisch erkennen, aber er kann nur über Umwege rausfinden, ob es ein Pro oder Classic ist. Da ich aber recht viele Pins brauche, kann ich nicht nur freie benutzen für die ganzen zusätzlichen oder anderen Features.
Hier ein Sneak-Peak:
3 „Gefällt mir“
Sieht sehr schick aus!
Was mir eben noch aufgefallen ist: Der letzte Stand auf dem pga460-branch von gestern hat noch das ESP32-WROOM-32 Modul, aktueller ist ja das ESP32-WROOM-32E. Der Footprint ist leicht anders, und die MCU auch etwas… Ich hätte zugunsten der Zukunftssicherheit wohl dennoch den 32E bevorzugt.
Spricht für dich etwas gegen den 32E?