ich stehe vor einem kleinen Problem und würde gerne euere Meinung hören, ob diese Lösung funktionieren kann .....
Ich benötige Zufallszahlen um auf einem RGB-LED-Panel [96x32] zufällig LEDs in zufälligen Farben aufleuchten zu lassen. Dazu habe ich die Random-Funktion meines Compilers bemüht (welcher ist ja mal egal) und festgestellt, daß immer die gleichen LEDs leuchten. Manchmal kommt ein anderes Muster, aber im großen und ganzen gibt es nur 2 unterschiedliche.
Die Idee wäre nun einen Rauschgenerator an einen der ADCs anzuschliessen und diesen zyklisch auszulesen. Da es ein XMega ist, hätte ich 12 Bit also einen Bereich von 0-4095 zur Verfügung. Das beschränken auf meine benötigten Werte bekomme ich hin.
Kann das funktionieren? Als Rauschgenerator würde ich einen TA7642 AM-Empfänger-IC nehmen, von dem liegen noch 20 Stück rum und auf MW rauscht es eh nur noch.
Die Idee wäre nun einen Rauschgenerator an einen der ADCs [...]
Kann das funktionieren?
"Im-Prinzip-Ja", aber das hängt entscheidend von der Qualität des Rauschgenerators ab (u.a. Autokorellationsspektrum) und von der Art und Weise, wie die Ränder des Amplitudenspektrums behandelt werden.
Die direkt vom ADC erzeugten Werte werden dann vermutlich normalverteilt sein und nicht gleichverteilt, das muss dann im Zweifel umgemappt oder sonstwie behandelt werden. Die Abtastintervalle müssen deutlich länger als die inverse Bandbreite der Rauschquelle sein.
Für ernsthafte Kryptographie muss da eine Menge Gehirnschmalz rein, aber wenn Du bloss Lichteffekte brauchst sollte das tun.
Hast du „randomize;“ aufgerufen?
Wenn ja; wann, wo und wie oft?
Einfach „random(255;“ (oderso) erzeugt halt immer die gleichen, sich wiederholenden Zahlen. Wie genau Random(x) nun in Pascal implantiert ist, weiß ich ehrlich gesagt auch nicht. Aber ich weiß noch, dass man og. „Randomize“ aufrufen muss, um das ganze so ‚in Gang‘ zu setzen, dass random mit neuen Startwerten gefüttert wird, um es mal so auszudrücken.
Edit: implementiert
Alternativ zu „Randomize;“, welcher den Random-Generator mit systemticks seit Start (sowas wie millis()) initialisiert, könntest du den Rückgabewert „Randseed“ auch selbst mit einer (Long)Zahl füttern. Hier kann man tatsächlich den ADC nehmen, wenn man die Sache beliebig kompliziert werden lassen will. Ich würde halt ab und an „randomize“ aufrufen.
Pascal ist bei mir auch schon wieder 20Jahre her. Hab mal viel mit Delphi programmiert.
... und festgestellt, daß immer die gleichen LEDs leuchten.
Dann verwendest du immer den gleichen Startwert.
Als Rauschgenerator würde ich einen TA7642 AM-Empfänger-IC nehmen
Für ein paar blinkende LEDs ist das viel zu viel Aufwand.
Hast du nicht irgendeine Tastendruckdauer oder eine Uhrzeit, um dem Zufallszahlengenerator die identischen Startbedingungen abzugewöhnen?
Ohne auf Compiler oder Library Vodoo zu vertrauen .. Das Konzept nennt sich LFSR, linear feedback shift register. Durch Nachbilden eines schieberegisters und feedback kann man Zufallszahlen vor vorgegebener Periodizitaet bekommen. Mit 20 bit ist die Periode 1 Million, bei 30 bit eine Milliarde. Die Tabelle geht bis 168 oder so...
Siehe Xilinx, XAPP 210 : https://docs.amd.com/v/u/en-US/xapp210
Vielleicht meldet sich Harry ja nochmal und löst auf. Evtl. ist random einfach so aufgerufen worden, liefert ein real von 0.0 - 1.0 und er castet versehentlich auf int. dann kommt immer Null oder Eins raus. Kann ja auch sein.
Daher warte ich erstmal auf Feedback.
Danke aber das ist kein Turbo oder Lazarus. Wenn ich den Startwert ändere, kommt zwar auch ein anderes Muster, aber auch das ist bei gleichem Startwert immer gleich.
Das (Bild) gibt der Compiler her (AVRCo).
Danke aber das ist kein Turbo oder Lazarus. Wenn ich den Startwert
ändere, kommt zwar auch ein anderes Muster, aber auch das ist bei
gleichem Startwert immer gleich.
So arbeiten die PRNG nun einmal. An denen ist reinweg garnichts zufällig, sondern streng deterministisch. Gleicher Seed, gleiche Sequenz. Egal ob in C, Pascal oder INTERCAL.
Gut dann lassen wir doch mal die Random-Funktion des Compilers. Daß die Sche...e ist, weiss ich ja, deshalb der Ansatz Rauschen und ADC, nur wird das funktionieren? Ich würde den ADC-Eingang aus dem Bauch raus ja komplett ohne Kondensator beschalten, denn der würde das Rauschen ja glätten.
deshalb der Ansatz Rauschen und ADC, nur
wird das funktionieren?
Ausprobieren: Von ausreichend ADC-Samples nur das unterste Bit verwenden und entweder direkt nutzen, oder damit einen PRNG füttern. Kryptographische Qualität benötigst du ja nicht.
Sche...e ist, dass du nicht verstehst, wie die gestartet werden muss, um deine Anforderungen zu erfüllen. Wenn du immer an der selben Stelle in der PRBS startest (festes Seed), kannst du nicht erwarten, dass sich etwas ändert.
Damit das System nicht merkt, dass die PRBS periodisch ist, muss das Systemgedächnis kürzer als diese Periode sein und der Generator nicht immer mit dem selben Startwert gestartet werden.
Verglichen mit der Aussage „ohne Kondensator“ am ADC und der (halbwegs vorherrschenden) Komplexität der, auf Hackaday, vorgestellten Schaltung glaube ich nicht, dass das für Harry so einfach umzusetzen sein wird.
Harry, wenn kannst/willst/darfst so stell doch mal deinen Code ein, lade ihn hier als Anhang hoch. Dann kann „man“ sich das ansehen. Soo grottenschlecht ist der Random-Algo nicht, wenn man ihn, wie von der Implementation vorgesehen, verwendet.
Kannst aber auch nen 4K7 gegen VCC (5V/3.3V?) (da fallen bei geschätzten 300uA ca 1.4V ab) und eine elektretkapsel gegen GND schalten. OHNE Kondensator am Mittelabgeiff auf den ADC… da liegst du ungefähr auf V-halbe und wirst einen startwert von um 500 rum haben, wenn du das Rauschen der Kapsel und den „Krach“, den sie einfängt, nicht noch anderweitig verstärken willst.
Zähle doch einfach beim Reset eine Variable im EEPROM hoch und verwende deren Wert als "random seed". Alternativ könntest Du einen Bereich im RAM als $NOINIT definieren, in der Hoffung dass der Inhalt zufällig ist und eine Prüfsumme über den Bereich als Startwert für den Zufallsgenerator nutzen.
Ich habe auch schon den Startwert als Random gesetzt, also
RandomSeed(Random) aber selbst das bringt immer das gleiche Muster.
Wenig überraschend. Du hattest ja schon festgestellt, das ohne Seed die gleiche Sequenz kommt. Da ändert es auch nichts, wenn du den PRNG mit sich selbst fütterst.
Ansatz Rauschen und ADC, nur wird das funktionieren?
'türlich wird es. Du musst nur darauf achten:
a) Die Abstastgeschwindigkeit muss deutlich langsamer sein als die inverse Bandbreite des Rauschens
b) Die Zahlenwerte werden nicht gleichverteilt sein, sondern Gauss-verteilt ("Glockenkurve"). Die müsste man ggf. noch per Software gradebiegen, wenn erforderlich.
Wenn a/b das ein Problem ist, dann nimm nur einige wenige ADC-Zufallszahlen und füttere damit den Startwert eines PRNG.
Ich würde den ADC-Eingang aus dem Bauch raus ja
komplett ohne Kondensator beschalten, denn der würde das Rauschen ja
glätten.
Ja, der C wäre kontraproduktiv.
Als Rauschquelle nimm einfach eine Zenerdiode, deren Rauschen breitbandig verstärkt wird.
Als Rauschquelle nimm einfach eine Zenerdiode, deren Rauschen
breitbandig verstärkt wird.
Antenne, in Form ein paar cm offener Leitung, dürfte fürs unterste Bit des ADC reichen. Da ist zwar jeder Mist dabei, voran SNTs und Leuchtstoffröhren, aber für den Seed eines PRNG und seine LEDs reicht es sicher.
Antenne, in Form ein paar cm offener Leitung, dürfte fürs unterste Bit
des ADC reichen. Da ist zwar jeder Mist dabei, voran SNTs und
Leuchtstoffröhren, aber für den Seed eines PRNG und seine LEDs reicht es
sicher
DAS ist mal eine Idee, die schnell umsetzbar ist :-) Danke.
hatte ich mal nen Zufallszahlengenerator vorgestellt. Der macht guten Zufall.
LFSR als Zufallszahlengeneratoren ranziehen ist keine gute Idee. Selbst wenn man nur ein Einzelbit nimmt ist das nicht gut verteilt.
Analoge Quellen Antennen Z-Dioden etc. pp. nicht ranziehen. Wir haben mal Wochen erfolglos zugebracht um eine Schaltung mit Z-Diode von einem Radio in einen Rauschgenerator zu verwandeln.
Mache nie was analog was Du auch digital machen könntest.
hatte ich mal nen Zufallszahlengenerator vorgestellt. Der macht guten
Zufall.
Ein Quellenangabe würde nicht schaden. Der Code stammt aus "Numerical Recipes in C: The Art of Scientific Computing" und ist der “Minimal" Random Generator von Park und Miller. In dem Buch gibt es übrigens noch mehr davon.
hatte ich mal nen Zufallszahlengenerator vorgestellt. Der macht guten
Zufall.
Ein Quellenangabe würde nicht schaden. Der Code stammt aus "Numerical
Recipes in C: The Art of Scientific Computing" und ist der “Minimal"
Random Generator von Park und Miller. In dem Buch gibt es übrigens noch
mehr davon.
Stimmt, danke für den Hinweis. Der post von mir ist von 2006 oder so, ich hatte vergessen woher ich den hatte, damals hatte ich die Quelle aber auch nicht genannt. Ich will mich auf keinen Fall mit fremden Federn schmücken. Ich benötige aber auch keinen akakdemischen oder sonst irgendeinen Schmuck mehr.
Zähle doch einfach beim Reset eine Variable im EEPROM hoch und verwende
deren Wert als "random seed".
Die beste Antwort wird wieder mal ignoriert. Das ist die Lösung für das Problem von Harry. Er will nicht, dass jedesmal die gleiche Abfolge erscheint.
Wenn die Pseudozufallszahlengeneratoren (PRNG), die hinter den üblichen Funktionen random, randomize, etc. der Programmiersprachen liegen, mit unterschiedlichen Startwerten gefüttert werden, erzeugen sie komplett unterschiedliche Folgen. (Das ist ihr eigentlicher Job für z.B. Kryptographie).
Wenn ich also einen einfachen Zähler im EEPROM jedes mal erhöhe und ihn als Startwert nehme, dann kommt jedesmal eine komplett andere Folge raus, Auch wenn diese Startwerte dann 0,1,2,3,4,5,... sind. Und das ist ja, was Harry will oder? Da benötigen wir doch keinen ADC der irgendeinen Mikrofonoutput misst.
Nicht ganz, denn da das ein Lichteffekt ist/sein soll, müßte ich bei jedem Durchlauf einen neuen Wert übergeben. Wie lange wird das bei einem Word 0..65535 wohl reichen, wenn die Schaltung auch mal 4...5h am Stück läuft und für jeden Displayaufbau 5s benötigt? Von der Lebensdauer des EEPROMs mal ganz zu schweigen. Aber das bringt mich auf eine andere Idee: Startwert 1, Bild, Startwert 2, Bild, ... usw.
Probier ich mal aus :-)
falls kein TRNG auf dem µC vorhanden ist oder die implementierung nicht vorhanden/man zu faul ist:
wähle einen initialen seed der größe x bytes (bspw. bei AES-128 wären es 16 byte, bei SHA256 wären 8 bis 32 byte in ordnung)
berechne einen cipher/hash des seeds (da reicht ein AES-128 oder jegliche art von hash-funktion) -> output ist eine random number mit x bytes (bspw. bei AES-128 sinds 16 byte, bei SHA256 dann 32 byte)
setze einen neuen seed aus dem initialen seed (aus 1.) und der zuletzt generierten random number (aus 2.) zusammen (bspw. die ersten 8 bytes aus initial seed + die ersten 8 bytes aus der random number)
wiederhole die schritte 2. und 3. nach bedarf
damit kann man sogar die üblichen random number test-suites bestehen ...
Nicht ganz, denn da das ein Lichteffekt ist/sein soll, müßte ich bei
jedem Durchlauf einen neuen Wert übergeben. Wie lange wird das bei einem
Word 0..65535 wohl reichen, wenn die Schaltung auch mal 4...5h am Stück
wenn ich dich richtig verstanden habe, geht das: ist der Generator erst mal gestartet, liefert er bei jedem Zugriff eine "andere" Zufallszahl. Das kannst Du je nach Länge der Periode des Generators sehr sehr oft machen, bis sich die Zahlen wiederholen. Also beim Programmstart den Generator einmal initialisieren, und dann einfach immer neue Zahlen anfordern. Der Generator kann dann durchlaufen bis das Gerät ausgeschaltet wird.
Du könntest auch den vorgeschlagenen Zähler nehmen und während des Programmlaufs an den gewünschten Stellen mit (Zähler * n) den Generator wieder neu initialisieren.
Oder Du initialisierst den Generator an den gewünschten Stellen mit dem letzten generierten Zufallswert.
Das ist dann zwar bezogen auf den Startwert auch wieder deterministisch, aber du bekommst "für jedes Spiel" andere Zahlen, auch wenn Du das Gerät nicht ausschaltest.
Oder Du initialisierst den Generator an den gewünschten Stellen mit dem
letzten generierten Zufallswert.
Ob man beim Start des Controllers einen inkrementierten Zähler im EEPROM als Seed verwendet, oder den Seed im EEPROM durch die erste daraus abgeleitete Zufallszahl ersetzt, ist bei nicht zu bescheuertem PRNG das gleiche Prinzip. Sowohl was das Erlebnis angeht, als auch in der Anzahl Schreibzyklen. Auch die jeweils letzte als Seed zu verwenden ändert daran wenig, geht aber auf die Schreibzyklen.
Kryptografische Sicherheit würde ich daraus nicht ableiten, aber für die LEDs braucht man die nicht. Es reicht ja, wenn es sich nicht offensichtlich von Anfang an wiederholt.
