Osmuino - Ein OpenSource GPS-Tracker auf Arduino-Basis

Ich bin gerade dabei einen Tracker auf Arduino-Basis zu entwickeln. Hauptgründe sind SD-Kartenfähigkeit, Displayanzeige und Akkulaufzeit. Mein bisher schönster Logger war der WSG-1000, was ich hier versuche ein wenig nachzuempfinden.

Der Name ist noch nicht endgültig - mit OSM hats nicht direkt was zu tun, wobei ich aber ein paar zusätzliche Tasten für’s Logging (POI & Co.) eingeplant habe und die maximale Aktualisierungsrate der GPS-Koordinaten bei mind. 5 Hz liegen wird.

Der Quellcode und der Aufbau sollen frei zur Verfügung gestellt werden, dass es jeder nachbauen und modifizieren kann. Nur einen Lötkolben sollte man besitzen, um ein paar Drähte anzulöten :wink:

Mein größeres Projekt ist “Mapduino”, welches noch ein OLED/TFT Display ab 1,8" zur Kartenanzeige beinhalten wird. Es ist geplant, dass Osmduino auf den Mapduino aufgesteckt wird. Oben die Anzeige der Koordinaten, Geschwindigkeit, Einstellungen usw. und darunter eine Kartenanzeige auf einem 1,8" bis 4…5" Display mit oder ohne Touch.

Weshalb ich das jetzt schon während der Entwicklung poste: ich hätte gerne Vorschläge von euch, was nötig wäre anzuzeigen. Was wäre Sinnvoll auf dem kleinen Display des Loggers beim Einschalten dessen (irgendein Knopf drücken → Display geht für x Sekunden an), was auf den Folgedisplays beim durchzappen. Was wären nötige Funktionen? Z.B. Fahrradtacho-Modus mit dauerhafter Geschwindigkeitsanzeige, Schrittzählerfunktion uswusw.


Grobe Übersicht geplante Hardware:

  • Arduino Nano oder Pro Mini Microcontroller-Board (6-10 €; < 4x2 cm)
    https://www.arduino.cc/en/Main/ArduinoBoardNano
    https://www.arduino.cc/en/Main/ArduinoBoardProMini
  • 1,3" Monochrom-OLED Display mit 128x32 pixeln (10 €)
  • u-Blox NEO 6M (bis 5 Hz Akt.Rate, 15-25 €), 7M (20-40 €) oder M8N (bis 15 Hz, 30-60 €) GPS Receiver
  • 3-achsen Beschleunigungssenor mit 3-achsen Gyroskop (5-10 €)
  • MicroSD oder SD-Slot (2-6 €)
  • Barometer für genaue Höhe (BM180 um 3-8 €, BM280 10-15 €, xxx). Enthält auch Thermometer
  • Temperatur/Hygrometer Sensor (8-12 €)
  • Helligkeit (einfach nur die realitive Helligkeit <2 € mit LDR-Sensor oder Absolute in LUX um 10-15 €)
  • Buzzer/Mini-Lautsprecher für Warn-/Infosignale (0,5-3 €). Theoretisch wiedergabe von kleinen WAV-Files möglich und angedacht. Dadurch weniger nervige Töne statt gepiepse dadurch möglich
  • Taster (3 - 5 Stück zu 0,5-1,5 €)
  • Schalter zum Einschalten des Geräts (1-3 €)
  • unterschiedliche Akkutypen sollen unterstützt werden (3xNiMh, LiIon, LiPo, usw.). Theoretisch auch der Betrieb direkt über Mini-USB Buchse an z.B. einer PowerBank möglich.
  • Gehäuse (xx €…von kleiner Tupperdose bis Selbstbau alles möglich)

Die ganzen Sensoren sind optional - soll nur GPS aufgezeichnet werden, so nimmt man nur das GPS-Modul. Möchte man eine genaue Höhe haben, dann nimmt man einen Barometersensor. Ich baue schon mehrere Sensortypen in die Software ein, welche ich schon mehrfach da habe. z.B. drei Verschiedene Typen von Beschleunigersensoren oder drei unterschiedliche Helligkeitssensoren. Die Software soll dann auch nach und nach durch andere erweitert und an andere Displays und Sensoren angepasst werden.

Die Grundkosten für den reinen Logger belaufen sich hier auf etwa 50-60 € inkl. Display, Baro-Thermometer, SD-Kartenslot, Taster, Schalter und Lautsprecher.


Grobe Übersicht geplante Software:

  • Aufnahme und Anzeige von GPS-Daten (Position, Geschwindigkeit, Richtung, usw.)
  • Anzeige freier Speicher SD-Karte, aufgenommene Anzahl Punkte, freier Speicher in % (oder Punkten)
  • Anzeige Akkustand. Dies ist sogar in 1% Schritten ziemlich genau möglich. Einstellbare Warnschwellen. Erhöhte Sparmaßnahmen einstellbar, wenn Akkustand unter einem bestimmten Wert fällt.
  • Anzeige Druck, Temperatur und Höhe des Barometers. Zwei zusätzliche Temperatursensoren sind vorgesehen und können mit GPS-Koordinaten abgespeichert werden.
  • Abstimmung zwischen Beschleunigersensor und GPS-Koordinaten bzgl. Stillstand. D.h. durch den Beschleunigersensor soll erfasst werden ob GPS-Koordinaten überhaupt gespeichert werden. Somit werden Sprunghafte Änderungen ignoriert. Beim loslaufen/fahren können die ersten Meter ggf. sogar über den Beschleunigersensor ermittelt und geloggt werden, bevor auf die Koordianten des GPS-Moduls zugegriffen wird
  • Einstellbarer Logging-Typ. Fußgänger → Erfassung von Schritten wäre möglich. Bzw. darüber könnte Pause/Ganggeschwindigkeit und Entfernung ermittelt werden. Seltenes wegschreiben von Koordinaten als per Fahrrad oder Auto. Halt die typischen Logger-Settings :slight_smile:

Der u-Blox Logger ist via USB-TTL Konverter (5 €) über deren Software einstellbar. Dort kann man die Abfragehäufigkeit und auch Energiesparmaßnahmen einstellen. Ob und wie es über den Microcontroller geht weiß ich noch nicht. Theoretisch muss es möglich sein, da es über die serielle Schnittstelle läuft.

Der Stromverbrauch des NEO 6M liegt im Durschnitt bei 8-10 mA, wenn dieser jede 10 Sekunden wach gehen soll und nach einem erfolgreichen Fix die Datensätze schickt (dazu gibt es ein Powermanagement PDF von u-Blox, wo die Verbräuche getestet wurden). Der Arduino wird die meiste Zeit schlafen gelegt, wodurch sein verbaruch kaum meßbar wird (im Schlaf im Microampere Bereich). Das ganze kann also auf durchschnittlich 10 mA gebraucht werden = 100 Stunden Laufzeit je 1000 mA (wären dann bis zu 60h mit dem standard 600 mA Nokia-Akku der BT747 Logger). Mit einem 18650 LiIon 3000 mAh Akku (5-10 €) hätte man somit eine Laufzeit von 250-300 Stunden.

Die Stromverbräuche werden ich selber messen um optimale Bedingungen für den Stadardbetrieb zu gewährleisten. Standardmäßig schickt der NEO 6M ein mal pro Sekunde die Datensätze. Hier dürfte der Stromverbrauch eher beim doppelten bis dreifachen liegen.

Soweit erstmal die groben Details. Werde die Tage mal ein paar Fotos posten, dass man sich das ganze physisch vorstellen kann :slight_smile: Was meint ihr dazu bzw. hättet ihr schon spezielle Ideen?

Gruß
Paul

Hi,

