Downlink issue with ebyte e78 Lora chips

Hello,

I have an ebyte e78 device in OTAA class C connection to my gateway.

The connection status has SNR: +13 and RSSI: -45.

I’m able to send uplink messages, however, often times, my downlink messages are not received by the end device, though they are scheduled on the gateway (so, the gateway receives them).

If I send an uplink message from the end device to TTN servers, then I’m able to send downlink messages for a while.

What could be the issue?

search the forum and see what they say about rssi

what time period is a while

10sec 20sec min or hours

According to this documentation: RSSI and SNR | The Things Network

My SNR is OK for SF9BW125, because it is positive and way above the minimum limit of -12.5dB.

It also says that RSSI is better when it is closer to zero, but I should be okay for up to -80dB RSSI for most devices.

Could this be an issue with e78 devices compatibility with TTN V3 instead?

Also to answer your other question, after a couple of seconds, maybe 15-20 seconds.

yes closer to zero the better to a point i keep my rssi to between -65 and -80
i have a 2 brick walls between my gateway and workshop
have you heard about channel bleed

do you understand fup

did you read and understood the part in the documentation about rx, tx and the timing around them

I’m not aware of channel bleed.

My rx1 delay is set to 5 seconds, the end device sends data 6 seconds after a receive occurs. Is this delay not enough?

It also appears that this problem mostly occurs when end devices are somehow disconnected or a reboot command is sent through AT commands.

In those cases, do I need to reset MAC session through TTN?

If gateway is turned on first, then devices are allowed to connect, I have a very stable communication for a couple hours.

However, if RSSI somehow drops lower than -80 dB and/or gateway is powered on after the devices are, then I have this issue; uplinks are okay, downlinks are queued but not sent until a successful uplink is received. Then downlinks work for a couple of tries, just to not work again.

A stronger signal doesn’t mean that it is better. If the signal received by the node is to strong, the node can’t handle it. It’s like someone shouting at you. You hear it, but you don’t understand it.
If the timing is ok, use two walls in between the gateway and the node - as already said above.

I see.

Putting a wall between the gateway and the end device definitely helped, as the RSSI is -80dB right now but it is more stable.

Before, the RSSI was unstable between -40dB to -65dB. This should be a problem yes?

Also, is it okay for some downlink messages not being sent, but retrying after a couple of seconds such as 30seconds and having them sent to end device is normal?

I’m using basics station connection to TTN from my gateway, I have a MQTT client and my downlinks are scheduled everytime, that’s for sure, it’s just that sometimes they are not delivered to end devices, without a couple tries.

Is this a normal case, or shall I excpect every downlink to reach destination? (In ideal situations)