How to connect Utrecht E&A exhibition KISS LoRa to TTN?

The latest versions can be downloaded from Arduino itself via: Sketch >> Include library >> Manage libraries. You can search for The Things Network

It can also be downloaded from our GitHub: https://github.com/TheThingsNetwork/arduino-device-lib

@hw-geitz
The device only needs to be connected to a pc / laptop for uploading new software. If you’re not doing os, it uses the pc for the power supply, but you can use the battery for this.

@ppeters @hw-geitz

Can you check the following:

  • Did you set OVERRIDE at line 77 to true?
  • Open the Console, click on your application, click on the tab Data and check if you see anything coming in.
  • Please check if the deveui (or hwEUI) which you can see in your Serial Monitor is similar to the Device EUI shown in the Console under your device. If this differs, please change the EUI via Settings in the Console.

Hopefully this works. Otherwise the issue is with the keys you put in the device, the coverage in your area or the device itself.

Hi All, Finaly it works!
The problem in the keys,
After commisioning the gadget again, I checked the hweui with the output from the consol and the hweui were different.
in Applications => kiss-lora-hw-geitz => Devices => kiss-lora-device-***** => settings I chanced the hweui code.

And the gadget starts working. generating output!

tnx Laurens for directing me in the right direction.

Small summery:
use KISSLoRa-demo_app scetch and edit
static const bool OVERRIDE = true;
static const char appEUI = "70B3****"; <= your gadget appEUI
static const char appKey = "4640F4ABB9A7465B524E1B0D"; <=your appKey
Upload to gadget.
Check gatget console output
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
– Status
EUI: 0004*****
Battery: 3294
AppEUI: 70

DevEUI: 0004A00000000 <===== copy this to your ttn console
Data Rate: 3
RX Delay 1: 1000
RX Delay 2: 2000

This worked for me.
Tnx all for the input hints and tips!
HW

1 Like

I was one of the lucky guys to get the gadget during day 1 of the E&A fair.
Unfortunately I had a busy schedule so at the end I never commissioned the gadget at the fair but as soon as I was home I downloaded the github archive using the information on the received information sheet (github.com/yourproductsmarter).

There was a strange bug in the firmware; there need to be 11 spaces in between the appeui and the appkey.
To point others to this, I decided to check the actual code line in the current github archive.

Surprisingly, the code that is in there right now is different from the code that I downloaded last week :fearful:
This means that the KISSLora-demo_app in the current archive is different from the one in my device.
The archive at https://github.com/TheThingsIndustries/KISSLoRa-demo looks more like the actual code that was programmed in the device during the fair. I suggest to use that code if you want to play with the original firmware.
Just follow the instructions to install the drivers and libraries. Now you can connect to the device from within the Arduino environment, use the serial console and program the device if you want.

Commissioning the device is done by first reading the deveui (type getdeveui in the serial console), then add a new device to your application (create an application first if you don’t have one yet) and then install the keys using setappeui:0000000000000000 1234567…89. You may need to specify 11 spaces in between the application EUI and the application key (at least this was true for my device).
After this the device should work.

The device works, but the antenna is a failure. It is supposed to be a good antenna and maybe it is, but I am not convinced the matching circuit is correct. Also, if the antenna is bent (it is very easy to push the floating part of the antenna down), the antenna impedance changes enough to be noticeable as a lower RSSI level reported by TTN.

This may (will) result in a non-optimal range but if you are close to a gateway there should not be a problem.
I had a good connection at 100m from my gateway with 2 this concrete walls in between the gateway and the KISSLoRa gadget and I only have a small 'rubber duck" antenna attached to the gateway.

The gadget is fun to play with. But the battery only lasts for about 1.5 days so make sure you have your PC or a USB charger/power bank at hand.

Rob

Indeed the antenna is not so effective. I made this quaterwave antenna, and i’m 1100 meters from an accespoint.

