Seedstudio/Disk91 wio LoRaWan Field Tester

Dear all,

I am testing the wio LoRaWan Field Tester, which is an open-source project from disk91, available on github. I purchased a kit from seedstudio. Then I removed the Helium key and installed a fresh firmware.

Surprisingly the integration webhook maps to a closed-server operated by disk91. So I am looking for information how to integrate it directly with TTN mapper.

Here is my webhook:

function Decoder(bytes, port) { 
  var decoded = {};
  if ( port != 1 ) return decoded;
  var lonSign = (bytes[0]>>7) & 0x01 ? -1 : 1;
  var latSign = (bytes[0]>>6) & 0x01 ? -1 : 1;
  var encLat = ((bytes[0] & 0x3f)<<17)+

  var encLon = ((bytes[3] & 0x7f)<<16)+
  var hdop = bytes[8]/10;
  var sats = bytes[9];
  const maxHdop = 2;
  const minSats = 5;
  if ((hdop < maxHdop) && (sats >= minSats)) {
    // Send only acceptable quality of position to mappers
    decoded.latitude = latSign * (encLat * 108 + 53) / 10000000;
    decoded.longitude = lonSign * (encLon * 215 + 107) / 10000000;  
    decoded.altitude = ((bytes[6]<<8)+bytes[7])-1000;
    decoded.accuracy = (hdop*5+5)/10
    decoded.hdop = hdop;
    decoded.sats = sats;
  } else {
    decoded.error = "Need more GPS precision (hdop must be <"+maxHdop+
      " & sats must be >= "+minSats+") current hdop: "+hdop+" & sats:"+sats;

  return decoded;

Unfortunately it does not return any information. I understand that hdop must be lower than 2.

Anyone using this device here? Sorry for posting here. I think a lot of TTN users are looking for a cheap testing device, so it might help. disk91 might answer but it might takes weeks so I am posting here.

Kind regards,

Incredible, I launched a field study and it is looking for Helium hotpots, as shown on the map (it will be visible only during a few hours) :

I am not interested in Helium … I think the device went off and is configured by default for Helium.

Not very friendly …

Anyone any idea how to get off this mess?


Not looked in detail but claims works with TTN - so

Integrations link the LNS (TTN in this case) and the end server/dashboard…so data wont ‘automatically’ jump from TTN to a target dashboard server unless you set it up.

  1. Is device registered in TTN?..and (proven) working correctly?
  2. Have you set up the Application/Device Integration to TTNMapper from TTN?
  3. I see I the github “Setup with Cargo (helium tracking platform)” - is that the target for current set up? is Disk91 scrapping from there?

From what you say suspect node still defaulting to Helium deployment - how have you configured the firmware/what firmware are you using? - Original or a re-write?

Ensure f/w isnt locking you into H/D91, recode as needed, register correctly in TTN…

…have you reached out to him (Paul) and asked for support/instructions on using TTN given he lists in features:

“Works with TTN and Helium”

Remember the nature of these types of devices is they tend to heavily rely on downlinks (Acks) to gather/report stats and ofetn are set up to push up against legal airtime limits - even breaking them if badly configured! If using with TTN please respect TTN FUP - 10 DL max/day :wink:

I think this may answer why it’s back on Helium …

Indeed - see WioLoRaWANFieldTester/ at master · disk91/WioLoRaWANFieldTester · GitHub

So you can track exactly 10 points per day with this field tester on TTN.

Edit: Or maybe even only 5 as the doc seems to imply that not only is it using confirmed uplinks but that it then gets a downlink with the RSSI & SNR for use on the local display.

Seeed is directed on Helium only - simply go on their Discord channel and post something about another Lorawan network - it will be deleted very quickly. And so its with their hardware - designed for Helium (except their “Grove” sensor kits) and nothing else

What is it about with the RAK Field Tester For LoRaWAN | RAK10701-P/RAK10701-L - would this be more useable for TTN? I didnt find there any limitations like its announced for the Seeed tracker

They are benign pieces of hardware - it’s how you configure them that breaches the Fair Use Policy for TTN. Car manufacturers mostly don’t tell you not to drive faster than the limit and/or warn about running people over.

There is mapping using the well established TTNMapper - which sends uplinks from a device with a GPS or a device without a GPS in conjunction with a smartphone app. That maps coverage - for which @Jeff-UK is very slightly beyond obsessed with.

There is asset tracking, which works very well with LoRaWAN on the basis that you have coverage at your various locations - so you can see a truck or a pallet or a box or an individual item has arrived somewhere. Otherwise it is in transit.

There is real-time tracking which can’t be feasibly done on TTN due to FUP and is a bit marginal due to legal restrictions on a commercial instance and instantly fails when you go out of range of a gateway.

And then there is field testing which I take to be evaluating an area to determine where the best places are for gateways & devices, mostly the former.

However for reasons yet to be explained to me field testing seems to involve LoRaWAN and lots of transmissions, rather like mapping but without any real science - the testers seem to get you to wander around a lot without any hint about where you haven’t been etc etc.

If I want to evaluate a site, I put LoRa P2P devices where the client wants the devices and then do a 2D or 3D (for building with more than one level) grid search with the “gateway” P2P device, look at the outputs on my iPad as I go and figure out how to get some decent, preferably overlapping, coverage. Then I leave some devices in “gateway” mode where I think the gateways should be, have a cup of tea, maybe a scone or a spam fritter, and re-evaluate the results. Sometimes I may move a test device within the parameters of the brief to help.

For in-building surveys, the first thing to do is to get a copy of the plans so you can see if it’s a big Faraday cage (iron girders, made from Irn Bru in Scotland) or made out of straw. Then you will know how hard things are going to be.

Sometimes the most counterintuitive position helps - like a skinny hi-rise and you park a gateway on either side but outside the building, letting the RF leak out the windows.

And in all of this, having a bag of TTIGs to do some emergency in-fills when the client puts a device where no one originally said is a good thing to have.

1 Like


Last time I checked LoRaWAN was a standard. And which network a device works on is determined by where it is registered (in which join server the JoinEUI, DevEUI and AppKey are registered).
If registered on both TTN and Helium it will be a lottery who ‘wins’ and on which network the device will be active.

The wiki entries for the Lora-e5 based hardware have extensive information on how to use them with TTN including steps on how to register devices.

Hello again,

Thanks for reminding of TTN usage. I am mostly mapping my own gateways, and this is a very limited usage. But I understand fair use policies. By the way, I have two outdoors gateways and I see plenty of messages flowing in and most of them are breaking fair-use rules. In the Mikritik LR8 I enabled the settings : “LBT Listen before talk”, guess this is important.

By the way, this is free air so should Helium break those rules when it comes to mapping ?

Yes I could register TTN using AT commands but whenever the Wio Lorawan Field tester goes off batteries, I loose everything. The only solution is to recompile from scratch and hard code credentials.

On of my gateway has a beautiful view 150° around on 20 kilometers when it is installed with batteries and sun panels. So everyone will be able to talk to my gateway and break the rules, but not me paying for hardware and being the land owner. Good to know !!!

Also, the device is using a dedicated payload for TTN networks as explained here:

The base URL web-hook to be used is :

I have no idea how to configure the Javascript payload, all this is very obscure.

What I would like is use TTN mapper itself and not a third party tool with a dedicated web-hook.

I will wait for answers from the author but it can take weeks.

Kind regards,

There are two limits that apply - one is a LEGAL ie regulatory limit that varies by territory and local legislation. All users can, in theory, go up to the legal limits, however, reality is that if everyone did what they CAN vs what they SHOULD then the airwaves would get increasingly unusable, and likely regulatory reaction would be to further restrict to still be able to offer some level of service. The second limit is the FUP. TTN has a FUP, not sure on Helium’s limits… As a community network we are conscious that the community needs fair use and access and therefore apply what may be considered socially responsible limits. This again is in two forms one covering uplink time - 30s per device per day - so that not everyone is screaming all the time and hogging the airwaves, even below legal air time (typically duty cycle or dwell time constrained), the otherside if downlink time - where we dont restrict by downlink airtime - but rather the number of downlinks. Why? - simply because every DL renders the sending GW deaf (they are simplex remember) to ALL uplinks from ALL users that might be heard by the GW, A selfish downlinker breaching this limit can have a major impact on the availability of the network for everyone. The other aspect of limiting messages - either by count or consumed airtime - is that those messages have to be handled by the ‘free’ to use TTN back end servers - as funded by TTI and the TTN foundation…given this is an expensive and constrained resource we need to make sure users are not abusing. Helium on the other hand ISNT FREE - you ‘pay’ for use and operation of devices by consuming HNT, as disproportionate amount of that payment goes to the entities behind the network, so in theory the more use the more they ‘earn’ hence no motivation to limit beyond legal limits - even if a potential selfish abuse of the airwaves… Helium GWs not only dl for actual network/application use they also add on beaconing/witnessing processes - not to facilitate traffic but rather as a another mechanism for generating ‘payments’. Again as simplex devices when beaconing the GW’s are not able to hear real traffic… :man_shrugging:

We can all use mappers and survey equipment - we just need to ensure we are responsible how we do so! (Hint FUP is per day - so if you want to map coverage for 1hr say to check and publish your local TTN Community networks coverage then there are ways and means (just stay inside legal limits cause :police_car: :judge: :slight_smile: ) - surveying/mapping is rarely a 24hr a day process and goal is to try and avoid having devices set up and just banging away 24/7 automatically killing the spectrum for all… :wink:

Note: TTNMapper started off as the original service, with Helium heatmapping being added 4-5 years later, Helium dont allow TTN Mapping - the initiator and controller of the system decided to extend…

That link looks to be broken

For TTN you need to look at the provided Integrations (Webhooks)…and follow the breadcrumbs e.g. as below:

Open the TTN Application where you have registered the device, click Integrations drop down menu, select Webhooks, find TTNMapper (alphabetic listing), and take it from there…

Thanks for clarification about fair-use policy.

In the case of my summer house, it is very well placed on a high point, so I really want to test long distance (over 15 km) communication. At present, my TTN gateway is outside on a wall of my house. But I might be interested in installing the TTN gateway on the hill, well above the 4G tower. So before investing in expensive batteries and solar panels I want to do field testing. This is why I purchased this equipment. I don’t plan to do 24x7 day testing and beacon all the time. So yes … I might break TTN fair-use, but this is for good reasons and very limited time (only a day). This is on the country side and I see only a few hundreds messages per day. So I will not break free-air and I know I have to act in a responsible way.

Thanks for TNT mapper integration.

I did try to use TNT mapper web-hook, but it does not work. I also need a Javascript Payload (I used the above script) and nothing gets transmitted.

If no one here is using this device, we might wait for clarification about the author, which claims this is open-source software and compatible with TTN.

What I probaby need to do is recompile from scratch and remove the Helium credentials and hard-code my own credentials in firmware. This is not a ready-to-use product for TTN which I understand.


And you know this how? Which LoRaWAN providers do you think your gateway hears?

Doesn’t really matter what Helium think & do, this is TTN, a free to you service that is shared by a community of users. And the legal authorities always have the last say on the rules, so whilst Helium, which users pay for, isn’t restricted by a Fair Use Policy, they still have to stick to the legal limits.

Apart from the likely error in your statement, this is the deal, live with it or use something else.

How is this relevant?

It is becoming clear that your breadth of understanding and knowledge on many aspects is likely to lead you in to many different sorts of difficulties.

So code the firmware, it’s just a Speed LoRa-E5 running LoRaMAC-node at the heart of it all, pretty routine stuff.

Second time you’ve said this. Adding libel to your posts won’t help you either - how do you now it will take weeks and given that you have only paid for the hardware, why should you expect any help from Disk91 who makes a valuable contribution to the practical knowledge of LoRaWAN I don’t know.

Take gateway to hill, plug in to battery pack, leave with friend, drive away 15km, run device, look at results.

I only drove my car at 100mph down the high street just to see if it would work OK officer, it’s all good, no one was hurt, I think.

The community does not support anyone that wishes to overtly breach the FUP for any duration what-so-ever.

It is not a good reason because you do not need to use this device to test it - a TTN Mapper based system would work equally well.

Only the LoRaWAN ones, you don’t know what other legitimate ISM traffic is going on, or indeed any LoRaWAN traffic that may be just out of range of your current gateway.

How will you know? What airtime calculator will you be using?

But you’re not planning to …

Third strike …

1 Like