GithubHelp home page GithubHelp logo

[REOPENED]Configure AAEON AIOT-IP68 Gateway and Network Server/ LoRaWanPktFwdModule fails to start about iotedge-lorawan-starterkit HOT 14 CLOSED

azure avatar azure commented on May 30, 2024
[REOPENED]Configure AAEON AIOT-IP68 Gateway and Network Server/ LoRaWanPktFwdModule fails to start

from iotedge-lorawan-starterkit.

Comments (14)

gerfen avatar gerfen commented on May 30, 2024

I just noticed that I am not seeing a GPIO folder for pin 430. This seems incorrect to me.

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

After a complete reinstall of Ubuntu 16.04, I now have a /sys/class/gpio/gpio430/ folder but sadly the packet forwarder is still not starting.

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

I got this response back from AAEON support:

looks there is no problem to communicate with LoRa module through SPI interface.
Failed to start the concentrator is mostly network or LoRa cloud setting problem when you using OTAA(Over The Air Activation).

So it appears that I have all of the GPIO and SPIDEV are configured correctly? I'm at a loss for what is preventing the packet forwarder from starting.

from iotedge-lorawan-starterkit.

ronniesa avatar ronniesa commented on May 30, 2024

Hi Gerfen, it is a know issue due to a bug how we compile the pktfwrd that we have on the docker file on master that affect this gateway. It is corrected in the dev branch.

Wrong code: https://github.com/Azure/iotedge-lorawan-starterkit/blob/master/LoRaEngine/modules/LoRaWanPktFwdModule/Dockerfile.amd64

Right code: https://github.com/Azure/iotedge-lorawan-starterkit/blob/dev/LoRaEngine/modules/LoRaWanPktFwdModule/Dockerfile.amd64

Just copy the Dockerfile.amd64 from dev and rebuild and push the container.

Let us know if this fix the issue. We will publish a new release next week on master that include the fix

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

@ronniesa Thanks for the reply. I'm still having issues getting the packet forwarder started. I noticed some errors while the containers were being rebuilt:

Step 9/31 : RUN ./compile.sh
 ---> Running in d7866a6cfcfc
make: Entering directory '/lora_gateway'
make all -e -C libloragw
make[1]: Entering directory '/lora_gateway/libloragw'
*** Checking libloragw library configuration ***
#File initialization
# Release version
Release version   : 5.0.1
# Debug options
# end of file
*** Configuration seems ok ***
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_hal.c -o obj/loragw_hal.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_gps.c -o obj/loragw_gps.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_reg.c -o obj/loragw_reg.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_spi.native.c -o obj/loragw_spi.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_aux.c -o obj/loragw_aux.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_radio.c -o obj/loragw_radio.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_fpga.c -o obj/loragw_fpga.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/loragw_lbt.c -o obj/loragw_lbt.o
ar rcs libloragw.a obj/loragw_hal.o obj/loragw_gps.o obj/loragw_reg.o obj/loragw_spi.o obj/loragw_aux.o obj/loragw_radio.o obj/loragw_fpga.o obj/loragw_lbt.o
gcc -O2 -Wall -Wextra -std=c99 -Iinc -I. -L. tst/test_loragw_spi.c -o test_loragw_spi -lloragw -lrt
-lm
gcc -O2 -Wall -Wextra -std=c99 -Iinc -I. -L. tst/test_loragw_reg.c -o test_loragw_reg -lloragw -lrt
-lm
gcc -O2 -Wall -Wextra -std=c99 -Iinc -I. -L. tst/test_loragw_hal.c -o test_loragw_hal -lloragw -lrt
-lm
gcc -O2 -Wall -Wextra -std=c99 -Iinc -I. -L. tst/test_loragw_gps.c -o test_loragw_gps -lloragw -lrt
-lm
tst/test_loragw_gps.c: In function 'main':
tst/test_loragw_gps.c:201:59: warning: format '%d' expects argument of type 'int', but argument 2 has type 'ssize_t {aka long int}' [-Wformat=]
             printf("WARNING: [gps] read() returned value %d\n", nb_char);
                                                           ^
