Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #308296 > unrolled thread
| Started by | Frank Buss <fb@frank-buss.de> |
|---|---|
| First post | 2021-08-06 16:41 +0200 |
| Last post | 2021-08-07 10:01 +0200 |
| Articles | 20 on this page of 788 — 37 participants |
Back to article view | Back to de.sci.electronics
MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-06 16:41 +0200
Re: MSP430 Reset nicht zuverlässig? Leo Baumann <ib@leobaumann.de> - 2021-08-06 16:45 +0200
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-06 17:10 +0200
Re: MSP430 Reset nicht zuverlässig? Leo Baumann <ib@leobaumann.de> - 2021-08-06 17:15 +0200
Re: MSP430 Reset nicht zuverlässig? Gerhard Hoffmann <dk4xp@arcor.de> - 2021-08-06 18:00 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-07 06:50 -0400
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-07 14:18 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-07 13:40 +0000
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-07 15:46 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-07 19:14 +0000
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-07 21:23 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-07 21:54 +0000
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-08 08:26 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-08 08:46 +0000
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-07 15:58 +0200
Re: MSP430 Reset nicht zuverlässig? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2021-08-07 15:07 +0000
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-06 17:19 +0200
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-06 17:51 +0200
Re: MSP430 Reset nicht zuverlässig? Andreas Neumann <an5275@sedo.com> - 2021-08-07 09:46 +0300
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-06 17:46 +0200
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-06 22:24 +0200
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-06 22:31 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2021-08-07 09:36 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-06 13:59 -0700
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-06 23:32 +0200
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-07 07:31 +0200
Re: MSP430 Reset nicht zuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2021-08-07 19:11 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-12 11:48 -0700
Re: MSP430 Reset nicht zuverlässig? Reinhardt Behm <rbehm@hushmail.com> - 2021-08-13 02:46 +0000
Re: MSP430 Reset nicht zuverlässig? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2021-08-13 07:26 +0000
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-15 19:20 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-14 11:42 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-15 19:24 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-15 15:29 -0400
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-16 20:27 +0000
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-16 23:07 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 10:10 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-17 20:12 -0400
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-18 19:43 +0000
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-18 21:10 -0400
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 11:00 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-19 15:45 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-31 13:53 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-09-01 19:19 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-01 12:34 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-09-01 19:55 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-01 15:31 -0700
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-02 10:59 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-02 10:22 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-09-03 20:14 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-03 15:49 -0700
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-04 11:04 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-09-04 15:56 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-04 13:19 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-09-04 15:58 +0000
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-04 18:28 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-09-01 17:29 -0400
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-09-11 13:28 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-11 17:58 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-12 14:42 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <usenet@nerdcraft.de> - 2021-09-12 14:46 +0200
Re: MSP430 Reset nicht zuverlässig? Heinz Schmitz <HeinzSchmitz@kra.org> - 2021-09-13 13:47 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-14 15:55 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-09-15 08:22 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-15 11:30 -0700
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 04:16 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-17 08:42 -0700
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-15 10:22 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-17 19:07 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-17 11:17 -0700
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-17 20:47 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-17 12:07 -0700
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-17 22:32 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-17 15:31 -0700
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-18 00:53 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-18 11:50 -0700
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-09-18 20:53 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-09-11 13:30 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-11 18:02 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-15 19:17 +0200
Re: MSP430 Reset nicht zuverlässig? Reinhardt Behm <rbehm@hushmail.com> - 2021-08-17 08:24 +0000
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 10:31 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-19 14:22 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-20 08:25 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-20 12:31 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-20 13:58 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-20 21:04 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-21 10:14 +0200
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-21 15:08 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-21 17:51 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-20 06:21 -0400
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-20 18:15 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-20 19:26 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-20 21:11 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-21 10:18 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-21 18:05 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-21 10:53 -0700
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-21 20:49 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-22 04:11 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-22 20:51 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 08:24 +0200
Re: MSP430 Reset nicht zuverlässig? olaf <olaf@criseis.ruhr.de> - 2021-08-17 10:35 +0200
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-17 10:53 +0200
Re: MSP430 Reset nicht zuverlässig? Gerhard Hoffmann <dk4xp@arcor.de> - 2021-08-17 10:54 +0200
Re: MSP430 Reset nicht zuverlässig? olaf <olaf@criseis.ruhr.de> - 2021-08-17 11:34 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-15 19:03 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-15 21:49 +0200
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-16 06:10 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-16 22:06 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-17 20:23 +0000
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-16 11:18 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-16 22:15 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-16 20:09 +0000
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 10:03 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-17 20:25 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-17 20:43 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-16 11:46 -0700
Re: MSP430 Reset nicht zuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2021-08-16 22:13 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 10:06 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 09:45 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-17 11:52 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-17 20:39 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-17 14:09 -0700
Re: MSP430 Reset nicht zuverlässig? Reinhardt Behm <rbehm@hushmail.com> - 2021-08-18 06:23 +0000
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-18 11:46 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-18 18:26 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-19 08:36 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 11:24 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-19 14:23 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-18 18:01 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-18 10:47 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-18 19:41 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-18 13:11 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 09:49 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-19 10:27 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 11:11 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-19 15:39 +0000
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-19 15:43 +0000
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-19 20:40 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-20 08:55 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-20 22:12 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-20 20:47 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-21 21:01 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-21 23:38 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-22 10:18 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-22 20:59 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-23 17:47 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-23 20:37 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-23 23:57 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-24 06:44 +0200
Re: MSP430 Reset nicht zuverlässig? olaf <olaf@criseis.ruhr.de> - 2021-08-24 10:25 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-24 12:46 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-24 13:11 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-24 15:59 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-25 00:28 +0200
Re: MSP430 Reset nicht zuverlässig? olaf <olaf@criseis.ruhr.de> - 2021-08-25 16:19 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-25 22:11 +0200
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-25 22:27 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-25 19:08 +0000
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-29 22:52 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-30 11:13 -0400
Re: MSP430 Reset nicht zuverlässig? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2021-08-24 09:26 +0000
Re: MSP430 Reset nicht zuverlässig? Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2021-08-24 11:52 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-24 12:23 +0200
Re: MSP430 Reset nicht zuverlässig? Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2021-08-24 12:50 +0200
Re: MSP430 Reset nicht zuverlässig? Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2021-08-24 13:03 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-24 15:54 +0000
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-24 18:05 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-24 18:43 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-24 11:27 +0000
Re: MSP430 Reset nicht zuverlässig? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2021-08-24 13:20 +0000
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-24 11:05 +0000
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <usenet@nerdcraft.de> - 2021-09-12 14:12 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-25 19:00 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-19 20:35 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-20 21:03 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-21 21:04 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-22 10:20 +0000
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-18 19:36 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-18 13:26 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 09:57 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-19 10:52 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-19 17:01 +0000
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-19 11:22 -0700
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-20 01:07 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-08-20 07:41 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-20 09:10 +0000
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-20 11:42 +0200
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-20 11:50 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-20 20:36 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-08-20 22:39 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-21 10:56 -0700
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-08-21 21:20 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-21 13:00 -0700
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-08-21 23:47 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-22 00:16 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-23 10:28 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-25 00:25 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-25 14:33 -0700
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-25 23:47 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-26 10:42 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-26 14:23 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-27 13:16 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-27 11:24 -0700
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-29 23:02 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-30 10:09 +0200
Re: MSP430 Reset nicht zuverlässig? Heinz Schmitz <HeinzSchmitz@kra.org> - 2021-08-30 10:30 +0200
Re: MSP430 Reset nicht zuverlässig? Reinhardt Behm <rbehm@hushmail.com> - 2021-08-30 11:12 +0000
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-30 13:16 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-30 15:33 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-22 10:04 +0000
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-22 04:15 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-18 17:47 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-18 11:58 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 09:36 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-19 12:23 -0700
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-20 09:18 +0000
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-20 06:33 -0400
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-20 14:44 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-20 00:45 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-20 06:55 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-20 20:44 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-20 07:50 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-20 21:23 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-21 09:49 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-21 21:36 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-22 00:05 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-22 21:11 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 08:36 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-23 20:45 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-25 00:34 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-25 04:31 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-25 10:20 -0400
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-25 22:25 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-26 04:43 -0400
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-26 10:15 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-25 22:22 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-26 10:37 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-26 20:40 +0200
Re: MSP430 Reset nicht zuverlässig? Enrik Berkhan <Enrik.Berkhan@inka.de> - 2021-08-20 05:52 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-20 21:29 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-20 15:55 +0200
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-20 16:01 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-20 21:47 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-21 00:24 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-21 19:32 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-21 21:40 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-21 23:25 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-22 20:11 +0200
Re: MSP430 Reset nicht zuverlässig? Bernd Laengerich <Bernd.Laengerich@web.de> - 2021-08-19 10:00 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-19 00:35 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-19 16:24 +0000
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-19 21:16 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-20 09:01 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-17 20:50 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-17 13:27 -0700
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-18 21:16 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-07 07:33 -0400
Re: MSP430 Reset nicht zuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2021-08-07 19:21 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-08 07:10 -0400
Re: MSP430 Reset nicht zuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2021-08-08 23:45 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-12 11:58 -0700
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-12 18:54 -0400
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-14 11:51 -0700
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-14 18:43 -0400
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-14 20:39 -0700
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-08-15 10:09 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-15 10:05 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-15 20:40 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-16 11:51 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 09:57 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-17 11:31 -0700
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-18 11:20 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-18 18:18 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-18 17:22 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-18 13:56 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 10:55 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-19 12:47 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-20 08:22 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-21 11:51 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-21 21:38 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-23 10:19 -0700
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-24 09:27 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-08-24 10:35 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-24 09:53 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-08-24 10:28 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-25 23:43 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-25 15:26 -0700
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-26 08:37 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-26 10:15 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-26 12:03 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-26 13:27 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-26 15:39 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-26 18:17 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-26 18:47 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-26 19:20 +0200
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-26 19:23 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-26 19:43 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-26 11:41 -0400
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-26 22:47 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-27 09:53 +0200
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-08-27 15:43 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-30 20:06 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-27 13:13 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-26 11:45 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-30 20:12 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-25 00:21 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-25 08:48 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-25 15:11 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-26 11:29 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-08-26 11:43 +0200
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-27 00:17 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-26 14:54 -0700
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-27 00:15 +0200
Re: MSP430 Reset nicht zuverlässig? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2021-08-27 12:15 +0000
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-27 12:59 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-27 13:22 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-27 08:11 -0400
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-27 11:36 -0700
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-27 18:48 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-08-27 19:34 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-27 11:30 -0700
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-30 20:26 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-31 11:09 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-09-11 13:24 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-09-14 12:24 -0700
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-19 11:19 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 11:57 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-15 06:38 -0400
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-16 11:53 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-15 19:28 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-16 11:55 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-15 19:32 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 22:45 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-18 14:13 -0700
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-15 19:15 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-15 20:14 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-15 23:12 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-16 11:01 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 22:03 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 21:48 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-19 09:12 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-20 22:02 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-21 09:53 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-21 21:45 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-22 00:11 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-22 21:20 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-23 03:12 +0200
Re: MSP430 Reset nicht zuverlässig? Heinz Schmitz <HeinzSchmitz@kra.org> - 2021-08-23 08:03 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 09:24 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 08:48 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-23 22:31 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-25 00:40 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-23 09:16 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-23 23:21 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-24 10:05 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-25 00:29 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-30 21:05 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-30 22:05 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-30 22:16 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-30 22:55 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-30 20:33 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-30 21:04 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-30 21:19 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-30 21:59 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-30 22:11 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-30 23:25 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-31 06:52 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-31 09:12 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-09 22:13 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-10 06:46 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-10 12:35 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-10 16:50 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-10 19:11 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-12 17:03 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-12 17:08 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-09-11 13:10 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-11 18:33 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-09-13 09:15 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-13 09:52 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-13 10:30 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-13 10:39 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-13 11:07 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-13 12:38 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-14 02:57 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-14 06:50 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-14 20:24 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-14 18:48 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-14 18:56 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 08:31 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-15 11:15 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 12:23 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 12:53 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-15 13:22 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 13:51 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-15 14:01 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 14:36 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 02:42 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 06:51 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 12:32 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 13:19 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 12:44 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-15 13:14 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 13:58 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-15 20:48 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-16 00:39 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 03:00 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-16 13:30 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-09-16 11:54 -0400
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-09-16 21:29 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-17 08:31 +0200
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-09-17 15:28 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-09-17 06:13 -0400
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-09-17 15:34 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-17 19:12 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-17 19:25 +0200
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-09-17 20:25 +0200
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-09-17 20:19 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-16 21:38 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-09-17 09:38 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-10-05 22:26 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-10-06 08:25 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-11-04 14:19 +0100
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-11-04 17:32 +0000
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-17 19:10 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-17 20:36 +0200
Re: MSP430 Reset nicht zuverlässig? olaf <olaf@criseis.ruhr.de> - 2021-09-15 13:52 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-15 12:27 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 12:40 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-15 13:21 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 13:33 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-15 13:45 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 13:59 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-16 21:45 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-17 11:56 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-17 13:40 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-17 13:47 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <usenet@nerdcraft.de> - 2021-09-17 14:00 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-17 14:05 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <usenet@nerdcraft.de> - 2021-09-17 14:06 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-17 14:17 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-17 21:10 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-17 23:48 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-09-18 08:03 -0400
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-18 20:29 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-18 22:27 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 00:28 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-19 14:50 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-09-19 15:13 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-19 17:03 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-09-19 17:22 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-19 18:14 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-09-19 18:17 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-19 18:54 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-19 18:45 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-19 19:56 +0200
Re: MSP430 Reset nicht zuverlässig? olaf <olaf@criseis.ruhr.de> - 2021-09-18 09:37 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-18 20:40 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-09-18 12:10 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-18 20:42 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-18 22:38 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-09-19 10:55 +0200
Re: MSP430 Reset nicht zuverlässig? Holger Schieferdecker <spamless@gmx.de> - 2021-09-20 15:20 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-21 20:29 +0200
Re: MSP430 Reset nicht zuverlässig? Holger Schieferdecker <spamless@gmx.de> - 2021-09-22 13:16 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-17 20:17 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-17 20:41 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-18 09:45 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-18 11:46 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 00:28 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-19 04:06 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 10:20 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-19 12:38 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 14:30 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-19 16:48 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 20:46 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-19 20:52 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-19 21:05 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-19 23:12 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-19 23:58 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 21:07 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-09-20 05:55 -0400
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-20 14:56 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-19 14:56 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-19 17:06 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 20:52 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-19 21:57 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 22:12 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-19 23:21 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-20 00:21 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-20 06:21 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-20 10:22 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-20 14:16 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-20 11:59 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-20 14:49 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-20 15:11 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-20 23:24 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-21 02:31 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-21 03:21 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-21 11:22 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-21 16:23 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-21 18:40 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-21 19:35 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-20 15:15 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-20 23:29 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-21 13:50 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-21 16:38 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-21 18:25 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-21 18:44 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-21 19:42 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-21 19:44 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-21 21:17 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-22 09:15 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-22 12:47 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-23 13:45 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-20 17:44 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-20 23:42 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-20 21:10 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-20 23:55 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-21 13:40 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-21 16:44 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-21 18:58 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-21 20:52 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-21 21:10 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-22 07:02 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-22 08:53 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-22 09:30 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-22 12:59 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-22 17:11 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-22 17:57 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-23 08:07 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-23 13:33 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-22 22:50 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-09-18 11:52 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-18 14:27 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-09-18 14:29 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-18 14:49 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-18 21:03 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-18 21:40 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-15 14:16 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 14:38 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 03:30 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 06:55 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-16 20:25 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-16 22:38 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-16 23:12 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-15 15:34 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-15 15:31 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-15 15:52 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-15 16:54 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 17:31 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-16 08:08 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 08:25 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 12:49 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 13:22 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 13:32 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 21:00 +0200
Re: MSP430 Reset nicht zuverlässig? Reinhardt Behm <rbehm@hushmail.com> - 2021-09-17 03:18 +0000
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-09-16 11:47 -0400
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-16 21:51 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 13:10 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-15 13:38 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 13:49 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-15 14:39 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 15:17 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-15 14:07 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 14:24 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-15 15:35 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 17:01 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-16 08:30 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 17:35 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-15 17:46 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-15 17:55 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-16 08:30 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 08:39 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 13:02 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 13:24 +0200
Re: MSP430 Reset nicht zuverlässig? olaf <olaf@criseis.ruhr.de> - 2021-09-15 13:51 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-15 16:59 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 03:40 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-16 09:05 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 09:23 +0200
Re: MSP430 Reset nicht zuverlässig? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-16 21:52 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-15 20:34 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-15 23:33 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-16 20:37 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-17 00:47 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-17 12:10 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-17 16:20 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-17 21:48 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-18 00:14 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-18 10:29 +0200
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-09-19 21:16 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-19 22:55 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-18 21:14 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-18 23:13 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-18 23:37 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-09-18 23:59 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-17 06:49 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 04:01 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 06:58 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-16 12:56 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 13:16 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-09-16 11:50 -0400
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 18:02 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-16 18:41 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-17 11:54 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-09-17 12:23 +0200
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-09-17 12:36 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-17 13:04 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-17 14:00 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-17 19:15 +0200
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-09-17 20:11 +0200
Re: MSP430 Reset nicht zuverlässig? Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2021-09-17 20:42 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-17 19:05 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-09-17 23:51 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-17 13:50 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-16 18:21 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-17 21:52 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-18 10:14 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-18 21:18 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-09-19 10:46 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-18 11:30 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-18 21:23 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-09-19 00:40 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-09-17 06:04 -0400
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-09-16 20:44 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-08-22 10:31 +0200
Re: MSP430 Reset nicht zuverlässig? Heinz Schmitz <HeinzSchmitz@kra.org> - 2021-08-22 12:18 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-22 12:22 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-08-22 12:33 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-22 21:31 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-23 09:28 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 09:55 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-23 10:53 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 14:57 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-23 16:53 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-23 23:57 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-24 16:14 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-25 01:07 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-25 16:49 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-25 22:33 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-30 21:32 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-24 05:56 +0200
Re: MSP430 Reset nicht zuverlässig? Eric Bruecklmeier <nil@nil.nil> - 2021-08-23 09:56 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-23 23:58 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-22 22:32 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 08:58 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-24 05:56 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-30 21:41 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-16 22:31 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 11:03 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-17 12:10 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-17 13:32 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-17 14:33 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-17 19:45 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-17 20:30 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-17 20:43 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-18 09:41 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-18 10:25 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-17 20:24 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-18 16:49 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 22:18 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 22:16 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-17 13:22 -0700
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-15 15:02 -0400
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-16 11:04 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-16 11:34 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-16 08:06 -0400
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 08:55 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-17 13:53 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-18 17:16 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-19 00:20 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-19 10:30 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 11:33 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-19 12:23 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 15:55 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-19 18:06 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-20 09:23 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-20 07:43 -0400
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-20 14:45 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-23 01:05 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 09:13 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-24 01:01 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-25 00:46 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-25 09:03 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-25 10:26 -0400
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-20 07:13 -0400
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-20 14:45 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-21 22:02 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-16 08:03 -0400
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-17 09:27 +0200
Re: MSP430 Reset nicht zuverlässig? Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2021-08-16 17:07 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-16 18:19 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-16 19:25 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-16 19:27 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-16 20:20 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-17 20:52 -0400
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-18 09:49 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-18 10:09 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 19:16 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-17 02:12 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-17 13:00 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-17 14:48 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-18 11:01 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 19:23 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-17 18:36 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-17 20:57 -0400
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-17 20:55 -0400
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-18 10:41 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-17 20:45 -0400
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 19:30 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-18 15:18 -0400
Re: MSP430 Reset nicht zuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2021-08-16 23:33 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-17 20:42 -0400
Re: MSP430 Reset nicht zuverlässig? Guido Grohmann <guido.grohmann@gmx.de> - 2021-08-18 07:12 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-18 06:15 -0400
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-16 18:52 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-16 20:23 +0000
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-17 02:22 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-17 11:06 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-17 13:36 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2020@bartheld.net> - 2021-08-17 13:49 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-17 20:30 +0000
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-18 09:57 +0200
Re: MSP430 Reset nicht zuverlässig? Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2021-08-19 10:16 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-19 16:31 +0000
Re: MSP430 Reset nicht zuverlässig? Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2021-08-21 10:31 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-21 15:15 +0000
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-18 16:45 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-17 07:02 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-17 19:39 +0000
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-17 21:35 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-18 09:58 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-18 21:53 +0200
Re: MSP430 Reset nicht zuverlässig? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-08-20 02:10 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-17 02:25 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-16 23:04 +0200
Re: MSP430 Reset nicht zuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2021-08-16 23:39 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-18 22:53 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 08:34 +0200
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-19 09:33 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-21 22:19 +0200
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-21 22:24 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-22 04:44 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-22 04:40 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-23 00:08 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-23 08:18 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-30 22:39 +0200
Re: MSP430 Reset nicht zuverlässig? Hartmut Kraus <hartmut.melina@web.de> - 2021-08-31 01:03 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-31 05:41 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-04 18:40 +0200
Re: MSP430 Reset nicht zuverlässig? Reinhardt Behm <rbehm@hushmail.com> - 2021-08-22 04:16 +0000
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-22 09:49 +0200
Re: MSP430 Reset nicht zuverlässig? Heinz Schmitz <HeinzSchmitz@kra.org> - 2021-08-22 12:22 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-22 18:31 +0200
Re: MSP430 Reset nicht zuverlässig? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2021-08-19 08:27 +0000
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-19 10:40 +0200
Re: MSP430 Reset nicht zuverlässig? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2021-08-19 08:55 +0000
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 11:05 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-19 08:18 -0400
Re: MSP430 Reset nicht zuverlässig? Sebastin Wolf <invaild@invaild.net> - 2021-08-19 14:45 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-19 15:59 +0200
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-19 12:23 +0200
Re: MSP430 Reset nicht zuverlässig? Hanno Foest <hurga-news2@tigress.com> - 2021-08-19 12:53 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-19 08:09 -0400
Re: MSP430 Reset nicht zuverlässig? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2021-08-19 13:18 +0000
Re: MSP430 Reset nicht zuverlässig? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-08-19 17:26 +0200
Re: MSP430 Reset nicht zuverlässig? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2021-08-19 15:38 +0000
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-19 17:05 +0000
Re: MSP430 Reset nicht zuverlässig? Frank Buss <fb@frank-buss.de> - 2021-08-19 21:00 +0200
Re: MSP430 Reset nicht zuverlässig? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-08-20 09:13 +0000
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-20 22:30 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-21 22:13 +0200
Re: MSP430 Reset nicht zuverlässig? Rupert Haselbeck <mein-rest-muell@gmx.de> - 2021-08-21 23:36 +0200
Re: MSP430 Reset nicht zuverlässig? Marte Schwarz <marte.schwarz@gmx.de> - 2021-08-22 00:34 +0200
Re: MSP430 Reset nicht zuverlässig? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-08-22 04:32 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-09-07 22:49 +0200
Re: MSP430 Reset nicht zuverlässig? Thomas Langhammer <thomas.langhammer@gmx.net> - 2021-08-19 21:00 +0200
Re: MSP430 Reset nicht zuverlässig? "Wolfgang Allinger" <all2001@spambog.com> - 2021-08-20 08:03 -0400
Re: MSP430 Reset nicht zuverlässig? Volker Bartheld <news2021@bartheld.net> - 2021-08-13 08:34 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-14 18:30 +0200
Re: MSP430 Reset nicht zuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2021-08-16 23:14 +0200
Re: MSP430 Reset nicht zuverlässig? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-08-16 23:25 +0200
Re: MSP430 Reset nicht zuverlässig? Joerg <news@analogconsultants.com> - 2021-08-14 11:59 -0700
Re: MSP430 Reset nicht zuverlässig? Axel Berger <Spam@Berger-Odenthal.De> - 2021-08-14 21:15 +0200
Re: MSP430 Reset nicht zuverlässig? Gerald Oppen <Gerald.Oppen@web.de> - 2021-08-16 23:09 +0200
Re: MSP430 Reset nicht zuverlässig? Rafael Deliano <rafael_deliano@arcor.de> - 2021-08-07 10:01 +0200
Page 34 of 40 — ← Prev page 1 … 32 33 [34] 35 36 … 40 Next page →
| From | Rupert Haselbeck <mein-rest-muell@gmx.de> |
|---|---|
| Date | 2021-08-17 20:24 +0200 |
| Message-ID | <igbtuh-o5v.ln1@nntp.haselbeck-net.de> |
| In reply to | #308672 |
Hanno Foest schrieb: > Rupert Haselbeck: > >> Etwa 95% der Verkehrsunfälle werden durch Menschen verursacht, zumeist >> durch zu hohe Geschwindigkeit, zu wenig Abstand, zu starke Ablenkung >> (Handy, Radio, Navi, etc). > > Wenn die Zahl denn stimmt. Die Unfallstatistiken sind frei zugänglich... > Die von mir erwähnten (flüchtigen) Probleme > mit der Lenkunterstützung muß man erst mal erkennen. Natürlich. Es macht aber dennoch einen gewissen Unterschied, ob die Lenkunterstützung in einer engen Kurve bei einer Geschwindigkeit an der Haftungsgrenze der Reifen ausfällt oder aber beim Einparken MfG Rupert
[toc] | [prev] | [next] | [standalone]
| From | Marte Schwarz <marte.schwarz@gmx.de> |
|---|---|
| Date | 2021-08-18 16:49 +0200 |
| Message-ID | <sfj6mb$sq6$1@gwaiyur.mb-net.net> |
| In reply to | #308665 |
Hi Rupert, >> Ja ne... eine ausgefallene Lenkunterstützung, die mit einem Getriebe >> fest aufgelegt ist, läßt sich praktisch nicht mehr lenken. Ein >> Kraftsportler schon, aber nicht DurchschnittsführerscheininhaberIn. > > Der Ausfall der Lenkunterstützung ist - in einer Krisensituation - > freilich höchst gefährlich. Er ist aber auch hinreichend selten. So selten nicht, wenn man in den falschen Fahrzeugen sitzt... Aber darum gings hier ja gar nicht, sondern darum, dass es gelegentlich keine gute Idee ist, als sicheren Zustand Power-Off anzusteuern, zumal an sich nichts kaputt ist, sondern wie hier offensichtlich ein kurzer Spannungseinbruch der Grund war. Die Szene behebt das Problem mit einer neuen Batterie, die Dickste, die mechanisch reinpasst... Marte
[toc] | [prev] | [next] | [standalone]
| From | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2021-08-18 22:18 +0200 |
| Message-ID | <sfjpva$io6$2@dont-email.me> |
| In reply to | #308665 |
Rupert Haselbeck schrieb: > Marte Schwarz schrieb: >> Ja ne... eine ausgefallene Lenkunterstützung, die mit einem Getriebe fest aufgelegt ist, läßt sich praktisch nicht mehr lenken. Ein Kraftsportler schon, aber nicht DurchschnittsführerscheininhaberIn. > > Der Ausfall der Lenkunterstützung ist - in einer Krisensituation - freilich höchst gefährlich. Er ist aber auch hinreichend selten. > Etwa 95% der Verkehrsunfälle werden durch Menschen verursacht, zumeist durch zu hohe Geschwindigkeit, zu wenig Abstand, zu starke Ablenkung (Handy, Radio, Navi, etc). > Bei den technischen Ursachen handelt es sich großteils auch wieder um eigentlich menschliche Ursachen, weil da Wartungsfehler ganz vorne dabei sind als da wären defekte Bremsen mit knapp der Hälfte > (45%) der technisch bedingten Unfallursachen (meist abgenutzte Bremsbeläge, undichte Bremszylinder), defekte, abgefahrene oder falsche Reifen mit etwa 23% (Risse durch Randsteinkontakt etc, falscher > Luftdruck, auch mal zu alte Reifen), Fahrwerksdefekte mit 23%. > Der Rest von etwa 10% verteilt sich im Wesentlichen auf Probleme mit der Lenkung, mit Motor und Getriebe und mit der Ekeltronik. > Vgl. https://www.haufe.de/recht/deutsches-anwalt-office-premium/10-technische-maengel-als-unfallursache-a-statistische-daten_idesk_PI17574_HI7543855.html Vor etwa einem halben Jahrhundert hatte Frankreich seinen Tüv abgeschafft. Meinung war wohl, die regelmässige Durchsicht würde reichen. Wenn man sie denn durchführen würde. Die Unfall- statistiken stiegen auf IIRC 60% an für Unfälle durch technische Probleme. Man hat dann den Tüv wieder eingeführt... -- mfg Rolf Bombach
[toc] | [prev] | [next] | [standalone]
| From | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2021-08-18 22:16 +0200 |
| Message-ID | <sfjpr7$io6$1@dont-email.me> |
| In reply to | #308662 |
Marte Schwarz schrieb: > > Ja ne... eine ausgefallene Lenkunterstützung, die mit einem Getriebe fest aufgelegt ist, läßt sich praktisch nicht mehr lenken. Ein Kraftsportler schon, aber nicht DurchschnittsführerscheininhaberIn. Ich kenne den gegenteiligen Effekt. Ich bin da auch extrem erschrocken. Ich hab eigentlich nur wenige Runden auf der Cart-Bahn gedreht, Gruppenzwang. Auf dem Heimweg mit dem Auto habe ich beim ersten rechts Abbiegen die Panik gekriegt: Hilfe, das Lenkrad hat sich gelöst! Keine Lenkkräfte und kaum Kurvenwirkung... Anderntags hatte ich Muskelkater. Persönlich mag ich keine Autos mit starker Bremsunterstützung. Da habe ich immer das Gefühl, dass ich da nicht gut dosieren kann. Albtraum war eine CX-Citrone mit absurder Servobremse; da reicht die Verzögerungs- kraft im Fuss, um Rückkopplung auszulösen. Beim Insignia muss man angenehm heftig draufdücken. -- mfg Rolf Bombach
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2021-08-17 13:22 -0700 |
| Message-ID | <io2k4mF2bgpU1@mid.individual.net> |
| In reply to | #308645 |
On 8/16/21 1:31 PM, Sieghard Schicktanz wrote: > Hallo Volker Bartheld, > > Du schriebst am Sun, 15 Aug 2021 20:14:22 +0200: > >> Und die redundante Auslegung in der Avionik ist doch eigentlich auch >> nur eine Krücke für kaputte Systeme, oder? > > Nachdem dort i.a. mindestens 3 (drei) Systeme parallel arbeiten, > _sollte_ eine sichere Mehrheitsentscheidung in fast allen Fällen > gegeben sein. Da gibt es weit mehr. Ich darf keine Details aus Kunden-Design erzaehlen, nur bekannte Arbeitsprinzipien. Nimm mal die Beleuchtung fuer die Passagiere als Beispiel. Ja, auch die hat heute uC. Wenn sowas im Rahmen einer nicht ganz knitterfreien Landung mit uC-Versager aufhoert zu arbeiten und die Leute in der nun voellig dunklen Passagierkabine am Boden die Notausgaenge nicht rechtzeitig finden, ist das ganz grosser Driss. Daher haben wir dort ganz andere Zulassungstest. Wenn etwa eine wichtige Anlage bei langsam runter- und wieder raufgedrehter Versorgungsspannung nicht wiederkommt -> Durchgefallen. Alle meine Aerospace Designs mussten da durch. Wer es nicht glaubt, die Details stehen (bei uns) in der Norm RTCA/DO-160. Selbst fuer vermeintlich weniger wichtige Dinge wie Passenger Entertainment Systems gilt das, denn darueber werden u.a. auch Notfallmeldungen ausgegeben. > ... Das betrifft aber halt auch nur Ausfälle der Elektronik, > kaputte Software, 1:1 auf alle System verteilt, erkennt das auch nicht. Es betrifft immer alles. > (Deswegen wird da z.T. schon gefordert, daß die Systeme mit Software zu > arbeiten haben, von verschiedenen Entwicklungs-Teams oder gar mit > unterschiedlichen Entwicklungs-Systemen erstellt wurde. Das erschwert > dann wieder andere Anforderungen, z.B. die Sicherstellung der > Gleichzeitigkeit von Aktionen u.ä., wofür dann wieder hardware-mäßige > Vorkehrungen - "Lockstep"-Synchronisation z.B. - getroffen werden. > Heinz Erhardt[?] hätte gesagt: Eine Komplikation jagt dieselbe...) > Es hilft am Ende auch nicht viel. > BTW, bei Autos müssenschon (maximal) zwei parallele Systeme reichen > (sagt die Auto-Industrie), die können schließlich nicht 'runterfallen. Sie koennen aber, wie in Volkers Beispiel, auf etwas hartes und unangenehmes zu rasen. Bei deutschen Autobahngeschwindigkeiten kann das aehnliche Konsequenzen haben wie ein Flugzeugabsturz. [...] -- Gruesse, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2021-08-15 15:02 -0400 |
| Message-ID | <Fbvn99IzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #308596 |
On 15 Aug 21 at group /de/sci/electronics in article sfbi43$ppe$1@gwaiyur.mb-net.net <marte.schwarz@gmx.de> (Marte Schwarz) wrote: > Hi Wolfgang, >>> Ein WDT ist kein Betriebsmittel, sondern "failsafe of last resort". > Ein WDT ist eine Funktionsgruppe, die man sinnvoll nutzen kann und > ebenso total bescheuert betreiben kann. Das ist wie mit Messern und > Schußwaffen auch. So isset, nur mir fielen keine sinnvollen Anwendung für WDT-Restart ein. Hab da eine völlig andere Phantasie und 45 Jahre Erfahrungen aus dem Hochsicherheitsbereich. Wenns ne Störung gibt, dann auf gar keinen Fall automatisch wieder starten. Never Ever! >> Klar, sie sehen das so. Ist aber Müll, weil das System initialisiert wird >> und wieder von vorne startet, obwohl es krank ist. Kranke Systeme dürfen >> nicht von selbst starten. Never ever. > Das ist oft so, muss aber nicht sein. Es gibt durchaus Systeme, die mit > einem WDT ganz gut klar kommen und es gibt Systeme, die man dann besser > in einen Dauerreset schickt. >> Der WDT Scheiß war zu meiner Zeit bei Ampelanlagen direkt verboten. > Mir ist eine Ampelschaltung, die im Zweifelsfall aus einem Fehlerzustand > neu bootet deutlich lieber, als eine, die im Fehlerzustand verharrt oder > gar weiter erratisches Zeugs macht. Neu bootende Ampel willst Du wirklich nicht, wenn sie dann alle paar Sekunden wieder in den Störungszustand geht. Gibt ne schöne Lichtorgel... Einschaltablauf Nebenrichtung schaltet in Rot ein, Hauptrichtng bleibt duster, bis alle Feindlichkeiten abgelaufen sind und zeigt dann Grün. Soweit so gut. AAAAABER jetzt läuft die wieder auf Störung, wird angeschaltet (zeigt sehr wahrscheinlich dabei Gelb (Blinken) in der NR an. Der Honk, der da vor Rot steht, sieht nur Gelb und fährt los. Er kennt den Unterschied zwischen ROT/GELB und GELB nicht... Tausendmal ist nix passiert, 1000 und 1 Nacht, und es hat BUMMMMS gemacht. FYI Ampelanlagen in D gehen Störungen per Vorschriften in einen sicheren Zustand. Zwangsweise! Rot wird gegen Ausfall auf Strom und gegen Feindlichkeiten überwacht. GRÜN wird gegen ungewolltes Erscheinen auf Spannung überwacht (Fremdspannung) und auf Ablauf aller feindlichen Zustände incl. Räumzeiten. Als sicherer Zustand gibbet mehrere: 1. Notprogramm, ggf. von einer mechanischen Steuerungswalze. Gibt es heutzutage vermutlich nicht mehr. 2. Alles Rot, unseelige Siemens Leidenschaft :p 3. Hauptrichtung aus, Nebenrichtung Gelb blinken. M.E. ist das nicht optimal, da die Hauptrichtung nicht vor Problemen gewarnt wird. 3.1. Sollte dabei noch irgendwo ein Grün eine Spannung führen, dann schaltet die Anlage spannungsfrei und kann nur manuell vor Ort wieder eingeschaltet werden. Dann noch mein abgelehnter Vorschlag aus den 70ern (wg. NIH) Hauptrichtung Gelb Blinken (als Warnung, das was faul ist) Nebenrichtung Rot Blinken (führt bestenfalls sogar zum Anhalten, jedenfalls zur Vorsicht) Wurde abgelehnt, da Rot Blinken nicht in der StVO vorgesehen ist. Scheißbürokraten! >> Im KKW Bereich auch und auch bei Leuts die sich mit Sicherheit wirklich >> auskannten. > Auch da wäre mir so manche Funktion deutlich lieber, wenn sie nach einem > Reset wieder koordiniert startet, als wenn sie im erratischen Zustand > weiter erratische Dinge tut. Abschalten ist angesagt, Hauptschütz raus, zur äussersten Not Crowbar über Einspeisung! Auf keinen Fall neu booten ohne das der Fehler behoben wurde. >> Nur ein 'harmloses' Beispiel. Rollgang im Walzwerk fällt aus, glühende >> Bramme bleibt im Walzgerüst stecken. Walzen werden voll auf gefahren. >> Soweit so gut, aber jetzt schlägt der postulierte WDT des Walzgerüstes zu >> und fährt die Walzen wieder zu. > Das ist dann ein klarer Fall von Programmierfehler. Das ist eindeutig > kein Fehlerfall für einen WDT. Wer das so programmiert, gehört... ACK, aber kommt halt immer wieder vor. Ich hab in meinem Berufsleben locker ein Dutzend solcher Fälle erlebt. >> Und Jahrzehnte später immer noch nix dazugelernt. Die inzwischen ex AEG >> Tochter Telefunken hat Ari- und Mörsergranaten frühzeitig nach Abschuss >> gezündet, weil der WDT zuschlug. > Dann war das eben falsch programmiert, da kann der WDT nichts dafür. > Schuld ist hier der, der nicht damit umgehen konnte. Sowieso. >>> Aehnlich wie der Airbag im Auto. Der kommt erst, nachdem man voll >>> verrissen hat, kann aber dafuer sorgen, dass einen die Enkelchen >>> naechstes Weihnachten noch haben. >> >> Das ist völlig was anderes und hat genau nix mit WDT zu tun. > Warum denn? Der WDT soll ebenso erst dann kommen, wenn alles andere > versagt hatte. Einen WDT einzusetzen um schlampige Programmierung zu > retten, ist Müll, da stimme ich Dir völlig zu. Na wenigstens was :) Aber eben auf keinen Fall einen Restart! Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Marte Schwarz <marte.schwarz@gmx.de> |
|---|---|
| Date | 2021-08-16 11:04 +0200 |
| Message-ID | <sfd9m4$2g2$1@gwaiyur.mb-net.net> |
| In reply to | #308607 |
Hi Wolfgang, > So isset, nur mir fielen keine sinnvollen Anwendung für WDT-Restart ein. > Hab da eine völlig andere Phantasie und 45 Jahre Erfahrungen aus dem > Hochsicherheitsbereich. Wenns ne Störung gibt, dann auf gar keinen Fall > automatisch wieder starten. Never Ever! Deine Erfahrung aus dem Hochsicherheitsbereich in Ehren, aber sie kann nicht wirklich als fundiert betrachtet werden, weil Dir elementares Wissen über Watchdog-Funktionen fehlen Selbstverständlich checkt man beim Boot eines Programmes erst mal, was vor dem Reset war. Alle mir bekannten µCs haben Flags, die Auskunft darüber geben, ob der µC aus einem Watchdog-Event aufgewacht ist. Dass man diese Info beim Hochfahren einholt und entsprechende Routinen einpflegt, um z.B. in den sicheren Zustand mit Fehlermeldung übergeht, ist selbstverständlich. Dass man beim Hochfahren zunächst einmal Sicherheitschecks macht, um nachzusehen, ob alle Funktionsgruppen auch das tn, was sie sollen, sollte in der Branche selbstverständlich sein. Und dennoch: Der Teufel ist ein flinkes Eichhörnchen udn wenn es denn tatsächlich mal passieren sollte, trotz aller Schutz- und Vorsichtsmaßnahmen, dass sich ein Programmablauf in einen nicht vorhergesehenen Zustand begibt, dann ist mir ein koordiniert startender Prozessor viel sympathischer, als ein erratisch weitertaktender µC, der von einem Zufallsstatus in den nächsten rennt. > Neu bootende Ampel willst Du wirklich nicht, wenn sie dann alle paar > Sekunden wieder in den Störungszustand geht. Gibt ne schöne Lichtorgel... s.o. > FYI Ampelanlagen in D gehen Störungen per Vorschriften in einen sicheren > Zustand. Zwangsweise! Und wie soll sie koordiniert dahin kommen, wenn sie sich mal verlaufen hatte? Richtig, via Watchdog-Reset! > Rot wird gegen Ausfall auf Strom und gegen Feindlichkeiten überwacht. > GRÜN wird gegen ungewolltes Erscheinen auf Spannung überwacht > (Fremdspannung) und auf Ablauf aller feindlichen Zustände incl. > Räumzeiten. Von wem? > Auf keinen Fall neu booten ohne das der Fehler behoben wurde. Möglicherweise war der Fehler einmalig und kehrt so schnell nicht wieder. Bei Dir scheint es aber nur den einfachen Hardwarereset zu geben. Wer die Sicherheitseinrichtungen nicht kennt und demnach auch nicht mit ihnen sinnvoll umgehen kann, sollte sich aus dem Bereich Sicherheit eher fernhalten... >> Das ist dann ein klarer Fall von Programmierfehler. Das ist eindeutig >> kein Fehlerfall für einen WDT. Wer das so programmiert, gehört... > > ACK, aber kommt halt immer wieder vor. Ich hab in meinem Berufsleben > locker ein Dutzend solcher Fälle erlebt. Ich finde es erschreckend, mit welchem "Wissen" man Programmierer aufs Volk los läßt... > Aber eben auf keinen Fall einen Restart! Was denn sonst? Nach dem WDT-Reset geht man natürlich nicht einfach zur Tagesordnung über, sondern setzt eine Fehlermeldung ab, untersucht ggfs die Störungsursache und ergreift entsprechende Maßnahmen. Wer schon einmal eine Sicherung wieder eingeschaltet hat (oder eine Schmelzsicherung getauscht hatte, weiß doch: Viele Ereignisse haben sich mit dem Wiederinbetriebnehmen schon erledigt, andere erkennt man beim Wiederinbetriebnehmen. Selten lässt es sich nicht wieder in Betrieb nehmen... Marte
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2021-08-16 11:34 +0200 |
| Message-ID | <inupq3Fa1llU1@mid.individual.net> |
| In reply to | #308612 |
Am 16.08.21 um 11:04 schrieb Marte Schwarz: >> FYI Ampelanlagen in D gehen Störungen per Vorschriften in einen sicheren >> Zustand. Zwangsweise! > > Und wie soll sie koordiniert dahin kommen, wenn sie sich mal verlaufen > hatte? Richtig, via Watchdog-Reset! Weißt du das, oder spekulierst du das? Ich persönlich würde neben der eigentlichen Steuerung ein unabhängiges paralleles System mitlaufen lassen, das unplausible Betriebszustände erkennt und dann z.B. die gesamte Anlage dauerhaft stromlos macht. >> Rot wird gegen Ausfall auf Strom und gegen Feindlichkeiten überwacht. >> GRÜN wird gegen ungewolltes Erscheinen auf Spannung überwacht >> (Fremdspannung) und auf Ablauf aller feindlichen Zustände incl. >> Räumzeiten. > > Von wem? Z.B. Extrahardware, s.o. >> Auf keinen Fall neu booten ohne das der Fehler behoben wurde. > > Möglicherweise war der Fehler einmalig und kehrt so schnell nicht > wieder. Möglicherweise auch nicht. Und möglicherweise passieren ganz seltsame Dinge, die zuvor nie passiert sind, und an die noch keiner vorher gedacht hat. Ein Techniker, der sich das dann angucken muß, hat zumindest die *Chance*, hier einzugreifen. Du kommst mir in deinem Glauben, man könne schon alle Fehler (notfalls nach WDT-Reset) geeignet adressieren, wenn sich der Programmierer nur ordentlich Mühe gibt, nahezu grenzenlos naiv vor. Murphy ist auch dann noch da, wenn man glaubt, an alles gedacht zu haben. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2021-08-16 08:06 -0400 |
| Message-ID | <FbznFuuEQoB@allinger-307049.user.uni-berlin> |
| In reply to | #308614 |
On 16 Aug 21 at group /de/sci/electronics in article inupq3Fa1llU1@mid.individual.net <hurga-news2@tigress.com> (Hanno Foest) wrote: > Am 16.08.21 um 11:04 schrieb Marte Schwarz: >>> FYI Ampelanlagen in D gehen Störungen per Vorschriften in einen sicheren >>> Zustand. Zwangsweise! >> >> Und wie soll sie koordiniert dahin kommen, wenn sie sich mal verlaufen >> hatte? Richtig, via Watchdog-Reset! > Weißt du das, oder spekulierst du das? Ich persönlich würde neben der > eigentlichen Steuerung ein unabhängiges paralleles System mitlaufen > lassen, das unplausible Betriebszustände erkennt und dann z.B. die > gesamte Anlage dauerhaft stromlos macht. Richtig, so geht das. Oder gar Drei Systeme! >>> Rot wird gegen Ausfall auf Strom und gegen Feindlichkeiten überwacht. >>> GRÜN wird gegen ungewolltes Erscheinen auf Spannung überwacht >>> (Fremdspannung) und auf Ablauf aller feindlichen Zustände incl. >>> Räumzeiten. >> >> Von wem? > Z.B. Extrahardware, s.o. >>> Auf keinen Fall neu booten ohne das der Fehler behoben wurde. >> >> Möglicherweise war der Fehler einmalig und kehrt so schnell nicht >> wieder. > Möglicherweise auch nicht. Und möglicherweise passieren ganz seltsame > Dinge, die zuvor nie passiert sind, und an die noch keiner vorher > gedacht hat. Ein Techniker, der sich das dann angucken muß, hat > zumindest die *Chance*, hier einzugreifen. > Du kommst mir in deinem Glauben, man könne schon alle Fehler (notfalls > nach WDT-Reset) geeignet adressieren, wenn sich der Programmierer nur > ordentlich Mühe gibt, nahezu grenzenlos naiv vor. Murphy ist auch dann > noch da, wenn man glaubt, an alles gedacht zu haben. So isset! Elfenbeinturm as its best! Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Marte Schwarz <marte.schwarz@gmx.de> |
|---|---|
| Date | 2021-08-17 08:55 +0200 |
| Message-ID | <sffmhc$ps7$1@gwaiyur.mb-net.net> |
| In reply to | #308614 |
Hi Hanno, >>> FYI Ampelanlagen in D gehen Störungen per Vorschriften in einen sicheren >>> Zustand. Zwangsweise! >> >> Und wie soll sie koordiniert dahin kommen, wenn sie sich mal verlaufen >> hatte? Richtig, via Watchdog-Reset! > > Weißt du das, oder spekulierst du das? Ich persönlich würde neben der > eigentlichen Steuerung ein unabhängiges paralleles System mitlaufen > lassen, das unplausible Betriebszustände erkennt Das (und andere Sicherheitsmaßnahmen) ist selbstverständlich, schließt aber einen Watchdog in der µC-Schaltung nie aus. Wenn die Anlage nach einem WDT-Reset (Verbunden mit Sicherheitschecks und Meldung an den Betreiber) klaglos weiter läuft, warum sollte man die ganze Anlage stromlos schalten und dadurch Risiken in Kauf nehmen, zu deren Vermeidung man die Anlage schließlich installiert hatte? > und dann z.B. die gesamte Anlage dauerhaft stromlos macht. Ob das eine sinnvolle Sicherheitsstrategie ist, darf schon hinterfragt sein. >>> Auf keinen Fall neu booten ohne das der Fehler behoben wurde. >> >> Möglicherweise war der Fehler einmalig und kehrt so schnell nicht wieder. > > Möglicherweise auch nicht. Und möglicherweise passieren ganz seltsame > Dinge, die zuvor nie passiert sind, und an die noch keiner vorher > gedacht hat. Ein Techniker, der sich das dann angucken muß, hat > zumindest die *Chance*, hier einzugreifen. Wenn Du meine Ausführungen gelesen hast, dann weißt Du, dass ich Dir hier nicht widerspreche, aber auch gar keinen Widerspruch sehe. Die Frage ist, was bis dahin passiert. > Du kommst mir in deinem Glauben, man könne schon alle Fehler (notfalls > nach WDT-Reset) geeignet adressieren, wenn sich der Programmierer nur > ordentlich Mühe gibt, nahezu grenzenlos naiv vor. Murphy ist auch dann > noch da, wenn man glaubt, an alles gedacht zu haben. Dann darfst Du kein Medizinprodukt in Betrieb nehmen, mit dem wahlweise lebenserhaltende Maßnahmen durchgeführt werden oder potenziell erheblich gefährliche Aktionen passieren könnten. In der Branche bin ich zu Hause. Ich hab schon Software gesehen, die Checksummen von Speicherbereichen gemacht hatten, bevor die Routinen angesprungen wurden... Eigene Überwachungsschaltungen, die die Hardware kontrollieren und mit eigener Stromversorung und eigener Logik - immer mit anderer Technologie als die Hauptaufgabe - sind dort ebenfalls übliche Maßnahmen. Ein Fehler, der nicht erkannt werden kann, muss in der Risikoanalyse als vorhanden vorausgesetzt werden. Es kommt nicht von ungefähr, dass solche Produkte oft ziemlich teuer sind, nicht nur, weil die Stückzahlen oft klein sind. Dass das im Automobil in sicherheitsrelevanten Bereichen weniger Aufwand sein sollte, müsste mich wundern, bzw wundert mich immer wieder, wenn ich krasse Fehler bemerke. Die ausgefallene elektrische Lenkunterstützung beim Meriva meiner Mutter zum Beispiel. Dass das durchgeht, im Fehlerfall bis zum nächsten Zündungsausschalten einfach alles stillzulegen, ist aus meiner Sicht grob fahrlässig. Gut, der Fehler tritt nur bei langsamer Fahrt vor engen Kurven auf, trotzdem fährt das Fahrzeug nicht mehr dahin, wo es eigentlich hin sollte. Ein gutes Beispiel, in dem ein Abschalten eindeutig nicht ein sicherer Zustand sein muss. Wer meint, dass das Auto nach einem solchen Ereignis nicht mehr fahren darf, muss dann auch den Power-On-Reset blockieren und das Auto komplett stilllegen. So wird neu gestartet und sich gefreut, dass es ja wieder fährt und wieder gut ist, bis zum nächsten Event. Aus meiner Sicht dürfte das Fahrzeug ab sofort nicht schneller als 20 km/h werden. Genug, um eine Gefahrensituation für sich und andere zu entschärfen, zu langsam, um es als Regelbetrieb zu tolerieren. Damit wäre sichergestellt, dass die nächste Werkstatt angefahren wird. Dabei darf selbstverständlich die Lenkunterstützung (auch ohne die Zündung zwischendurch deaktivieren zu müssen) wieder neu starten. Ein qualifizierter Fehlereintrag in OBD-System sollte auch selbstverständlich sein. Auch den gab es nicht in der Deutlichkeit, dass die Mechaniker die Ursache hätten vernünftig eingrenzen können... Du merkst an diesem einfachen Beispiel hoffentlich, dass ich durchaus die Sache etwas differenzierter betrachte, als hier manche wahrhaben wollen. Marte
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2021-08-17 13:53 +0200 |
| Message-ID | <io1m94Fr5brU1@mid.individual.net> |
| In reply to | #308650 |
Am 17.08.21 um 08:55 schrieb Marte Schwarz: >>>> FYI Ampelanlagen in D gehen Störungen per Vorschriften in einen >>>> sicheren >>>> Zustand. Zwangsweise! >>> >>> Und wie soll sie koordiniert dahin kommen, wenn sie sich mal >>> verlaufen hatte? Richtig, via Watchdog-Reset! >> >> Weißt du das, oder spekulierst du das? Ich persönlich würde neben der >> eigentlichen Steuerung ein unabhängiges paralleles System mitlaufen >> lassen, das unplausible Betriebszustände erkennt > > Das (und andere Sicherheitsmaßnahmen) ist selbstverständlich, schließt > aber einen Watchdog in der µC-Schaltung nie aus. Mag sein, aber ich wüßte gerade nicht wozu, wenn da doch eh ein unabhängiges paralleles System ist, das erkennt, daß da gerade was krumm ist. > Wenn die Anlage nach > einem WDT-Reset (Verbunden mit Sicherheitschecks und Meldung an den > Betreiber) klaglos weiter läuft, warum sollte man die ganze Anlage > stromlos schalten und dadurch Risiken in Kauf nehmen, zu deren > Vermeidung man die Anlage schließlich installiert hatte? Wenn. Wenn kein Fehler vorliegt, warum gab es dann den WDT-Reset? Immer alles auf Glitch wg. kosmischer Strahlung zu schieben halte ich für albern. Ob die Sicherheitschecks alles finden ist halt fraglich. - Ich bin nicht in der Verkehrstechnik zuhause, aber mein Dunning-Kruger reicht nicht aus, mich glauben zu machen, daß ich das besser könnte und wüßte als die Leute, die in der Branche gearbeitet haben (Wolfgang) und die Gesamtheit der in Vorschriften gegossenen historischen Erfahrungen. Und wenn man mal ein paar Dokus über Flugzeugabstürze etc. geguckt hat, dann weiß man auch, daß manchmal die allerabsurdesten Dinge schiefgehen, an die kein Arsch vorher gedacht hat. Wenn dein Ego dich glauben macht, es besser zu wissen: ok. Ich wär da eher vorsichtig. >> und dann z.B. die gesamte Anlage dauerhaft stromlos macht. > > Ob das eine sinnvolle Sicherheitsstrategie ist, darf schon hinterfragt > sein. Man kann alles hinterfragen. Der aktuelle Kontext (s.o.) ist aber eine Ampelanlage, und von denen habe ich schon viele in einem stromlosen Zustand gesehen, und bei den allermeisten Kreuzungen sind die Ampeln sogar derart stromlos, daß da gar keine sind - von daher ist das offenbar schon ein anerkannt sicherer Zustand. >>>> Auf keinen Fall neu booten ohne das der Fehler behoben wurde. >>> >>> Möglicherweise war der Fehler einmalig und kehrt so schnell nicht >>> wieder. >> >> Möglicherweise auch nicht. Und möglicherweise passieren ganz seltsame >> Dinge, die zuvor nie passiert sind, und an die noch keiner vorher >> gedacht hat. Ein Techniker, der sich das dann angucken muß, hat >> zumindest die *Chance*, hier einzugreifen. > > Wenn Du meine Ausführungen gelesen hast, dann weißt Du, dass ich Dir > hier nicht widerspreche, aber auch gar keinen Widerspruch sehe. Die > Frage ist, was bis dahin passiert. Vielleicht lese ich was anderes, als du schreibst, oder aber du meinst was anderes, als du schreibst. Dinge wie "Wenn die Anlage nach einem WDT-Reset (Verbunden mit Sicherheitschecks und Meldung an den Betreiber) klaglos weiter läuft, warum sollte man die ganze Anlage stromlos schalten" sehe ich jedenfalls im Widerspruch zu meinem Absatz. >> Du kommst mir in deinem Glauben, man könne schon alle Fehler (notfalls >> nach WDT-Reset) geeignet adressieren, wenn sich der Programmierer nur >> ordentlich Mühe gibt, nahezu grenzenlos naiv vor. Murphy ist auch dann >> noch da, wenn man glaubt, an alles gedacht zu haben. > > Dann darfst Du kein Medizinprodukt in Betrieb nehmen, mit dem wahlweise > lebenserhaltende Maßnahmen durchgeführt werden oder potenziell erheblich > gefährliche Aktionen passieren könnten. In der Branche bin ich zu Hause. OK, ich dilettiere hier, aber argumentieren kann ich trotzdem: Medizintechnik halte ich im Vergleich zu Verkehrstechnik für deutlich unkritischer. Ampeln arbeiten Jahrzehntelang durchgehend, große Passagierjets (mit vielen Leuten an Bord) können 5-10 Jahre reine Flugzeit erreichen. Geht da was schief, sind Leute tot, und möglicherweise gleich sehr viele auf einmal. Mit Medizintechnik, Defi oder so, kommen erst gar nicht so viele Leute in Berührung, und wenn doch *und* es geht was schief, fällt es auf und man kann was dagegen tun, bevor zu viele Leute tot sind. (Ausnahme ist vielleicht sowas wie der Therac-25, wo das Problem möglicherweise nicht sofort auffällt.) > Ich hab schon Software gesehen, die Checksummen von Speicherbereichen > gemacht hatten, bevor die Routinen angesprungen wurden... Eigene > Überwachungsschaltungen, die die Hardware kontrollieren und mit eigener > Stromversorung und eigener Logik - immer mit anderer Technologie als die > Hauptaufgabe - sind dort ebenfalls übliche Maßnahmen. Ein Fehler, der > nicht erkannt werden kann, muss in der Risikoanalyse als vorhanden > vorausgesetzt werden. Es kommt nicht von ungefähr, dass solche Produkte > oft ziemlich teuer sind, nicht nur, weil die Stückzahlen oft klein sind. Und ich frag mich bei sowas, ob es nicht mehr Leben retten könnte, wenn man den Kram nicht einfach nur ohne derlei Checks straightforward solide konstruiert, aber stattdessen nur für 1/10 des Preises. Ärmere Länder würden sich freuen. - Kann man natürlich nicht, weil es hierzulande oder gar in den USA den Hersteller gleich ein paar Fantastillarden kosten würde, wenn auch nur einer durch so ein Gerät zu Tode käme. > Dass das im Automobil in sicherheitsrelevanten Bereichen weniger Aufwand > sein sollte, müsste mich wundern, bzw wundert mich immer wieder, wenn > ich krasse Fehler bemerke. Es könnte sich kaum einer Autos leisten, wenn die nach den gleichen Sicherheitsstandards wie Flugzeuge gebaut und gewartet (!) werden müßten. Wobei das vielleicht gar nicht so schlecht wäre... > Die ausgefallene elektrische > Lenkunterstützung beim Meriva meiner Mutter zum Beispiel. Dass das > durchgeht, im Fehlerfall bis zum nächsten Zündungsausschalten einfach > alles stillzulegen, ist aus meiner Sicht grob fahrlässig. Gut, der > Fehler tritt nur bei langsamer Fahrt vor engen Kurven auf, trotzdem > fährt das Fahrzeug nicht mehr dahin, wo es eigentlich hin sollte. > > Ein gutes Beispiel, in dem ein Abschalten eindeutig nicht ein sicherer > Zustand sein muss. Sicherlich richtig. > Wer meint, dass das Auto nach einem solchen Ereignis > nicht mehr fahren darf, muss dann auch den Power-On-Reset blockieren und > das Auto komplett stilllegen. So wird neu gestartet und sich gefreut, > dass es ja wieder fährt und wieder gut ist, bis zum nächsten Event. Die Story vom Meriva ist noch der harmlose Fall. Mir wurde mal erzählt (hab ich hier auch schon zum Besten gegeben...), daß die Lenkunterstützung eines Benz bei Autobahnfahrt auf Maximum ging. War wohl sehr stressig, die hypernervös reagierende Karre auf dem Standstreifen zum Halten zu bringen, ohne sie irgendwo gegenzufahren. Zündung aus, Zündung wieder an, alles wieder ok... > Aus > meiner Sicht dürfte das Fahrzeug ab sofort nicht schneller als 20 km/h > werden. Genug, um eine Gefahrensituation für sich und andere zu > entschärfen, zu langsam, um es als Regelbetrieb zu tolerieren. Damit > wäre sichergestellt, dass die nächste Werkstatt angefahren wird. Sehe ich ähnlich. > Dabei > darf selbstverständlich die Lenkunterstützung (auch ohne die Zündung > zwischendurch deaktivieren zu müssen) wieder neu starten. Und da wird es dann schwierig. In einem anderen Fall (USA) zog die Karre eine Spur auf dem Highway zur Seite, wenn man einen UKW-Kurzstreckensender mit iPod in den Zigarettenanzünder einsteckte. Gegenhalten kann man bei sowas vergessen. - Möchte man wirklich, auch mit 20km/h, mit einer sich *irgendwie* erratisch verhaltenden Lenkunterstützung, die im Gegensatz zur hydraulischen Servolenkung prinzipiell alles tun kann, was sie gerne möchte, herumfahren? Andererseits, hey. Wir nehmen nun mal die Opfer in Kauf, die daraus resultieren, daß wir bei Autos nicht die gleichen technischen Standards haben wie bei Flugzeugen. Dann kann man bei sowas auch einfach resetten, wie man es ja auch tut. Ob mit oder ohne 20km/h Notlauf und/oder OBD-Fehlerlog ist dann auch nur noch Geschmackssache. Wenns zu viele Tote gibt, wird die Versicherung dem Hersteller das schon geeignet einpreisen. > Ein > qualifizierter Fehlereintrag in OBD-System sollte auch > selbstverständlich sein. Auch den gab es nicht in der Deutlichkeit, dass > die Mechaniker die Ursache hätten vernünftig eingrenzen können... > > Du merkst an diesem einfachen Beispiel hoffentlich, dass ich durchaus > die Sache etwas differenzierter betrachte, als hier manche wahrhaben > wollen. Ich kann mangels Sachkunde die Vorsicht eines Verkehrstechnikers zwar nur unzureichend emulieren, aber soweit ich das zu können glaube, scheinst du mir immer noch zu undifferenziert zu sein. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Marte Schwarz <marte.schwarz@gmx.de> |
|---|---|
| Date | 2021-08-18 17:16 +0200 |
| Message-ID | <sfj894$qq$1@gwaiyur.mb-net.net> |
| In reply to | #308671 |
Hi Hanno, >> Das (und andere Sicherheitsmaßnahmen) ist selbstverständlich, schließt >> aber einen Watchdog in der µC-Schaltung nie aus. > > Mag sein, aber ich wüßte gerade nicht wozu, wenn da doch eh ein > unabhängiges paralleles System ist, das erkennt, daß da gerade was krumm > ist. Und wenn dieses parallele System feststellt, dass eigentlich gar nichtts mehr krumm ist? >> Wenn die Anlage nach einem WDT-Reset (Verbunden mit Sicherheitschecks >> und Meldung an den Betreiber) klaglos weiter läuft, warum sollte man >> die ganze Anlage stromlos schalten und dadurch Risiken in Kauf nehmen, >> zu deren Vermeidung man die Anlage schließlich installiert hatte? > > Wenn. Wenn kein Fehler vorliegt, warum gab es dann den WDT-Reset? Immer > alles auf Glitch wg. kosmischer Strahlung zu schieben halte ich für albern. Ist aber oft so. Wie viele Fehler hab ich schon so gesehen, dass EMV oder externe Spannungseinbrüche einen Event auslösten und danach alles wieder klaglos spielt, bis zum nächsten Event ;-) Noch einmal: Es geht nicht darum einfach so zu tun, als ob nichts wäre. Selbstredend hat sich ein System dann darum zu kümmern, dieses Ereignis auch zu protokollieren und irgendwelche (bekannten) Schäden auszuschließen. Idealerweise gibt es auch Maßnahmen, die zur weiteren Stabilisierung eingesetzt werden können... Aber einfach abschalten ist oft die schlechteste aller Varianten. > Ob die Sicherheitschecks alles finden ist halt fraglich... > daß manchmal die allerabsurdesten Dinge schiefgehen, an die kein > Arsch vorher gedacht hat. Eben. Aber man muss auch daran denken, was passiert, wenn das System weg ist, aber noch tun könnte. >> Ob das eine sinnvolle Sicherheitsstrategie ist, darf schon hinterfragt >> sein. > > Man kann alles hinterfragen. Der aktuelle Kontext (s.o.) ist aber eine > Ampelanlage, und von denen habe ich schon viele in einem stromlosen > Zustand gesehen, und bei den allermeisten Kreuzungen sind die Ampeln > sogar derart stromlos, daß da gar keine sind - von daher ist das > offenbar schon ein anerkannt sicherer Zustand. Dort, wo keine sind, immer ;-) Da, wo man sie hin gemacht hat, geschah dies selten, um das Stadtbild aufzuwerten. >>>>> Auf keinen Fall neu booten ohne das der Fehler behoben wurde. >>>> Möglicherweise war der Fehler einmalig und kehrt so schnell nicht >>>> wieder. >>> Möglicherweise auch nicht. Und möglicherweise passieren ganz seltsame >> Wenn Du meine Ausführungen gelesen hast, dann weißt Du, dass ich Dir >> hier nicht widerspreche, aber auch gar keinen Widerspruch sehe. Die >> Frage ist, was bis dahin passiert. > Vielleicht lese ich was anderes, als du schreibst, oder aber du meinst > was anderes, als du schreibst. Dinge wie "Wenn die Anlage nach einem > WDT-Reset (Verbunden mit Sicherheitschecks und Meldung an den Betreiber) > klaglos weiter läuft, warum sollte man die ganze Anlage stromlos > schalten" sehe ich jedenfalls im Widerspruch zu meinem Absatz. Ich weiß jetzt nicht mehr auswendig, auf welchen Absatz Du Dich beziehst. Zu meinem Satz stehe ich nach wie vor. > OK, ich dilettiere hier, aber argumentieren kann ich trotzdem: > Medizintechnik halte ich im Vergleich zu Verkehrstechnik für deutlich > unkritischer. Wenn Du meinst... > möglicherweise gleich sehr viele auf einmal. Mit Medizintechnik, Defi > oder so, Das kommt sehr speziell drauf an... Nimm die aktuelle Impfaktionen. Wenn am Spritzendesign gerade was schief liefe und in ein paar Monaten die hälfte der Geimpften tod wären, dann sähe das anders aus... Nee, ohne Scheiß. Nimm einen einfachen Magnetresonanztomographen und lass den mal quenchen. Wenn das Helium dann nicht sehr gut koordiniert abgehet, dann gibt es schnell ein paar Dutzend tote... Da passiert zum Glück selten etwas, aber unter anderem auch deshalb, weil man in der Szene in der Regel gut aufpasst. Anscheinend läßt bisher die Kostenstruktur noch mehr Gründlichkeit zu. > Und ich frag mich bei sowas, ob es nicht mehr Leben retten könnte, wenn > man den Kram nicht einfach nur ohne derlei Checks straightforward solide > konstruiert, aber stattdessen nur für 1/10 des Preises. Ärmere Länder > würden sich freuen. Nicht wirklich... Das Beispiel Astrazeneca ist ein gutes hierfür. In Afrika will das keiner mehr haben, weil es in D nicht mehr gut genug ist... >> Aus meiner Sicht dürfte das Fahrzeug ab sofort nicht schneller als 20 >> km/h werden. Genug, um eine Gefahrensituation für sich und andere zu >> entschärfen, zu langsam, um es als Regelbetrieb zu tolerieren. Damit >> wäre sichergestellt, dass die nächste Werkstatt angefahren wird. > > Sehe ich ähnlich. Dann sind wir uns ja einig. >> Dabei darf selbstverständlich die Lenkunterstützung (auch ohne die >> Zündung zwischendurch deaktivieren zu müssen) wieder neu starten. > Und da wird es dann schwierig. In einem anderen Fall (USA) zog die Karre > eine Spur auf dem Highway zur Seite, wenn man einen > UKW-Kurzstreckensender mit iPod in den Zigarettenanzünder einsteckte. > Gegenhalten kann man bei sowas vergessen. - Möchte man wirklich, auch > mit 20km/h, mit einer sich *irgendwie* erratisch verhaltenden > Lenkunterstützung, die im Gegensatz zur hydraulischen Servolenkung > prinzipiell alles tun kann, was sie gerne möchte, herumfahren? Ne, aber der Anhalteweg bei Tempo 20 ist verhältnismäßig klein ;-) Und Fehlerzustände wollten auch in meinem Szenario erkannt sein. Das oben beschriebene Szenario bezog sich auf den häuffigen Fall, dass nach einem Reset alles wieder klaglos spielt, als wäre nie etwas geschehen. > Andererseits, hey. Wir nehmen nun mal die Opfer in Kauf, die daraus > resultieren, daß wir bei Autos nicht die gleichen technischen Standards > haben wie bei Flugzeugen. Dann kann man bei sowas auch einfach resetten, > wie man es ja auch tut. Ne, tut es eben nicht. Es bleibt blockiert, bin man einen neuen POR auslöst. Der BOR darf das scheinbar nicht wieder in Funktion resetten, zumindest dachten das wohl die Programmierer... oder sie dachten eher gar nicht daran, dass ein Brown-Out überhaupt abzufangen wäre... > Ich kann mangels Sachkunde die Vorsicht eines Verkehrstechnikers zwar > nur unzureichend emulieren, aber soweit ich das zu können glaube, > scheinst du mir immer noch zu undifferenziert zu sein. Könnte schon sein ;-) Marte
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2021-08-19 00:20 +0200 |
| Message-ID | <io6gf6Fp0erU1@mid.individual.net> |
| In reply to | #308719 |
On 8/18/21 5:16 PM, Marte Schwarz wrote: > Es geht nicht darum einfach so zu tun, als ob nichts wäre. Selbstredend > hat sich ein System dann darum zu kümmern, dieses Ereignis auch zu > protokollieren und irgendwelche (bekannten) Schäden auszuschließen. > Idealerweise gibt es auch Maßnahmen, die zur weiteren Stabilisierung > eingesetzt werden können... Aber einfach abschalten ist oft die > schlechteste aller Varianten. Da lobe ich mir den Java SEH Ansatz: der Compiler merkt, welche Exceptions ein Unterprogramm werfen kann, und wo im Callstack welche Exception gehandelt wird, und wo eine ungehandelt das Programm abstürzen läßt. Nimmt man WDT als Exception hinzu, sollte eigentlich klar werden, wann/wo welche Reaktion darauf sinnvoll ist. Diese Analysetechnik halte ich für sehr hilfreich, unabhängig davon, ob auf dem Zielsystem SEH tatsächlich zum Einsatz kommt. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2021-08-19 10:30 +0200 |
| Message-ID | <io6j4lFpgqdU1@mid.individual.net> |
| In reply to | #308719 |
Am 18.08.21 um 17:16 schrieb Marte Schwarz: >> Mag sein, aber ich wüßte gerade nicht wozu, wenn da doch eh ein >> unabhängiges paralleles System ist, das erkennt, daß da gerade was >> krumm ist. > > Und wenn dieses parallele System feststellt, dass eigentlich gar nichtts > mehr krumm ist? Wenn nichts krumm ist, löst es nicht aus. Wenn es auslöst, ist oder war da was krumm. Wenn nicht eindeutig erkennbar ist, *was* da krumm war (und das etwas zulässiges war), gibts Notbetrieb oder Abschaltung. Ansonsten fängst du dir dabei langfristig alle Fehler ein, an die der Programmierer nicht gedacht hat. Und die gibt es immer - zumindest kannst du deren Abwesenheit nicht beweisen. Letztendlich ist das ein erkenntnistheoretisches Problem: Falsifikation ist einfach, Verifikation ist schwer bis unmöglich. >>> Wenn die Anlage nach einem WDT-Reset (Verbunden mit Sicherheitschecks >>> und Meldung an den Betreiber) klaglos weiter läuft, warum sollte man >>> die ganze Anlage stromlos schalten und dadurch Risiken in Kauf >>> nehmen, zu deren Vermeidung man die Anlage schließlich installiert >>> hatte? >> >> Wenn. Wenn kein Fehler vorliegt, warum gab es dann den WDT-Reset? >> Immer alles auf Glitch wg. kosmischer Strahlung zu schieben halte ich >> für albern. > > Ist aber oft so. Ja sicher, zu analogen Zeiten war alles, was man zu faul zum Debuggen war, ein "Haarriß in der Leiterplatte", zu digitalen Zeiten ist es ein "Glitch durch kosmische Strahlung". > Wie viele Fehler hab ich schon so gesehen, dass EMV > oder externe Spannungseinbrüche einen Event auslösten und danach alles > wieder klaglos spielt, bis zum nächsten Event ;-) Das kann schon sein, aber dann ist mangelnde EMV oder mangelnde Stabilität der Stromversorgung das Problem, das es zu adressieren gilt. Wobei letzteres ja durchaus in den Bereich "zulässiger Fehler" fallen kann (was kann die Ampelanlage dafür, wenn das E-Werk spinnt?), aber dann muß man das auch per brownout detector oder BOR erkannt und protokolliert haben. [stromlos machen] >>> Ob das eine sinnvolle Sicherheitsstrategie ist, darf schon >>> hinterfragt sein. >> >> Man kann alles hinterfragen. Der aktuelle Kontext (s.o.) ist aber eine >> Ampelanlage, und von denen habe ich schon viele in einem stromlosen >> Zustand gesehen, und bei den allermeisten Kreuzungen sind die Ampeln >> sogar derart stromlos, daß da gar keine sind - von daher ist das >> offenbar schon ein anerkannt sicherer Zustand. > > Dort, wo keine sind, immer ;-) Da, wo man sie hin gemacht hat, geschah > dies selten, um das Stadtbild aufzuwerten. Normalerweise stellt man die irgendwohin, um den Verkehrsfluß zu verbessern. Wobei ich es auch schon gesehen hab, daß der Verkehr bei ausgefallener Ampel besser floß. Klar, man kann auch mit Ampeln Unfallschwerpunkte entschärfen. Ob eine aus unbekannten Gründen neu startende Ampelanlage an dieser Stelle besser ist, als der vorherige Zustand, ist aber geraten. Daher lebt man lieber mit den bekannten Gefahren des vorigen Zustands (ohne Ampel). [...] Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Marte Schwarz <marte.schwarz@gmx.de> |
|---|---|
| Date | 2021-08-19 11:33 +0200 |
| Message-ID | <sfl8h2$5ht$1@gwaiyur.mb-net.net> |
| In reply to | #308771 |
Hi Hanno, > Wenn nichts krumm ist, löst es nicht aus. Wenn es auslöst, ist oder war > da was krumm. In der Welt in der Du lebst, scheint alles recht übersichtlich zu sein. Das ist in der Welt in der ich lebe nicht so. > Wenn nicht eindeutig erkennbar ist, *was* da krumm war > (und das etwas zulässiges war), gibts Notbetrieb oder Abschaltung. > Ansonsten fängst du dir dabei langfristig alle Fehler ein, an die der > Programmierer nicht gedacht hat. Und die gibt es immer - zumindest > kannst du deren Abwesenheit nicht beweisen. Ich wüsste nicht, warum man unbedingt mit Notbetrieb und Abschaltung reagieren müsste. Man sollte den Event protokollieren, sicher und bestimmt. Aber warum sollte man ein funktionsfähiges System dann zwingend außer Betrieb setzen? Das kann sinnvoll sein, aber sicher nicht immer. >> Wie viele Fehler hab ich schon so gesehen, dass EMV oder externe >> Spannungseinbrüche einen Event auslösten und danach alles wieder >> klaglos spielt, bis zum nächsten Event ;-) > > Das kann schon sein, aber dann ist mangelnde EMV oder mangelnde > Stabilität der Stromversorgung das Problem, das es zu adressieren gilt. Bin ich ganz bei Dir. > Wobei letzteres ja durchaus in den Bereich "zulässiger Fehler" fallen > kann (was kann die Ampelanlage dafür, wenn das E-Werk spinnt?), aber > dann muß man das auch per brownout detector oder BOR erkannt und > protokolliert haben. Würde ich dir niemals widersprechen. >> Dort, wo keine sind, immer ;-) Da, wo man sie hin gemacht hat, geschah >> dies selten, um das Stadtbild aufzuwerten. > > Normalerweise stellt man die irgendwohin, um den Verkehrsfluß zu > verbessern. Wobei ich es auch schon gesehen hab, daß der Verkehr bei > ausgefallener Ampel besser floß. ;-) Es gibt nichts, was man nicht richtig versemmeln könnte. > Klar, man kann auch mit Ampeln Unfallschwerpunkte entschärfen. Ob eine > aus unbekannten Gründen neu startende Ampelanlage an dieser Stelle > besser ist, als der vorherige Zustand, ist aber geraten. Ob es durch ausschalten besser wird auch. IMHO meist nicht. Marte
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2021-08-19 12:23 +0200 |
| Message-ID | <io6popFqp0sU1@mid.individual.net> |
| In reply to | #308782 |
Am 19.08.21 um 11:33 schrieb Marte Schwarz: >> Wenn nichts krumm ist, löst es nicht aus. Wenn es auslöst, ist oder >> war da was krumm. > > In der Welt in der Du lebst, scheint alles recht übersichtlich zu sein. > Das ist in der Welt in der ich lebe nicht so. Ich hab eher den gegenteiligen Eindruck: Du glaubt, IMO eher naiv, verifizieren zu können, ob ein System funktionsfähig ist. Kann man aber nicht - einfaches Beispiel: Wackelkontakt, der beim Check nicht auftritt. Jetzt wird man in der Realität mit dem Restrisiko leben müssen, aber spätestens, nachdem nicht vorhersehbarer Fehlerzustand aufgetreten ist, *weiß* man, daß das System irgendwie fehlerhaft ist. >> Wenn nicht eindeutig erkennbar ist, *was* da krumm war (und das etwas >> zulässiges war), gibts Notbetrieb oder Abschaltung. Ansonsten fängst >> du dir dabei langfristig alle Fehler ein, an die der Programmierer >> nicht gedacht hat. Und die gibt es immer - zumindest kannst du deren >> Abwesenheit nicht beweisen. > > Ich wüsste nicht, warum man unbedingt mit Notbetrieb und Abschaltung > reagieren müsste. Man sollte den Event protokollieren, sicher und > bestimmt. Aber warum sollte man ein funktionsfähiges System dann > zwingend außer Betrieb setzen? Es ist ja eben nicht funktionsfähig, sonst hätte es ja keinen Fehler gegeben. - OK, vielleicht haben wir ja unterschiedliche Definitionen von funktionsfähig? Wenn du meinst, daß ein "funktionsfähiges" System *meistens* sich so verhält wie designt, dann magst du recht haben. Halte ich aber für hinterfragbar, wenn es um Menschenleben geht. > Das kann sinnvoll sein, aber sicher nicht > immer. Es kann natürlich sinnvoll sein, ein fehlerhaftes System ggf. nach Reset weiterlaufen zu lassen, weil die Alternative noch problematischer wäre. Lenkunterstützung hatten wir schon, noch spektakulärer bei einer startenden Rakete: Abschalten ist da keine Option, also wird man nach WDT/POR/BOR (der hoffentlich schnell genug ist) versuchen, genauso weiterzumachen wie vorher, weil das *möglicherweise* hilft, alles andere andere aber sicher ein Totalverlust wäre. Das ändert aber gar nichts daran, daß ein derart spinnendes System fehlerhaft ist und der Fehler konstruktiv behoben gehört! [...] So weit sind wir ja offenbar nicht auseinander - ich vermute, unsere Differenzen liegen irgendwo in der definitionstechnischen Grauzone zwischen "funktionsfähig" und "fehlerfrei". >> Klar, man kann auch mit Ampeln Unfallschwerpunkte entschärfen. Ob eine >> aus unbekannten Gründen neu startende Ampelanlage an dieser Stelle >> besser ist, als der vorherige Zustand, ist aber geraten. > > Ob es durch ausschalten besser wird auch. IMHO meist nicht. In dem Fall, wo es schiefgeht, und du die Anlage trotz voriger Probleme weiterlaufen läßt und es dadurch Unfälle gibt, hast du jedenfalls *richtig* Ärger. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Marte Schwarz <marte.schwarz@gmx.de> |
|---|---|
| Date | 2021-08-19 15:55 +0200 |
| Message-ID | <sflnrv$6im$1@gwaiyur.mb-net.net> |
| In reply to | #308786 |
Hi Hanno, > Ich hab eher den gegenteiligen Eindruck: Du glaubt, IMO eher naiv, > verifizieren zu können, ob ein System funktionsfähig ist. Kann man aber > nicht - einfaches Beispiel: Wackelkontakt, der beim Check nicht > auftritt. Jetzt wird man in der Realität mit dem Restrisiko leben > müssen, aber spätestens, nachdem nicht vorhersehbarer Fehlerzustand > aufgetreten ist, *weiß* man, daß das System irgendwie fehlerhaft ist. Solange man sein System so konstruiert hatte, dass man diesen Fehler sicher beherrschen kann, bleibt das Risiko begrenzt. Unter dieser Maxime ist generell zu entwickeln. Ein Fehler, den man nicht sicher erkennen und beherrschen kann, muss man in der Sicherheitsbetrachtung als gegeben voraussetzen. Ein System, das mit einem Wackelkontakt problematisch würde, darfst Du demnach gar nie in Betrieb setzen. >> bestimmt. Aber warum sollte man ein funktionsfähiges System dann >> zwingend außer Betrieb setzen? > > Es ist ja eben nicht funktionsfähig, sonst hätte es ja keinen Fehler > gegeben. - OK, vielleicht haben wir ja unterschiedliche Definitionen von > funktionsfähig? Wenn du meinst, daß ein "funktionsfähiges" System > *meistens* sich so verhält wie designt, dann magst du recht haben. Halte > ich aber für hinterfragbar, wenn es um Menschenleben geht. Es geht doch hier die ganze Zeit NICHT um einen Gerätefehler, sondern um externe Ereignisse, die das Gerät möglicherweise nur kurzzeitig ausser Tritt gebracht hatte. Ein Beispiel wäre EMV, z.B. Blitzschlag in der Umgebung. Ja ich weiss, dass Du alle Geräte immer so auslegst, dass ein direkter Blitzschlag immer noch kontrolliert bearbeitet wird... Hör mir mit solchen Albernheiten auf. Du kannst ein System nie so auslegen, dass alle Eventualitäten abgedeckt sind. Da in der Praxis immer wieder mal solch hässliche Dinge passieren, die eigentlich nicht passieren dürften, bleibt die Frage, wie man dann damit umgeht. Darum geht es hier und nicht um Bauteilausfall oder schlechtes EMV-Design, wobei da die Grenzen fließend sein werden. Auch hier bleibt die Frage, wie mit solchen Fehlern umgegangen werden soll. Ich verweise wieder auf die el. Lenkhilfe... > Es kann natürlich sinnvoll sein, ein fehlerhaftes System ggf. nach Reset > weiterlaufen zu lassen, weil die Alternative noch problematischer wäre. > Lenkunterstützung hatten wir schon, noch spektakulärer bei einer > startenden Rakete: Abschalten ist da keine Option, also wird man nach > WDT/POR/BOR (der hoffentlich schnell genug ist) versuchen, genauso > weiterzumachen wie vorher, weil das *möglicherweise* hilft, alles andere > andere aber sicher ein Totalverlust wäre. Das ändert aber gar nichts > daran, daß ein derart spinnendes System fehlerhaft ist und der Fehler > konstruktiv behoben gehört! Das kannst Du in vielen Fällen aber erst retrospektiv tun. Hier geht es aber darum, was man vorausschauend eindesignt, für die Fälle, die eben noch nicht bekannt sind, aber sicher kommen werden. Genau davon gehe ich nämlich aus. Alles andere halte ich für naiv. Du wirst EMV nur bis zu bestimmten Grenzwerten auslegen und testen können. Ich verspreche Dir, dass sich die Natur nicht immer daran halten wird, was man von ihr so erwartet. Es soll im Ahrtal einige Häuser geben, die da schon sehr lange standen und viel Regen abbekommen hatten. Irgendwie ist es dann doch passiert, dass da mal mehr Wasser vom Himmel kam, als sich irgendjemand vorstellen mochte. Und ja, da waren viele dabei, die keine Elementarschafdenversicherung hatten. Viele wohl, weil diese unbezahlbar gewesen wäre oder von den Versicherungen gar nicht angeboten worden wären. Ich weiss wovon ich rede, ich habe sozusagen intime Einblicke in diese Szene. Im Angebot hat man diese Tarife immer. Verkaufen tut man sie dann trotzdem nicht. Bis dahin, dass der Vertrag einfach nie in der Zentrale ankommt, egal wie oft er eingereicht wird. Der wird einfach nicht angenommen, der Vertreter kommt auch nie mehr zu Dir, hat nie mehr Zeit für Dich... Und die Konkurrenz erst recht nicht. > So weit sind wir ja offenbar nicht auseinander - ich vermute, unsere > Differenzen liegen irgendwo in der definitionstechnischen Grauzone > zwischen "funktionsfähig" und "fehlerfrei". So wird es sein. Ich gehe immer davon aus, dass es etwas geben wird, was das System außer Tritt bringt. Wenn das nie eintritt, ist alles gut, aber man sollte eine sinnvolle Version der Handlungsalternativen haben, wenn doch. Einfach abschalten ist IMHO oft keine sinnvolle Option. Im AED ist sie es tatsächlich, trotz Medizintechnik und im wahrsten Sinn an der Grenze des Lebens eingesetzt. Und auch da ist in meinen Designs differenziert getestet worden, ob man nicht doch neu starten kann. > In dem Fall, wo es schiefgeht, und du die Anlage trotz voriger Probleme > weiterlaufen läßt und es dadurch Unfälle gibt, hast du jedenfalls > *richtig* Ärger. Wieso sollte das passieren? Entweder man kann nachweisen, dass man einen Fehler unter Kontrolle bringt oder man lässt es bleiben. Solange man das aber kann, gibt es keinen Grund das Gerät nicht in Betrieb zu nehmen. Kann man das nicht, dann ist das Design kaputt. Du musst bei jeder nicht getesteten Komponente davon ausgehen, dass sie defekt ist. Der Ansatz scheint Dir nicht vertraut zu sein. Marte
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2021-08-19 18:06 +0200 |
| Message-ID | <io7drlF1nbU1@mid.individual.net> |
| In reply to | #308811 |
Am 19.08.21 um 15:55 schrieb Marte Schwarz: >> Ich hab eher den gegenteiligen Eindruck: Du glaubt, IMO eher naiv, >> verifizieren zu können, ob ein System funktionsfähig ist. Kann man >> aber nicht - einfaches Beispiel: Wackelkontakt, der beim Check nicht >> auftritt. Jetzt wird man in der Realität mit dem Restrisiko leben >> müssen, aber spätestens, nachdem nicht vorhersehbarer Fehlerzustand >> aufgetreten ist, *weiß* man, daß das System irgendwie fehlerhaft ist. > > Solange man sein System so konstruiert hatte, dass man diesen Fehler > sicher beherrschen kann, bleibt das Risiko begrenzt. *Welchen* Fehler? Es geht doch die ganze Zeit um Fehler(auswirkungen), deren Ursache nicht genau bekannt ist: Irgendwas ist nicht so, wie es sein sollte, WDT schlägt zu, System befindet sich beim folgenden Neustart für gesund. Welcher Fehler war das jetzt? > Unter dieser Maxime > ist generell zu entwickeln. Ein Fehler, den man nicht sicher erkennen > und beherrschen kann, muss man in der Sicherheitsbetrachtung als gegeben > voraussetzen. Ein System, das mit einem Wackelkontakt problematisch > würde, darfst Du demnach gar nie in Betrieb setzen. Ich hab nicht gesagt, wo der Wackelkontakt ist. Der könnte überall sein: In jeder Lötung, Steckverbindung, in jedem Bonddraht jedes IC, Haarriß auf der Leiterplatte *g*. Klar, man wird eher Steckverbindungen und Verkabelungen bei Fehlerszenarien berücksichtigen, beim Rest dürfte das Restrisiko mit vernünftiger Fertigung und QA minimal sein. Aber eben nicht null. Es gibt mit Sicherheit Stellen, an denen eine zur Unzeit auftretende schlechte Verbindung unschöne Effekte haben wird. >>> bestimmt. Aber warum sollte man ein funktionsfähiges System dann >>> zwingend außer Betrieb setzen? >> >> Es ist ja eben nicht funktionsfähig, sonst hätte es ja keinen Fehler >> gegeben. - OK, vielleicht haben wir ja unterschiedliche Definitionen >> von funktionsfähig? Wenn du meinst, daß ein "funktionsfähiges" System >> *meistens* sich so verhält wie designt, dann magst du recht haben. >> Halte ich aber für hinterfragbar, wenn es um Menschenleben geht. > > Es geht doch hier die ganze Zeit NICHT um einen Gerätefehler, sondern um > externe Ereignisse, die das Gerät möglicherweise nur kurzzeitig ausser > Tritt gebracht hatte. Ein Beispiel wäre EMV, z.B. Blitzschlag in der > Umgebung. Und wie willst du das unterscheiden? DAS ist doch der Punkt. Irgendwas ist nicht so, wie es sein sollte, WDT schlägt zu, System befindet sich beim folgenden Neustart für gesund. Ist es wirklich gesund, und war das ein Blitzschlag oder kosmische Strahlung, oder liegt ein Gerätefehler vor z.B. in Form eines Wackelkontakts oder was auch immer, der beim Selbsttest gerade mal nicht da ist, oder an den der die Selbsttestroutinen Schreibende nicht gedacht hat? >> Es kann natürlich sinnvoll sein, ein fehlerhaftes System ggf. nach >> Reset weiterlaufen zu lassen, weil die Alternative noch >> problematischer wäre. Lenkunterstützung hatten wir schon, noch >> spektakulärer bei einer startenden Rakete: Abschalten ist da keine >> Option, also wird man nach WDT/POR/BOR (der hoffentlich schnell genug >> ist) versuchen, genauso weiterzumachen wie vorher, weil das >> *möglicherweise* hilft, alles andere andere aber sicher ein >> Totalverlust wäre. Das ändert aber gar nichts daran, daß ein derart >> spinnendes System fehlerhaft ist und der Fehler konstruktiv behoben >> gehört! > > Das kannst Du in vielen Fällen aber erst retrospektiv tun. Hier geht es > aber darum, was man vorausschauend eindesignt, für die Fälle, die eben > noch nicht bekannt sind, aber sicher kommen werden. Genau davon gehe ich > nämlich aus. Alles andere halte ich für naiv. Du wirst EMV nur bis zu > bestimmten Grenzwerten auslegen und testen können. Ich verspreche Dir, > dass sich die Natur nicht immer daran halten wird, was man von ihr so > erwartet. Genau darum geht es mir. *Wenn* dann aber in der Realität die Störungen größer sind als angenommen und (damals?) testbar, und daher durchschlagen, sollte man aber (in sicherheitskritischen Bereichen) eher nachbessern als das populäre Allheilmittel "Reboot" zu verwenden. > Es soll im Ahrtal einige Häuser geben, die da schon sehr lange > standen und viel Regen abbekommen hatten. Irgendwie ist es dann doch > passiert, dass da mal mehr Wasser vom Himmel kam, als sich irgendjemand > vorstellen mochte. Und der WDT-Benutzer sagt sich: Das war ein singuläres Ereignis, haben wir ja noch nie vorher gesehen, daß es so viel regnet, derzeit regnet es ja auch kaum, das passiert sicher nicht noch mal, also bauen wir die Häuser wieder an die gleiche Stelle ;) Na gut, nicht alles, was hinkt, ist ein Vergleich. >> So weit sind wir ja offenbar nicht auseinander - ich vermute, unsere >> Differenzen liegen irgendwo in der definitionstechnischen Grauzone >> zwischen "funktionsfähig" und "fehlerfrei". > > So wird es sein. Ich gehe immer davon aus, dass es etwas geben wird, was > das System außer Tritt bringt. Wenn das nie eintritt, ist alles gut, > aber man sollte eine sinnvolle Version der Handlungsalternativen haben, > wenn doch. Einfach abschalten ist IMHO oft keine sinnvolle Option. Im > AED ist sie es tatsächlich, trotz Medizintechnik und im wahrsten Sinn an > der Grenze des Lebens eingesetzt. Und auch da ist in meinen Designs > differenziert getestet worden, ob man nicht doch neu starten kann. Das mag ja sein, aber mal zurück zum Thema Ampelanlage: Wenn Wolfgang schreibt "FYI Ampelanlagen in D gehen Störungen per Vorschriften in einen sicheren Zustand. Zwangsweise!", dann glaub ich ihm das erst mal. Wenn ich dann https://www.ksta.de/koeln/nach-stromausfall-ampeln-im-koelner-stadtgebiet-wieder-in-betrieb-38093580?cb=1629386022334 "Nachdem sich die meisten Ampelanlagen bereits kurz nach dem Ausfall selbstständig wieder angeschaltet hatten, mussten neun Anlagen durch Techniker der Stadt manuell wieder in Betrieb genommen werden." (nach einem simplen Stromausfall!) lese, paßt das auch ziemlich gut dazu. Jetzt kannst du, wie bereits mehrfach im Thread geäußert, zwar es glauben besser zu wissen und zu bezweifeln, daß das die richtige Strategie ist, und daß stattdessen die Ampeln in jedem Fall nach erfolgreichem Selbsttest wieder selbsttätig starten sollten, aber das geht dann schon arg in Richtung Selbstüberschätzung, denn du stellst dich damit als Fachfremder gegen die Gesamtheit der Erfahrungen der Verkehrstechnik, deren Resultat ja (hoffentlich) die erwähnten Vorschriften sind. Du solltest vielleicht einfach mal akzeptieren, daß man andernorts vorsichtiger ist als du, und das vielleicht sogar bessere Gründe hat, als daß alle anderen doof sind. Egal, wie doll du das Thema unterrichtest. >> In dem Fall, wo es schiefgeht, und du die Anlage trotz voriger >> Probleme weiterlaufen läßt und es dadurch Unfälle gibt, hast du >> jedenfalls *richtig* Ärger. > > Wieso sollte das passieren? Wieso sollte das *nicht* passieren? Murphy. Woher kommen die Vorschriften? Ist das nie vorgekommen? Ich würde blind aufs Gegenteil wetten. > Entweder man kann nachweisen, dass man einen > Fehler unter Kontrolle bringt oder man lässt es bleiben. Zum x-ten Mal: Irgendwas war seltsam, der WDT schlägt zu, hinterher sieht alles gut aus. Was war der Fehler? Wie willst du einen Fehler, den du nicht mal kennst, unter Kontrolle bringen? > Solange man das > aber kann, gibt es keinen Grund das Gerät nicht in Betrieb zu nehmen. Du kannst es aber nicht, s.o. > Kann man das nicht, dann ist das Design kaputt. Dann ist das wohl so. > Du musst bei jeder nicht > getesteten Komponente davon ausgehen, dass sie defekt ist. Der Ansatz > scheint Dir nicht vertraut zu sein. Ich denke eher, daß dir nicht klar ist, was das bedeutet. Teste mal den Siebkondensator deiner Stromversorgung. Insbesondere auch darauf, daß er nicht *demnächst* dahinschwindet und der resultierende Ripple deinen Prozessor wunderliche Dinge tun läßt. [1] Ich denke, du weißt, wie man das Problem in der Raumfahrttechnik zu adressieren versucht, aber das will man andernorts meist nicht bezahlen, Sicherheit hin oder her. Hanno [1] Vielleicht hat auch der Ripple irgendwie den WDT Reset ausgelöst, aber gerade ist alles wieder gut, weil jetzt die Sonne auf den Schaltkasten scheint und 5° mehr ausreichen, um den ESR so weit zu verringern, daß der Ripple gerade ausreicht, um keinen erkennbaren Fehler mehr auszulösen...? -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Marte Schwarz <marte.schwarz@gmx.de> |
|---|---|
| Date | 2021-08-20 09:23 +0200 |
| Message-ID | <sfnl9a$t22$1@gwaiyur.mb-net.net> |
| In reply to | #308823 |
Hi Hanno, >> Solange man sein System so konstruiert hatte, dass man diesen Fehler >> sicher beherrschen kann, bleibt das Risiko begrenzt. > > *Welchen* Fehler? Es geht doch die ganze Zeit um Fehler(auswirkungen), > deren Ursache nicht genau bekannt ist: Irgendwas ist nicht so, wie es > sein sollte, WDT schlägt zu, System befindet sich beim folgenden > Neustart für gesund. Welcher Fehler war das jetzt? Genau deshalb ist es bei sicherheitsrelevanten Systemen so, dass man nach einem WDT (wie auch bei jedem POR) zunächst einmal Checkt warum gestartet wird und dann werden eine ganze Runde Selbsttests durchgeführt. Nicht selten werden diese Selbsttests auch in regelmäßigen Abständen durchgeführt, so wie Du auch alle 2 Jahre Dein Auto zum TÜV bringst... Du darfst beim Einschalten des Gerätes nie davon ausgehen, dass das Gerät fehlerfrei sei, weder beim POR noch beim WDT. Wenn beim Selbsttest kein Fehler erkannt wird, darf man tatsächlich davon ausgehen, dass kein Fehler da ist, selbst wenn der WDT ausgelöst hatte. Selbstverständlich hat man den WDT-Reset festzuhalten und zu melden. Selbstverständlich muss man der Ursache dann auf den Grund gehen und die Ursachen zu ermitteln und Abzustellen versuchen. Eine WDT-Reset ist nie ein Allheilmittel, es ist immer ein Rückfallsystem, eine Fehlerbehandlungsroutine. >>> Es ist ja eben nicht funktionsfähig, sonst hätte es ja keinen Fehler >>> gegeben. - OK, vielleicht haben wir ja unterschiedliche Definitionen >>> von funktionsfähig? Wenn du meinst, daß ein "funktionsfähiges" System >>> *meistens* sich so verhält wie designt, dann magst du recht haben. Jedes System verhält sich höchstens im spezifizierten Bereich so, wie es designt wurde. Im Gegensatz zu Dir betrachte ich grundsätzlich auch das Verhalten eines Gerätes, wenn es Events außerhalb des erlaubten Bereiches gibt. >>> Halte ich aber für hinterfragbar, wenn es um Menschenleben geht. Ich halte es für fahrlässig genau dieses nicht zu tun. Wer so tut, als ob sein Gerät niemals nicht in eine Situation geraten kann, die nicht vorhergesehen wurde, begeht in meinen Augen eine fahrlässige Ignoranz. >> Es geht doch hier die ganze Zeit NICHT um einen Gerätefehler, sondern >> um externe Ereignisse, die das Gerät möglicherweise nur kurzzeitig >> ausser Tritt gebracht hatte. Ein Beispiel wäre EMV, z.B. Blitzschlag >> in der Umgebung. > > Und wie willst du das unterscheiden? DAS ist doch der Punkt. Irgendwas > ist nicht so, wie es sein sollte, WDT schlägt zu, System befindet sich > beim folgenden Neustart für gesund. Ist es wirklich gesund, und war das > ein Blitzschlag oder kosmische Strahlung, oder liegt ein Gerätefehler > vor z.B. in Form eines Wackelkontakts oder was auch immer, der beim > Selbsttest gerade mal nicht da ist, oder an den der die > Selbsttestroutinen Schreibende nicht gedacht hat? Genau darum geht es doch die ganze Zeit. Du weißt nie, welche Geschichte Dein Gerät hatte, es sei denn, Dir ist es gelungen, ein wenig Geschichte zwischen den Resets zu erhalten. Den Rest machen Selbsttests, die natürlich aussagekräftig sein müssen, die auch die Überwachungseinheiten prüfen etc. Das ist eine Welt, in die man sich eindenken und einleben muss. Entweder das geht einem als Designer in Fleich und Blut über, oder man wechselt besser in den Consumerbereich... > Genau darum geht es mir. *Wenn* dann aber in der Realität die Störungen > größer sind als angenommen und (damals?) testbar, und daher > durchschlagen, sollte man aber (in sicherheitskritischen Bereichen) eher > nachbessern als das populäre Allheilmittel "Reboot" zu verwenden. Wie oft habe ich hier schon geschrieben, dass ein WDT kein Heilmittel ist und dass man nicht einfach zur Tagesordnung übergehen darf? Aber bis dahin einfach abzuschalten ist eben oft keine schlaue Idee. >> Es soll im Ahrtal einige Häuser geben, die da schon sehr lange standen >> und viel Regen abbekommen hatten. Irgendwie ist es dann doch passiert, >> dass da mal mehr Wasser vom Himmel kam, als sich irgendjemand >> vorstellen mochte. > > Und der WDT-Benutzer sagt sich: Das war ein singuläres Ereignis, haben > wir ja noch nie vorher gesehen, daß es so viel regnet, derzeit regnet es > ja auch kaum, das passiert sicher nicht noch mal, also bauen wir die > Häuser wieder an die gleiche Stelle ;) Lass uns eine Wette abschließen, ob im Ahrtal nächstes Jahr an diesen überfluteten Stellen Häuser bewohnt sein werden... :-( Lass uns eine Wette abschließen, ob nächstes Jahr an vergleichbaren Stellen Wohngebäude bewohnt sein werden, obwohl es ein endliches Risiko gibt, dass sie irgendwann ein vergleichbares Schadensereignis ereilt. Lass uns eine Wette abschließen, ob in wenigen Jahren wieder Wanderer durch die Höllentalschlucht wandern werden... > Na gut, nicht alles, was hinkt, ist ein Vergleich. ;-) > "Nachdem sich die meisten Ampelanlagen bereits kurz nach dem Ausfall > selbstständig wieder angeschaltet hatten, mussten neun Anlagen durch > Techniker der Stadt manuell wieder in Betrieb genommen werden." > > (nach einem simplen Stromausfall!) lese, paßt das auch ziemlich gut dazu. Bei neun Anlagen hat es also geklappt, wie es angeblich vorgeschrieben ist und alle anderen Anlagen sind nicht normkonform? > Jetzt kannst du, wie bereits mehrfach im Thread geäußert, zwar es > glauben besser zu wissen und zu bezweifeln, daß das die richtige > Strategie ist, und daß stattdessen die Ampeln in jedem Fall nach > erfolgreichem Selbsttest wieder selbsttätig starten sollten, Du schreibst das doch gerade selbst. Die allermeisten Anlagen sind selbsttätig wieder in Betrieb gegangen. > Du solltest vielleicht einfach mal akzeptieren, daß man andernorts > vorsichtiger ist als du, und das vielleicht sogar bessere Gründe hat, > als daß alle anderen doof sind. Ich habe seltenst von Ampeln geschrieben. Ich hatte mich meist auf konkrete Beispiele bezogen, sei es die elektrische Bremsunterstützung, oder auch lebenserhaltende Systeme. Ich hatte auch (hoffentlich) klar kommuniziert, dass es Systeme gibt, bei denen ein sicherer Zustand "Power-Off" sinnvoll ist und andere, bei denen ich das anders sehe und dies auch stets versucht nachvollziehbar zu erklären, wie ich dazu komme. Wenn es eine Norm gibt, in der die Sicherheitsabschaltung von Ampeln tatsächlich so rigide drin steht, dann hätte das schon lange belegt werden können. Und selbst da sagt mir meine Erfahrung, dass in den Normen oft veraltetes Zeugs steht und viele verständige Gutachter bei benannten Stellen das auch wissen :-) Genau so wie es manuelle Defis mit Relais gibt, gab/gibt es sicher noch Ampelsteuerungen auf mechanischen Schrittschaltwerken oder vergleichbarer Low-tech, deren Fehlerbehandlungsroutinen eben weniger Spielraum gelassen hatten. > Wie willst du einen Fehler, den du nicht mal kennst, unter Kontrolle bringen? Das ist doch Alltag in der Sicherheitstechnik. Du kannst nie alle Fehler kennen! Du kennst die korrekten Zustände und alles, was davon abweicht ist falsch. Das kann und muss man erkennen und darauf reagieren. >> Du musst bei jeder nicht getesteten Komponente davon ausgehen, dass >> sie defekt ist. Der Ansatz scheint Dir nicht vertraut zu sein. > > Ich denke eher, daß dir nicht klar ist, was das bedeutet. Du unterstellst mir laufend Dinge, die ich hier schon wiederholt anders dargestellt hatte. > Teste mal den Siebkondensator deiner Stromversorgung. Nein, ich teste, ob die Spannungsversorgung korrekt ist. Solange sie das ist, kann vernünftig gearbeitet werden. Tritt ein Event auf, in dem das nicht so ist, wird das gerne vermerkt udn in einen sicheren Zustand überführt. Das kann je nach Anforderung das Umschalten auf eine Notstromversorgung, das Herunterfahren des Systemes oder sonstige Maßnahmen auslösen, die zum Einsatzgebiet passen. Eine Maßnahme, die tatsächlich nicht allzu selten sinnvoll ist, ist das System weiterlaufen zu lassen, sofern ich es in einem kontrollierbaren Zustand halten kann. > nicht *demnächst* dahinschwindet und der resultierende Ripple deinen > Prozessor wunderliche Dinge tun läßt. Das möchte ich sehen, wie Du damit umgehst... > das Problem in der Raumfahrttechnik zu adressieren versucht, aber das > will man andernorts meist nicht bezahlen, Sicherheit hin oder her. So ist es, nur leider unterstellst Du mir immer wieder, dass ich nicht differenzieren könne und willst statt dessen alles undifferenziert abschalten. Oder auch plötzlich doch nicht mehr, aber bitte nur mit mehrfacher redundanter Auslegung, die aber leider viele nicht bezahlen wollen... > [1] Vielleicht hat auch der Ripple irgendwie den WDT Reset ausgelöst, > aber gerade ist alles wieder gut, weil jetzt die Sonne auf den > Schaltkasten scheint und 5° mehr ausreichen, um den ESR so weit zu > verringern, daß der Ripple gerade ausreicht, um keinen erkennbaren > Fehler mehr auszulösen...? Und jetzt? Du würdest jetzt also den Lenkassistenten ausgeschaltet lassen? Um zum Defi zurück zu kehren, dessen sicherer Zustand in meinem Umfeld so definiert ist, dass keine Hochspannung geladen sein darf: Ist es jetzt sinnvoller nach einem solchen Event, alles still zu legen oder würdest Du es doch vorziehen, wenn das System neu durchstartet und vielleicht doch noch einen gut überwachten lebensrettenden Stromstoß abgibt, weil Dein Gesamtsystem so sicher konstruiert ist, dass es bei einem erneuten kritschen Vorfall innerhalb von ms in der Lage ist, den sicheren Zustand anzufahren? Marte
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2021-08-20 07:43 -0400 |
| Message-ID | <FcEokz7UQoB@allinger-307049.user.uni-berlin> |
| In reply to | #308865 |
On 20 Aug 21 at group /de/sci/electronics in article sfnl9a$t22$1@gwaiyur.mb-net.net <marte.schwarz@gmx.de> (Marte Schwarz) wrote: > Genau so wie es manuelle Defis mit Relais gibt, gab/gibt es sicher noch > Ampelsteuerungen auf mechanischen Schrittschaltwerken oder > vergleichbarer Low-tech, deren Fehlerbehandlungsroutinen eben weniger > Spielraum gelassen hatten. Diese Ampeln, vor allem die SBH Phasensatzsteuerungen (Programmwalzen für jede komplette Phase) waren da sehr sicher, da sie nicht schneller laufen konnten, als der Synchronmotor samt Getriebe hergab. Aber eben mechanisch sehr aufwendig. Per uC sollte dass dann wesentlich billiger und einfacher werden. Wars auch. Allerdings können Compuster auch wesentlich schneller laufen, als vorgesehen. Auch die verkehrsabhängigkeit war vollständig zu machen. Ich hab seinerzeit (1978?) die erste voll verkehrsabhängige VSA (Ampel) der Welt in Düsseldorf, Hüttenstrasse Ecke Sonnenstrasse entwickelt und programmiert. Zusätzlich noch lustige StraBa Vorrangschaltung... Ja, HW und SW auf 8080 Basis. Und wer elektrisches Gespratzel von Bahnen auf die Elektronik kennt, weiss, was da los war! Ich weiss nicht mehr, wie ich damals das Problem mit dem sicheren 1Hz Takt gelöst habe, aber der TÜV hats abgesegnet. Und die waren äusserst skeptisch: 1 uC statt dutzenden Walzen? Sowas geht nie nicht, hamwa ja noch nie gemacht... Und im Hintergrund schmiss SIEMENS auch noch mit Knüppel und Lehm! Ich hab später noch oft gegen SIEMENS als Einzelkämpfer gewonnen. ICE Soultz/Elsass, Thyssen Krupp, Ensidesa, BHP in einigen Walzwerken, KKW Mülheim/Kärlich, Biblis, Mercedes Benz Düsseldorf, BritishRail sind mir gerade wieder eingefallen. SIEMENS hat das Problem, dass sie hervorragend Zinseszinsrechnung beherrschen, dafür ansonsten schon mal schwächeln :) besonders bei Kreativität, Flexibilität und Beweglichkeit. Grossbank mit Elektro Bauchladen :) Warum sind Dinos augestorben? Zuviel Scheiss, zuwenig Hirn! Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
Page 34 of 40 — ← Prev page 1 … 32 33 [34] 35 36 … 40 Next page →
Back to top | Article view | de.sci.electronics
csiph-web