Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[PeMue]

Hallo vbs,

Bin langsam etwas frustriert...  keine Ahnung was es noch sein könnte... zwischendurch hat es oben in der Ecke beim StepUp auch schon mal etwas Rauchentwicklung gegeben, aber jetzt funktioniert er komischerweise wieder. Aber ist sicher erstmal auch nicht ideal.

bekommst Du den MAX1824 zerstörungsfrei runtergelötet? Nicht, dass der eine Macke hat und auch beim "rückwärtsbestromen" Strom zieht. Das wäre ggf. noch eine Möglichkeit.
Aber zuerst würde ich Gernotts Vorschlag umsetzen (Aktivierung Spannungsmess-Pin), ggf. mit IR beobachten (falls machbar).

Ist das ein Nachbau? Ohne Atmel-Logo und co.? Ist das legal?

Ohne Logo vermutlich nicht, aber da gab es eine Änderung in der Beschriftung.

Gruß Peter

[vbs]

Hi Ihr,

danke euch für die Tipps. Also eine Wärmebildkamera habe ich leider nicht, aber das wäre in der Tat ne tolle Sache.

Zu dem Spannungsteiler hab ich etwas gegoogelt... ist offenbar der gängige Weg um eine Spannungsmessung zu bauen. So... also R2 und R3 bilden wohl den Spannungsteiler. Gemessen wird an Pin 24 vom Atmel (Signal A1). Damit man nicht ständig Strom verbraucht, wird dann die Spannungsmessung nur kurzzeitig aktiviert. Hm, passiert wohl über Pin 7 11 (Signal D7). Und da ist die Frage, ob evtl. diese Spannungsmessung fälschlicherweise ständig aktiv ist? Bin ich da auf dem richtigen Weg?

Nur wie prüfe ich das... An dem Mess-Pin 24 darf nur eine Spannung anliegen, wenn gerade gemessen wird, sprich, ich messe da mal die Spannung und wenn ich da dauerhaft eine Spannung sehe, dann ist was faul?

Sorry für die Fragen, bin da nicht so der Fitteste... volles Verständnis falls ihr keine Lust mehr habt. 

Fürs StepUp ablöten und später wieder anlöten (intakt) würde ich mir ein ca. 70%-Chance geben (aufgerundet)... würde ich trotzdem mal probieren wenns sein muss.

[vbs]

Also ich hab mal gemessen:

U-BAT: 2,45 V
A1: 2,34 V
D7: 2,32 V

A1 ist das Signal, welches auch an Pin 24 anliegt und gemessen wird. Die genannten Spannungen messe ich dauerhaft.
Bin mir nicht sicher, was das jetzt aussagt bzw. ob ich jetzt überhaupt was sinnvolles gemacht habe.

[PeMue]

Hallo vbs,

D7: 2,32 V

das passt, denn zur Messung wird D7 auf Masse gelegt, dann müsste an A1 die geteilte Spannung anliegen, sprich:

Code Auswählen Erweitern

A1 =  Ubat*100/570
Insofern alles ok. Ich schau mal, ob wir im Büro eine Wärmebildkamera haben, dauert aber etwas ...

Gruß Peter

[Tom Major]

Wenn die R2/3 Werte so wie im Schaltplan sind, 470k und 100k, kann die Batt.messung nicht für den hohen Strom verantwortlich sein.
Worst case, A1 und D7 sind auf Masse, dann fließen da ca. 6uA bei 3V, also keine Erklärung für die 1600 uA.

Vorausgesetzt Fuses und Firmware passen, aus meiner Sicht wären Step-Up und Sensoren die nächsten Kandidaten.
Step-Up würde ich testweise rauslöten, das sollte bei einem SOT23-5 machbar sei.

Für die Sensoren findet sich vielleicht eine Leiterbahn, die diese mit 3V versorgt, die man testweise durchtrennen könnte um dann den Strom zu checken und danach wieder zusammenlöten.
Habe mir aber das alte Layout nicht angeschaut, vielleicht findet sich eine solche Stelle.

[PeMue]

Hallo,

Ich habe MAX1724 mit 3,0V Ausgangsspannung im Einsatz, deswegen die 3000, aber klar bei 3,3V Ausgangsspannung natürlich dann 3300.

