I’m using RAK7240 in package forwarder mode to transmit messages to my own server.
Looking in the LoRa Packet Logger I see that each uplink that I send is sended by various simultaneous channels.
If there is only an uplink its not a problem, but it is when I’m expecting a downlink, so each uplink makes a downlink response, affecting to the traffic:
Hi Welcome to the community,
nope it is not a normal LoRaWan behavior.
how many nodes are sending uplinks at the same time? because i noticed the gateway sending a RadioBusy message which means too many nodes are trying to uplink at the same time… also are your node expecting a confirmed Message? if that’s the case and the network is busy your end node might keep sending uplinks until it gets that confirmed downlink message.
also can you share what kind of end node you are getting the uplinks from?
It was discussed before here in the forum by one of the RAKstars member that it can be a caused by overwhelmed RF frontend. How far is your device to the gateway, if they are too near, probably move it further in few meters or move it to another room to have signal attenuation with the wall.
I’m using CMWX1ZZABZ-078 module, the STM32 microcontroller based with the LoRaWAN stack provided by ST modified, working on class A and sending uplinks of 1 byte every 20s, with 32 end-nodes.
The downlinks are sended by the server to power ON lighting of the end-node when the server receives an uplink and it has a queued message to send.
The radio busy cause is sending 2 downlinks at the same time with only 1 gateway, because we only have 1 downlink channel.
I have taken the gateway 20 meters away and with some walls between GW and nodes, and its doing the same, maybe with less ocurrence, but I have multiple uplinks on some nodes:
Hi if I understood your setup correctly my guess is that your end node is controlling a light fixture that is connected to a grid and if that’s the case then the node is not battery powered but grid powered! And as per LoRaWan specifications you should not use “Class A” in this scenario but instead use “Class C” which is the proper class for always connected nodes that allows you to send downlinks anytime without having to get an uplink first! It also allows you to do Multicast downlinks as well! So I recommend you do some reading about class c and plan your scenario around it.
Using Class C will help you avoid all of the unnecessary 20sec uplinks! As the nodes will always be connected to the gateway and ready to receive a downlink anytime!
Hi @dani_JVV
What I’m trying to say is that your way of implementing the nodes use, calls for Class C because doing a 20sec uplink is definitely not a class A architecture and will not respect the fair airtime use policy and will run your battery down anyway, while causing unnecessary congestion of the network! So if you are looking to stay connected to the gateway at all times please use Class C! and base your power management around that!
To avoid multiple uplinks try turning off the “Confirmed Message” by switching to unconfirmed messages!
Those pairings of moderately strong and very weak signals at the same time on different frequencies are perfectly consistent with either RF overload, or a malfunctioning transmitter or receiver that’s either putting some additional energy out on a spurious frequency, or misinterpreting received energy as being on a different frequency than it actually was.
The server should discart the uplink with worse RSSI / SNR, is that right?
Not exactly “discard” but any reply or ADR calculation should be based on the strongest of the signals being reported to the server within the de-duplication time window, which since these are at effectively the exact same time would definitely be the case. A few years back there were some bugs in some servers that would get confused with multiple reports from the same gateway but those should be long fixed.
The comment that your 20 second uplink intervals are drastically too frequent is however correct - you’ll need to re-think your overall architecture/design.
