Random outcome on multiple devices

[Aussie Barry]

Hi All,

I have read most of the forum posts regarding Random Number generation but can't find one that answers my particular question.
I understand the random number sequence will be highly repeatable and predictable if using the same seed but what is the likelihood of the same random number being generated on two or more stand alone PIC's?
For example, four PIC12F508's all running the same code and all turn on at the same time - would the outcome of a "RANDOM MyNumber" command likely to be the same for all four PIC's?

A bit of background - I need to build an array of 32 pairs of LED's and set each pair to toggle at a different frequency. Each pair of LED's will be driven by its own PIC. I was hoping to be able to introduce a degree of randomness to the whole scheme rather than having to program each PIC differently to achieve an overall variation in flash rates between individual pairs.

Comments and suggestions would be greatly appreciated.

Cheers
Barry
VK2XBP

[Art]

Hi Barry, Greetings from Australia

If you run the same program on all four pics the result will be the same.
There is no math formula to produce a random number
PicBasic will cycle through a finite set of numbers.

If you can choose a seed, you could load each pic with a different seed.

If any action depends on a user pressing a button you can time the button
push, or count contact bounce, and add that result to a seed for a different seed each launch.

Without any external input, I think you'd be needing to at least write
something different to each on-board EEPROM,
unless you can do something really tricky to detect noise in a power supply or some such thing.
Cheers, Art.

[Aussie Barry]

Hi Art,

In what part of the "Land Down-Under" do you reside?
I am in Sydney's southern suburbs.

Thanks for the quick reply.
Noise detection systems are overkill for this project. I was hoping that the power up sequence for individual devices would have provided some degree of variation.
What if I used a timer based system to generate the seed and then de-tuned the internal oscillator between various devices to get some spread of variation - do you think that would work?
Alternately, I could cascade a pulse from PIC to PIC and emulate a button push... just thinking out aloud here.

Cheers
Barry
VK2XBP

[Art]

Close to Brisbane here

There are always things you can try. Maybe PicBASIC's POT command.
only instead of using a potentiometer, try a fixed value resistor,
and maybe a reading with POT will vary enough with temperature
(if you had to produce multiple units and keep firmware identical).

Once with the Sony PSP I got random numbers by looking at the audio input

[HenrikOlsson]

Hi,
It all depends on where you want to introduce the variation.... If you by "detune" the oscillator mean to tweak the OSCTUNE register slightly between devices then you might as well program in a different seed from the get-go - there will be a unique program in each device either way.

Perhaps you can use something like the RCTime command with an external RC (duh...) network to generate the seed and rely on the tolerance of the R and the C to get the needed variance.

/Henrik.

EDIT: Art beat me to it while I was typing and doing some other things.

[Aussie Barry]

Great suggestions guys - thank you.

I will look at the POT/RCTime commands and choose wide tolerance components or random values to achieve the desired variation.

Cheers
Barry
VK2XBP

[Art]

I can't help thinking there would be some noise on the power you'd see with ADC.
Interference between ADC pins has always been a problem...

[Aussie Barry]

I am not sure how I would go about un-tapping the noise to produce a random output.
Would you care to expand your idea for me?

Cheers
Barry
VK2XBP

[Art]

If the device is mains powered there's a 50/60Hz clock on the transformer secondary
the way old LED digital clocks used to keep time from mains signal.
If you are looking at that with a pic that has an independent clock the results will vary.

If you can run an ADC from internal RC clock

DEFINE ADC_CLOCK 3

and the pic from xtal, and look at any clock or output signal
generated by the pic program with ADC the results will differ as clocks lose sync.

I would try the resistor Cap network first (timing cap discharge via resistor).

[Demon]

(Never done this)

What about reading a resistor on analog pin? A high value, maybe 100K, would that produce a reasonably wide range of seeds?

Robert

Edit: since no 2 resistors are exactly alike, the voltage should vary.

[Art]

It sounds like it would work.
That would be the first thing I'd try now, nice one.
.. and if not, then tapping the centre of a divider (two resistors from +ve to Gnd).
Still cheaper than timing a cap discharge.

I can't say I've tried to make two devices produce a different result,
just one device from one launch to the next.

(Never done this)

What about reading a resistor on analog pin? A high value, maybe 100K, would that produce a reasonably wide range of seeds?

