Hi Leute ... brauche eure Hilfe... Ich will eigentlich ganz was einfaches machen. Habe eine kleine Schaltung: Akku ( 4V ) geht an Schalter ( EIN AUS ) und weiter zum kleinen Motor. Ich möchte erreichen, dass wenn ich einschalte: Der Motor nicht sofort AN geht, sondern zufällig innerhalb weniger Sekunden angeht ( zb. 10 Sek. ) und auch AN bleibt. Wie bekomm ich das hin? Geschaltet werden solln ca. 100 mAh Vielen Dank für eure Antworten... MfG
Ich würde einen kleinen uC verwenden und währen die Taste gedrückt ist einen Zähler sehr schnell von 1-10 zählen lassen. Wenn die Taste losgelassen wir, würde ich den Zählerstand als zufälligen wer nehmen. Es ist aber kein echter Zufall.
:
Bearbeitet durch User
Bastler schrieb: >> Es ist aber kein echter Zufall. > > Es gibt auch keinen "echten" Zufall Rauschen? Zerfall von Atomen?
M. H. schrieb: > Ich würde einen kleinen uC verwenden und währen die Taste gedrückt ist > einen Zähler sehr schnell von 1-10 zählen lassen. Wenn die Taste > losgelassen wir, würde ich den Zählerstand als zufälligen wer nehmen. Es > ist aber kein echter Zufall. Ganz im Gegenteil, wenn der Zähler schnell genug getaktet wird, dann sind die Zeiten (echt) zufällig. Ansonsten würde ich es auch so machen, wie du es vorgeschlagen hast: µC -> Transistor -> kleiner Motor
M. H. schrieb: > Es ist aber kein echter Zufall. Meinst du, du kannst bei z.B. 1MHz Zählfrequenz (Timer mit µC-Clock) irgendwie erreichen, dass der Bediener den Tastendruck auch auf nur 10µs genau hinbekommt? Der Bediener ist nach der Beschreibung immerhin Bestandteil des Zufallszahlengenerators.
Bastler schrieb: >> Es ist aber kein echter Zufall. > > Es gibt auch keinen "echten" Zufall Warum gibt es keinen echten Zufall? Der Beweis für diese Behauptung interessiert mich.
Davis schrieb: > Warum gibt es keinen echten Zufall? Der Beweis für diese Behauptung > interessiert mich. Weil alles auf den physikalischen Gesetzen basiert
Ok... Es ist zufällig, da ein Mensch es nicht bewusst beeinflussen kann. Theoretisch ist es aber kein Zufall, da der Wert direkt von der Zeit, in der der Taster gedrückt ist abhängig.
Bastler schrieb: > Davis schrieb: >> Warum gibt es keinen echten Zufall? Der Beweis für diese Behauptung >> interessiert mich. > > Weil alles auf den physikalischen Gesetzen basiert Und in denen ist der Zufall inhärent. Stichwort Quantenmechanik.
Bastler schrieb: > Davis schrieb: >> Warum gibt es keinen echten Zufall? Der Beweis für diese Behauptung >> interessiert mich. > > Weil alles auf den physikalischen Gesetzen basiert Und nach heutigem Wissensstand laufen eine ganze Reihe dieser physikalischen Prozesse zufällig ab.
Hab grad noch etwas rumgeforscht und rausgefunden, dass das perfekte eine digitale Zeitschaltuhr mit Random Funktion wäre. Nur diese muss auch in die Niederspannungsschaltung passen und möglichst mini sein... Zum Thema Zufall :-) Physikalisch gesehen gibt es nach Stand der Forschung zwei Sorten von Zufall: das deterministische und das indeterministische Chaos.
Bastler schrieb: > Davis schrieb: >> Warum gibt es keinen echten Zufall? Der Beweis für diese Behauptung >> interessiert mich. > > Weil alles auf den physikalischen Gesetzen basiert Unfug. Habe ich mir doch gedacht, dass du keinen Beweis hast.
Bastler schrieb: > Davis schrieb: >> Warum gibt es keinen echten Zufall? Der Beweis für diese Behauptung >> interessiert mich. > Weil alles auf den physikalischen Gesetzen basiert Ein metastabiler Atomkern möge eine Halbwertszeit von einer Sekunde habe. Du misst nach genau einer Sekunde, ob der Atomkern zerfallen ist. Ist er das, so mögest Du ein Bit auf Eins setzen, andernfalls auf 0. Der Wert dieses Bits ist echt zufällig. Beispiel, wie sowas in der Praxis aussehen kann: http://www.youtube.com/watch?v=SxP30euw3-0 http://www.youtube.com/watch?v=noDSyLzVz2g Um auf das Ausgangsthema zurückzukommen: Ein eigener uC nur für die paar Sekunden zufälliger Einschaltverzögerung kommt mir persönlich etwas viel Aufwand vor, gäbe es einfache Alternativen ohne uC?
Hallo Davis, ich denke die Antwort ist einfach. Der Zufall (-Zahl) ist nicht vorhersagbar, aber ein reines Computerprogramm ist deterministisch, es hat ein Mensch geschrieben und es macht auch nur das, was dieser ihm vorgibt. Also arbeitet es nur vorbestimmte Anweisungen ab und wird deshalb vorhersagbar - auch wenn es endliche Zeit benötigt, um einen Anfangszustand wieder zu erreichen.
:
Bearbeitet durch User
Norbert M. schrieb: > Ein eigener uC nur für die paar > Sekunden zufälliger Einschaltverzögerung kommt mir persönlich etwas viel > Aufwand vor, gäbe es einfache Alternativen ohne uC? Wie bekommst Du dann einen Zufall eingebaut? Der AtTiny10 hätte die passende Größe für sowas.
ROFL Schon spaßig was hier so alles zustande kommt :-P @TO: Kleinen µC z.B. Tiny85 nehmen, Taster anschließen und das Prellen via PinChangeIRQ auswerten, also einfach zählen lassen und mit %10 den Timer für das Anschalten des Motors beschicken.
Oliver R. schrieb: > Norbert M. schrieb: >> Ein eigener uC nur für die paar Sekunden zufälliger >> Einschaltverzögerung kommt mir persönlich etwas viel >> Aufwand vor, gäbe es einfache Alternativen ohne uC? > Wie bekommst Du dann einen Zufall eingebaut? Genau das war meine Frage. Wenn ich's wüsste, würde ich nicht fragen ;-) Für so ein Problem muß es doch auch eine analoge Lösung geben.
Uwe S. schrieb: > Hallo Davis, > > ich denke die Antwort ist einfach. > > Der Zufall (-Zahl) ist nicht vorhersagbar, aber ein reines > Computerprogramm ist deterministisch, es hat ein Mensch geschrieben und > es macht auch nur das, was dieser ihm vorgibt. > > Also arbeitet es nur vorbestimmte Anweisungen ab und wird deshalb > vorhersagbar - auch wenn es endliche Zeit benötigt, um einen > Anfangszustand wieder zu erreichen. Hallo Uwe, die Antwort ist einfach. Dadurch, dass der Mensch die Taste betätigt und wieder loslässt, wird der für die Steuerung herangezogene Timerwert sehr zufällig. Der Mensch bringt den Zufall ein, das Programm gibt ihn nur wieder. Und wie immer in der Physik kann ein Experiment den Beleg liefern. Also, man nehme einen ATTiny13, schließe eine Taste an und schreibe ein Programm, welches nach dem Drücken und wieder Loslassen den 8Bit Timerwert ausgibt. Die Timerwerte untersuche man dann auf "Zufälligkeit". Bei z. B. 25600 "Versuchen" (was natürlich eine ganze Menge ist) wird jeder mögliche Timerwert rund 100 mal vertreten sein.
> Für so ein Problem muß es doch auch eine analoge Lösung geben.
Die aber aufwändiger ist, als ein kleiner µC
Das ist ja die Krux an der ganzen Sache. Im Grunde gibt es viele
Probleme, für die der Einsatz eines µC im Grunde genommen kompletter
Overkill ist. Und trotzdem ist es die einfachste Lösung (und meistens
auch die billigste), wenn man die Anzahl der verwendeten Bauteile
betrachtet.
Durch die Programmierbarkeit sind die Dinger so flexibel einsetzbar,
dass sie in riesigen Stückzahlen gebaut werden, was wiederrum den Preis
drückt.
:
Bearbeitet durch User
Oliver R. schrieb: > Analoger Zufall, da war doch mal was: > Beitrag "analoger Zufallsgenerator" Danke für den Tipp, dort ist interessantes zu lesen (insbesondere die Schaltungen mit dem zenerrauschen). Karl Heinz schrieb: >> Für so ein Problem muß es doch auch eine analoge Lösung geben. > Die aber aufwändiger ist, als ein kleiner µC Ja, ich seh's ein. Hätte ja sein können, daß es so 'ne Art Trickschaltung gibt wie "...und dann schaltet der MOSFET nach 3 bis 10 Sekunden durch, weil die Sperrschicht..." oder sowas. > Durch die Programmierbarkeit sind die Dinger so flexibel einsetzbar, > dass sie in riesigen Stückzahlen gebaut werden, was wiederrum den Preis > drückt. Daß die Sache mit dem uC hier die einfachste und billigste ist, war mir sowiso klar. Hab' nur der Interesse halber nachgefragt - man lernt ja nie aus, insbesondere als Anfänger nicht. Danke euch Beiden! (Und möge der, der mich oben downgevotet hat, einen Pickel am Hintern bekommen :-) )
Bastler schrieb: > Weil alles auf den physikalischen Gesetzen basiert Und wie sind diese Gesetze, z.B. für den Radioaktiven Zerfall? Rechne mal vor, was da nicht zufällig ist ;-)
Angehängte Dateien:
-
image201312180001.jpg
120 KB
Man könnte das Problem auch irgendwie mit einem NE555 oder CD4093 und einem CD4017 lösen. Ist jetzt nicht 100% analog, aber ohne µC. Man könnte an jeden der Ausgänge einen anderen Widerstand + Diode anschließen, der einen Elko lädt. Der NE555 ist durch einen Pulldown im Reset, wenn der Taster nicht gedrückt ist. Der Taster setzt Reset auf 1 und schaltet einen Transistor ein, der den Elko entlädt. Wenn der Taster losgelassen wird, hört der NE555 auf zu schwingen, der Transistor sperrt und der CD4017 bleib bei einem "zufälligen" Wert stehen und der Elko wir über einen "zufälligen" widerstand geladen… Wenn man statt dem NE555 ein Schimitt-Trigger NAND nimmt, kann an zwei der nicht benötigten Gatter verwenden um eine schöne Flanke für den FET zu erzeugen.
:
Bearbeitet durch User
Klasse, danke, sowas in der Art habe ich mir vorgestellt. Bin leider zu blöd oder unerfahren, mir selbst sowas auszudenken. Da bestätigt sich mal wieder die alte Weisheit, daß man mit dem 555er und ein paar Logik-ICs fast alles lösen kann :-) Schön zu sehen, daß dieses ältere Wissen doch noch nicht ausgestorben ist. LG, N0R
Norbert M. schrieb: > Da bestätigt sich mal wieder die alte Weisheit, daß man mit dem 555er > und ein paar Logik-ICs fast alles lösen kann :-) Notfalls muss man sich den µC aus Gattern aufbauen^^. Ich glaube die Lösung mit dem CD4093 wäre in diesem Fall besser als die mit dem NE555, da der CD4093 die Flanke am Ausgang viel steiler macht und der Mosfet weniger Verlustleistung beim Schalten hat.
Soweit ich den OP lese, gibt es keinen Taster. Daß Gerät wird komplett eingeschaltet und soll dann den Motor verzögern. Mit einem MC könnte man dazu einfach die Rand-Funktion benutzen und den neuen Startwert im EEPROM speichern. Dann sind nur etwa 1.000.000 Einschaltungen garantiert (der Motor dürfte weit eher hin sein).
Peter Dannegger schrieb: > Soweit ich den OP lese, gibt es keinen Taster. Daß Gerät wird > komplett > eingeschaltet und soll dann den Motor verzögern. > > Mit einem MC könnte man dazu einfach die Rand-Funktion benutzen und den > neuen Startwert im EEPROM speichern. > Dann sind nur etwa 1.000.000 Einschaltungen garantiert (der Motor dürfte > weit eher hin sein). Muß er ja nicht speichern, µC aus wenn Schalter aus. Sobald µC Saft hat wird der Zufallswert errechnet und entsprechend ausgegeben. Und Schalter prellen nicht ?
kopfkratzer schrieb: > Muß er ja nicht speichern, µC aus wenn Schalter aus. > Sobald µC Saft hat wird der Zufallswert errechnet und entsprechend > ausgegeben. Der "Zufallsgenerator" wird aber vermutlich jedes Mal das gleich ausgeben, wenn die Startbedingungen nach dem Reset immer gleich sind. Peter Dannegger schrieb: > Dann sind nur etwa 1.000.000 Einschaltungen garantiert (der Motor dürfte > weit eher hin sein). Oder auch mehr, wenn man nicht immer die gleiche Zelle verwendet. Peter Dannegger schrieb: > Soweit ich den OP lese, gibt es keinen Taster. Daß Gerät wird komplett > eingeschaltet und soll dann den Motor verzögern. Und für echten Zufall müsste man beim Start einen Rauschgenerator mit dem ADC messen.
:
Bearbeitet durch User
M. H. schrieb: > kopfkratzer schrieb: >> Muß er ja nicht speichern, µC aus wenn Schalter aus. >> Sobald µC Saft hat wird der Zufallswert errechnet und entsprechend >> ausgegeben. > Der "Zufallsgenerator" wird aber vermutlich jedes Mal das gleich > ausgeben, wenn die Startbedingungen nach dem Reset immer gleich sind. Kommt drauf an wie man's realisiert, Kabel an ADC und man hat "echten" Zufall. Oder man nimmt als Startbedingung z.B. den internen Temperatursensor eines Tiny85. RAND() sollte aber auch beim Einschalten immer wieder etwas anderes liefern ...
Ein analog generierter Zufall müßte doch theoretisch auch mit einem Rauschgenerator, einer sample&hold-Schaltung und einem Monoflop möglich sein..?? Nicht daß die Aufgabe dadurch einfacher zu lösen wäre als mit einem Rechenknecht. Aber immerhin ein wenig einfacher, als den Zerfall eines bestimmten Atoms, und so.. ;)
kopfkratzer schrieb: > RAND() sollte aber auch beim Einschalten immer wieder etwas anderes > liefern ... nicht wirklich. der Standard C Zufallszahlengenerator ist auch nichts anderes als eine Formel. Gleiche Startbedingungen -> gleiche Zahlenfolge. Das ist in manchen Fällen gut, zum Beispiel vereinfacht es erheblich das Debugging. Ist in machen Fällen auch schlecht, weil man sich selber um die Startbedingungen kümmern muss. Mit einem EEPROM ist das aber kein Problem, so wie PeDa das beschrieben hat. Und Hand aufs Herz: Ehe da das EEPROM den Geist aufgibt, ist der ganze Klapperatismus meistens sowieso schon längst beim Altstoffsammelzentrum.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.