Hi all!
I have an issue with some packet decoding im hoping somebody understands
I have used the packet decoder:
https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/
but i am unable to read the message supposedly due to som MIC issue, but how does that happen?
(Apparently the device has not been joined to any application, is this strictly necessary to decode simple packages when i have the other information such as Devkey and vice cersa? )
Br,
Rasmus
If the device has not joined yet you won’t have valid keys which are required to validate the MIC.
The DevAddr suggests the device has successfully joined. As does the fact that it is sending data frames that are not join packets.
The right and valid AppKey will be required to decode your application data.
Alright, so far soo good :)!
it seems to be joined now as is shows up in application, however it seems strange that there is no payload transmitted?
shouldnt i be able to see the data that i tried tot transmit within the data tab of the lora-node i’ve set up ?
Thanks in advance
There’s most definitely a payload
In fact the hexdump in the payload field of is bytes comprising the string “Hello [22]”
If you’re wondering why the message wasn’t printed as a string, it’s because you’re not supposed to send strings - that’s wastefully expansive.
Really you should be packing messages to bit level, at the very least using whole bytes efficiently.
There’s also no need to embedded a count, since you already have to send the frame count as part of the packet protocol header - see the 22 in the overview line of the message above the expansion.
Thank you for noticing me, i thought the data would be decoded from hexadecimal once receiver with nwsk and appkey 
Second question:
It seems quite random as to when i am able to see the data in the Application tab…
Yesterday i had the node up and running and importing fine into the application, but today nothing is happening?
The gateway receives it fine: 
but there is no response inside the application: 
how can it be possible to only be able to transmit into the application sometimes rarther than all the time when the gateway sees the transmission?
Probably because your frame counter illegally rolled back, making it look like an attacker had recorded your old packets and was playing them back even though it was actually you sending new ones, improperly starting over from a low number.
You really need to make the frame counter continue across minor maintenance of the node firmware; otherwise you’re going to need to hit that “reset frame counters” button in your screenshot.