Posts by Pertl

    im deep Sleep Modus der von einer RTC DS3231 aufgeweckt wird.

    Leider habe ich mit der DS3231 bezüglich stromsparen schlechte Erfahrungen gemacht, da für den Alarm eine ständige, externe Stromversorgung benötigt und darüber ca. 150µA "verbraten" werden. Die Zeit läuft über interne Batterie weiter, aber Alarm geht nicht raus wenn man die Versorgung kappt. Deswegen arbeitet mein Arduino über internen Wake-Up und versorgt die RTC nur wenn ich die genaue Zeit benötige.

    Der $__timeFilter() hat nichts mit SQL zu tun, das ist eine reine Hilfe aus Grafana der wird bevor es an die Datenbank gesetzt wird durch extract(epoch from ) BETWEEN 1524573524 AND 1524584324 ersetzt (was nicht wirklich sinnvoll ist).


    Die Gruppierung übernimmt das GROUP BY und dann musst du hald eine zeitliche Gruppierung einführen.


    So dann noch eine Kleine Anmerkung am Rande:

    Die bisher dargestellten Abfragen nutzen noch nicht die Funktionen von Timescale, dafür sind dann nochmal etwas andere Funktionen zu verwenden.


    So noch kurz zum Schluss:


    Grafana ist ein echt super Tool und in Kombination mit InfluxDB auch ohne SQL Kenntnisse zu nutzen. Bei der Verwendung von Postgres bzw. TimescaleDB schaden Grundkenntnisse in SQL nicht (vielleicht sollte man auch bisschen mehr können), dass man vernünftige Ergebnisse bekommt (Finger weg von den Grafana-Makros). Aber Postgres bietet in kombination mit weiteren Erweiterungen wie z.B. PostGIS auch eine super Plattform auch für Grafana, da man damit dann wieder direkt z.B. das WorldMapPanel in Grafana füttern kann.

    Du verwendest das INNER JOIN falsch, bei dir ergibt sich dadurch nur eine Gruppe.


    mit on a.a=1 wählst du nur die Datensätze aus a aus die in spalte a.a eine 1 enthalten (wie bei einem WHERE nur hald im ON - so einen konstrukt habe ich ehrlichgesagt noch nie gesehen?! da du ja auch noch nichtmal die Tabelle nutzt auf die du verlinkst - dann würde das ganze etwas mehr Sinn machen) und auf beiden seiten auftreten (wegen INNER JOIN). vgl. z.B. folgende Grafik: http://www.office-loesung.de/files/visual_sql_joins_orig.jpg


    Wenn dann müsstest du deine Abfrage ändern, dass du wirklich auch Gruppen erhälst:

    Code
    select a.a, avg(a.b)-avg(b.b) from a inner join b on a.a=b.a group by a.a;

    mit dieser Abfrage solltest du bei deinem Minimalbeispiel 3 Gruppen (a.a = 1, 2, 3) erhalten. Avg kümmert sich um den Mittelwert der dann 2 ergibt.


    M.E. müsste da "-2" rauskommen, wenn Deine Annahme richtig wäre:

    Wie du auf -2 kommst ist mir ein Rätsel, bei deinem Beispiel müsste (wenn du das JOIN änderst): für Gruppe a.a = 1 -> -2, a.a = 2 -> 0 und a.a =3 -> 2 raus kommen (sofern ich jetzt auf die schnelle keinen schmarn gerechnet habe).

    Sehe ich es richtig, daß Ihr mit der Division durch 2000 die Intervalle in Doppelsekunden berechnet? Gibt's da einen bestimmten Grund für?

    1920 Pixel hat ein Monitor - also haben wir rund 2000 Datenpunkte als Grenze genommen, die mindestens angezeigt werden sollen.


    Funktion in Worten:

    Wenn 5 min größer als Anzeigezeitbereich geteilt durch 2000 dann setze 5min als Gruppierungseinheit. Damit erreichen wir dass immer mindestens 2000 Gruppen im Zeitbereich liegen und damit haben wir keinen (sichtbaren) Informationsverlust.


    Liegen denn die Messwerte für innen und aussen mit den exakt gleichen Zeitstempeln vor? Falls nicht würdet Ihr beim INNER JOIN über die Differenzen aller Innentemperaturen im Intervall zu jeweils allen Aussentemperaturen mitteln. Sollte aufs gleiche rauskommen, scheint mir aber ebenfalls umständlich.

    Ich habe gerade nachgesehen, die Datensätze haben exakt den selben Timestamp.


    Falls nicht würdet Ihr beim INNER JOIN über die Differenzen aller Innentemperaturen im Intervall zu jeweils allen Aussentemperaturen mitteln. Sollte aufs gleiche rauskommen, scheint mir aber ebenfalls umständlich.

    Ich vermute mal, dass für den INNER JOIN der ON Teil vergessen wurde, hab es gerade getestet und funktioniert einwandfrei. Auch die Perfomance ist verständlicherweise viel besser bei INNER JOIN als bei CROSS JOIN. Es gibt ja defeinitiv nur zwei Pärchen. Eventuell wäre noch ein FULL OUTER JOIN eine Idee, falls mal ein Wert in einer der beiden Tabellen fehlt.



    Ich kann jetzt alleine auch den Fehler nicht ganz nachvollziehen, bei meinem Test gerade in Grafana stimmte alles zusammen...

    Hofei hat gleich Feierabend dann telefonieren wir, Infos folgen.


    Edit-Hinweis: besser ist avg(intemp) - avg(outtemp) da bei ungleichen Datenpunktanzahl sonst das Ergebnis abweicht bzw es sogar zu einem Fehler kommen könnnte....

    So da ich der Schuldige an dem ganzen Thema bin (Hofei ist auf meinem Server ansässig), kurz mal ein Kommentar zu dem ganzen von mir nachgeschoben. Da ich die Diskussion (Influx vs. Postgres mit Timescale) bereits vielfach geführt habe und deshalb hier auch noch ein paar Infos für alle Skeptiker ;)

    Die entsprechenden SQL-Kommandos sind in der Grafana-Syntax für den Einsatz mit Influx vorhanden.

    Auch der gleichzeitige Zugriff auf mehrere Datenreihen ist einfach.

    Ich arbeite seit ca. 2 Jahren mit diesem Duo und bin sehr zufrieden - es gibt nur weniges, was nicht geht (und ich habe noch ein Grafana/Influx von 2016 (ohne Aktualisierung))

    Influx ist schön und gut für die Datenspeicherung und einfache Abfrage der Daten als Zeitreihen. Auch die Zusammenarbeit mit Grafana ist bei Influx wirklich gut. Aber sobald es an die Auswertung / Analyse der Daten geht ist Influx einfach vollkommener Müll.


    Ich beschäftige mich sehr viel mit Metereologischen (Regen, Grundwasserstände, Temperatur, ...) und Verbrauchs-Daten (Trinkwasser). Influx mag wunderbar funktionieren, wenn ich wissen will wie im Zeitbereich von t1 bis t2 der Verlauf bezogen auf ein Intervall x ist. Aber sobald komplexere Fragestellungen auftauchen Scheitert Influx (z.B. Differenzwerte aus zwei Tabellen). Innerhalb einer Tabelle würde es funktionieren, aber dies würde dazu führen, dass man einfach alle Daten in eine Tabelle füttern müsste?! Vielleicht wie hier im Beispiel bei Innen- und Außentemperatur noch sinnvoll, bei vielem anderen aber nicht (z.B. Wasserverbrauch und Außentemperatur).


    Des weiteren sind Fragestellungen wie: Gib mir die statistischen Größen für den typischen Trinkwasserverbrauch über den Wochengang aus (für jeden Tag den Mittleren und Gesamten Verbrauch, die Standardabweichung, ...). Hier ist bei InfluxDB immer ein Postprocessing notwendig und dadurch sind die Werte in Grafana nicht darstellbar bzw. nutzbar. Für mich wäre z.B. eine Alarmierung über Grafana bei einer Abweichung von über 15% vom durchschnittlichen typischen Tagesverbrauch des Trinkwassers interessant. Das ganze ist in Abhängigkeit von Temperatur, Tag (Wochentag / Feiertag), Monat, ... Über Timescale (Postgres) ist man in der Lage die Fragestellung mit einer Abfrage zu lösen, mit Influx geht das ganze ohne Postprocessing nicht bzw. müsste man für die Darstellung die temporären Daten (des Trinkwasserverbrauchmodells in Abhänigkeit von Tag, Monat, Temperatur, ...) erst in die Datenbank speichern um die Daten dann wieder auswerten zu können.

    $__timeFilter() eine Funktion (Makro) welche von Grafana zur Verfügung gestellt wird:


    - $__timeFilter(column) -> extract(epoch from column) BETWEEN 1492750877 AND 1492750877

    Wie bereits erwähnt ist diese Funktion zwar implementiert in Grafana allerdings sehr ineffizient.

    vgl. https://github.com/grafana/grafana/issues/11578


    Die ganz Zeitstempelarithmetik kommt mir extrem umständlich vor. Ich kann mir nur schwer vorstellen, daß das nicht einfacher geht – da ich Grafana allerdings überhaupt nicht kenne, kann ich leider keinen konstruktiven Vorschlag machen, wie das sein sollte.

    Es gibt Gründe für die ganze Kompexität der Zeitstempelarithmetik: Da man auf der Web-Oberfläche beliebige Zeitbereiche auswählen und analysieren kann, muss man hier etwas steuernd eingreifen. Die Funktion set_intervall benötigt man aus dem Grund, da der Zeitbereich beliebig gewählt werden kann. Fragt man nun z.B. 24 Stunden ab erhält man bei 15 Minuten (das Messintervall) 96 Datensätze zur anzeige, soweit kein Problem. Sieht man sich allerdings die Werte für ein Jahr an erhält man schon 35 040 Datensätze und so weiter. Aus diesem Grund werden die Daten über ein sinnvoll kleines Intervall gruppiert, so dass die Darstellung nicht darunter leidet, aber die Datenmenge möglichst gering ist.


    Die Funktion haben wir (mal schnell zum testen - daher nur manuelle Werte über IF) von der Grafana-Schnittstelle für InfluxDB agekupfert, da es hier (intern) genau so gemacht wird. So ich muss jetzt arbeiten - ich werde mir das Problem mal am Abend genauer ansehen und mich nochmal melden ;)

    Jup kann gerne aushelfen, war nur die Tage bisschen viel Arbeit - die Selbstständigkeit hat mal wieder mit SELBST und STÄNDIG zugeschlagen :shy:

    Hab jetzt mal blos alles kurz überflogen - ab Montag sollte es wieder leichter gehen bei mir... Aber kurz mal eine kleine Hilfe vorab ins Blaue.

    Auch suchen. "python round number", "python round decimal". Suchmaschinen beißen wirklich nicht. Ich kaue das hier nicht nochmal durch, sorry.


    Ich logge mich mal aus, bis irgendwann in 1-2 Wochen mal. Vielleicht hilft Pertl ja noch.

    Zahlen Runden machst du am besten über die Methode format()

    Code
    gekuerzt = "{:.2f}".format(zahl)

    Die Funktion wandelt dir die Zahl in einen String um {:.2f} steht in dem Beispiel als Platzhalter eine Fließkommazahl mit 2 Nachkommastellen.


    Soweit ich das in aller kürze sehe, dürfte es zu keinen größeren Problemen kommen, wenn du anstelle einer Zahl einen String mit einer Zahl in deinem Code verwendest. Wichtig ist Zahlen immer erst ganz am Ende für die Ausgabe vorbereiten (z.B. mit format-Methode) da du mit Strings nicht rechnen kannst ;)

    Google Translate ist Müll :baeh2:

    Dann lieber DeepL (https://www.deepl.com/translator), die können noch kein Japanisch.

    Ich weiß - aber mangels Japanisch auf die Schnelle keine Alternative parat gehabt. Und bevor ich japanisch lern ist mir google lieber ;)


    Nö, bitte niemanden anstiften, noch Python 2 zu verwenden! :baeh2:
    ...

    python-kurs.eu ist keine, ich wiederhole: keine gute Quelle, um Python zu lernen. Dort wird teilweise nicht sehr idiomatisches Python "gelehrt"...

    Wenn kein Python 2 in Frage kommt, dann müsste man den Code des Repos anpassen ;) z.B. i2c_sensor/lib/Adafruit_I2C.py Zeile 50, 77, 85, ...

    Ob dein Code unter Python 2 läuft - kann ich mangels Können und Erfahrung in Python 2 nicht beurtilen - als Quelle habe ich einfach das oberste Ergebnis aus google genutzt.

    Sieht ja schonmal gar nicht so schlecht aus :)


    Die für dich relevanten Code-Zeilen wären dann:


    Python
    from ina226 import INA226
    
    
    if __name__ == '__main__':
        sensor = INA226(False)
        spannung = sensor.get_voltage()
        strom = sensor.get_current()
        leistung = sensor.get_power()

    Anmerkung für potentielle Fehlersuche, bin ich grade drüber gestolpert, Python-Code ist in 2.7 also für die Speicherung entsprechende Tutorials für Python 2 verwenden.

    ... dann noch eine Speicherung (wo auch immer, wie auch immer... Textfile? DB?) hinzufügen.

    Hier wärst du uns noch eine Antwort schuldig geblieben... aber vielleicht einfach mal selbst probieren, wir helfen gerne weiter.


    Beispiele einfach googlen z.B. "Python Datei schreiben" https://www.python-kurs.eu/dateien.php

    weitens kann ich kein Japanisch, sonst könnten mir evtl. die Kommentare ja weiterhelfen


    Kleiner Tipp: Google kann Japanisch ;)
    https://translate.google.de/tr…-on-raspberrypi-python%2F


    Äh Repo????? :conf:

    Wikipedia:


    Ein Repository (englisch für Lager, Depot oder auch Quelle; deutsch Plural Repositorys), auch – direkt aus dem Lateinischen entlehnt – Repositorium (Pl. Repositorien), ist ein verwaltetes Verzeichnis zur Speicherung und Beschreibung von digitalen Objekten für ein digitales Archiv. Bei den verwalteten Objekten kann es sich beispielsweise um Programme (Software-Repository), Publikationen (Dokumentenserver), Datenmodelle (Metadaten-Repository) oder betriebswirtschaftliche Verfahren handeln. Häufig beinhaltet ein Repository auch Funktionen zur Versionsverwaltung der verwalteten Objekte.

    Also ein Repository oder Kurz Repo ist einfach ein Depot für den Quellcode z.B. Github, Gibtlab oder ähnliches.

    Also du soweit ich das sehe brauchst du blos die Daten vom Repo laden.

    Code
    git clone https://github.com/R2D2Prj/i2c_sensor

    Git clone lädt das Github-Verzeichnis runter. Es legt automatisch ein Verzeichnis i2c_sensor (mit Namen des Repo) an, in dem du die notwendigen Scripts für das Auslesen findest. Dann solltest du die Dateien bereits ausführen können.


    In wie weit die Chinesischen Zeichen in den Kommentaren eventuell Probleme machen kann ich nicht sagen :conf:, da ich sowas noch nie in meinem Quellcode hatte.

    Hallo,


    Also ich habe den Sensor auch rumliegen, ich glaube das es nichts viel günstigeres geben wird (den Sensor gibts für ca. 2€).


    Das Projekt halte ich an sich für ambitioniert aber durchaus interessant. Allerdings gibt es viele Dinge die du dir vor Projektbeginn mal durch den Kopf gehen lassen solltest.


    1) Was willst du erkennen? große Objekte: Häuser, Bäume, Hecken oder kleine Objekte: andere Drohnen, Masten, Maschendrahtzaun...

    Gerade was feine Bauteil angeht, glaube ich nicht dass der Sensor sie gut erkennen kann, das müsste man auf jeden Fall austesten.


    2) Wie willst du die Drohe ansteuern bzw. den Kollisionssensor verwenden? Automatische Kollisionsverhinderung bedarf eines Steuerungseingriffes durch die Messeinheit. Gibt es hierfür eine Möglichkeit?


    3) Was passiert bei Steig/Sinkflug bzw. wenn die Drohne beschleunigt und dabei geneigt ist? Die Sensoren erkennen dann ggf. keine Hindernisse mehr die direkt vor der Drohne liegen.


    4) Wie soll die Stromversorgung sichergestellt werden? Ein Raspberry ist sicher die Stromfressenste Variante und für die Anwendung. 24 Sensoren wirst du nicht an einem Raspberry Pi abgefragt bekommen. Hier wär eine Lösung mit µC wahrscheinlich sinnvoller (vielleicht kann man auch ganz auf den Raspi verzichten da Stromsparender und schneller da kein OS bremst).


    5) Wie schnell fliegt deine Drohne bzw. das zu erkennende Hindernis (falls bewegliches erkannt werden soll)? Wäre für die Signalverarbeitung und reaktion relevant.
    Beispiel: Geschwindigkeit 20km/h = 5,6m/s, Messbereich 1,50m (lt. deiner Frage) -> 0.27s bis Kollision (in der Zeit soll gemessen, verarbeitet und reagiert sein - ich befürchte dass hier der Raspberry durch OS-Einflüsse usw. ungeeignet ist). Des weiteren ist die Frage ob die Ansteuerung (Drohnenseitig) überhaupt so schnell funktioniert.


    bin neu im Forum und habe auch Allgemein nicht viel Erfahrung mit Raspberry, habe aber vor in kürze einige Projekte zu starten.

    Ganz ohne Erfahrung ist das Projekt relativ ambitioniert. Hast du mit µC Erfahrungen?

    Ich habe mich mit meinem Laptop auch sehr lange gespielt und immer wieder Probleme mit Dualboot gehabt. Meine schlussendlich seit mehreren Jahren stabil laufende Lösung möchte ich kurz mit euch teilen:


    Ich habe einfach Windows auf der einen Festplatte und Linux auf einer zweiten Festplatte. Jeweils als Installation samt Bootloader auf der jeweiligen Festplatte. Als "Bootmanager" nutze ich BIOS / UEFI. Beim Startvorgang F8 gedrückt und schon kann ich die Boot-Festplatte auswählen. Ich glaube dass ich noch "FastBoot" bwz. "SecureBoot" oder wie das Feature auch immer heißt deaktivieren musste.

    ich bin schon bastelfreundlich

    Wenn etwas mit Arbeit zu tun hat, stört es auch nicht. Wenn ich weiß, dass es geht, versuche ich so einiges.


    OK dann probier mal deinen Sensor vom Chinamann, falls du an physikalischen Experimenten interessiert bist kann ich mal bischen im Physik-Baukasten suchen ;)

    Mal kurz BTT: Ich werfe jetzt mal kurz was ein, da ich nicht weiß wie bastelfreundlich der Guido ist. Es gäbe noch die Möglichkeit einen "Drucksensor" selbst zu bauen und dann z.B. mithilfe von Wasserstandsmessungen oder Drehgebern (ähnlich wie bei analogem Manometer) den Druck abzuleiten. Mir fielen da ein paar Möglichkeiten ein, wie man die Physik hier nutzen könnte bzw. es gibt auch im Netz einige Anleitungen für Do-It-Your-Self Analog-Manometer, die müsste man hald um eine Elektronische Komponente erweitern (aber Drehgeber oder z.B. Ultraschallsensor zur Wasserstandsmessung sind deutlich günstiger als Drucksensor). Wobei wir hier dann hald von erheblichen Einbusen in der Genauigkeit sprechen - wobei ein Analog-Manometer auch auf 0.1 Bar Skala eine Ablesung von rund 0.025 Bar möglich ist - was im Verglich zum Drucksensor ja auch noch sehr ungenau ist.


    Ich gehe mal davon aus, dass wir sowieso von Relativdruckmessung sprechen und nicht dem Absolutdruck?!

    Hi,


    also ich habe im Rahmen meiner Forschungsgruppenarbeit an der Uni zum Thema Drucksensoren (im Trink- und Brauchwasserbereich) einiges gelernt. Anfänglich dachte ich auch das rund 20€ doch ausreichend sein sollten für derartige Sensoren - allerdings wurde ich eines besseren Belehrt.


    Wir hatten den einen verhältnismäßig günstigen Sensor (ich glaub es war dieser: [1]) um 40€ ausgetestet. Leider ist das Ding äußerst unzuverlässig was die Messgenauigkeit angeht, da der Nullpunkt relativ instabil ist. Das heißt folgender Versuch: Sensor ohne Druck auslesen: 0.7 Volt; mit Druck beaufschlagt: 3.8 Volt; Sensor ohne Druck auslesen: 0.6 Volt. Werte sind frei erfunden, nur um das Problem zu verdeutlichen. Auch beim Langzeitversuch konnte kein einpendeln des Nullpunkts erreicht werden. Wie das Druckverhalten ist wenn der Sensor ständig unter Druck steht habe ich leider keine Erfahrungen.


    Wir haben uns dann für einen etwas teuereren Sensor [2] entschieden der sich relativ stabil verhällt. Davon haben wir aktuell einige im Labor in Einsatz und sind auch mit den Messergebnissen und deren stabilität zufrieden.

    Grundsätzlich zeigen die Erfahrungen bei diversen anderen Projekten, für vernünftige Relativdrucksensoren (zur statischen Druckmessung) musst du rund 80-120€ ausgeben, dass auf das Ergebnis vertraut werden kann. Grundsätzlich solltest du auf Sensoren in Edelstahlgehäuse zurückgreifen und Sensoren mit Dichtungen die wassertauglich sind verwenden. Im Grunde kannst du dir hier [3] einen entsprechenden Drucksensor raussuchen, je nach Anschluss/Medium/Druckbereich.


    [1] https://at.rs-online.com/web/p/drucksensoren/1115921/

    [2] https://at.rs-online.com/web/p/drucksensoren/8315616/

    [3] https://de.rs-online.com/web/c…esswandler/drucksensoren/

    Für Telegram gibt es einen Client am PC, mit dem du die gleiche Kommunikation wie am Handy nutzt (ähnlich wie Signal, Whatsapp, ...)

    Wobei es hald noch den Zusatz gibt, dass man für Endgeräte ohne Handy (bei mir z.B. 2 Raspis, 2NAS, mein V-Server und ein realer Server) habe ich jeweils einen Bot angelegt (teilweise nutzen mehrere Geräte den selben "Bot" = eigentlich eine Absenderadresse ohne Handy-Nummer) z.B. habe ich einen "AlarmBot" über den bekomm ich im Störfall eine Benachrichtigung (1 Bot für alle Geräte) - des weiteren Nutze ich aber z.B. einen Bot, der mir wenn ich ihn Auffordere aktuelle Messwerte zusendet (z.B. ich sende an den Bot den Text "Temperatur" und er antwortet mir mit "22 Grad") und einen Bot der für mich Fahrtenbuch und Stundenaufzeichnungen macht (je nach gesendetem Text)

    Möglichkeiten sind Grenzenlos, Bots kannst du z.B. auch zu Gruppen hinzufügen, Dateien schicken / emfpangen / verarbeiten


    In Planung habe ich z.B. noch einen Bot der mir Fotos die ich ihm sende gleich am Server in das richtige Projektverzeichnis legt.

    Ich versteh aber auch weiterhin nicht wieso Du überhaupt einen ESP32 für einfache Messungen in Betracht ziehst - zumal du kein WLAN nutzen willst sondern GSM, da wäre selbst ein ESP8266 die falsche Wahl...

    eigentlich habe ich den ESP für private experimente gekauft und wollte nur anhand des Chips einfach die gemessen Werte aus dem Unisystem (rapidM2M M3) evaluieren. Da der bereitgestellte Chip auch Bluetooth und den ganzen anderen Schnickschnak hat dachte ich es wäre für Vergleichsmessungen ausreichend.


    https://www.microtronics.com/de/produkte/rapidM2M_M3.html


    Es gibt genug µC die mit Sensoren und GSM sprechen können

    Das ist so bischen das Problem, dass selber bauen immer bischen schwierig ist, soll heißen: ich mache Entwurf, Labortechniker baut es und ich kann es dann nutzen. Und dort fiel die Wahl auf oben gennantes fertiges Modul, mit dem ich mich jetzt auseinandersetzen muss.... und dessen Werte ich über Messungen am ESP32 abgleichen wollte.



    kommst du sogar ohne GSM aus, je nachdem wie die Umgebung aussieht könnte evtl. LoRa reichen

    LORA hatten wir schon auf dem Tisch, allerdings mangels Infrastruktur (Gateways usw.) zum flächendeckenden Einsatz verworfen.



    EDIT:


    Sry vergas zu erwähnen, dass ich das wir ausgemacht habe ;)


    gestern haben wir den

    Wäre der ESP32 dafür nicht etwas oversized? Was spricht gegen den ESP8266 ?

    Eigentlich nichts, hab nur vom ESP32 gelesen und wollte den mal ausprobieren. Grundsätzlich gehts mir eigenltlich eh blos darum, dass ich einen vernünftigen Wert bekomme, mit wie viel Stromaufnahme ich im Sleep-Mode rechnen muss.


    Kurzer Exkurs warum das ganze überhaupt gestartet wurde:
    Ich arbeite derzeit an meiner Diplomarbeit (Bauingenieur) im Bereich Siedlungswasserwesen. Mir wurde Mess- und Übertragungelektronik bereitgestellt - die im Tagesschnitt 22mA bei 5 Volt braucht. (Betriebsmodus 2x täglich senden, minütlich messen) Ziel war daher eigentlich mit einem SIM800 Modul und dem ESP Vergleichsmessungen zu machen um nächste Woche klar stellen zu können dass irgendwas mit der Messelektronik schief läuft (zu viel Stromverbrauch). SIM Modul benötigt zum senden rund 1 Minute und bis zu 3 Ampere, Messsensor benötigt 5mA beim messen (ca. 1 Sekunde). Rechnet man das ganze mal hoch ist eigentlich ganz egal was man zum Senden (2 Minuten täglich) oder Messen (24 Minuten täglich) braucht.
    Ich habe anbei mal eine kleine Excel-Aufstellung die links die gestern ermittelten Werte (im schlimmsten Fall mit ESP) darstellt. Man sieht bereits hier, dass wir im Tagesschnitt um 10mA weniger benötigen als in der bereitgestellten Messelektronik. Jetzt mal vorausgesetzt, dass der AMS1117 nochmal gute 5mA verbrät, wäre ich bei einem durchschnittlichen Strom von 8.77mA (rechter Teil).
    Da das Ziel der Arbeit, die Untersuchung von autarken Messeinheiten ist, die sich über Mini-Generatoren selbst mit Strom versorgen, muss ich so haushalten, dass mein erzeugbarer täglicher Strom (ca. 2000-3000 Ws hätte ich mal grob als Potential errechnet) abzüglich Verluste beim Laden/Entladen von Li-Po / Li-Io Akku größer ist als die verbrauchte Energie ist.


    Da wir leider nicht 100%ig von der Studienrichtung her die Kompetenz besitzen und man sehr viel liest im µA Bereich - wollte ich einfach mal "Leihenhaft" das ganze nachvollziehen können. Es handelt sich ja wie gesagt rein um eine Machbarkeitsstudie und reine Prototypen, die dann sicherlich von Elektronikern viel besser umgesetzt werden können.


    Also Schlussendlich steht für mich noch immer die Frage im Raum, kann ich mit 2000-3000 Ws täglich einfache Messelektronik mit GSM-Übertragung autark betreiben. Ziel sollte sein in den Bereich, der vermutlich ohne den AMS1117, erreicht wird zu kommen (mit professionellerer Ausarbeitung als meiner kann dann der Betrieb sichergestellt werden). Ich werde die nächsten Tage mal auf Support-Antwort vom Chip-Hersteller warten ob die genauere Werte haben für Sleep-Mode und ansonsten werde ich meinen Chip opfern und mal das Bauteil entfernen.

    Wenn du den also abklemmst sinkt dein Verbrauch auf 4,5mA?

    Das habe ich mich noch nicht getraut


    Zu beachten ist übrigens auch zu dem von Heise.de angeblich verwendeten ESP32:

    >>Wir haben uns das Developer Board des ESP32 angeschaut. Bisher haben erst 200 Beta-Tester weltweit ein ESP32-Entwicklerboard bekommen. Auf diesem ESP-WROOM-03 ist ein Chip mit der Bezeichnung "ESP31B" verbaut, der sich zu dem endgültigen Chip noch unterscheiden kann.


    Quelle: Den von Hofei genannten Artikel


    Bei mir am Board ist ein Chip mit der Bezeichnung ESP-WROOM-32 verbaut.


    Naja wie raspiprojekt bereits indirekt anmerkte, habt ihr nicht nur einen nackten ESP-WROOM-32 sondern es befindet sich auch noch ein USB-TTL-Converter uf der Platine.

    Irre ich mich oder kann ich ohne den USB-TTL-Converter das Ding gar nicht programmieren? Oder wäre es z.B. möglich, dass ich einen reinen ESP-WROOM-32 Chip nehme, einen USB-TTL-Converter anstecke zum Programmieren und dann für den Betrieb wirklich nur den blanken Chip [1] nutze? Allerdings muss ich mich dann auch wieder um Akkuanschluss usw kümmern - also im Endeffekt wieder das was am Board drauf sitzt doch anbauen. Sind meine Erwartungen zu hoch, dass man damit eine Messeinheit auch > 6 Monate hinweg sinnvoll für kleines Geld betreiben kann? Ich habs gestern mal überschlagen die Elektronik wäre 99% der Zeit im Sleep-Modus...


    [1] z.B. https://eckstein-shop.de/Espressif-ESP-WROOM-32