ich habe mir den Quellcode noch einmal angeschaut und versucht zu verstehen  .
Ist das richtig, dass beim BatterySensor zuerst die Versorgungsspannung gegen die interne Referenz gemessen wird und danach die Batteriespannung? Über den Quotient und den Widerstandsteiler wird dann die Batteriespannung errechnet? Das ist dann der Grund, warum man die Ausgangsspannung als Wert übergibt und nicht die Eingansspannung?

Danke + Gruß

Peter

[vbs]

So, hab den StepUp runter bekommen (ging eigentlich ganz gut). Aber: keine Änderung Messe jetzt wieder ~770 uA (wie neulich bei Umgehung des StepUp).

Ist das eigentlich erklärbar, dass der Stromverbrauch ohne StepUp von 1600 uA auf 770 uA sinkt? Ich meine, das sind ja Welten, wenn der erwartete Verbrauch insgesamt bei ca. 20 uA liegt. Dass der StepUp 800 uA saugt, ist doch schon schrecklich, oder?

Jetzt wird die Luft wohl langsam dünn :/ Sensoren oder aber der Atmel an sich? 

[frank]

nach den messungen würde ich tippen, dass die kondensatoren eine macke haben.

c8 ist aus dem spiel, daher die verbesserung auf 770uA.
da c9 der gleiche kondensator ist, vermute ich hier die restlichen 750uA, die noch zuviel sind. vielleicht auch zusammen mit c10.

ich frage mich nur, woran die kaputt gegangen sein könnten.

ich würde als nächstes c9 entfernen und messen.

[vbs]

Hab ich direkt gemacht.... aber... man ahnt es schon... 

Also C9 auslöten bringt keine Änderung (weiterhin 770 uA). C10 hab ich nicht, so wie ich das verstehe (beziehe mich auf "Wetter-Sensor_Atmega328 Out 1.1.brd", wobei auf dem Board in Eagle dann 1.2 steht und meinem Board in echt "1.0" steht).

Ich habe auch C8 wieder aktiviert, um zu prüfen, ob er wirklich verantwortlich für die vorherige Stromabsenkungen war. Aber auch da: den GND-Ping von C8 verbunden aber trotzdem weiterhin 770 uA (hätte man jetzt eine Erhöhung wieder auf 1600 uA erwarten können). Scheint also zumindest mit C8 nichts zu tun haben.

[frank]

schade eigentlich.

Ich habe auch C8 wieder aktiviert, um zu prüfen, ob er wirklich verantwortlich für die vorherige Stromabsenkungen war. Aber auch da: den GND-Ping von C8 verbunden aber trotzdem weiterhin 770 uA (hätte man jetzt eine Erhöhung wieder auf 1600 uA erwarten können). Scheint also zumindest mit C8 nichts zu tun haben.

das verstehe ich noch nicht ganz.

ich schaue in dirks schaltplan pdf, kleine platine ganz am ende, von hier: https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Schematic-RF.pdf?raw=true

ist zwar rev1.1, aber um den stepup sieht es so aus, wie bei deinem photo aus beitrag #2643.

zum testen von c8 hast du also die batterie wieder "normal" eingespeist? und der stepup ist aber noch draussen?

[vbs]

Du hast recht, C10 existiert. Offenbar nicht mehr in 1.2, aber die hab ich ja auch nicht. Also C10 kommt morgen an die Reihe

Ansonsten ist mein Setup so (gewesen):
- StepUp rausgenommen
- C9 rausgenommen

-> Strom 770 uA

In dem Zustand hab ich dann den rechten Pin von C8 nach links mit dem unteren Batterie-Pin (GND) verbunden. Mein Ziel war, dass er damit wieder in Betrieb war und evtl. dann wieder die erhöhte Stromaufnahme hätte erzeugen sollen.

Ich lasse mich da aber gerne korrigieren.

Wünsche erstmal einen guten Rutsch!

[vbs]

Also C10 nun auch raus, aber keine Änderung. Weiterhin 770 uA.

Sieht jetzt recht kahl da oben aus...

[Kai-Alfonso]

Ich würde in solchen Fällen immer erst mal auf die serielle Debugausgabe über FTDI im Arduino Serial Monitor schauen. Kommen die Init Meldungen der AskSinPP? Werden alle Sensoren erkannt und kommen Messwerte?

Hallo Tom,

ich bin jetzt erst dazu gekommen, das mal zu überprüfen. Ich habe den selben Sensor einmal mit der alten 0.15 FW geflashed und einmal mit der neuen 1.2 FW.

Mit der 0.15er Firmware bekomme ich alle Sensordaten - Hardware ist also i.O.

