I’m trying to transfer my end device from V2 to V3 but when I try to add the device in the V3 console and choose Dragino Technologies as the supplier the resulting device list does not include the HAT.
There is nothing on the HAT or the Dragino manuf website other than “SX127X GPS HAT” which isn’t in the model list
Has anyone created a V3 end device of this type? If not, does it matter should I just lie about what it is (for now)?
Many thanks for any help you can give me.
For unknown devices you can use “try manual device registration“. Because hats do not come with embedded software the vendor will not be able to add it to the device database as they can’t guess the LoRaWAN standard your software uses.
Thanks for the suggestion. I’ll give it a go.
Well, it worked. I re-used the EUI from the V2 device. Unfortunately, I can see it trying to join in the V3 console but no join-accept message is received at my end although TTN scheduled it.
Is this because the device exists with the same EUIs in both V2 and V3? (stuff passed to V3 not routed back to V2?)
Thanks for any further help. This isn’t something I do daily.
“Stuff” is passed from v3 back to V2.
Try changing the AppsKey on V2 so there is no match on the V2 NS.
Sorry for the long delay coming back and the potentially stupid questions that follow - I’ve been busy bashing my head against V3 rather than moving devices from V2 to V3 - only one test device was affected and V2 became read only anyway whilst I was trying things out.
So, instead, I elected to create an app on V3 and end device for V3 directly. Then program my device with the new keys.
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. I then added a random secret (using Python secrets) to the deveui to create the AppKey and another random secret to create the AppEui. These are programmed into my device and I have double/triple checked they are the same. They are the correct number of bytes each. devnonce is a random 16 bit number generated by the software I’m using when it tries to join.
However, when the device tries to join I sometimes see the join-accept on the V3 console but don’t get a reply at my device. I say sometimes joins because if I change the SF the join-accept appears to happen with sf 8 or 9 not 7 and still nothing received by my device hence no nwskey etc created. This leads me to think the signal strength at my end (urban) is too low. Is that a reasonable assumption?
The gateway I believe my device connects to is 11km away 100ft up a bridge over the River Humber. My hardware is on the top floor of my house (3m up). I can’t actually see the bridge from here.
The software I’m using is computenodes/dragino from github. This worked fine on V2, when my kickstarter gateway was alive and well and living in the next room. I should add this software works as class C (I ticked that box in the V3 console) and does not listen for RX2. I am trying to work on that to see if I’m just missing the reply but my kickstarter gateway seems to confirm nothing was sent back (see below) .
Lastly, to try to eliminate signal strength issues, I created a new V3 gateway and , I believe, registered my old kickstarter with TTN V3. I say ‘believe’ because the LEDs tell me it has connected and its settings page reports the asrv as what I expect.
{
"ssid": "XXXXXXXXXXXXXXXXXX",
"gwid": "bnn-ttn-1@ttn",
"gwkey": "XXXXXXXXXXXXXXXXX",
"asrv": "https://eu1.cloud.thethings.network/",
"locked": true
}
The info page from my kickstarter is as follows and shows 38 packets up (from my testing) but zero coming down. This could be another issue - if you know anything please enlighten me.
Sorry for the verbosity of this but I’m working alone , going dizzy reading loads of conflicting information, trying lots of code changes and baffled that V2 worked out of the box but V3 hasn’t, for me anyway. I’ll try again tomorrow but for now it’s Beer O’ Clock.
Thanks again for your patience and any help you can give me.
There’s two parts to this.
First of all, there is your gateway which would be useful to have online as the other gateway 11km away is going to be a bit of a lottery if you don’t have line of sight.
Does the v3 web console for the gateway show any statistic log lines? Or any uplinks from any other devices.
Once that is checked out, it will make debugging the Dragino HAT much easier. What software are you using on your Pi to driver the HAT?
Thank you very much for responding. Yes there are two parts to this - I was hoping to give a clear picture of what I have tried so far - I know how difficult remote fault finding is when you only get a dribble of information (I was international tech support on unix based systems for 25 years, now a retiired old bloke).
When I was in tech support and users told me ‘it didn’t work’ the act of standing next to their desktop, mysteriously, made it work. Usually user error.
The Dragino HAT hdw is sitting on a RasPI model 4 and, as I said, I’m using GitHub - computenodes/dragino: LoRaWAN implementation in python software (Python). This combo has worked flawlessly on V2 with my Kkckstarter gw also on V2.
Hmm, this morning leds 2 & 4 on my kickstarter gateway were slow blinking showing internet/mqtt problems. I rebooted my router, but not the gateway, and now all leds are back on solid plus the V3 console now shows the gateway connected.
I also saw a brief blink on led 5 (traffic, nothing to do with me) but nothing in the gateway console either.
I think I need to do some more experimentation with my ‘end-device’ today and will let you know how I get on.
The local council distributed a number of these kick starter gateways into the local community via a group I belong to. They too, are going to want to know how to get this working.
Thanks again for responding, I’ll let you know if I make any progress.
Sadly no - further forward. As you can see the join-request got through via another gateway but the message back was not received after waiting 15 seconds . My gateway thinks it sent the packets (10) up but the info on the device live data doesn’t tell me which gateway picked it up. That would have been useful.
The test assumed a response would happen in RX1 at join freq and SF. How long should it wait before switching to RX2? I have read that RX1 delay should be no more than 5 seconds with a 1 second window before listening on RX2 but I also read a join could take upto 15 seconds. Arghh!
Gateway details are available once you click on the message in the device view. A window with a large json structure should open containing an overload of details.
Please read the LoRaWAN specification and regional parameters, there is a lot of information in them. For join RX1 is 5 seconds. Not 4, not 6 and certainly not 15. RX2 is RX1 plus one second. After that no more data will arrive at the end device for a join request so 15 seconds does not make sense.
Assumption make an ass… You need to be sure what happens for debugging.
LoRaWAN time slots are extremely timing critical. A RPi isn’t a great choice for a real time embedded system with the default Linux versions. To make sure you have a chance of receiving data open RX1 early and close it a bit beyond the normal window.
BTW, make sure to use a fully LoRaWAN compliant gateway when developing, single channel abominations make life a lot more difficult and will cause issues for other users as well.
Yeah, I get that a lot - trouble is on the forum you can’t stand next to them although, UK travel restrictions be damned, I’m tempted for some cases to go and fix it that way!
For Joins, Rx1 is 5 seconds - so you only need to wait 6.5 seconds to know. Don’t confuse this 5 seconds with the other 5 seconds I’ll mention in a second.
Rather like in your gateway console where you clicked on the line and got the event details, you will get the same for the device log - scroll down in that box and it will show you the gateway info.
You don’t, it’s meant to be baked in to the code - if nothing arrives after 5 seconds, wait 1 second and listen again.
Depends on the context of what was being written - I could just as easily say it takes 10 minutes if the device has to try a few times.
Ideally you need to get to a point where your gateway is showing it is transmitting the Join Accept before moving on to the Pi problem.
Can you look at the device log and see which gateways it is being heard by.
Do you have another device you can put on to v3?
v3 is far more compliant so more relaxed implementations of a LoRaWAN MAC are going to struggle to talk to the NS.
And then there is the info Jac has mentioned regarding timings.
1 - I don’t get that with join request
{
"name": "js.join.accept",
"time": "2021-07-15T07:11:50.514650673Z",
"identifiers": [
{
"device_ids": {
"device_id": "test-01",
"application_ids": {
"application_id": "bnn-dragino-test"
}
}
},
{
"device_ids": {
"device_id": "test-01",
"application_ids": {
"application_id": "bnn-dragino-test"
},
"dev_eui": "29510000A0710000",
"join_eui": "43762049A040C5E7",
"dev_addr": "260B57B9"
}
}
],
"correlation_ids": [
"rpc:/ttn.lorawan.v3.NsJs/HandleJoin:01FAMG3R7C7HVYE22QX5KPYRYD"
],
"origin": "ip-10-100-5-178.eu-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ",
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01FAMG3R7JMXNYWGWKXHVK6T1W"
2 Thanks, that was the timing I was working with. The dragino code listens immediately after transmission is complete.
4 I agree but the Pi was chosen because of a lot of other stuff it needs to do including message scheduling, aggregating data to reduce traffic and more (LOL). As I said. It works ok in V2 In the main the use case just transmits periodically whilst keeping to the 1% duty cycle and Fair Use policy.
That’s not the Join Request which is what you need to find.
If your gateway isn’t hearing it, just concentrate on that in the first instance.
For how long - does it stop before the transmission arrives?
Given the relaxed nature of v2, that may well be the case. But we don’t have v2 anymore, so you need to make your device more compliant.
Thank you. I have a ‘pax counter’ based on TTGO which was originally working on V2.
I copied the keys to V3 and deleted the device from V2 - it shows a join-accept in V3 but the device is indicating ‘join wait’ which suggests it hasn’t gotten the Ok from upstairs. I didn’t originate the code it was a curiosity thing.
Again I don’t see an obvious gateway id in the JSON.
{
"name": "js.join.accept",
"time": "2021-07-15T08:56:44.808391808Z",
"identifiers": [
{
"device_ids": {
"device_id": "brian-sensor",
"application_ids": {
"application_id": "bnn-pax-counter"
}
}
},
{
"device_ids": {
"device_id": "brian-sensor",
"application_ids": {
"application_id": "bnn-pax-counter"
},
"dev_eui": "0000000000000003",
"join_eui": "70B3D57ED001DD19",
"dev_addr": "260BADEB"
}
}
],
"correlation_ids": [
"rpc:/ttn.lorawan.v3.NsJs/HandleJoin:01FAMP3V02VM5ZFZAVZY766607"
],
"origin": "ip-10-100-5-178.eu-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ",
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01FAMP3V088947FJB66Q64NP4T"
}
I can change the keys on my RasPi to make another device. I think it’ll take a lot longer for me to delve back into arduino to produce a new device that way but I can see the benefit
I said this last time:
Please please please look for a Join Request and not a Join Accept
Can’t see that being of much use, we don’t even know if the Python is receiving.
You probably need to check ‘verbose stream’ to see the join request. This is the accept.
Which all will interfere with the real time nature required for LoRaWAN. If you need a RPi a safer solution would be to use a module like RN2483 which embeds the LoRaWAN stack and can be driven using a uart using ASCII commands.
Including OTAA joins?
Sorry, I mis-understood. The wording here ‘Accept join-request’ under ‘Type’
suggested to me that the join was accepted and that was the line supposedly providing the gateway info.
Now, if that just means ‘tried to join’ but ‘not accepted’ that would be a different matter.I understand TTN ignores dodgy messages for security reasons.
I can see how frustrating this is for us both and I do sincerely apologise. I know you guys work with this stuff all day long.
I’ll take a look at the RN2483 device.
I’ll go quiet now whilst I try to build an Arduino device.
It is, but you kept saying you couldn’t see which gateway was picking it up and I kept saying that you needed to look at the Join Request line.
Which you haven’t done, so we still don’t know if your gateway is working.
It does say “Join Accept”, it does not say “Join Accept to be transmitted by gateway, details enclosed”
You look on the gateway console to see the transmission.
If you look at the Join Request, it will tell you which gateways heard the request.
So until we know if your gateway is participating in all of this, building a new device may be pointless.
But you could try ABP …
The join is accepted, however this is a response message, not the request. Have you used the ‘verbose stream’ tick box top right of the traffic window? Checking it will display a lot more information relevant when debugging, including the request packet with gateway information.
My BAD and massive appologies for mis-understanding. Previously, all I ever saw were the Accept join-request messages. - I’m pretty sure that when I tried the verbose tickbox after the attempted join I didn’t get any more detail but now, having ticked the box before attempting a join, I get all sorts of detail. I could be wrong, of course, my head is spinning.
My apologies.
“forwarder_gateway_id”: “hcc-lora-004”, - this is the humber bridge gateway (still on V2) 11km away not my kickstarter in the next room. Perhaps my kickstarter was lying to me about forwarding packets
I got this info too.
“rssi”: -114,
“channel_rssi”: -114,
“snr”: -14.5,
A number of messages are slightly lower than this at rssi -117 and snr -9.25.
Should be ok for reception of the downlink join-accept I would have thought but I’m not seeing it.
The log tells me a JOIN-ACCEPT was scheduled for downlink transmission at RX1 delay:5
The console for my Kickstarter shows no traffic at all so I guess that needs looking at. I’d like to cure that first to eliminate signal strength. Perhaps I’ll try rebooting the kickstarter to see what I can find out.