LIG16 troubleshooting

Sure thing. I captured the traffic on my router with tcpdump filter ‘host and port 1700’. Looking at the capture in Wireshark with the built-in LoRaWAN decoder shows a lot of Malformed packets (one pair every ~5 seconds) and a join request(?) every ~30 seconds. The join request contains the same status report json as seen in the log.

The PCAP is available here if you want to have a look at it yourself

That shows that your pull data packets are being acked, but your stats ones are not.

You don’t have any receive packet reports in that pcap

It is interesting that the stats packets are coming form a different UDP source port than the pull acks; however I check on one of my gateways with an SX1301 and that seems to be the case for me, too, so I guess that’s not it.

The “malformed packets” are probably something like wireshark trying to interpret the traffic as something it isn’t - I had to turn off RADIUS and SKYPE. What should have worked was turning off everything and turning on only UDP, but for some reason that wasn’t parsing the UDP frames to payload data.

I’m currently having problems getting my node connected, but I don’t know where the problem is as I got it working before (same node, same gateway).

I have set Wireshark to decode everything on port 1700 UDP as LoRaWAN and the Protocol field was always set to LoRaWAN, so not sure whats going wrong here.

I’m not sure it understands the Semtech UDP and JSON in which the LoRAWAN traffic would be wrapped - but even if it did understand it, it couldn’t decode traffic until some actually exists.

Don’t worry about decoding LoRaWAN yet, worry about capturing raw uplinks as UDP packets, and getting those to show up in the TTN console.

Your previous PCAP didn’t have any radio signals in it at all, just stats messages indicating time periods in which no radio traffic was received; the stats messages weren’t acked by TTN, but that’s an independent problem from the gateway not receiving anything to begin with.

I’ve also just received a LIG16 and had the same problems. Neither TTN v2 or v3 were working.
After updating the firmware (using the latest TESTING one, “lgw-5.4.1613373757”) I was able to get it connected to v2, but still no success with v3 (although I think I have to try that again…)

What I also did was to set the email address on the LoraWan page to one that’s as short as possible. I had the impression, that the packets sent to the server (the “stat:” packets) got somehow truncated. This might be just a red hering, since I didn’t validate if the packets are really truncated, or if it was the tcpdump dissector that just truncated the output.