List des Devices mit 0.15 FW

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        E2DF18
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     22
   NAME       HM_E2DF18
   NOTIFYDEV  global
   NR         41
   STATE      T: 24.1 H: 33 L: 0.97 P: 1024.9
   TYPE       CUL_HM
   lastMsg    No:0B - t:70 s:E2DF18 d:F11234 00F1212809000000610DAC
   nanoCUL_MSGCNT 22
   nanoCUL_RAWMSG A140BA270E2DF18F1123400F1212809000000610DAC::-26.5:nanoCUL
   nanoCUL_RSSI -26.5
   nanoCUL_TIME 2019-01-03 09:21:08
   protLastRcv 2019-01-03 09:21:08
   protRcv    22 last_at:2019-01-03 09:21:08
   protSnd    27 last_at:2019-01-03 09:21:08
   protState  CMDs_done
   rssi_at_nanoCUL cnt:22 min:-32.5 max:-26.5 avg:-28.86 lst:-26.5
   READINGS:
     2019-01-03 08:58:37   Activity        alive
     2019-01-03 08:58:11   CommandAccepted yes
     2019-01-03 08:58:37   D-firmware      0.15
     2019-01-03 08:58:37   D-serialNr      CCV7907987
     2019-01-03 08:58:38   PairedTo        0xF11234
     2019-01-03 08:58:34   R-burstRx       off
     2019-01-03 08:58:34   R-pairCentral   0xF11234
     2019-01-03 08:58:38   RegL_00.         00:00 01:00 05:64 0A:F1 0B:12 0C:34 12:10 14:03 24:00 25:00
     2019-01-03 09:21:08   batVoltage      3.50
     2019-01-03 09:21:08   battery         ok
     2019-01-03 09:21:08   humidity        33
     2019-01-03 09:21:08   luminosity      0.97
     2019-01-03 08:58:33   powerOn         2019-01-03 08:58:33
     2019-01-03 09:21:08   pressure        1024.9
     2019-01-03 08:58:37   recentStateType info
     2019-01-03 09:21:08   state           T: 24.1 H: 33 L: 0.97 P: 1024.9
     2019-01-03 09:21:08   temperature     24.1
   helper:
     HM_CMDNR   11
     PONtest    0
     cSnd       01F11234E2DF1800040000000000,01F11234E2DF180103
     mId        F102
     peerIDsRaw ,00000000
     regLst     ,0
     rxType     156
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +E2DF18,00,00,00
       nextSend   1546503668.23117
       prefIO     
       rxt        2
       vccu       
       p:
         E2DF18
         00
         00
         00
     mRssi:
       mNo        0B
       io:
         nanoCUL:
           -18.5
           -18.5
     prt:
       bErr       0
       sProc      0
       sleeping   1
       try        1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rpt:
       IO         nanoCUL
       flg        A
       ts         1546503668.13194
       ack:
         HASH(0x5587674bdd20)
         0B8002F11234E2DF1800
     rssi:
       at_nanoCUL:
         avg        -28.8636363636364
         cnt        22
         lst        -26.5
         max        -26.5
         min        -32.5
     shadowReg:
Attributes:
   IODev      nanoCUL
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   0.15
   model      HB-UW-Sen-THPL-O
   peerIDs    00000000,
   room       CUL_HM
   serialNr   CCV7907987
   subType    THPLSensor

Den selben Sensor habe ich dann mit folgenden defines kompiliert und geflashed

Code Auswählen Erweitern

//#define SENSOR_DS18X20
//#define SENSOR_BME280
#define SENSOR_BMP180
#define SENSOR_TSL2561
//#define SENSOR_MAX44009
#define SENSOR_SHT10
//#define SENSOR_DIGINPUT

Das Gerät lies sich einwandfrei anlernen und die Sensordaten kommen alle auch - nur nicht die des TSL2561

List des Devices mit 1.2 FW

Code Auswählen Erweitern



