Dragino LG-01 connected but no packets

Gateways [obsolete] SCPF
17

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.

18

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.

19

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 ?

20

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)
LMIC_disableChannel(1);
LMIC_disableChannel(2);

21

That is an interesting question. When multiple gateways are in range of one another can a bad player ruin it for everybody? Will I latch on to your single channel at times.
Even if it is 8 channels, if it is not functioning correctly what is the impact.

Which leaves me to wonder, what kind of range can you really get from an indoor unit with a small antenna and I assume lower power? Am I causing people problems?

22

This is Edwin from Dragino. I am sorry that the LoRa IoT Kit cause these trouble in connecting to TTN. While you use end node to connect LoRaWAN via a Single Channel Gateway, there is indeed chanlleage because of hardware limitation.

The LoRa IoT Kit is provided as a low cost Kit to study LoRa technolog and LoRaWAN technology. We have improved the connection in the v2 version of the kit. Now it is able to use a modified LMIC version in Arduino to connect to LoRaWAN via OTAA and ABP. The latest insturction can be found here : http://www.dragino.com/downloads/index.php?dir=LoRa_IoT_Kit/v2-Kit/&file=Single%20Channel%20LoRa%20IoT%20Kit%20v2%20User%20Manual_v1.0.4.pdf
to see how to connect to LoRaWAN. And also the limitation for the connection.

The End Node in the instruction is Arduino with a modified LMIC library. If user use other end nodes, most properly can’t meet the requirement in the limitation: 1) Single Channel, 2) enlarge RXtimeout. For an demo on how other end nodes can connect, here is a video for reference:

So the Single Channel gateway LG01/LG02 are not recommend to use for LoRaWAN gateway.

Besides connect to LoRaWAN, LG01 and LG02 support LoRa connection with servers such MQTT, RestFul. The insturction can be found on the kit manual as well.

23

I personally do not have the kit and just have the gateway LG01-P. So it sounds like I should expect that it would still work with TTN. But I see mine connected, I see it forward packets to the internet in a packet capture but the gateway never sees the packet and my captures are showing malformed radius packets. So what is that all about?
Which is the same condition seen by Explorex.
What should we expect if we don’t have a v2.0 kit?

24

Sorry sent it to myself originally…

I personally do not have the kit and just have the gateway LG01-P. So it sounds like I should expect that it would still work with TTN. But I see mine connected, I see it forward packets to the internet in a packet capture but the gateway never sees the packet and my captures are showing malformed radius packets. So what is that all about?
Which is the same condition seen by Explorex.
What should we expect if we don’t have a v2.0 kit?

25

Can you show the malformed radius packets? Where do you see them?
The LoRaWAN packet is AES128 encrypt on HEX format, in the gateway side, you can’t parse it. If you check the data in ASCII form you will see malformed.

In your end node, can you set up it to transfer in single channel frequency? and set it to work in ABP mode?

26

I have single channel configured on the node. Using 914900000. I see the data on the LG01 sensor data view. I see the forwarded frames in wireshark on my switchport and I see the packet leave my router interface. tcpdump of packet and wireshark captures here
https://www.thethingsnetwork.org/forum/t/dragino-lg01-connected-but-no-gateway-data/27599/2

27

Is this a OTAA join packet?

28

The App is setup for ABP. I get those packets from the gateway even if there is no node running.
Not sure what I should check beyond this

image

29

possible these are from other nodes. If the node is not a LoRaWAN node. TTN won’t accecpt the packet so no traffci display.

are there any output in your end node serial? Can we check what frequency and DR it is sending?

30

My node is a
LoStik by Ronoth is an affordable, easy to use, LoRaWAN™ compatible device.

  • Supports Packet mode LoRa® (packet mode) or LoRaWAN™
  • Compatible with The Things Network
  • Based on the RN2903/R2483 by Microchip

I am using 914900000 and it appears the data rate is adaptive. Guessing since this gateway is receive only that possibly may not work.

I am in a very rural area and question if they are from some other node. I would need to watch for sensor data change when it happens to determine.

31

What is the output from RN2903. The actually Frequency and data rate it use? We only need to match one to see.

