Lora packets from Dragino Lora Shield to LG01 Gateway

ChirpStack Network Server
1

Hi there,

I built a lorawan system by installing chirpstack architecture with a Lora shield from Dragino with Arduino mega and a lora gateway Lg01. I built a Lmic library for sending packets with Otaa activation method. The system was working fine and suddenly the device unable to Join to the Network server or The gateway does not receive any packets !!
Ihave attached a log read from Network server

chirp network server
chirp network server1920×1080 567 KB

I have a problem with packets ! somtimes the gateway received the packets and sometimes the packets got lost.
Although I donwloaded a lmic library from Dragino and I change the frequency plan for europe 868.1 Mhz to match my lora shield. The gateway is single channel and works on 868.1 MHZ

lora gateway
lora gateway1357×695 49.5 KB

anyone can explain to me what is going on over here ?
thanx in advance
regards
Mohamad

here I attcahed pic from serial monitor. the device tries to join network

00:06:46.922 -> ######### Smart Plant from THM ####### COUNT=1    ###########
00:06:46.991 -> The temperature and humidity:
00:06:47.025 -> [24.00℃,59.00%]
00:06:47.060 -> moisture S1 is: 31
00:06:47.060 -> moisture S2 is: 41
00:06:47.094 -> moisture S3 is: 29
00:06:47.094 ->  I Am Dry pls Water!!
00:06:47.129 ->  Pump is ON 
00:06:53.576 -> Britghtness is : 50 -Bright : 
00:06:53.610 -> 1257644: engineUpdate, opmode=0x8
00:06:53.644 -> Packet queued
00:06:58.587 -> 1571170: EV_JOINING
00:06:58.621 -> 1571199: engineUpdate, opmode=0xc
00:06:58.656 -> 1571539: TXMODE, freq=868300000, len=23, SF=7, BW=125, CR=4/5, IH=0
00:07:13.653 -> 2509151: RXMODE_SINGLE, freq=868300000, SF=7, BW=125, CR=4/5, IH=0, rxsyms=255
00:07:23.686 -> 3134204: JaccRX1, dataLen=0
00:07:28.681 -> 3446784: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0, rxsyms=255
00:07:43.709 -> 4384346: JaccRX2, dataLen=0
00:07:48.716 -> 4696890: engineUpdate, opmode=0xc
00:08:08.701 -> 5946964: engineUpdate, opmode=0xc
00:08:08.736 -> 5947304: TXMODE, freq=868500000, len=23, SF=7, BW=125, CR=4/5, IH=0
00:08:23.736 -> 6884848: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0, rxsyms=255
00:08:33.774 -> 7509901: JaccRX1, dataLen=0
00:08:38.749 -> 7822481: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0, rxsyms=255
00:08:53.760 -> 8760042: JaccRX2, dataLen=0
00:08:58.790 -> 9072586: engineUpdate, opmode=0xc
00:09:23.797 -> 10635169: engineUpdate, opmode=0xc
00:09:23.831 -> 10635510: TXMODE, freq=868100000, len=23, SF=8, BW=125, CR=4/5, IH=0
00:09:38.829 -> 11573119: RXMODE_SINGLE, freq=868100000, SF=8, BW=125, CR=4/5, IH=0, rxsyms=255
00:09:48.861 -> 12198173: JaccRX1, dataLen=0
00:09:53.834 -> 12510754: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0, rxsyms=255
00:10:08.865 -> 13448319: JaccRX2, dataLen=0
00:10:13.875 -> 13760864: engineUpdate, opmode=0xc
00:11:28.875 -> 18448544: engineUpdate, opmode=0xc
00:11:28.909 -> 18448886: TXMODE, freq=868300000, len=23, SF=8, BW=125, CR=4/5, IH=0
00:11:43.914 -> 19386494: RXMODE_SINGLE, freq=868300000, SF=8, BW=125, CR=4/5, IH=0, rxsyms=255
00:11:53.939 -> 20011549: JaccRX1, dataLen=0
00:11:58.935 -> 20324129: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0, rxsyms=255
00:12:13.944 -> 21261694: JaccRX2, dataLen=0
00:12:18.939 -> 21574239: engineUpdate, opmode=0xc
00:13:28.976 -> 25949410: engineUpdate, opmode=0xc
00:13:29.010 -> 25949752: TXMODE, freq=868500000, len=23, SF=9, BW=125, CR=4/5, IH=0
00:13:44.009 -> 26887360: RXMODE_SINGLE, freq=868500000, SF=9, BW=125, CR=4/5, IH=0, rxsyms=255
00:13:54.019 -> 27512414: JaccRX1, dataLen=0
00:13:59.030 -> 27824995: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0, rxsyms=255
00:14:14.042 -> 28762560: JaccRX2, dataLen=0
00:14:19.046 -> 29075188: engineUpdate, opmode=0xc
00:17:09.059 -> 39700548: engineUpdate, opmode=0xc
00:17:09.093 -> 39700889: TXMODE, freq=868100000, len=23, SF=9, BW=125, CR=4/5, IH=0
00:17:24.107 -> 40638498: RXMODE_SINGLE, freq=868100000, SF=9, BW=125, CR=4/5, IH=0, rxsyms=255
00:17:34.105 -> 41263554: JaccRX1, dataLen=0
00:17:39.111 -> 41576134: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0, rxsyms=255
00:17:54.127 -> 42513698: JaccRX2, dataLen=0
00:17:59.157 -> 42826244: engineUpdate, opmode=0xc
00:20:54.165 -> 53764112: engineUpdate, opmode=0xc
00:20:54.200 -> 53764454: TXMODE, freq=868300000, len=23, SF=10, BW=125, CR=4/5, IH=0
00:21:09.208 -> 54702000: RXMODE_SINGLE, freq=868300000, SF=10, BW=125, CR=4/5, IH=0, rxsyms=255
00:21:19.234 -> 55327056: JaccRX1, dataLen=0
00:21:24.217 -> 55639636: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0, rxsyms=255
00:21:39.237 -> 56577200: JaccRX2, dataLen=0
00:21:44.244 -> 56889745: engineUpdate, opmode=0xc
2