Nice find! Can confirm that my gateway now shows as online in the console for TTNv2.
A manually compiled forwarder (from https://github.com/Lora-net/sx1302_hal) seems to work just as well once i disabled the temperature reporting.

Now to get a node working … My node was stuck at US915 (instead of EU868), works fine now and I should have RTFM before.

I just saw this gateway; how is it holding up for you? Are you able to provide details on what typical resource utilization is (something like free -h and or what a quick glance at top shows)?

If one was comparing this to the RAK7246, what would your thoughts be?

Did you read through the existing explanations of difficulty in the thread?

For a box just trying to be a packet forwarder, that’s unlikely to be very meaningful, it’s not a high-memory or dynamic-allocation demand and very little of the software is original and likely to have memory leaks.

If one was comparing this to the RAK7246, what would your thoughts be?

Apples vs oranges.

The RAK7246 uses a pi reliant on an SD card, and the low end of an early generation power hungry concentrator chip. The LG16 more wisely uses a NOR flash and a recent generation low power concentrator chip drawing far less power even when running twice the decoder instances.

But the 7246 is a mature product that works with TTN out of the box and permits software to be rebuilt on it, while updating the LG16 requires getting the right cross compiler and likely patching around some minimal C library issues.

For a first gateway to operate from an office or lab, the RAK7246 could have appeal, for something to qualify for field deloypment, the LG16 is vastly superior.

But ultimately, neither is really “right” - the LG16’s OpenWrt base is the right idea, but the board is missing some key details of system management, power, extensibility and choice of the best mobile data modem to use for backhaul in a given installation.

This is why I’m asking, to see if there have been any significant changes, I’m leary of Dragon.

That is a very good point, I hadn’t thought of the flash longevity.

I’m assuming this is referencing the convenience of compiling on the device? Leading into why I asked about system utilization, is that I have been going with my own OpenWRT builds for my routers lately, and was trying to figure out what all I could compile in for the LIG16 (Possibly an OpenVPN or Wireguard client for remote management, etc.).

I’m leary of anything I can’t rebuild from source. This you can

’m assuming this is referencing the convenience of compiling on the device? Leading into why I asked about system utilization, is that I have been going with my own OpenWRT builds for my routers lately, and was trying to figure out what all I could compile in for the LIG16 (Possibly an OpenVPN or Wireguard client for remote management, etc.).

Again this reflects not really understanding how lightweight a packet forwarder is as a task.

Have you compared the amount of RAM on the dragino to a typical router, especially in the context of how little traffic it has to handle?

My ‘weakest’ router currently has 128MB of ram and 32MB of flash, and claims to have 72MB RAM available and 18MB of flash free. With that said, I’ve taken to leaning towards a larger build and am working on a mostly common ‘extras’ group of packages that I test on this one so I don’t crash my network first. I include a bunch of unnecessary stuff such as fish, mosh, tmux, and OpenSSL instead of MbedTLS, etc.

Essentially, trying to figure out if I’d get buyers remorse.

Are you trying to use it as a LoRaWan gateway or as your Internet router?

Gateway, but I’m contemplating using it as a third device for a wifi mesh network that I’ve been meaning to get around to, and being based on OpenWRT I could potentially configure it to be mostly similar (although, it does look like I would need to do a separate config for it if I used my current one), do you know how much of the installed 16MB is used with the factory build?

do you know how much of the installed 16MB is used with the factory build?

Have you looked at the size of the download image?

If you’re concerned about the Dragino you can also get yourself a comparable late generation radio in the form of the RAK2287 card and host it on your own choice of SPI-capable OpenWrt platform.

I did not think to look at the size of a built binary. I am doing that now :wink:

Both are good points, thank you.

*Future self, the Dragino prebuilt binary for the current release is 9.9MB

If you just want to use the LIG16 as a LoRaWAN packet forwarder you have to update it to a current firmware release (I’m running Dragino-v2 lgw-5.4.1614755572) and you’re good to go. No need to compile or patch anything yourself.
I can’t compare it to any other gateway or give you many real-world measurements as it’s my only gatewaay so far.

I wanted to do some things differently than inteded by Dragino and am currently running my LIG16 with most of the services disabled. The only reasons why I manually compiled a packet forwarder was initially to see if it fixed anything (it didn’t) and now mostly because I can.

Some stats from my gateway (with pretty much every service disabled):

root@ttngw01:~# free
             total       used       free     shared    buffers     cached
Mem:         60192      31344      28848        676       3948      11328
-/+ buffers/cache:      16068      44124
Swap:            0          0          0
root@ttngw01:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 8.5M      8.5M         0 100% /rom
tmpfs                    29.4M    676.0K     28.7M   2% /tmp
/dev/mtdblock4            5.8M    740.0K      5.0M  13% /overlay
overlayfs:/overlay        5.8M    740.0K      5.0M  13% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@ttngw01:~# uptime
 18:32:45 up 14 days, 50 min,  load average: 0.07, 0.12, 0.09

Power draw (using a POE adapter) as reported by my switch is aroung 1.6W

Since a few days I also own a LIG16. Installed the newest firmware and had no problems to connect it to TTN V2. The BootLog is filled up with many USB-errors although no USB-device is connected.
The DevAddr-filter does not seem to work.
It seems that the firmware is still under development.
Power-requirement: DC 1.02W to 1.3W measured without power-supply, less than half of the LPS8.
Compared to the LPS8 until now I recognized no huge difference, the sensitivity seems to be a little bit better.

Hi @wolfp . I was thinking about getting the lig16. What are your experiences after a few months use? And what kind of range do you have outdoors?

By the way: the lig16 is out of stock everywhere, so not sure what is going on there…

In the meantime I connected the Dragino LIG16 to TTS CE (TTN V3) without any problems. In the firmware are still a few (minor) bugs but these don’t influence the function as a gateway.
The coverage you can achieve is independent of the gateway you use - the antenna and it’s position is much more important. There are some threads in this forum about that. I don’t want to break distance-records. I use a selective antenna from Horizon on the roof.
Imho we have a shortage of semiconductors and other parts in the moment. This maybe the reason why the gateways are on backorder everywhere.

1 Like

There is a new firmware downloadable at Dragino. It removes some of the bugs.
The Dragino LIG16 seems to be available soon. But its price was increased by 50,00€ (166,00€ inkl. VAT in DE)!