how to create Random Number Generator without using Microcontroller? - Page 1
Forum section: electronics / projects

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 14, 2014, 11:36:17 pm
content: I would like to create a very simple Random Number Generator circuit of some kind, without using a Microcontroller, and without writing any code.Is there a single integrated circuit, or a combination of a few, that can do this?I have done some preliminary searching and have not found such a critter yet. I would like to stick with plain jane through hole plastic (or ceramic) PDIP packages. No SMD.This will not be used for crytography, and in fact will be used for an extremely pedestrian purpose. It does NOT need to be an extremely Random source. Using a plain-jane Seed of some kind would be fine. Even some kind of chip that could somehow create a bunch of"psuedo random" noise, or a whole bunch of various voltage levels that change with time, that I could tap off of.To be specific, I am thinking abourt creating a grid of led's of various types, very very small ones, and string it across my bedroom ceiling. I am thinking there might be something like 50 to 100 led's eventually, but I would start off with something simpler in the beginning, maybe 10 or 20, to get my feet wet, and learn the simple basics of such a circuit.They don't even have to be led's, I'm just thinking they would be simpler to work with than other types of bulbs.The idea is to simulate a "planetarium". To have say 50 to a couple hundred tiny lights connected to a large (perhaps 8 feet square or larger) grid of wires, and to have some kind of circuit that would turn various lights on and off at "relatively" random intervals. Trying to simulate a clear night sky that has shooting stars, blinking lights, satellites, meteors, "solid stars"-meaning on all the time), all that sort of thing.I think it would be very cool, and possibly even relaxing, to have a ceiling full of twinkling lights, that would look somewhat like a "night sky". After the functioning circuit and grid of lights and wires were in place, I would use something to "mask" it all, like a thin black cloth, and have just the led's or bulbs exposed.So, has anybody 'round here ever done such a thing, or can anybody recommend some kind of simple circuit that can generate a series of "psuedo-random" numbers, or voltage values, that I could use as the primary "generator"?I don't want to use a microcontroller. I have found a number of micro's that can generate RN's, but that is way too complicated for me. I've never used a micro, so it would be overkill, and would take about a hundred times more time to learn than I want to put into this.I don't want to learn coding, or how to write code. Maybe sometime, but not for this.I want this to be cheap. I am comfortable spending maybe $20 on passives, chips, and transistors, plus the costs of the led's and necessary wiring. But I don't want to spend $40 on an Arduino and have to learn how to use THAT.I am thinking something that could generate psuedo random voltage levels would be enough to start with, as the input to the circuit, and then use transistors, various base currents, various RC circuits, maybe even a 555 timer (or more than one), maybe some comparators, etc. Maybe even some kind of "electrical noise generator", that I could use with some kind of simple "sampling circuit", that would periodically look at the values of the "noise" and then transform that somehow.I would need some way to control the very general "timing". In other words, I would need to be able to adjust some commponents (ideally potentiometers or variable capacitors), or even fixed valuue passives, to put the timing in the general proper range.Anybody have any ideas?THANKS to the whole EEVBLOG community, and to Dave for all he does for us "new players".-Doug_in_MinnesotaJune 14-2014

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 14, 2014, 11:59:38 pm
content: I should have done a search of the forums first, before psting, I just didn't think of it.I have found a few threads that come very close to answering my question.For example, this one looks pretty close (maybe EXACTLY close):https://www.eevblog.com/forum/projects/self-flashing-leds/Here are some other threads that I am going to look through to get ideas:https://www.eevblog.com/forum/projects/lm565-lm567-questions/msg432504/#msg432504https://www.eevblog.com/forum/projects/555-random-number-generator/msg408811/#msg408811https://www.eevblog.com/forum/projects/tlc59405941-default-initialisation/msg451529/#msg451529And that is just from the First page of Search results.So I will start going through all those ideas.Sorry I didn't think of this before writing my original post. I will up-date if I get to the point of finding a circuit, or some good circuit ideas, that look like they will work for me.THANKS EVERYBODYDoug

author: rob77
author_rank: Super Contributor
timestamp: June 15, 2014, 12:04:26 am
content: zener diodes are quite noisy (avalanche breakdown) , or you can use a reverse biased PN junction of a transitsor - amplify the noise and use an ADC to convert it to random numbers.and good luck with your plan to go without a microyou will end up with with a HUGE circuit without a micro.you can buy a Chinese arduino nano clone under 10$ on e-bay or DX - you got everything you need for your project on that litle board - except the noise generator ( you can find a schematic on the net for zener noise generator).

author: dannyf
author_rank: Super Contributor
timestamp: June 15, 2014, 12:21:50 am
content: QuoteA few options:1) an rc oscillator has very high phase noise. So you can use either two rc oscillators to gate each other, or one crystal oscillator to gate a rc oscillator; Make sure that their frequencies are sufficiently different (10x or more would work). An IC like 4060 would work for example - for both serial or parallel output;2) a timer / counter latched by another noisy oscillator can work as well. Good for parallel output;3) delta-sigma adc: a flip-flop, a couple resistor + a capacitor is all you need. Good for serial output.4) ring oscillators: built with rc oscillators (a bunch of 555 for example)....

author: mariush
author_rank: Super Contributor
timestamp: June 15, 2014, 12:39:21 am
content: You could try to take advantage of how some components change their behavior with temperature. For example, you could use resistors with high temperature coefficient with a 555 timer to get an output from 555 that will change as the resistor heats up or cools down.Honestly, it would be cheaper to use a microcontroller. You don't need microcontrollers with random generators, you can do some pseudo random generator in a few lines of C. There's even ready made functions ... for example XC8 compiler for Microchip PICs has built in rand() function which returns a pseudo-random number between 0 and 32767 every time it runs.. you can use that to determine time a led stays on or off.A 8pin DIP microcontroller is around 50 cents (pic12f1571) and can control about 3-4 leds at same time each blinking at random intervals (. Your problem is just that the programmer costs a bit of cash...20-50 dollars, depending of who makes the chip (atmel/arduino/attiny or microchip/pic etc)AVR chips (attiny 13) are a bit more expensive at about 1$ each, but programmer is cheaper.

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 15, 2014, 02:35:31 am
content: Well, first off, Thanks to those who have already answered my question.In only a couple hours, there are already several answers.I particularly like the answer from Mariush.With that said, it seems I have bitten off WAY more than I can chew. I had thought this would be so very simple to do, but it's not, I realize that now.I have searched the Net, and found many different ways of creating a random number generator circuit.Some use digital techniques, some use PN junction noise of various types (Zener noise, shot noise, Josephson junction noise,and several others). Others use combinations of several transistors and diodes and RC timing loops, etc. And some use op-amps with other incidental components.And quite a few use microcontrollers.I've read as much as my mind can accomodate in one evening, and I have come to the conclusion that my original idea is an OK idea (the virtual planetarium), but actually making it happen is generally VERY complicated (by my standards).I don't understand a word of dannyj's answer, WAY beyond my level of knowledge.Some of the solutions I have found put out a stream of bits (kind of random bits, I think in a "serial" way). Others will output a constantly varying "voltage", which is pretty much what I thought I wanted. But the complexity (not the cost) is beyond what I think I can put into this project.THEN, after all the reading, and reading the replys that have come to this post already, I realize that creating the "random signal" is only a tiny part of what the project would be.The issue that arises is: So I have a randomly varying voltage signal, now what do I do with it?In other words, the first box in a long Block Diagram of circuit function would be "Create random voltage" (or Serial string). The LAST box would be: "hook up your 50 led's to these 50 pins on your breadboard". And then in between there would be god only knows how many OTHER Blocks.There would have to be a function to sample the voltage, and then somehow feed that into whatever Block would turn it into something that could amplify and route a voltage (or current) to 50 or a hundred different led's. I can see now that using a microcontroller is probably the only practical way to do that.I can also see that using a micro would mean the Random Generator circuitry would be unnecessary, it could be done in code inside the micro (I've done this before in Excel).I know enough about led's to get an array of them driven. But how to sync or trigger whatever would drive them, from the "random voltage" source, is about 100 times more than I can understand.SO, for the moment, I think I am going to abandon this project. I think that from my reading, and from the Reply's from Mariush and rob77 and others above, that using a microcontroller would be pretty much required. So I will take that as my lesson from having looked into this.So I'll add this project to one of several for far out in the future after I have learned to work with microcontrollers (which is something I DO want to do EVENTUALLY).I guess I would not mind the cost of a micro (I guess they are available for just a few dollars, I didn't realize that). But as was mentioned above, the Programmer costs money.I have no problem with buying a programmer, (I assume something like a PicAxe would be enough for a beginner), it is just not something I want to do right now. I could probably afford the programmer, I am just not at a place right now where I want to start studying microcontrollers.The thought of learning about microcontrollers, and then learning about how to program them, and then learning enough about coding to use them constructively, leaves me feeling this would take 100's of hours, which I don't want to put into this.I thank everybody who took time to answer.THANKS EVERYBODYAnd by the way, if we are all sitting around reading EEV Forums on a Saturday night, I think we ALL need to get a life!-Doug

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 15, 2014, 03:02:16 am
content: Hmm, driving an array of LEDs will be as much hardware as anything anyway, so it needn't be terrible to do in raw logic. The main downside to something embedded (MCU / FPGA) is the number of output pins. You don't need much guts, just IO.What you're looking for is an LFSR (linear feedback shift register). Take a few shift registers (e.g. 74HC164), chained together, and some XOR gates. Look up the tap points for the register bit length (the combinations for maximal length series have long ago been elucidated and tabulated) and put it together. Clock everything with, say, a 555, or just make an RC oscillator with some extra XORs (I want to say, up to at least 24 bits, there are sequences that only need one or two XORs, so you'll have plenty of extras if you use a full quad of them).As for the LEDs, if you hook them to the shift register bits, each individual LED will be pseudorandom, but the same sequence, shifting around. From moment to moment, the pattern of LEDs lit or inactive will be pseudorandom, but the shifting from cycle to cycle, LED to LED, will probably be perceptible and repetitive. If you can arrange the LEDs spatially random, that'll help break it up, but still.So, further, I would suggest using several independent generators, perhaps using different sequences, and slightly different frequencies. Spread the LEDs around as best you can, don't leave them in groups.You can even use the output of one to gate the output of another, which will give an uneven stepiness to the update rate, which might be handy. At that point you're kinda-sorta looking at having enough logic to use a CPLD or FPGA, or just write it out in software.For getting fancier, you might consider adding some filtering (so the LEDs fade in and out rather than switching suddenly), which needs an additional LED driver, say a 2N3904 with an RC filter. Simple, but every little bit adds up if you're doing tens or hundreds at a time. Don't forget to use different resistors for different LEDs, otherwise it'll all be the same intensity.You could also wire a few bits together, with different resistors as a crude DAC, so the LEDs randomly light to different intensities.Or a few periodic ones, right off an oscillator, like as pulsars or whatever.Tim

