Microchip RN2483 Lora
Making downlink working correctly with RN2483 on LoRaWan is not a simple a quick thing to do if you do not have all the keys to do it. After spending some time to fix my code for this, here are the tips to consider and not forget !
On LoRaWan, downlink can be made in two different ways after a transmission. There are two receive windows right after the transmission.
The first receive windows starts right after the transmission and have de defined duration you can change with the RN2483 rxdelay1, the default value is 1000ms. During this delay, the device will expect to get a message on the same frequency and with the same datarate used for the transmission.
The second reception windows starts also right after the transmission but have a longer duration you can change with rxdelay2 parameter. The default value is 2000ms. The main difference is during this period the device expect reception on a predefined frequency with a predefined bitrate. The standard frequency is 869,525Mhz because this frequency can be used with a larger transmission power up to 27dB. The standard bitrate is DR0, basically 300bps. It gives a larger chance for the message to be received by the device.
A message received by the device have to be acked for being considered as transmitted by the gateway. Otherwise the gateway will perform up to 5 retry before cancelling it. The ack is done by transmitting a empty message to the gateway. Eventually if another message is in the downlink queue it will be transmitted as a response. This can be repeated until the queue is becoming empty.
On the RN2483, you MUST have activated the AutoReply setting if you expect to complete the transmission-reception procedure. If not the device you never terminate and returns the expected mac_tx_ok message.
To activate this setting, you have to type :
mac set ar on
This makes it working correctly.
The next thing to take into consideration when you are prototyping at home is when your gateway transmit at 27dB in a short distance of your device it will be too much power for the device receiver and it will saturate it. The ACK or the message will ne be transmitted correctly because of it. So in a local usage to make windows 2 reception working correctly it is recommended to reduce the gateway transmission power to 10-14dB.
a few corrections:
The first receive window starts rxdelay1 seconds after the end of the uplink transmission and have a default value of 1000ms.
The second receive window starts rxdelay2 seconds after the end of the transmission and have a default value of 2000ms.
The duration of both receive windows are very small, just the minimum necessary to sense the spectrum for an incomming frame (a RSSI threshold or CAD channel activity detection). If a frame is coming, then continues until the complete frame reception time needed.
Both uplink and downlink data transmissions can be confirmed or not confirmed (with ACK or no ACK). If you want to send downlink confirmed data from server to node, it is good to know the node need not to manage the ACK if you use the command “mac set ar on”.
Is there a way to access the RSSi of the last received packet when using RN2483 ?
I believe its not possible, but if you have a spectrum analyzer, then you can measure the RSSI value.
Not really, the loss is really high regarding the distance and environment. But some power meter can be used
If using ACK it sounds like there is some kind of messaging register involved. My concern would be a backup of messages, due to signal issues or perhaps intermittent hardware failure. This has plagued many wireless carriers in the past and can cause false positives when using this protocol for status alerts.
With your code however i’m sure you can write a “no ACK” command that can use a different protocol such as XML to get the message not being delivered and use that protocol to set forth processes for further monitoring.
How can I reduce transmitted power on Microchip LoRa gateway?
Very interesting, thankyou