Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Tom Major]

Super Sache dass du das MAX1724 fake Thema im eigenen Thread dokumentiert hast 

- AA/AAA: Wenn der Platz da ist würde ich immer die größte Kapazität nehmen, sehe außer Platz keinen Grund für AAA. Ich habe als Batt.halter die COMF BH-321-1A von TME, die passen straff ohne Nacharbeiten in das Gehäuse.
https://github.com/TomMajor/SmartHome/tree/master/PCB/Sensor_PLHT#bauelemente
Ich muss dazu sagen dass ich mir ein paar AA Batt.halter angeschaut habe und den kürzesten ausgewählt habe 

- RTC/Quarz: Wie du schreibst, für UART oder ähnliches ist es manchmal angenehmer eine genauere Betriebsfrequenz zu haben. Nur um ein paar Sensorwerte zu messen reicht der int. RC-Osc.
Der Quarz nur ist eine Option falls man die Platine für andere Anwendungen benutzen möchte.

Die RTC Option wird im AVR Datenblatt beschrieben, bei mir steht dazu nur kurz hier was:
https://github.com/TomMajor/SmartHome/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-avr-ruhestroms-power-save-mode

Noch besser bezüglich Ruhestrom wird es schließlich wenn man statt dem Watchdog wake-up ein wake-up über die Timer2/RTC Option mit 32,768kHz Uhrenquarz wählt. Dieser Uhrenquarz wird an den XTAL Pins des AVR angeschlossen, als Haupttaktgeber muss man den internen 8MHz RC-Oszillator über die Fuses einstellen.

Einfach einen Uhrenquarz an die XTAL pins. Und der RC-Osc muss über die Fuses aktiviert werden (bzw. ist default aktiv bei einem neuem chip).

[vbs]

Ok danke, hab ich jetzt etwas eingelesen und begreife langsam. Gut geholfen hat das:
https://www.mikrocontroller.net/articles/Sleep_Mode

Hab mal den "NX3215SA" rausgesucht:
https://www.ndk.com/images/products/catalog/c_NX3215SA-STD-MUA-14_e.pdf

Wäre hoffentlich richtig?

[papa]

Ich habe diese hier FC-135

https://www.mouser.com/ds/2/137/1699449-465441.pdf

[Tom Major]

ich nehme zur Zeit diesen
https://de.farnell.com/abracon/ab26t-32-768khz/crystal-32-768khz-12-5pf-cylinder/dp/2467704

[vbs]

So, nun das Staffelfinale

Also ich hab jetzt so einen Uhrenquarz verbaut und erstmal mit dem SleepTestRTC getestet. Da der CC auch drauf sitzt, hab ich die Funktion "cc1101_powerdown" in setup() eingebaut, damit eben der CC dann auch korrekt schlafen gelegt wird. War hoffentlich richtig...

