OBS Pro - Automatisiert bestückbare Hardware

Design & Entwicklung Elektronik & Gehäuse
#85

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.

#86

Schau mal in den Branch wip-simplify so wie es im readme steht. Dort ist die Versionsnummer 1.0.0-alpha.2

#87

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.

#88

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.

#89

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).

#90

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.

Transreflexives OBS-Display
#91

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.

#92

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.

#93

Das mit den Pins 4/5 (SENSOR_*) habe ich aufm Schirm :wink:
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:

OBSPro_3D
OBSPro_3D963×1122 99.1 KB

3 „Gefällt mir“
#94

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?

#95

Öhhh, wenn das von der aktuellen Firmware so unterstützt wird, gerne. Das normale eap-32 scheint ja obsolet zu sein. Hatte da etwas Probleme das zu finden.
Gibt es denn da auch nen Plan auf was größeres als die 4MB Variante zu wechseln?

#96

Das mit µC tauschen war mir jetzt auf die Schnelle doch etwas zu heikel und habe das erstmal so gelassen. Platine und Bauteile sind bestellt. Der aktuelle Stand ist im pga460 branch:

Ich rechne mit den ersten aufgebauten Prototypen in 2-3 Wochen.

1 „Gefällt mir“
#97

Ich wusste es bei meinem letzten Post auch nicht – aber die MCUs sind wohl Binärkompatibel.
Im ESP32 Chip Revision v3.0 User Guide heißt es unter 2.2.:

  1. Software Design Changes:
    Client can continue to use the same software and binary for deployed product. The
    same application binary will work on both chip revision v1.0 and chip revision v3.0.
1 „Gefällt mir“
#98

Na das wäre ja top :slight_smile:

#99

Zwischendurch mal ein Update:
Ich habe in den letzten Tagen viel für den OBSPro gemacht. Es gibt zwei neue Prototypen, auf denen vor allem die Ultraschall-Schaltung komplett getauscht wurde und jetzt auf einem PGA460 basiert - den gab es damals nicht (bezahlbar) dank Chip-Krise. Hier habe ich gerade die ersten Daten ausgelesen bekommen:
grafik
Man sieht in etwas über 2m schön die Decke :slight_smile: und ein paar Mehrfachreflektionen zwischen Tisch und Decke bei Vielfachen davon :stuck_out_tongue:
Das Gemüse am Anfang muss ich noch in Griff bekommen. Man kann da so viel einstellen, ich bin erst mal froh ein Hello-Word am Laufen zu haben und dort sogar was erkennen zu können.

Leider funktioniert das GPS (was jetzt ein MAX-M10M ist) nicht mehr, das habe ich erst einmal bei Seite geschoben. Hier ist ein NMEA-Decoder notfalls schnell implementiert. Dann halt ohne Almanac-Daten für den Warm-Start. Der sollte trotzdem in < 30 Sekunden nen Lock bekommen. Also das GPS läuft, nur funktionieren die UBX-Kommandos scheinbar nicht mehr.

3 „Gefällt mir“
#100

Nach etwas Optimierung kann ich Autos bis ~6m problemlos erkennen (geht vermutlich auch noch mehr) und auch das Nachklingeln konnte ich deutlich reduzieren, womit auch Objekte ab ~20 cm zuverlässig detektiert werden.

grafik
grafik908×814 30.4 KB

Das rote ist die einstellbare Detektions-Schwelle, das orangene ist die erkannte Distanz.
Was auch interessant sein könnte: Der Sensor kann prinzipiell bis zu 8 Ziele erkennen und einem die Amplitude und auch Länge der Pulse sagen. Oder man kommt wie in dem Screenshot zu sehen auch an die Rohdaten ran, wobei die eine deutlich schlechtere Zeitauflösung haben (je nach Einstellung bei unser Anwendung 16x oder 32x schlechter). Rohdaten und Entfernungen/Breiten/Amplituden gehen gleichzeitig in einer Messung leider nicht.
Außerdem kann der Sensor auch noch die Temperatur messen, womit man die etwas unterschiedliche Schallgeschwindigkeit (ca. 0,6 m/(s*K)) kompensieren kann. Bei 20K Unterschied macht das schon 3,5% aus.
Als nächstes folgt die Integration meines Codes in den OBS Code. Evtl. könnte ich da noch mal die Hilfe von @andreas brauchen. Viele Funktionen, die die Ultraschall Manager Klasse hat, habe ich noch nicht verstanden.

