Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Gernott]

Fuse CLKDIV8 ist auch eine Sache die in dem Zusammenhang nicht ganz unwesentlich ist.

Im Rohzustand ist ja das Bit gesetzt, d.h. ein hoher SPI-Takt sollte eigentlich kein Problem sein, oder?


Noch eine andere Frage zum Programmieren: Wenn ich einen Unisensor1-Sketch Arduino-IDE seriell aufgespielt habe und ich danach einen neuen Sketch laden möchte, findet der FTDI keine Synchronisierung. Ich muß dann erst den Bootloader wieder neu flashen, dann geht es wieder zu laden. Ist das normal oder übersehe ich hier etwas?

Gruß
G.

[PeMue]

Hallo Gernott,

Noch eine andere Frage zum Programmieren: Wenn ich einen Unisensor1-Sketch Arduino-IDE seriell aufgespielt habe und ich danach einen neuen Sketch laden möchte, findet der FTDI keine Synchronisierung.

im Prinzip ist der Universalsensor wie ein Arduino pro mini. Dieser muss kurz vor dem Flash Vorgang resettet werden, damit das Flashen funktioniert, sprich es gibt nur ein relativ kleines Zeitfenster zum Flashen nach dem Reset. Ich programmiere aber immer per ISP und danach OTA, von daher kann ich mich auch täuschen ...

Gruß Peter

[Gernott]

Dieser muss kurz vor dem Flash Vorgang resettet werden, damit das Flashen funktioniert...

Hallo Peter,
ja, das kenne ich beim Pro Mini. Allerdings gibt es bei der Eigenbauplatine keinen RESET-Knopf. Ich ging davon aus, das macht das DTR-Signal vom FTDI mit der RESET-Leitung am AVR automatisch. Wenn das Kompilieren fertig ist, blinkert auch kurz die LED ein paar Mal, so daß wohl ein RESET stattfindet und der Bootloader startet. Womöglich stimmt aber das Timing nicht? Ich habe allerdings bei avrdude nichts gefunden, was eine Wartezeit nach dem Reset einstellen kann.

Ist der Unisensor1 auch OTA programmierbar? Bisher hatte ich das nur bei Dirks Firmware so gemacht. - Habe es gerade gefunden. Es braucht einen speziellen OTA-Bootloader.

Gruß
G.

[Tom Major]

Wenn du C1 bestückt hast sorgt DTR für ein Reset am AVR, das geht automatisch, Arduino Standard Verhalten, kein Reset Knopf drücken nötig.

Wenn es nicht geht wurde entweder der bootloader überschrieben (sketch flash size > (32k - bootloader size) ?) oder etwas stimmt mit dem Takt beim AVR nicht.

Ich setzte normalerweise die Fuse BLB1, das schützt den bootloader vor dem (seriellen) Überschreiben.
https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader#standard-bootloader-atmega328p-rc-oszillator-oder-quarz-8mhz
2. Bild

Kannst du im seriellen Monitor die Debugausgaben lesen? Dann stimmt der Takt einigermaßen denke ich.
Ob der bootloader überschrieben wurde könntest du durch ein Verify über ISP checken.

[Gernott]

Wenn es nicht geht wurde entweder der bootloader überschrieben....

Hallo Tom
Du hast Recht, der Bootloader war weg. Ich hatte mir den Flash runtergeladen und Bytefolgen aus dem Bootloader gesucht und nicht gefunden. Die Fusebits waren auch verstellt. Die habe ich neu gesetzt und dann den Bootloader neu geschrieben. Danach waren die Fuses wieder verstellt. Das hatte ich bisher nicht bemerkt. Nachdem ich die Fuses wieder richtig gesetzt hatte, ging dann auch das wiederholte Hochladen des Skteches.
Komischerweise hat das avrdude -verify nicht gemeckert. Komisch ist, daß da nach dem Lesen immer 0.00 s steht. Vergleicht der evtl. nur die Dateigröße:

Code Auswählen Erweitern

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: verifying flash memory against D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude.exe: load data flash data from input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude.exe: input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex auto detected as Intel Hex
avrdude.exe: input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex contains 32652 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 32652 bytes of flash verified

avrdude.exe done.  Thank you.


Vielen Dank für die helfenden Worte und Deine tollen Projekte!
Gruß
G.

[Gernott]

Gleich noch eine Frage hinterher, zum PIR AM312

In der Modifikation von fhemfreund,  ist dort der Spannungsregler ausgelötet oder bleibt der drin?
Mir ist auf https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1
in der Schaltung und den Bildern nicht so klar, ob Transistor direkt an den Sensor kommt oder an die Pins des Moduls.

Gruß
G.

[Tom Major]

Hallo Tom
Du hast Recht, der Bootloader war weg. Ich hatte mir den Flash runtergeladen und Bytefolgen aus dem Bootloader gesucht und nicht gefunden. Die Fusebits waren auch verstellt. Die habe ich neu gesetzt und dann den Bootloader neu geschrieben. Danach waren die Fuses wieder verstellt. Das hatte ich bisher nicht bemerkt. Nachdem ich die Fuses wieder richtig gesetzt hatte, ging dann auch das wiederholte Hochladen des Skteches.
Komischerweise hat das avrdude -verify nicht gemeckert. Komisch ist, daß da nach dem Lesen immer 0.00 s steht. Vergleicht der evtl. nur die Dateigröße:

Code Auswählen Erweitern

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: verifying flash memory against D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude.exe: load data flash data from input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude.exe: input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex auto detected as Intel Hex
avrdude.exe: input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex contains 32652 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 32652 bytes of flash verified

avrdude.exe done.  Thank you.


Vielen Dank für die helfenden Worte und Deine tollen Projekte!
Gruß
G.

Gerne.
Bei deinem verify sieht man das avrdude command nicht, aber 32652 bytes finde ich komisch, der bootloader hat normal 2KB, start adress 0x7800
https://github.com/TomMajor/SmartHome/blob/master/Info/Bootloader/mega328_RC-Osc_or_Quarz/ATmegaBOOT_168_atmega328_pro_8MHz.hex
Verify bedeutet echtes zurücklesen, beim bootlader halt 2048 Bytes.
Eventuell machst du immer ein chip erase?, das löscht auch den bootbereich (allerdings nicht die Fuses).

[Tom Major]

Gleich noch eine Frage hinterher, zum PIR AM312

In der Modifikation von fhemfreund,  ist dort der Spannungsregler ausgelötet oder bleibt der drin?
Mir ist auf https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1
in der Schaltung und den Bildern nicht so klar, ob Transistor direkt an den Sensor kommt oder an die Pins des Moduls.

Gruß
G.

Ich glaube fhemfreund hat den Spannungsregler nicht ausgelötet sondern der Transistor geht direkt an den Ausgang des PIR Moduls.
Oder ihn noch mal direkt fragen.

[fhemfreund]

Gleich noch eine Frage hinterher, zum PIR AM312

In der Modifikation von fhemfreund,  ist dort der Spannungsregler ausgelötet oder bleibt der drin?
Mir ist auf https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1
in der Schaltung und den Bildern nicht so klar, ob Transistor direkt an den Sensor kommt oder an die Pins des Moduls.

Gruß
G.

Ja der Spannungsregler ist ausgelötet, da er im Standby noch ein paar uA braucht. Da meine Sensoren mit 3V arbeiten, ist dieser sowieso überflüssig.
Habe mal 3 Bilder angehängt, die die Transistorbeschaltung direkt am PIR zeigen.

Übrigens: habe meine beiden Testsensoren jetzt ein paar Monate mit einer CR123 im Betrieb. Bis dato ist noch kein nenenswerter Spannungsabfall bei ca. 134.000 Sendeintervallen und ca. 930 PIR Triggerevents festzustellen.

Andreas

[Gernott]

Ja der Spannungsregler ist ausgelötet, da er im Standby noch ein paar uA braucht.

Hallo Andreas
Das hatte ich mir fast gedacht. Danke für die Klarstellung und die Bilder dazu.
Gruß
G.

[Gernott]

Nachdem ich gerade Sensoren am Universalsensor teste, habe ich einen mit BME280 auf einem kleinen breakout board vom überheizten Dachgeschoß in den Keller gebracht. Ist das normal, daß der Sensor mehr als 2 Stunden braucht, um auf einen Temperatursprung von -8 K zu regieren?

[Tom Major]

Nachdem ich gerade Sensoren am Universalsensor teste, habe ich einen mit BME280 auf einem kleinen breakout board vom überheizten Dachgeschoß in den Keller gebracht. Ist das normal, daß der Sensor mehr als 2 Stunden braucht, um auf einen Temperatursprung von -8 K zu regieren?
Screenshot_2019-06-30.png

Das Thema gab es schon ein paar Mal, die Vermutung ist die große thermische Trägheit des Systems BME+Platine+ggf. Gehäuse und weil der BME thermisch so "fest" daran gekoppelt ist.
Könntest mal spaßeshalber einen DS18x20 der in der Luft hängt einbauen/aktivieren und die gleiche Messung mit dem Temperatursprung noch mal machen.
Habe ich irgendwann auch noch vor, meine BME Außentemperatur ist mir auch zu langsam..

[Gernott]

Könntest mal spaßeshalber einen DS18x20 der in der Luft hängt einbauen/aktivieren und die gleiche Messung mit dem Temperatursprung noch mal machen.

Soviel Spaß muß sein, hier das Ergebnis. Der positive Temperatursprung ist mit 600 s aufgelöst, der negative mit 60 s. Interessant ist der Einfluß der Lage. Links war der BME280-breakout horizontal positioniert, recht vertikal über eine Kante stehend. Dort wir der Sensor offenbar besser angeströmt und reagiert dann deutlich schneller. Der SHT hing ohne breakout dünn verdrahtet im Raum und reagiert ziemlich schnell.

[Tom Major]

sehr schöne Messung, Danke.
Bestätigt imho die Theorie der großen thermischen Trägheit des BME gegenüber anderen, freistehenden Sensoren.
Werde auf jeden Fall bei meinen Sensoren die Temperatur von einem zusätzlichen DS nehmen wenn möglich, auch wenn ein BME verbaut ist.

[vbs]

Werde auf jeden Fall bei meinen Sensoren die Temperatur von einem zusätzlichen DS nehmen wenn möglich, auch wenn ein BME verbaut ist.

Warum eigentlich zusätzlich? Kann der DS den BME nicht einfach ersetzen?