Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

AWS IoT LoRaWAN - Unable to connect node to gateway.

0

My goal is to create a private lora network using AWS IoT for LoRaWAN. For the gateway, I am using a raspberry pi 4 (model B) in combination with a Seed Studios WM1302 Corecell concentrator running basicstation (Station Ver : 2.0.6(corecell/std)). The gateway was successfully connected to AWS using the following this AWS IoT tutorial -> Getting Started with AWS IoT Core for LoRaWAN on YouTube. I also using this tutorial to setup the node profiles, etc in AWS to prepare connect a node to the network through the gateway.

The node is not an off the shelf node. It is a TTGO T-Beam running "MCCI LoRaWAN LMIC Library" arduino library. The TTGO T-Beam consists of an ESP32 MCU processor and a Lora 1276 radio transceiver. The DevEUI was created from the T-Beam's mac address (adding fffe to the middle). The AppEUI has been set to the same as the DevEUI and the AppKey has been randomly generator using python code. On the T-Beam firmware, the DevEUI and AppEUI have both been entered in little-edian, while the AppKey is in big-edian. These EUI's and Key were entered in normally on the AWS Iot for LoRaWAN side, under "add device". I also understand this isn't "best practice" for assigning an DevEUI, AppEUI and AppKey, however it is simply for the sake of testings.

The Problem: Somewhere there is an issue as the T-Beam node is not connecting to the AWS raspberry pi gateway. The logs of the gateway show it is connected. AWS also shows the gateway is connect. However the node is running in a loop of:

118176217: EV_TXSTART

118558132: EV_JOIN_TXCOMPLETE: no JoinAccept

It seems the gateway is not sending out a JoinRequest (or JoinAccept, not sure which it would be). I know on the TTN network, there is an App server and a Join server, however those dont exist within AWS's LoraWAN solution. I am wondering how I can get a non-off-the-shelve node to connect to my gateway. How does the gateway send out join requests and how does AWS accept a device's join accept. The gateway log does show the following as well (should the JoinEUI list be 0?):

Configuring for region: US915 -- 902.0MHz..928.0MHz

...

2024-09-22 22:26:49.826 [S2E:INFO] TX power: 26.0 dBm EIRP

2024-09-22 22:26:49.826 [S2E:INFO] JoinEUI list: 0 entries

2024-09-22 22:26:49.826 [S2E:INFO] NetID filter: FFFFFFFF-FFFFFFFF-FFFFFFFF-FFFFFFFF

2024-09-22 22:26:49.826 [S2E:INFO] Dev/test settings: nocca=0 nodc=0 nodwell=0

Here are the specifications of my setup: Both gateway and node are physically in the same room on a table, antenna connected to each respectively.

Gateway: US-915, Subband 1 filter in AWS

no JoinEUI filters

no NetID filters

CUP's enables

all roles, profiles, rules etc have been setup currently in AWS

Node:

US-915, Subband 1 filter

Will to provide more information upon request.

Topics
Internet of Things (IoT)
Tags
AWS IoT Core
Language
English

asked 2 years ago475 views

5 Answers
0

Hi. AWS IoT Core for LoRaWAN includes a join server. To be clear, devices don't connect to gateways. Your Basic Station gateway will relay the Join Request from device to cloud, and relay the Join Accept from cloud to device. Basic Station will log this if you set the logging level to at least XDEBUG. Then you will for example see Join Request being relayed on the Web Sockets connection::

2024-03-05 06:36:00.015 [AIO:XDEB] [4|WS] > {"msgtype":"jreq","MHdr":0,"JoinEUI":"70-B3-D5-7E-D0-02-6B-90","DevEUI":"70-B3-D5-49-99-B6-A6-83","DevNonce":2084,"MIC":1936168195,"RefTime":1709620559.871467,"DR":0,"Freq":917400000,"upinfo":{"rctx":0,"xtime":28147503087419124,"gpstime":1393655777968900,"fts":-1,"rssi":-63,"snr":7,"rxtime":1709620560.015467}}

If you don't even see the Join Request on the gateway, the issue is probably your device and gateway are on different RF frequencies/subbands. Check the router_config message from the Basic Station logs: https://doc.sm.tc/station/tcproto.html#router-config-message.

On the AWS side, you can get more visibility using Network Analyzer: https://www.youtube.com/watch?v=Qk9pkhL8xjc. And/or enable wireless logging in CloudWatch: https://docs.aws.amazon.com/iot-wireless/latest/developerguide/cloud-watch-logs.html

I think the likelihood is that your device profile or device has been created in AWS IoT Core for LoRaWAN with some incorrect information. Resulting in Join Accepts being received by AWS IoT Core for LoRaWAN, but not accepted. So please carefully consider your LoRaWAN version, regional spec setting, DevEUI, AppEUI and so forth.

AWS
EXPERT

answered 2 years ago

  • Jetty
    2 years ago

    If you have an insight on the comment below, that would be very much appreciated.

  • Jetty
    2 years ago

    Are you able to check on the last two posts at the bottom? Feedback would be extremely helpful.

0

Hi Greg, thank you for your response. It helped me understand what to look. Very much appreciated!

The Raspberry Pi Basic Station Gateway is communicating with AWS. It shows as a connected gateway in AWSIOT. I also see the "router_config" in the basic station logs:

