Ahh -- Yes I recall now, same problem on the SI44xx chips. So maybe a "bind" mode that uses a know fixed ID (maybe all F's) in conjunction with a random PAN_ID that is compiled into the gateway only. The randomness is controlled by the build process or it could be a sequenced number etc. Bind mode on the gateway would use the known fixed ID and it would only respond to GetPan_ID requests from nodes. The mode would be entered during boot, detected by a button press or jumper. The gateway would not exit bind mode until it is rebooted with the jumper removed. The end/router nodes would be built with the fixed ID programmed in the EEprom (hence all F's) and would therefore know that it has not gotten a PAN_ID yet. It would then enter a loop asking for a PAN_ID from the gateway, using said fixed ID . The end/router node would indicate a successful exchange of the PAN_ID by setting it's LED (on PB5/SCK ) and entering an indefinite loop after storing the PAN_ID in the eeprom. The end/router would have an option to ease the EEPROM during the boot of the node by detecting a switch closure or jumper to force a rebind to a different network. So from a user's point of view to bind a node you place a jumper on the gateway and the node then power both. Wait until you get a green light on the node. at which point you remove the jumpers and reset both. When playing with the PAN ID yesterday I noticed that the lower 8 bits (I think) showed some strange behavior. Is the library using the data pipes, and therefore 7:0 is not actually usable in the PANID? Gary