search

lorabasics / basicstation

LoRa Basics™ Station - The LoRaWAN Gateway Software
https://doc.sm.tc/station
Other
340 stars 178 forks source link

Seeed WM1302 (SX1302) fails to connect, start #172

Open md4k9 opened 1 year ago

md4k9 commented 1 year ago

I'm having difficulty getting my Seeed WM1302 (based on SX1302) SPI concentrator to start. It is mounted in the Seeed WM1302 Raspberry Pi HAT on a Raspberry Pi 4 (64-bit) running Raspberry Pi OS Lite (64-bit). The first error I see is "[HAL:ERRO] [lgw_start:742] FAIL TO CONNECT BOARD".

Why would it be failing to connect to the board? Am I correct in compiling this with "platform=rpi" and not "platform=corecell"?

In reference to issue #171 , I was able to get it to compile using your suggestion, but am now running into this issue.

Thank you.


2022-10-04 03:33:59.894 [TCE:VERB] Connecting to MUXS...
2022-10-04 03:34:00.974 [TCE:VERB] Connected to MUXS.
2022-10-04 03:34:00.976 [S2E:WARN] Unknown field in router_config - ignored: regionid (0xE6FFB211)
2022-10-04 03:34:00.976 [S2E:WARN] Unknown field in router_config - ignored: config (0xF7A3E35F)
2022-10-04 03:34:00.976 [S2E:WARN] Unknown field in router_config - ignored: protocol (0xFD309030)
2022-10-04 03:34:00.909 [RAL:INFO] Lora gateway library version: Version: 5.0.1;
2022-10-04 03:34:00.911 [RAL:INFO] [LGW lgw1] clksrc=1 lorawan_public=1
2022-10-04 03:34:00.911 [RAL:INFO]  RX/TX RF0:    902.7MHz rssi_offset=-166.0 type=2 tx_notch_freq=0
2022-10-04 03:34:00.911 [RAL:INFO]  RX    RF1:    903.5MHz rssi_offset=-166.0 type=2 tx_notch_freq=0
2022-10-04 03:34:00.911 [RAL:INFO]  [mSF]   0:    902.3MHz rf=0 freq=-400.0 datarate=126
2022-10-04 03:34:00.911 [RAL:INFO]  [mSF]   1:    902.5MHz rf=0 freq=-200.0 datarate=126
2022-10-04 03:34:00.911 [RAL:INFO]  [mSF]   2:    902.7MHz rf=0 freq=  +0.0 datarate=126
2022-10-04 03:34:00.912 [RAL:INFO]  [mSF]   3:    902.9MHz rf=0 freq=+200.0 datarate=126
2022-10-04 03:34:00.912 [RAL:INFO]  [mSF]   4:    903.1MHz rf=0 freq=+400.0 datarate=126
2022-10-04 03:34:00.912 [RAL:INFO]  [mSF]   5:    903.3MHz rf=1 freq=-200.0 datarate=126
2022-10-04 03:34:00.912 [RAL:INFO]  [mSF]   6:    903.5MHz rf=1 freq=  +0.0 datarate=126
2022-10-04 03:34:00.912 [RAL:INFO]  [mSF]   7:    903.7MHz rf=1 freq=+200.0 datarate=126
2022-10-04 03:34:00.912 [RAL:INFO]  [STD]   8:    903.0MHz rf=0 freq=+300.0 datarate=4 bw=1 
2022-10-04 03:34:00.912 [RAL:INFO]  channel 9 disabled
2022-10-04 03:34:00.912 [RAL:INFO] SX130x LBT not enabled
2022-10-04 03:34:00.912 [RAL:INFO] Station device: /dev/spidev0.0 (PPS capture disabled)
2022-10-04 03:34:00.912 [HAL:INFO] [lgw_spi_open:101] Setting SPI speed to 8000000
2022-10-04 03:34:00.912 [HAL:INFO] [lgw_spi_open:135] Note: SPI port opened and configured ok
2022-10-04 03:34:00.912 [HAL:ERRO] [lgw_start:742] FAIL TO CONNECT BOARD
2022-10-04 03:34:00.912 [RAL:ERRO] Concentrator start failed: lgw_start
2022-10-04 03:34:00.912 [RAL:ERRO] ral_config failed with status 0x08
2022-10-04 03:34:00.912 [any:ERRO] Closing connection to muxs - error in s2e_onMsg
2022-10-04 03:34:00.912 [AIO:DEBU] [3] ws_close reason=1000
2022-10-04 03:34:00.912 [AIO:DEBU] Echoing close - reason=1000
2022-10-04 03:34:01.197 [AIO:DEBU] [3|WS] Server sent close: reason=1000
2022-10-04 03:34:01.197 [AIO:DEBU] [3] WS connection shutdown...
2022-10-04 03:34:01.197 [TCE:VERB] Connection to MUXS closed in state -1
2022-10-04 03:34:01.197 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)
2022-10-04 03:34:01.337 [AIO:DEBU] [4] HTTP connection shutdown...
2022-10-04 03:34:01.338 [CUP:INFO] Interaction with CUPS done (no updates) - next regular check in 1d
2022-10-04 03:34:11.198 [HAL:INFO] [lgw_spi_close:159] Note: SPI port closed
2022-10-04 03:34:11.198 [AIO:INFO] ./tc.trust:
beitler commented 1 year ago