And I have a good signal the gadget is 1 meter above the ground indoors

1 Like

That looks like an easy fix.
Just remove C23 and C24 and solder a wire to pin 23 (3rd pin from the side of the rotary switch).

The antenna should be a 1/4 wave antenna which is 1/4 * 300/868 = 86 mm.
I’m assuming this is the length you used?

If you are in for some experiment, start with 88 - 90 mm and measure the received RSSI level.
Cut small pieces from the antenna after every few messages to see improvements in the RSSI level.
(Note: smaller negative numbers mean a better reception).
Uncut the last piece as soon as you notice a lower RSSI level :wink:

For the best signal, the antenna should be placed vertically with a horizontal ground plane (the PBC)
I use this antenna for my Sodaq ONE:https://shop.sodaq.com/en/anaren-868-mhz-antenna.html and this is also just a 1/4 wave antenna with a UFL connector to connect it to the Sodaq ONE board.

Rob

  • OVERRIDE is set to true
  • No data is visible (The device is never seen…)
  • The deveui is ok as well ( but I will rererecheck tomorrow when I have the device available)
  • Coverage is ok (since other kisslora devices DO work)

I guess something is wrong with the device itself

Thanks so far…

How do I messure the rssi?

@laurens

I checked the conditions you mentioned again (OVERRIDE = true, deveui in console is the same as displayed in the serial monitor when starting the device). I even removed my device, application fron ttn console and added it anew (new appeui and appkey also put in demo-app code and uploaded).

That did not help, I get a sequence of:

Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.

3 times, then

Sending: mac join otaa
Response is not OK: no_free_ch
Send join command failed

13 times and then the sequence repeats itself
(is there a clue in this 3 - 13 sequence?).

As said before, it’s not the coverage since other KISSLoRa devices work perfectly well at the same spot, deveui, appEUI and appKey I now rerererechecked.

So what is this backend status?

What are possible next steps to debug the hardware?
(although all of the other stuff works as shown by running the other examples)

Still puzzled but grateful for the support,

Peter

It is listed in the console. Log in to your TTN account and go to the kiss-lora-… application and open the “Data” page. Every time the device sends data it should be listed here combined with the meta data like which gateway(s) received the packet. The rssi is part of the meta data (each gateway receiving the data will have rssi).

I just added an external antenne (wire soldered to pin #23 as mentioned. I now get some data in the console, but the gadget still shows that the oota is denied

{
  "time": "2017-06-09T09:14:14.325248788Z",
  "frequency": 868.1,
  "modulation": "LORA",
  "data_rate": "SF7BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "gtw_id": "eui-aa555a00080605b7",
      "timestamp": 1732999923,
      "time": "2017-06-09T09:14:14.490534Z",
      "channel": 0,
      "rssi": -120,
      "snr": -5.2,
      "rf_chain": 1,
      "latitude": 52.08394,
      "longitude": 5.1674,
      "altitude": 39
    }
  ]
}

I get RSSI levels varying from -113 to -120

In the latest sketch you can adjust the spreading factor for the join. It could help if you set this to SF 9 or 10.

I noticed the latest sketch also removed the ‘debug’ option.

Goto www.arduino.cc and download the latest IDE
good luck

In TTN Mapper i see the same coverage from the gateway Located in “De Meen, Apeldoorn”, 0031552048001A03
Last heard at 2017-06-10 00:40:02 as indicated by my measurements.

So it is not strange with an rssi of -119 that the device stops transmission after 137 frames.

