Hallo, ich möchte über einen langen Zeitraum (mindestens 1 Jahr) im Minutentakt den Status eines Pins auslesen und nicht flüchtig speichern. Der Status ändert sich über z.B. das Schließen eines Reed Relais. Das Ganze soll ein mobiles kleines Kästchen werden, in der Größe eines Feuerzeugs o.ä. . Die Messwerte würde ich dann gerne per USB auslesen und wieder löschen können. Da die Anzahl der Statusänderungen gering sein wird (ca. 10x / Tag) kann man natürlich über entsprechende speichersparende Lösungen nachdenken. Also z.B. 234 Minuten LOW / 16 Minuten high ergäbe nur zwei Byte. Jede Minute einzeln zu speichern macht bei 525.600 Minuten / Jahr keinen Sinn. 3650 Statuswechsel / Jahr sind da eher realistisch. - Wie geht man so etwas prinzipiell an? - Mit welcher stromsparenden Hardware kann man das umsetzen? - Spannungsversorgung über CR2032 oder gibt's Alternativen? Ich habe bisher nur mit ATMEGAs gearbeitet, und da auch schon umfangreiche Projekte umgesetzt, die waren aber alle nicht stromsensibel. Ich wäre euch sehr dankbar, wenn ihr mir zu meinem Projektchen eine Hardwareempfehlung geben könntet, und vielleicht ein Ansatz wie man das maximale aus der Ladung der geplanten CR2032 Spannungsversorgung heraus bekommt. Vielen Dank vorab, Micha
Lässt sich ein zeitlicher Maximalabstand der Zustandswechsel angeben?
> Mit welcher stromsparenden Hardware kann man das umsetzen?
Hier würde ich mir ggf. mal die msp430 mit fram anschauen (bis 128kb),
vielleicht ist da was dabei.
USB plus 3650 Statuswechsel/Jahr plus CR2032 würde ich einen STM32F103 nehmen oder einen entsprechenden Controller aus der AVR-Serie.
S. Landolt schrieb: > Lässt sich ein zeitlicher Maximalabstand der Zustandswechsel angeben? Leider nein, jeder Zustand kann auch ein paar Wochen dauern. Ach ja, die zeitliche Genauigkeit der Messung ist zweitrangig, d.h. Toleranz bis +/- 1% ist i.O.
Du solltest auch über Fehlerkorrektur nachdenken, wäre ja wirklich ärgerlich wenn nach einem Jahr messen Bitfehler vorliegen.
Michael B. schrieb: > Jede Minute einzeln zu speichern macht bei 525.600 Minuten / Jahr keinen > Sinn. 3650 Statuswechsel / Jahr sind da eher realistisch. Wenn Du die Minuten als 31Bit zählst (+ 1Bit für Pinzustand), sind das nichtmal 16kB, da lohnt noch keine Komprimierung. Du kannst nen ATmega328 nehmen, der mit Uhrenquarz schläft (<1µA) und mit Pin-Change-Interrupt aufwacht. Die Daten schreibst Du in die oberen 16kB Flash oder in einen externen EEPROM (AT24C512).
Peter D. schrieb: > Du kannst nen ATmega328 nehmen, der mit Uhrenquarz schläft (<1µA) und > mit Pin-Change-Interrupt aufwacht. Die Daten schreibst Du in die oberen > 16kB Flash oder in einen externen EEPROM (AT24C512). dazu müsste der schlafende atmega aber beim pinwechsel auch wissen wie viel zeit vergangen ist. kann der dat?
Michael B. schrieb: > Jede Minute einzeln zu speichern macht bei 525.600 Minuten / Jahr keinen > Sinn Das sind Sekunden!! Für die 9000 Minuten pro Jahr braucht man als serielle Bits etwas mehr als 1 kByte, also nur Pipifax. Aus dem gleichen Grund braucht man als Time Stamp nur 15 bit, also für 4000 Wechsel 8 kByte. immer noch kein Problem. Und für den Energieverbrauch spielt das überhaupt keine Rolle, die Speicherung frisst keine Energie, sondern der Betrieb des µC, und da reicht es wenn er einmal pro Minute kurz aufwacht. Man kann sich das Leben natürlich auch künstlich schwermachen, etwa indem man Timestamps verwendet, die vom Urknall bis zum Ende des Universum reichen... Georg
Vernünftig würde mir erscheinen, dass du den Controller beim Pegelwechsel am Pin aufweckst(Interrupt) und die Zeit im Flash oder EEPROM abspeicherst.Das spart am meisten Strom und Speicher, ausserdem entgeht dir kein Pegelwechsel. Grüsse
@ Georg 365 Tage x 24 Stunden/Tag x 60 Minuten/Stunde = 525.600 Minuten
Da gab's doch mal ein Lied: fivehundredtwentyfivethousandsixhundred minutes fivehundredtwentyfivethousand moments oh dear fivehundredtwentyfivethousandsixhundred minutes how do you measure, measure a year?
Bei etwa 10 Wechsel pro Tag wäre ein möglicher Ansatz: erstes Byte: Pinzustand (0 oder 1), Ggf. folgt noch eine Absolutzeit. Ab dem zweiten Byte (unter der Voraussetzung, dass der Speicher zu Beginn 0xff ist): 0..240 = 0..240 Sekunden bis zum Levelwechsel 241: 240 Sekunden + nachfolgendem Byte (bzw. Bytes) Bis zu 4 Stunden passen also in 1 Byte. Insegsamt brauchst Du dann 1 Byte pro Flankenwechsel (also 4kB) + ggf. ein paar Mehr, wenn 4h überschritten werden. Maximal also 6kB pro Jahr. Zur Speicherung reicht statisches RAM, solange die Batterie wirklich fest verbunden ist und nicht einfach so rausfällt.
Michael B. schrieb: > ... Hardwareempfehlung ... Mit sowas hier anfangen: ebay 171280297414 Da mit hast du eine einigermaßen präzise RTC (± Fake). Ob die aber am Ende des Jahres die Uhrzeit noch auf 1% genau hat? Mit drauf ist ein 4kilobyte-EEPROM. Das reicht gemeinerweise nicht für 3650 Timestamps. Runterlöten und z.B. durch Ebay 310624875928 ersetzen. Dieses RTC-Platinchen hat einen Steckverbinder. Dazu zwei Gegenstellen bauen. Eine z.B. aus einem Arduino Nano Clone (ebay 172425955537) mit PC-Verbindung (USB) zum Uhrzeit stellen und EEPROM auslesen. Und eine sparsame (hier gehen die Arduino-Clones nicht, zumindest nicht unverändert) mit schlafendem AVR (+eigener Knopfzelle), der per PIN-Change aufwacht, Zeit aus RTC liest, timestamp mit neuem Status ins EEPROM schreibt, weiterschläft. Wird nicht ganz "Feuerzeug-Format" kriegen, das liegt aber eher an den Batterien. Disclaimer: Ich hab bei den Ebay-Links einfach den Erstbesten im Suchergebnis genommen. Gibt sicher billigere/mit weniger Versandkosten/Schneller hier weil nicht aus China/usw. Selber suchen. Falls am Einsatzort WLAN vorhanden ist: Option2, ESP8266: (Ebay 272359218537) hat genug nichtflüchtigen Speicher, aber keine RTC. Müsste also Aufwachen, WLAN verbinden, Zeitserver fragen, Event wegspeichern (und/oder in die Cloud packen), weiterschlafen. Braucht wg. Wlan eine dickere Batterie.
Vergiss nicht, dass du dazu wohl auch eine Echtzeituhr benötigst.
c. m. schrieb: > dazu müsste der schlafende atmega aber beim pinwechsel auch wissen wie > viel zeit vergangen ist. kann der dat? RTC heißt das Wunderding, dass man ihm bequemerweise zur Seite stellt, damit man die aktuelle Uhrzeit zur Verfügung hat.
c. m. schrieb: > dazu müsste der schlafende atmega aber beim pinwechsel auch wissen wie > viel zeit vergangen ist. kann der dat? Ja, deshalb der Uhrenqurz an T2. T2 läuft weiter, auch wenn die CPU schläft. Bei Compare Match gibt es einen Interrupt, die CPU wacht auf, zählt die Minuten hoch und geht wieder schlafen.
:
Bearbeitet durch User
Hardware: Man nehme einen STM32L0 mit 64k Flash, programmiere ihn umd löte ihn auf eine Knopfzelle. Anschließend wird noch der zu messende Pin verbunden. Software : Starte die integrierte RTC, speichere Zeit als je ein Byte für Minute:Stunde:Tag:Monat, lege den Controller schlafen und aktiviere davor einen wake up interrupt bei pin change. Bei interrupt, lese RTC, speichere 4 Byte in nächste Position im EEprom. Schlafe. Bei Interrupt, lese RTC, speichere 4 Byte in nächste Position im EEprom bis Page Size des Flash Speichers erreicht ist (128 Byte(?)) kopiere EEprom ins Flash. Schlafe. Bei interrupt, lese RTC, speichere 4 Byte in erste Position im EEprom. Schlafe.... Nach einem Jahr, lese am PC den Flash aus und speichere. Werte aus und beachte dass der interne Oszillator nicht kallibriert ist, man aber alles sehr einfach kalibrieren kann, da man ja weiß von wann bis wann der Controller lief.
Ich würde, um Speicher zu sparen, nur die Flankenwechsel + Datum/Uhrzeit speichern. Für die "Richtung" des Pegelwechsels reicht ein Bit. Der Zeitstempel mit Tag, Monat, Jahr, Stunde, Minute braucht (vorausgesetzt, dass immer zur vollen Minute gemessen wird): 5 + 4 + 12 + 6 + 6 Bit also 34 Bit. Wenn du dich beim Jahr darauf festlegst, dass du hinterher einfach noch 2000 addierst, kommst du mit 8 Bit bis ins Jahr 2255, das sollte meiner Meinung nach ausreichen. Es verbleiben also noch 30 Bit, das sind 4 Byte mit 2 ungenutzten Bits (mit denen du z.B. durch Nutzung für die Jahreszahl bis 3023 kommst). Programmiertechnisch ist diese Art der Speicherung und die anschließende Auswertung zwar schwieriger, jedoch mittes shift-Operationen leicht zu bewerkstelligen. In C einfach Variablen vom Typ "unsigned long" verwenden. Wenn du natürlich öfter Pegelwechsel hast, schreibst du dir damit schnell den Speicher zu. Alternativ das Startdatum/Uhrzeit speichern und danach beständig jede Minute in einem Bit den Pegel speichern. Das Startdatum außer acht gelassen, muss also mindestens 32 Minuten zwischen den Pegelwechseln liegen, damit die Abspeicherung von Flankenwechseln mit Zeitstempel Sinn macht.
> Für die "Richtung" des Pegelwechsels reicht ein Bit. > Der Zeitstempel mit Tag, Monat, Jahr, Stunde, Minute braucht > (vorausgesetzt, dass immer zur vollen Minute gemessen wird): > 5 + 4 + 12 + 6 + 6 Bit also 34 Bit. Stattdessen würde ich 16 Bit Werte speichern: Ein Bit für den Pegelwechsel und fünfzehn Bits für die verstrichenen Minuten. An den Anfang der Aufzeichnung kommen Uhrzeit & Datum.
...Oder du speicherst das Startdatum/Uhrzeit und bei jedem Flankenwechsel die Richtung und in 23 Bit den "Minutenoffset" dazu. So kommst du mit drei Byte hin und hast kommst auch ein paar Jahre weit (15, wenn ich mich nicht täusche). Das Startdatum kann dann auch "Ausführlicher" sein, das fällt ja bei vielen Messwerten nicht mehr ins Gewicht. Die Auswertung bzgl. Schaltjahren und die Rückkonvertierung musst du dann eben am PC machen.
Baldrian schrieb: > Stattdessen würde ich 16 Bit Werte speichern Geht auch, aber dann kommt man nur 22 Tage weit. Danach kann man aber auch wiederum einen Zeitstempel speichern. Die Möglichkeiten sind schier ungbegrenzt :>
Hier wird mal wieder, mehr oder weniger Erfolgreich, im Nebel herumgestochert. Die, aus meiner unmaßgeblichen Sicht wichtigsten, Informationen fehlen. Also: Wie oft ist zu erwarten, dass sich was tut und wie genau soll dies protokolliert werden? Vor allem, da das interne EEPROM meist nicht viel Platz bietet. So kann es dann sein, dass noch ein paar Krücken nötig werden. So zum Bleistift: Externe EEPROMs, Batteriegepufferte (?!?) RAM-Bausteine oder die bereits angesprochenen FRAM. Bei großem Datenvolumen könnte sogar eine SSD-Karte sinnvoll werden. Energietechnisch wird wohl eine Kombination aus einem energiesparenden µP und einer externen RTC am sinnvollsten sein. Viele µP können zwar eine eigene RTC betreiben, aber ich kenne keinen, der energiemäßig, an eine externe RTC herankommt. So bleibt nur noch die Reaktion auf einen Flankenwechsel des µP übrig. Nicht vergessen: Jeder µP, der irgendwie Tickt, will programmiert werden. Also auch das Stellen der Uhr oder das Rücksetzen, nach dem Auslesen der Werte.
Amateur schrieb: > Viele µP können zwar eine eigene RTC betreiben, aber ich kenne keinen, > der energiemäßig, an eine externe RTC herankommt. Der ATmega328 kommt auf <1µA bei 3V und 25°C, das sollte für viele Anwendungen ausreichen. Siehe Datenblatt: Figure 33-13. ATmega328: Power-Save Supply Current vs. VCC (Watchdog Timer Disabled and 32kHz Crystal Oscillator Running)
@Peter Ich weis, das ist auch sehr wenig, aber z.B. bei der PCF8563, wirklich eine 08/15 Uhr steht: "Low backup current; typical 0.25 µA at VDD = 3.0 V and Tamb = 25°C" würde mich nicht wundern, wenn sich das nicht sogar unterbieten lässt.
Amateur schrieb: > "Low backup current; typical 0.25 µA at VDD = 3.0 V and Tamb = 25°C" > würde mich nicht wundern, wenn sich das nicht sogar unterbieten lässt. Warum zusätzlichen Aufwand treiben, um besser als ausreichend zu sein?
Amateur schrieb: > Vor allem, da das interne EEPROM meist nicht viel Platz bietet. So kann > es dann sein, dass noch ein paar Krücken nötig werden. So zum Bleistift: > Externe EEPROMs, Batteriegepufferte (?!?) RAM-Bausteine oder die bereits > angesprochenen FRAM. Bei großem Datenvolumen könnte sogar eine SSD-Karte > sinnvoll werden. Weder externes EEPROM oder gar eine SD-Card werden benötigt. Die zu erwartende Datenmenge ist grob bekannt (siehe oben). > Energietechnisch wird wohl eine Kombination aus einem energiesparenden > µP und einer externen RTC am sinnvollsten sein. Nein, ... > Viele µP können zwar eine eigene RTC betreiben, aber ich kenne keinen, > der energiemäßig, an eine externe RTC herankommt. ... da es auf die Gesamtbilanz ankommt.
MSP430FR mit RTC
Wenn es unter 1µA bleiben soll gehts auch mit einem Atmel SAML21. Dazu kann man ein paar nette Features nutzen und bleibt weiterhin unter 1µA. Beim SAML22 gibt sogenannte Damper-Inputs, die hängen am RTC und funktionieren wie externe Interrupts. Ausgelöst wird damit ein RTC-Interrupt. In der Interrupt-Routine wird dann geprüft, welcher Kanal ausgelöst hatte. Das ganze gibts auch mit Entprellung und Zeitstempel der Auslösung. Aktiv ist dabei nur Backup + RTC. Im RTC gibts dann noch ein paar nette 32bit Register die als speichernder RAM während der Schlafzyklen benutzt werden können. Die Werte könnte man dann z.B. täglich ins Flash schreiben. Minimalbeschaltung kann der reine Prozessor mit USB-Anschluss sein. Ein 32kHz Quarz gäbe dir eine recht genaue RTC dazu. Theoretisch kommt man ohne Quarz auf bis zu 0,14µA, nutzt man jedoch ein paar Features sind ca 0,6µA eher realistisch. Mit Quarz sollte man bei ca 1µA rauskommen. Vorteile dieser Lösung wären: - USB-Interface - bis zu 265kB Flash nutzbar als Datenspeicher für die Messwerte - weiter Spannungsbereich: 1,6V - 3,6V - Mehrere Interrupts im RTC mit Zeitstempel nutzbar(SAML22) - Externe Interrupts auch mit RTC nutzbar. Den SAML22 nutze ich zur Zeit mit einem 100 Segment Charakter-LCD-Display bei laufender Anzeige zur Durchflussmessung und Langzeiterfassung von Leitwert und Durchflussmenge bei unter 10µA. Mit 2 Mikrozellen läuft das die nächsten 10-20 Jahre. Da kosten halt ein Operationsverstärker und das LCD noch ein paar µA.
Baldrian schrieb: > Stattdessen würde ich 16 Bit Werte speichern: Ein Bit für den > Pegelwechsel und fünfzehn Bits für die verstrichenen Minuten. An den > Anfang der Aufzeichnung kommen Uhrzeit & Datum. Das ist schon fast optimal. Tatsache ist: du verschwendest mit diesem Ansatz vollkommen sinnlos ein Bit pro Sample. Natürlich würde man zur Anfangszeit auch noch den Anfangszustand in einem einzigen Bit speichern, dann dann steckt die Information über den Pegel für jedes Sample bereits allein in der Tatsache der Speicherung eines Zeitoffsets, denn dieser erfolgt ja lt. Definition nur bei einem WECHSEL des Pegels. Zusätzlich könnte man sicher noch die Speicherung der Zeitoffsets optimieren. Da muss man wohl nicht jedesmal 16 Bit für verschwenden. Allerdings hängt die optimale Strategie natürlich sehr stark davon ab, wie die durchschnittlich 10 Pegelwechsel "im Regelfall" über den Tag verteilt sind. Vermutlich würden aber 7Bit + 1Bit "Escape" schon für einen sehr hohen Prozentsatz der Tage den Speicherbedarf problemlos halbieren. Und für die paar Tage, bei denen das nicht zutrifft, also das Escape-Bit plus ein (oder mehr) zusätzliche Bytes für den Zeitoffset benötigt werden, wäre er immer noch kleiner als bei stumpfer 16-Bit-Speicherung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.