the dragino you use is 1 channel, so you have to use abp.

3

hi @Thiago_Campos ,
thank you for your reply. I think there is no problem with Otta with single channel gateway I tested my system with otta and works fine.
I configured config file again and lora node works on 868.1 MHZ with SF7 to enable LG01 that recieve on this parameters.

application server22
application server221920×1080 552 KB

chirp gui
chirp gui1598×716 28.9 KB

I have configured lora shield to send only on one frrequency 868.1 MHZ for F1-5.

lorabase
lorabase987×746 42.9 KB

config file inside lora
config file inside lora1437×781 38.2 KB

Now, the problem the end-node not able to join the network server as you can see
it tries to join but there is no response from the Netwokr Server
in the attached photos:

application server
application server1920×1080 544 KB

here as you can see there is no EV_JOINED it still waits an answer from NS !
serial from end nodes
serial from end nodes1920×1080 210 KB

chstack-network server
chstack-network server1920×1080 562 KB

gateway log LG01
gateway log LG011920×1080 279 KB

4

Single channel gateways are not lorawan compliant. I know it’s a very annoying answer, and it means your gateways need a proper concentrator, and therefore are more expensive, but it is just reality. Lorawan is a great protocol, but the gateways aren’t cheap. Believe me, I have received that answer in the past myself. I didn’t look in too much detail at your setup, but the downlinks (and therefore joinAccept) are sent at a different frequency from the uplinks, so if your gateway doesn’t support multiple channels, it may not be able to send them. Check https://lora-alliance.org/wp-content/uploads/2020/11/RP_2-1.0.2.pdf#page=25 for the information on channels.