Robert

Edit: since no 2 resistors are exactly alike, the voltage should vary.

[Demon]

Even better, use a LED and 330R resistor. You're bound to get different voltages and it serves as a power indicator.

Robert

[Aussie Barry]

Hi Guys,

All great ideas - thank you.
I have decided to program each PIC separately making subtle differences to LED flash rates and "off-time" periods to give an overall effect of randomness.
This is a one-off project that I am doing as a labour of love for my company. As such, I just want to get in and get out as quickly as possible

Cheers
Barry
VK2XBP

[HenrikOlsson]

Hi,
One possible issue with using the ADC is that the 12F508 being mentioned in the first post doesn't have one....

/Henrik.

[Art]

Still in general, it sounds like something to try.
You get 14 bit ADC with pic if I remember,
should be high enough resolution to vary with resistor tolerance.

I was keen to see how it panned out without doing it myself

[HenrikOlsson]

As long as we stick to 8-bit PICs (which is what PBP supports) there's a quite a selection devices with 12bit ADC and two devices with 16bit ADC (18F8xJ72). All of them are enhanced 16F1xxx or 18F parts though, the smallest I could find thru a quick look is 28pin.

/Henrik.

[Aussie Barry]

Hi All,

So much has happened in the last week or so...
In typical fashion, the customer (my company on this occasion) has requested "additional functions" to be included which are above and beyond the original scope of work. The degree of modification has required a complete re-design.
I won't bore you with the trivial details but the system now requires three separate LED flash sequences AND an auto function to scroll through the three stand-alone sequences.
No - problems, just more time and code...

I have now moved to a PIC16F1503. I would still like to use some sort of random number generation routine to achieve a random display flash rate between the thirty two individual PIC's without having to separately programming them. I could take the easy way out and do it manually but I like the idea of coming up with something eloquent

Here is my thought:
I can use my MeLabs programmer to generate a unique serial number for each PIC that I program. I understand this is a straight forward process. I would like to my program to read this unique serial number and use it as the seed for the random number generation source.

Here is my question:
Can is this concept be taken to a reality or am I barking up the wrong tree?

Comments and suggestions greatly appreciated.

Cheers
Barry
VK2XBP

[Darrel Taylor]

Well, the short answer is YES.

The programmer can auto increment a serial number that gets programmed into Flash Memory.
That value can be read back with READCODE.

[Archangel]

Here is my thought:
I can use my MeLabs programmer to generate a unique serial number for each PIC that I program. I understand this is a straight forward process. I would like to my program to read this unique serial number and use it as the seed for the random number generation source.

I think this would be the same as giving the PIC a fixed seed in the code. You might try a subprogram to save the last number used and then shutting it down. At startup have it read that value from eeprom.

[Darrel Taylor]

I think this would be the same as giving the PIC a fixed seed in the code.

Exactly!
Using the U2's incrementing serial number ... Each PIC has a "Fixed Seed".
But each of the 32 PICs are guaranteed to have a different seed, therefore a different blink pattern on power-up.

They are all running the same sequence of 65535 pseudo random numbers, but they all start at a different point in that sequence.

[Aussie Barry]

Thanks for the sanity check guys
Glad to know I am on the right track.

I should be able to sort out the serial number start and incremental values but I am curious to know the best place to store the information in flash memory.
I will be totally honest - I am now working well beyond the limits of my knowledge base. A simple recommendation would be appreciated. A recommendation along with an explanation as to why would superb. I revel in every opportunity to learn something along the way.

Please note: I have RTFM. Reading is one thing, comprehending is something altogether different.

Cheers
Barry
VK2XBP

[Darrel Taylor]

I would suggest putting it at the end of Program Memory.

The 1503 has 2K words of flash, so two locations starting at 07FEh.
It will store the lowbyte and highbyte separately.

Temp   VAR WORD
Seed   VAR WORD

READCODE $7FE, Temp
Seed.LowByte = Temp.LowByte
READCODE $7FF, Temp
Seed.HighByte = Temp.LowByte

I don't have access to a 1503 today, but I think it should work.

[Aussie Barry]

Legendary response Darrel - thank you!

I will keep you posted with project milestones as they are reached.

Cheers
Barry
VK2XBP