Lolin32 ESP + OLG-02 Gateway Downlink Not Received

Hi there,

Currently I’m working on the setup using Lolin32 using RFM95 HopeRF communicating with the OLG-02 Dragino. The code I’m using is basically TTN-ABP code from Arduino-LMIC Library. I only change the pinmap, input the FILLMEIN section, and the frequency setting at the project config file. Things I’ve done this far:

  1. Adjusting LMIC_setClockError
  2. Adjusting the distance between gateway and the node
  3. Adjusting the Rx2 window to SF7 to adjust with the gateway TX window, and make sure either timing received by the gateway can be received by the node
  4. Updating the gateway firmware to the latest version

RXTX~ (RXPKT): [up] {“rxpk”:[{“time”:“2011-12-31T17:22:39.685198Z”,“tmst”:2561550987,“chan”:0,“rfch”:1, “freq”:923.200000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:8 .0,“rssi”:-92,“size”:26,“data”:“QA8YBCaAAAAB1V59GB7xuSnChmheVbqX/7U=”}]}
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]:
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: RXTX~ (TXPKT): [down] { “txpk”:{“imme”:false,“tmst”:2562550987,“freq”:923.2,“rfch”:0,“powe”:14,“modu”:“L ORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:24,“ncrc”:true,“data”:“oA 8YBCYAIQMBeykk2dDHz2V/xhSW//6S”}}
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:219:jit_enqu eue(): Current concentrator time is 2562176078, pkt_type=0
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:196:jit_sort _queue(): sorting queue in ascending order packet timestamp - queue size:1
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:198:jit_sort _queue(): sorting queue done - swapped:0
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:531:jit_prin t_queue(): INFO: [jit] queue contains 1 packets:
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:532:jit_prin t_queue(): INFO: [jit] queue contains 0 beacons:
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:538:jit_prin t_queue(): - node[0]: count_us=2562550987 - type=0
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:397:jit_enqu eue(): enqueued packet with count_us=2562550987 (size=24 bytes, toa=61000 us, ty pe=0)
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:512:jit_peek (): peek packet with count_us=2562550987 at index 0
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:527:jit_prin t_queue(): INFO: [jit] queue is empty
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: jitqueue.c:441:jit_dequ eue(): dequeued packet with count_us=2562550987 from index 0
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]:
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: INFO~ Transmit at SF7BW 125 on 923.200000.
Sun Jan 1 00:22:40 2012 daemon.info lg02_pkt_fwd[4365]: INFO~ Donwlink done: co unt_us=2562550987

9881: TXMODE, freq=923200000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
75247: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 4
75880: RXMODE_SINGLE, freq=923200000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 76919 rxtime: 75872 entry-rxtime: 1047 now-entry: 5 rxtime-txend: 62126
137497: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
138129: RXMODE_SINGLE, freq=923200000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 139681 rxtime: 138122 entry-rxtime: 1559 now-entry: 5 rxtime-txend: 124376
139699: processRx2DnData txrxFlags 0x2 --> 00
139760: processDnData_norx txrxFlags 00 --> 20
140020: EV_TXCOMPLETE (includes waiting for RX windows)

TTN Console

I’m looking forward to hearing any more suggestions :smiley:

Note that Dragino do not recommend the LG-02 for connection to TTN, from their own product page;

“For Private LoRa Protocol, Not recommend for LoRaWAN use.”

1 Like

Yes, I am actually very aware of this. OLG-02 itself is a dual channel gateway and I reckon if the TX RX frequrency for both channels are configured properly, it should still be able to communicate properly, no?

…and you are also aware that using a single/dual packet forwarder engine such as this vs a full LoRaWAN compliant 8 channel (minimum) gateway on TTN potentially disrupts the use of TTN for other users who arent configuring their nodes specifically to work with your GW’s fixed/limited channel offering, causing confusion, apparent mis-operation, lost packets, delayed/in effective joins or confirmed packets/downlinks etc. costing them time effort and money?! Big hint as called out on other threads such devices are not recomeneded and are considered deprecated within the community… but still it might work for you and you want to use it right?! :wink: (Sorry if that sounds brutal/sacrcastic - british humour :slight_smile: - but have been burnt by these before costing me real money and have just had one pop up close to some deployed GW’s in one community and we are seeing impact :frowning: ) Pls use on a private network if you must…

1 Like

Unfortunately, what you are saying is true :slight_smile: and I completely agree with you. However, the circumstances here in our region fortunately, there hasn’t been any LoRaWAN gateway set-up around our area and this work we do now is used for a pilot project that act as our private network :smiley: and decides for future upgrade for full compliance with LoRaWAN standard. I’m though still working to make this work, if you have any suggestions for me to tweak or work on would probably be very helpful and appreciated :smiley:

We had a single channel one locally pop up… Absolute pain with our nodes

The problem with your setup is that it is making your life more difficult because you are using a ‘gateway’ which is not suited for the task. In stead of having to debug just the node side, you now have two unknowns which need debugging.
In principle it should work, however if it doesn’t there is a lot that might cause the issues and it is hard to debug.

Looking at the logging the response should be in the RX1 window at the frequency the module is listening. However timing could be the issue, is the LG02 transmitting at the right moment? Is the node listing at that time? There is no easy way to debug this.