where : ibrtses embedded

Using dynamic ID's

In distributed network systems it may happen that ID's have to be assigned dynamically. Eg

As usual, a device may only send a packet when a master requests it to do so. This means a device cannot broadcast a message such as 'hello, I'm here ! ID#A2W4567VZ'. The network has to provide broadcasts though. The broadcast is used exclusively by the master. It is obvious that only one device can answer at a time, otherwise the reply becomes corrupted. Assigning a dynamic ID requires a series of steps and a few commands. Both, the master and the slave device act as state machines. The master has to be able to detect the sending of a corruped reply.

The command, here simply named AssignID is set up similar to :

field value meaning
STX   header
Length   length of packet
SRC   ID of the master
DST Broadcast address  
Msg AssignID  
data[1] new ID  
data[2] probability  
data[3] assign unknown / assign all  
CRC   checksum to detect valid packet

The device state machine :

state event action next state

receive AssignID and probability evaluates to 1

none possibly assigned
possibly assigned receive any command to this ID reply to this command probably assigned
possibly assigned timeout none unassigned
probably assigned receive any command to this ID reply to this command assigned
probably assigned timeout none unassigned

The master state machine, concerning this try :

state event action next state
idle timer make new ID and send AssignID 1
1 timer send any command to new ID 2
2 receive valid reply send any command to new ID 3
2 receive invalid reply cache ID for non use while timeout of the device 1
2 timeout discard ID 1
3 receive valid reply add new device to list of devices 1
3 receive invalid reply retry 3
3 timeout retry 3
3 retries expired mark device  

The state machines require some finish, that they are water tight.This depends on the actual implementation.

The probability mechanism

As there may be more than one device in the unassigned state, not all of them should reply to an AssignID request. This can be achieved with a random number generator. The device calculates a random number each time an AssignID request is received. The probability is a mask, ANDed with the random number gives zero or not. A zero means reply to the request. Note that the random number must not be just an incrementing counter as at powerup, all devices would have the same value and it would repeatedly be so. Use a random number XOR the serial number or such a thing.


 RandomNumber:=Random16() XOR Serial;              // random number 0x0000..0xFFFF
 //generate mask from probability   
 Mask:=(0xFFFF << Probability);                    // 0 -> 0xFFFF, 15 -> 0x8000
 Reply_To_Assign:=((RandomNumber AND Mask)<>0);	   // reply if not zero
The probabilty here is in fact inverse - but the point is shown.

The outer loop of the master

The master does the AssignID from time to time. A bit more often when more that average invalid replies are encountered during AssignID. In a loop the probability is increased, when no reply comes forth, and lowered when the number of invalid replies rise.

The AssignID is best run in an own thread (task). It should run exclusively, meaning no other commands may interfere.


Questions ?
Feedback ?

sponsored links


last updated: 12.april.00

Copyright (99,2000) Ing.Büro R.Tschaggelar