mir fällt im Moment nur eine Sache auf: das Ignorieren von sprunghaften Änderungen. Reflektierte Signale liefern keine zufälligen Abweichungen. Sie passen oft gut zusammen und liefern ein einigermaßen plausibles Ergebnis. Dann biegt man um eine Ecke oder kommt an eine Kreuzung, ein paar andere Satelliten werden sichtbar und die gelieferte Koordinate springt auf den “richtigen” Wert. Das ist nicht selten! Sprunghafte Änderungen würde ich daher nicht ignorieren (zumindest dann nicht, wenn dabei die GPS-Höhe nach oben springt).

Weide

Das Problem kenne ich natürlich auch :slight_smile: Ich hatte vor einen HDOP bzw. PDOP Filter einzubauen. Wobei HDOP alleine eher Sinn macht. Dadurch sollen Punkte, die oberhalb der Grenze liegen, gar nicht geloggt werden. Gibts also “Positive” sprünge, dürfte hier der HDOP eher fallen, weshalb sowas nicht rausgefiltert wird.
Wenn mehrere Koordinaten nacheinander nicht gespeichert werden, könnte man eine neue Logdatei anfangen und den schlechten Abschnitt dadurch ganz weglassen (Tunnel sind da ja ein tolles Beispiel). Mülldaten also von vornehinein gar nicht loggen, bevor man sich wundert, was das gewesein sein soll.

Ich dachte, dass die DOPs nur den Verschlechterungsfaktor durch ungünstige Satellitenrichtungen angeben … die ändern sich aber nicht nennenswert, wenn ein direktes Signal statt eines reflektierten empfangen wird.

Ein neues Segment in derselben Datei müsste auch reichen.

Die DoP Werte sind rein rechnerische Werte aus der jeweiligen Konstellation der Satelliten die für den Fix verwendet werden, d.h. sie haben mit Fehler etc. durch Reflexionen überhaupt nichts zu tun.

Vernünftigerweise sollte man eher die Bedingungen welche Sats für den Fix verwendet werden (z.B. keine kleinen Höhenwinkel zulassen) schärfer fassen als sie normalerweise gesetzt sind.

Vielleicht als Anregung ein ähnliches Projekt:

https://www.rbb-online.de/panorama/beitrag/2016/08/ingenieur-testet-brandenburger-radwege-infrastrukturministerium.html

…eventuell TFT mit SD Slot https://ex-store.de/397-400x240-TFT-LCD-Touch-Display-fuer-Arduino-Uno-Mega

aber die näheren Daten kenne ich nicht.

@Weide: natürlich würde ich dann Segmente abspeichern. Wusste nicht, dass man innerhalb einer GPX Einteilungen speichern kann… Neue Datei würde ich gerne mal haben, wenn eine Längere Pause anstand (z.B. auch Übernachtung → neuer Tag, neue Loggingdatei). Das wäre aber jetzt speziell für Touren und nicht für’s Mapping. Fehlt mir halt beim 747er.

@Simon: ich weiß, dass die darauß errechnet werden. Niedriger DOP heißt aber gleichzeitig besserer Empfang bzw. höhere Genauigkeit. Bei einem HDOP von ich glaube über 2 oder 3 sind die Daten schon kaum zu gebrauchen gewesen, da hier Abweichungen von 10 Metern und mehr von der eigentlichen Strecke bestehen.
Wird denn sowas nicht über die DOP Werte berücksichtigt? Winkel sagt mir gerade nichts…welcher Datensatz wäre das denn?

@womisa: das bringt leider nichts. Ich nehme extra ein OLED, damit man es bei jeder Witterung ablesen kann… die schönsten INformationen bringen ja nichts, wenn man das Display abdunkeln oder gar unters Hemd halten muss, um etwas drauf zu erkennen :wink: Die OLEDs hier sind pervers hell…habe eine Uhr gebaut, welche ich auf 2 einzelne Pixel umstellen muss nachts, damit das Zimmer nicht ausgeleuchtet wird. Sogar die zwei einzelnen pixel (mitte + Minute in sekundentakt Blinkend) leuchte genug, dass ich in einem Umkreis von 2 Metern nirgendwo gegenlaufe, wenn ich auf die Toilette muss :wink: Und das ist sogar schon der gedimmte Zustand (ca. 2/3 der Helligkeit).
Ein TFT bzw. OLED mit SD wird beim Mapduino eingesetzt. Dieses wollte ich aber nur für Kartendaten nutzen. Es sollen zwei SD-Slots vorhanden sein - eines rein für das logging und eines für die Karten. Eine Idee ist es, dass ich eine Konfigurationssoftware unter Windows erstelle, mit welcher man den Logger bequem einstellen kann. Vielleicht paar funktionen, die direkt am Gerät nicht einstellbar sind. Ist ein wenig fummelig mit zwei/drei Tasten Zahlen einzugeben. Dadurch wird das ganze innerhalb kürzester Zeit mit paar Klicks und Eingaben erledigt. Weiterer vorteil: man erstll sich zwei SD-Karten für den Logger. Eine mit eine Konfiguration für’s Mapping (alle Koordinaten in höchster Geschwindigkeit abspeichern) und eine für’s Wandern/Biken oder was auch immer (z.B. nur jede 10 Sekunden oder 15 Meter usw. abspeichern). Das ganze ggf. mehrfach auf dem Gerät speicherbar. Also übernahme Konfiguration von SD-Karte auf Speicherslot Nr. x von 10.
Weiterer Grund für die Verwendung von zwei SD-Karten ist die Geschwindigkeit. Auf die SD-Karte für’s Logging greift der Arduino zu - auf die SD-Karte mit dem Kartenmaterial der Teensy. Würde man nun eine SD-Karte nutzen, dann müsste der Arduino GPS-Daten speichern und Kartendaten laden + an Teensy weiter leiten. Das wäre nicht nur noch langsamer als es schon ist (normal um 200-250 kb/Sec - es ist halt kein USB 3.0 ;), sondern würde den Arduino ständig belasten, was zu einem höheren Stromverbrauch führt.

@Reclus: ähnlich ist es nicht, da ich nur einen reinen GPS Logger/Tracker plane und keine mobile Vermessungsstation :wink: Das hier aber wurde schon vor Jahren mal im Forum diskutiert und könnt natürlich auch hier eingebaut werden:
“Dieser Beschleunigungssensor misst die Vibrationen bei der Fahrt”, erklärt Oertelt. “Je unebener der Weg ist, desto höher sind die Vibrationen. Anhand dieser Messungen kann man die Befahrbarkeit und den Komfort des Radwegs objektiv beurteilen.”

Da ich den Quellcode offen stelle, können hier paar Leute natürlich eine spezielle OSM-Version entwerfen, welche den Untergrund anhand von Vibrationen/Ausschlägen “scannt” und entsprechend einträgt. Man bräuchte nur je Fahrrad eine Kalibration durchzuführen (mein Fully mit 160mm Luftfederung vorne bleibt da ziemlich ruhig - hier müsste man den Sensor aus dem Gehäuse herausführen und direkt an der Vordergabel befestigen. Das wäre eine Änderung gegenüber meiner Version, welche anhand des Beschleunigersensors nur erkennen soll ob und wieviel man sich bewegt, um das logging zu stoppen/starten). Ändert sich der Belag, so würde der kleine nachfragen ob er richtig schätzt. So wäre es möglich nciht nur neue Strassen gleich korrekt mit dem Grade und Surface aufzunehmen, sondern bestehende Wege zu ergänzen bzw. korrigieren.

Die DOP sind errechnete Werte aus der Konstellation der genutzten Satelliten. Optimal z.B. stehen die Satelliten in einem Winkel von 90° zueinander. Schlechter DOP hat geringere Genauigkeit zur Folge, das Umgekehrte gilt aber nicht unbedingt, da noch etliches andere die Genauigkeit verschlechtern kann. Die DOP-Werte sind so etwas wie ein best case.

Historisch waren sie mal ein Maß für die künstliche Verschlechterung der Signale für zivile Nutzer durch das US-Militär (dilution of precision).

Die Wikipedia erklärt das schön anschaulich anhand von Bildern: https://de.wikipedia.org/wiki/Dilution_of_Precision

