please FORMAT your forum post… especially the loooooooooooooong copy/pasted code 
Ok done!
waiting for some help…
1 Like
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?