tst/test_loragw_gps.c:214:37: warning: comparison is always false due to limited range of data type
[-Wtype-limits]
             if (serial_buff[rd_idx] == LGW_GPS_UBX_SYNC_CHAR) {
                                     ^~
gcc -O2 -Wall -Wextra -std=c99 -Iinc -I. -L. tst/test_loragw_cal.c -o test_loragw_cal -lloragw -lrt
-lm
make[1]: Leaving directory '/lora_gateway/libloragw'
make all -e -C util_pkt_logger
make[1]: Entering directory '/lora_gateway/util_pkt_logger'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../libloragw/inc src/util_pkt_logger.c -o obj/util_pkt_logger.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/parson.c -o obj/parson.o
gcc -L../libloragw obj/util_pkt_logger.o obj/parson.o -o util_pkt_logger -lloragw -lrt -lm
make[1]: Leaving directory '/lora_gateway/util_pkt_logger'
make all -e -C util_spi_stress
make[1]: Entering directory '/lora_gateway/util_spi_stress'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../libloragw/inc src/util_spi_stress.c -o obj/util_spi_stress.o
gcc -L../libloragw obj/util_spi_stress.o -o util_spi_stress -lloragw -lrt -lm
make[1]: Leaving directory '/lora_gateway/util_spi_stress'
make all -e -C util_tx_test
make[1]: Entering directory '/lora_gateway/util_tx_test'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../libloragw/inc src/util_tx_test.c -o obj/util_tx_test.o
gcc -L../libloragw obj/util_tx_test.o -o util_tx_test -lloragw -lrt -lm
make[1]: Leaving directory '/lora_gateway/util_tx_test'
make all -e -C util_lbt_test
make[1]: Entering directory '/lora_gateway/util_lbt_test'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../libloragw/inc src/util_lbt_test.c -o obj/util_lbt_test.o
gcc -L../libloragw obj/util_lbt_test.o -o util_lbt_test -lloragw -lrt -lm
make[1]: Leaving directory '/lora_gateway/util_lbt_test'
make all -e -C util_tx_continuous
make[1]: Entering directory '/lora_gateway/util_tx_continuous'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../libloragw/inc src/util_tx_continuous.c -o obj/util_tx_continuous.o
gcc -L../libloragw obj/util_tx_continuous.o -o util_tx_continuous -lloragw -lrt -lm
make[1]: Leaving directory '/lora_gateway/util_tx_continuous'
make all -e -C util_spectral_scan
make[1]: Entering directory '/lora_gateway/util_spectral_scan'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -I inc -I../libloragw/inc src/util_spectral_scan.c -o obj/util_spectral_scan.o
gcc -L../libloragw obj/util_spectral_scan.o -lloragw -lrt -o util_spectral_scan
make[1]: Leaving directory '/lora_gateway/util_spectral_scan'
make: Leaving directory '/lora_gateway'
make all -e -C lora_pkt_fwd
make[1]: Entering directory '/packet_forwarder/lora_pkt_fwd'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -D VERSION_STRING="\"`cat ../VERSION`\"" -I../../lora_gateway/libloragw/inc src/lora_pkt_fwd.c -o obj/lora_pkt_fwd.o
src/lora_pkt_fwd.c: In function 'thread_up':
src/lora_pkt_fwd.c:1628:105: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' [-Wformat=]
                     j = snprintf((char *)(buff_up + buff_index), TX_BUFF_SIZE-buff_index, ",\"tmms\":%llu",

     ^
In file included from src/lora_pkt_fwd.c:50:0:
src/lora_pkt_fwd.c: In function 'thread_gps':
src/lora_pkt_fwd.c:2727:17: warning: format '%d' expects argument of type 'int', but argument 2 has
type 'ssize_t {aka long int}' [-Wformat=]
             MSG("WARNING: [gps] read() returned value %d\n", nb_char);
                 ^
inc/trace.h:27:29: note: in definition of macro 'MSG'
 #define MSG(args...) printf(args) /* message that is destined to the user */
                             ^~~~
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../../lora_gateway/libloragw/inc src/parson.c -o obj/parson.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../../lora_gateway/libloragw/inc src/base64.c -o obj/base64.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../../lora_gateway/libloragw/inc src/jitqueue.c -o obj/jitqueue.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. -I../../lora_gateway/libloragw/inc src/timersync.c -o obj/timersync.o
gcc -L../../lora_gateway/libloragw obj/lora_pkt_fwd.o obj/parson.o obj/base64.o obj/jitqueue.o obj/timersync.o -o lora_pkt_fwd -lloragw -lrt -lpthread -lm
make[1]: Leaving directory '/packet_forwarder/lora_pkt_fwd'
make all -e -C util_ack
make[1]: Entering directory '/packet_forwarder/util_ack'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/util_ack.c -o obj/util_ack.o
gcc obj/util_ack.o -o util_ack
make[1]: Leaving directory '/packet_forwarder/util_ack'
make all -e -C util_sink
make[1]: Entering directory '/packet_forwarder/util_sink'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/util_sink.c -o obj/util_sink.o
gcc obj/util_sink.o -o util_sink
make[1]: Leaving directory '/packet_forwarder/util_sink'
make all -e -C util_tx_test
make[1]: Entering directory '/packet_forwarder/util_tx_test'
mkdir -p obj
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/util_tx_test.c -o obj/util_tx_test.o
gcc -c -O2 -Wall -Wextra -std=c99 -Iinc -I. src/base64.c -o obj/base64.o
gcc obj/util_tx_test.o obj/base64.o -o util_tx_test
make[1]: Leaving directory '/packet_forwarder/util_tx_test'
Removing intermediate container d7866a6cfcfc
 ---> a43e3771e890

Is there some other step that I am missing? If it makes sense I can switch to the dev branch in the short term as I am several weeks away from deploying the gateway in the field.

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

I was able to get a clean container build but I'm still not able to get the packet forwarder to start. I forced the removal of the docker images via sudo docker rmi .... The LoRaWanPktFwdModule logs look the same as my original post.

Any other ideas?

from iotedge-lorawan-starterkit.

ronniesa avatar ronniesa commented on May 30, 2024

you can try to install the pktfrd outside the container directly from semtech and see if it starts.... so we can exclude docker or our issues.... there is an spi stress tool also in there the you can try to run to test that spi works

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

@ronniesa Thanks for the suggestion. @Mandur provided some assistance to me. We attempted to enable SPI on the gate way using the scripts here: https://github.com/dcleri/spi-enable. I think I should be seeing /dev/spidev0.0 and /dev/spidev0.1 after rebooting but I am not.

I did get a few warnings while executing ./install_hooks and ./acpi-add spidev*:

W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module i915
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.

I'm not sure if the last warning may be the root cause of the issue? Anyway, I am not able to run the spi stress tool successfully. I get the following error:

INFO: Starting LoRa concentrator SPI stress-test number 1
ERROR: lgw_connect() did not return SUCCESS

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

I was able to resolve this issue. I rebuilt the OS from scratch by following the steps in my original post and then applying the spi-enable scripts which I received from an AAEON engineer from Taiwan. To be honest have have not compared the scripts with those found here https://github.com/dcleri/spi-enable.

So I think this issue was resolved by applying the spi-enable scripts and using the corrected Dockerfile.amd64 docker file.

Thanks to @ronniesa and @Mandur for the help. You guys are fantastic to work with. :)

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

Closing...

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

I hate to reopen this issue but I'm having the same issue with starting the LoRaWanPktFwdModule on a brand new AAEON AOIT-IP68 gateway using the 1.0.2 release (Note: this is not the same production gateway I referenced in issue #221). I've compared the Dockerfile.amd64 with the version @ronniesa referenced and the "Right code" on Mar 21, 2019 -- the files are identical. I've applied the spi-enabled scripts and confirmed that the /dev/spidev1.0 and /dev/spidev1.1 files have been created. I also confirmed that the /sys/class/gpio/gpio430/ folder exists. Unfortunately the concentrator is failing to start. Here are the logs[1].

Any ideas what could be causing this issue for me? Please let me know if I should open a new issue to track this problem.

Thanks!

[1] LoRaWanPktFwdModule Logs

US region detected.
Accessing concentrator reset pin through GPIO430...
Using SPI dev 1 from environment variables
*** Beacon Packet Forwarder for Lora Gateway ***
Version: 4.0.1
*** Lora concentrator HAL library version info ***
Version: 5.0.1;
***
INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: lorawan_public 1, clksrc 1
INFO: no configuration for LBT
INFO: antenna_gain 0 dBi
INFO: Configuring TX LUT with 16 indexes
INFO: radio 0 enabled (type SX1257), center frequency 902700000, RSSI offset -166.000000, tx enabled 1, tx_notch_freq 0
INFO: radio 1 enabled (type SX1257), center frequency 903400000, RSSI offset -166.000000, tx enabled 0, tx_notch_freq 0
INFO: Lora multi-SF channel 0>  radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1>  radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2>  radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 3>  radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 4>  radio 1, IF -300000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 5>  radio 1, IF -100000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 6>  radio 1, IF 100000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 7>  radio 1, IF 300000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora std channel> radio 0, IF 300000 Hz, 500000 Hz bw, SF 8
INFO: FSK channel 8 disabled
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to AA555A0000000000
INFO: server hostname or IP address is configured to "192.168.0.17"
INFO: upstream port is configured to "1680"
INFO: downstream port is configured to "1680"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: found local configuration file local_conf.json, parsing it
INFO: redefined parameters will overwrite global parameters
INFO: local_conf.json does not contain a JSON object named SX1301_conf
INFO: local_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to AA555A0000000101
INFO: server hostname or IP address is configured to "172.17.0.1"
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
ERROR: [main] failed to start the concentrator

from iotedge-lorawan-starterkit.

Mandur avatar Mandur commented on May 30, 2024

@gerfen let me know if you still need help with this issue.

from iotedge-lorawan-starterkit.

ronniesa avatar ronniesa commented on May 30, 2024

@gerfen can we close this one as I believe is solved right?

from iotedge-lorawan-starterkit.

gerfen avatar gerfen commented on May 30, 2024

Still haven't gotten the gateway configure. I had to shelve working on getting the gateway configured due to to other pressing matters. I'll close the issue. Thanks for your patience. :)

from iotedge-lorawan-starterkit.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.