Hi @md4k9, for testing proper wiring/connectivity between the host and the radio board, the HAL provides a few test tools. Could you please run test_loragw_reg and test_loragw_com?

md4k9 commented 1 year ago

test_loragw_reg:

CoreCell reset through GPIO17...
SX1261 reset through GPIO17...
CoreCell power enable through GPIO18...
CoreCell ADC reset through GPIO13...
Opening SPI communication interface
Note: chip version is 0x10 (v1.0)
## TEST#1: read all registers and check default value for non-read-only registers
------------------
 TEST#1 PASSED
------------------

## TEST#2: read/write test on all non-read-only, non-pulse, non-w0clr, non-w1clr registers
------------------
 TEST#2 PASSED
------------------

Closing SPI communication interface
CoreCell reset through GPIO17...
SX1261 reset through GPIO17...
CoreCell power enable through GPIO18...
CoreCell ADC reset through GPIO13...`

**test_loragw_com**:
CoreCell reset through GPIO17...
SX1261 reset through GPIO17...
CoreCell power enable through GPIO18...
CoreCell ADC reset through GPIO13...
Beginning of test for loragw_com.c
Opening SPI communication interface
SX1302 version: 0x10
Cycle 0> did a 894-byte R/W on a data buffer with no error
Cycle 1> did a 1-byte R/W on a data buffer with no error
Cycle 2> did a 301-byte bulk R/W on a data buffer with no error
Cycle 3> did a 1007-byte R/W on a data buffer with no error
Cycle 4> did a 1-byte R/W on a data buffer with no error

... (it appears these were all "with no error"

Cycle 6227> did a 446-byte bulk R/W on a data buffer with no error
Cycle 6228> did a 356-byte R/W on a data buffer with no error
Cycle 6229> did a 1-byte R/W on a data buffer with no error
Cycle 6230> did a 450-byte bulk R/W on a data buffer with no error
Cycle 6231> ERROR (200): failed to write burst
Closing SPI communication interface
End of test for loragw_com.c

Do you know what could be causing "ERROR (200): failed to write burst"?

I think I may just not be installing the HAL binaries to the correct location. Where are these supposed to be installed such that they're properly included/linked during the compilation of Basics Station?

beitler commented 1 year ago

Hi @md4k9 ,

did you change the PIN definition in the reset script according to the instructions from seed? https://wiki.seeedstudio.com/WM1302_module/

If the test tools continue to fail for you, I suggest you reach out to the seed forums.

I think I may just not be installing the HAL binaries to the correct location. Where are these supposed to be installed such that they're properly included/linked during the compilation of Basics Station?

The build process takes care of that. You see the required dependencies being pulled from github into the deps/ folder.

md4k9 commented 1 year ago

@beitler Are you stating that the compilation of basicstation pulls all necessary HAL dependencies? In other words, I should be able to clone, compile, and run basicstation without needing to manually do anything with the HAL repo?

I don't believe there's anything wrong with my module, just that I'm not compiling or running something in the proper way. When I run the packet forwarder from the SX1302 HAL repo, it appears to run without any errors, but I'm still having trouble with basicstation.

I did change the pin settings per the Seeed instructions when compiling and testing the SX1302 HAL repo. However, for basicstation, I'm not sure which reset_lgw.sh file to edit as there are 4 of them (excluding 1 in examples): -/deps/lgw/git-repo/reset_lgw.sh -/deps/lgw/platform-rpi/reset_lgw.sh -/deps/lgw1302/git-repo/tools/reset_lgw.sh -/deps/lgw1302/platform-corecell/tools/reset_lgw.sh

Which one should I be editing?

beitler commented 1 year ago

@beitler Are you stating that the compilation of basicstation pulls all necessary HAL dependencies? In other words, I should be able to clone, compile, and run basicstation without needing to manually do anything with the HAL repo?

Correct. This is the case for the Semtech official gateway reference designs. Sometimes gateway manufacturers deviate from the reference designs. In such cases, the gateway manufacturers should provide instructions on the required changes. Sometimes gateway manufacturers provide their own fork of the HAL.

When I run the packet forwarder from the SX1302 HAL repo, it appears to run without any errors, but I'm still having trouble with basicstation.

Interesting. This is puzzling. If your packet forwarder runs ok, then the test tools from the SX1302 HAL repo should also run ok. Could you please post the global_conf.json of your packet forwarder installation as well as the station.conf of your station installation?

However, for basicstation, I'm not sure which reset_lgw.sh file to edit as there are 4 of them

station is not trying to guess the reset script location. The reset script needs to be explicitly configured in station.conf or passed as command line argument.

md4k9 commented 1 year ago

@beitler Thank you for the replies.

@beitler Are you stating that the compilation of basicstation pulls all necessary HAL dependencies? In other words, I should be able to clone, compile, and run basicstation without needing to manually do anything with the HAL repo?

Correct. This is the case for the Semtech official gateway reference designs. Sometimes gateway manufacturers deviate from the reference designs. In such cases, the gateway manufacturers should provide instructions on the required changes. Sometimes gateway manufacturers provide their own fork of the HAL.

Great thank you.

When I run the packet forwarder from the SX1302 HAL repo, it appears to run without any errors, but I'm still having trouble with basicstation.

Interesting. This is puzzling. If your packet forwarder runs ok, then the test tools from the SX1302 HAL repo should also run ok. Could you please post the global_conf.json of your packet forwarder installation as well as the station.conf of your station installation?

I'm not understanding what you believe isn't running correctly from SX1302 HAL. You requested that I run test_loragw_reg and test_loragw_com. For the former, both passed. For the latter, the test correctly writes data for a certain period of time before it errors out. After running it several times, it errors out after a different number of writes on each test. From what I read in the documentation, this test is supposed to run either until you kill it or it hits an error. Is it not expected that it will run into an error eventually ("ERROR (200): failed to write burst" in my case)?

I'm also unfamiliar with global_conf.json and am finding little in the way of documentation for this file. Do you have a good reference? The only places I see this file in my file system are in basicstation/deps/lgw...

However, for basicstation, I'm not sure which reset_lgw.sh file to edit as there are 4 of them

station is not trying to guess the reset script location. The reset script needs to be explicitly configured in station.conf or passed as command line argument.

I've been approaching the problem from a different angle and am trying to connect my gateway to a Basics Station LNS. However, I've run into a new issue: The EUI reported by station is missing a character - i.e. in the format xxxx:xxx:xxxx:xxxx (15 characters). Because of this, the LNS won't expect it as it's expecting 16 characters, not the 15 characters Basics Station is reporting. Do you know why this would be or how I can fix it? Another observation is that the ID reported by the SX1302 HAL tool "chip_id" reports a completely different, 16-character ID in hex format. Shouldn't these be the same?

chaudhariatul commented 1 year ago

Hi, I'm running into same issue while trying to connect to AWS IoT LoRaWAN using CUPS with SPI - WM1302. I have a rinit.sh file in the same directory with cups.trust, cups.key, cups.crt, station.conf and cups.uri file.

issuer name       : OU=Amazon Web Services O=Amazon.com Inc. L=Seattle ST=Washington C=US
subject name      : CN=AWS IoT Certificate
issued  on        : 2022-10-15 07:26:07
expires on        : 2049-12-31 23:59:59
signed using      : RSA with SHA-256
RSA key size      : 2048 bits
basic constraints : CA=false
key usage         : Digital Signature
2022-10-15 07:35:44.118 [TCE:VERB] Connecting to MUXS...
2022-10-15 07:35:44.307 [AIO:DEBU] [4] HTTP connection shutdown...
2022-10-15 07:35:44.307 [CUP:INFO] Interaction with CUPS done (no updates) - next regular check in 1d
2022-10-15 07:35:45.023 [TCE:VERB] Connected to MUXS.
2022-10-15 07:35:45.066 [S2E:WARN] Unknown field in router_config - ignored: protocol (0xFD309030)
2022-10-15 07:35:45.066 [S2E:WARN] Unknown field in router_config - ignored: regionid (0xE6FFB211)
2022-10-15 07:35:45.067 [SYS:VERB] rinit.sh: Forked, waiting...
2022-10-15 07:35:45.067 [SYS:DEBU] execvp argv[0]: </bin/bash>
2022-10-15 07:35:45.067 [SYS:DEBU]        argv[1]: <rinit.sh>
2022-10-15 07:35:45.067 [SYS:DEBU]        argv[2]: <rinit.sh>
2022-10-15 07:35:45.067 [SYS:DEBU]        argv[3]: </dev/spidev0.0>
2022-10-15 07:35:45.382 [SYS:INFO] Process rinit.sh (pid=1067) completed
2022-10-15 07:35:45.382 [RAL:INFO] Lora gateway library version: Version: 5.0.1;
2022-10-15 07:35:45.392 [RAL:INFO] [LGW lgw1] clksrc=1 lorawan_public=1
2022-10-15 07:35:45.392 [RAL:INFO]  RX/TX RF0:    904.3MHz rssi_offset=-166.0 type=2 tx_notch_freq=0
2022-10-15 07:35:45.392 [RAL:INFO]  RX    RF1:    905.3MHz rssi_offset=-166.0 type=2 tx_notch_freq=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   0:    903.9MHz rf=0 freq=-400.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   1:    904.1MHz rf=0 freq=-200.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   2:    904.3MHz rf=0 freq=  +0.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   3:    904.5MHz rf=0 freq=+200.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   4:    904.7MHz rf=0 freq=+400.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   5:    904.9MHz rf=1 freq=-400.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   6:    905.1MHz rf=1 freq=-200.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   7:    905.3MHz rf=1 freq=  +0.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  channel 8 disabled
2022-10-15 07:35:45.392 [RAL:INFO]  channel 9 disabled
2022-10-15 07:35:45.392 [RAL:INFO] SX130x LBT not enabled
2022-10-15 07:35:45.392 [RAL:INFO] Station device: /dev/spidev0.0 (PPS capture disabled)
2022-10-15 07:35:45.392 [HAL:INFO] [lgw_spi_open:101] Setting SPI speed to 8000000
2022-10-15 07:35:45.392 [HAL:INFO] [lgw_spi_open:135] Note: SPI port opened and configured ok
2022-10-15 07:35:45.392 [HAL:ERRO] [lgw_start:742] FAIL TO CONNECT BOARD
2022-10-15 07:35:45.392 [RAL:ERRO] Concentrator start failed: lgw_start
2022-10-15 07:35:45.392 [RAL:ERRO] ral_config failed with status 0x08
2022-10-15 07:35:45.392 [any:ERRO] Closing connection to muxs - error in s2e_onMsg
2022-10-15 07:35:45.392 [AIO:DEBU] [3] ws_close reason=1000
2022-10-15 07:35:45.392 [AIO:DEBU] Echoing close - reason=1000
2022-10-15 07:35:45.438 [AIO:DEBU] [3|WS] Server sent close: reason=1000
2022-10-15 07:35:45.438 [AIO:DEBU] [3] WS connection shutdown...
2022-10-15 07:35:45.438 [TCE:VERB] Connection to MUXS closed in state -1
2022-10-15 07:35:45.438 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)
2022-10-15 07:35:55.438 [HAL:INFO] [lgw_spi_close:159] Note: SPI port closed
2022-10-15 07:35:55.439 [AIO:INFO] ./tc.trust:

my Station.conf content:

{
    /* If slave-X.conf present this acts as default settings */
    "SX1302_conf": {             /* Actual channel plan is controlled by server */
    "lorawan_public": true,      /* is default */
        "clksrc": 1,             /* radio_1 provides clock to concentrator */
    /* path to the SPI device, un-comment if not specified on the command line e.g., RADIODEV=/dev/spidev0.0 */
    /*"device": "/dev/spidev0.0",*/
    /* freq/enable provided by LNS - only HW specific settings listed here */
    "radio_0": {
        "type": "SX1257",
        "rssi_offset": -166.0,
        "tx_enable": true,
        "antenna_gain": 0
    },
    "radio_1": {
        "type": "SX1257",
        "rssi_offset": -166.0,
        "tx_enable": false
    }
    /* chan_multiSF_X, chan_Lora_std, chan_FSK provided by LNS */
    },
    "station_conf": {
    "radio_init": "rinit.sh",
    "log_file":  "stderr",
    "log_level": "DEBUG",  /* XDEBUG,DEBUG,VERBOSE,INFO,NOTICE,WARNING,ERROR,CRITICAL */
    "log_size":  10000000,
    "log_rotate":  3,
    "CUPS_RESYNC_INTV": "1s"
    }
}
beitler commented 1 year ago

Hi @chaudhariatul, thanks for submitting the issue. These are very gateway specific aspects. Whenever the connection to the radio board fails, this should be the thought process for troubleshooting:

chaudhariatul commented 1 year ago

Hi @beitler I found the issue. With WM1302 I should have used the corecell configuration and updated the RESET pin.

It's now working.

toi-go commented 1 year ago

Hi @md4k9, for testing proper wiring/connectivity between the host and the radio board, the HAL provides a few test tools. Could you please run test_loragw_reg and test_loragw_com?

Would you mind sharing some details on how to run these tools. I've found the source files in the following directories: basicstation/deps/lgw1302/git-repo/libloragw/tst/test_loragw_reg.c basicstation/deps/lgw1302/platform-corecell/libloragw/tst/test_loragw_reg.c But I haven't found any binaries.

To build basicstation, I've used the following command: make platform=corecell variant=debug deps s-clean s-all

How to build the binaries of these tools?

grostim commented 2 weeks ago

I have the same issue with my Seeedstudio RHF0M301. "[HAL:ERRO] [lgw_start:742] FAIL TO CONNECT BOARD"

All HAL test tools run perfectly fine; even the test_capture_packet that logs a couple of packets per minutes.

If i let BasicStation try in loop, it will eventually (sometimes after hours of trials) succeed to connect and work as expected.

by activating the XDBG level, i see that the issue is related to PLL

2024-06-17 14:11:43.479 [HAL:XDEB] [lgw_setup_sx125x:465] ERROR: FAIL TO LOCK PLL

Meimurugan11 commented 2 weeks ago

Hi, I'm running into same issue while trying to connect to AWS IoT LoRaWAN using CUPS with SPI - WM1302. I have a rinit.sh file in the same directory with cups.trust, cups.key, cups.crt, station.conf and cups.uri file.

issuer name       : OU=Amazon Web Services O=Amazon.com Inc. L=Seattle ST=Washington C=US
subject name      : CN=AWS IoT Certificate
issued  on        : 2022-10-15 07:26:07
expires on        : 2049-12-31 23:59:59
signed using      : RSA with SHA-256
RSA key size      : 2048 bits
basic constraints : CA=false
key usage         : Digital Signature
2022-10-15 07:35:44.118 [TCE:VERB] Connecting to MUXS...
2022-10-15 07:35:44.307 [AIO:DEBU] [4] HTTP connection shutdown...
2022-10-15 07:35:44.307 [CUP:INFO] Interaction with CUPS done (no updates) - next regular check in 1d
2022-10-15 07:35:45.023 [TCE:VERB] Connected to MUXS.
2022-10-15 07:35:45.066 [S2E:WARN] Unknown field in router_config - ignored: protocol (0xFD309030)
2022-10-15 07:35:45.066 [S2E:WARN] Unknown field in router_config - ignored: regionid (0xE6FFB211)
2022-10-15 07:35:45.067 [SYS:VERB] rinit.sh: Forked, waiting...
2022-10-15 07:35:45.067 [SYS:DEBU] execvp argv[0]: </bin/bash>
2022-10-15 07:35:45.067 [SYS:DEBU]        argv[1]: <rinit.sh>
2022-10-15 07:35:45.067 [SYS:DEBU]        argv[2]: <rinit.sh>
2022-10-15 07:35:45.067 [SYS:DEBU]        argv[3]: </dev/spidev0.0>
2022-10-15 07:35:45.382 [SYS:INFO] Process rinit.sh (pid=1067) completed
2022-10-15 07:35:45.382 [RAL:INFO] Lora gateway library version: Version: 5.0.1;
2022-10-15 07:35:45.392 [RAL:INFO] [LGW lgw1] clksrc=1 lorawan_public=1
2022-10-15 07:35:45.392 [RAL:INFO]  RX/TX RF0:    904.3MHz rssi_offset=-166.0 type=2 tx_notch_freq=0
2022-10-15 07:35:45.392 [RAL:INFO]  RX    RF1:    905.3MHz rssi_offset=-166.0 type=2 tx_notch_freq=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   0:    903.9MHz rf=0 freq=-400.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   1:    904.1MHz rf=0 freq=-200.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   2:    904.3MHz rf=0 freq=  +0.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   3:    904.5MHz rf=0 freq=+200.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   4:    904.7MHz rf=0 freq=+400.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   5:    904.9MHz rf=1 freq=-400.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   6:    905.1MHz rf=1 freq=-200.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  [mSF]   7:    905.3MHz rf=1 freq=  +0.0 datarate=0
2022-10-15 07:35:45.392 [RAL:INFO]  channel 8 disabled
2022-10-15 07:35:45.392 [RAL:INFO]  channel 9 disabled
2022-10-15 07:35:45.392 [RAL:INFO] SX130x LBT not enabled
2022-10-15 07:35:45.392 [RAL:INFO] Station device: /dev/spidev0.0 (PPS capture disabled)
2022-10-15 07:35:45.392 [HAL:INFO] [lgw_spi_open:101] Setting SPI speed to 8000000
2022-10-15 07:35:45.392 [HAL:INFO] [lgw_spi_open:135] Note: SPI port opened and configured ok
2022-10-15 07:35:45.392 [HAL:ERRO] [lgw_start:742] FAIL TO CONNECT BOARD
2022-10-15 07:35:45.392 [RAL:ERRO] Concentrator start failed: lgw_start
2022-10-15 07:35:45.392 [RAL:ERRO] ral_config failed with status 0x08
2022-10-15 07:35:45.392 [any:ERRO] Closing connection to muxs - error in s2e_onMsg
2022-10-15 07:35:45.392 [AIO:DEBU] [3] ws_close reason=1000
2022-10-15 07:35:45.392 [AIO:DEBU] Echoing close - reason=1000
2022-10-15 07:35:45.438 [AIO:DEBU] [3|WS] Server sent close: reason=1000
2022-10-15 07:35:45.438 [AIO:DEBU] [3] WS connection shutdown...
2022-10-15 07:35:45.438 [TCE:VERB] Connection to MUXS closed in state -1
2022-10-15 07:35:45.438 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)
2022-10-15 07:35:55.438 [HAL:INFO] [lgw_spi_close:159] Note: SPI port closed
2022-10-15 07:35:55.439 [AIO:INFO] ./tc.trust:

my Station.conf content:

{
    /* If slave-X.conf present this acts as default settings */
    "SX1302_conf": {           /* Actual channel plan is controlled by server */
  "lorawan_public": true,      /* is default */
        "clksrc": 1,           /* radio_1 provides clock to concentrator */
  /* path to the SPI device, un-comment if not specified on the command line e.g., RADIODEV=/dev/spidev0.0 */
  /*"device": "/dev/spidev0.0",*/
  /* freq/enable provided by LNS - only HW specific settings listed here */
  "radio_0": {
      "type": "SX1257",
      "rssi_offset": -166.0,
      "tx_enable": true,
      "antenna_gain": 0
  },
  "radio_1": {
      "type": "SX1257",
      "rssi_offset": -166.0,
      "tx_enable": false
  }
  /* chan_multiSF_X, chan_Lora_std, chan_FSK provided by LNS */
    },
    "station_conf": {
  "radio_init": "rinit.sh",
  "log_file":  "stderr",
  "log_level": "DEBUG",  /* XDEBUG,DEBUG,VERBOSE,INFO,NOTICE,WARNING,ERROR,CRITICAL */
  "log_size":  10000000,
  "log_rotate":  3,
  "CUPS_RESYNC_INTV": "1s"
    }
}

Hi @beitler and @chaudhariatul ,

Am using waveshare SX130x LoRaWAN Gateway Module/HAT for rpi 4. I want to integrate the sx1302 lorawan packet forwarder with aws server it requires aws key, certifates, trust certificates. I am trying to configure with sample configuration files am not sure this format is right. Please help me to resolve this issue.Any help would be greatly appreciated. If possible could you give me the sample station.conf file for aws integration.

Thanks

Meimurugan11 commented 2 weeks ago

Hi all, Am using waveshare SX130x LoRaWAN Gateway Module/HAT for rpi 4. I want to integrate the sx1302 lorawan packet forwarder with aws server it requires aws key, certifates, trust certificates. I am trying to configure with sample configuration files am not sure this format is right. Please help me to resolve this issue.Any help would be greatly appreciated. If possible could you give me the sample station.conf file for aws integration.

Thanks

chaudhariatul commented 6 days ago

Which OS are you running?

Share output for arch, uname -a and cat /etc/os-release.