LORAWAN Field Tester


We are having LORAWAN Field tester and WisGate Edge Lite Gateway.
With this setup we tried to check minimum and maximum range distance and RSSI.
In this case Distance and RSSI are showing same values as 250 m and RSSI varies with change in location.
Number of Gateways values is 1 as we are having 1 Gateway.

Here can you please help us to understand why distance is showing fixed value 250m.
Please note that we have also referred below URL

Please guide us on the same.



Hello Dinesh,

There was a bug in the decoder.
It was updated 3 weeks ago in our Github Repo

Can you try with the updated decoder?

Sorry for late reply.
We will check this out and will get back to you.

Just today I built a lightweight daemon to support the RAK10701 (very slick device, nicely done). Using Paho-MQTT and cJSON, I built a stand-alone service that runs on my ChirpStack server instances using the MQTT interface. I referred to the configuration directions for ChirpStack/Datacake.

I wasn’t quite sure what to make of this snippet of code from the Datacake decoder. It seems to compare the calculated distance (in km) with minDistance/maxDistance, which seem to be in meters. For example, if decoded.minDistance is 1800m and new_distance is 10km, it would seem to update decoded.minDistance to 10000m, so on. decodec.maxDistance appears to stick at whatever the first new_distance value is. Looking at the GitHub repo, this is indeed the bug fixed 3 weeks ago; there’s still old code on the RAK10701 webpage/guide.

            // Calculate distance
            var new_distance = distance(gw_lat[idx], gw_long[idx], decoded.latitude, decoded.longitude);
            if ((new_distance < decoded.minDistance) || (decoded.minDistance == 0)) {
                decoded.minDistance = new_distance * 1000;
            if ((new_distance > decoded.maxDistance) || (decoded.maxDistance == 0)) {
                decoded.maxDistance = new_distance * 1000;

I ended-up just converting distance to meters before doing min/max handling, and the minMod/maxMod are just those disances in units of 250m. At least that seems to be giving the right results. I sure do like the RAK10701.

Lamarr, Inc.

Hi @danak6jq
Can you share your daemon?

The doc pages are in the process of updating. The correct script should be online soon.

1 Like

The daemon is a science-fair experiment at the moment - I’d like to clean it up a bit before releasing to the wild (in particular, at least make it a proper systemd service). Toward that end, I’ve invited you to a currently private repository and welcome your input, or you may fork/derive from/share it as desired.

I got your invitation. Thanks. Will have a look.

1 Like

While it’s still a bit of a science experiment (particularly, needs systemd integration, just haven’t had time to focus on that yet), the “rftd” daemon is proving stable in testing with Chirpstack v3. It isn’t leaking memory or consuming much CPU time (very little, actually), so I’ve changed the repo to public for anyone else interested in testing this.

danak6jq/rftd: RAK10701 Field Tester daemon for ChirpStack v3/v4 (github.com)

Note that the ChirpStack configuration may need adjustment to MQTT QoS (I suspect not, but beware if you have other MQTT subscribers)

One thing I’ve noticed - because this is a local service running on the ChirpStack server system, it usually responds to ULs immediately. I noticed - not surprisingly - that using a cloud-based back-end has enough latency that the downlink always has one report period of latency (it’s always one ping behind).

With this server located on the ChirpStack server, it reliably schedules the downlink quickly-enough that the RFT receives the GW report in the Ack downlink of each ping. This is handy for mobile operation.

I am primarily testing on Chirpstack v3, but did test on Chirpstack v4. Please report any issues via GitHub

Feel free to clone, fork, send me PRs. Please retain the copyrights and license attribution, of course.