For development this should be okay.
but can you buy just a few of these chips ?
maybe in the future in the TTN webshop… a special 'hard to get for hobbyist chip page with special discounts ’ 
Or start selling EUIs in the webshop
1 Like
unavoidable, there is no free in free beer in the future imho
** from the perspective of the hardware designer, its off course very important to know now, if your integrated micro chip 24AA02E64 in your node design, are worthless in the (near) future*
Aren’t there any cheap RFID / NFC tags with EUIs pre-burned onto them? If so, it would serve dual purpose, not only gives you an id, but also makes it easy to get the id of a sensor by just moving your phone close to it.
The trick with free beer is usually that someone else pays for it.
For AppEUIs we solved this by buying a block of EUIs. Maybe we could crowdfund another block for DevEUIs, but it’s probably easier to just buy some cheap (less €0.30) chips that have an EUI. Just search for “EUI” on farnell.com 
3 Likes
exactly, but you cannot buy just 10 chips… thats why I suggested the TTN webshop to the rescue, maybe in cooperation with Micro Chip / Semtech , maybe a combined purchase effort…or what you suggest a crowdfund.
You can even buy singles at Farnell if you are a business customer, so 10 is not problem at all. For Dutch private customers I know of at least one electronics parts retailer willing to order and resell parts from Farnell, however the overhead cost for each order would make the chips relatively expensive.
1 Like
I like the idea of crowdfunding a block of DevEUI’s. How about if TTN buys these and offers them on the TTN webshop? I’ll buy 10 at least (for starters). 
same here.
I didn’t understand this … why becoming worthless??
Thanks
http://www.microchipdirect.com/ProductSearch.aspx?keywords=24AA02E64
Starting at €0.19 for onesies, excluding the postage
Cheers,
2 Likes
You’ll have to judge whether you want to use a random ID. However, the definition of EUI-64 allows for this. The definition is given in chapter 8 of the IEEE-802 spec (freely available at http://standards.ieee.org/getieee802/download/802-2014.pdf).
In section 8.2, they describe the u/l bit (bit 1) of byte 0 of EUI-64. If you set that bit, you have a “locally administered address”. Bit 0 always has to be zero for addresses. So a legitimate way of generating a random address, with very low probability of collision, is to generate 8 random bytes, then set bit 1 of byte 0, clear bit 0 of byte 0. On Ubuntu, this simple program will do what you need.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/fcntl.h>
int main(int ac, char **av) {
int fd, i;
unsigned char eui[8];
fd = open("/dev/random", O_RDONLY);
if (fd < 0) {
perror("can't open /dev/random");
exit(1);
}
if (read(fd, eui, sizeof(eui)) != sizeof(eui)) {
fprintf(stderr, "couldn't read %zu bytes\n", sizeof(eui));
exit(1);
}
eui[0] = (eui[0] & ~1) | 2;
for (i = 0; i < sizeof(eui); ++i) {
printf("%02X%c", eui[i], i == sizeof(eui)-1 ? '\n' : '-');
}
return 0;
}
8 Likes
I’ve posted the program on https://github.com/things-nyc/random-eui64 in case anyone is interested. If I have time, I’ll update it to do simple things like generate a block, and allow you to omit the “-” in the output, which is often convenient when copying/pasting.
3 Likes
A more common, though deprecated, approach seems to be to insert 0xFFFE in the middle; see “Mapping an EUI-48 to an EUI-64” in IEEE SA - Registration Authority, emphasis for the past tense mine:
Some standards have described how an EUI-48 value could be mapped to an EUI-64, as follows: Let the six octets of the EUI-48 be labeled eui48[0] through eui48[5]. Let the eight octets of the mapped EUI-64 be labeled eui64[0] through eui64[7]. The following mapping has been described:
eui64[0] = eui48[0]
eui64[1] = eui48[1]
eui64[2] = eui48[2]
eui64[3] = FFhex
eui64[4] = FEhex or eui64[4] = FFhex
eui64[5] = eui48[3]
eui64[6] = eui48[4]
eui64[7] = eui48[5]In other words, the EUI-64 value was generated by inserting either the value FFFEhex or the value FFFFhex in between eui48[2] and eui48[3].
But beware it also notes this is deprecated, emphasis mine:
Mapping an EUI-48 assigned with an MA-S/OUI-36 or MA-M assignment to an EUI-64 potentially creates a duplicate of an EUI-64 assigned with a different MA-S/OUI-36 or MA-M. The IEEE RA has taken appropriate actions to mitigate creation of duplicates based on this mapping but, to protect the integrity of EUI-64 identifiers, this mapping is deprecated.
Earlier it stated, again emphasis mine:
The mapping described here is deprecated and it should not be used in new applications as it includes an unacceptable probability of duplicating an EUI-64.
(It’s also used in IPv6 but there it also sets a specific bit which in IPv6 defines universal/global scope, so would probably not suffer any chances of duplicating IPv6 addresses.)
1 Like
Just to add up to the excellent response of @terrillmoore : DO NOT USE A FULLY RANDOM EUI64! Sorry for the all caps, but I see people sometimes acting in very un-neighborly ways on those matters, because they ignore that there are a simple ways to be neighborly.
Let’s say the EUI64 is in the following format Hh:HH:HH:HH:HH:HH:HH (canonical representation, in network order, aka MSB first, aka. Big Endian, aka “the way people write numbers in left-to-right writing systems”). It’s a 16-digit hexadecimal number, and the second digit (aka the lower nibble of the most significant byte), represented with the lower case ‘h’, has a special meaning. The IEEE has a document on the matter, https://standards.ieee.org/develop/regauth/tut/eui.pdf (top of page 4) but it’s lacking some nice examples.
First, let’s assume we can ignore “group” addresses so the ‘M’ bit is always 0. The IEEE then consider an address can be of two types (depending on the ‘X’ bit):
- fist type is a globally administrated address. This type of address is guaranteed unique, assuming people follow the rules and don’t do whatever they want. It’s composed of a 24 or 36 bit OUI, followed by some bits managed by the owner of the OUI. In that case, the ‘h’ digit of the address is always 0, 4, 8 or C.
- second type is a locally administrated address. There, the IEEE say “do whatever you want, but please identify your address as a locally administrated one”. In that case, the ‘h’ digit of the address is always 2, 6, A or E.
To sum up, for personal projects, it’s perfectly ok to use a nearly randomly generated address, just make sure to force the second hexadecimal digit of the address to be ‘2’. With 60 bits left to pick randomly, the probability of collision is really really low, assuming you properly seed the rand() function of your favorite language 
As soon as your project has any chance of having a real customer, just contact the IEEE. Getting an OUI36 is reasonably cheap and simple, even for a very small business.
Yup, this 48 ↔ 64 mapping doesn’t make sense anymore, specially for manufacturers with an OUI36.
Would it be useful to have ttn give out locally administered DevEUI numbers? This way, these numbers are at least generated in a correct way, and you don’t have the problem of people not knowing that certain bits have to be set in a certain way, or making other mistakes or wrong assumptions that jeopardize the uniqueness of the ID’s. And there is no need to buy a block.
That would be quite convenient, yes, to be able to generate and auto-fill a valid locally administrated DevEUI when declaring a new device.