No problem, the details can be overwhelming.
What SF are those packets? Because at lower SFs your node might not hear the reply. Getting your own gateway running correctly is a good step to a controlled environment where you can access logs of all important components.
Thank you for your patience. The join-request packets seem to get through at SF8,9 or 10 but not 7. So I think distance is an issue.
I agree regarding my own gateway - I’m trying to re-activate it again.
I’ve plugged in a long ethernet cable to get rid of any WiFi flakyness if any (though it never was a problem before). Currently It is stuck on Broker Connection: False at the moment as shown below.
The ‘config correct: false’ line looks suspicious to me. Can’t verify at the moment but I would expect that to require a ‘true’ value.
I have done the re-activation tango and my kickstarter gw has ‘connected’ again.
Still, it shows packets up (When I fired up my TTGO pax counter) but none down.The pax counter display told me it was waiting for a join.
The TTN V3 console shows no traffic at all - I left this console view open since , as you can see, 07:27 this morning whilst I went and did something more rewarding - playing golf.
I also put an FTDI on the gw debug port and have several hours of recorded debug messages. 99% of which are just stack status messages - and they show the stack isn’t being consumed by anything.
There are a lot of these:-
LGMD:Rejected packet (0x11)
which , I guess, may be non-compliant transmissions from somewhere (not me I was on that golf course) LOL
There’s a thread about this on the forum dating back to April 22nd but it remains unresolved.
Also this - but it hasn’t appeared in the gateway console even with verbose checked
LGMD:LORA: Accepted packet
MQTT: Sending UPLINK OK
There are some of these
MQTT: Sending status packet
MQTT: Sending status succeeded: 885 <- incrementing number.
Is it possible to get more info out of the debugging on the kickstarter gw?
Something fundamentally wrong here I think.
My RPi+ Dragino HAT based end-node is seen by the V2 gateway on the Humber Bridge and Live data shows up in the V3 verbose log. The Live data shows the join was accepted and a JOIN_ACCEPT was queued for sending back but I received nothing at my end. RSSI was -111 at one point so within the RFM95 spec. hence I would expect to receive something, if transmitted, but no rx_done interrupt was generated.
I also added logging to all the interrupts PayloadCrcError, CadDone etc - not a dicky bird.
I cranked the TxPower down to 1db - my kickstarter gateway saw the transmission (info page Packets Up increasing) but it wasn’t picked up by any other gateways in the area. That was intended to force the packets down to come via my gw, but they didn’t.
My Kickstarter gw (bnn-ttn-1) still tells me, via the info page, that it is sending packets up but nothing appears in the V3 console live data. And it shows no packets down at all. Can you tell if the gw is actually subscribing and not just publishing?
I built an LMIC-node using a Heltec Lora 32 V2 (and a V1) for comparison but still no join - though my Kickstarter incremented its Packets Up at each join attempt. However, there was no traffic in the V3 console for it (keys were double checked).
It would be useful to know which gateway the return message was supposed to go to for sending on to me.
If anyone has any other suggestions of things to try I’m all ears. Thanks for reading.
Buy a TTIG and an Adafruit Feather M0 + RFM95 - we can debug them!
So, we’ve exhausted all other possibilities like server log files?
I’m not about to part with approx £100 for extra hardware I can ill afford on my lowly pension. The Heltec is just another Arduino MCU so I don’t see the point in buying a Feather. The TTIG - well, the local community has something like 30 kickstarter gw, many as yet undeployed, which they will want/hope to use.
I guess I’ll try to install the things stack on a Pi4 as a local server and see if I can identify the problem with the Kickstarter packet forwarding. It’s a shame, my kickstarter has been, till V3, rock solid. I know others have gotten theirs to work.
Nope, you could have a day out in Bolton
Hi,
@bnnorman, did you ever get things working? I also have a Dragino Lora/gps HAT and had ambitions to connect it to TTN via V3. However, I am utterly lost on what I would need and if this is even possible.
If it is working for you, can you give me some pointers on what I need to do?
Supposedly this library is supposed to work with TTS v3, but I am lost with all the parameters I seem to need and how to derive them (see keys_example.py). You said something along these lines:
To be able to create unique deveui and appkey I bought a 25AA02UID eprom from microbit because it’s programmed with 6 UID bytes and I just added 00 00 for my (first) device…
So, do I need to get more hardware? Has the TTS v3 stack changed in a way that the Dragino HAT won’t work out of the box anymore? If it’s not going to work with the Dragino HAT, what HAT does work (as node) and which library do I use to send data.
Thanks for help,
Hardy
Yes I got it working just fine. It took me several months to change over to V3 as I had to modify the original Dragino code to handle MAC command handling because the original coder stopped developing just before V3 kicked in.
You can find my modded version of the Python code here:-
BNNorman/dragino-1: LoRaWAN implementation in python (github.com)
I believe the V3 console now generates deveui etc for you so I wasted money buying the eeprom memory chips but hey ho, it was interesting and they were cheap, but turns out I only needed one and could generate thousands of valid UID from the device id. DOH, such is life.
The HAT I’m using is shown here:- Raspberry Pi HAT featuring GPS and LoRa® technology
You should make sure you use the HAT V1.4 - some wiring changes I think but not sure if they matter.
From my repository you only need to copy the dragino folder to your project folder (it isn’t a python package). Then you need to modify dragino.toml to configure it for you use case. You don’t need cache.json it will be created when the code first runs and its absence basically makes the node send a join request. There is,normally, only ever one join request with V3 OTAA the subsequent messages used the cached keys from the join. If you want to force a new join just delete cache.json and run your code again.
My project was to add LoRa radio to the road speed signs for the local council - they have yet to install it on a road , not the fastest shakers and movers, but they did fire it up to check it was talking to TTN.
Regards
Brian
Hi Brian,
Yes I got it working just fine.
Congratulations 
It took me several months to change over to V3 as I had to modify the original Dragino code to handle MAC command handling because the original coder stopped developing just before V3 kicked in.
I feel your pain and great work updating the code.
You can find my modded version of the Python code here:-
BNNorman/dragino-1: LoRaWAN implementation in python (github.com)
Awesome. This code made my day. Together with this GitHub comment on how to configure the SPI bus, I finally got to a stage where there seems to be some actual communication between the Pi and the Dragino board. This feels like a big step forward.
Unfortunately, nothing is showing up on the TTN console yet, but there could be many reasons for that.
The closest gateway is 8km from my location and I have no idea whether I would be able to reach and connect to it. My plan is to set up my own gateway, but I am waiting for parts. With my own gateway, it hopefully will be easier to see whether and what gets send/received.
I believe the V3 console now generates deveui etc for you so I wasted money buying the eeprom memory chips
LOL. So yes, a DevEUI gets generated, together with an AppEUI and AppKey. However, I have a few questions about this. Maybe you can help?
So I got AppEUI, DevEUI and AppKey. The AppEUI are only ‘0’ though. It was set to this value when I generated the device. Does that sound right?
Then you need to modify dragino.toml to configure it for you use case.
Ok, so I am wondering what I need to set when it comes to these key and id parameters. The toml file contains:
[TTN.OTAA]
# received session key values are stored by MAChandler
# enter your OTAA keys here
deveui = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
appeui = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
appkey = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
devaddr= [0x00, 0x00, 0x00, 0x00] # not joined
[TTN.ABP]
# enter your device ABP key values below
devaddr = [0x00,0x00,0x00,0x00]
newskey = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
appskey = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
appkey = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
appeui = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
deveui = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
Which of the two sections (TTN.OTAA vs TTN.ABP) do I need to fill out? Both? I’ve set deveui, appeui and appskey in both sections. As said, though, appeui is only ‘0’ and the appskey I get from the TTN console is one octal shorter then the place holder. Should I just remove the last 0x00?
I have no idea what devaddr and newskey mean and where I would get them from.
Can you shed some light on this?
Also a bit unrelated. When I created the device on the TTN network, I needed to select the generic device option where I had to specify a MAC protocol version, ranging somewhere from v 1.0 to 1.1 with various increments in between. I took the first option, but no idea whether this was right or not. What do you use?
You don’t need cache.json it will be created when the code first runs and its absence basically makes the node send a join request. There is,normally, only ever one join request with V3 OTAA the subsequent messages used the cached keys from the join. If you want to force a new join just delete cache.json and run your code again.
Let’s see when I get there 
My project was to add LoRa radio to the road speed signs for the local council - they have yet to install it on a road , not the fastest shakers and movers, but they did fire it up to check it was talking to TTN.
Nice one. I want to connect some temperature sensors which are supposed to feed into a weather station of mine.
–Hardy
That’s very ambitious in a rural setting, extremely ambitious in an urban environment. I would not expect the average gateway install to hear that, nor the baby antenna on an indoors device.
Debugging is always best done with your own gateway - a TTIG is ~$/£/€90 and will save you hours.
Whilst it is deemed technically correct by the higher powers, it often confuses the code. Get a fake real one here: https://descartes.co.uk/CreateEUIKey.html
If you can’t tell your ABP from your OTAA, that’s not good. Please use the documentation to learn the basics, it will help enormously - both you and the people answering your questions 
: https://www.thethingsnetwork.org/docs/lorawan/
Fantastic work - a really useful addition to the community resource.
What is the supported LoRaWAN version - aka, what copes - I’m not talking certification level, just what needs to be set for it to work OK.
I was struggling to connect to TTN till I finally got my kickstarter gateway working. Nearest gateway to me was 11km - it did pick up my transmissions but I never got a JOIN_ACCEPT back even though RSSI was within spec and SNR was good. Probably due to buildings in the way.
If the gateway is seeing your node then there should be something in the V3 console provided your keys are correct. Otherwise you will be ignored.
The actual keys used in dragino.toml are selected by the auth_mode entry. So, if you are using OTAA, which you should, then make sure it says:-
auth_mode="OTAA"
You can then ignore the TTN.ABP section. I would leave it in because, IIRC, there’s a bug , which I haven’t fixed, which causes an exception if they are missing. (So many other things going on). Leave the ABP section as-is (arrays of hex zeros)
If your keys (appeui, deveui and appkey) are correct and devaddr is [0x00, 0x00, 0x00, 0x00] then the JOIN_REQUEST will be sent . TTN sends back the session keys (newskey etc) and the actual devaddr. The values are cached in cache.json and are used to override the dragino.toml session key settings. Dragino.toml is just a starting point cache.json rules thereafter.
I have never tried using zeros for keys - as I said I bought an eeprom chip because it had a unique UID and appended my own generated values to create the deveui and appkey. The appEui (aka joinkey) is just a randomly generated key.
.
This is how I generate my appkey values. These values are not to be shared. You also need to format them as python arrays containing 0xnn values for dragino.toml
import secrets
def addSpaces(a):
n=2
b=[a[i:i + n] for i in range(0, len(a), n)]
return " ".join(b)
print(addSpaces(secrets.token_hex(8)))
devaddr and newskey are generated by the TTN server on a successful join. The code will cache them on your node in cache.json.
My devices are MAC V1.0.2 with PHY V1.0.2 REV A which is the recommendation when transferring V2 devices to V3 though it still works ok for me.
It’s frustrating that the TTN console remains silent till you send a valid JOIN_REQUEST - security.
Getting a good radio signal is best done putting the antenna high up and in line of sight. Me and ladders don’t play well so my gateway is on a window ledge on the 2nd floor of my house in another room (don’t get too close otherwise RF signals can get garbled.
Good luck.
There is no way of it telling it’s for the device - this is like you not knowing someone posted you a birthday card with the wrong address on it - so no trace of a hint of anything ‘wrong’ with any of this.
Just saying so someone doesn’t think this is somehow abnormal for TTS.
Hi,
Debugging is always best done with your own gateway - a TTIG is ~$/£/€90 and will save you hours.
Jupp. That’s what I thought. I was just hoping to make some more progress on the node while waiting for the gateway. However, I think I reached a point where I need one.
Get a fake real one here: Random EUI or Key generator
Nice, thanks.
If you can’t tell your ABP from your OTAA
Nope, not yet. Definitely need to learn more and better understand on a deeper level. On the other hand, one would hope for a very simple and low effort entry into the TTN world and grow from there. I guess things might be easier if one buys re-assembled TTN ready devices. Building these components yourself always adds another level of complexity, but is also part of the fun
–Hardy
Hi,
I was struggling to connect to TTN till I finally got my kickstarter gateway working. Nearest gateway to me was 11km - it did pick up my transmissions but I never got a JOIN_ACCEPT back even though RSSI was within spec and SNR was good. Probably due to buildings in the way.
Ok.
The actual keys used in dragino.toml are selected by the auth_mode entry. So, if you are using OTAA, which you should, then make sure it says:-
auth_mode="OTAA"You can then ignore the TTN.ABP section. I would leave it in because, IIRC, there’s a bug , which I haven’t fixed, which causes an exception if they are missing. (So many other things going on). Leave the ABP section as-is (arrays of hex zeros)
Thanks. Makes sense now.
If your keys (appeui, deveui and appkey) are correct and devaddr is [0x00, 0x00, 0x00, 0x00] then the JOIN_REQUEST will be sent .
ok
TTN sends back the session keys (newskey etc) and the actual devaddr. The values are cached in cache.json and are used to override the dragino.toml session key settings. Dragino.toml is just a starting point cache.json rules thereafter.
got you
devaddr and newskey are generated by the TTN server on a successful join. The code will cache them on your node in cache.json.
I see. The toml configuration seems a bit confusing in this case. I would not expect it to have devaddr and newskey at all then. If these keys are generated and stored/used from cache.json, what’s the point in having them in the configuration file. But I get the picture now.
My devices are MAC V1.0.2 with PHY V1.0.2 REV A which is the recommendation when transferring V2 devices to V3 though it still works ok for me.
Ahh, that’s good to know. I’ll try that.
Getting a good radio signal is best done putting the antenna high up and in line of sight.
Ok
Good luck.
Thanks. And thanks for all this super valuable information and tips. I feel I’m close, but at the same time, I’ll need my gateway. I’ll report back once I can make some progress again.
–Hardy
Erm, that’s such a basic level of knowledge that in LoRaWAN terms is like breathing or eating.
People took out time to create the materials you get for free so you can use the free service. The least you can do is take some time out to read them so you can use the free service without causing issue. Can’t be more than an evening’s effort.
And, as we are all volunteers here, pretty much the only response you are going to get from us until you’ve demonstrably read the basic docs is “have you read the docs”. Otherwise we’ll be advising you on things you don’t understand because you’re brain is starved of oxygen because you don’t yet know how to breath.
Nope - you still need to know what ABP and OTAA is. And a few other important concepts.
It’s even harder if you don’t know the core concepts …
The toml file is a starting point which is superceded by dynamically cached values, from any MAC commands received, in cache.json.
When you next update the library on GitHub please can you change this to nwskey to reduce confusion.