RE: Random number generator in assembler

Hi David

Thanks for the very informed reply. I had decided to use the ID to encode a
send time. Lucky for me I do not have a busy network. I am also looking at
the RSSI prior to a send to avoid possible collisions. In another project I
may get the RF traffic will increase so I need to do a little more in
relation to collisions. I will take a better look at the hash function you
mentioned. 
I have volume I & II of Knuth. I agree it is not light reading but very
interesting to see how he does things. 


Thanks

Peter

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Tuesday, 9 June 2015 4:15 PM
To: [email protected]
Subject: Re: [msp430] Random number generator in assembler

Hi,

Knuth is the ultimate reference for many algorithms, but The Art of Computer
Programming is not light reading.  If you are not heavily into theoretical
computing, don't bother trying to use them as sources for something like
this.

What you have to do is think about the /real/ problem, not jump to a
solution and try to implement it.  You don't need a random number generator
- so trying to make something that will generate good quality high entropy
pseudo-random numbers will mean extra effort and extra risk of getting
things wrong.

You have a bunch of nodes that are going to send sometime between 1200 and
1300.  That's a period of 3600 seconds.  Each has a unique node number
between 1 and 65000.  If the radio transmission takes less than
50 ms, then your solution is easy - wait (id * 50 ms) before sending.
That will also guarantee that there won't be collisions, which would
otherwise always be a risk with random delays.  Case closed.


If send times are longer than 50 ms, there will always be a risk of
collisions.  You will need some way to spread out the nodes amongst
appropriately timed slots - but it does not need to be random.  In fact, it
is better if it is /not/ random.  Use a hash function on the ID with an
initial fixed salt value.  If two nodes collide, they should each pick a
different salt value - they will not collide again.  (In theory, they could
now collide with other nodes - there is no limit to the maximum length of
such collision chains, but in practice the likelihood of collision decreases
at each step unless you have too many nodes.) Once the nodes have settled on
their slot numbers, stick to them.

An easy hash function is something like crc16(idLo ++ idHi ++ saltLo ++
saltHi), since there's a fair chance you already have code for a crc
calculation for adding checksums to your telegrams.

mvh.,

David





On 09/06/15 03:28, 'Peter Grey' [email protected] [msp430] wrote:
>  
> 
> Thank you to all who replied. It is appreciated. I am going to have a 
> look at SLAA338 and I found I have a few books by Donald Knuth with 
> references to random number generation. It will keep me busy over a 
> few evenings!
> 
>  
> 
> Peter
> 
>  
> 
> *From:*[email protected] [mailto:[email protected]]
> *Sent:* Tuesday, 9 June 2015 1:42 AM
> *To:* [email protected]
> *S ubject:* Re: [msp430] Random number generator in assembler
> 
>  
> 
> 
> 
> XOR-SHIFT is one technique, wikipedia describes it .
> 
> Brian
> 
> 'Peter Grey' [email protected] <mailto:[email protected]> 
> [msp430] wrote:
> 
>      
> 
>     Does anyone know of a simple way of randomising some data in
>     assembler. I want to send a RF signal between noon and 1300 hours.
>     There are quite a few transmitters and I do not want them to all
>     send off at once. Each has a unique ID numbered from 1-65000.
> 
>      
> 
>     TIA
> 
>      
> 
>     Peter< o>
> 
>      
> 
>     Peter Grey
> 
> 
> 


------------------------------------
Posted by: David Brown <[email protected]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[email protected]


------------------------------------

Yahoo Groups Links






------------------------------------
Posted by: "Peter Grey" <[email protected]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[email protected]