I'm using RHF0M301 LoRaWAN Gateway module with my custom gateway board, not the Raspberry Pi platform and Semtech packet forwarder.

When i send a confirmed uplink message, the problem is occured.

The problem is that i can't receive downlink(ACK) with warning message.

In packet-forwarder console window

WARNING : A downlink was already scheduled. overwritting it...
INFO : [jit]lgw_status returned TX_SCHEDULED

There is no problem sending a unconfirmed message.
Packet forwarder work fine without any problems.

It is only a matter of receiving the downlink.

However, there is no such problem in the raspberry pi platform environment.

In the raspberry pi platform environment, I can receive downlink or ack.

This problem seems to be caused by the differnce between custom board and
raspberry pi.

I think that spi and reset pin are connected properly.

When i excute test_loragw_reg, the following message is displayed.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
End of register verification
IMPLICITY_PAYLOAD_LENGHT = 197 (should be 197)
FRAME_SYNCH_PEAK2_POS = 11(should be 11)
PREAMBLE_SYMB1_NB = 49253(should be 49253)
ADJUST_MODEM_START_OFFSET_SF12_RDX4 = 3173(should be 3173)
IF_FREQ_1 = -1947(should be -1947)
End of test for loragw.reg.c
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I think these messages prove that the pins are properly connected.

Is there anything else to consider besides pin connection?

[jit] seems to indicate that the downlink request couldn't be served because of the LBT function ; in other words the medium was busy and therefore the downlink couldn't be done.

Can you check and compile a non-LBT version of the packet forwarder to make sure?

regards

Hi,
pktfwd trace WARNING: a downlink was already scheduled, overwritting it... regardless of LBT configuration present. It would be useful to know the real meaning and and how packet are treated (wich packet will be sent ? the one already present -scheduled- or the other one -overwrite it...-) also because pktfwd do not send any advice of this to the LoRa Network Server and than the packet is not recoverable.

Could you provide an explanation of how pktfwd behaves in this scenario ?
Thanks in advance
B/R

I have the same problem. Any fix?
This happens to about 30% of my downlinks