How to find the DevEUI on a RFM95

Hello,

Now that I have the RFM95 working with a WeMos D1 Mini, I am trying find out the Dev EUI of the device. I understand that it is a 64bit address hard coded or programmed into each radio chip. Is that correct?

Using the lmic library, is there an easy way to display the address? I tried using the showStatus method in the TTN DeviceInfo example but it just hangs and does not display the Dev EUI.

Any pointers are greately appreciated.

Mark

As far as I know, there is no unique id in an RFM95.

There is however one in the ESP8266 (which is inside the Wemos D1 mini). You can access it as follows:
ESP.getChipId()
See also
https://github.com/esp8266/Arduino/blob/master/doc/libraries.md#esp-specific-apis

The unique id is 4 bytes long. This id is also used to create the default ESP wifi MAC address by adding the ESP vendor id before it.

replying to myself:
It looks the unique id of an ESP8266 is actually only 3 bytes long, the one in my esp8266 has 0x00 as the first byte. This might still be unique enough for your use case.

Apparently the first few bytes of the MAC address are not always the same, so if you can somehow read the MAC address of the ESP8266 module, that would be the closest thing to a unique id.

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! :slight_smile:

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. :sunglasses:

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 :smile:)

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