I have two RAK3172-E Evaluation Boards, running an unmodified firmware version 4.2.0, updated from 4.0.x, both versions exhibiting the same problem. Configuration was done via USB by sending AT commands to /dev/ttyUSB0 (or 1).
After configuring them as class C devices, both locally and on TTS and checking that the device joins, it does not receive or process the downlink message which was sent from TTS. The gateway which the device uses to communicate with TTS actually sends the data to the air but for some reason is not processed. Two different gateways were tested, one with a SX1250 chip and the other with a SX1257 chip, exhibiting the same problem. Using the AT command AT+RECV=? shows AT+RECV=0: OK and no other characters are observed on the terminal.
If an uplink message is sent with AT+SEND=1:1234 , the data is received on TTS and shortly after the downlink message arrives as +EVT:RX_1:-47:4:UNICAST:1:1234 . If other downlink messages are sent, they are received and printed on the terminal. If the RAK3172-E is reset or power cycled, it will not receive any other downlink messages until it sends an uplink message.
LPM is set to 0 and other settings seems to be correct. Is there any other setting on the RAK3172-E which should be considered or is this a firmware problem?
(1) What is your LoRaWAN region?
Some regions start with only 2 or 3 channels opened and it takes one to two downlinks before all 8 channels are setup on the end device.
What frequency is used for the downlink that doesn’t receive the RAK3172?
(2) Are you sure the downlink is showing in the gateway logs?
Some LNS require at least one uplink before they send downlinks.
The gateways are configured as Europe 863-870 MHz (SF9 for RX2), the end devices reports AT+BAND=4. I can add that if I send multiple downlink messages, only the last one will be seen on the end device after it sends an uplink message.
According to the logs, a LoRa packet is received from TTS, gets queued for RF transmission, gets transmitted and gets dequeued. No errors can be seen or error counters incrementing. But if I send a downlink message to two end devices at the same time, I see that TX rejects one packet (collision). The “COLLISION_PACKET” error can be observed on TTS live data as well. So, it seems high likely that the downlink message is sent to the air. As a side note, the gateways are configured with Semtech UDP Packet Forwarder, not LNS or CUPS.
Ok, so it is not a bug but a protocol definition, despite the protocol version differences (1.0.3 vs 1.0.4). I will consider this. This topic can be closed.