2025-01-04 22:51:49.103 [AIO:XDEB] [4|WS] > {"msgtype":"version","station":"2.0.6(corecell/std)","firmware":null,"package":null,"model":"corecell","protocol":2,"features":"rmtsh"}
2025-01-04 22:51:49.103 [AIO:XDEB] [4] socket write bytes=143
2025-01-04 22:51:49.141 [AIO:XDEB] [4] socket read  bytes=981
2025-01-04 22:51:49.141 [AIO:XDEB] [4|WS] < {"msgtype":"router_config","NetID":null,"JoinEUI":null,"region":"US902","hwspec":"sx1301/1","freq_range":[902000000,928000000],"DRs":[[10,125,0],[9,125,0],[8,125,0],[7,125,0],[8,500,0],[-1,0,0],[-1,0,0],[-1,0,0],[12,500,1],[11,500,1],[10,500,1],[9,500,1],[8,500,0],[7,500,1],[-1,0,0],[-1,0,0]],"sx1301_conf":[{"radio_0":{"enable":true,"freq":902700000},"radio_1":{"enable":true,"freq":903700000},"chan_FSK":{"enable":false},"chan_Lora_std":{"enable":true,"radio"
2025-01-04 22:51:49.142 [AIO:XDEB] [4|WS] . :0,"if":300000,"bandwidth":500000,"spread_factor":8},"chan_multiSF_0":{"enable":true,"radio":0,"if":-400000},"chan_multiSF_1":{"enable":true,"radio":0,"if":-200000},"chan_multiSF_2":{"enable":true,"radio":0,"if":0},"chan_multiSF_3":{"enable":true,"radio":0,"if":200000},"chan_multiSF_4":{"enable":true,"radio":0,"if":400000},"chan_multiSF_5":{"enable":true,"radio":1,"if":-400000},"chan_multiSF_6":{"enable":true,"radio":1,"if":-200000},"chan_multiSF_7":{"enable
2025-01-04 22:51:49.142 [AIO:XDEB] [4|WS] . ":true,"radio":1,"if":0}}],"protocol":0,"regionid":0}
2025-01-04 22:51:49.142 [S2E:WARN] Unknown field in router_config - ignored: protocol (0xFD309030)
2025-01-04 22:51:49.142 [S2E:WARN] Unknown field in router_config - ignored: regionid (0xE6FFB211)

It seems the issue is likely with the the Node as I am not seeing a "jreq" message on the gateway. The Node is running the "MCCI LoRaWAN LMIC Library" Github (https://github.com/mcci-catena/arduino-lmic?tab=readme-ov-file#changing-debug-output) This is the debugging I am getting from the node:

364555: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 4
365187: RXMODE_SINGLE, freq=926300000, SF=10, BW=500, CR=4/5, IH=0
rxtimeout: entry: 368647 rxtime: 365179 entry-rxtime: 3468 now-entry: 5 rxtime-txend: 311126
426805: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
427437: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 434096 rxtime: 427429 entry-rxtime: 6667 now-entry: 6 rxtime-txend: 373376
434119: processRx2Jacc txrxFlags 0x2 --> 00
436543: EV_JOIN_TXCOMPLETE: no JoinAccept
444234: engineUpdate, opmode=0xc
457275: engineUpdate, opmode=0xc
457296: EV_TXSTART
457375: TXMODE, freq=904600000, len=23, SF=8, BW=500, CR=4/5, IH=0
769653: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 5
770287: RXMODE_SINGLE, freq=923900000, SF=7, BW=500, CR=4/5, IH=0
rxtimeout: entry: 773010 rxtime: 770278 entry-rxtime: 2732 now-entry: 6 rxtime-txend: 311126
831903: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 5
832537: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 839196 rxtime: 832528 entry-rxtime: 6668 now-entry: 5 rxtime-txend: 373376
839218: processRx2Jacc txrxFlags 0x2 --> 00
841640: EV_JOIN_TXCOMPLETE: no JoinAccept
849332: engineUpdate, opmode=0xc
1743222: engineUpdate, opmode=0xc

... It keeps trying to transmit, but nothing is received on the gateway side.

Both systems have been configured to us915. Sub band 1

UPDATE Jan 6th:

The LMIC library references sub-bands as 0-7 (no 1-8). So the node was really using sub-bad 2. I have changed it to sub-band 1 however I am still not receiving a transmission on the gateway

answered 2 years ago

  • Greg EXPERT
    2 years ago

    Hi. The router_config message shows that the subband 1 is correctly configured. The gateway will be listening on upstream channels 0-7 (902.3 to 903.7, 200kHz spacing, 125kHz BW) and upstream channel 64 (903.0, 500kHZ BW). However, your device log shows only one transmission, on channel 65 (904.6). Per your update on Jan 6, is your device now transmitting on 903.0? If so, the gateway should receive it. Presumably this transmission is the join request. If possible, I recommend to change the firmware to send the join request on channels 0-7.

0

I only included a portion of the log from the node. Apologies for not getting a good sample. Here some log from the node. I've gotten ride of the sub-band 1 declaration on the node side as specifying the a sub-band isn't best practice. It is not correctly transmitting TX on various sub-bands. The node transmits a jreq ever 10 seconds or so (length 23 bytes). Both gateway and node seem to be correctly configured to the right frequencies. Not picking up any jreq on the gateway logs.

3237030: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 4
3237664: RXMODE_SINGLE, freq=923900000, SF=10, BW=500, CR=4/5, IH=0
rxtimeout: entry: 3241122 rxtime: 3237655 entry-rxtime: 3467 now-entry: 5 rxtime-txend: 311126
3299280: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
3299913: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 3306572 rxtime: 3299905 entry-rxtime: 6667 now-entry: 6 rxtime-txend: 373376
3306594: processRx2Jacc txrxFlags 0x2 --> 00
3309342: EV_JOIN_TXCOMPLETE: no JoinAccept
3317038: engineUpdate, opmode=0xc
3353900: engineUpdate, opmode=0xc
3353919: EV_TXSTART
3354000: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
3666278: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 4
3666912: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
rxtimeout: entry: 3669634 rxtime: 3666903 entry-rxtime: 2731 now-entry: 5 rxtime-txend: 311126
3728528: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
3729161: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 3735820 rxtime: 3729153 entry-rxtime: 6667 now-entry: 6 rxtime-txend: 373376
3735842: processRx2Jacc txrxFlags 0x2 --> 00
3738591: EV_JOIN_TXCOMPLETE: no JoinAccept
3746281: engineUpdate, opmode=0xc
4136084: engineUpdate, opmode=0xc
4136104: EV_TXSTART
4136182: TXMODE, freq=905300000, len=23, SF=10, BW=125, CR=4/5, IH=0
4469859: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 4
4470493: RXMODE_SINGLE, freq=927500000, SF=10, BW=500, CR=4/5, IH=0
rxtimeout: entry: 4473951 rxtime: 4470484 entry-rxtime: 3467 now-entry: 6 rxtime-txend: 311126
4532109: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
4532742: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 4539401 rxtime: 4532734 entry-rxtime: 6667 now-entry: 5 rxtime-txend: 373376
4539423: processRx2Jacc txrxFlags 0x2 --> 00
4542171: EV_JOIN_TXCOMPLETE: no JoinAccept
4549861: engineUpdate, opmode=0xc
4557218: engineUpdate, opmode=0xc
4557238: EV_TXSTART
4557318: TXMODE, freq=904600000, len=23, SF=8, BW=500, CR=4/5, IH=0
4869596: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 5
4870230: RXMODE_SINGLE, freq=923900000, SF=7, BW=500, CR=4/5, IH=0
rxtimeout: entry: 4872953 rxtime: 4870221 entry-rxtime: 2732 now-entry: 5 rxtime-txend: 311126
4931846: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 5
4932480: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 4939139 rxtime: 4932471 entry-rxtime: 6668 now-entry: 6 rxtime-txend: 373376
4939161: processRx2Jacc txrxFlags 0x2 --> 00
4941908: EV_JOIN_TXCOMPLETE: no JoinAccept
4949599: engineUpdate, opmode=0xc

... This isn't really an AWS issue as of right now. Must be an RF issue on the node side or raspi concentrator side. I appreciate the help thus far. I will put this thread on hold until I have a dedicated AWS related issue....

answered 2 years ago

  • Greg EXPERT
    2 years ago

    The gateway won't receive the following messages because they're transmitted on the wrong subband. The gateway is only listening on channels 0-7 and 64 (which is correct for subband 1).

    TXMODE, freq=905300000, len=23, SF=10, BW=125, CR=4/5, IH=0
TXMODE, freq=904600000, len=23, SF=8, BW=500, CR=4/5, IH=0

    I think the gateway should receive this one because it's channel 64.

    TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
0

Hi Greg, I've set the Node to only transmit on sub-band 1 (seen in logs blow). No transmissions are picked up.

I got an software-defined-radio to test if the node is transmitting at all, and on the right frequencies. I can confirm it is. The SDR is able to pick up the radio signals. So that leads me to believe it is an issue with basic station / WM1302 concentrator. It is not picking up radio signals (even though all the SPI read/writes in the logs check out, all the frequency configs are correct, and everything else I could think to check).

I am uploaded the logs here if you can let me know if everything checks out? I am wondering if "synchword PRIVATE" has anything to do with it? Must the node at the gateway has the same synchword?

Also, this is the video I followed to setup the gateway: Connecting gateways to AWS Iot Core for LoRaWAN by Ali Benfattoum He sets his up for a different concentrator model. I made the necessary changes for setting up the "corecell" version of basic station instead of "live-s2.sm.tc" build to match my hardware

Station Logs: Station Log 1 Station Log 2 Station Log 3 Station Log 4 Station Log 5 Station Log 6 Station Log 7 Station Log 8 Station Log 9 Station Log 10 Station Log 11 Station Log 12 Station Log 13 Station Log 14 Station Log 15

Node Logs: T-Beam Logs 1 T-Beam Logs 2

answered 2 years ago

0

Update:

The gateway might be picking up a LoRa Join request from the node... but they are few and far between. The gateway only show a transmission received in the logs about every 10-20 minutes and the node transmits every 10 seconds. Also the signal strength is super low so I don't know if the gateway is actually picking up a node transmission or not. Here is the snippet from the log. Seems to be a CRC error (last line). The rx_buffer_fetch looks correct however (23 byes)

2025-01-06 19:31:05.896 [SYN:XDEB] SYNC: ustime=0x00002BF2B230 (Q=181): xticks=0x26ca8223 xtime=0xF5000026CA8223 - PPS: pps_xticks=0x00000000 (0) pps_xtime=0x0 (pps_en=0) 2025-01-06 19:31:07.146 [HAL:XDEB] [rx_buffer_fetch:154] ----------------- 2025-01-06 19:31:07.146 [HAL:XDEB] [rx_buffer_fetch:155] rx_buffer_fetch: nb_bytes to be fetched: 23 (23 0) 2025-01-06 19:31:07.146 [HAL:XDEB] [rx_buffer_fetch:165] RX BUFFER: A5C00007500D00270C00E67D796345FC6BB1DB00000073 2025-01-06 19:31:07.146 [HAL:XDEB] [rx_buffer_fetch:177] INFO: syncword found at idx 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:244] INFO: pkt syncword found at index 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:275] Packet checksum OK (0x73) 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:311] ----------------- 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:312] modem: 13 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:313] chan: 7 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:314] size: 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:315] crc_en: 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:316] crc_err: 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:317] sync_err: 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:318] hdr_err: 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:319] timing_set: 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:320] codr: 0 2025-01-06 19:31:07.147 [HAL:XDEB] [rx_buffer_pop:321] datr: 5 2025-01-06 19:31:07.148 [HAL:XDEB] [rx_buffer_pop:322] num_ts: 0 2025-01-06 19:31:07.148 [HAL:XDEB] [rx_buffer_pop:331] ----------------- 2025-01-06 19:31:07.148 [HAL:XDEB] [sx1302_parse:1946] [7 0x11] 2025-01-06 19:31:07.148 [HAL:XDEB] [sx1302_parse:1959] Note: LoRa packet (modem 13 chan 7) 2025-01-06 19:31:07.148 [HAL:ERRO] [timestamp_counter_correction:463] wrong coding rate (0) 2025-01-06 19:31:07.148 [HAL:XDEB] [sx1302_rssi_get_temperature_offset:2283] INFO: RSSI temperature compensation: 2025-01-06 19:31:07.148 [HAL:XDEB] [sx1302_rssi_get_temperature_offset:2284] coeff_a: 0.000 2025-01-06 19:31:07.148 [HAL:XDEB] [sx1302_rssi_get_temperature_offset:2285] coeff_b: 0.000 2025-01-06 19:31:07.148 [HAL:XDEB] [sx1302_rssi_get_temperature_offset:2286] coeff_c: 20.410 2025-01-06 19:31:07.148 [HAL:XDEB] [sx1302_rssi_get_temperature_offset:2287] coeff_d: 2162.560 2025-01-06 19:31:07.148 [HAL:XDEB] [sx1302_rssi_get_temperature_offset:2288] coeff_e: 0.000 2025-01-06 19:31:07.148 [HAL:XDEB] [lgw_receive:1320] INFO: RSSI temperature offset applied: 1.375 dB (current temperature 32.0 C) 2025-01-06 19:31:07.148 [HAL:XDEB] [lgw_receive:1323] INFO: nb pkt found:1 left:0 2025-01-06 19:31:07.148 [HAL:XDEB] [lgw_receive:1337] --- OUT 2025-01-06 19:31:07.148 [RAL:DEBU] [CRC FAIL] 903.700MHz -6.50/-93.0 SF?? (mod=16/dr=5/bw=4) xtick=26dd8b5f (652053343) 0 bytes:

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content