Closed miqmago closed 2 years ago
0,5m distance between node and gateway is very much to close. The receiver of the node/gateway may be overloaded. Try 10m or a wall in between. If that doesn't work look for the memory overflow.
" I've also tried to set adr to false and force SF 7 but it always ends up with SF 12.:"
I observed this behaviour too with my T-Beams. I can't explain why this happens. There seems to be a MAC-command from TTS that switches the node to SF12.
Thanks @wolfpcgn! I've made some more experiments, moving away to different distances and the result is the same, having payloads with some wrong bytes (1 to 5 wrong bytes) at random positions. I've also tried with different MCU and some of them always fails and some of them never fails.
I'm starting to think it could be a hardware issue with some boards. Just to discard memory overflow, any idea on how could I check it? Right now I'm printing the received frame inside decodeFrame()
, I've placed debug printing code there:
LMIC_DEBUG_PRINTF("Frame: ");
for (i = 0; i < LMIC.dataLen; i += 1) {
LMIC_DEBUG_PRINTF("%02x", LMIC.frame[i]);
}
LMIC_DEBUG_PRINTF("\n");
I've been always sending the same data 0408070000
:
~3m
v v v
60371b6e0185040003310700010de7d4b0feceacc2fd64
60371b6e0185040003310700010de7d4b0fecda0c2ed64 YDcbbgGFBAADMQcAAQ3n1LD+zaDC7WQ=
~10m (1 floor)
vv
60371b6e0195070003320700010da49d7c151ffe6f68cf
60371b6e0195070003320700010da49d7c151ff44f68cf YDcbbgGVBwADMgcAAQ2knXwVH/RPaM8=
v
60371b6e0195080003310700010d55000a0c16ab606fa4
60371b6e0195080003310700010d55000a0c162b606fa4 YDcbbgGVCAADMQcAAQ1VAAoMFitgb6Q=
~15m (2 floors)
v v
60371b6e0195090003310700010d1bd27ee641e2782492
60371b6e0195090003310700010d1bd27ee611e2702492 YDcbbgGVCQADMQcAAQ0b0n7mEeJwJJI=
v v vv v
60371b6e01950a0003310700010d49d6763d335eefb14e
60371b6e01950a0003310700010d45d2763d63ddefb17e YDcbbgGVCgADMQcAAQ1F0nY9Y93vsX4=
~20-30m (outside building)
vvv v
60371b6e01950b0003300700010d8e261edb97fcad180c
60371b6e01950b0003300700010d8e261edb94b0ad189c YDcbbgGVCwADMAcAAQ2OJh7blLCtGJw=
vvv v
60371b6e01950c0003300700010d680e127e45dc0a4384
60371b6e01950c0003300700010d680e127e065c084384 YDcbbgGVDAADMAcAAQ1oDhJ+BlwIQ4Q=
v v
60371b6e01950d0003300700010dc23b2b97c14d87991c
60371b6e01950d0003300700010dc23b2b97a1cd87991c YDcbbgGVDQADMAcAAQ3COyuXoc2HmRw=
0.5m Different antenna
vv v
60371b6e01950e0003320700010dc6f649e54ef16b8fa8
60371b6e01950e0003320700010dc6f649e54ed4618fa8 YDcbbgGVDgADMgcAAQ3G9knlTtRhj6g=
I'm using chirpstack to enqueue downlinks to ttgo lora device. I've tried with 3 different gateways from RAK (raspberry PI, rak edge lite and rak edge lite2) and different MCU's (all of them ttgo-lora32-v1).
On small payload packets, 1 byte, all works fine and the packet is correctly received, decoded and verified.
When packet payload sizes are >= 2 bytes then the device starts to fail in receiving the packets. I've been trying with different packet sizes. The packet received on the gateway seems ok, I've been reading the packets from mqtt broker. I couldn't find a way to log the real bytes that the gateway is sending to the device, but all other communications (join request, accept, uplink, etc...) are fine.
To me the problem seems seems a memory allocation problem: it seems that the last bytes from the
LMIC.frame
are wrong usually starting from byte 27. In small packets it makes MIC to be wrong, but in large packets data is also wrong:I've tried with different distances, most of the trials with 0.5m distance and no obstacles in line of sight.
Environment
To Reproduce
device configuration
.pio/libdeps/latest-dev/MCCI LoRaWAN LMIC library/project_config/lmic_project_config.h
:The power supply of the device is completely cut off on each cycle, as it has an external power management system. The keys are stored on EEPROM on join success and recovered from memory on each cycle. I've also tried to set adr to false and force SF 7 but it always ends up with SF 12.: