Dear All,
I have an end device (Heltec AB02S) sending 20bytes, which is well received by my RAK833-868EU, and the packet forwarder correctly forwards by UDP the lora message towards TTN.
I have used TCPdump on my raspberry to check the UDP traffic and I can see UDP messages encoded in base64 with 20bytes lenght payload, however TTN says it only receives 6 bytes, where are things going wrong?
Thanks for the help.
Cheers
Can you show us the exact information you are seeing please - payload being sent, what the gateway receives and what TTN is receiving. It will help us see how the data is changing as it goes through each system.
That sounds about right.
6 bytes of application payload is about what one would expect a raw packet of size 20 bytes to contain.
Or alternately, 0 bytes of application payload, and 6 bytes of MAC command response. Or other network rather than application level messages.
Sure,
Attached the you can find the payload (not encoded) I send from the end device,
The TCPdump capture from the rpi gateway, and the TTN screenshot. Just note that the messages screenshots are not for the same exact message, as I am sending 1 every second at the moment for testing purpose.
But this should not really be too much relevant for this.
Thanks for the help.
19:11:06.973 -> Humidity = 6553.50,Temperature = 0.00,Temperature3 = 28.16,Pressure = 960.69,Temperature = 0.00
19:11:06.973 -> ,Temperature Av = 28.16
19:11:07.288 -> Payload: 55558540000CCCC4502C7044AE47E141
19:11:07.288 -> confirmed uplink sending ...
19:11:07.288 -> TX on freq 867900000 Hz at DR 5
19:11:07.288 -> TX on freq 867900000 Hz at DR 5
19:11:07.378 -> Event : Tx Done
19:11:07.378 -> RX on freq 869525000 Hz at DR 3
0000 44 fe 3b 41 13 f8 b8 27 eb 8d e6 c2 08 00 45 00 D.;A...'......E.
0010 00 e5 bb cd 40 00 40 11 a7 b0 c0 a8 01 2b 34 d4 ....@.@......+4.
0020 df e2 e8 1a 06 a4 00 d1 da 72 02 55 a2 00 b8 27 .........r.U...'
0030 eb ff fe d8 b3 97 7b 22 72 78 70 6b 22 3a 5b 7b ......{"rxpk":[{
0040 22 74 6d 73 74 22 3a 35 36 37 30 34 39 33 39 35 "tmst":567049395
0050 2c 22 63 68 61 6e 22 3a 34 2c 22 72 66 63 68 22 ,"chan":4,"rfch"
0060 3a 30 2c 22 66 72 65 71 22 3a 38 36 37 2e 33 30 :0,"freq":867.30
0070 30 30 30 30 2c 22 73 74 61 74 22 3a 31 2c 22 6d 0000,"stat":1,"m
0080 6f 64 75 22 3a 22 4c 4f 52 41 22 2c 22 64 61 74 odu":"LORA","dat
0090 72 22 3a 22 53 46 37 42 57 31 32 35 22 2c 22 63 r":"SF7BW125","c
00a0 6f 64 72 22 3a 22 34 2f 35 22 2c 22 6c 73 6e 72 odr":"4/5","lsnr
00b0 22 3a 36 2e 35 2c 22 72 73 73 69 22 3a 2d 38 38 ":6.5,"rssi":-88
00c0 2c 22 73 69 7a 65 22 3a 31 39 2c 22 64 61 74 61 ,"size":19,"data
00d0 22 3a 22 67 41 5a 47 43 79 59 41 48 67 41 43 37 ":"gAZGCyYAHgAC7
00e0 30 4a 63 74 4f 39 65 32 77 32 74 75 67 3d 3d 22 0JctO9e2w2tug=="
00f0 7d 5d 7d }]}
{
"name": "as.up.data.forward",
"time": "2021-11-07T18:13:46.072386991Z",
"identifiers": [
{
"device_ids": {
"device_id": "eui-70b3d57ed004677b",
"application_ids": {
"application_id": "projectkamptest1"
}
}
},
{
"device_ids": {
"device_id": "eui-70b3d57ed004677b",
"application_ids": {
"application_id": "projectkamptest1"
},
"dev_eui": "70B3D57ED004677B",
"join_eui": "0000000000000000",
"dev_addr": "260B4606"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
"end_device_ids": {
"device_id": "----",
"application_ids": {
"application_id": "projectkamptest1"
},
"dev_eui": "-----",
"join_eui": "0000000000000000",
"dev_addr": "260B4606"
},
"correlation_ids": [
"as:up:01FKXSPDYNBKWQ6TDM63S7K15Q",
"gs:conn:01FKXRA9R5HZS810EQXQZXNA2Y",
"gs:up:host:01FKXRA9RB3GRW9BYR4QKN2VBZ",
"gs:uplink:01FKXSPDQW0GJZ56F1B9MGA8C1",
"ns:uplink:01FKXSPDQX60SRZ9BD93WMMYQD",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FKXSPDQX17WR0659SNHR75Z1",
"rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FKXSPDYMQR97JPEJNZ69248H"
],
"received_at": "2021-11-07T18:13:46.070640803Z",
"uplink_message": {
"session_key_id": "AXz7ilfMEgFt44uQIYcwEw==",
"f_port": 2,
"f_cnt": 162,
"frm_payload": "VVWFQAAA",
"decoded_payload": {
"Battery": 0,
"Light": 4.166666507720947
},
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "projectkamprpi2",
"eui": "-----"
},
"timestamp": 1448291979,
"rssi": -103,
"channel_rssi": -103,
"snr": 1.2,
"uplink_token": "Ch0KGwoPcHJvamVjdGthbXBycGkyEgi4J+v//tizlxCL3cyyBRoMCNmuoIwGEPOLt5YDIPidt6eTKg==",
"channel_index": 2
}
],
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 7
}
},
"data_rate_index": 5,
"coding_rate": "4/5",
"frequency": "868500000",
"timestamp": 1448291979
},
"received_at": "2021-11-07T18:13:45.853601971Z",
"confirmed": true,
"consumed_airtime": "0.051456s",
"version_ids": {
"brand_id": "heltec",
"model_id": "cubecell-gps-6502-class-c-otaa",
"hardware_version": "_unknown_hw_version_",
"firmware_version": "1.0",
"band_id": "EU_863_870"
},
"network_ids": {
"net_id": "000013",
"tenant_id": "ttn",
"cluster_id": "ttn-eu1"
}
}
},
"correlation_ids": [
"as:up:01FKXSPDYNBKWQ6TDM63S7K15Q",
"gs:conn:01FKXRA9R5HZS810EQXQZXNA2Y",
"gs:up:host:01FKXRA9RB3GRW9BYR4QKN2VBZ",
"gs:uplink:01FKXSPDQW0GJZ56F1B9MGA8C1",
"ns:uplink:01FKXSPDQX60SRZ9BD93WMMYQD",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FKXSPDQX17WR0659SNHR75Z1",
"rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FKXSPDYMQR97JPEJNZ69248H"
],
"origin": "ip-10-100-12-138.eu-west-1.compute.internal",
"context": {
"tenant-id": "-----="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ",
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "-----"
}
Yeah I was meaning application payload is being cropped, as I am sending 18 bytes to be precise from end device, but only 6 are received as application payload on the ttn, even though on the tcpdump I can see more bytes as application payload than 6.
That far too often. Once every 5 minutes is the max you are allowed at TTN given your payload size. You also need to keep within the 1% legal airtime limit which you are probably exceeding at this point. So reduce the frequency of transmissions asap!
What you are seeing in tcpdump is the entire LoRaWAN packet including LoRaWAN headers. That is not just application payload.
So, to summarize:
This strongly suggests your node is simply not sending 18 bytes like you think it is.
Yes indeed, I realized where my error was, I didn’t know about the lorawan headers being 13 bytes, and it was throwing me a bit off track.
Thanks a lot!
Now immediately dial back your Tx rate as suggested/requested by Jac! 
(If not already done so)
I’m not sure as a scientific investigation a method of “It’s not working properly so I’ll hammer it really really hard far in excess of any legal or fair use policy to see if it improves” helps - it just continually confirms that it’s repeatable and makes it easier for law enforcement to find you.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.