Dragino+pi3 node transmission problems

(Chickadee) #22

Successes! we were able to receive packets on the TTN console! Now that we have gotten packets sent to us from one of our nodes. We are attempting to change the payload to unique values.

(Arjan) #23

Nice. Your next problem: you’ve got the AppEUI in the wrong order. And you might have made the same mistake for the DevEUI. You’re seeing OTAA Join Requests, but TTN does not recognize these values and does not create an OTAA Join Accept.

See Hex, lsb or msb? (When indeed using LMIC, scroll to my answer at the end.)

(Chickadee) #24



You were right about the keys being switched around. We got those fixed and have now successfully got a join accepted. The nodes have been seen by the TTN. But we are not able to see any decoded data. How do we actually see the data?

(Arjan) #25

What are you seeing?

When an OTAA Join succeeds then you’re sure that the configuration is okay. Next, if the device is transmitting any data, and one or more gateways receive that, then you should see the decrypted application data in both the application’s Data page and the specific device’s Data page in TTN Console. You should also see the full LoRaWAN packet in the gateway’s Traffic page (if one has access to that, which you do), which includes the encrypted application payload (plus the LoRaWAN header, the MIC and possibly some MAC commands, all shown as a single sequence of hexadecimal values).

So, is the device sending any uplink at all, after the join?

If you define a Decoder in the application’s Payload Format, and if that does not throw any errors, then TTN can also decode the application data for you, and show that on the same Data pages.

Do you have any Decoder defined? (Not mandatory, of course. You can also decode in your own application, fed by the MQTT Data API or some integration.)

(Chickadee) #26

We have not defined a decoder, no. We are looking at the ‘integration’ tab though. From what we can gather, if we were to setup an http integration then we would be able to send the (decryped)data directly to wherever we determine, right? Does the decryption only happen if we define a decoder in the applications payload format or through our own application. I guess what I am asking is if we decide to setup an http integration, would that handle the decryption for us or would we need to define it in the payload as well?


this is an example of an up-link we received after the join. We also noticed our RSSI is very low. This might be because of the building we are testing in. This particular packet was sent from a node located approximately 30 to 40 meters away. Although we are right next to a massive cluster computer, which I assume would probably interfere with the signal strength. We are planning to take our devices outside for a better testing environment.

(Arjan) #27

In your current setup, TTN knows all secrets and will indeed always decrypt for you. See the documentation. (In theory you could also have your own Handler.)

If you also define a Decoder then both the MQTT Data API and the HTTP Integration will give you both the Base64 encoded raw application payload, and whatever fields that are returned by the Decoder.

(As an aside, as you showed another screenshot of the gateway’s Traffic page: be sure to also peek into what the application’s and device’s Data pages give you if you didn’t do that already.)

(Chickadee) #28


We’ve been able to send configurable payloads, verified by a decoder. However, it seems that our maximum range is 2.5 feet for acknowledgements and payloads(uplinks). We’ve done multiple tests at 50 and 100 meters but to no avail. What troubleshooting steps do you recommend to fix the range?

-Chickadee - J