Hi, don’t know if some people still have this issue but I tested in the context of a single-channel gateway (SCG) with downlink capabilities and it seems it is not really possible to avoid changing a bit the LMIC source to really have for instance join-accept sent on a fix frequency and especially another SF than the default one at SF7. The solution proposed by @arjanvanb only work if SF7 is used by both the device for all uplinks and the SCG. If the device and the SCG want to use for instance SF12, then calling LMIC_startJoining(); and set LMIC.txChnl to 0 corrupt the LMIC timing because the transmission time has been computed based on SF7. The results is that the RX1 window is scheduled too early compared to what is then advertised by the join-accept (5s window). Therefore the modification proposed by @mogyoros work better.
Meanwhile 2020, I’d really recommend getting one of the cheap full gateway options instead.
Yes totally agree, we are using RPI+RAK2245 a lot. But we also deploy a lot of very cheap single-channel gateway for small-holders in Africa who only want to manage a dozen of sensors for rural applications.
I am new to this technology, but i saw when you go to the lmic library, you can edit the frequency setup for Rx-Tx by commenting all except one, or by chosing the max channel number to 1. but not sure that it will help since the channel switches all the time to find the best Bandwidth.
What you are suggesting makes the software non LoRaWAN compliant.
No, the channel switches all the time to avoid overloading a single frequency. Which is exactly what happens when people start using non compliant single channel solutions.
This thread is dated and single channel packet forwarders (single channel nodes included) are no longer supported on the forum. See: Single Channel Packet Forwarders are deprecated and NOT Supported [guidelines]
Advice for those new to LoRaWAN: better learn the concepts of LoRaWAN and how to properly use it.