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?
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.
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?
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?
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?
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
Is this a OTAA join packet?
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
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?
My node is a
LoStik by Ronoth is an affordable, easy to use, LoRaWAN™ compatible device.
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.
What is the output from RN2903. The actually Frequency and data rate it use? We only need to match one to see.
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=”}]}
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…
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
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?
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.
Does this mean my current LG01-P does not have the ability to connect to TTN and I would need the new LG01-N to even have a chance?
Does anyone have a recommended mutli channel gateway, for myself a beginner to purchase instead?
Read the other forum messages, not only this thread. You are not the first one with this question.
LG01-N will have same situation of LG01-P when working with your end node. When you set the RN2903 in ABP mode. Can you see what frequency it transfer?