Schutz vor "Babbling Idiot" (BI)

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

stan23
Beiträge: 1101
Registriert: 13.12.2016, 21:14
System: Alternative CCU (RaspberryMatic etc.)
Wohnort: Altmühltal
Hat sich bedankt: 177 Mal
Danksagung erhalten: 109 Mal
Kontaktdaten:

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von stan23 » 21.10.2019, 11:27

Außerdem sollte die Baudrate besser 57600 sein.
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

Beowolf
Beiträge: 556
Registriert: 15.07.2006, 12:50
Wohnort: Greven
Hat sich bedankt: 11 Mal
Danksagung erhalten: 13 Mal

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von Beowolf » 21.10.2019, 11:45

Ich hatte den Programmer erst auf com4. Der ist jetzt auf com3. Hatte den "Ursprungsbefehl" hier einkopiert. Mein Fehler.

Keine Änderung wenn ich die Baudrate auf 57600 stelle.

Beowolf
Beiträge: 556
Registriert: 15.07.2006, 12:50
Wohnort: Greven
Hat sich bedankt: 11 Mal
Danksagung erhalten: 13 Mal

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von Beowolf » 21.10.2019, 13:27

So, ich habe jetzt den Befehl so verändert.
C:\Users\Manfred>C:\Users\Manfred\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14\bin\avrdude -C C:\Users\Manfred\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14\etc\avrdude.conf -v -pm328p -P com3 -c stk500 -b 57600 -Ulfuse:w:0xFF:m -Uhfuse:w:0xD2:m -Uefuse:w:0xFF:m
Also aus "-c stk500v1" habe ich "-c stk500" gemacht. Ich hatte mir mal die avrdude.conf angeschaut. Dort ist ein stk500v1 nicht aufgeführt.

Als Meldung habe ich dieses zurück bekommen.

Code: Alles auswählen

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\Manfred\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14\etc\avrdude.conf"

         Using Port                    : com3
         Using Programmer              : stk500
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel STK500
         Programmer Model: STK500
         Hardware Version: 10
         Firmware Version Master : 2.10
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_getparm(): failed to get parameter 0x9a
         Topcard         : Unknown
         Vtarget         : 3.3 V
         SCK period      : 8.7 us
         Varef           : 3.3 V
         Oscillator      : Off

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as FD
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD2"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD2:
avrdude: load data hfuse data from input file 0xD2:
avrdude: input file 0xD2 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFF:
avrdude: load data efuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D2
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK (E:FF, H:D2, L:FF)

avrdude done.  Thank you.
Das ist doch jetzt so ok, oder?

Grüße
Manfred

TomMajor
Beiträge: 1045
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 58 Mal
Danksagung erhalten: 176 Mal
Kontaktdaten:

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von TomMajor » 18.04.2020, 13:32

---
Update April 2020

Jerome ist es gelungen, einen Babbling Idiot reproduzierbar nachzustellen, das ist großartig und ein guter Erkenntnisgewinn 8)

- er hat dafür einen Pro Mini und seinen Sketch für die 1-Kanal-Fernbedienung HM-RC-P1 hergenommen und konnte mit folgenden Parametern ein "BI-Simulator-Setup" aufbauen:
- die Fuse des internen Brown-Out Detectors (BOD) im AVR auf 1.8V gesetzt
- Versorgung über Labornetzteil, eingestellt auf 2,2V und 15mA (mit der Strombegrenzung des Labornetzteils werden schwache Batterien simuliert)
- beim Senden knickt die Spannung auf 1,45V ein und es entsteht ein Dauersender - reproduzierbar! :D
- Wichtige Erkenntnis: wenn Vcc vom Pro Mini getrennt wird, so dass die Spannung nur noch am Vcc-Pin des CC1101 anliegt sendet der CC1101 weiter!

- Die vor 2 Jahren konzipierten Schaltungsteile B und C zusammen auf meiner BI Info Seite würden genau diesen BI verhindern, über die Abschaltung des CC1101 mittels P-Kanal Mosfet für den Fall dass der AVR im Reset ist.

- Unabhängig davon hilft Schaltung A (Messung des Batteriezustands unter Last, schon länger von mir als Standard bei meinen HM Platinen verwendet) natürlich auch, wenn man gute Infos über den Batteriezustand hat und rechtzeitig tauschen kann.

Alle Details zum April 2020 Update hier:
https://github.com/TomMajor/SmartHome/t ... april-2020

Danke an Jerome für die Ideen und Arbeiten am BI-Simulator-Setup und die zur Verfügung gestellten Bilder. 8)
Dateianhänge
BI_HM-RC-P1.jpg
Schaltung.png
Viele Grüße,
Tom

HMSteve
Beiträge: 88
Registriert: 20.08.2019, 06:23
Danksagung erhalten: 11 Mal

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von HMSteve » 12.05.2020, 07:20

Hervorragend, dass Ihr das reproduzierbar hinbekommen habt, sah ich leider erst gestern.
Mir ist das bislang genau einmal und nicht reproduzierbar, jedoch unter aehnlichen Bedingungen (langsames Verringern der Vin zum Test der Funktion des MCP) gelungen: Reset am AVR war schon low und der CC1101 sendete weiter.
Zu dem Zeitpunkt hatte ich jedoch den Mosfet nach Schaltung C schon wieder entfernt und ueberbrueckt (und inzwischen auch aus meinem Layout geworfen), da mich der Ruhestrom durch den 100k Pullup am Gate gestoert hat. Mit 1MOhm schaltete der (mein Exemplar, hab vergessen, was ich genau nahm) schon nicht mehr richtig ab. Fuer einen alle paar Minuten sendenden Sensor fand ich sinnvoll, den im Setup einzuschalten und eingeschaltet zu lassen, wuerde also an 100k dauerhaft ca 30uA verbraten.
Wie hast Du das umgesetzt, Tom, habe ich die Idee missverstanden?