author: rob77
author_rank: Super Contributor
timestamp: June 15, 2014, 06:25:08 am
content: number of output pins is not an issue - you can multiplex. there are examples on the web how to drive 8x8 led matrix (64 LEDs) with a micro.and using an arduino board is well within your capabilities. if you're able to search on google and you understand basic electronics (you do understand according to your posts) then you will be able to learn the arduino stuff in extremely short time - it's a matter of hoursdon't be afraid of the Chinese arduino clones - they work exactly the same way, no issues with the software or example projects. arduno is open source with all manufacturing details - so anyone can manufacture and sell those and actually the Chinese companies are able to sell them below 10$

author: Stonent
author_rank: Super Contributor
timestamp: June 15, 2014, 07:27:15 am
content: I saw a video recently where someone drove a shift register from a 555 timer and when his hand approached it, it would change. He then added a wire to DS and it would start picking up a clock. I suppose it was getting a 60HZ hum or something.

author: motocoder
author_rank: Unknown
timestamp: June 15, 2014, 08:08:08 am
content: LFSR counterhttp://www.fpga4fun.com/Counters3.html

author: Psi
author_rank: Super Contributor
timestamp: June 15, 2014, 09:49:23 am
content: QuoteI did something very similar to this, made a MCU drive a 8x4 array of leds and psudo randomly flash them on/off slowly.It was for a cityscape painting my sister did. We picked 32 random windows in a few buildings in the painting and put one of the leds behind each.When it ran it made a nice cityscape where random rooms in each building would illuminate on/off (as if people were in the offices buildings).Even coded a little switch-on flicker, to make it seem like a fluorescent tube starting (for added realism).I just generated some random data on the PC and pre-programmed it once into the mcu's EEPROM memory. The code just steps through that.