32

11:33:17.637 > radio set pwr 2
11:33:17.645 > ok
11:33:17.645 > radio set bw 125
11:33:17.652 > ok
11:33:17.652 > radio set rxbw 25
11:33:17.660 > ok
11:33:17.660 > radio set afcbw 41.7
11:33:17.669 > ok
11:33:17.669 > radio set freq 914900000
11:33:17.685 > ok
11:33:17.685 > radio set fdev 25000
11:33:17.698 > ok
11:33:17.698 > radio set bitrate 50000
11:33:17.712 > ok
11:33:17.712 > radio set prlen 8
11:33:17.720 > ok
11:33:17.720 > radio set bt 0.5
11:33:17.728 > ok
11:33:17.728 > radio set crc on
11:33:17.735 > ok
11:33:17.735 > radio set cr 4/5
11:33:17.743 > ok
11:33:17.744 > radio set mod lora
11:33:17.752 > ok
11:33:17.752 > radio set iqi off
11:33:17.760 > ok
11:33:17.760 > radio set wdt 15000
11:33:17.772 > ok
11:33:17.772 > radio set sf sf8
11:33:17.780 > ok
11:33:17.780 > radio set sync 34
11:33:17.788 > ok

11:34:22.548 > Uplink Sent
11:34:22.548 > radio tx 222
11:34:22.558 > ok
11:34:22.610 > radio_tx_ok
11:34:22.610 > Uplink Sent
11:34:22.610 > mac resume
11:34:22.616 > ok

and on my router egress

192.168.110.15.35988 > 13.66.213.36.1700: [udp sum ok] UDP, length 213

E…gg@.@…v…n…B.$…d…@A…{“rxpk”:[{“tmst”:2559122192,“time”:“2019-07-03T15:34:24.023237Z”,“chan”:7,“rfch”:0,“freq”:914900000,“stat”:1,“modu”:“LORA”,“datr”:“SF8BW125”,“codr”:“4/5”,“lsnr”:7.8,“rssi”:-78,“size”:2,“data”:“AiI=”}]}

33

And also, in regard to seeing someone elses data that may be true. I now have had a second packet show up on my gateway counter, no data. And when I looked at my gateway there was unkown data in there.

Which also gets back to what am I doing to other people if they hit me. Hope they got it…

34

We have not used RN2903 before. but while use the RN2483, the module can send a LoRa packet instead of LoRaWAN: see: http://wiki.dragino.com/index.php?title=Communicate_with_RN2483

If the device is sending a none LoRaWAN packet, gateway will still forward to LoRaWAN server but the server will ignore.

I didn’t see you use any join command in the RN2903. maybe you can try to use:
mac join abp

35

I looked at the doc, other than a different frequency (US) I changed my SF from 8 to 7. Same result Hid my keys…

14:06:24.589 > mac set devaddr ???0D
14:06:24.598 > ok
14:06:24.598 > mac set appskey ???DCCB
14:06:24.614 > ok
14:06:24.614 > mac set nwkskey ???B3E5
14:06:24.630 > ok
14:06:24.630 > mac save
14:06:25.352 > ok
14:06:26.150 > mac join abp
14:06:26.158 > ok
14:06:26.178 > accepted

Now this raises another question. Because if I set my LoraWAN keys and such when I upload I do not even see it on the LG01.
I am running 3 tests, first 2 are FCC and Radio. Those appear to work fine and those are the test I see the packets on.
My expectation is to at least see those packets at the gateway in TTN, I do not expect to see them at the device or app. So is this an incorrect expectation? Will the gateway not even count the packets or show the traffic?

36

With radio commands you are transmitting in plain LoRa mode, the data of those transmissions will not match the LoRaWAN packet format and if forwarded by the gateway (which should do so as those packets fail CRC tests) will be dropped by the back-end.

For a valid sequence you should:
RESET the rn2903 back to factory settings.
Disable all channels apart from the one(s) used by your gateway AND TTN (use mac commands for this)
Set the EUIs and keys.
Join ABP.
Use the mac transmit command.

Do not use any radio commands if you want the data to be shown in TTN console.