I’m not sure if I follow. 8E EF 60 is in the TTN console, under the data tab.
The sketch I use uses LORA_Send_Data() as shown above, and LORA_Send_Data() as in my last message contains Encrypt_Payload().
So I assume it is encrypted (hence I do get 3 distinct values in TTN if I send “TTT”) I guess?
That’s weird. Unless the specific sketch is doing additional encryption, that should not happen when using TTN Console to administer applications and devices. I think sprintf(msg,"TTT"); should not cause that either.
Sorry, I’d use a different example then. Examples that send text are not a good start anyway, as to save bandwidth a LoRaWAN node should not send text.
When using ABP, then I guess TTN Console cannot know if the correct Application Session Key (AppSKey) was used.
For uplinks, the Message Integrity Code (MIC) is calculated using the secret Network Session Key (NwkSKey), not the AppSKey. But even when TTN determines the packet’s MIC is valid, decryption of the application payload (using the secret AppSKey) might will still silently fail when using different secrets for encryption and decryption. (So: will show different results when the AppSKey in TTN Console and the node do not match.)
You can see for yourself with your own data or an example in the “FRMPayload decrypted” part of the online decoder: just play with the AppSKey to see you’ll get different decrypted data, without any clue if the right key was used. Changing the NwkSKey will get you an error though, as for the MIC we know the expected value from the LoRaWAN packet.
So: are you sure you used the correct AppSKey in your node? See also Hex, lsb or msb?
Thanks for the pointers. I forgot to mention that I use msb - the reason being that with lsb I did not see any data at all . With msb I actually received.
However, I now saw in your link that lmic requires lsb, which is confusing as I don’t receive anything then.
Do all of the values need to be in either msb or lsb? If so I’m not sure why msb gives me data…
I’m not sure if:
If you see packets in a gateway’s Traffic page then you only know it’s connected; you don’t know if the keys are okay. (Though maybe peeking into the “trace” part might give you some hints about TTN knowing the recipient.)
If you see data in a device’s Data page, then the DevAddr and NwkSKey in the node are okay. And:
For OTAA you can then assume all keys in the device are okay.
For ABP, if you see the correct data, then the AppSKey is okay too. (So, all keys are okay.)
For ABP, if you see the wrong data then check the value for AppSKey in the node, or maybe try to revert it in the node.
The tutorial that you were using originally probably has a bug in the Encrypt_Payload function. The function in Encrypt_V30.cpp encrypts the payload with:
This should be: