# IR Random Number Generator?

So this is a somewhat off the cuff question, or discovery, or just a curiosity. I have been working with the Arduino platform and projects for a couple of months now, great education, thought provoking, and just plain fun for these isolate at home times. Anyway, I did the typical "kits" approach to start with. I came to the IR code experiment and thought it was pretty neat to see the actual codes. With an engineering background I knew the basics of the IR remote and now I can see the actual codes from the various remote makers, cool. So then I put together an uno running the basic blink program and attached a standard IR led in parallel to the visible led. I used a second uno to run the typical IR code receiver experiment. Of course, the blink, blinks and the IR receiver, receives.

My question comes in with what exactly the standard IR led in its blink process is creating. I opened the serial monitor for the IR receive uno and observed the string of numbers (I created both HEX and DEC outputs). The thing is, I have been unable to find any duplicate numbers? In other words I have let the simple blinking IR led run for a great deal of time, generating a great deal of numbers on the IR receive side. I have started and stop the process numerous times. I capture the numbers into a spread sheet to analyze and, at least each time I have done this the numbers are all unique. Numbers between captured runs are also unique to each other. The decimal numbers generated are all either 9 or 10 digit unique numbers. Typically computer generated random numbers are not actually totally random, thus the use of 'seed' programs for computer random number generation.

Of course there is nothing terribly important or earth shattering about this question but hopeful someone in the Arduino community can tell me where the numbers in my little experiment are coming from, and why they always seem, at least in my experience, to be unique? Is there something in the architecture of the uno on the IR receiving side that would happen to 'choose' the numbers to spit out to the serial monitor or is it just noise that I am capturing? I guess if these numbers always come out unique it could have some application as a random number or random seed generator. Otherwise it is just a curiosity. Thanks.

gbrei91:
So then I put together an uno running the basic blink program and attached a standard IR led in parallel to the visible led. I used a second uno to run the typical IR code receiver experiment. Of course, the blink, blinks and the IR receiver, receives.

My question comes in with what exactly the standard IR led in its blink process is creating.

Without seeing your two programs it’s a bit hard to guess an answer.

If the IR LED is just blinking on and off then it seems illogical to be expecting a program intended to receive complex IR codes to make any sense of the blinking.

…R

Thanks Robin2 for the response. Yes, I agree, it is illogical to expect the IR receive program to make sense of a blinking IR led, I wasn’t really going for logic, but rather understanding. I am just curious as to where the generating numbers are coming from, as I said perhaps just noise? Also, I am even more curious as to why I can’t seem to find any repetition in the numbers, why do they all seem to be unique? At some point I would expect to find a repeat, perhaps I just don’t have a big enough sample size. I am new to the forum, so I will have to learn how to attach the programs here, but I assure you they are the basic blink and IR receive programs that are included in many of the Arduino kits. Anyway, not a real problem to necessarily solve, and nothing to stop the enjoyment I am getting from working (playing really) with my Arduino, just a curiosity. Thanks again for the response.

gbrei91:
I am new to the forum, so I will have to learn how to attach the programs here,

See General Guidance and How to use the Forum. It’s at the top of every Forum section.

…R

gbrei91: I am just curious as to where the generating numbers are coming from, as I said perhaps just noise?

Not nearly as curious as I am. Are you using the random() function? You didn't actually say.

You do know that the vast majority of IR is transmitted using OOK (On/Off Keying) of the IR carrier. Usually for consumer IR products, but not exclusively, the carrier is modulated at around 38kHz. The precise frequency is usually not that important.

The vast majority of consumer IR receivers will only output a signal if they first detect that carrier, and secondly only if they detect short bursts of that carrier. If you send too long (or continuous) 38kHz you will saturate the AGC circuit, and the receiver will "ignore" it.

So, if you are just powering the IR led, and not modulating it at 38KHz, it's very unlikely the receiver is going to make much sense of it. Probably it will just see it as noise and reject it. IR receivers are designed to readily reject noise from sunlight and fluorescent lamps, which would otherwise present problems.

Also, it is common practice to drive the LED at more than it's maximum If, which is fine because you are modulating with a 50% duty cycle and not steady state. Higher If will give better range.

How fast is your blink program blinking?

This is pretty speculative, but consider the following:

IR typical operating characteristics

