what exactly is your gateway (dragino + rpi ?)
It is a rpi3 with LoRa concentrator like this one https://www.thethingsnetwork.org/labs/story/how-to-build-your-own-lorawan-gateway
Moreover I tested this lora server: Alternative LoRaWAN network-server: loraserver.io (with packet forwarder and gateway bridge).
It works well with ABP, if I set all the 8 channels, the node uses all the 8 channels. OTAA works well the only point is that I would like to use all the 8 lora channels also with OTAA, not only the first 3 channels
Thx
I tested some time ago also it on TTN and I got the same outcome.
this is the TTN forum so for support on the Brocaar loraserver better to ask there
maybe there are here some topics off interest
.
Hello all,
My first message here, not sure if this is the right place. Nevertheless:
I have an Adafruit feather M0 and followed various online manuals (mainly https://community.hiveeyes.org/t/using-the-adafruit-feather-m0-lora-rfm95-and-ttn/528) to adapt and load the ttn-otaa sketch. By accident in the sketch I copied a DevEUI that I previously registered with a TTN Uno board and messages came through marvelously.
Then I registered a new device, had ttn generate a DevEUI and put that in the sketch (with the byte order reversed as I did before). I uploaded the sketch and ⌠nothing.
Reverting again to the previous DevEUI in my sketch, it immediately worked again. Very reproducible.
Does anyone have an idea what I might have overlooked? Why doesnât it work with a newly generated and registered DevEUI?
Thanks!
Wouter.
first thought : the TTN uno board doesnât use LMIC while the Adafruit feather does.
So these should be 2 totally different sketches ⌠not only the keys.
Thanks for the thought.
Indeed. I used entirely different code on the TTN Uno and the Feather M0. In the sketch for the Feather M0 I got messages through to my ttn console if I used the DevEUI that I previously used for the Uno. If I then only change the DevEUI in that sketch (a new one generated by TTN), it doesnât work.
In the TTN Uno DevEUI is determined by the manufacturer. Do I understand correctly that for the LMIC route with an RFM95 it is not and it needs to be assigned in the sketch? If so, why does one DevEUI work (the one I accidentally copied from an entirely different node) and another (generated by ttn) does not?
you copied the key to the new lmic device⌠TTN thinks it still the first device you registered , with TTN UNO the keys are in the main module the rn2483, so if you use the generated key for that node and add it to a sketch for another TTN uno it wonât work.
Understood. This helps me understand a little bit better.
So, because of re-using the DevEUI of the Uno, TTN thinks I am still using that TTN UNO node, whereas I am actually using the feather M0. Since TTN receives the messages, this at least tells me that all the Feather hard- and software works.
What is puzzling me is when I then (i) register a new device on TTN in the same application, (ii) have TTN generate a new DevEUI, (iii) change only the DevEUI in the sketch, and (iv) upload the sketch to the feather, I donât see any messages coming on on the TTN console for that application.
Ah, thank you. So the TTN generate button is for ABP only! Does the feather/RFN95 have an hardware defined DevEUI and how do I find out about it? Guess I have some more reading/understanding to do.
1 Like
When you register a new device the APP key will be different, did you update both the EUI to the generated value and the App key?
I never thought of the App key being different (assuming, wrongly so, that it registers to the same application). Will give it a try. Thank you!
⌠SOLVED ⌠Many thanks!
Hello! I have a custom single channel LoRa Gateway and I started with ABP which worked fine. Now I am trying the OTAA and although I can see the first packet both on my gateway console
Packet RSSI: -67, RSSI: -94, SNR: 9, Length: 23
rxpk update: {ârxpkâ:[{âtmstâ:4046223465,âchanâ:0,ârfchâ:0,âfreqâ:868.100000,âstatâ:1,âmoduâ:âLORAâ,âdatrâ:âSF7BW125â,âcodrâ:â4/5â,âlsnrâ:9,ârssiâ:-67,âsizeâ:23,âdataâ:âAAluftWgAgp4UZD9jbfr4eSA77r9ZZs=â}]}
and on the TTN gateway console
{ "gw_id": "eui-b827ebffff0292e1", "payload": "AAHQs3DyQJAE95/ZURhoXq2/oqb2UMM=", "dev_eui": "AD5E681851D99FF7", "lora": { "spreading_factor": 7, "bandwidth": 125, "air_time": 61696000 }, "coding_rate": "4/5", "timestamp": "2019-01-23T18:05:42.068Z", "rssi": -67, "snr": 9, "app_eui": "049040F270B3D001", "frequency": 868100000 }
But I donât see the rest of the process to continue. In example the Serial monitor repeats this state EV_TXSTART
20:05:34.479 -> Starting
20:05:34.547 -> Packet queued
20:05:34.547 -> 196: EV_JOINING
20:05:41.512 -> 438616: EV_TXSTART
20:06:50.618 -> 4768566: EV_TXSTART
20:07:57.008 -> 8927362: EV_TXSTART
...
I have copy pasted very carefully the OTAA credentials to the sketch.
Also I have made these configurations to âagreeâ with EU frequencies and the Arduino Uno as âMobilefishâ suggests
// project-specific definitions
//#define CFG_eu868 1
#define CFG_eu868 1
//#define CFG_au921 1
//#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP /* for as923-JP */
//#define CFG_in866 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS
#define DISABLE_PING
#define DISABLE_BEACONS
#define LMIC_DEBUG_LEVEL 0
#define USE_IDEETRON_AES
Also, how the different app eui and dev eui accross three continuous messages is explained?
Anyway, no matter my efforts I still have not achieved a OTAA connection, if anyone could help me that would be great. Thank you!
Single channel gateways are not LoRaWAN specs conform. You canât use a single channel gateway for OTA.
Unless TTN has changed detection for single channel gateways, then: if the single channel gateway supports downlinks, then it also supports OTAA.
But indeed, single channel gateways are not compliant and using them needs a lot of tweaking, especially in the nodes to force them to use only that single channel (and SF).
As TTN is not even showing the Join Accept in the gatewayâs Traffic page, maybe:
- It does not recognize the AppEUI/DevEUI or cannot validate the MIC from the Join Request. Am I right to assume nothing shows in the applicationâs Data page in TTN Console? That might indicate the AppKey, AppEUI and/or DevEUI are wrong. (See Hex, lsb or msb?)
- It refuses the DevNonce, see OTAA shows "Activation DevNonce not valid: already used".
- It refuses the single channel gateway to transmit the Join Accept, as it somehow detected it does not support downlinks. Does your gateway even support downlinks?
Clicking on a Join Request might give you some more information in the Trace details.
Is one of them even what youâre expecting? (Every TTN provided AppEUI starts with 0x70B3D57ED, so it seems the third might be the expected one?) Are you sure all are transmitted by your device?
Youâll need to show us the code, and tell us which LMIC youâre using, and tell us what earlier suggestions from this topic youâve tried. (It seems GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment might be the most up to date?)
And if yes: what if you move the node a few meters away from the gateway?
First of all thank you for the fast response! I will try to give you as many details I can.
About typos an lsb/msb on the keys, I have checked them so many times that I donât think itâs that.
As for the DevNonce message, I donât see it in the TTN console.
As for the downlinks, that is interesting and maybe the problem is here. How do I check if my gateway supports downlinks? Is this part of the configuration of the packet forwarder or the configuration in TTN gateway settings?
About the transmitted packets that I see in the TTN gateway console, there is one for every time I power on the node. Also, the code of my node is based on the https://github.com/mcci-catena/arduino-lmic
#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>
#ifdef COMPILE_REGRESSION_TEST
# define FILLMEIN 0
#else
# warning "You must replace the values marked FILLMEIN with real values from the TTN control panel!"
# define FILLMEIN (#dont edit this, edit the lines that use FILLMEIN)
#endif
static const u1_t PROGMEM APPEUI[8]={ 0x09, 0x6E, 0x01, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}
static const u1_t PROGMEM DEVEUI[8]={ 0xA0, 0x02, 0xF2, 0x40, 0x0A, 0x78, 0x90, 0x04 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}
static const u1_t PROGMEM APPKEY[16] = { 0x01, 0x12, 0xC5, 0x5E, 0x1B, 0x05, 0xBD, 0x22, 0x60, 0xF9, 0xC7, 0x48, 0x0F, 0x55, 0x03, 0x63 };
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}
static uint8_t mydata[] = "Hello, world! OTAA";
static osjob_t sendjob;
const unsigned TX_INTERVAL = 20;
const lmic_pinmap lmic_pins = {
.nss = 6,
.rxtx = LMIC_UNUSED_PIN,
.rst = 5,
.dio = {2, 3, 4},
};
void onEvent (ev_t ev) {
Serial.print(os_getTime());
Serial.print(": ");
switch(ev) {
case EV_SCAN_TIMEOUT:
Serial.println(F("EV_SCAN_TIMEOUT"));
break;
case EV_BEACON_FOUND:
Serial.println(F("EV_BEACON_FOUND"));
break;
case EV_BEACON_MISSED:
Serial.println(F("EV_BEACON_MISSED"));
break;
case EV_BEACON_TRACKED:
Serial.println(F("EV_BEACON_TRACKED"));
break;
case EV_JOINING:
Serial.println(F("EV_JOINING"));
break;
case EV_JOINED:
Serial.println(F("EV_JOINED"));
{
u4_t netid = 0;
devaddr_t devaddr = 0;
u1_t nwkKey[16];
u1_t artKey[16];
LMIC_getSessionKeys(&netid, &devaddr, nwkKey, artKey);
Serial.print("netid: ");
Serial.println(netid, DEC);
Serial.print("devaddr: ");
Serial.println(devaddr, HEX);
Serial.print("artKey: ");
for (int i=0; i<sizeof(artKey); ++i) {
Serial.print(artKey[i], HEX);
}
Serial.println("");
Serial.print("nwkKey: ");
for (int i=0; i<sizeof(nwkKey); ++i) {
Serial.print(nwkKey[i], HEX);
}
Serial.println("");
}
LMIC_setLinkCheckMode(0);
break;
case EV_JOIN_FAILED:
Serial.println(F("EV_JOIN_FAILED"));
break;
case EV_REJOIN_FAILED:
Serial.println(F("EV_REJOIN_FAILED"));
break;
case EV_TXCOMPLETE:
Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
if (LMIC.txrxFlags & TXRX_ACK)
Serial.println(F("Received ack"));
if (LMIC.dataLen) {
Serial.print(F("Received "));
Serial.print(LMIC.dataLen);
Serial.println(F(" bytes of payload"));
}
os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
break;
case EV_LOST_TSYNC:
Serial.println(F("EV_LOST_TSYNC"));
break;
case EV_RESET:
Serial.println(F("EV_RESET"));
break;
case EV_RXCOMPLETE:
Serial.println(F("EV_RXCOMPLETE"));
break;
case EV_LINK_DEAD:
Serial.println(F("EV_LINK_DEAD"));
break;
case EV_LINK_ALIVE:
Serial.println(F("EV_LINK_ALIVE"));
break;
case EV_TXSTART:
Serial.println(F("EV_TXSTART"));
break;
default:
Serial.print(F("Unknown event: "));
Serial.println((unsigned) ev);
break;
}
}
void do_send(osjob_t* j){
if (LMIC.opmode & OP_TXRXPEND) {
Serial.println(F("OP_TXRXPEND, not sending"));
} else {
LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);
Serial.println(F("Packet queued"));
}
}
void setup() {
Serial.begin(9600);
Serial.println(F("Starting"));
#ifdef VCC_ENABLE
pinMode(VCC_ENABLE, OUTPUT);
digitalWrite(VCC_ENABLE, HIGH);
delay(1000);
#endif
os_init();
LMIC_reset();
do_send(&sendjob);
}
void loop() {
os_runloop_once();
}
Iâm sure the software comes with some documentation? Itâs not so much in the configuration of the gateway/packet forwarder, but simply a feature which should be documented when supported. When in doubt then tell us what youâre using.
APPEUI looks good, that should indeed be LSB in LMIC, so end with 0x7ED5B370 for TTN. Good.
DEVEUI should be LSB too, but APPKEY should be MSB. Did you check that? (As an aside, Iâd leave the comments for the EUIs and key in placeâŚ)
And that one has the same AppEUI each time, I assume? So the other two from the screenshot are just some other LoRa or LoRaWAN packets that the gateway received?
So thereâs nothing special in the Trace part of the Join Request, when clicking it in TTN Console?