RAK8249 Bad Coverage

[Zaid (Zaid Nasralla)]

Issue: Bad coverage

Setup: Roof top about 12 m height

LoRa® Server: TTN

Details:
I have installed the gateway on a pole with 12m

height, 5.8 dBi antenna, 16- channel, I could not get more than 400m with LoS. No cables for the antenna, it is directedly connected to the gateway, radios configuration are default. Below readings from inside the building below the gateway ( with these two nodes). Even outdoor next to building, I did not get RSSI more than -70db

[cstratton (Chris)]

My main concern here would be why your log is showing multiple join cycles.

Are you sleeping the ESP32 in a why which does not retain data? That’s really not going to work. You need to retain the join session state through any sleep mode of a node, doing what you are doing and re-joining for every transmission will just waste a lot of downlink capacity and battery and burn through the join nonce space to the point where your node won’t be able to register any more.

In terms of the question you are trying to ask, -80 RSSI isn’t terrible for something close-in, though it’s possible you have an issue such as an unsuitable antenna for the node or the gateway, or a node that was made for a different frequency band than you are using it on.

The real key would be to see what happens as you get further way. All of your traffic seems to be at the fastest spreading factor regularly used, which is to say the shortest range mode. With a short payload like that on EU868 you should be able to go all the way out to SF12 for a substantial improvement.

My guess here is that your main issues trace back to a not-quite-right node firmware.

[Zaid (Zaid Nasralla)]

@cstratton

Are you sleeping the ESP32 in a why which does not retain data? That’s really not going to work. You need to retain the join session state through any sleep mode of a node, doing what you are doing and re-joining for every transmission will just waste a lot of downlink capacity and battery and burn through the join nonce space to the point where your node won’t be able to register any more.

Thanks for the recommendation, but I am doing that manually for testing purposes.

[Zaid (Zaid Nasralla)]

@cstratton

In terms of the question you are trying to ask, -80 RSSI isn’t terrible for something close-in, though it’s possible you have an issue such as an unsuitable antenna for the node or the gateway, or a node that was made for a different frequency band than you are using it on.

The node is RAK7205 868MHz, Gateway RAK7249 868MHz, the Antenna 5.8 dBi 868MHz, which one is not compatible? Even the ESP32 node is 868MHz. BTW: I used PSA2701T Spectrum Analyzer to verify the frequencies of the uplink and downlink, and I found both using the specified frequency.

[Zaid (Zaid Nasralla)]

@cstratton

The real key would be to see what happens as you get further way. All of your traffic seems to be at the fastest spreading factor regularly used, which is to say the shortest range mode. With a short payload like that on EU868 you should be able to go all the way out to SF12 for a substantial improvement.

This is my question, if I am using ADR, why it is keep using SF7 and sometimes SF8.

[Zaid (Zaid Nasralla)]

[cstratton (Chris)]

@Zaid

This is my question, if I am using ADR, why it is keep using SF7 and sometimes SF8.

You’re using it close enough to the gateway that those are the proper choices -80 RSSI is very “loud” in terms of what LoRa can work with.

Move the node further away and ADR should adapt, but only slowly - it may take hours to more than a day, as it will only fall back when the packets are no longer getting through or getting through with very marginal signal quality. ADR isn’t really designed for moving nodes, and downlinks are expensive so rare thus it cannot adapt quickly.

If you want to do coverage testing your probably want ABP rather than OTAA and to use a fixed spreading factor, SF10 would be good for testing.