No. When LMiC prints RXMODE_SINGLE it’s actually listening for a short time, to see if it can recognise the “preamble”, and if it finds that, it will just read the downlink for you. (Actually the LoRa chip will do that for you, when LMiC tells it to.)
As the clock of the node might not be very precise, using MAX_CLOCK_ERROR one can make LMiC start listening a bit earlier, and listen a bit longer.
Also, don’t ignore:
And what did you intend to write here?
Hello,
First, apologies for the interruption.
Second,
I have been trying to figure out how to receive downlink messages, but I am not able to receive anything. Uplink works fine with no problems. The build I am using is the Dragino kit (LG01-P Single-Channel Gateway, Arduino Uno + Dragino LoRa Shield) for US915 MhZ. The IoT server is TTN, activation mechanism is ABP, and the library used is LMIC.
Gateway configuration →
TTN Gateway Traffic →
As Bernd first mentioned (our setup is similar), the gateway packet forwarder code seems to support downlink, and it is indeed receiving downlink from the TTN and transmitting what has been received. →
Node logs →
As shown in the images, I am using 903.3 (SF7BW125) for uplink, and 923.3 (SF12BW500) for downlink.
I have tried incorporating
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
in the code, but it didn’t solve the problem.
From what I have observed, the gateway seems to report receiving the downlink and transmitting it just as the node’s log report the second
RXMODE_SINGLE
Thus, I thought of trying to increase the delay value of the RX_1 receive window from the lorabase.h file, but that didn’t help.
Any suggestions? 
Thanks in advance
Please don’t post logs as images. Now I’ll leave it up to you pinpoint that some of your setup mentions SF9 for downlinks, while the gateway logs shows TTN uses SF12 instead.
See also https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928
Thank you for your reply Arjan. Sorry about the image logs!
I believe you’re referring to the gateway transmit spread factor? I changed it to 12, but no luck.
I just tried changing the SF of the first RX_WINDOW to SF12 to test if it changes anything, but I am still nothing. However, the gateway’s log now reports receiving a downlink and transmitting it just after the node’s serial monitor shows the first RXMODE_SINGLE (I guess the timings are more aligned now?).
Regarding the TTN frequency plans page - am I missing something?
I am quite new to all of this, forgive the ignorance 
Too bad your single channel gateway is apparently using a fixed frequency and SF for downlinks (if I understand the setup screen correctly); for downlinks it could easily use whatever TTN tells it to use. I’m not sure how to read the frequency plan, but TTN and your node are probably using the same settings, while your single channel test gateway seems to use specific settings.
You can see if RX1 or RX2 is supposed to be used by comparing the tmst of the uplink and the downlink. The difference is the time in microseconds. For your previous screenshot it was 2 seconds, hence RX2 indeed.
Hi, one thing that I am still checking out, based on an earlier question of " Are you sure that the backend is broadcasting on the expected frequency?"
It seems that, in my case, we are using the 868 MHz specification, but the Thingpark backend is using, according to their specification, the G3 subband which operates at 434.04 - 434.79 MHz…
So based the fact that you are also not receiving downloads, I would suggest that you also make sure, that the backend is using the expected download frequencies.
TTN frequency plan shown in the link you provided me displays 8 channels for uplink, each channel corresponding to a downlink as well (903.9 → 923.3… 904.1 → 923.9… etc). All un-used ones were disabled (as I am using a SCG).
Therefore, I think specific settings are applied on all 3 sides (TTN, gateway, and node). Logs from the gateway show that every time a downlink message is received, it is received in the same configuration as the ones before.
Then I assume that if I set RX1 & RX2 to (SF12BW500), I’d be guaranteeing receiving it every time if timing is correct? (Since all downlinks coming from TTN seem to be using the same SF, BW, and frequency. Only difference in windows used).
Thanks for your reply sir. I first checked the LMIC library’s lorabase.h file to confirm what frequency is used for downlinks if CFG_915 is used (since I am using US915), and it matches what I specified for downlinks. Also, I have taken a look at the gateway traffic in the TTN console, TTN also seems to be using 923.3.
lorabase.h file
// Default frequency plan for US 915MHz
enum { US915_125kHz_UPFBASE = 902300000,
US915_125kHz_UPFSTEP = 200000,
US915_500kHz_UPFBASE = 903000000,
US915_500kHz_UPFSTEP = 1600000,
US915_500kHz_DNFBASE = 923300000,
US915_500kHz_DNFSTEP = 600000
};
enum { US915_FREQ_MIN = 902000000,
US915_FREQ_MAX = 928000000 };
Downlink messages seem to have (288 - 329ms) airtime. Is this normal? Uplinks average at 66ms.
Thanks in advance
The devices I have seen operate either in the 868 MHz band or in the 433 MHz band, because the HF part has to be tuned to the specific frequency range. Therefore I think it is highly unlikely that the backend responds in the 433 MHz range when the join request and the uplink operates in the 868 MHz range.
But, as I don’t know the Thingpark backend, I cannot say this for sure.
I total agree with you - currently discussions with local technical folk.
It seems that they are unable to confirm what the download frequency is at the moment, but they are looking into it.
I am now setting up a Microchip dev board as a test bed to see if I have the same problems as on the Feather board.
I have played around with the dragino gateway and I found that the downlink feature is kind of implemented but hardly usable.
First you have to make sure that the packet forwarder is installed on the arduino in the gateway and that it is the version ending with 003.
Then you have to uncomment the following line in the config.h of the LMIC library:
#define DISABLE_INVERT_IQ_ON_RX
In the main program I set the delay for the first RX window to 3 seconds and increased the value for the clock error to 10%
LMIC.rxDelay = 3;
LMIC_setClockError(MAX_CLOCK_ERROR * 10 / 100);
With these settings I was able to receive a downlink message, but this is hardly usable for more than testing.
It also seems that the downlink message is transmitted by the gateway after the second uplink message from the device. After the first uplink message the downlink counter in the TTN is incremented und probably also sent to the gateway. It seems that the gateway then stores the message and transmits it after the next uplink message was sent. This is somewhat usable as long as just one node device is working with the gateway. As soon as a second device is added it is very likely that the downlink messages are sent to the wrong device.
The current implementation of the dragino packet forwarder seems to have a very high latency which makes it impossible to get anywhere near the correct timing for downlink messages.
Thank you so much for your reply Mr. Bernd. I have successfully received downlink, though “Invalid downlink”, but something is being received nonetheless.
Precisely. It’s the same in my case as well after applying your fix. Downlink is only received after the 2nd uplink transmission is done.
Now I’ll move on to trying to read correct data instead of “Invalid downlinks”.
But for the uplink it specifies SF7 to SF10, while for the downlinks it lists SF7 to SF12. Also, the uplinks have 9 frequencies, the downlinks only 8, so I can only assume that 904.6 SF8 should not be used when relying on downlinks, like when using ADR? Not a clear specification if you’d ask me. Also, US has the notion of “hybrid” which is not mentioned at all?
If that’s true, then I’d not alter my application/node but I’d look for a different test gateway, or get a full gateway.
But indeed, if the downlink has not already been scheduled then TTN might not wait long enough for the application to return a downlink. But then TTN is scheduling it for the next opportunity, not the gateway; see My application's downlink is always queued for next uplink.
(This ESP8266 test gateway worked great for me, for EU868. See also @bluejedi’s list in Single Channel Packet Forwarder part 3 [Deprecated] .)
