Iāll hope your are lucky with the Kiss LoRa-antenna and the node with the elektor arduino parts.
A couple of days ago I went by car from the North of A. to Zutphen with the KissLora on the rear shelf.
There has been connection with 3 gateways: Mheen, Myrtillushof? in A.
en Auxenze,Industrieweg, Zutphen.
At the moment my device has send 50848 packets. 1 : 10 was received by a gateway.
When looking at the KissLoRa demosoftware itās conform what you can see in de Arduino IDE serial monitor below.
So for the moment Iāll keep the Kiss LoRa in the āoriginal formā.
Thank you, Batilan. I flashed the sketch and did the setappeui provisioning trick and KISS Lora is sending data to my single channel gateway. But not all features described in dokumentation of KISS seems to work. It takes a long time to show any reaction after turning the rotary switch and sometimes I canāt see any reaction. Any idea whatās going wrong?
Keep in mind that the spreading factor used during transmission influences the distance you can cover to a gateway. The higher the SF the longer the distance. The KISS demo app uses a random SF so the arrival of your packets will vary accordingly.
If you want to experiment and have reproducable results have a look at this part of the code:
Thanks, but Iām afraid to crash the gadget when I try to dowload new software. Iāve bad experiences with this āArduinoā alikes.
Now I do my LoRa experiments with the Pycom Lopy. Easy programming in python with the Atom IDE on Linux and direct results as a second kiss-lora-device.
My closest acces point is 8km from my home (open field) is it reasonable to expect a proper connection? If so I will try to fix the antenna, or replace it with a half wave dipole.
Yes it is, I have succesfully modidfied my KISS and suddenly it connects to a gateway 9km from my workplace. Be sure to play with the spreadfactor setting to get a consistent link, I use SPF 12.
I have my KISSLoRa with me in my car and have it configured in the TTNMapper gadget. Today I drove by a gateway and it connected and finally got the OTAA keys near Ede, this was at 1km distance. Later I send some data via a gateway in Arnhem at 5km distance. So larger distances is no problem, but getting connected via OTAA is a bit difficult. I guess it would be best to use ABP on this gadget.
I know the RN2483 try to join on OTAA with SF7, but I never really figured out what their back-out algorithm was. You would think itās somewhat close to LoRaMac-node, but the RN2483 gives up way too soon for it to have tried several time at every spread factor.
In fact, this topic seems to imply there are no back out strategy for OTAA, and the user is supposed to implement one themselves.
Just in case, try adding āmac set dr 0ā before your āmac joinā, and check on the TTN console the SF of the JOIN_REQUEST message.
This is dependant on how you control the RN2483. TTN uses by default SF7 for OTAA but you can force OTAA using SF12 if you want. When static ADR can than control the node to go up to the aproperiate SF that fits the propagation path. Settings are done in the TTN library.
I never used the TTN library to control my RN2483s, only the command reference manualā¦ and I never saw anything in it hinting at this behavior, hence my comment.
Furthermore, my experience is that JOIN_REQUEST can be sent at any SF, regardless of the network. The network only controls the ADR (so SF and TX power) if enabled on the node, and the SF/frequency of RX2.
Anyway, the spread factor used for JOIN_REQUEST doesnāt depend on whether ADR is enabled or not.
Any RSSI/SNR figures or coverage comparisons available already? 
