No join accept after join request

Thanks a lot for your answers, I really didn’t notice these values are much to low.
I re-plugged the antennas and the values are now slightly better.
But still they are much too low. ( “rssi”: -119, “snr”: -2.2).
The antenna on my end node was given to me without any more information (I assume wrong freq, nothing written on it).
I order a new one and will keep you up to date!

A SNR of -2.2 dB should be ok to establish a connection up to SF7. What is the distance between node and gateway?

1 Like

The distance is three meters and there is no wall in between.
Since the rssi should be between -30 (good) and -120(bad) I expect the antenna to be mismatched.

Under normal circumstances this is much to close. Put the node away from the gateway.

It’s like someone shouting at your ears: you hear him but you don’t understand anything.

1 Like

I removed the device and gateway away (about 30m, including some walls).
Still more or less the same (“rssi”: -126, “snr”: -8.5)

Are you sure that the gateway that is receiving your node is your gateway?

I am, I compared the gateway-ids

So I now have the antenna but this did not make any difference.
Interestingly, the join works with another (similar) board. The snr and rssi are as bad as ever.
I tried it with four boards and only one worked (but only if closer than 10m to the gateway).
The other three had an RX timeout.
I increased the distance to more than 200m but then I had no signal at all.

Does anyone had a similar signal power problem using the RFM95W module?
PS: I tested with a second gateway and the values where the same.

What is the MCU you have wired to the RFM95?
Soldering hiccups happen, can you check continuity on all the pins, particularly DIO1
Which LoRaWAN MAC are you running on your MCU?

1 Like

IIRC, LoRa chips like the sx1276 have several RF outputs, a normal RF output and a “boost” output.
Also, you might have an antenna switch between the antenna and the RF input.
You need to check and make sure what kind of arrangement is present on the RFM95 module.

If the wrong output is selected or if the antenna switch is not driven correctly, I can imagine it works really poorly, with low RSSI/SNR.

Unfortunately, I could not quickly find a schematic of the RFM95 that shows this clearly.

1 Like

Fair chance the radio board is not intended for the frequency being used

2 Likes

Good point, @nicoca, can you post a picture of the underside of the RFM module - the side with the text.

1 Like

I use a STM32L452. The soldering is good, I rechecked with an oscilloscope every signal.
The problem is more that I don’t receive any signal at the RFM95.
My LoRaWAN MAC-Layer Version is 04.04.02.

I thought about that as well but unfortunately I only received the soldered boards.
But I will ask the previous developers.

At this point: Thank you all for your helpful inputs!!

Hi bertrik

I think it was, what you described!
First I found out, a NiceRF module was placed (I thought it is HopeRF).
NiceRF modules (not sure if HopeRF as well, but Semtech do not) use the PA_BOOST output of SX1276, instead of RFO_HF. Setting the PACONFIG register bit 7 to 1 configures the module correctly.

This was a hard piece of work, so thanks for all your ideas!!!
I really like the community in this forum.

PS: rssi is now arround -50 and snr about 10.

3 Likes

Hello @kersing,

For a new use case we have increased the ping intervals Keep_alive from 10 seconds to 250 seconds, and State Interval 30 seconds to 1800 seconds. After changing the gateway configuration strangely devices are not receiving the join accept from the server, but the devices are sending the join requests.

But when the ping interval are set to default we don’t have this problem.

Can you explain us what is the reason for this behaviour?

Please let me know if you need any other information.

Thanks in advance.

Best Regards,
Pavan Ravuru

These need to be fairly small for the backend to consider your gateway to be alive. Try with 45 seconds or there abouts. Also keep in mind session tracking firewall timeouts, the connection should not expire.

Why use values that large? With the default values a gateway consumes less than 100MB traffic a month, with these settings things break as you noticed.

@kersing Yes with the default configuration it consumes less than 100 MB. But the use-case is to get the connectivity on the open sea. So we are using Satellite connection and if a single gateway consumes around 100 MB it is going to be super expensive.

Moreover we are using single satellite modem for two gateways. When both the gateways are pinging continuous, communication window of the satellite is opened for a longer time and when it is open for more than 200 seconds. We are getting penalty on the actual data usage.

This is reason why we choose to have a high ping interval.

Those values will not work for an UDP based packet forwarder, you could try BasicStation which is TCP based and check if that fits your use case better. Or look into satellite based LoRaWAN nodes.