Mode 11 cannot receive data from Arduino_LoRa_temp

[ktannady]

Hello i have successfully connected my gateway to my local chirpstack and TTN, i also can get my Rpi gateway to play ping pong with my end node (with mode 1). now that I change to mode 11 to connect to my chirpstack, i cannot get my data from the Arduino_LoRa_temp ( i can receive data if i set my gateway to mode 1). i have uncommented #WITH_AES and #define LORAWAN but still no success

Here is my config code on the Arduino //add 4-byte AppKey filtering - only for non-LoRaWAN mode //#define WITH_APPKEY //////////////////////////// //request an ack from gateway - only for non-LoRaWAN mode //#define WITH_ACK //////////////////////////// //if you are low on program memory, comment STRING_LIB to save about 2K

define STRING_LIB

//////////////////////////// //#define LOW_POWER //#define LOW_POWER_HIBERNATE //#define SHOW_LOW_POWER_CYCLE //////////////////////////// //Use LoRaWAN AES-like encryption

define WITH_AES

//////////////////////////// //Use our Lightweight Stream Cipher (LSC) algorithm //#define WITH_LSC //////////////////////////// //If you want to upload to LoRaWAN cloud without pure LoRaWAN format you have to provide a 4 bytes DevAddr and uncomment #define EXTDEVADDR //#define EXTDEVADDR //////////////////////////// //Use native LoRaWAN packet format to send to LoRaWAN gateway - beware it does not mean you device is a full LoRaWAN device

define LORAWAN

//////////////////////////// //this will enable a receive window after every transmission, uncomment it to also have LoRaWAN downlink //#define WITH_RCVW //////////////////////////// //when sending to a LoRaWAN gateway (e.g. running util_pkt_logger) but with no native LoRaWAN format //just to set the correct sync word. DO NOT use if LORAWAN is uncommented //#define USE_LORAWAN_SW //////////////////////////// //force 20dBm, use with caution, test ony //#define USE_20DBM ///////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////// // ADD HERE OTHER PLATFORMS THAT DO NOT SUPPORT EEPROM

if defined ARDUINO_SAM_DUE || defined _VARIANT_ARDUINO_DUEX || defined SAMD21G18A

undef WITH_EEPROM

endif

/////////////////////////////////////////////////////////////////// // ADD HERE OTHER PLATFORMS THAT DO NOT SUPPORT LOW POWER LIB

if defined ARDUINO_SAM_DUE || defined _VARIANT_ARDUINO_DUEX

undef LOW_POWER

endif

///////////////////////////////////////////////////////////////////

// IMPORTANT SETTINGS /////////////////////////////////////////////////////////////////// // please uncomment only 1 choice //

define ETSI_EUROPE_REGULATION

//#define FCC_US_REGULATION //#define SENEGAL_REGULATION ///////////////////////////////////////////////////////////////////

// IMPORTANT /////////////////////////////////////////////////////////////////// // please edit band_config.h to define the frequency band

include "band_config.h"

//////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////////////////////////////////////////////// // uncomment if your radio is an HopeRF RFM92W, HopeRF RFM95W, Modtronix inAir9B, NiceRF1276 // or you known from the circuit diagram that output use the PABOOST line instead of the RFO line

define PABOOST

///////////////////////////////////////////////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////// // CHANGE HERE THE NODE ADDRESS BETWEEN 2 AND 255 - NON LORAWAN uint8_t node_addr=2; //////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////// // CHANGE HERE THE DEFAULT LORA MODE

define LORAMODE 1

////////////////////////////////////////////////////////////////// `

