Always wrong payload in TTN

Hello All,

Someone a idea what can be going on ? It’s driving me nuts …
I sent ( as test ) always the same 2 bytes ( values 21 and 80 , HEX : 15 and 50 )

PROBLEM : These are always different in TTN payload , really random !!

Tryed already differente code ( sketch ) all the same ramdomness as payloadresult

Using a TTGO ESP LoRa v1.0 as Gateway and as Node. So a 1 channel gateway setup ( don’t need more for the moment and my node doesn’t reach any other GW in SF7 )
Node forced to always use the singel same freq.
Using ABP ( as otaa isn’t supported on a 1ch non-bidirectional GW)
Al this works nice :
counter increments with 1 in TTN ( no miss hits )
“frequency”: 868.1,
“modulation”: “LORA”,
“coding_rate”: “4/5”,
“spreading_factor”: 7,
“bandwidth”: 125,
update interval 30s ( maybe violating fair use policy, will check ones my payload is correct )
“rssi”: arround -63,
“snr”: arround 9,

Somewhere a bug in the gateway ?

did you try with different values… for example 22 and 81 ? can you check ?

Thanks for the reply [BoRRoZ] . Why would you expect 22 and 81 to be correctly received ?
Evens if they would, I don’t want to exclude 21 and 80 to be sent. ( 21 = degrees in celcius at home , 80 humidity )

can you show a screenshot of your application in your TTN console when receiving your data.

That usually means your application skey is not set to the correct value (does not match the TTN setting). If the address and network skey do not match you will not get the data routed to the application, if the application skey match doesn’t the data can’t be decrypted correctly and you will get random data.

1 Like

Hello Jac. Thanks for replying.
I copy/pasted them from the TTN console in lsb format.
Just verified both ( TTN and sketch ) to be sure, ones more, and they are the same :

Sketch :
static const uint8_t PROGMEM APPSKEY[16] = { 0xAF, 0x45, 0x2C, 0x52, 0xF2, 0xEF, 0x62, 0xBD, 0x9D, 0x23, 0x66, 0xDB, 0x4F, 0x1C, 0xE7, 0x53 }; // lsb

TTN:
Capture2

Other ideas ?

Some fresh wrong payload for this code (only releated to those 2 bytes ) :

// moisture variable
int moisture = 0;
// temperature in Celcius
int tempC = 0;

// Reading temperature and humidity
// moisture = sensor.readHumidity();
moisture = 80;
// Read temperature as Celsius (the default)
// tempC = sensor.readTemperature();
tempC = 21;

void build_data() {
dataTX[0] = tempC;
dataTX[1] = moisture;
}

// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, dataTX, sizeof(dataTX), 0);

Capture1

Quote from Matthijs Kooijman, One of the (earlier) maintainers of LMIC:

Did you enter the devaddr LSB-first and the keys MSB-first?

So LSB might be the wrong format for the keys,

2 Likes

Hello Jac. Indeed !! That did the job. Thanks !
As simple as that …
So AppSKey, application session key needs to be MSB !!
( Altrough strange, as a lot of code examples show it beings LSB )