in my test, after join i send 12 packets to ttn with no anwer. at counter 12, 13 ff ttn generate a uplink an i can receive it in RX0. why is it different from 0-12 than after?
Why do you expect an answer? LoRaWAN is an protocol targeted at heavy uplink and very few downlinks. As such no answer is to be expected.
As kersing suggested, data communication over LoRaWAN usually works without answers. The device just sends data data. There is only sporadic bidirectional communication as part of the ADR algorithm, see here: https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate.html
Your LoRaWAN stack on the device handles this internally and the application running on your device probably isn’t even aware that it is happening. You can recognise this traffic in the gateway console by it port number of 0. You cannot really tell why exactly the network decides to send ADR packets at a particular time, but you can now inspect the contents of ADR packets in the v3 console if it interests you.
By the way, communication from device to network is called uplink. Communication from network to device is called downlink.
I just want to know what it’s all about and why data packets are being sent that I don’t need.
OK, I understand, ADR requests. But with every package? Isn’t that unnecessary trafik?
thanks for help.
I found LMIC:setAdrMode(0) to be in control.
Except ADR is very useful - it means the device transmits at an appropriate rate, saving air time & battery life.
That happens if the backend notices you device doesn’t respond to the instructions being sent. What hardware and software are you using?
i use original ibm lmic. In buildDataFrame() on any packets (after 12 at begin)
if( LMIC.ladrAns ) { // answer to ADR change
LMIC.frame[end+0] = MCMD_LADR_ANS;
LMIC.frame[end+1] = LMIC.ladrAns & ~MCMD_LADR_ANS_RFU;
end += 2;
LMIC.ladrAns = 0;
}
ADR ist processed and LMIC.adrChanged has 0x87. Is this not the response of ADRchange?
You are aware the original LMIC is very old and newer versions have numerous bugfixes? The MCCI version is actively maintained and a far better choice.
The IBM code was still relatively simple. MCCI is too opaque and for arduino. so nothing for me. i want to understand the technology and not a header forest.
The code might be simple but it contains numerous issues that have been solved in the newer code. Issues that make the code non LoRaWAN compliant and will result in issues with V3 of the backend.
Perhaps you can use LoRaMAC-Node from Semtech?
I have MCCI for me ported from arduino to stm32 bare metal without arduino and without any STM Libs. Today i have no problems more. Thanks.
1 Like