I guess the emphasis is at “to make sure that the joining process will start”?
Without explicitly calling this, the very first message that is sent should also trigger OTAA. That’s also written in a comment of Matthijs’ ttn-ota.ino example, and works for me:
void setup() {
...
os_init();
LMIC_reset();
// Start job (sending automatically starts OTAA too)
do_send(&sendjob);
}
Is there a way that I can test if the JOIN was successful? In other words if the EV_JOINED event happened?
I.e. by testing LMIC.opmode or OP_TXRXPEND or similar?
Starting
Packet queued
181: EV_JOINING
I used lora gateway esp8266 single channel.
I’m having this problem. How do I solve it?
Does this issue require a gateway response?
Have you solved this problem yet?
Hi Kibet:disappointed_relieved:,
I am having the same error, I made a lot of changes in my code but is not working at all, the thing here is that I am using a Mini Ultra Pro card with a RFM95W which does not provide DEVEUI address due to this boad (V1) has no EUI-64 chip, so, it reads only zeros, I tried to load a number by my self but still the EV_JOINING is stuck. All I have read since now points out that this number it does not matter too much, and so far my node does not receive anyting at the back end, I only visualize yellow requests in my gateway, which is a mulltichannel Conduit.
Could you please share with me the code you used to make your node work? I have spent two weeks trying to make this to work out without any good result.
Thanks a lot.
Regards.
Hi all,
I’m testing lora node (Arduino UNO + Dragino) with OTAA.
By default the OTAA code use the first 3 lora channels. In some post/code example there was that if you want to use all the 8 lora channels it needs to set the channel in this way:
LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI); // g-band
LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK, DR_FSK), BAND_MILLI); // g2-band
I tryed but both on the lora server side and on the gateway I can see that the node uses only 3 channels (the default channels 0,1,2).
Thanks in advance for your help!!
Following the code that I use:
/*******************************************************************************
Original script is Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
*******************************************************************************/
#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>
static const u1_t APPEUI[8] = { 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; // REVERSE ORDER
static const u1_t DEVEUI[8] = { 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; // REVERSE ORDER
static const u1_t APPKEY[16] = { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 };
// provide APPEUI (8 bytes, LSBF)
void os_getArtEui (u1_t* buf) {
memcpy(buf, APPEUI, 8);
}
// provide DEVEUI (8 bytes, LSBF)
void os_getDevEui (u1_t* buf) {
memcpy(buf, DEVEUI, 8);
}
// provide APPKEY key (16 bytes)
void os_getDevKey (u1_t* buf) {
memcpy(buf, APPKEY, 16);
}
static uint8_t mydata[] = "Hello, TTN over OTAA!";
static osjob_t sendjob;
static osjob_t initjob;
// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 5;
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 9,
.dio = {2, 6, 7},
};
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"));
do_send(&sendjob);
break;
case EV_RFU1:
Serial.println(F("EV_RFU1"));
break;
case EV_JOIN_FAILED:
Serial.println(F("EV_JOIN_FAILED"));
break;
case EV_REJOIN_FAILED:
Serial.println(F("EV_REJOIN_FAILED"));
// Re-init
os_setCallback(&initjob, initfunc);
break;
case EV_TXCOMPLETE:
Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
if (LMIC.dataLen) {
// data received in rx slot after tx
Serial.print(F("Data Received: "));
//Serial.write(LMIC.frame + LMIC.dataBeg, LMIC.dataLen);
Serial.println();
}
// Schedule next transmission
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:
// data received in ping slot
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;
default:
Serial.println(F("Unknown event"));
break;
}
}
void do_send(osjob_t* j) {
// Check if there is not a current TX/RX job running
if (LMIC.opmode & OP_TXRXPEND) {
Serial.println(F("OP_TXRXPEND, not sending"));
} else {
// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, mydata, sizeof(mydata) - 1, 0);
Serial.println(F("Packet queued"));
}
}
// initial job
static void initfunc (osjob_t* j) {
// reset MAC state
LMIC_reset();
// start joining
LMIC_startJoining();
// init done - onEvent() callback will be invoked...
}
void setup() {
Serial.begin(115200);
Serial.println(F("Starting"));
// LMIC init
os_init();
// Reset the MAC state. Session and pending data transfers will be discarded.
os_setCallback(&initjob, initfunc);
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
// Set up the channels used by the Things Network, which corresponds
// to the defaults of most gateways. Without this, only three base
// channels from the LoRaWAN specification are used, which certainly
// works, so it is good for debugging, but can overload those
// frequencies, so be sure to configure the full frequency range of
// your network here (unless your network autoconfigures them).
// Setting up channels should happen after LMIC_setSession, as that
// configures the minimal channel set.
LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI); // g-band
LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK, DR_FSK), BAND_MILLI); // g2-band
// TTN defines an additional channel at 869.525Mhz using SF9 for class B
// devices' ping slots. LMIC does not have an easy way to define set this
// frequency and support for class B is spotty and untested, so this
// frequency is not configured here.
// Disable link check validation
LMIC_setLinkCheckMode(0);
// required for downlink
LMIC.dn2Dr = SF9;
// Set data rate and transmit power (note: txpow seems to be ignored by the library)
LMIC_setDrTxpow(DR_SF7, 14);
os_runloop();
// Never get here
}
void loop() {
// Never get here
}
Ok done!
waiting for some help…
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.
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?
