FeatherMO LoRa nodes now broken due to required TTN Upgrades

[adafruit2]

thanks!

[TI545]

With respect to nodes being migrated to V3, the main thing to remember here is you'll need to delete the device from the V2 Console and make sure the keys in your INO sketch match whatever your registered in V3 for your application/device. When I do this, I can see the node sending data to V3 using the original library suggested by Adafruit, but I can't decode it (yet).

I've been tracking my whole LoRa adventure (for non-programmers/engineers like me) in this playlist which may contain additional details of interest: https://youtube.com/playlist?list=PLqJ5 ... uY2UfPyT8i

Hope this helps!

Thanks for your information biod101. A couple of questions for you. Do you know if your lora feather is directly sending data to TTN v3, versus using the Packet-Forwarder they provided in this interim v2/v3 period?

Second question: I added my lora m0 feather to the v3 console, and then deleted it from the v2 console. For the settings screen shot you posted, I'm having trouble finding those settings in the v3 console so that I can check my work. Where in the v3 console is there an "edit end device" button? I can see devEUI in general settings, but that's all.

[biod101]

Regarding

Do you know if your lora feather is directly sending data to TTN v3, versus using the Packet-Forwarder they provided in this interim v2/v3 period?

Let me dig up the emails from TTN that might shed some light on this - stay tuned.

Regarding

I'm having trouble finding those settings in the v3 console so that I can check my work. Where in the v3 console is there an "edit end device" button? I can see devEUI in general settings, but that's all.

The settings I mentioned are under "General Settings", and then expand "Network Layer"

settings.png (241.77 KiB) Viewed 108 times

[biod101]

Here is a copy of the discussion I had with TTN to get the FeatherMO node to at least communicate with V3. This first quote is in response to my communicating challenges with the same:

Yes, the problem probably lies in the fact that your device is still talking to V2. And yes, even though you moved your gateway to The Things Stack, the traffic gets routed back to V2 (that's our latest feature that helps the community to migrate their stuff). According to our documentation, you should change the AppKey for your OTAA device in the V2 Console to prevent it from re-joining the V2 network. Once you change the AppKey, you should trigger your device to perform a new OTAA join. That's when your device will stop working on V2, and join the The Things Stack network.

I was also having trouble understanding APP and API keys - here was the response on that front:

1. API Key and AppKey are two completely different things. AppKey is the application key your device is using in the process of joining the network via OTAA join procedure. API key is just a key you create to provide authorization for your gateways/applications/users/organizations (for example, to tell the third party application that you want it to accept and process the traffic from your app, you must prove that you own that app and there you would use the API key). So, no, these are not the same, and you shouldn't create the API key to join the network. In your code, you should use the AppKey because it will allow you to complete the join procedure on The Things Stack.

2. The documentation is slightly incorrect and I'm working on it, here's what's the catch - you CAN use the same AppKey as you used on V2, but you DON'T HAVE TO. When you are registering your OTAA device, in the last step of registration you can choose to: enter the AppKey by yourself (in this case, you can copy the one you used on V2), or auto-generate the AppKey (in this case, you can copy that AppKey you generate and change it in the code you're uploading to your device).

So, I think the easiest option for you is to navigate to The Things Stack Console -> find your app -> find your device -> Overview tab -> Activation information section -> AppKey, copy the AppKey and change it in the code you're uploading to your device. The other option would be to delete the device you created on The Things Stack and when re-registering it, instead of auto-generating the AppKey, you would copy the AppKey you're using in the code you're uploading to your device and paste it in the AppKey field.

Here was my attempt at fixing things:

Okay - I tested the device "featherweather" again with V2 and it was connected this morning. I then revised the EUI for the associated application in my V2 console, and then to make sure nothing carries over, I just deleted the associated device altogether in V2. I then double checked my INO code to make sure the appeui and deveui match what's in the V3 console settings for the device.

keysInCode.png (480.77 KiB) Viewed 108 times

I then reset my device so that it would search for the gateway and attempt to link to V3. I then confirmed my gateway is connected, which it is under V3. Unfortunately, nothing is being registered in the data view

... then, I tried this:

Wait - I see now that the API key needs to be added to the associated application for V3. I didn't do that - let me play with it on this front.

Set that up properly, and then:

Next, I modified the first two keys to little endian, and left the last one as msb per this guidance:
https://learn.adafruit.com/the-things-n ... duino-code

Now, it looks like some data is being transmitted:

data.png (298.72 KiB) Viewed 108 times

After that, I tried playing with the payload decoder, but that didn't work. Here is the response I got from TTN:

The thing is that payload decoders are not 1 on 1 replicable from V2 to V3, and you need to do a little (but obviously significant) modification. For example, if your decoder function on V2 was:

function Decoder(bytes) {
var temperature = bytes[0] | bytes[2];
return {
temperature: temperature;
}
}


then your V3 payload formatter function will be:

function decodeUplink(input) {
var bytes = input.bytes;
var temperature = bytes[0] | bytes[2];
return {
temperature: temperature;
}
}

You can notice that most of the code remained the same, the only difference is in the name of the function and defining the input. Please try this on your end.

Unfortunately, my job and kids keep me busy, so this is as far as I managed to get. Having said that, you can see that we are very close - the original libraries and code suggested by Adafruit do appear to work in that the node is talking to V3, but the payload decoder is broken.

Tomorrow, I'm setting up a gateway at my local maker space, and then headed off for annual leave for the next two weeks so I'll be offline. As such, I wanted to get something posted in the hopes our friends in this forum (or Adafruit) can help us get this one to done ;) Sorry if this is difficult to follow - it's the highlights of what I managed to glean from all my emails with TTN.

I'll come back to this in a couple weeks. So close!

[biod101]

Looks like my annual leave got postponed - I'll be around.

[TI545]

I'm having trouble finding those settings in the v3 console so that I can check my work. Where in the v3 console is there an "edit end device" button? I can see devEUI in general settings, but that's all.
The settings I mentioned are under "General Settings", and then expand "Network Layer"

settings.png

Thanks for the additional info, I will look through it. On this one item, I did find the settings you showed for Network Layer. I had set my region to "nam1" (because I'm in north america) and when I changed it to "eu1", those setting then appeared.

In the mean time, I am starting over, reading the LMIC library and examples to see what I need to set up to get my feather m0 rfm95 boards working with TTN v3 / "The Things Stack"

[jerryn]

FYI -- I found that after updating the LMIC library, it defaults to v3 compatibility and I was able to just recompile my V2 example and it worked fine with a V3 Application and Device that I configured.
I am using the MCCI Lorawan LMIC V4.0.0 library

[TI545]

FYI -- I found that after updating the LMIC library, it defaults to v3 compatibility and I was able to just recompile my V2 example and it worked fine with a V3 Application and Device that I configured.
I am using the MCCI Lorawan LMIC V4.0.0 library

Thanks, good to know. I started going through https://github.com/mcci-catena/arduino-lorawan that admin adafruit2 suggested, it is very interesting, and they do have examples for the feather m0 rfm95, but it is also very different.

I see that there have been recent updates on github to the LMIC library that learn.adafruit used in the tutorial https://github.com/mcci-catena/arduino-lmic. That must make it work with TTS / v3. I haven't migrated my gateway to v3 yet, but since LMIC version 4 works, I will do it.