All the uRADMonitor detectors were designed with a unique hardcoded identifier used to organise the datasets collected. Using this approach we were able to group together measurements collected from any given hardware unit, and display them to the unit owner or on the uRADMonitor frontend, like in this example. We named this identifier a “Device ID”, and those of you running uRADMonitor units are already accustomed to the numeric series starting with 11, 12 (model A) or 51 (KIT1). This technique worked perfectly for quite some time now, but it was difficult to push out firmware updates, as all firmware files had to be customised independently to a given Device ID. We had the same problem when producing the hardware, as each unit had to be flashed with its own firmware file, increasing the complexity of the entire process.

Dynamic IDs

Instead of using hardcoded IDs, the idea of having server allocated dynamic ids quickly emerged. It was presented on the forums, and with valuable community feedback it got shaped into a robust mechanism that can serve an increasing network of detectors. As of recently this mechanism was successfully implemented and future units will use it by default.

The mechanism

The Dynamic IDs work by establishing a two way communication with the uRADMonitor server. On its first transmission, the uRADMonitor detector sends encrypted data, presenting itself with a default ID and a given class. The class identifies the model of the uRADMonitor detector, either a Model A, KIT1, model D or any other uRADMonitor hardware. The server then checks the request, and if valid it allocates a new ID that is sent to the unit as a response. The unit saves the received ID to its non-volatile EEPROM memory, and will use that for any further transmissions.
Unused IDs belonging to units that went offline for a long period of time will expire so that the numbers return to the pool of allocatable IDs.

Finally, one last question remains. How can one identify a local unit if he or she doesn’t know the ID? This problem is solved with the implementation of the Dashboard, a new frontend component that shows all units that share the same IP with the user and allows assigning them to the user’s account for future management regardless of location.