Here is my output on the Arduino 15:31:36.987 -> LoRa temperature sensor, extended version 15:31:36.987 -> Arduino Pro Mini detected 15:31:36.987 -> ATmega328P detected 15:31:37.561 -> SX1276 detected, starting 15:31:37.595 -> SX1276 LF/HF calibration 15:31:37.832 -> ... 15:31:38.239 -> Set BW to 125kHz: state 0 15:31:38.274 -> Set SF to 12: state 0 15:31:38.274 -> Set frequency to 433.175MHz: state 0 15:31:38.478 -> Set sync word to 0x34: state 0 15:31:38.478 -> Using raw mode for native LoRaWAN Setting Power: state 0 15:31:38.579 -> Setting node addr: state 0 15:31:38.579 -> SX1272 successfully configured 15:31:39.089 -> Reading 264 15:31:39.191 -> Reading 242 15:31:39.258 -> Reading 228 15:31:39.360 -> Reading 216 15:31:39.461 -> Reading 204 15:31:39.562 -> Mean temp is 20.66 15:31:39.595 -> Sending !TC/22.50 15:31:39.595 -> Real payload size is 10 15:31:39.595 -> end-device uses native LoRaWAN packet format 15:31:39.595 -> !TC/22.50 15:31:39.595 -> plain payload hex 15:31:39.628 -> 5C 21 54 43 2F 32 32 2E 35 30 15:31:39.628 -> Encrypting 15:31:39.628 -> encrypted payload 15:31:39.628 -> 79 F8 50 C9 3B 02 32 D7 18 39 15:31:39.628 -> calculate MIC with NwkSKey 15:31:39.628 -> transmitted LoRaWAN-like packet: 15:31:39.662 -> MHDR[1] | DevAddr[4] | FCtrl[1] | FCnt[2] | FPort[1] | EncryptedPayload | MIC[4] 15:31:39.662 -> 40 4A 1F 01 26 00 00 00 01 79 F8 50 C9 3B 02 32 D7 18 39 F8 EC 41 8F 15:31:39.696 -> [base64 LoRaWAN HEADER+CIPHER+MIC]:QEofASYAAAABefhQyTsCMtcYOfjsQY8= 15:31:39.696 -> --> CS1 15:31:40.238 -> --> CAD 551 15:31:40.238 -> OK1 15:31:40.238 -> --> RSSI -127 15:31:41.731 -> End send: 7768 15:31:41.731 -> LoRa pkt size 23 15:31:41.731 -> LoRa pkt seq 0 15:31:41.765 -> LoRa Sent in 1489 15:31:41.765 -> LoRa Sent w/CAD in 2042 15:31:41.765 -> Packet sent, state 0 15:31:41.765 -> 0 15:31:41.765 -> Will send next value at 15:31:41.765 -> 607788

Here is the output on my rebooted Rpi

After 10 minutes

i have been stuck for days, thankyou.

[CongducPham]

Looks like it comes from a mismatch frequency. In mode 1, the default frequency in band 433 is 433.3 and in LoRaWAN mode it is 433.175. Your gw is on 433.3 while your device is on 433.175. Do you use the latest version of lora_gateway.cpp as normally the gateway should be in 433.175 if it is compiled with BAND433, or did you set the 433.3 freq right in the gateway_conf.json? Also do you use the quick lorawan configuration feature of the web interface on the gateway? It is safer in order to able to set all parameters.

regards,

[ktannady]

hello, i have tried to update as you do in your video, but i cannot run "sudo ./lora_gateway" anymore as it said that "lora_gateway command not found" so i don't try to update the gateway after that.

i tried to compile the lora_gateway.cpp to change the band but i couldn't because of some error (i forgot to screenshot it), so i change the band on the web interface to 433mhz.

i just update the gateway as you ask before, after that i cannot run the lora_gateway anymore, and i tried to compile and found this error

g++ -Wall -c "lora_gateway.cpp" (in directory: /home/pi/lora_gateway) lora_gateway.cpp: In function ‘void loop()’: lora_gateway.cpp:854:22: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=] PRINT_VALUE("%lu",rcv_time_ms); ^~~ ~~~~~ lora_gateway.cpp:214:42: note: in definition of macro ‘PRINT_CSTSTR’

define PRINT_CSTSTR(fmt,param) printf(fmt,param)

                                      ^~~

lora_gateway.cpp:854:10: note: in expansion of macro ‘PRINT_VALUE’ PRINT_VALUE("%lu",rcv_time_ms); ^~~ lora_gateway.cpp:908:23: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=] sprintf(print_buf, "^r%d,%d,%d,%lu\n", ^~~~~~ lora_gateway.cpp:912:5: (uint32_t)(optFQ*1000.0));

lora_gateway.cpp:917:23: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=]
    sprintf(print_buf, "^t%s*%lu\n", time_str, rcv_time_tmst);
                       ^~~~~~~~~~~~            ~~~~~~~~~~~~~
lora_gateway.cpp:985:14: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=]
       printf("^$Check for downlink requests %s*%lu\n", time_str, current_time_tmst);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            ~~~~~~~~~~~~~~~~~
lora_gateway.cpp:1004:15: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘ssize_t’ {aka ‘int’} [-Wformat=]
        printf("^$Read downlink: %lu\n", dl_line_size);
               ^~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~
