{
"name": "gs.up.receive",
"time": "2023-07-17T16:27:02.352763745Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "eui-b827ebfffe96c13d",
"eui": "B827EBFFFE96C13D"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.GatewayUplinkMessage",
"message": {
"raw_payload": "QDQUCyaADwAAn2nbVmQ/Ag==",
"payload": {
"m_hdr": {
"m_type": "UNCONFIRMED_UP"
},
"mic": "VmQ/Ag==",
"mac_payload": {
"f_hdr": {
"dev_addr": "260B1434",
"f_ctrl": {
"adr": true
},
"f_cnt": 15
},
"frm_payload": "n2nb"
}
},
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 7,
"coding_rate": "4/5"
}
},
"frequency": "868100000",
"timestamp": 3950447387,
"time": "2023-07-17T16:27:02.319Z"
},
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "eui-b827ebfffe96c13d",
"eui": "B827EBFFFE96C13D"
},
"time": "2023-07-17T16:27:02.319Z",
"timestamp": 3950447387,
"rssi": -13,
"channel_rssi": -13,
"snr": 9.2,
"uplink_token": "CiIKIAoUZXVpLWI4MjdlYmZmZmU5NmMxM2QSCLgn6//+lsE9EJuW3NsOGgwI1tfVpQYQnrCPqAEg+MKNyPxyKgwI1tfVpQYQwJuOmAE=",
"gps_time": "2023-07-17T16:27:02.319Z",
"received_at": "2023-07-17T16:27:02.330587177Z"
}
],
"received_at": "2023-07-17T16:27:02.352573470Z",
"correlation_ids": [
"gs:conn:01H5J7201WX2TM1VYSN1737S1F",
"gs:uplink:01H5JATFAG4W9BYDQYVH1QWC2Y"
],
"crc_status": true
},
"band_id": "EU_863_870"
},
"correlation_ids": [
"gs:conn:01H5J7201WX2TM1VYSN1737S1F",
"gs:uplink:01H5JATFAG4W9BYDQYVH1QWC2Y"
],
"origin": "ip-10-100-7-222.eu-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_TRAFFIC_READ"
]
},
"unique_id": "01H5JATFAGGPEEZFTXZ30F303Q"
}
i’ll take a look on all your suggestion. I get the inspiration from one of the commercial sensors decoder (pepperl and fuchs) we get and it seems to works fine for that type of messages. But for sure the format is a bit different from what we are sending.
They are recommendations from the people that write TTS, combined with the person that does the integration / payload formatter training videos. And it’s not currently working for you so I don’t think it’s unreasonable to consider the forum expertise over Pepperl & Fuchs. 
Search the forum for the fun people have with floating point. The rest of the code changing the byte array in to a string and then cutting it up is just to weird to think about.
And you may exceed the timeout with all that unnecessary processing and not get the payload decoded at all.
the playground looks like accepting the code and return me the values i’m expecting… the problem is what the real-time decoding gave me an error and after that it stops me to show the raw payload, this seems to be very strange to me.
i do not now what was the problem but with the last version i can see the data decoded… i didn’t change anything in the configuration, just some adjustments in a code:
function decodeUplink(input) {
var hexStr = input.bytes;
var data = payloadParser(hexStr);
return {
data: data,
warnings: [],
errors: []
};
}
/**
* This is the function to create a payload object by decoding hex string
* @param {String} hexStr
* @return {Data}
*/
function payloadParser(hexStr)
{
var data = {};
data.payload = hexStr;
data.node_id = returnInt(hexStr, 0);
data.temp = intToInt(hexStr, 2)/100;
data.hum = returnInt(hexStr, 4)/100;
data.press = returnInt(hexStr, 6)/10;
data.AQI = returnInt(hexStr, 8)/10;
data.CO2 = returnInt(hexStr, 10);
data.VOC = returnInt(hexStr, 12)/100;
return data;
}
function returnInt(bytes, idx){
var num = bytes[idx] | bytes[idx+1] << 8;
return uintToInt(num, 16);
}
function uintToInt(uint, nbit) {
nbit = +nbit || 32;
if (nbit > 32) throw new RangeError('uintToInt only supports ints up to 32 bits');
uint <<= 32 - nbit;
uint >>= 32 - nbit;
return uint;
}
function intToInt(bytes, idx){
var sign = bytes[idx+1] & (1 << 7);
var x = ((bytes[idx] & 0xFF) | ((bytes[idx+1] & 0xFF) << 8));
if(sign) return 0xFFFF0000 | x;
else return x;
}
and it happens again, i’m not getting again any measurements from the sensor even tough i can see some on the Gateway. Neather deocded nor raw.
Have you ignored the f_cnt for the device?
Sorry where can i find this settings?
What is the LoRaWAN library you are using?
LoRaWAN library for Pico from Github; lorawan-library-for-pico/src/lorawan.c at main · ArmDeveloperEcosystem/lorawan-library-for-pico (github.com)
after reflashing the device and without any decoding on TTN side i saw 4 messages only on Application layer and then it stops recieving anything. The counter is incrementing from 4 to 7.
it is also very confusing the information i’m seeing on the Gateway tab and Application. i can see some frames coming over there, but nothing on application side. is there some configuration i’m missing?
Yes, but more essentially missing is the knowledge of difference between ABP and OTAA and why it’s preferable to use OTAA due to this exact issue.
If you look at the Learn section (top of this page) and search for ‘ABP frame counters’ on the docs and this forum you’ll get lots of info. The docs will point you to the relevant settings to change.
But simplest to just use OTAA
it’s true what the best way is to use OTAA, but still if exist ABP registration and it is allowed on TTN, i do not understand the behavior. Reading the posts and the theory it is clear what for ABP if u reset the node, the frame counter will restart and the frames suppose to be ignored by the Network server, But in my case the behavior is not like this. I still get the first frames and after that they are coming in randomly, but i can’t see these frames in specific part of the TTN dashboard view. I see some frames on GW console and some of them on generic part of application console. But when i get into the specific device console, there is no live frames. i can share the json from all 3 console if u can help me to understand?
Only when the counter is lower or equal to the previous value. Once the counter increases to a value above the last one used the uplink will show in the application,
The counter is ignored if you set the according flag in the device properties. please don’t because it makes your devices insecure and opens it up to replay attacks and more nasty issues.
You should see all of them (as received by the gateway) because this is before the network server checks the counters,
The application data and the device data (for that device in that application) should match.
Make sure all thee are the exact same timeframe. Sharing data of different timeframes won’t allow analysis.
Please also share the detailed device setup. No need to share the keys, but every other setting including the nitty gritty details of the MAC settings and advanced setting.
i re-registered the device one more time in 20/07 and i turned it off, yesterday i turned it on again, and behavior is the same as on 20/07. The problem is what the live data i can see on device console is only about 20/07, nothing from yesterday.
i didn’t change anything in this General settings except the frame counter reset (on or off doesn’t seems to change anything). i didn’t find the ignore frame counter setting anywhere thought.
Can i send json files only to you without making them public pls or there nothing which can compromise our devices on that log?
Egregious breach of TTN Fair Use Policy - unlisting topic pending confirmation that it will be adhered to.
Sorry, one of the messages i get on TTN reports me the value: consumed_airtime: “0.061696s”. Based on the fair use policy the time allowed for public networks for node is 30 sec per 24 hours, so i do not think i’m violating it sending messages every 10 minutes. Sorry i’m new in this area and trying to understand so, could you please explain?
One of the devices shows three uplinks in the space of 15 seconds so it won’t take long for it to consume airtime.
The concern (that is replicated across the forum time & time again) is that someone may leave it running on their bench. Neither does it work better because you hit the servers frequently. And it’s very hard to see what happened if the console is a blizzard of data.
And then there is the law (police, courts etc) for the duty cycle - a percentage in an hour.
Either have it on a one-shot on boot and just reset the device, have it on a push-button or set it to interval per https://avbentem.github.io/airtime-calculator/ttn/eu868. This is how the community ensures it doesn’t impact the free service paid for by TTI.
Travelling hopeful on the above, some things for you to consider:
- Please read the rest of the Learn section, not just the Bytes bit I gave you above, there’s a lot of the usual gotcha’s covered in it. Plus https://www.thethingsnetwork.org/docs/lorawan/
- Your RSSI is way way too high - you will be overloading the gateway input circuits which will most likely turn the uplink in to a CRC error which is where your missing uplinks are going - 5 to 10m separation and/plus a brick wall - forum search will explain it in detail.
- No way that firmware of LoRaMAC-node is v1.0.2.
- TTN has an entry for the frequency plan of “Europe 863-870 MHz (SF9 for RX2 - recommended)” - the draft plan has only 6 channels so YMMV. It also has to be in sync with your gateway.
The docs for the Pico repro are almost non-existent - where did you get the LW version and the channel plan settings from?
The repro has an older release of LMn but it should be possible to cross-reference it to a release so you can see which versions it supports - it may well have options you need to #define as recently we’ve had a choice of three. The most recent is not necessarily the best / simplest to get started with.
Just one clarification. Probably the one u mention with 3 uplink in 15 secs is the one with the address
eui-9c65f9fffe346af5? this one is not main, so i need to figure out if they are also complaint with the TTN policy. Thanks for detailed description of the problem. i will try to get better understanding of all configuration.the one i was worried about is the euie661640843133e22.
We don’t tend to bike-shed the details or get too involved intricate calculations - any console logs or code that indicates an interval less than the ones from the calculator causes concern - doesn’t matter if it’s not the device in question, it’s any device on TTN.