DId you get the EUI of RFM95? if yes, just let me know how? I am using Arduino UNO as a micro controller with RFM95.
Since in the last 4 years no-one seems to have discovered a EUI in the LoRa devices, and its not mentioned in the datasheet, one presumes there isn’t one.
If your using a 5V UNO with the RFM95, dont forget the need for logic level conversion circuits.
There is no unique ID in either the RFM95 or an ATmega based Arduino; you’ll need to generate a Dev EUI (I believe you can have one generated when you register a device in the TTN console) and then include that in your sketch.
Beware that the Uno isn’t a very good host platform for bare-radio LoRaWAN - not much memory so it can be challenge to fit code versions recent enough to include key bugfixes, and yes, the signal voltage level is also wrong needing translation.
Most LoRaWAN nodes use ARM core processors (even if under Arduino), a few use ESP8266 or ESP32.
1 Like
A method that I’ve used for management of OTAA parameters on Arduino platform:
- OTAA parameters (device EUI, applicaton EUI and application key) are all generated on the TTN side
- OTAA parameters are stored in (simulated) EEPROM on the node
- the arduino node runs a simple command interpreter that allows you to set them over the serial port
Advantages:
- the source code doesn’t hardcode the OTAA parameters, so can use the same firmware on multiple devices without modification
- firmware updates don’t erase the EEPROM, so you need to configure each device only once and safely do firmware updates after that, keeping the settings intact.
2 Likes
This is valid for TTN V2 but in V3 (TTS) it asks for device EUI. Can we write whatever we like?
You should use a valid EUI you own of course to avoid conflicts with those assigned by vendors.
It would be nice if TTN could generate one as available in V2. (@johan)
2 Likes
Generating DevEUI´s would be really helpful. I dont know what to fill in there for self-programmed devices.
By migrating devices to V3, I also want to change from ABP (which most of my devices do) to OTAA. But I can´t do this without knowing what to use as DevEUI.
I guess, using DevEUI´s generated in V2 are not reasonable in V3?
You should be fine using the generated values from V2. When people migrate OTAA devices for which the values have been generated that’s what happens as well.
1 Like
Ah, I see. Great! 
V2 doesn’t issue DevEUIs, only AppEUIs. V3 doesn’t do that, because V3 supports the all-zeros AppEUI/JoinEUI 0000000000000000.
Sorry, in V2 I’m able to have the console generate a DevEUI, note ‘this field will be generated’ in the DevEUI field.
1 Like
Yeah OK, randomly generated, indeed. Fair enough. That’s a bad practice anyway.
We could start issuing DevEUIs from our MAC-S block and purchase a new one when we ran out, with some sort of maximum per application or something.
I had a hiccup getting my auntie’s LMiC Adafruit Feather RFM95 with all zeros - no worky.
I’ll revisit it now I know more about breaking things less.
Mmm, I guess that getting a valid DevEUI is what most users were expecting (for years already) when they request the V2 Console to generate a DevEUI for their device.
Automatic creation of DevEUI in V2 Console has been the standard procedure for almost all DIY nodes (most use hardware that provides no DevEUI).
Are DevEUI’s created in the current V3 console still randomly generated?
Aha! Well, at least we can blame The Things Network for applying that bad practice. 
1 Like
I would suggest a maximum per user. If a user needs a lot of them they can buy their own MAC-S, those are not that expensive for a commercial entity but too much for hobbyist. (I would rather have the hobbyist spend money on decent hardware that is capable of LoRaWAN compliance 
)
Isn’t this the same as the pre-programmed EUI-64 in Microchip’s 24AA025E64 I2C Serial EEPROM? @Charles included support for that EEPROM in his Mini-LoRa design for providing a unique DevEUI for every device.
The EEPROM costs around € 0,40 (in low volumes) and that includes the hardware so the EUI-64 should only be a fraction of that price.
It’s valid LoRaWAN, but indeed I can imagine some lightweight end device libraries don’t see a difference between zeros and “not set”.
Makes sense. Issue is filed, you can subscribe here: Issue DevEUI from range with maximum per application · Issue #3750 · TheThingsNetwork/lorawan-stack · GitHub
Not really though, because in The Things Network V2 and V3, only the combination of AppEUI/JoinEUI and DevEUI is unique. Since V2 did issue a globally AppEUI to each application, it didn’t really matter what the DevEUI is. With V3, since we don’t issue an AppEUI/JoinEUI, so then it does matter what the DevEUI is, and it shouldn’t be random.
Agreed, but in the context of applications we don’t have users, only a bunch of collaborators, and keeping maxes across all of them is not feasible.
It’s really cheap indeed. 28 degrees of freedom costs USD 780, so roughly 0,000003 cts per DevEUI. And it gets much cheaper in volume, like the OUI / MAC-L blocks that most vendors have.
2 Likes
So that will be around 260 million DevEUI’s (per USD 780).
Are you saying that devices without real DevEUIs should set this field to zero?
No, there must be a DevEUI in V3.
1 Like