What puzzles me is that I went with the device two times to the gateway in De Meen and also the gateway AA555A0000088213 at the “Kadaster building” an i was unable to get the device joined (also not after powering down, power up and monitoring the serial line with the Arduino serial monitor on my PC…
— Resetting RN module
Model: RN2483
Version: 1.0.1
Sending: mac set deveui 0004A30B001EFC3A
Sending: mac set adr off
— Random Seed
– hwEui read from module: 0004A30B001EFC3A
– seed: 41935
— I2C Accelerometer initialized
EUI: 0004A30B001EFC3A
Battery: 3273
AppEUI: 70B3D57EF000545D
DevEUI: 0004A30B001EFC3A
Data Rate: 5
RX Delay 1: 1000
RX Delay 2: 2000
EUI: 0004A30B001EFC3A
Battery: 3273
AppEUI: 70B3D57EF000545D
DevEUI: 0004A30B001EFC3A
Data Rate: 5
RX Delay 1: 1000
RX Delay 2: 2000
Sending: mac set rx2 3 869525000
Sending: mac set ch drrange 1 0 6
Sending: mac set ch dcycle 0 799
Sending: mac set ch dcycle 1 799
Sending: mac set ch dcycle 2 799
Sending: mac set ch dcycle 3 799
Sending: mac set ch freq 3 867100000
Sending: mac set ch drrange 3 0 5
Sending: mac set ch status 3 on
Sending: mac set ch dcycle 4 799
Sending: mac set ch freq 4 867300000
Sending: mac set ch drrange 4 0 5
Sending: mac set ch status 4 on
Sending: mac set ch dcycle 5 799
Sending: mac set ch freq 5 867500000
Sending: mac set ch drrange 5 0 5
Sending: mac set ch status 5 on
Sending: mac set ch dcycle 6 799
Sending: mac set ch freq 6 867700000
Sending: mac set ch drrange 6 0 5
Sending: mac set ch status 6 on
Sending: mac set ch dcycle 7 799
Sending: mac set ch freq 7 867900000
Sending: mac set ch drrange 7 0 5
Sending: mac set ch status 7 on
Sending: mac set pwridx 1
Sending: mac set retx 7
Sending: mac set dr 5
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Response is not OK: no_free_ch
Send join command failed

Just now in my study room (1100 m from the gateway De Meen) i did a reset in order to check the EUI in the device and the EUI in the console and to my surprisei found out that the device was joined and data coming in

{
“time”: “2017-06-10T01:19:41.69515481Z”,
“frequency”: 867.9,
“modulation”: “LORA”,
“data_rate”: “SF7BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-0031552048001a03”,
“timestamp”: 807276668,
“time”: “2017-06-10T01:19:38.928471Z”,
“channel”: 7,
“rssi”: -117,
“snr”: -0.8,
“latitude”: 52.22202,
“longitude”: 5.993231,
“altitude”: 65
}
],
“latitude”: 52.216347,
“longitude”: 5.9813824,
“altitude”: 16

In plain Dutch" nou breekt mn klomp"

Any ideas ?

Jelle

In plain Dutch: “Ik heb geen idee” :wink:
Not sure how long you waited, it might take some time. Also some gateways are not capable of doing OTAA if they are configured with poly-forwarder to multiple backends (I found out “the hard way” :blush:).

Waited 2-4 minutes
In my study connection was made after approx 15 minutes

Btw connection was lost after 155 frames, 7 hours ago.
Last frame rssi -119, so i can understand that nothing is receiived now.

In the terminal screen i see every 20-30 sec: " …succesfull transmission"

Thx for your help.
Tomorrow i will move near the gateway and see if data will be received . If not, restart and wait 15 minutes for a connection.

1 Like

I went within 100 meter of a gate way and correct working was showed.
At home (400 meters of gate way) it was not working, maybe due to a poor RF signal of gateway.
Changed the antenne by a wire of 86 mm. Now it works also at home.
ps. TheThingsNetwork library 2.5.2 works fine.

terminal screen: …succesful transmission, every 20 sec
in the console: few hours data (rssi: -103 to -120) and then period of 3-10 h no data
Last received data: rssi: -113

Conclusion:
1-signal strength varies a lot
2-signal strength at 1 km is very weak most of the times
3-not a stable connection ???
4-No indication at gadget that data is not received (is that normal?)

Jelle