4 „Gefällt mir“
#101

Ich denke ich habe die Ultraschall-Software fertig, wobei man bei diesem Spinnen-Netz von Software nicht sagen kann, ob man nicht irgendwo einen Faden vergessen hat.
Jetzt beiße ich mir die Zähne am GPS aus. Die UBX-Befehle, die bislang verwendet wurden sind zumindest teilweise nicht mehr verfügbar bzw wurden durch andere ersetzt. Jetzt stehe ich vor der Wahl das UBX-Zeugs anzupassen oder da einen NMEA-Decoder einzubauen. Die NMEA Nachrichten gehen scheinbar aktuell ins Nirwana.
Frage an die Experten: Gibt es irgendwo ne Doku was eigentlich am Ende in der cvs an Daten benötigt wird? Beim Ultraschall waren jetzt irgendwie nen Dutzend Funktionen, die ich nicht nach-implementiert habe (bzw. nicht konnte), die scheinbar nur Debug-Foo waren und nie wieder raus genommen wurden. Ich fürchte, dass das beim GPS auch so ist. Die Anzahl an public-Methoden ist ja wahnsinnig um ne Position und ne Uhrzeit zu bekommen.
Dazu kommt, dass auch die GPS-Klasse wieder von allem Möglichen abhängt, wovon sie nicht abhängen sollte (dem Display z.B.). Was mich zu einem anderen Problem führt: Gibts ne Möglichkeit das Kompilieren/Hochladen schneller zu machen? Aktuell brauche ich für beides zusammen knappe 2 Minuten - was den Debug-Prozess echt nervig macht. Beim US hatte ich mir dann nen extra Projekt gemacht. Das ging beim GPS aber so einfach nicht, weil das wie gesagt von allem Möglichen abhängt, wovon es nicht abhängen sollte.

1 „Gefällt mir“
#102

Update: Ich habe mich nun zwei Tage durch dieses GPS-Monstrum gequält und konnte es um einige UBX-Befehle erweitern, so dass nun M6 und M10 Module funktionieren. Einige Sachen wie das Aiding funktionieren noch nicht, da ich keine äquivalente Funktion gefunden habe - habe aber auch nicht intensiv gesucht. Lock ist nach ca. 20 Sekunden selbst an einem schlechten Standort da.
Außerdem habe ich die Soft-Power-On/Off Funktion noch mal in eine Hardware-Timer-Interrupt-Routine geworfen, womit das nun auch zuverlässig funktioniert, egal in welchem Menü man sich gerade befindet.

Ein Problem habe ich noch, evtl. kann da wer weiter helfen. Ab und zu hängt sich die Firmware beim Starten in irgend einer Endlosschleife auf und er kotzt die ganze zeit

E (3968) gpio: gpio_set_level(226): GPIO output gpio_num error

aus. Mir ist klar, dass das bedeutet, dass ich ein gpio_set_level/digitalWrite auf einen Pin mache, der kein Output sein kann. Ich verstehe aber nicht warum das nur manchmal passiert und viel schlimmer: Ich habe keine Idee wie ich das debuggen kann. Er sagt einem leider nicht welcher Pin das ist oder wo das im Quelltext ist. Die Funktion gpio_set_level scheint vorkompiliert zu sein, so dass ich da nicht mal zusätzlich die Pin-Nummer oder nen Stack-Trace auskotzen könnte. Jemand noch ne Idee?

Grober Plan ist nun, dass ich morgen noch ein paar Kleinigkeiten an der Hardware fixe und dann 25 Demonstratoren bestelle. Davon gehen 5 an den OBS e.V., 5 an die Hochschule Karlsruhe, 10 an die lokale OBS-Braunschweig Gruppe und 5 für „mich“. Die 5 für „mich“ gebe ich prinzipiell raus, falls mir jemand bei der Firmware oder beim Testen helfen will.

2 „Gefällt mir“
#103

OK, das hat sich erledigt. Mit ner tonne Debug-Nachrichten habe ich es gefunden. War eine un-initialisierte Variable und dann sind schlimme Dinge passiert :stuck_out_tongue:

2 „Gefällt mir“
#104

Die 25 Demonstratoren (nenne ich sie jetzt) sind bestellt! Daumen drücken, dass ich nichts verpatzt habe :stuck_out_tongue:

6 „Gefällt mir“