this is the output of the data you say but I don’t understand that in v2 it was clear now I can not understand what this numbers mean
regards from Germany 
I cannot explain every detail about the v3 console that is different from the v2 console.
Just explore it a bit by yourself.
What I see in your gateway console live data view is that the gateway is actually talking to TheThingsNetwork and sending a status at a regular interval (that’s good!). However it appears that it is not receiving any LoRaWAN traffic at all, not from your node but also not from any other node.
Would be helpful to see some valid data indeed, but its not too unusual to receive nothing: i have two gateways, one receives nothing but my own devices, another just regularly picks up a device which sends in SF12.
But after @MarcKCity you created a new device: does your AppEUI have all zeros? (default if you create a device in V3)
I cannot receive anything from a device using an MCCI lib & has an all-zero AppEUI/JoinEUI set.
Just recently found this, because i created the first device in V3 (before i just migrated my old devices from V2, and so they all had something set / i copied the same values into V3.
If i set it to a random value everything is working, but according to the docs, this seems to be the right way to define one. Just try if this works in your code:
https://www.thethingsindustries.com/docs/devices/adding-devices/
Note:
Some devices do not support using
0000000000000000as a JoinEUI/AppEUI, because technically, this value is invalid. However, The Things Stack supports using this value to indicate the absence of an actual JoinEUI/AppEUI.If your device gives an error when using
0000000000000000, try using the DevEUI value as a JoinEUI/AppEUI, both in The Things Stack and on your device.
Nick had previously posted this to the forum that may help for small number of devices (suggest dont use on a volume run - buy a block! 
https://descartes.co.uk/CreateEUIKey.html
Derived from this:
Thank you all for helping me
I have now used the Create random EUI generator but it don’t want to work with the custom EUI it shows again the same error in the Arduino IDE and no data in end device live data -.-
i don’t understand why the new v3 must be so complicated … it was already a struggle in v2 until everything was correct with all these keys to transmit 3 sensor values. in the end I only need a code with which I can query the dht22 and an ldr (. analog light sensor) and send this to ttn but that really seems to be a life’s work with the v3. through my search on the internet i noticed that not only i am very dissatisfied with the new system. I’m curious if some of the gateways might not go offline in the future because nobody wants to do it anymore when such trivial things no longer work without extreme effort. greetings marc
[image]
TTN v3 isn’t really that difficult, not more difficult than v2 IMHO, actually a lot more powerful in terms of APIs to retrieve information from devices, gateways etc than I first assumed. I don’t think it’s going away.
I think the first steps are:
- seeing that your node claims it’s transmitting something, like trying to do an OTAA join, perhaps you can see a radio signal on an SDR (node OK)
- seeing that the OTAA join is received at the gateway and seeing it in the gateway console (gateway OK)
- seeing that the join request triggers a join accept (settings in console and keys OK)
Then after that, you can start thinking about decoding the data and processing
It is a tough call with the migration - but the LoRaWAN standard moves on, as have the support libraries.
You need to be using the MCCI-LMIC library 3.3 or 4.0 for a compliant library.
If you can get that installed I can document the changes you need to make to the library to maximise available SRAM on the Pro Mini.
Thank you for the numerous answers and the help that is really very nice and not a matter of course in today’s world.
I updated the lmic to 4.1.0. and instead of the EUI with only zeros, I generated one via the generator.
Then I entered the APP EUI and the DEV EUI in lsb format. The APP key in msb format. and tested again with the same result 
I don’t know what else I can do or what “could be wrong” in the appendix again some pictures and here the code including keys maybe someone sees an error. Or maybe someone has an Arduinio program that I can test (of course I add my keys beforehand) to test whether it is possibly due to the gateway and not to the arduino sketch? Many greetings Marc
#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>
#include <DHT.h>
#include <DHT_U.h>
#include <Adafruit_Sensor.h>
//
// For normal use, we require that you edit the sketch to replace FILLMEIN
// with values assigned by the TTN console. However, for regression tests,
// we want to be able to compile these scripts. The regression tests define
// COMPILE_REGRESSION_TEST, and in that case we define FILLMEIN to a non-
// working but innocuous value.
//
#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
// This EUI must be in little-endian format, so least-significant-byte
// first. When copying an EUI from ttnctl output, this means to reverse
// the bytes. For TTN issued EUIs the last bytes should be 0xD5, 0xB3,
// 0x70.
static const u1_t PROGMEM APPEUI[8]= { 0x10, 0x0E, 0x7A, 0xB0, 0x04, 0x65, 0xA0, 0x0C };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}
// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8]= { 0x1F, 0x69, 0x04, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}
// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from ttnctl can be copied as-is.
static const u1_t PROGMEM APPKEY[16]= { 0x2E, 0x66, 0x6D, 0xFB, 0x51, 0x9D, 0xF6, 0x79, 0x2F, 0x84, 0xB4, 0x1F, 0xC3, 0x13, 0xB0, 0x40 };
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}
static uint8_t btn_activated[1] = { 0x01};
static osjob_t sendjob;
// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 60;
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 5,
.dio = {2, 3, LMIC_UNUSED_PIN},
};
//------ Added ----------------
#define LED_YELLOW 8
#define LED_GREEN 6
#define DHT_PIN 7
#define BTN_PIN 9
// DHT11 or DHT22
#define DHTTYPE DHT22
// Initialize dht
DHT dht(DHT_PIN, DHTTYPE);
int buttonState = 0; // current state of the button
int lastButtonState = 0; // previous state of the button
int BattValue = 0;
int BattOut = A1; //Voltage Divider INPUT
//-----------------------------
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:
LMIC_setDrTxpow(DR_SF9,14);
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("");
}
// Disable link check validation (automatically enabled
// during join, but because slow data rates change max TX
// size, we don't use it in this example.
break;
/*
|| This event is defined but not used in the code. No
|| point in wasting codespace on it.
||
|| 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"));
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"));
//------ Added ----------------
if (LMIC.dataLen == 1) {
uint8_t result = LMIC.frame[LMIC.dataBeg + 0];
if (result == 0) {
Serial.println("RESULT 0");
digitalWrite(LED_YELLOW, LOW);
digitalWrite(LED_GREEN, LOW);
}
if (result == 1) {
Serial.println("RESULT 1");
digitalWrite(LED_YELLOW, HIGH);
digitalWrite(LED_GREEN, LOW);
}
if (result == 2) {
Serial.println("RESULT 2");
digitalWrite(LED_YELLOW, LOW);
digitalWrite(LED_GREEN, HIGH);
}
if (result == 3) {
Serial.println("RESULT 3");
digitalWrite(LED_YELLOW, HIGH);
digitalWrite(LED_GREEN, HIGH);
}
}
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;
/*
|| This event is defined but not used in the code. No
|| point in wasting codespace on it.
||
|| case EV_SCAN_FOUND:
|| Serial.println(F("EV_SCAN_FOUND"));
|| 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){
// Check if there is not a current TX/RX job running
if (LMIC.opmode & OP_TXRXPEND) {
Serial.println(F("OP_TXRXPEND, not sending"));
} else {
uint32_t humidity = dht.readHumidity(false) * 100;
uint32_t temperature = dht.readTemperature(false) * 100;
Serial.println("Humidity: " + String(humidity));
Serial.println("Temperature: " + String(temperature));
BattValue = averageAnalogRead(BattOut);
int battVoltage = ( 3.36 / 1024 * BattValue * 2 * 100 ) - 250;
Serial.println("BattValue");
Serial.println(BattValue);
Serial.println("battVoltage");
Serial.println(battVoltage);
byte payload[5];
payload[0] = highByte(humidity);
payload[1] = lowByte(humidity);
payload[2] = highByte(temperature);
payload[3] = lowByte(temperature);
payload[4] = battVoltage;
//Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, payload, sizeof(payload), 0);
Serial.println(F("Packet queued"));
}
// Next TX is scheduled after TX_COMPLETE event.
}
//Takes an average of readings on a given pin
//Returns the average
int averageAnalogRead(int pinToRead)
{
byte numberOfReadings = 8;
unsigned int runningValue = 0;
for(int x = 0 ; x < numberOfReadings ; x++)
runningValue += analogRead(pinToRead);
runningValue /= numberOfReadings;
return(runningValue);
}
void setup() {
Serial.begin(9600);
Serial.println(F("Starting"));
//------ Added ----------------
pinMode(LED_YELLOW, OUTPUT);
pinMode(LED_GREEN, OUTPUT);
pinMode(BTN_PIN, INPUT);
digitalWrite(BTN_PIN, LOW);
dht.begin();
//-----------------------------
#ifdef VCC_ENABLE
// For Pinoccio Scout boards
pinMode(VCC_ENABLE, OUTPUT);
digitalWrite(VCC_ENABLE, HIGH);
delay(1000);
#endif
// LMIC init
os_init();
// Reset the MAC state. Session and pending data transfers will be discarded.
LMIC_reset();
LMIC_setAdrMode(1);
LMIC_setLinkCheckMode(1);
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
// Start job (sending automatically starts OTAA too)
do_send(&sendjob);
}
void loop() {
//------ Added ----------------
// read the state of the button value:
buttonState = digitalRead(BTN_PIN);
// compare the buttonState to its previous state
if (buttonState != lastButtonState) {
if (buttonState == HIGH) {
// if the current state is HIGH then the button went from off to on:
LMIC_setTxData2(1, btn_activated, sizeof(btn_activated), 0);
Serial.println(F("Button On"));
} else {
// if the current state is LOW then the button went from on to off:
Serial.println(F("Button Off"));
}
// Delay a little bit to avoid bouncing
delay(50);
}
// save the current state as the last state, for next time through the loop
lastButtonState = buttonState;
//-----------------------------
os_runloop_once();
}
type or paste code here
Thanks for all the detail, FYI, if it can be text, please use text (Arduino console log) and to save us (me) peering at small screen shots, can we switch to asking for information - a picture without expected information is a distraction - we promise to believe you if you say there is no Join-Accept!
However at present there doesn’t appear to be a Join-Request in your gateway console and the Arduino output doesn’t appear as expected - it’s not reporting EV_JOIN_TXCOMPLETE and is a classic issue where the whole stack has ground to a halt due to lack of memory, see this important tip:
So if you can hang on a few more hours, I can do the above.
sorry thought it would be good if I send pictures of all the details, ok then i know about the future
of course it doesn’t depend on a day, that would of course be very nice;)
Greetings from Germany
I haven’t seen any difference between v3.1.0 and v4.1.0 in terms of size, v3.1.0 is declared as being properly Class A compliant so I’ll leave you to figure out which version gives you the most SRAM but I have spun up an original TinyThing (Pro Mini + RFM95) to check it was good and it ran happily on OTAA for several hours. I used LMIC a lot when I first started with LoRaWAN so I’d say that it will just run & run (like the ones around the office & in the garden, 100k uplinks in some cases).
So the two main changes are to un-comment these lines:
and
If necessary (depends on what sensors you are using), you can also add a:
#define DISABLE_LMIC_FAILURE_TO
to match up with
and make sure the line 87 is:
#define LMIC_DEBUG_LEVEL 0
I have transitioned the TinyThings to using ATmega4808 + RFM95 as one of the options - this triples the SRAM to 6K and increases flash from 32K to 48K. This means I can run LMIC with all the options with full logging (level 2) and line 93 uncommented - so I get ALL the detail. This is how I can then figure out what’s going on and then apply changes back to the original 328 version.
Please let me know how you get on,
1 Like
I get the same error in the Arduino IDE console unknown event: 20
But when I test the same code with a heltec board I get it in the gateway and see the payload so it must be something with the use of Arduino pro mini ?!
regards from Germany
UPDATE:
I found this website: Mobilefish.com - Build Lora node using Arduino Pro Mini and HopeRF RFM95 LoRa transceiver module (V3).
and use the infos for the problem with the Arduino pro mini 3,3v and no I get this in the ice console ( see picture). but why no join accept? 
Just analyse things step-by-step, there could be any number of things wrong.
So do you see your join-request in the console of the gateway?
First make sure you see your join request in the gateway console, then make sure you see a join accept being sent out by the gateway, then see if you can receive it on the node.
The event codes for LMIC are here:
Number 20 is EV_JOIN_TXCOMPLETE, which means that the node claims it sent a JOIN accept.
On an atmel, things are quite tight with respect to memory, perhaps too tight in your case.
Yes, hence the comment about lack of memory above - the Heltech modules have far more memory.
As before, forum policy is not to use pictures when you can copy & paste the text. Please review the how-to
The MobileFish tutorial gives some useful information although I find that using LoRaWAN 1.0.2 doesn’t work as well with the new stack. I haven’t tried turning off the TimeReq MAC command but I can see that that would help.
I note in one of your text sections above you are including <Adafruit_Sensor.h> - I’m not sure that is required for the DHT library and it may be adding an overhead to both flash & RAM, you may want to try removing it.
But overall you appear to have got to a point where it thinks it is transmitting the Join Request.
-
What was the flash size & available SRAM on the compile? It is shown in the IDE just before it downloads to the device - DO NOT take a screen shot - it is text.
-
Does your gateway “see” the join request in its web console? If not, does the gateway internal log see the transmission?
-
How far apart is the device & the gateway?
-
Did you put the OTAA EUI’s in as little endian?
-
Can you try the example TTN OTAA sketch without any extras, just the 2 EUI’s & the AppKey?
Sorry for the picture I now know only pictures when it is needed.
I now flashed the lmic example code ttn OTAA and get in the Arduino IDE the result:
Packet queued
2571: EV_JOINING
3132: EV_TXSTART
404925: EV_JOIN_TXCOMPLETE: no JoinAccept
413495: EV_TXSTART
793966: EV_JOIN_TXCOMPLETE: no JoinAccept
973362: EV_TXSTART
In the gateway nothing appear ?! in the V3 Console nothing see in the live message stream too.
yes 2 lsb and the appkey in msb I know that 
68% and 70% ius used with the example ttn otaa sketch.
Gateway:
"boot_time": "1970-01-01T00:00:00Z",
"versions": {
"hal": "Version: 5.0.1; Options: native;",
"platform": "IMST + Rpi"
},
"metrics": {
"cpu_percentage": 0,
"lmnw": 0,
"lmok": 0,
"lmst": 0,
"load_1": 1.26,
"load_15": 1.44,
"load_5": 1.46,
"lpps": 0,
"memory_percentage": 70.45938,
"rtt_ms": 291,
"rxin": 3946,
"rxok": 153,
"temp": 40.084,
"txin": 46,
"txok": 46
}
},
"correlation_ids": [
"gs:conn:01FJ464G5SZ295Y00D6N7G41EC",
"gs:status:01FJ48D4TM6KR9XYCBH92XQN10"
],
"origin": "ip-10-100-6-163.eu-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_STATUS_READ",
"RIGHT_GATEWAY_STATUS_READ"
]
},
regards from Germany
Marc
Flash/SRAM use similar to my test device - although the actual numbers would be clearer - 22K leaves plenty of space for a small selection of sensors but 614B is getting close to where I see the devices freezing.
I wasn’t thinking of the gateway config, I was thinking of the log of activity from the gateway that shows uplinks & downlinks. This will show if the gateway hears the join request. If it does, but it has some issue - like it fails the CRC check - it won’t be sent on to TTS which is why it wouldn’t been seen on the gateway console.
Do you have any other devices you could use to verify the gateway is OK?
You may have done this already, but just checking you’ve changed the region in lmic_project_config.h?
the config. h is default set to 868mhz I changed nothing because I found nothing to change there.
what do you mean with log of activity ? I only see live data in the V3 and in my rpi terminal it shows nothing.
with the heltec v2 board it sends hello world to the same gateway.
my gateway is only 10 meters away so no problem
regards from Germany
Not config.h. I said lmic_project_config.h.
As for the gateway, check the system.log for output from the gateway software.