Viele Gruesse,
Stephan

TomMajor
Beiträge: 1045
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 58 Mal
Danksagung erhalten: 176 Mal
Kontaktdaten:

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von TomMajor » 12.05.2020, 17:29

HMSteve hat geschrieben:
12.05.2020, 07:20
Hervorragend, dass Ihr das reproduzierbar hinbekommen habt, sah ich leider erst gestern.
Mir ist das bislang genau einmal und nicht reproduzierbar, jedoch unter aehnlichen Bedingungen (langsames Verringern der Vin zum Test der Funktion des MCP) gelungen: Reset am AVR war schon low und der CC1101 sendete weiter.
Zu dem Zeitpunkt hatte ich jedoch den Mosfet nach Schaltung C schon wieder entfernt und ueberbrueckt (und inzwischen auch aus meinem Layout geworfen), da mich der Ruhestrom durch den 100k Pullup am Gate gestoert hat. Mit 1MOhm schaltete der (mein Exemplar, hab vergessen, was ich genau nahm) schon nicht mehr richtig ab. Fuer einen alle paar Minuten sendenden Sensor fand ich sinnvoll, den im Setup einzuschalten und eingeschaltet zu lassen, wuerde also an 100k dauerhaft ca 30uA verbraten.
Wie hast Du das umgesetzt, Tom, habe ich die Idee missverstanden?

Viele Gruesse,
Stephan
Die Idee hast du richtig verstanden.
Ich habe Schaltung C damals vor 2 Jahren nur als erweiterte Möglichkeit dokumentiert, als Standard umsetzen auf meinen Boards bisher tue ich nur A und B.

Deswegen u.a. fand ich neulich die Reproduzierbarkeit des BI bei Jerome so gut weil endlich mal ein Beweis für den CC1101 als BI selber auftauchte.

Habe mir gerade noch mal die Originalschaltungen von eq3 beim Wassermelder und 3-Kanal Switch angeschaut, dort wird das Funkmodul mit einem 4,7k Widerstand und pnp Transistor geschaltet, also noch wesentlich höher (Basis-)Strom als du mit der Mosfet Schaltung gemessen hast.
D.h. eq3 schaltet das Funkmodul im sleep ab, dann fließt auch kein Basisstrom.

Geht natürlich nur bei Geräten die nicht durch Burst geweckt werden sollen. Könnte man hier vermutlich auch machen, aber der CC1101 braucht dann wohl ein neues init.
Und eigentlich sollte es auch ganz ohne 100k gehen, der ist nur für definiertes Potential falls der AVR pin auf input steht. (und weil ich per se ein Mosfet Gate ungern floaten lasse :roll: )
Viele Grüße,
Tom

deimos
Beiträge: 3588
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 21 Mal
Danksagung erhalten: 219 Mal
Kontaktdaten:

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von deimos » 12.05.2020, 17:37

Hi,

mit der Reproduzierbarkeit wäre noch eine Sache interessant: Wie lange hält dieser Zustand bei normalen Batterien an. Wenn wir da nur von Minuten reden, dann ist es ja eher unproblematisch (wenn auch nervig), wenn wir über Stunden oder Tage reden, wird es zu einem echten Problem.

Viele Grüße
Alex

TomMajor
Beiträge: 1045
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 58 Mal
Danksagung erhalten: 176 Mal
Kontaktdaten:

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von TomMajor » 12.05.2020, 17:43

Gute Frage.
Laut meiner Sammlung von BI Fällen
https://github.com/TomMajor/SmartHome/t ... on#problem
hat ein BI das ganze HM Netz lahmgelegt.
Auch wenn es nur Minuten sein sollten, die dort teilweise beschrieben Auswirkungen von usern klingen definitiv nicht gut.
Zuletzt geändert von TomMajor am 12.05.2020, 20:53, insgesamt 1-mal geändert.
Viele Grüße,
Tom

jp112sdl
Beiträge: 5537
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 223 Mal
Danksagung erhalten: 462 Mal
Kontaktdaten:

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von jp112sdl » 12.05.2020, 19:02

deimos hat geschrieben:
12.05.2020, 17:37
Hi,

mit der Reproduzierbarkeit wäre noch eine Sache interessant: Wie lange hält dieser Zustand bei normalen Batterien an. Wenn wir da nur von Minuten reden, dann ist es ja eher unproblematisch (wenn auch nervig), wenn wir über Stunden oder Tage reden, wird es zu einem echten Problem.

Viele Grüße
Alex
1 Tag mindestens :roll: :mrgreen:

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Alveran
Beiträge: 220
Registriert: 07.08.2018, 20:17
Hat sich bedankt: 44 Mal
Danksagung erhalten: 20 Mal

Re: Schutz vor "Babbling Idiot" (BI)

Beitrag von Alveran » 12.05.2020, 20:52

Frau hat mehrere Stunden das Garagentor nicht aufbekommen weil ich vergessen hatte die Fuses zu setzten und die Batterie nach ein paar Tagen unter 2.8V gefallen ist. Fragt lieber nicht.

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“