Ich komm nun runter auf 2,0 uA (vorher ohne Quarz 5 uA). Laut Wiki sollte man ja aber auf 0,75 uA runter kommen (https://github.com/TomMajor/SmartHome/tree/master/Info/Ruhestrom). Daher die Frage: Sind meine 2,0 uA erwartungsgemäß oder ist da mal wieder irgendwas faul?
Ist der Grund evtl. dass ich ja einen komplett aufgebauten Sensor teste (jedoch ohne MAX1724) und da eben noch die anderen Bauteile (Sensoren) die Differenz von 1,25 uA ausmachen?

[Tom Major]

Ich komm nun runter auf 2,0 uA (vorher ohne Quarz 5 uA). Laut Wiki sollte man ja aber auf 0,75 uA runter kommen (https://github.com/TomMajor/SmartHome/tree/master/Info/Ruhestrom). Daher die Frage: Sind meine 2,0 uA erwartungsgemäß oder ist da mal wieder irgendwas faul?
Ist der Grund evtl. dass ich ja einen komplett aufgebauten Sensor teste (jedoch ohne MAX1724) und da eben noch die anderen Bauteile (Sensoren) die Differenz von 1,25 uA ausmachen?

Hast du mal in die Datenblätter deiner Sensoren geschaut was deren Ruhestrom ist, erklärt das die Differenz?

[vbs]

Hm gute Frage, also beim BMP280 ist es recht eindeutig. Der startet im Sleep-Mode und braucht dann 0,1 uA. Beim MAX44009 bin ich nicht ganz sicher. Wenn ich es richtig verstehe, dann braucht er 0,65 uA.

Würde heißen: Ich habe momentan 2,0 uA. Wenn ich 0,1 uA und 0,65 uA abziehe, bin ich bei 1,25 uA. Im Wiki ist von 0,75 uA die Rede. Da bin ich also 0,5 uA drüber. Ich meine aber, dass ich auch ohne den Quarz schon immer 0,5 uA drüber war, da ich IIRC 5,5 uA anstatt 5,0 uA (laut Wiki) hatte. Würde also dazu passen.

Diese 0,5 uA fand ich damals nicht relevant, da es bezogen auf die 5 uA nur 10% drüber war. Bezogen auf die 0,75 uA ist es jetzt natürlich fast eine Verdoppelung. Aber ich glaube, dass ich damit jetzt auch einfach leben kann. Vielleicht liegen solche Schwankungen auch einfach in normalen Toleranzen...

[Kai-Alfonso]

Hi,

ich wollte grade die aktuellste FW kompilieren, Arduino schmeißt aber folgende Fehlermeldung raus

Code Auswählen Erweitern


sketch\Sensors/tmBattery.h: In member function 'virtual uint16_t as::tmBatteryResDiv<SENSPIN, ACTIVATIONPIN, FACTOR>::voltage()':

sketch\Sensors/tmBattery.h:177:33: error: 'PIN_A0' was not declared in this scope

         ADMUX |= ((m_SensePin - PIN_A0) & 0x0F);    // select SensePin as input

                                 ^

sketch\Sensors/tmBattery.h: In member function 'virtual uint16_t as::tmBatteryLoad<SENSPIN, ACTIVATIONPIN, FACTOR, LOADTIME>::voltage()':

sketch\Sensors/tmBattery.h:234:33: error: 'PIN_A0' was not declared in this scope

         ADMUX |= ((m_SensePin - PIN_A0) & 0x0F);    // select SensePin as input

Schuld ist die Datei tmBattery.h und der Fehler kommt nur, wenn man mit der Option BAT_SENSOR tmBatteryLoad kompiliert.

Bei mir steht im Sketch

Code Auswählen Erweitern

#define BAT_SENSOR tmBatteryLoad<A0, 7, 4000, 200>

[vbs]

Hast du evtl. falschen Board-Typ gewählt? Sollte Arduino Pro und ATMega328p sein.

[papa]

Code Auswählen Erweitern

[quote author=Kai-Alfonso link=topic=20620.msg938227#msg938227 date=1557400153]
ich wollte grade die aktuellste FW kompilieren, Arduino schmeißt aber folgende Fehlermeldung raus
define BAT_SENSOR tmBatteryLoad<A0, 7, 4000, 200>
[/quote]
Numm mal die "richtige" Pinnummer 14 anstatt dem A0 im Template.

[Kai-Alfonso]

Numm mal die "richtige" Pinnummer 14 anstatt dem A0 im Template.

Der Fehler bleibt der selbe - als Board nutze ich bis jetzt (und das hat immer funktioniert) atmega328p_xplained_mini

Kompiliere ich mit (von vbs) vorgeschlagen als Board Arduino Pro mit 328P kommt folgendes:

Code Auswählen Erweitern

Arduino: 1.8.9 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328P (3.3V, 8 MHz)"

Build-Optionen wurden verändert, alles wird neu kompiliert
D:\Dropbox\Entwicklung\Arduino\libraries\AskSinPP/Channel.h: In member function 'deletepeer.constprop':

D:\Dropbox\Entwicklung\Arduino\libraries\AskSinPP/Channel.h:157:3: internal compiler error: Segmentation fault

   }

   ^

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

lto-wrapper.exe: fatal error: D:\Dropbox\Entwicklung\Arduino\hardware\tools\avr/bin/avr-gcc returned 1 exit status

compilation terminated.

d:/dropbox/entwicklung/arduino/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

exit status 1
Fehler beim Kompilieren für das Board Arduino Pro or Pro Mini.




[vbs]

Hatte auch schon mehrmals Probleme mit diesem arm-Crosscompiler :/ Bei mir hat es dann immer irgendwann geklappt nachdem ich die IDE neu gestartet habe und möglichst viel von dem Projekt gecleant habe.

[papa]

Probier mal ne ältere Arduino IDE Version - z.B. 1.8.1.

[Tom Major]

Kann den Fehler nicht nachstellen, geht einwandfrei bei mir mit dieser Zeile

Code Auswählen Erweitern

#define BAT_SENSOR tmBatteryLoad<A0, 7, 4000, 200>


Code Auswählen Erweitern

Sketch uses 23480 bytes (76%) of program storage space. Maximum is 30720 bytes.
Global variables use 1130 bytes (55%) of dynamic memory, leaving 918 bytes for local variables. Maximum is 2048 bytes.


Arduino 1.8.9
Board: Arduino Pro or Pro Mini

[Tom Major]

Der Fehler bleibt der selbe - als Board nutze ich bis jetzt (und das hat immer funktioniert) atmega328p_xplained_mini

Übrigens sehe ich gerade dass der Fehler beim 2. Post nicht identisch zum ersten ist.

internal compiler error: Segmentation fault

das hatte ich auch schon mal, dieser interne gcc Fehler geistert seit einigen Jahren durch die Foren.
Was bei mir dann hilft:
Settings/compiler warnings: alle 4 Optionen einzeln aktivieren und jeweils zu builden versuchen, mit einer der 4 Optionen geht es dann meistens.