Internals:
   CFGFN     
   DEF        3CE50C
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     33
   NAME       HM_3CE50C
   NOTIFYDEV  global
   NR         78
   STATE      T: 24.3 P: 1024.8 H: 33 B: 0 I: 0
   TYPE       CUL_HM
   lastMsg    No:05 - t:70 s:3CE50C d:F11234 00F328082100000000000C80
   nanoCUL_MSGCNT 33
   nanoCUL_RAWMSG A150584703CE50CF1123400F328082100000000000C80::-36:nanoCUL
   nanoCUL_RSSI -36
   nanoCUL_TIME 2019-01-03 09:41:01
   protLastRcv 2019-01-03 09:41:01
   protRcv    33 last_at:2019-01-03 09:41:01
   protResnd  4 last_at:2019-01-03 09:27:36
   protSnd    23 last_at:2019-01-03 09:37:39
   protState  CMDs_done
   rssi_at_nanoCUL cnt:33 min:-42 max:-23 avg:-26.63 lst:-36
   rssi_nanoCUL cnt:2 min:-120 max:-119 avg:-119.5 lst:-119
   READINGS:
     2019-01-03 09:32:29   Activity        alive
     2019-01-03 09:26:41   CommandAccepted yes
     2019-01-03 09:32:29   D-firmware      1.2
     2019-01-03 09:32:29   D-serialNr      UXA8507754
     2019-01-03 09:29:45   PairedTo        0xF11234
     2019-01-03 09:26:12   R-pairCentral   0xF11234
     2019-01-03 09:29:44   RegL_00.         00:00 05:40 0A:F1 0B:12 0C:34 12:15 14:06 20:00 21:3C 22:00 23:00
     2019-01-03 09:41:01   batVoltage      3.20
     2019-01-03 09:41:01   battery         ok
     2019-01-03 09:41:01   brightness      0
     2019-01-03 09:41:01   digitalInput    0
     2019-01-03 09:41:01   humidity        33
     2019-01-03 09:26:12   powerOn         2019-01-03 09:26:12
     2019-01-03 09:41:01   pressure        1024.8
     2019-01-03 09:27:32   recentStateType info
     2019-01-03 09:41:01   state           T: 24.3 P: 1024.8 H: 33 B: 0 I: 0
     2019-01-03 09:41:01   temperature     24.3
   helper:
     HM_CMDNR   5
     PONtest    1
     cSnd       01F112343CE50C00040000000000,01F112343CE50C0103
     mId        F103
     peerIDsRaw ,00000000
     regLst     ,0
     rxType     156
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3CE50C,00,00,00
       nextSend   1546504861.54269
       prefIO     
       rxt        2
       vccu       
       p:
         3CE50C
         00
         00
         00
     mRssi:
       mNo        05
       io:
         nanoCUL:
           -28
           -28
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_nanoCUL:
         avg        -26.6363636363636
         cnt        33
         lst        -36
         max        -23
         min        -42
       nanoCUL:
         avg        -119.5
         cnt        2
         lst        -119
         max        -119
         min        -120
     shadowReg:
Attributes:
   IODev      nanoCUL
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   model      HB-UNI-Sensor1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   UXA8507754
   subType    UniSensor1

Ich wollte das dann über die Serielle Konsole debuggen, bekomme aber nur Zeichensalat, egal wie viel Baud ich angebe.

[Tom Major]

Also C10 nun auch raus, aber keine Änderung. Weiterhin 770 uA.

Sieht jetzt recht kahl da oben aus...

Was du noch versuchen könntest bevor du weiter ablötest oder trennst:
Mit einem Multimeter alle Pegel der 32 AVR pins beim 20uA device und beim 1600 uA device vergleichen. Dann bei Auffälligkeiten die pins näher untersuchen die Abweichungen zeigen. Keine Garantie dass es was bringt, könnte aber. Macht nur Sinn wenn du 100% sicher bist die gleiche SW auf beiden Geräten zu haben.

Danach wie gesagt meinen Vorschlag mit dem Abtrennen der Sensoren über Leiterbahn falls möglich.

[Tom Major]

Hallo Tom,

ich bin jetzt erst dazu gekommen, das mal zu überprüfen. Ich habe den selben Sensor einmal mit der alten 0.15 FW geflashed und einmal mit der neuen 1.2 FW.


Ich wollte das dann über die Serielle Konsole debuggen, bekomme aber nur Zeichensalat, egal wie viel Baud ich angebe.

Hast du 57600 Baud versucht? Und hast du RC-Osz. oder Quarz als Haupttaktgeber?
Wenn serieller Debug gehen würde würdest du direkt die Meldung "TSL2561 found" bzw. "Error: TSL2561 not found" sehen.

Außerdem ist bei mir

Code Auswählen Erweitern

#define TSL2561_ADDR TSL2561_ADDR_FLOAT


definiert, auf welchem Pegel liegt der Adress-Eingang des TSL2561 bei dir?