lora_gateway.cpp:1118:21: warning: comparison of integer expressions of different signedness: ‘long int’ and ‘uint32_t’ {aka ‘unsigned int’} [-Wsign-compare]
        if (millis() > rcv_time_ms + rx_wait_delay/1000 - MARGIN_DNW) {
            ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lora_gateway.cpp:1237:16: warning: unused variable ‘downlink_message’ [-Wunused-variable]
        uint8_t downlink_message[256];
                ^~~~~~~~~~~~~~~~
lora_gateway.cpp:767:9: warning: unused variable ‘i’ [-Wunused-variable]
     int i=0, e;
         ^
lora_gateway.cpp: In function ‘int main(int, char**)’:
lora_gateway.cpp:1381:39: error: ‘optarg’ was not declared in this scope
            case 'a' : loraMode = atoi(optarg);
                                       ^~~~~~
lora_gateway.cpp:1381:39: note: suggested alternative:
In file included from /usr/include/arm-linux-gnueabihf/bits/getopt_posix.h:27,
                 from /usr/include/unistd.h:869,
                 from arduPi.h:320,
                 from SX1272.h:38,
                 from lora_gateway.cpp:197:
/usr/include/arm-linux-gnueabihf/bits/getopt_core.h:36:14: note:   ‘unistd::optarg’
 extern char *optarg;
              ^~~~~~
lora_gateway.cpp: In function ‘void loop()’:
lora_gateway.cpp:917:23: warning: ‘%s’ directive writing up to 99 bytes into a region of size 98 [-Wformat-overflow=]
    sprintf(print_buf, "^t%s*%lu\n", time_str, rcv_time_tmst);
                       ^~~~~~~~~~~~  ~~~~~~~~
lora_gateway.cpp:917:11: note: ‘sprintf’ output between 6 and 114 bytes into a destination of size 100
    sprintf(print_buf, "^t%s*%lu\n", time_str, rcv_time_tmst);
    ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from SX1272.h:38,
                 from lora_gateway.cpp:197:
arduPi.h: At global scope:
arduPi.h:250:12: warning: ‘REV’ defined but not used [-Wunused-variable]
 static int REV = 0;
            ^~~
Compilation failed.

im new to linux and LoRa, so i dont want to mess up with the code (the reason i dont update the gateway), i hope you can help me , thankyou 

regards,

[CongducPham]

In radio.makefile, add the option for band 433:

CFLAGS=-DPABOOST -DMAX_DBM=14 -DBAND433

check whether you need PABOOST or not

Then, you should use the scripts/basic_config_gw.sh script, just run:

cd scripts sudo ./basic_config.gw.sh

to setup and compile your gateway.

Read instructions on the github for updates, it is better to use the web interface.

regards,

[ktannady]

Hello, after run the basic config either from the bash or the web interface, i still cannot run my lora_gateway command.

Here is my radio.makefile as you suggest

Here is the output when i try the sudo ./basic_config.gw.sh

it seems like there are some error, what can i do to compile it to executeable? Thankyou regards,

[CongducPham]

If you have Buster version of Raspbian, then be sure in raspberry.makefile to have uncommented the following line:

CFLAGS+=-DGETOPT_ISSUE

[ktannady]

Hello, i have successfully run my ./lora_gateway now. I have still the same issues that my gateway cannot receive data from my arduino side.

Here is my gateway setting on my web interface.

Here is my arduino side

Here is the result on the gateway side

is there anyway i can see which frequency my gateway is currently running? regards,

[ktannady]

Update : I have successfully receive data on my gateway after a few tries. it seems like there is some hardware (loose cable) that stop them from communicating,

Thankyou for helping me sir, regards,

[CongducPham]

Your gateway is still running on 433.3 while your device is running on 433.175 which is default freq for LoRaWAN. To use default frequency on gateway for LoRaWAN, you have to leave the frequency configuration on the gateway to -1 and not to 433.3.

[ktannady]

alright, i have been successfully receive data from my arduino, i need to manually change the frequency to -1 in gateway_conf.json as the web interface doesnt have the option to change to -1.

Thankyou sir, regards,

[CongducPham]

You have to update the web interface as well. The latest version allows you to set freq to -1 in the ISM band option. Anyway, great to hear that it is working now.

[ktannady]

Hello sir, does the gateway can handle chirpstack downlink?

[CongducPham]

yes. please look at https://github.com/CongducPham/LowCostLoRaGw/blob/master/gw_full_latest/README-downlink.md

[ktannady]

Hello sir, after enqueue the downlink payload from my local chirpstack i cant seem to find the downlink.txt, is there anything that i missed out?

regards.

[CongducPham]

You have to make sure that everything is configured for lorawan with downlink, so better to use the "configure for LoRaWAN" quick button on the web admin interface.

Then, downlink.txt will be created when PULL DATA will be received from network server, after the downlink has been processed, the file is deleted.

You can check if the gateway receives the downlink messages by looking at the log file. Output similar to:

Check for downlink requests 2020-01-21T17:33:28.439246
Read downlink: 204
Downlink entry: {"txpk":{"imme":false,"rfch":0,"powe":14,"ant":0,"brd":0,"tmst":4156747970,"freq":868.1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","ipol":true,"size":25,"data":"YCQfBCYC9QAIAQF+eOi0BvnZlM6hkIt/wA=="}}
Process downlink request
LoRaWAN downlink request
Target RX1
Packet sent, state 0
-----------------------------------------------------

regards,

[ktannady]

Hello sir, is there anyway i can make the gateway generate a downlink, without the slave communicating first? i want to make the gateway send command via downlink every hour to the slave,

regards,

[CongducPham]

Hi, there is no such thing possible in so-called class A devices. What you ask for is for class B devices where peridic downlink can be programmed. LMIC has normally support for class B and ChirpStack Network Server has also this support. You might go for that and test how it works.

hope that helps