Ich würde in jedem Fall auf die Verfügbarkeit von Ublox M8U warten, weil das (vermutlich) der erste Receiver mit headless DR ist.
Man kann sich also eigentlich den separaten Gyro und Compass sparen, zumal man es selbst sowieso nicht gerechnet bekommt.

Da ich meine Beiträge leider nicht editieren kann, Nachtrag:

Wenn das jemand “komplett” bauen möchte, ggf. mit Gehäuse aus dem Drucker dabei: Ich würde das als Bausatz bestellen wollen (auch mit Aufschlag), nur damit ich mir die Teile nicht selbst zusammenklauben muss.

Hier eine Vorgehensweise wenn man die GPS-Rohdaten haben möchte (zwecks Korrektur):

http://www.dg1sfj.de/funk/geraete/79-ublox-ms1-gps-modul

Gruß Klaus

@ad: Die Frage ist immer: was kostet es? Der kostet ja schon so in normalen Shops um 90 € - gegenüber der 15 € des 6M ist der Aufpreis nicht berechtigt, da er ja nicht um das sechsfache genauer ist. Wenn da jetzt noch das DR rein kommt, wird der sicherlich nicht günstiger.
Das derzeit beste Modul mit dem M8N ist dieses hier - mit einem eingebauten Kompass + grosser 35mm Antenne. Dafür ist das Modul ganze 5x5 cm groß:
https://drotek.com/shop/en/home/613-ublox-neo-m8n-gps-hmc5983-compass-xl.html Genua dieses habe ich in D nicht unter 90 € gefunden. Aber Frankreich ist ja nicht soo weit weg…

Wenn ich das via irgendeinen GPS-Empfängers + 9-achsen Sensors (auf den werde ich umsteigen, da kompakter als beschleuniger+gyro und Kompass extra - zudem kosten die 9-achser 10-15 €) das selber machen kann ist man flexibler in der Auswahl der Komponenten. Da ich auch Bluetooth einbauen will, kann der Logger nicht nur auf SD-Karte speichern, sondern auch parallel (was bt747 und andere Logger wahrscheinlich auch nicht) über Bluetooth das Smartphone füttern kann. Oder umgekehrt: über Bluetooth GPS eines anderen Loggers empfangen und übernehmen oder parallel zum eingebauten abspeichern…bt747 im Rucksack und den Osmuino am Lenkrad. Theoretisch kann dann via DOPs/Satstellungen entschieden werden von welchem Logger die aktuelle Koordinate genommen weren soll, um möglichst genaue Streckenaufzeichnung zu gewährleisten.

Das mit dem Beschleunigersensor Es muss ma nnicht perfekt funktionieren. Hauptsächlich gehts erstmal um die Erfassung von Stillstand und vermeidung der Springens der GPS-Koordinaten bzw. überhaupt der Stop der Aufzeichnung dieser, da man sich ja nicht bewegt.

Bzgl. Antennenausrichtung hatte ich beim Mapduino angedacht ein Micro-Servo einzubauen, welches die GPS-Antenne bzw. das aufgesteckte Osmuino ständig in die Waage bringt. Ist besonders am Lenker interessant bei Steigungen/Gefälle. Zusatzkosten Servo: 2 € (ggf zwei Sütck, falls das Gewicht für diesen zu hoch ist und die Ausrichtung dadurch zu lange dauert)

Zum Bausatz:
ich habe hier seit über einem Jahr teile für einen RepRap Mendel90 rumfliegen - sogar eher für zwei. Haupthobby ist ja basteln, weshalb ich so ein Teil schon vor vielen Jahren gebraucht hätte :wink: Damit will ich u.a. Gehäuse für Raspberrys und andere Spielereien drucken. Damit ließe sich zumindest ein Prototyp drucken. Das Gehäusedesign wäre dann logischerweise auch Open, was sich dann jeder beim Kumpel oder bei einer 3D-Druckerei bestellen kann.

