// Original code as provided, with minor renaming/reformatting/editing as required.
//X ABC Algorithm Random Number Generator for 8-Bit Devices:
//This is a small PRNG, experimentally verified to have at least a 50 million byte period
//by generating 50 million bytes and observing that there were no overlapping sequences and repeats.
//This generator passes serial correlation, entropy , Monte Carlo Pi value, arithmetic mean,
//And many other statistical tests. This generator may have a period of up to 2^32, but this has
//not been verified.
// By XORing 3 bytes into the a,b, and c registers, you can add in entropy from
//an external source easily.
//This generator is free to use, but is not suitable for cryptography due to its short period(by
//cryptographic standards) and simple construction. No attempt was made to make this generator
// suitable for cryptographic use.
//Due to the use of a constant counter, the generator should be resistant to latching up.
//A significant performance gain is had in that the x variable is only ever incremented.
//Only 4 bytes of ram are needed for the internal state, and generating a byte requires 3 XORs ,
//2 ADDs, one bit shift right , and one increment. Difficult or slow operations like multiply, etc
//were avoided for maximum speed on ultra low power devices.
void seedRNG8(uint8_t s1, uint8_t s2, uint8_t s3) // Originally init_rng(s1,s2,s3) //Can also be used to seed the rng with more entropy during use.
//XOR new entropy into key state
a = (a^c^x);
b = (b+a);
c = ((c+(b>>1))^a);
Nice project! Keep in mind I’m not a cryptographer and that algorithm hasn’t been thoroughly tested except as to the statistical properties and average period, it could still have a short cycle somewhere. That should never occur if you are constantly reserving with new entropy though. It’s mostly designed for speed, which it does very well. It looks like you mention avoiding TX collisions as one of the main reasons for using randomness. I am actually currently working on a network protocol called WBTV(it’s on my github) that uses random CSMA to avoid collisions on the UART. I decided that the RNG wasnt a bottleneck so I wound up going with xorshift 32 for that one, just on account of it being more standard and better understood. If you are receiving messages, the exact arrival times of new messages are unpredictable because each device has its own clock that drifts, and you can get a little bit of entropy there. RF signal strength, temperature, etc are also good. I actually do use the XABC algorithm when I’m doing stuff on the pic10 or something where the time to run an xorshift round would be way way too high, but generally prefer something more thoroughly analysed if I don’t need speed. Xorshift itself has issues with quality too, but it’s a good compromise. Some things And Some words! <firstname.lastname@example.org> wrote: