Dragino LG-01 connected but no packets

Has anyone ever successfully connected the Dragino LG-01 gateway to The Things Network and received traffic?

For the past 2 months I’ve been reading forums (similar question to this one), trying different packet forwarding firmware and altered End Node configurations, such as RX/TX Frequencies.

My gateway is connected to The Things Network however no packets ever are uploaded.

Notably, I can see via my admin panel of my Dragino, that it is receiving my end node packets, however the problem seems to lie with the actual forwarding to the Things Network.

Weirdly, out of the thousands of packets I’ve tried to send, I’ve had one successful which I noticed about 20 minutes after it occured and was never able to replicate another successfully forwarded packet.

I’ve read another question regarding a similar problem and tried to create the data folder but to no avail.

Is there any advice, or new firmware someone could direct me to?

Regards a frustrated maker, so close to project completion…

1 Like

Is the Dragino LG-01 a single channel Gateway ?

Yes it is!

You are telling my exact same story. I show connected. Tried creating 3 different gateways. I know the LG01-P is forwarding the packets to router.us. but I never see them at the gateway or the application. And I see strange RADIUS malformed packets. Whats that about?

Here is my issue. has some packet capture stuff.

1 Like

Glad you understand my frustration! It’s really halted my application progress.

I’m beginning to think something mightve change in The things Network back-end and the firmware we have been using e.g v004 might just not be up to scratch anymore.

you use a non compliant single channel gateway… So don’t expect everything to work the same as a full gateway on the Things Network.

As @BoRRoZ has said single channel gaterways are not TTN compliant.

You might expect the company selling the non-complaint Gateways to provide support …

Can you recommend a gateway you find personally flawless?

I agree this appears to be a Dragino firmware issue. Fortunately I can still return mine and considered trying the LG02 because it does transmit and receive and is different hardware. But still single channel. Or just build one with a pi, which I was trying to avoid.

But I am curious, if my node and my gateway are both configured single channel and my node is successfully sending the packets to TTN in the correct format, what difference does single channel make?

One thing I realized on the LG01-P, the specs are terrible. They expect a 60% frame loss on the lora side and I see less get through than that. Not sure I would recommend it to a friend. Not even as a learning tool.

one of the problems is that Dragino is selling these ‘lora kits’

price is attractive but… its not LoRaWAN compliant and they don’t tell you that.
Nice to study and experiment a bit with lora , but don’t use them on a LoRaWAN network.

1 Like

looks like you pointed out the one kit I own…

Appreciate the replies, will learn from my mistakes!

TTN provide the backend infrastructure and support that TTN needs to operate on a free to use basis. Its reasonable that it expects people to install compliant Gateways that are available for others in the community to use.

They just receive a small fraction of all LoRaWAN traffic a real gateway would receive. For someone close to you expecting a gateway not knowing it is single channel (and tuned to which frequency and data rate) that is confusing at least. Also, the software does not always support downlinks so OTAA is impossible and if downlink is supported timing is not always correct. (And LoRaWAN timing needs to be very strict)

All in all, a single channel gateway is not even a toy, it creates serious challenges for the users when just getting a node to run (within reach of a full gateway) is a challenge by itself.

I totally respect the concept of building a usable and fairly shared compliant network. I certainly hope to participate.

The concept is trying to learn without making a serious investment up front. I would really be heart broke if I had 3 times the investment and could not accomplish my objective. On this exercise I do not expect integrity, just working with functionality.

I have opened an issue with the vendor. Lets see what they have to say.

So even if I pick an 8 channel device I have to worry about the product reliability.

1 Like

For 99% percent of the 8 channel gateway there are no issues. Today I noticed Dragino has an 8 channel one as well, based on the over the top claims made by a local reseller I won’t be buying it (this gateway should outperform pro gateways by Kerlink according to their blurb, not something I buy into)

I trust you know where to solicit feedback once you are looking at a specific gateway. :wink:

Well, I considered all that has been shared. Thank you. I have learned a significant amount in just 2 weeks.

The fact that the LG01-P is single channel (which initially did not bother me but I know more now), only receive and will always only do ABP. And that their own spec says it will lose 60%.

I have chosen a different low cost attempt.
Basically a pre-assembled raspberry pi dyi.

Says Full LoRaWAN Stack support (version 1.0.2) hope that is current, recognize not ‘certified’

I figure this way I am not bound to a rom based solution and I may be able to bail myself out with this one. And at the end of the day I at least end up with another pi. :slight_smile:

When I consider the value of my time, am I really saving money fooling with the Dragino?

I will still let ya know what dragino say about the LG01. And if the new solution works.

You should be fine with that choice. LoRaWAN 1.1 support using TTN should work as well once it is implemented on the public infrastructure. Might require a software upgrade on the gateway but that should not be a problem.

If you put a single channel Gateway in an area close to a compliant multichannel Gateway would the service of existing node users (connecting to the multichannel Gateway) be affected ?

I am in the same situation, wanting to start to learn with a low cost solution.
However, I managed to make it work by using ABP instead of OTAA, and by not using

LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);
LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);
LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);
LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);
LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);
LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);
LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);
LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);
LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK, DR_FSK), BAND_MILLI);

but leaving the default (three channels) and disabling channels 1 and 2 (keeping only channel 0)