Auf die Idee eines Shops mit allen Teilen bin ich auch gekommen. Ist mir aufgefallen, als ich über gut fünf Shops verstreut Teile zusammen suchen musste. Wäre natürlich einfacher, wenn man alles in einem Paket zusammen bekommt. Von Minimal-Lowcost bis Highend-mit-allem. Aber das ist bisher nur eine Idee. Müsste nämlich alles direkt aus China in entsprechenden Stückzahlen rüber, damit das überhaupt was bringt.

Bin Mittwoch irgendwann wieder Daheim - kann dann mal paar Fotos und Gewichte der ganzen Teile Posten, sowie die mögliche Größe des ganzen.

Eventuell diese Bausteine als (fertige) Hardware_Basis?

https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-NANO/open-source-hardware
https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-NANO-BAT/open-source-hardware
https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-NANO-BB/open-source-hardware

https://www.olimex.com/Products/Modules/GPS/MOD-GPS/

…etc…

Ich habe mir vor langer Zeit mal einen “Fensterbank-Logger” damit zusammengfriemelt. Das funzt gut, kam aber aus dem Bastelstatus nicht heraus. Da Gehäuse und die Altagstauglichkeit fehlt.

Da es zwischenzeitlich Smartphones mit den oben aufgeführten Fetures gibt, habe ich mir vor kurzem ein LG Wine Smart angeschafft. Man kann ja selbst ein Android Programm entwickeln, falls man mit den zur Verfügung stehenden nicht zu frieden ist.
Eventuell noch gewünschte intelligente Hardware mit eigenem Prozessor über Bluetooth einbinden…?

Ich denke halt, dass man beim Selbstbau niemals eine solches kompaktes und laufstabiles Gerät hinbekommt…

@womisa: Viel zu groß und zu teuer. Arduino Pro Mini ist 18x33mm klein und wiegt unter 2 Gramm und kostet um 4-6 €. Das wiegen bei dem Modul wahrscheinlich die ganzen Buchen schon… :wink: Und mehrfach so teuer ist es auch.

“LG Wine Smart” → Akkuleaufzeit von 100-200 Stunden im GPS-Logging Modus? :wink:
Und wieviele Stunden als Karte? Ablesbarkeit bei direkter Sonneneintrahlung?

“Ich denke halt, dass man beim Selbstbau niemals eine solches kompaktes und laufstabiles Gerät hinbekommt…”

  1. ist bzw. wird es kompakter und viel leichter und 2. wieso sollte es nicht laufstabil sein bzw. werden?

Mit den Aduinos werden auch Smartwatches gebaut - was ich mit einem 0,96" oder 1,3" Oled auch vor habe. Eher aber mit einem 8266er statt Arduino, da es hier noch kompaktere Platinen gibt.
Hier eines der Projekte - “Retrowatch”:
http://www.instructables.com/id/Make-your-own-smart-watch/

…ok!

…muß man aber nicht vertiefen!
Das “Arduino Pro Mini” hat aber noch keine SD Karte und keinen USB Anschluß… Die EXT-Buchse kann man leicht weg machen und 30x30x15mm mit dem Akku Modul ist auch nicht all zu groß…

Ich habe das WineSmart als Ersatz für meinen bisherigen BT747 Logger, der etwas schwächelt. Ich nehme das WineSmart als reinen Logger und Notfalltelefon und bin vom Akkuverbrauch positive überascht!

Ps: Falls das ein OpenSource Projekt wird, werde ich als Hobby mit meinen eingeschränkten Hardware/Löt Kenntnissen da auch was machen…

Damit ihr euch das besser vorstellen könnt, habe ich mal schnell die ganze Familie mit dem Handy geshootet :wink:

Erster Reihe:

  • Raspberry Pi
  • Arduino Uno (16 Mhz, 8 Bit MCU)
  • Arduino Micro (16 Mhz, 8 Bit MCU)
  • Teensy 3.2 (M4 96 Mhz, 32 Bit MCU - über 10 mal schneller als Arduino)
  • Arduino Pro Mini (16 Mhz bzw. 8 Mhz bei 3,3V für Osmuino, 8 Bit MCU)
  • ESP8266 (minimalste Version, die ich fad; Deutsche Herstellung; 160 Mhz, 32 Bit MCU - gut 20-fache Aduino Geschwindigkeit)
  • Piezo-Tongeber (die winzige goldene Scheibe - entspricht der Technik aus Glückwunschkarten)
  • im roten Gehäuse das bereits eingeklebte 1,3" OLED DIsplay (Platine etwas kleiner als vom Bildschirm rechts unten)
  • Mein aalter BT747a+ Logger :wink:

Zweite Reihe:

  • Nokia Akku für den BT747 Logger
  • Micro (AAA, ~700 mAh), Mignon (AA, 1900 - 2800 mAh) und 18650er LiIon Akku (2000-3000 mAh)

Oben:

  • Bluetooth-Modul (suche noch kleinere)
  • zwei verschiedene 3-Achs Beschleuniger+Gyros
  • BMP180 Barometer-Sensor
    Unten:
  • zwei verschiedene Echtzeituhren (kleiner als TinyRTC links gehts wohl nicht - muss man ein wenig dran rumfeilen)
  • 1,8" TFT LCD mit Micro-SD-Kartenslot auf der Rückseite

Der Arduino Pro Mini soll das kleine Display antreiben, während der Teensy die Kartendaten lädt und bearbeitet. ESP8266 wird rein für die Bildschirmausgabe des TFT/OLED genutzt, da hier jeder Pixel einzeln verschickt wird. Mit dem Arduino dauert das Füllen eines 320x240 Bildschirms mehrere Sekunden (!).

Was hier noch fehlt:

  • Ein zusätzlicher Microsd-Kartenslot für den Logger. Ist kaum größer als die Karten selbst
  • GPS Modul (ist ca. 35x35 klein + genauso großer Antenne an einem ca. 6-8 cm langem Kabel mit Micro-SMA-Stecker)

Das endgültg geplante Display für die Kartendarstellung soll ein 1,69" Farb-OLED mit 160x128 Pixeln sein (identische Auflösung zu dem 1,8" TFT hier). Weitere Displaygrößen - allerdings nur als TFT, dafür teils mit Touchscreen - wären 2.2", 2.4", 2.8", 3.2" und auch größere, falls nötig. Ab 2,8" gibt es dann fast nur noch AUflösungen mit 320x240.

Vergrößerter Ausschnitt:

Genau darum geht es: “USB-Buchse” ist gleichzeitig serielle Schnittstelle bzw. Controller, der Pausenos strom nimmt - obwohl ein mal nach dem Programmieren dieser fast nie wieder gebraucht wird :wink: (für das GPS-Modul wird sowieso ein USB-TTL Adapter benötigt. Mit diesem kann man die Arduinos ebenfalls programmieren). Dieser Chip verbraucht das mehrfache (hundertfache) des Standbymodus des Pro Mini…daher so abgespeckt wie möglich.
MicroSD module kosten um 2€ - zudem kann ich die im Gehäuse da hin platzieren, wo man hin kommt :slight_smile: Zusätzlich werden solche Module nicht direkt an den Strom, sondern an digitale Ausgänge gehangen, damit man diese nur mit Strom versorgt, wenn gebraucht.

Wie lange hält er denn bei welchen Aufnahmeintervalen? :slight_smile: Wie lange lässt du den je Loop-Durchlauf schlafen? Ohne spezielle Sparmaßnahmen verbrauchen die MCUs das hundert bis tausendfache dessen, was man durch gezielte Maßnahmen erreichen kann. Akkulaufzeiten beim reinen Loggen von Temperaturen von mehreren Monaten statt im Normalfall nur wenigen Stunden :slight_smile:

Das wird nicht sondern ist ein OpenSource Projekt :wink: Darfst gerne mitmachen :slight_smile: Könntest ja z.B. dein Projekt um so ein Oled-Display erweitern. Man könnte es ja mit aufnehmen - wie schon erwähnt, wollte ich Hardwareseitig das schon ein wenig streuen.