author: dannyf
author_rank: Super Contributor
timestamp: June 15, 2014, 10:07:50 am
content: QuoteAny of the ideals above could be easily implemented - they are a child's play so to speak.Here is one utilizing a rc oscillator + two shift registers. You can easily expand it to drive more digits. The pattern is entirely random, but auto-correlated - which if desired can be eliminated easily.You can also drive it via a mcu - the basic concept is the same.

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 16, 2014, 05:01:09 am
content: It was the best of times, it was the worst of times.............I'm going to pluck a few quotes here, from various people who have put up replie's on this subject.First, thanks to everybody for all the ideas. That's what is really cool here, to have 10 different people come up with 10 ways to do this. Awesome, as Dave might say......Just for clarity for everybody.....My understanding of electronics is what I would call "moderate" to "intermediate". I know DC and AC theory, I can fake it with op-amps and transistors if I have to, and I understand resistance, reactance, impedance, capacitance and inductance, transformers, diodes, and most other passive components. I've done a fair amount of breadboarding.I have NEVER touched (well OK, I've touched, but never used) a digital chip in my life. I have a vague Idea how gates work, and if I spent 5 or 10 hours reading I could probably have a very good idea how they work.I have a pretty good home lab, with a 60 Mhz B+K analog scope, a couple generators and counters, lots of meters, PSU's, etc. I have a large parts inventory, in the analog world. I am about to place a Digi-Key order (for some other stuff, including bags of LED's), so I could certainly add in a handful of digital chips.So, onward to the quotes, with my comments...from danny;"Any of the ideals above could be easily implemented - they are a child's play so to speak."uh, OK, if you say so. One persons childs play is another persons nightmare...continuing...."Here is one utilizing a rc oscillator + two shift registers. You can easily expand it to drive more digits. The pattern is entirely random, but auto-correlated - which if desired can be eliminated easily.You can also drive it via a mcu - the basic concept is the same."I can actually understand these paragraphs, excluding the "two shift registers" part. I assume a Shift Register is sort of how a base 10 (or base 2) numbering system is implemented in digital logic, kind of like "count to 10 then move one column to the left" (or right)?from Psi:"I did something very similar to this, made a MCU drive a 8x4 array of leds and psudo randomly flash them on/off slowly.It was for a cityscape painting my sister did. We picked 32 random windows in a few buildings in the painting and put one of the leds behind each.When it ran it made a nice cityscape where random rooms in each building would illuminate on/off (as if people were in the offices buildings).Even coded a little switch-on flicker, to make it seem like a fluorescent tube starting (for added realism).I just generated some random data on the PC and pre-programmed it once into the mcu's EEPROM memory. The code just steps through that."ah hem.......I was hanging in there right up until the "pre-programmed it once into the mcu's EEPROM memory. The code just steps through that" part. I like the ideas you put forth here. Yes, it sounds like you did almost exactly what I want to do, (VERY cool) except I don't know anything about how "multiplexing" led's would be done. My knowledge of led's extends to "put 50 resistors in series with 50 led's, feed'em all two volts, and you're home". I have even used a LM3914 driver chip, which is a cool and useful chip.But I would have to study a LOT to figure out how to drive 50 led's with less than 50 wires. How do "address" the different led's?I like the point about using different resistors, to get varying intensities. Also, I like the idea mentioned in an earlier post, which said to "spread out" the led's amd overlay different groups. to minimize similarities. Good ideal simple to implement. I also like the idea of using various RC loops to vary the on/off decay.motocoder:I looked at the link. Uh, it's over me head, at least initially.Everybody-Don't get me wrong, I could learn any of this stuff, given enough time. I truly appreciate all the guidance. I have no opposition to learning, it's what I'm in this for. I'm just afraid of getting into some kind of "down the rabbit hole" scenario which takes me until next Christmas to get half way through, only to get so frustated I throw the cat through the window (if I had a cat).Stonent said:I saw a video recently where someone drove a shift register from a 555 timer and when his hand approached it, it would change. He then added a wire to DS and it would start picking up a clock. I suppose it was getting a 60HZ hum or something.What is "DS"?rob,Your comments are encouraging. I have no problem buying true original Arduino hardware. I want to support the original guys, no need to look for clones to save 50% of $40.I have done some simple "coding". I've written quite a bit of "code" in Excel, a little Visual Basic, I've written raw HTML, so I'm not totally unfamiliar with the ideas. I have NO experience with C, C++, or any of the other "real" languages.I guess I don't understand the basics (no pun) of the "routine" of working with an Arduino or microcontroller, and the relationship to software.Is it something like this?1. Hook the Arduino board up to the USB on the PC.OR2. Use a PicAxe or something similar to interface some kind of PIC chip to the computer3. Open a text editor or some kind of "free" "environment" to "write" the code4. Somehow "download" the code from the PC "onto" the chip5. Hook up the chip or the microcontroller to the hardware you want to work with (I assume it just takes some proper Power connections) such as the led's, etc to the output pins of the microcontroller or the Arduino6. start screwing around to see how things work, and then re-iterate over and over until you get something that looks like it's almost working?Am I even in the ballpark here? Or am I way out in the weeds?T3sl4co1l;I see that the 74HC164 is only 35 cents at Jameco, probably cheaper at Digikey, so I could buy a whole bag of those, blow half of them up, and still have enough to do the project.It is starting to look to me like I have basically two general directions to go, to make a project like this happen in the real world. I'm apparently going to have to either;Learn about digital logicORlearn about microcontrollersor some combination of both.Whew, I had no idea what I was biting off. Although the lure of the end result does still intrigue me..........I'd like to have a lady friend over for the first time and lay on the bed looking at the ceiling....When I was in Electronics School (around 1981) they had a whole QUARTER on Digital (I did not get that far). So if I did try to do any digital, I would be starting from page one, read a few chapters, put some digital chips on the breadboard, break out the scope, and start trying to create some (relatively) slow clock speed signals. And then go from there. Do you all think I could start from such a place, and get to the points that people mention above, without 100 hours of study?Also, can microcontrollers or shift registers put out enough current per line to drive led's directly, say 10mA? Or do I need some kind of current amplifier circuitry?THANK YOU EVERYBODY-doug

author: Paul Moir
author_rank: Frequent Contributor
timestamp: June 16, 2014, 05:14:31 am
content: Yes, the 74HCxxx chips will handle 25ma going into them or coming out. Many MCUs these days will handle that or more. The last one I used could do 40ma in or out of any and all pins. Amazing days we're living in!The old 74LSxxx chips could only put out about 0.5ma and take in about 8ma, so you normally ran power through your LED and back into them (turning the output LOW to turn your LED on). The old fogey's story is, the letters matter!

author: rob77
author_rank: Super Contributor
timestamp: June 16, 2014, 08:56:53 am
content: the arduino would be ideal for you to make the first step into the MCU world.and it's really about hooking up the usb cable and start the arduino software on your PC. the software is very simple and comes with several demo sketches (they call projects "sketches"). so it's a matter of hours till you start writing your own code.arduino is coming with libraries for everything - no need to study the MCU datasheet to figure out how to initialize the output pins, or how to generate a PWM signal... arduino encapsulated all the low level MCU specific stuff into libraries.so it's pretty similar to coding in visualbasic & excellonce you make a giant leap forward and the speed of the arduino libraries is not sufficient for you anymore - then you can start coding low-level in C or AVR assembly - squeezing out the maximum performance out of the atmega - but still using the arduino boards.you might also check out PIC , but i'm not familiar with those - but i know they're making lot's of MCU models which are more application specific (e.g. why to use ATmega full of features (and use only 20% of them) if there is PIC which has exactly what you need for half the price ? for hobby projects it doesn't matter , but for higher volume production it does

author: Psi
author_rank: Super Contributor
timestamp: June 16, 2014, 10:46:49 am
content: Quote from: Doug_in_Minnesota on June 16, 2014, 05:01:09 amMCUs have different ways to store information. Data in the EEPROM memory is preserved even when power is lost. So instead of generating random numbers on the MCU as needed i instead stored 100 random numbers in EEPROM memory. That way it's easy/fast to code. You simply tell the MCU to use the number stored at EEPROM location 1, then location 2 etc..You dont need to use multiplexing, i only used it so i could have more LEDs than the MCU had outputs. You can go the simple way with each MCU output connected to 1 LED through a resistor if you want.

author: mariush
author_rank: Super Contributor
timestamp: June 16, 2014, 11:32:26 am
content: If you go with PIC microcontrollers, you have MPLAB X (the editor) and XC8 (the C compiler, which converts code you write in the editor in the binary the microcontroller understands) on Microchip's website .. these are free. The only thing you would have to pay for is a PicKit 3 which is the programmer for the chips:http://www.digikey.com/product-detail/en/PG164130/PG164130-ND/2171224It connects to the PC through USB, you select the programmer in the MPLAB X editor and when you're done writing a program, you simply click on a button to write the code to the microcontroller.There's only 5 wires and a resistor required to connect the programmer to the microcontroller and it's very easy to do it and once you programmed the chip, you can turn off the power, disconnect those wires and at the next time you power the microcontroller, the code you wrote can configure some of those pins that were used to program the chip as inputs or outputs.Arduino is cheaper because the boards come with a tiny program in the chips from the factory called firmware which never gets overwritten by you (unless you really want to). You have the free editor in which you can write sketches and then you click a button in the editor interface and the software on your computer restarts the arduino making that tiny firmware start and talk back and forth with the computer and takes the binary from the computer and saves it into the microcontroller memory and once it finishes, it runs that binary in the microcontroller.This makes everything nice and easy and saves people money by not having to buy a programmer. It's a great and simple way to learn the basics, how to write a program on a microcontroller, how to turn pins on or off, to set the as inputs or outputs and so on .. basically flashing a led is simply configuring a pin on output, sending digital 1s on that pin which means power is sent to the led and after a period you stop sending 1s to that pin to turn led off.However, when you buy an AtTiny13 or Atmega328 (or whatever is used by Arduino boards), they don't come with that firmware pre-written in the chip, so if you buy the "raw" chip and put it on a breadboard, you'll still need a programmer for it.As the Arduino is more popular, there are plenty of programmers for it, for example USBtinyISP is only 22$ (but you have to do some soldering):http://www.adafruit.com/products/46Here's a very good series of videos that explains a lot about Atmega32 and how to program them and shows some code with good explanations :https://www.youtube.com/playlist?list=PLE72E4CFE73BD1DE1If you can understand how to use that big chip, you can understand how to use those tinier AtTiny13 chips.Most microcontrollers can output about 20-25mA through a pin but the total amount of current through all pins varies. For example, a PIC mcu I worked with could do 25mA through each pin, but only about 120-200mA through all pins at one time.As leds generally can handle about 20mA continuously and up to about 100mA for a few ms every second, you could in theory connect leds directly on the pins and just allow 25mA to go through the LED and the current will be limited by the pin's maximum current. If you're worried about led burning up because it's more than 20mA, you can change the code to keep the led turned on 3ms, then turn it off for 1 ms, so basically the led with be turned on 75% of the time, then it has 25% time to cool down. As the led still turns on and off about 200 times a second, your eyes will still perceive the LED as always on, just at a slightly less bright compared to having it run 100% of the time.This trick is also used a lot even when you don't need it to limit current, simply to reduce brightness of the led or vary the brightness over time.Turning leds on/off can also be used with resistors. Let's say you have a 5v mcu and a 2v red led and you want 5mA going through it... with a resistor, you'd have to use a ~600 ohm resistor and you'd waste 15mW of power while the led is on. You could however use a resistor just to limit the current to the maximum the led can handle, about 20mA so you'd use a 150 ohm resistor and you'll have about 60mW of power wasted but you'd only turn on the led only 20% of the time and with 60mW/5 = 12mW you may get the same brightness as running the led all time at 5mA.-An EEPROM is just a slow memory inside the microcontroller (they're also available as separate chips), which is easier to read and especially write to by the microcontroller. You don't need an eeprom memory to store an array of numbers in the microcontroller, as long as the microcontroller has enough flash memory (where the binary is stored) you can enter those numbers in the source code of your program as an array of numbers. The compiler will convert that to binary and the numbers will be stored in the flash memory.

author: rob77
author_rank: Super Contributor
timestamp: June 16, 2014, 11:43:50 am
content: my further 2 cents - regrading MCU programmers...once you outgrown your arduino board - you can turn it into a MCU programmer device to flash raw MCUs. thre are sevaral opensource projects using arduino boards as a programmer for virtually any MCU (it's just a matter of bit-banging the particular flashing protocol).

author: eneuro
author_rank: Super Contributor
timestamp: June 16, 2014, 01:58:49 pm
content: Quote from: mariush on June 15, 2014, 12:39:21 amIn my TRNG project I use 4 ATTiny85 ADCs readings and XOR them to get 1 random bit on PB0 pin (I use Morse like 1 wire encoding of those random bits).This way I can connect whatever I want to my TRNG ATTiny85 3 ADCs - 4th additional ADC it is its internal temperature sensorI 'd like touse SS495A magnetic field Hall sensors as noise inputswith additional high current sources to create noisy external magnetic field when needed, however even using ADCs floating input pins readings gives nice outputsJust connected this 10kHz (10 kBits/second) TRNG prototypeto laptop microphone using simple microphone scope adaperand usingxscopenice noise is shown.Also recorded 1s sample at 44100 Hz rate, but only for test purposes and to hear output from this TRNG, whille higher resolution is needed to read Morse coded at 10 kHz PWM output signal.It is time to connect this TRNG using LPT pin or USB to PC, record more bits and do NIST tests for its randomness because sometimes something that looks noisy is not good for cryptographyIt will be interesting to see how good randomness I get from magnetic fields sensing in this TRNG and if it will pass NIST randomness tests described herehttp://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html

author: dannyf
author_rank: Super Contributor
timestamp: June 16, 2014, 02:39:40 pm
content: You cannot use the whole adv readings as they are highly co-related, your graph supports that as well.however, you can use just the lsb of the adc to construct a trng. The pin or adc channel can be connected, float, used or unused, internal or external,...

author: eneuro
author_rank: Super Contributor
timestamp: June 16, 2014, 08:32:48 pm
content: Quote from: dannyf on June 16, 2014, 02:39:40 pmI know and only ADC's LSB XOR'ed were used of courseQuoteThis graph does not mean I have bad TRNG, but this simple microphone scope interface was not designed for signals >1kHz while it has capacitor with RC constant close to 10kHz, so it simply integrate those Morse 1'es while its duty cycle is 2 times bigger than 0'es, and designed for average duty cycle 50% (mean microphone jack 3.5mm imput is about 250mV ).There each peak is close to 100us width as expected while we have 10kHz PWM and It was done rather to test response from this microphone scope interface to random Morse code input.To extract those random Morse encoded bits 100kHz-250kHz sample rate is needed and it is done in another optoisolated PC interface while I need to do NIST tests for randomness of this TRNG

author: dannyf
author_rank: Super Contributor
timestamp: June 16, 2014, 09:30:58 pm
content: Coding them doesn't add more information or randomness. You could use the four ADC to form four bits instead of one.the easiest way to output them would be to use uart.. On the PC, die hard or simple xy plot in excel would work.btw, if you use arduino ADC, it doesn't work.

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 17, 2014, 07:42:40 am
content: SO, I think I've made a decision. I think I am going to buy the necessary chips, programmer, memory, etc to start playing with the Arduino environment and hardware, or else do the same for the PIC world. I think I'll just bypass the path of buying and working with a whole pile of different kinds of digital chips.As Dave says in one of his first video's about Arduino (very humorous if you haven't seen it, but hey, nearly everything Dave does is humorous, that's why we love 'em) : "All I've been hearing about is bloody "Arduino this, Arduino that".I've been aware of the Arduino world for about a year and a half. Never gotten around to getting the stuff, although I've thought of it a number of times.So, I'll MAYBE go with the Arduio (Atmel), OR I might still go with the Pic world, not sure yet. Will have to give that a slight amount more thought.I DO know that there is this huge "ecosystem" of Arduino hardware, libraries, sketches, "Wiring" schematics, and a huge helpful world of enthusiasts who welcome helping people. So most of the questions I am likely to come up with have already been answered at some point. And if not, I'm sure somebody in that world will get me out of trouble.ALSO, I have been getting more and more aware of how miraculous the world of microcontrollers are, and all the opportunities they open up. For example, tonight I was watching Iain P. on YouTube do a tutorial on stepper motors with Arduino's. That is a cool world I could get deep into, trying to learn robotics, etc.Back when I went to school (about 1981, as mentioned previously) we didn't have microcontrollers, we had microPROCESSORS. And we thought that was the cat's whiskers....I think I am starting to understand that if I am working in a microcontroller world, I will still have to learn some basic digital concepts, but not as much digital as I would if I were sitting here with a huge pile of all different kinds of raw digital chips and trying to make stuff out of them. seems like the digital stuff is "cocooned" inside the Arduino, and that I only have to learn just as much as is necessary to make the digital parts of Arduino boards (shields) work.The only thing that gives me very slight pause is the whole "write code on the computer and then use that code to make something light up or make something move". I guess there is no way around that, and that this ability is really at the heart of the magic of a micro anyway, so I should think of it as opportunity, not as something to "overcome". I envision letting the magic smoke out of many chips, led's, resistors, mcu chips, and other components before getting my first "circuit" working. I guess that's the price of admission into the mcu world. I've certainly blown up my fair share of components in the analog world, including melting the primary wires of a large power transformer (car battery charger).Oh well. Besides--I damn near electrocuted myself on roughly 315 volts inside a computer power supply a couple weeks ago (that actually burned my skin, and left blisters, so in for an ounce, in for a pound, I guess they say). I think if I had been better grounded, I could be dead right now. Fortunately, I just got the volts across two sides of one hand, but that hurt like a mother.I'm really tired now, and need to go to sleep, but maybe tomorrow night I'll try to respond more directly to each of the second round of suggestions people have made here.Thanks everybody.-Doug

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 18, 2014, 12:05:50 am
content: How much of Ye Olde Dayes do you remember?You can still write out machine code if you prefer... but you probably don't...C is still around, just as it always has been. If you were doing embedded, you might've used assembler rather than C.If you remember much of microprocessors, you'll remember parallel address and data buses, address decoding, read/write strobes...All that is internal now, with all the timers and serial and parallel/GPIO (8255 style) and more already connected and integrated. You don't get an external bus anymore (except for a few chips that support legacy bus functions), so you actually have to work at it to drive bus style peripherals now (bit-banging GPIOs to generate bus and strobe signals, say, to write to your old fashioned DAC0080 or whatever).The Arduino toolkit is all C, but it looks a little different because of the preponderance of libraries performing functions, rather than poking registers by hand. You can still write ordinary C for the hardware without the libraries, as far as I know (read the datasheet for, well, everything). For that matter, you can write inline assembler too, but given the verbosity of the AVR's instruction set, and your slow application, I don't think that would be as good an idea for just starting out...If you find you don't like the Arduino toolkit, you can go to Atmel and get whatever the latest AVR Studio is, and see if you don't like it as well.Tim

author: rob77
author_rank: Super Contributor
timestamp: June 18, 2014, 01:51:51 am
content: it's definitely worth of starting with arduino - thanks to the wide ecosystem and community around - it's matter of hours to get up to speed.once you there you can start coding in plain C (without the arduino libs) or assembly using the arduino board - it's pretty comfortable.later if you will need more application specific micros - then jump into the PIC world.Atmel AVR => less MCU models , but bloated with features (almost doesn't matter which one to choose- just choose the one with enough IO pins and memory )PIC => lots of MCU models (really lots of them) better tailored for specific applications (you spend more time while choosing the specific PIC model, but you end up with a micro which fits perfectly your project)

author: mrflibble
author_rank: Super Contributor
timestamp: June 18, 2014, 02:18:28 am
content: The reverse biased transistor is pretty good if you want a "real" random process. If you can make do with pseudorandom, using a LFSR is fairly low cost in terms of resources. But you said no mcu, so maybe that option is a nogo. The lfsr is especially easy to implement if you happen to be using a cpld/fpga and need some pseudo random numbers.Or use a geiger counter, and time the pulses. Then do a time comparison between intervals to generate them bits. That also gets you good quality random bits, but it's going to be a low bitrate. Well, you can get a high bitrate but then you had better share some genes with D. radiodurans.

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 18, 2014, 02:38:49 am
content: mrfibble:Yes, in my very original post, and possibly in my 2nd one, I was emphasizing not using a MCU. However, that idea has changed, after reading all the answers and comments to my first post. I have decided (or realized) that learning how to use microcontrollers will be a valuable step in my education and hobby, and is really the best, fastest way to accomplish my goal. I did not realize the difficulties of doing my original project (driving some 50 odd led's in a psuedo random manner) until several people pointed them out. It was actually a fairly ignorant question, but all the people who have commented have helped me understand that it is more complicated than I may have originally assumed.So, as I pointed out about 4 post's above, I am now going to shift my focus, and buy the neccessary tools, to start learning about mcu's, whether that be Atmel with Arduino, or whether it be PIC with the various PIC development tools and free programming environments. I am torn between the two, but I'll work that out. I think I'll probably go the Arduino route, justy because there are SO many pieces of code, libraries, types of boards or "shields", and such a wide array of help available online. As Dave would say "every man and his dog" are using Arduino for something or other, and the number of things you can do with it are nearly unlimited.I think I'll skip the "geiger counter", but thanks anyway. And the pn junction noise is way more complicated than I need, and I don't need that level of "randomness". I think just the psuedorandom seed in the Arduino software will be more than good enough. I'm not building the Space Shuttle here, I just want to have a variety of led's on my ceiling blinking on and off (and a number of them which stay on all the time, like stars).Actually, I just realized something critical, which I had not considered before. Since what I really want, ultimately, is say 100 or so lights, but only about 20 to 40 of them that blink, or go on and off, for various periods of time, semi-randomly, I can actually just hardwire in the other 70 or so led's with series resistors. That can be a separate "large circuit", that stays static, and just has an on off switch for the whole damn thing, and then the whole array of lights that go on and off can be realized using the microcontroller!! Brilliant! That would lower the number of i/o pins I need dramatically.Thanks for your ideas.

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 18, 2014, 02:40:38 am
content: Tim,See my reply to mrfibble and robThanks

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 18, 2014, 02:56:14 am
content: mariush;Thank You VERY MUCH for your very detailed tutorial regarding Arduino and mcu's. Your comments are much appreciated, and I learned a huge amount from reading them. I am actually kind of EXCITED now, to get my first mcu package and start trying to learn how to use it! It probably won't be as hard as I am imaging.It's just that I look at all those connections on a typical Arduino board and I start thinking about writing software commands or functions to control them, and it looks a little scary. But, I'm reasonably intelligent, so I think I can figure it out.But I'll keep the fire extinguisher handy just in case.THANKS MUCH-Doug

author: mrflibble
author_rank: Super Contributor
timestamp: June 18, 2014, 03:27:32 am
content: Quote from: Doug_in_Minnesota on June 18, 2014, 02:38:49 amThe pn junction avalanche noise circuit is actually totally easy. But I can understand the "don't need it for this project" reasoning. Just remember it for later when you happen to need a "real" random source.QuoteSounds like a sensible choice.As for"That would lower the number of i/o pins I need dramatically."... I don't know what update rate you need, but if you happen to be running low on IO pins (or current capability) do not despair. If you have a low update rate for leds being ON/OFF you can also make use of shift registers like the 74HCT595 as a sort of cheapo IO expander. You could even PWM it using the output enable. It's not as good as some of the dedicated led driver chippies, but for simple led blinkies it will do the job just fine. Also, they are cheap and handy to have in the parts box.

author: SL4P
author_rank: Super Contributor
timestamp: June 18, 2014, 07:47:32 am
content: OK, my 2c worth - as simple as it can be.2x 8-bit shift registers chained together555 timer(1) as clock into both SR - gated by a second 555(2) to clock ~64 bits from 555(1)A high-impedance (CMOS?) input stage for first SR - to capture ambient electrical noise - perhaps filtered to remove mains and other dominant unwanted frequencies.Arrange the two SRs as an 8x8 matrix with LEDs at the 64 junctions with current limiting resistors (8x8=64)Done.The refresh/ update rate is set from 555(2) tick rate. (which pumps 64 bits of random noise into the registers with 555(1) clock rate)The pattern is arbitrarily set from the noise present at the SR data inputsCeiling can be overlaid with a simple grid of 8x8 tinned wires with LEDs at desired junctions (no shorts between X & Y please!It could be quite interesting with different noise densities during the day/ times of night etc.

author: eneuro
author_rank: Super Contributor
timestamp: June 18, 2014, 12:00:09 pm
content: Quote from: dannyf on June 16, 2014, 09:30:58 pmThis Morse bit encoding is not for adding randomness but for more reliable 1 wire bit transport onlyI prefere to connect to my PC computer/laptop external PCB's with microcontrolers onboard using galvanic isolation.I've pushed to the limits quite slow optoisolator PC817 with cut of around 80kHz, but as expected it did the job well as interface between uC output pin and LPT input under PC Linux @ sampling frequency around 140 kHz and 10 kHz PWM signal from ATTiny85 output pin.QuoteI've nice Morse encoded random bits received on PC Linux LPT input pin:QuoteAlso I was able to verify that this PWM is about 10 kHz from below sampling logs PWm signal period is about:QuoteusingQuotein my LPT PC Linux interfacelpt2bitsoftware:Morse1:QuoteMorse0:QuoteSo, even usual LPT with cheap optocoupler PC817 can be used as uC <-> PC interface and no strange uarts (additional hardware on PCB) needed in simple circuits with DIP8 ATTiny85 and I have about >5kV protection of my PC during those experiments with nice logs of uC output pins if needed for deep analysis

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 19, 2014, 01:39:41 am
content: Quote from: SL4P on June 18, 2014, 07:47:32 amAlright, seriously. I have a bone to pick here. Not with you specifically, but the general notion that "ohh well I can just wave this thing in the air and ... RANDOMNESS!!!111!!11!!".It ain't fucking gonna happen.It seems like there's this sense that, oh wellI don't knowwhat's going to happen, so itmustbe random. Occasionally, it's done in a roundabout enough way that it's actually harder to prove the result is truely random, rather than actually achieving (or preventing) true randomness.The better way is to simply avoid that altogether. Build a circuit which:1.Cannot be influenced by external forces, as much as technically possible.2. The source of noise should probably be something like amplified thermal noise.3. You can add scrambling to it later, especially to improve bit runs or weighting. But the source should be fundamentally random, as much as possible, and as easily proven as possible. You are only making more trouble for yourself if you do anything else.Examples of bad design:- Mixing RC oscillators- ADC readings"Mixing" in the radio sense: taking the difference of two frequencies, usually one an internal RC oscillator, the other an external quartz crystal (typical of MCUs). Or in the above example, mixing two RC oscillators.Reasons:The intended source is, hopefully, thermal noise, which is good. You can get true randomness out of that. The method is bad: the count is probably very stable from sample to sample (be it the number of cycles counted out against another timer, or the ADC count of a slightly uncertain analog input), so the rate of true entropy, and certainty thereof (yes, the "certainty of uncertainty", if you will), is small and variable, and dependent on very many outside influences -- that are easily affected. Simple examples: an attacker can vary the supply voltage, ambient temperature, ambient electrical interference and so on, and easily locate combinations that produce distinctive results: unusual runs of stuck bits, repeating patterns, etc. And then your random numbers aren't so random anymore, they might be under complete control; or if scrambled, they start going in circles because there's no new source of entropy (or, with a bit more work, near complete control is still achieved).Example of terrible design:- Pins floating in spaceWhy? First, you're even assuming that the pin will change, ever, at all, to begin with.A CMOS input typically has enough leakage that it pulls itself near a rail. It might take seconds or hours, but it's hardly random.With an antenna, in the presence of noise, you need to quantify what "noise" is.In most living environments, the dominant electric field component is 50/60Hz hum. Not very random and noisy, is it? If you sample that periodically at any frequency, you simply get the difference frequency, occasionally with some extra transitions near the zero crossing.In a quiet environment (unterminated pins with no traces; self-powered gizmos in remote locations; DC power or shielding; etc.), even with a large antenna (now you're making assumptions about ESD safety, too), the pin still may never transition. Atmospheric noise is strong, as radio signals go, but it's hardly real volts, even if you bothered to use a matching transformer.Good examples:- AM radio tuned to an empty channel (atmospheric*)- Zener or avalanche breakdown, amplified- Thermal noise, amplified (high gain amp, ADC; RC osc, mixer, and counter or ADC)*Atmospheric noise is the rumbling of a million outside influences. Use carefully. Obviously, a single-frequency radio can very easily be pulled, by even a weak interfering signal on the right frequency. Or just local noise can be used to dominate it (try listening to the noise during a local thunderstorm!).Understand the sources of error and influence. An RC oscillator might be fairly stable over voltage and temp, within 10% say. So taking one or a couple bits off the bottom of a count isn't terrible. A larger count helps, in that, the larger the count is, the larger the absolute uncertainty is; a true random source scales as ERR ~ sqrt(N). The relative error goes as 1/sqrt(N), so you wouldn't want to divide by the counting duration first. But notice that, the longer (more cycles) you count, the lower your bitrate is, but the more confident your uncertainty in that bitrate. The product of the two is your entropy rate.You can never have an entropy rate greater than your circuit's gain-bandwidth product allows. An RC oscillator is limited by the comparator running the oscillator, and the thermal noise of the RC element.Likewise, amplifying thermal noise for ADC readings requires enough bandwidth to get enough bits. You can't simply take one op-amp, wired for a gain of 10,000, and expect to get Mbits out of it; it's much too slow for that. Most likely you'll be left with something that drifts around slowly (electrically speaking: in the miliseconds time scale).While ADCs can provide the means of randomness, do not unilaterally decide that "oh well this thing is like 2LSBs off, so obviously every single measurement will be +/-2LSBs period!" The absolute position of a given ADC reading, relative to the actual voltage, might be off by 2 LSBs, or the width of that bit (the range of voltages which reads as the same count) might be 50% longer or narrower than it's supposed to be, but the pattern will be consistent: from sample to sample, the same voltage will always sample as the same count. It can be noisy, right over a threshold between counts (thermal noise pushing the bits one way or the other), but this cannot be relied upon. In short: even an ADC as notoriously poor as the ATMega's will still read consistently from sample to sample, even without particular care.My personal example: I remember in school the clunky MCU-and-breadboard kits they used. Didn't seem to be any particular care in the design. But you could perfectly well connect a potentiometer to the analog input, convert with ADC, and blink out the binary code on LEDs, and it would stay at the same count all on its own, and was fairly easy to set to a given count: turning a pot to 0.1% positional accuracy is tedious and tricky, but hardly impossible. And that's in the presence of residual supply ripple (not bad -- they used 7805s I think), ambient noise (unfiltered input wires), thermal noise (of the pot) and excess noise (of the pot's carbon track -- some spots you can't control so well because of "scratchiness").I know this doesn't matter to this thread, but I have to say something.Tim

author: SL4P
author_rank: Super Contributor
timestamp: June 19, 2014, 01:58:32 am
content: I certainly acknowledge what you're saying, but FFS - the OP wants to blink 'stars' on his ceiling, and is not electronically minded.If he gets that far, and wants to improve the distribution of noise - great, add a high-gain pre-amp!There is no correlation between the noise domain and the 64-bit samples, so the noise may be constant, but extremely unlikely to repeat in phase with the 555 timer clock!

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 19, 2014, 02:01:01 am
content: There appears to be a lot more to random numbers than I had imagined. Just read an interesting piece here...http://electronicdesign.com/learning-resources/understanding-intels-ivy-bridge-random-number-generatorThey appear to start with thermal noise, but then they do several "processing" steps to test the randomness, and even make it "more random".I would have thought that simply the raw bitstream from the thermal noise would have been truly random.Disclosure: While I work for Intel, I don't know anything more about this than you do. I work in an area far removed from architecture and circuit design.

author: SL4P
author_rank: Super Contributor
timestamp: June 19, 2014, 02:15:42 am
content: That's an interesting comment, as processing adds a finite distortion to the initial random sequence... or does it? When you start to combine more than one random stream, when does aliasing and other phase artefacts become a problem?Always fun!

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 19, 2014, 02:47:16 am
content: If it's true random, uncorrelated noise, nothing -- the (equal weighted, analog RMS voltage) sum goes as sqrt(2), or for a clocked bitstream... a whole lot of nothing, I think ("true coin flips" XOR "true coin flips" = guess what, more "true coin flips").Most sources have some degree of bias or weight or potential correlation to them (e.g., power supply noise, asymmetrical rise/fall times, etc.). So it helps to de-weight them (I don't remember how -- there's a process for it), or you can just seed it into any number of PRNGs with entropy input. Probably both are done, since they'd be doing it for low-latency crypto or something (the spooks -- who are far better versed in the order of chaos than I am).Tim

author: SL4P
author_rank: Super Contributor
timestamp: June 19, 2014, 05:52:44 am
content: Quote from: T3sl4co1l on June 19, 2014, 02:47:16 amWe agree completely! Me too.

author: eneuro
author_rank: Super Contributor
timestamp: June 19, 2014, 12:20:28 pm
content: Quote from: SL4P on June 19, 2014, 01:58:32 amIf he does not need TRNG for cryptography one can use software pseudorandom number generator I've used in many projects when strong randomness is not needed-it is a few lines of code in C on AVRQuote from: T3sl4co1l on June 19, 2014, 01:39:41 amOf course there is nothing bad in using ADC to obtain random bits, while it depends what you connect to your ADCFloating ADC pins might be not too good for cryptography, but it can be usable when used with another software pseudo random number generators.

author: SL4P
author_rank: Super Contributor
timestamp: June 19, 2014, 12:37:29 pm
content: Let's revisit the OP...Quote from: Doug_in_Minnesota on June 14, 2014, 11:36:17 pm... and start the conversation again.

author: dannyf
author_rank: Super Contributor
timestamp: June 19, 2014, 12:38:53 pm
content: QuoteNo. I can generate random numbers from an adc pin grounded or pulled to Vcc/Vref.All those approaches listed above can be used to generate TRNG. It is just a question of how you do it.

author: dannyf
author_rank: Super Contributor
timestamp: June 19, 2014, 12:51:47 pm
content: QuoteI think the earlier discussions are fairly exhaustive and cover pretty much all the basis.Doing so in the analog domain isn't difficult. Doing so in the digital domain, with programmable devices (like a mcu), isn't difficult.It is not difficult to do so with digital devices (like a gate) either. It is just that it becomes unnecessary or unnecessarily difficult.It is understandable that it can be challenging for a person not already into a mcu, or has no other purposes into the field of mcus.

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 20, 2014, 04:36:21 am
content: OK, everybody.....I want to "back up" a bit...........I have read through ALL the replies and comments that are up currently (up through Reply # 42 by dannyf, as of 8:30pm Central Time June 19 Wednesday).dannyf> THANK YOU for trying to refocus this discussion back to what I was originally asking for.I would like to politely request to most Commenter's to go back to the original Post, for anybody who is interested in that concept.Although I have read the last 10 or so posts tonight, and I find them quite interesting and amusing (and ALL way over my head and current state of knowledge and understanding), it seems that the whole point of the thread took a left turn somewhere around Reply #18. I don't mind at all having a few people get into a "this way versus that way" type of discussion, I just want to let everybody know that none of it matters to me. Feel free to continue the discussion about thermal noise versus ADC output versus picking up "noise" in the air versus using shift registers versus other concepts. But I won't be participating in THAT, because number one I don't care, and number two it doesn't address my actual needs in a practical way. Don't take this wrong, I'm not complaining in any way, and I TRULY don't mind some of you having this back and forth discussion here. Feel free, I just want to let you know that I won't be putting up a post regarding that kind of discussion, 'cause it's just not useful to me._________dannyj just put up a post (Reply #42) that really does a good job of addressing what I was originally asking for.But to refresh the discussion about how it started.....I somewhat half erroneously asked about generating random numbers, because I thought that was what I needed. But actually, it isn't (wasn't). What I SHOULD have done, is to be more clear about what the ULTIMATE, ACTUAL END RESULT and objective is, that I wanted to do (and still do).Picture this: You're laying in bed, well after dark, at night, ready to fall asleep. You look at the ceiling in your bedroom, and there are a large number of "lights", that look vaguely like "stars", and some of them are on continuously, and occassionally a "star" or "light" comes on, and stays on for a while. Or maybe one "blinks" for a moment, or a few seconds. And maybe a couple blink at a steady repeating rate, like a satellite (or even an airplane).The whole OBJECTIVE is to create an indoor sort of "planetarium" looking "system". What I am trying to do, is to "replicate" the look and feel of laying out in the backyard, late at night, watching the night sky. That's my objective.I might not be able to easily replicate "shooting stars", or "meteors", because that would probably involve some sort of very long series of lights placed physically together in a "string", and them somehow controlling them in a way that makes a bunch of them light up for a fraction of a second, and in a specific "sequence". That would be the only way to simulate "movement", that I can think of, without actually having a "motor based" system, where a single light would physically move a couple feet across the ceiling, which is far beyond what I am interested in doing right now.SO, I asked for some ideas, and I certainly got a few.My original post said I would like to avoid using microcontrollers. That was because I don't know much about them, in fact I know almost nothing about them. I certainly have never used them. So if I used an mcu, I would be starting from scratch. It seemed to me to be too complex of a way to approach the task. HOWEVER, after reading all the suggestions and commentary people have helpfully written, I came to the conclusion there is not really a "single chip" type solution for doing this task. I think I realized that there were two basic practical approaches. One would involve using an mcu, along with any necessary external peripheral chips, such as drivers, maybe transistors, etc. The other approach apparently would be based on using shift registers and other digital chip techniques. I have ZERO experience working with digital chips. I do have an idea of what they do, and vaguely about how they work, but if you gave me access to everything in the digikey catalog, and held a gun to my head, I would not be able to sit down at my bench and BUILD ANYTHING using digital chips. I have a LOT of reference books, almost a limitless quantity of books and sources of information. Of course, I could learn everything I would need to know about digital by reading sites on the web and then just breadboarding over and over.SO, I found myself faced with two decisionhs. One, do I go ahead and follow my interest in doing my originally stated project? And two, should I approach it from a primarily discrete digital component point of view, buying gates, registers, and all the various types of digital logic chips and related chips, and using the related resistors, caps, and anything else that would be needed (including a small but quality and accurate power source)?At the moment, my answer to decision number one is that Yes, I am going to keep pursuing this project.My answer to decision number two is that I am going to embrace the microcontroller world, and try to accomplish my task in that world.I feel that after reviewing the available tools, that if I spend somewhere between $40 to $80, I can buy a beginner level Arduino board, probably the most "generic multipurpose" Arduino board that I can identify, and also get a "programmer" of some type, IF I NEED IT.There are so many freely available software and programming tools and resources available for both the Arduino world, and the PIC world, that I intuitively feel I won't have to spend any real money in that area.It is not clear to me if I need to buy a "programmer" like a PicKit (which I previously referred to as a PicAXE, which was incorrect), or if I don't need that if I have the Arduino. I do have a PC of course, with text editing software. And I will download and install and use any software suggested by the Arduino web site or people.So, to re-cap, I AM going to go the MicroController way. I will buy the board, whether it is PIC or Arduino based and I'll buy any other hardware I need to. As long as I can keep my total expenditures under a Hundred dollars or so (the less the better), I'll be happy.One of the things that I find really appealing about the mcu path, is that I will be learning things that will be applicable to many other projects that I might want to do in the future (thanks rob). AND, I'll have the Arduino board with the included Atmel mcu, to experiment with for other things (motor control, etc).[skip this next long part if you don't care about knowing more about me and my skill level]>Also, I want to point out a few things that might help clear up some of the confusion that I might have unknowingly created. One, I DO have a reasonable level of skill in Electronics in general. I just don't have experience in Digital or with Microcontrollers. I went to Electronics school for a year or two (part time) around 1981-1982. It was a very good quality education, and I got straight A's and some 4.0 grades in several of my classes.So the stuff that was taught, I learned well. But because I only made it about half way through the two year full time curriculum (because I was starving and had to go to work), I only learned what was taught in the first year. Basically, DC and AC theory and principles (RCL), analog filters,some basic solid state stuff, diodes-pn junctions, op amps+transistors, along with all the relevant math, etc. That was most of what we learned. The second year would have included quarters on: Digital, Pulse Circuits, Industrial Electronics, TV+Radio, and several other areas that I don't even remember.However, I spent a FORTUNE on books. Back then, we didn't have the Net, so the only way to expand one's knowledge was to go to school, or to buy and read books and magazines, or go to the library. I have AT LEAST 100 books (reference, text, and other) about electronics, including many that are much more advanced beyond just what was covered in the classes I took. Those are just the physical, printed books. I have probably another 300 or so "electronic books" (PDF's, etc) that I have collected (downloaded) over the last ten years. This includes many of the classics, and some of them are the "huge" books, that cost like $80-$100 in hard cover, like "The Electronic Engineering Handbook", etc.I learned that if I used 4 or 5 books during any one quarter, rather than only the one book that was assigned as the Official text for the course, that I learned things in a much more thorough way. So I have a massive library. God, I spent so much money on books back in those days. I'll never throw them away, or sell them, even if I loose interest in Electronics for a while.Recently, over the last year or two, I have started getting back into my interest of electronics, at the hobbyist level. My primary interest is audio equipment. I have rounded out the "holes" in my lab equipment array, by adding a scope (B+K 60 Mhz two channel analog scope, in perfect condition), some additional power supplies, a couple counters, a second waveform generator (Wavetek 12 Mhz digitally controlled, tunable to a single exact frequency), several additional DMM's, and other stuff. I have also added a huge amount of mostly analog components and LOTS of semiconductors by stripping equipment and recycling parts. And of course, I have all the possible hand tools, including soldering equipment, etc.So pardon my self indulgent monograph about my history and skills, but I wanted to clear up some of the conclusions that had been formed about what my level of knowledge is, and isn't. If there is a place in the "beginners" forum, or another appropriate "introductions" place in the EEVBlog Forums, I'll probably excerpt some of this info, and post it there.One of the very interesting things about reading the EEVBLog Forum's, is to see such a wide array of skills and knowledge that different people have. Some people are more advanced than others, and some people have a lot of knowledge in certain areas, that other people might not have.______SO, back on track to the original point of the Original Post. My goal is to design and build the "planetarium", and to make it work, and to be able to control the timing of the various "lights" (stars). That's all. I have assumed that led's will be the best type of "light" to use, but I am open to suggestions. Led's are so easy to use, needing only a resistor and a low volt power supply, and use such low currents/power, that I figure that will be the best way to go.And as I mentioned, and a couple other posters have mentioned, the lights will be "physically spread out", so that say I have 70 lights that stay on all the time, and 30 that come and go, the ones that come and go will be "spread out" or "distributed" across the entire ceiling, and mixed in with all the others.I AM NOT going to use this circuit or project in ANY KIND of cryptography. I DO NOT need real sophisticated "randomness". I would prefer not to have too much "obvious repeating patterns" of lights coming on and off, but I don't anticipate that being a problem. If there are things I can do in the code of Arduino to minimize that, then great. But if there isn't a lot that is easy to use, then no biggie.At this point I understand (I think) that I will be using the Outputs of the Arduino board to "drive" some sorts of devices that will more directly supply and manage the current for all the led's. That part should be fairly straightforward. Whether it is a bunch of transistors, or dedicated led driver chips, or some other kind of "generic jelly bean chip", it shouldn't be too hard to implement. Not that I know how to do that right now, but I can certainly learn it without too much difficulty, I assume.I do anticipate a large "grid" of thin gauge wires going across my ceiling (not connected at the cross points, but simple insulated wire that goes to all the individual led's). I hope that when the whole thing is done, and mounted and tested and in place, that I'll be able to use some thin black cloth (which I already have), to basically "cover" the entire thing, and just have lots of little openings that all the lights can point through.This whole thing might turn out to be a bust, and look lousy, but I'm gonna try it and see what happens.I don't need, and don't want to use, any kind of "multiplexing" or "addressing" for individual lights. I'll simply make each individual circuit a discrete dedicated circuit. As I mentioned in Post# 26, I can run all of the "static" or "constant" led's off just one or two circuits that supply the appropriate current and voltage. It could be just a low voltage source (like two volts or so) with the right resistors, and a separate string for each light, or else a series-parallel circuit where I put 3 or 4 or 5 led's in series, with a resistor, and then just repeat that 10 or 15 times (in parallel), and use a slightly higher voltage, like 12 volts or something. I could probably adapt a generic 'wall-wart" of the appropriate voltage or 2 or 3 (I've got a whole box of 'em), and load it with the optimum current for that walwart (each one likes a different load to get the right voltage). And then just do the series-parallel thing with whatever combination of wall-warts that work out. That would be the simplest approach for all the constantly on stars. I can just run them all through a switch or power strip.The one thing that I won't be able to design in or adjust until the led's are actually on the ceiling is what "brightness" I'll have to set the various led currents to. Somebody (sorry I don't remember who) in the thread mentioned using a variety of different load resistors so the all the different lights are of various intensities, just like they would be if you were looking at the actual sky (Good idea-Thanks for that suggestion).______I will continue to read this thread each day until it peter's out, but I feel I have most of the info that I was looking for and that I will need. As I said above, once this thing starts to take form, I'll try to come back here and Report, although that will probably be quite a while from now (on the order of months, perhaps).I want to thank the following people, because their postings have been the very most helpful to me, addressing my original intention, and in writing at a level that I can understand:dannyfrob77mariushSLP4 (reply 39--thanks!)PsiT3sl4co1l n (Tim)Paul MoirI'll look through the EEVBlog Forums to find stuff about using Arduino's, I'm sure there are many. Just one last question, and I know this isn't the perfect place for it but: Does anybody have any recommendation about which Arduino to get? Or how to choose? There are like 50 or more, just from the original Arduino company itself, not to mention all the other variants people have created. It is a pretty overwhelming range of choices to me. I guess I'll have to learn about how to evaluate them, in terms of how many i/o pins, how much power they handle, how much memory of different types each one has, inclusion of a USB built in, etc etc.THANKS TO EVERYBODY WHO HAS HELPED ME-Doug

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 20, 2014, 05:09:52 am
content: If you want something small and inexpensive enough to make hundreds of them, I would consider using zener or transistor junction noise source and a 4000 series gate (like a 4049 hex inverter, etc.) You can bias certain varieties to be an analog amplifier stage, another stage to do frequency shaping (for fast or slow "twinkling"), and then connect the remainder of the gates in parallel for enough drive current to handle the LED load.OTOH, those little 8-pin microcontrollers may be as inexpensive, and are far easier to program for just the effect you are going for. I am assuming that you will have light sources of various sizes/brightness ("magnitude" in astronomical terms). And some that pulse rather slowly (perhaps using PWM), and others that "twinkle" rapidly, etc, etc.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 20, 2014, 05:12:54 am
content: Some people do this with optical fiber cable and an optical "noise source", a rotating "dirty filter" between the light source and the fiber inputs.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 20, 2014, 05:19:28 am
content: Note that you can now buy RGB LEDs in "conventional" 5mm or 8mm packages that actually haveaddressable controllersbuilt right in to the package. And they are well less than $1 each, especially in quantity.https://www.sparkfun.com/products/12877

author: eneuro
author_rank: Super Contributor
timestamp: June 20, 2014, 10:07:12 am
content: Quote from: Doug_in_Minnesota on June 20, 2014, 04:36:21 amYep, maybe it wasn't single chip solution a week ago but now here it is:ProTRNG by EneuroYou have 10 000 random bits per second on this small DIP8 uC PIN 6. All you need in basic setup add 10k resistor between PIN1 <-> PIN8 and power supply: 5Vcc -> PIN8, GND-> PIN4 .It can be available as SMD package tooI can ship it to you for free if this amount of random bits per second fits into your project.I found it usefull in my applications.It is a good idea to step into MCU world, however you can add shift registers and clock <10 kHz and you will be able to read those random bits from this TRNG in analog circuits tooIf you play with random numbers genarators for fun grab "random" data taken from such TRNG and present it as image and it is an indicator how good this TRNG might be.If you need it for cryptography than more advanced analysis and postprocessing is needed and quantum mechanics based TRNGs are often used in comercial products.This is sample of around 1KB gray image of random bytes recieved on my PC Linux LPT pin from this TRNG and using my small utility software to convert bytes stream from file into PNG image we can see how this random bytes made of 8bits from this TRNG looks like:Quote

author: dannyf
author_rank: Super Contributor
timestamp: June 20, 2014, 11:11:34 am
content: QuoteI would go with an Arduino: it gets you started quickly. You have the option to use it as an Arduino or AVR. Programmer there is either free or a couple dollars.PIC is a little bit old and requires a PICKIT2/3 to get started. But the chips tend to be more available and cheaper, a factor that may be important if you intend to produce the end products.The programming difficulties will depend on how "realistic" you want the stars to be. A shooting star can be quite difficult as it almost surely requires a matrix. Otherwise, with discrete stars, it is fairly easy to program. However, what we have discussed so far is to produce a random pattern of on/off. To simulate the sky, you need more sophistication than that.Either way, it all starts with generating a random number, how truly random it is is 2ndary.

author: dannyf
author_rank: Super Contributor
timestamp: June 20, 2014, 11:51:34 am
content: QuoteI put it on a 12F675, and I got 0.12ms per bit -> 8K bits per second, running at the default 4Mhz internal oscillator / 1Mhz F_CPU.All in 120 bytes of code.I will implement also an input clock so I can generate random numbers from the phase noise of the internal oscillator.

author: eneuro
author_rank: Super Contributor
timestamp: June 20, 2014, 03:07:26 pm
content: Quote from: dannyf on June 20, 2014, 11:51:34 amWho cares how much lines/bytes of code uC program uses while it is dedicated to this one random bits generating task and fits into 1KB-2KB flash ?You can simply change optimisation settings in C source code, adjust inline statements to fit into smaller code if needed.It does not matter if someone wants simply put it into circuit and... read random bits.Its quality maybe more important while even in simple applications it could be boring if some bit patterns repeated too often, so that is why I've tests for its randomness.As you can see in my simple DIP8 solution there are ... 4 (3 ADCs and 1 general I/O) not connected pins which can be connected to external noise sources if you needed higher quality TRNG.While I've made also automated tools for analysis of this TRNG randomness quality on PC Linux, it will be interesting to connect diffrent external noise sources like NTC temperature sensors, LDR photoresistors or analog Hall magnetic field sensors to see if such more advanced configurations of this simple TRNG passes cryptography tests for randomness

author: dannyf
author_rank: Super Contributor
timestamp: June 20, 2014, 03:51:56 pm
content: QuoteTry Die hard. Die harder is a little bit more advanced.

author: Doug_in_Minnesota
author_rank: Contributor
timestamp: June 22, 2014, 12:45:57 am
content: I did about 5 more hours reading the other night, and I have made what I think is a Pretty Firm Decision that I am going to buy an Arduino Mega 2560 R3, which uses an Atmel 2560 mcu. It is probably the most "beefy" standard off the shelf Arduino board/system that is available directly from Arduino, or through one of their resellers.https://www.sparkfun.com/products/11061I have downloaded the various Atmel 2560 datasheets. Of course, I don't understand the entire documents, but at least I have them, so I can study them when the appropiate time comes 'round.I have read a LOT of posts, here on the EEV Forums as well as in other places, where people "argue" about whether an Arduino is "real" electronics or not. Very much of a "snob" argument in my opinion. It would be all good and well for somebody (like me) to learn from Ground Zero, and learn how to do this entire project by using only digital logic chips, or ADC's, or using one of the many "pn junction noise" techniques that have been mentioned, but that really misses the point.Remember, I am intending to do this project FOR THE ULTIMATE OBJECTIVE. I don't care very much about how I get there, but I don't want to spend 4 months trying to make it work. I don't want to have to develop an intense knowledge of C, just enough to get the job done. I don't want to spend months learning the best ways to learn how to harness miscroscopic amounts of pn junction noise, and using fancy low-noise op-amps or transistors to expand the range of "values" available.I just want to put the stars on the ceiling, of an appropriate number, and in a variety of "brightnesses", and with an appropriate number of them "blinking", or maybe staying in an Off state most of the time, and coming on occassionally, for various amounts of time. THAT'S ALL!!!!!!!So, while I appreciate all the discussions above, 90% of it is over my head and CURRENT state of knowledge.90% of what I wanted to learn about is covered in about 20% of the posts.I'll learn enough C to write whatever functions or commands and programs I need in the Arduino language. I'll learn enough about PWM to vary the intensities to whatever degree I want. I'll learn enough about switcing transistors, or about certain IC's that can do the same task, to use the digital Outputs of the Arduino to control my led's.Everything else that the Arduino can do, and all of the many, many things that can be done by writing more complex code are all things I can learn in the future, for other purposes, as the breadth of my projects justify.I think that my goal (described repeatedly in previous posts) will be most easily, quickly, and inexpensively realized by using an Arduino board. And since I'm going to buy one, I decided to buy the biggest baddest one I could find, with the most memory of various types, most i/o, most power capability, most PWM, etc.That looks to be the 2560 Mega R3. It's about 47 american bucks, or so. Also, that board can be re-used for dozens (or hundreds) of different types of projects over the coming years.It might also turn out that it will be a good thing to buy an add-on shield that would be optimal for driving dozens of led's. I'll have to do more reading to determine that. Otherwise, I'll just find some specialized driver IC's that would be a good interface between the Arduino and the actual discrete led's, or else I'll just use some transistors, or some IC's that are an "array" of transistors, to drive the led's.If my "stars" project works out, then I will leave the installation as "permanent". But at that point, I can probably "optimize" it by taking the expensive Mega out and replacing it with a more bare bones Arduino that is just powerful enough to do the job. That would probably be about a twenty dollar board. I could adapt that in, replacing the Mega, and then use the Mega for my long term series of other projects and experiments.-More later.....ThanksDoug

author: rob77
author_rank: Super Contributor
timestamp: June 22, 2014, 01:07:34 am
content: the mega2560 is a good choice - for permanent installation you can buy a cheap chinese clone of mega 2560 for approx 25USD. or you can go for the nano clone for approx 10USD (nano is my favorite - because nano board fits into a DIP40 socket)the arduino boards are open source , so the chinese clones are exactly the same - 100% compatible. it makes sense to buy one genuine to support the arduino guys (if you wish) , but later on once you're using the board only as a break-out board for the bare atmega (no arduino software used in your project) then it makes more sense to go for the clones

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 22, 2014, 02:49:40 am
content: Remember that for driving large numbers of outputs (such as many stars!) we commonly use I/O expansion in the form of shift registers. You can string virtually any number of these together and drive them from a single output on the smallest Arduino you can find. Some are barely larger than your thumb-nail. You don't need a big controller to do this. You only need many outputs. Many more than even the largest Arduino offers. Which is why shift registers are so popular.And with the advent of those LEDs with built-in drivers, you can simply string out as many "smart" LEDs from a single Arduino pin as your budget will support. They could hardly have made it easier for this kind of project. I have ordered a bunch of those driver-LEDs for some of my own projects.

author: SL4P
author_rank: Super Contributor
timestamp: June 22, 2014, 06:13:37 am
content: I can't help but think we have moved on from choosing an RNG - to the best method of interfacing a ceiling full of LEDs..This thread could go on forever!

author: dannyf
author_rank: Super Contributor
timestamp: June 22, 2014, 12:19:40 pm
content: From a wiring perspective, particularly on a project spanning a large room, it is easier to have standalone self contained mcu plus led. The local mcu would determine randomly or otherwise the flashing pattern. You just need to connect power plus ground.

author: eneuro
author_rank: Super Contributor
timestamp: June 22, 2014, 01:36:50 pm
content: Quote from: SL4P on June 22, 2014, 06:13:37 amYep, but of course Arduino is not needed to step into MCU word-I've did it with DIP8 ATTiny85 (<2$ per unit) and self made LPT programer in DAPA mode using a few resistors. It takes <5 seconds to rewrite ATTiny flash memoryQuote from: Doug_in_Minnesota on June 22, 2014, 12:45:57 amKeep things as simple as possibleUse software I2C (only 2 uC pins needed) even on this DIP8 AVR ATTiny85 and connect via I2C as many LED "stars" as you want using for example thisPCA9552 LED blinking with GPIO expansion (http://www.nxp.com/documents/leaflet/75016021.pdf).Updated: It is not possibly to change I2C adress of PCA9553, so PCA9552 looks good depending how many those stars you need-without any tricks it looks like 8 such devices can be adressed by seting its hardware adress pins A0,A1,A2 while 16 leds per unit gives 128 leds or addidtional pins for your MCUIts application note is here:AN264: I2C DEVICES for LED DISPLAY CONTROLBTW: My TRNG can be installed even on ATTiny25, while <2KB of flash is needed for this TRNG, but it is easy run it on ATTiny85 and I2C can blink LEDs while random bits are created when needed on the same small DIP8 ATTiny

author: eneuro
author_rank: Super Contributor
timestamp: August 10, 2015, 08:33:26 pm
content: I'm interested now in much faster TRNG than this simply a few ADCs XORing I've implemented using ATTiny85 shown a few posts ago some times ago, and I've found in this paperOne Time Pad Encryption The unbreakable encryption methodvery interesting method to use timing jitter and oscillator drift found in free-running CMOS ring oscillators as a source of randomnessIn short words quoted from publication linked above it works like this:QuoteI've also found another scientific publications, where detailed analysis were made of timing jitter efects and it looks like indeed there is true random component.I will order a few NAND and XOR CMOS gates for other project too, so I thought try to test this CMOS ring oscilators concept shown above, but unsure-how do you think,. how many inverters might be needed for such one ring and what this "SS" mark means-even more inverters needed?I will have quad XOR2 gates, so maybe worth to try 4 or 8 ring oscilators like this and output XOR'ed all inputs to MPU pin than sample its logic value, and send to PC to make NIST tests for randomness, I've mentioned earlier in this thread?Beaty of this solution is no MPU ADC involved and it should be really fast

author: Someone
author_rank: Super Contributor
timestamp: August 11, 2015, 02:01:25 am
content: Quote from: Doug_in_Minnesota on June 20, 2014, 04:36:21 amOk, this is the start of a design. You want to define clear parts and requirements and break those down into achievable goals along the way. Multiplexing is a cheap way to drive many elements, and would be the cheapest way to blink more than a dozen or so LEDs.You might want to make a simulation to get an idea of how it would look before committing to isolated blinky lights in a field of static ones, as it will look nothing like stars at all (which have many atmospheric and optical effects occurring to make the magic). If you can program in some sort of "higher level" language on a computer it is easy to make a quick demonstration in say octave/scilab (free matlab type packages), or even in a browser in HTML/CSS javascript etc, once you have a software prototype you can get a feel for the design. For instance:http://jsfiddle.net/6wnnP/In that example every point is varying in brightness.