So what I normally do to debug is:

  1. check the live packet viewer in chirpstack for the gateway if you see the joinRequest coming in
  2. Do you see a joinAccept coming back? If not, then the network server isn’t accepting the join request. In case of abp, it could be the frameCount that doesn’t match (which is why you shouldn’t use abp). It could also be a mismatch in the keys between the chirpstack application server and device.
  3. Check with some kind of rf analyzer to see if any data is being sent by the gateway. That will also show you what frequency it is being sent at, and figure out why your sensor isn’t receiving it. (I like the RF explorer ones: https://www.seeedstudio.com/RF-Explorer-WSUB1G-PLUS-Slim-p-4163.html)

But expect to get a lot of answers frm people that “single channel gateways are not lorawan compliant” and run into a lot of limitations. If you want to save the money of buying a gateway, chances are you are a tinkerer that wants something cheap to setup with 1 gateway and just a few nodes. In that case you might be better off just using plain lora instead of lorawan. Lorawan really is meant for large networks with many gateways and many nodes.

1 Like
5

Hi @dolfandringa ,
thanks a lot for your informative answer. Actually I am working on a project at the University and they gave me this bad single channel gateway with other lora shields ! I should build an automated green house using this system Including ( some environment sensors).

do you have any recommnedations to go through this project because I must finish THIS MONTH !!

I have tested the system with previously with otaa and works fine for a while without any problem. I think dragino enlarges the receiving window period to get a join accept. I also modified a little have tiny modified sketch in arduino ide to work in limited condition by forcing lora shield work on one freq 868.1 mhz, but now there is an issue for receiving a join-accept from NS .
currently I have tested ABP actviation and works fine, but it takes 4-5 minutes t join the NS and the time intervlal in sketch set to 30 sec.

AS GUI UP messages from ABP
AS GUI UP messages from ABP1532×817 40.3 KB

eventually I need to see my sensors data online with GUI using this system :frowning: I hope it could be possible, cuz I shifted to chirpstrack from TTN to build a private lorawan network ( chirpstack)

do you mean radiohead between two lora nodes ?

Regards
Moshawa

6

Lol, uni project can be like that. I feel for you :slight_smile: LoRa!=LoRaWAN. The difference is similar to saying 802.11 vs WiFi, one is the physical link taking care of the RF signal, the other the network layer (roughly), taking care of addresses, encryption, etc.

If you don’t need a network, but just a few point-to-point connections (still possible with 1 gateway and like 4 or 5 sensors as long as you make sure they don’t all send at the same time), then LoRa could be enough. But it takes more time to setup and debug since and stuff, since you’re doing bare-bones rf links (similar to what you can do with RadioHead and an nrf24L01 for instance, which also !=wifi). There are multiple ways to implement Lora natively. I am not sure if RadioHead supports Lora specifically. I have used Congduch Pham’s low cost lora gw stuff before, which includes the SX1272 library, which can run on an arduino. Not very clearly written code, but it worked for me at the time using a single channel gateway. But that is probably going to be quite a bit of work too to get setup.

So for the OTAA/ABP stuff, I have never tried setting it up with chirpstack on a single channel gateway. But I am guessing your sensor or your gateway are trying different frequencies until they find one that works for both. Check the downlink and upink frequency settings both. For OTAA to work, you need to be able to send downlink messages back to the sensor, which generally get sent on a different frequency and different data rate (usually 500khz bandwidth). So with a single channel gateway that could be an issue. With ABP that is not necessary, so should be easier to setup. But then make sure to also turn off frame counter validation (but realize that disabling it is a serious security risk). Else the gateway will reject all packets after a sensor reboot if you don’t store the frame counter in EEPROM/flash or something. Also make sure Adaptive Data Rate is disabled, since that also requires downlink messages back to the sensor (to negotiate the frequency, data rate and rx power). But any issues in this area are very hard to diagnoze without some kind of RF analyzer (like the RF explorers or some type of SDR) that can show you that one of the devices is actually sending, and at what frequency and bandwidth.
Sorry I don’t have a clear answer (also not enough time to debug your issue in depth), but I hope this helps.

Cheers,

Dolf.