• IR remotes/detectors have the signal modulated on a carrier (commonly 38 kHz) which allows the receiver to use a band pass filter to largely filter out ambient IR.
• IR receivers have automatic gain control that tries to set the gain level such that the signal level to the band pass filter and detector is not at the power rails.
• The detector tries to suppress detected signal output when there isn't a clear 38 kHz carrier signal present. In this scenario, you have a IR blinker LED that is (I'm speculating, hence the question above) at a low frequency relative to the carrier. This causes a step change in the "ambient IR level" that changes the AGC set point. At this change the detector is confused enough to think there is a real signal and put out a data word which is in reality simply noise on the ambient IR or thermal noise from the detector itself. If the latter, it might be a very good random number generator. In fact there exist hardware random noise generators based on detecting thermal noise from a diode or transistor junction that are used in applications requiring "true" random numbers.

As I say, this is pretty speculative, but one hypothesis that might explain the observation. One could test this by changing the blink rate and see what effect that has on the rate of data output.

Wow, thanks for all of your responses. To aarg, no I am not using any random number generator within the programs, just a standard blink on one uno and a standard IR detect on the other uno. The detect module and program come from a Mega Sensor Kit I purchased, sunfounder I believe is the kit source. The blink program of course is everywhere within Arduino. To pcbbc and mrmark, yes the kit instructions explains, most of which I knew, about the 38K IR carrier and the kit comes with it own little basic remote to play with to see the generated codes. So I said, what the heck, and got a generic IR led off the web, all unmodulated of course, just because I was curious what it would produce, thus this whole post which I originally started in the general (talk about anything) forum. Mrmark, I think you hypothesis is correct and I am just capturing noise but I will vary the blink rate now to see what happens just... because I can, and this is really fun. Interesting to think that the noise is as random as it appears to be given the output numbers I am seeing, but then I guess there are many things in the universe that are just random.

pcbbc: it is common practice to drive the LED at more than it's maximum If, which is fine because you are modulating with a 50% duty cycle and not steady state. Higher If will give better range.

A lower duty cycle is more common, and if you look at a TX IR LED datasheet, you will probably find two max current specs, 100% and 10%. The peak intensity can be safely much higher at 10%. From a Vishay spec:

"The duty cycle of the carrier frequency can be between 50 % and 5 %. A remote control system using a Vishay IR receiver is more efficient regarding battery power consumption on the emitter side if the carrier duty cycle is low. This is shown in the following example:

• Carrier duty cycle 50 %, peak current of emitter IF = 200 mA, the resulting transmission distance is 25 m

• Carrier duty cycle 10 %, peak current of emitter IF = 800 mA, the resulting transmission distance is 29 m"

gbrei91: thus this whole post which I originally started in the general (talk about anything) forum.

Is this a duplicate post, then?

Just an update regarding mrmark's suggestion to change the blink rate and see what happens, thank you mrmark. The faster the blink rate, the more I observed an increasing race condition between the two uno boards. Specs for the IR receiver I happen to have indicate about a 20 millisecond turn around on reads and of course it was also expecting the 38K carrier to be present. As I approached a blink rate of even 100 millisecond blinks, the receiver and the program running it started having trouble keeping up and the random number output began to basically stutter. As I slowed down the blink rate to as slow as 5 seconds, the IR receiver was able to keep up just fine of course and continued to generate random numbers of 9 or 10 decimal digits. Still the question of sample size will remain mostly unanswered. The samples I took at 500 ms, 1 sec, 2 sec, etc. indicated totally unique numbers being created however if one was able to supercomputer attach it, there may be duplicates created in the 10's of thousands or 10's of millions of numbers created. Certainly I will never find that out.

Conclusions from this little journey:

-I definitely was using the IR hardware outside of its intended specs. -I was most likely capturing random noise as the hardware was trying to figure out what the heck I was doing with unmodulated IR signals coming in. -This set up, at reasonable blink rates, could probably be used as a decent random number generator as long as no ones life depended on it, although I am sure there are much simpler methods to generate those numbers. -It was a fun little experiment, time to try to break something else.

Again, thanks to all those who replied with questions and ideas. Now I guess I have to figure out how to close this post, or does it live on forever?

It lives forever. Someone will probably necro it 5 years from now, to ask about something else. :)