-
I'm working on an idea for a gift based on a small LED matrix necklace. I'd like to randomly change the image on it, and at first thought about some kind of switch that is very sensitive to motion but then thought what about leaving an input pin floating but tied to a part of the necklace that touches bare skin?
It will most likely be based on an ATTiny 2313V or 4313 and powered by a CR2032 battery.
What do you think? Leave a pin floating and use it tied to an interrupt? Or use an analog input that is sampled every so often to grab a number that will control the period of time each image is displayed?
And I understand that I could just as easily have it generate random numbers internally, but I want to have it interactive in some way. -
Just sample any pin, Vcc, Vref, a floating pin, or ground pin, etc., literally any pin.
Take the LSB and use a series of LSBs from consecutive sampling to form a random number of desirable width.
-
Use the ADC with a few mm of trace on it. Floating input pins will eventually charge to a fixed level.
-
Bad idea - floating input pins are a bad idea all around - they can actually increase your power consumption. Also, ESD - tying a pin into a neklace, well SOME protection should be there.
For randomness you should use an ADC noise (which the 2313 does not have), but it does have a comparator - you might use that somehow. -
The random number functions tend to be a bit crap for things you want to "look" random. They're more of a mathematically random system.
A way i found to work well is to fill the eeprom up with the kind of random number you're after. Leave one byte free and have this increment every time the mcu starts.
Use this number as the starting address to begin reading the eeprom.
You can add more complexity, such as having multiple index bytes which are used in sequence if you feel this one byte may exceed its 100,000 writes in normal operation . (eg, if you're using watchdog, brownout).
If you want it to have some actual randomness you can use the comparator noise to set the starting position instead of having a byte incremented. -
For randomness you should use an ADC noise
If you mean the lsb of an adc with any input then this is not very random at all (tested this and they are very predictable so even the samplerate is important here) but might be good enough for this application.
If you mean that the inputsignal for the ADC has random properties this could be used over time as a source of entropy.
-
Lot of years ago, I was playing with binary counters and 555s (It wasback in highscool). I left a pin floating. I was perfectly able to pick up 50 Hz (60 for you) in the walls from 20cm distance wit a generic 74 logic gate and 5cm wire, so it was not random anymore.
I would rather make a ring oscillator and sample that. http://nandblog.com/ring-oscillator-time/ or amplify thermal noise, or combination of the ideas given here. Be sure to check it against http://tools.ietf.org/html/rfc4086, so they cannot crack the toy
-
Yes, sampling a fast oscillator not locked to your own (preferably with lots of phase noise) can work well. Make sure you don't accidentally make an injection-locked oscillator out of your main clock though!
You can also use a reverse-biased B-E junction as a noise diode, though you'll need at least 7V or so. I have done that for a similar (but all-analog) blinky-LED doohickey and it works pretty well. -
Quote
If you mean the lsb of an adc with any input then this is not very random at all (tested this and they are very predictable so even the samplerate is important here)
Other than the stock Arduino adc (analogRead()) that is incorrectly implemented, I have yet to say a properly implemented adc not generating sufficiently random data.
The most common mistake is too fast adc that yields some banding - the tendency for the output data to be in certain bands.
The approach essentially depends on the notion that an adc has some inherent randomness - typically the lsb is not stable in the last few lsbs. -
The approach essentially depends on the notion that an adc has some inherent randomness - typically the lsb is not stable in the last few lsbs.
That is something I researched and tested, I needed entropy for a cryptographically secure random generator. This is ofcourse the most demanding application for randomness.
The thought that the lsb of the adc was random was tested with multiple sampling rates and different kind of input signals and unfortunately found to be not good enough for this purpose (tested with the diehard testsuite, it failed miserably).
The floating base of a normal transistor and some form of amplification of that noise signal as input to an adc was pretty good (schematics can be found on the net and were posted somewhere on this forum also not so long ago) but still very easy to manipulate with an outside signal. -
Use a forward biased LED and AC couple it to the ADC with a lot of gain and you will have a lot of noise along with randomness from the ambient light as well.
-
Quote
The thought that the lsb of the adc was random was tested with multiple sampling rates and different kind of input signals and unfortunately found to be not good enough for this purpose (tested with the diehard testsuite, it failed miserably).
There are many reasons that an approach could fail. The fact that it failed doesn't by itself mean that the approach is fundamentally flawed.
If you post your code, schematic and data obtained, I am happy to help you - cannot assure that it will pass any test per se.
The same approach actually does not require a pin to float - you can adc a grounded pin, or a pin connected to an internal source (Vcc or Vref for example). It also works better with higher resolution adc modules (12-bit vs. 10-bit for example).
-
There are many reasons that an approach could fail. The fact that it failed doesn't by itself mean that the approach is fundamentally flawed.
As I said I researched it quite a bit and know what can be done there and what not and it is very tricky with a lot of pitholes if you don't test the result. In my company they used a certain algorithm also based on adc noise for years but actually testing it with for instance diehard is quite an eyeopener, it needs 80MB of the generated data to start with and then it keeps on searching for repeating patterns, and it finds enough.
If you post your code, schematic and data obtained, I am happy to help you - cannot assure that it will pass any test per se.
The same approach actually does not require a pin to float - you can adc a grounded pin, or a pin connected to an internal source (Vcc or Vref for example). It also works better with higher resolution adc modules (12-bit vs. 10-bit for example).
If you don't need it for a cryptographically secure application it probably will be good enough. If you ever have time, generate 80MB of data from your adc lsb with whatever input you like and run it past the diehard testsuite
-
BTW there is a difference between statistically randomness and secure randomness,
James Reed has stated this beautifully in an 1977 article called "cracking a random number generator":Quote-The usual statistical standards, states that a sequence of numbers, that cannot be discriminated from a sequence of independent uniform deviates from the
unit interval, is considered random. PRNGs that are acceptable by these standards are suitable for simulations, games, and similar applications.
-The cryptography standards have to do with predictability. It is less important whether the sequence is uniformly distributed, but it is essential that knowing part of the sequence does not contribute any knowledge about other parts. This requirement is called unpredictability. -
Quote
it needs 80MB of the generated data...
Again, it is hard to discuss in the abstract. and you certainly don't need 80MB to share the code, schematic or data or your results - being there and done that.
I am happy to help, again.
-
Once I get the matrices from Jameco, I will start working on the software. I think the code will be a tight fit but doable.
I've got about 21 patterns that fit in the 5x7 space.
-
For that, a simple pseudo random variable will work: smaller footprint, and faster execution.
Randomness is over-rated.
-
For that, a simple pseudo random variable will work: smaller footprint, and faster execution.
Randomness is over-rated.
Well I wanted to hopefully add some level of interactiveness to it. I guess I'll see how the code goes when I get into it.
-
And I understand that I could just as easily have it generate random numbers internally, but I want to have it interactive in some way.
I completely missed this line.
Generate random numbers internally, and then bias them with a deterministic measurement? -
And I understand that I could just as easily have it generate random numbers internally, but I want to have it interactive in some way.
I completely missed this line.
Generate random numbers internally, and then bias them with a deterministic measurement?
Well whatever I do all has to fit in the 2k flash space / 512 bytes of RAM. I figured asking it to do random numbers would take up more flash. -
Not much flash at all, if you code efficiently. A Mersenne twister would use a lot of RAM, though, but this algorithm is very small.
-
Not much flash at all, if you code efficiently. A Mersenne twister would use a lot of RAM, though, but this algorithm is very small.
Well now that I think about I need it to erase hard drives and display images. -
You can use the ADC as a random source, as dannyf says, but no matter what, the entropy generated from sampling the ADC will have bias. Thus it's not truly random, and will fail tests for randomness, such as the Diehard tests, as Kjelt says. It can likely be used as is for games, blinky lights and what not.
The random sampled data from the ADC can be whitened with a small LFSR, a TGFSR, a huffman compression, a CRC calculation, or a pass through a tiny Mersenne twister. In a much more simpler way, suitable for a small micro in software, you can examine the bits two at a time and output 1 bit ala Von Neumann: "1,0" -> 1 , "0,1" -> 0 , ("00"|"11")->discard. You can also take the sampled output from two ADCs and XOR them together to get 1 bit stream.
Any of those methods would make it statistically more random, but not necessarily cryptographically random. Clearly Stonent doesn't need cryptographic randomness
-
Any of those methods would make it statistically more random, but not necessarily cryptographically random. Clearly Stonent doesn't need cryptographic randomness
I would call it interactive randomness. Maybe where if the ADC is completely free air that the changing of images slows down significantly but if the input pin picks up something from the necklace making skin contact intermittently that it makes it more likely to change the image. The circuit that I'm going to be basing this on was originally designed to use a push button to change to the next image. Maybe I'll try to find a really small SPST switch that pulls the pin low and makes the images only cycle maybe once ever 10 or 15 seconds but if left open it starts changing more with activity.
Or even forego the switch and come up with some kind of part of the necklace like a clasp or something that depending on its position it changes the behavior. -
You could add a SPI/I2C temp sensor to your micro, that would give you some unpredictability you could use.
Especially if the sensor could do 0.1 deg C resolution