particularly where low-cost RF is concerned, is that (a) you don't have a way to distinguish between collisions and simply noise-damaged packets, (b) and the baud rate is necessarily low, (c) and there's no way to distinguish between a collision with another station or the tractor across the street starting up.

Since slave addresses in the proposed approach are randomly distributed, and not necessarily limited (the O/P in the original thread didn't say how many, max) and the range over which the random distribution can occur is extremely large, (10 billion, IIRC) the search will take a very long time at a typical rate (8 kbps, max) for low-cost RF systems. More costly systems, costing, perhaps, 6x as much, might support a maximal rate of 250kbps (e.g. Zigbee) but that might still take a while.

I suspect that one possibly optimal way to handle this would be for the master to search/poll/whatever, however long that takes, in order to ascertain the device addresses each time a new slave is added, and then IAP it into FLASH so it's there in the future.

Given that the already-detected slave addresses are in FLASH, one can, quite effectively tell each and every one of them to "shut up" until further notice. That way there will be no collisions, only noise-corrupted messages and one "good" one. Once the ditital key address is in a FLASH table, it needn't be searched-for again, barring some catastrophe. After identifying the newly added slave(s) the previously known ones can be remotely enabled again by the master.

If the exact digital ID's of the slaves are knowable before deployment, then their addresses can be entered in a table in FLASH before their deployment, which, again, will make the process much less painful.

RE