IEEE802.15.4 over LoRa

Hello!

I have some boards similar to lora-e5-dev with sx126x LoRa module (RAK3172). Now I try to make a network on these boards.

As I inderstand, sx126x works as a raw device without hardware address and some other stuff if I don’t add the LoRaWAN module. So, I connected two gnrc_networking boards, add global IPs and it pinged normally. UDP also works.

Well, my questions:

  • Can I use routing with this radio? I don’t understand, should or not ndp and rpl work with this radio. gnrc_border_router can’t connect to other gnrc_networking over lora.
  • Anyone tried to make a 6loWPAN network with raw devices?

Main idea was to create a mesh network with LoRa modulation on 6LoWPAN. I know, LoRa is not a part of IEEE802.15.4 but I found an interesting text: Add an IEEE 802.15.4 over LoRa Semtech SX1276/77/78/79 device driver

Should I try to create a new driver for SX126x with IEEE802.15.4 MAC layer support? :slight_smile:

1 Like

Hi @HoCoK,

s I inderstand, sx126x works as a raw device without hardware address and some other stuff if I don’t add the LoRaWAN module. So, I connected two gnrc_networking boards, add global IPs and it pinged normally. UDP also works.

Yes, this will work because the SX1276 driver runs as a “raw” interface if you don’t use LoRaWAN (see RIOT/sys/net/gnrc/netif/init_devs/auto_init_sx126x.c at master · RIOT-OS/RIOT · GitHub). However, note that this is only encapsulating full IPv6 frames in the LoRa PHY Payload and does not offer any kind of access control to the media. Therefore expect a very high packet loss if you deploy many of these nodes in the same network.

Can I use routing with this radio? I don’t understand, should or not ndp and rpl work with this radio. gnrc_border_router can’t connect to other gnrc_networking over lora.

In theory this “should” work, because the router only cares about an interface (“raw” LoRa in this case). Therefore you could deploy regular routers (e.g gnrc_networking ) or border routers (gnrc_border_router).

Anyone tried to make a 6loWPAN network with raw devices?

You will need some kind of addressing to do that. You can probably base on the ESP-Now implementation, which also uses 6LowPAN (see RIOT/cpu/esp_common/esp-now/esp_now_gnrc.c at master · RIOT-OS/RIOT · GitHub).

Main idea was to create a mesh network with LoRa modulation on 6LoWPAN. I know, LoRa is not a part of IEEE802.15.4 but I found an interesting text: Add an IEEE 802.15.4 over LoRa Semtech SX1276/77/78/79 device driver

You may be interested in the on-going efforts to provide 802.15.4 PHY support for LoRa. https://dl.acm.org/doi/10.1145/3552432 defines an adaptation layer to run a IEEE 802.15.4 MAC over LoRa. That work is specific for the DSME operation mode of IEEE 802.15.4 (which supports CSMA/CA and time-slotted transmissions), but the adaptation layer is the same for any IEEE 802.15.4 MAC.

The work provides an IEEE 802.15.4 compatible SX1276 transceiver and the full integration with the MAC in GitHub - inetrg/tosn-dsmelora22: Measurement applications and code of DSME-LoRa.

Should I try to create a new driver for SX126x with IEEE802.15.4 MAC layer support? :slight_smile:

This would be definitely interesting! Maybe you can base on the existing SX1276 implementation for IEEE 802.15.4 (RIOT/drivers/sx127x/sx127x_rf_ops.c at a0d83380996283f60b9a6a18bf9f5c764f50b8ab · inetrg/RIOT · GitHub). Then you would get for free support for the DSME MAC, if you need reliable communication. If you don’t need the full MAC, you could still run the driver with the SubMAC (RIOT/sys/net/link_layer/ieee802154/submac.c at master · RIOT-OS/RIOT · GitHub) and get CSMA/CA + frame retransmission for free (and ofc 6LowPAN)

1 Like

Thanks for your answer! It really helps me in my RIOT journey :slightly_smiling_face:

Interesting idea. For some simple, small sensor nodes. Making them IP routable. That could be interesting. Lora also has so many different spreading factors etc. I would love to play around with that, WiFi-Halow, 6LowPAN and IPv6 over BLE.

Hello!

I think, I should try to port SubMAC to sx126x but I don’t find any docs except:

*https://doc.riot-os.org/group__net__ieee802154__submac.html
*https://github.com/RIOT-OS/RIOT/wiki/Tutorial%3A-How-to-port-a-radio-module-driver-to-RIOT-OS *https://doc.riot-os.org/driver-guide.html

which help me to create new or change existing driver with the SubMAC. Did I miss important docs or should I just follow to other drivers like kw2xrf or else? It is not clear for me at the first sight.

Cheers, Klim

Hi @HoCoK

A device that implements the IEEE 802.15.4 Radio HAL will work “out of the box” with the SubMAC, so you only need to write the HAL for the SX126X. You probably only need to adjusts the symbol time in the SubMAC, but that can be done in a separate step.

You can base on the existing implementation of the SX127X (RIOT/sx127x_rf_ops.c at a0d83380996283f60b9a6a18bf9f5c764f50b8ab · inetrg/RIOT · GitHub).

Hmm, it sounds pretty easily. I’ll figure it out. Thank you :relieved:

btw how similar are sx126x/sx127x/sx1280 ? Could they be served by a common driver when moving to the radio HAL or are there too many differences?

I cannot say so much about the sx1280, but the sx127x and sx126x diverge quite a lot. In fact, the sx126x driver is a package.

But I definitely like the idea of implementing these drivers with the Radio HAL. It is not only convenient for the upper layer, but would also enable to use (G)-FSK modulation (present in all LoRa transceivers) as a standard IEEE 802.15.4g with the SubMAC.

On 22/10/28 04:07PM, Benjamin Valentin via RIOT wrote:

btw how similar are sx126x/sx127x/sx1280 ? Could they be served by a common driver when moving to the radio HAL or are there too many differences?


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

Hello!

I have created a HAL level for sx126x and run on my STM32WLE5CC boards almost succesfully. Tested between gnrc_networking apps:

  1. UDP is worked
  2. RPL is worked
  3. Ping is worked, but some packets may be lost, because (I think) ping don’t wait after transmit a packet. Parametres for “ping” (-i, -W) don’t help.
Transmitter's log:
[11:34:16:214] ping6 -W 5000 -i 5000 fe80::dcee:6850:84e:9405%6␍␊
[11:34:16:219] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:16:228] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:228] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:232] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:237] [sx126x] writing (size: 36).␊
[11:34:16:241] [sx126x] netdev: set NETOPT_STATE_TX state␊
[11:34:16:325] [sx126x] netdev: SX126X_IRQ_TX_DONE␊
[11:34:16:325] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:16:336] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:16:336] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:16:344] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:344] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:352] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:352] [sx126x] writing (size: 36).␊
[11:34:16:361] [sx126x] netdev: set NETOPT_STATE_TX state␊
[11:34:16:441] [sx126x] netdev: SX126X_IRQ_TX_DONE␊
[11:34:16:441] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:16:445] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:16:449] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:21:240] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:21:250] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:21:250] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:21:262] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:21:262] [sx126x] writing (size: 36).␊
[11:34:21:262] [sx126x] netdev: set NETOPT_STATE_TX state␊
[11:34:21:346] [sx126x] netdev: SX126X_IRQ_TX_DONE␊
[11:34:21:346] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:21:371] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:21:371] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:21:390] [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊
[11:34:21:407] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊
[11:34:21:467] [sx126x] netdev: SX126X_IRQ_RX_DONE␊
[11:34:21:467] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:21:475] [sx126x] netdev: read received data.␊
[11:34:21:475] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:21:483] 12 bytes from fe80::dcee:6850:84e:9405%6: icmp_seq=2 ttl=64 rssi=49 dBm time=240.192 ms␊
[11:34:25:980] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:25:989] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:25:989] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:25:994] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:25:998] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:26:002] [sx126x] writing (size: 43).␊
[11:34:26:005] [sx126x] netdev: set NETOPT_STATE_TX state␊
[11:34:26:100] [sx126x] netdev: SX126X_IRQ_TX_DONE␊
[11:34:26:100] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:26:118] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:26:118] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:26:240] ␊
[11:34:26:240] --- fe80::dcee:6850:84e:9405%6 PING statistics ---␊
[11:34:26:256] 3 packets transmitted, 1 packets received, 66% packet loss␊
[11:34:26:256] round-trip min/avg/max = 240.192/240.192/240.192 ms␊
[11:34:26:256] > [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊
[11:34:26:762] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊
[11:34:26:832] [sx126x] netdev: SX126X_IRQ_RX_DONE␊
[11:34:26:832] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:26:850] [sx126x] netdev: read received data.␊
[11:34:26:850] [sx126x] netdev: set NETOPT_STATE_RX state␊
Receiver's log
[11:34:16:249] [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊
[11:34:16:266] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊
[11:34:16:326] [sx126x] netdev: SX126X_IRQ_RX_DONE␊
[11:34:16:326] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:16:334] [sx126x] netdev: read received data.␊
[11:34:16:338] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:16:338] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:16:348] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:348] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:355] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:16:361] [sx126x] writing (size: 36).␊
[11:34:16:361] [sx126x] netdev: set NETOPT_STATE_TX state␊
[11:34:16:444] [sx126x] netdev: SX126X_IRQ_TX_DONE␊
[11:34:16:444] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:16:449] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:16:453] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:21:270] [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊
[11:34:21:288] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊
[11:34:21:348] [sx126x] netdev: SX126X_IRQ_RX_DONE␊
[11:34:21:348] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:21:369] [sx126x] netdev: read received data.␊
[11:34:21:369] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:21:369] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:21:387] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:21:387] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:21:387] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:21:387] [sx126x] writing (size: 36).␊
[11:34:21:387] [sx126x] netdev: set NETOPT_STATE_TX state␊
[11:34:21:466] [sx126x] netdev: SX126X_IRQ_TX_DONE␊
[11:34:21:466] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:21:471] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:21:477] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:26:013] [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊
[11:34:26:031] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊
[11:34:26:101] [sx126x] netdev: SX126X_IRQ_RX_DONE␊
[11:34:26:101] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:26:119] [sx126x] netdev: read received data.␊
[11:34:26:119] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:26:710] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:26:724] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:26:724] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:26:724] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:26:742] [sx126x] netdev: send: wrote data to payload buffer.␊
[11:34:26:742] [sx126x] writing (size: 43).␊
[11:34:26:742] [sx126x] netdev: set NETOPT_STATE_TX state␊
[11:34:26:831] [sx126x] netdev: SX126X_IRQ_TX_DONE␊
[11:34:26:831] [sx126x] netdev: set NETOPT_STATE_RX state␊
[11:34:26:849] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[11:34:26:849] [sx126x] netdev: set NETOPT_STATE_RX state␊

So, I’m not sure, where the problem is : in “ping” or in my implementation of ieee802154 driver. I’m very glad to see your, @jia200x, suggestions.

sx126x_radio_hal.c

Probably have I an issue in switching TX-RX-Standby modes?

UPD: ping from gnrc_border_router to gnrc_networking gives 0% packet losses, but 100% losses conversely

1 Like

Hi @HoCoK

Could you check whether disabling retransmissions improve packet reception?

ifconfig <if> -ack_req

If so, the problem might be related to the ACK timeout (which can be configured later).

Otherwise, could you test the device with "tests/ieee802154_hal’ ? That should reveal if the problem lies on the driver or the upper layers.

Ok, I’ll check it tomorrow and give you a feedback.

Hmm, this test has many useful functions for testing! I’ll definitely try it!

Thanks

Hello, @jia200x

“-ack_req” changes nothing in packet reception, I have about 1% losses on 1000 packets (5-10) in close proximity (+22 dbm). Porting of ieee802154_hal test is in process.

Problem with ping to border_router solved, It was a wrong base address.

Hello!

I have some questions about 6LoWPAN, I think I don’t understand how it should works.

I would be really happy, if you help me in it.

  1. How can I create a 6LoWPAN network? Should I do more than written in “readme” for gnrc_border_router? Should I add something in 6ctx?
gnrc_border_router ifconfig
Iface  6  HWaddr: 6E:A9:25:4A:AD:B6 
          L2-PDU:1500  MTU:1500  HL:64  RTR  
          Source address length: 6
          Link type: wired
          inet6 addr: fe80::6ca9:25ff:fe4a:adb6  scope: link  VAL
          inet6 addr: fe80::2  scope: link  VAL
          inet6 group: ff02::2
          inet6 group: ff02::1
          inet6 group: ff02::1:ff4a:adb6
          inet6 group: ff02::1:ff00:2
          
Iface  7  HWaddr: 14:05  Channel: 26  NID: 0x23  PHY: O-QPSK 
          Long HWaddr: DE:EE:68:50:08:4E:94:05 
           State: IDLE 
          ACK_REQ  L2-PDU:102  MTU:1280  HL:64  RTR  
          RTR_ADV  6LO  IPHC  
          Source address length: 8
          Link type: wireless
          inet6 addr: fe80::dcee:6850:84e:9405  scope: link  VAL
          inet6 addr: bbb

b::dcee:6850:84e:9405  scope: global  VAL
          inet6 group: ff02::2
          inet6 group: ff02::1
          inet6 group: ff02::1:ff4e:9405
          inet6 group: ff02::1a
gnrc_networking ifconfig
[15:50:32:760] Iface  7  HWaddr: 24:2B  Channel: 26  NID: 0x23  PHY: O-QPSK ␊
[15:50:32:764]           Long HWaddr: A6:DE:12:64:DA:C5:A4:2B ␊
[15:50:32:767]            State: IDLE ␊
[15:50:32:772]           ACK_REQ  L2-PDU:102  MTU:1280  HL:64  RTR  ␊
[15:50:32:775]           RTR_ADV  6LO  IPHC  ␊
[15:50:32:778]           Source address length: 8␊
[15:50:32:781]           Link type: wireless␊
[15:50:32:786]           inet6 addr: fe80::a4de:1264:dac5:a42b  scope: link  VAL␊
[15:50:32:792]           inet6 addr: bbbb::a4de:1264:dac5:a42b  scope: global  VAL␊
[15:50:32:805]           inet6 group: ff02::2␊
[15:50:32:805]           inet6 group: ff02::1␊
[15:50:32:805]           inet6 group: ff02::1:ffc5:a42b␊
[15:50:32:805]           inet6 group: ff02::1a␊
[15:50:32:805]           ␊
[15:50:32:812]           Statistics for Layer 2␊
[15:50:32:812]             RX packets 14  bytes 951␊
[15:50:32:820]             TX packets 191 (Multicast: 143)  bytes 0␊
[15:50:32:820]             TX succeeded 22 errors 0␊
[15:50:32:834]           Statistics for IPv6␊
[15:50:32:834]             RX packets 13  bytes 1164␊

[15:50:32:834] TX packets 22 (Multicast: 14) bytes 1856␊ [15:50:32:834] TX succeeded 22 errors 0␊

UDP Transmission
[15:59:12:353] > PKTDUMP: data received:␊
[15:59:21:414] ~~ SNIP  0 - size:   5 byte, type: NETTYPE_UNDEF (0)␊
[15:59:21:414] 00000000  72  6F  72  6F  0A␊
[15:59:21:414] ~~ SNIP  1 - size:   8 byte, type: NETTYPE_UDP (4)␊
[15:59:21:414]    src-port: 45596  dst-port:  8800␊
[15:59:21:414]    length: 13  cksum: 0xafe9␊
[15:59:21:414] ~~ SNIP  2 - size:  40 byte, type: NETTYPE_IPV6 (2)␊
[15:59:21:414] traffic class: 0x00 (ECN: 0x0, DSCP: 0x00)␊
[15:59:21:414] flow label: 0x68b86␊
[15:59:21:446] length: 13  next header: 17  hop limit: 63␊
[15:59:21:446] source address: fd00:dead:beef::1␊
[15:59:21:446] destination address: bbbb::a4de:1264:dac5:a42b␊
[15:59:21:446] ~~ SNIP  3 - size:  24 byte, type: NETTYPE_NETIF (-1)␊
[15:59:21:446] if_pid: 7  rssi: 58  lqi: 255␊
[15:59:21:446] flags: 0x0␊
[15:59:21:446] src_l2addr: DE:EE:68:50:08:4E:94:05␊
[15:59:21:446] dst_l2addr: A6:DE:12:64:DA:C5:A4:2B␊
[15:59:21:446] ~~ PKT    -  4 snips, total size:  77 byte␊
6ctx
[16:04:37:893] cid|prefix                                     |C|ltime␊
[16:04:37:893] -----------------------------------------------------------␊
[16:04:37:905]   0|                                 bbbb::/64 |1|  599min␊

Hi @HoCoK

In general the GNRC Border Router should be enough for a 6LowPAN network, but the right answer depends on what do you envision as a 6LowPAN network. E.g are you considering a mesh or star topology? how does your use case look like?

EDIT: I see from the initial post that you want to build a mesh network, but is it peer-to-peer? cluster-tree? E.g do you need routing on intermediate nodes?

Yes, @jia200x Transmission between nodes is very desirable. Peer-to-peer model is preferable for my case.

Hi, @jia200x I have run the ieee802154_hal and ieee802154_submac tests. So, I saw some interesting things:

  1. -ack-req has no effect because I had IEEE802154_CAP_IRQ_ACK_TIMEOUT in caps. When I commented it, module had started to wait the ACK frame a couple of ms after transmiting. If it no receive (because ACK frame doesn’t form after receiving), transmitter sent a data packet again 4 times. So, I have some questions:

    • What should I do to enable forming the ACK frame in SubMAC? As said here SubMAC has implementation for CSMA-CA and frame retransmission if radio device is not support it (as I understand).

    • It is not clear for me, what should do ifconfig commands like -6lo, -iphc. E.g. -6lo gives me “error: unable to set option”. Does it mean that 6LowPAN doesn’t work because I don’t have implementation for important function.

Some debug information from tests/ieee802154_hal:

caps
[15:06:44:231] > caps␍␊
[15:06:49:158]                CAPS              ␊
[15:06:49:158] =================================␊
[15:06:49:158] - Frame Retransmissions:        n␊
[15:06:49:158]     * Info retries:             n␊
[15:06:49:158] - Auto CSMA-CA:                 n␊
[15:06:49:158] - 2.4 GHz band:                 y␊
[15:06:49:158] - SubGHz band:                  n␊
[15:06:49:158] - TX DONE indication:           y␊
[15:06:49:191]     * ACK Timeout indication:   n␊
[15:06:49:191] - RX_START indication:          y␊
[15:06:49:191] - CCA Done indication:          y␊
[15:06:49:191] - PHY modes:                      ␊
[15:06:49:191] -   * BPSK:                     n␊
[15:06:49:191] -   * ASK:                      n␊
[15:06:49:191] -   * O-QPSK:                   n␊
[15:06:49:191] -   * MR-O-QPSK:                y␊
[15:06:49:191] -   * MR-OFDM:                  n␊
[15:06:49:191] -   * MR-FSK:                   n␊
txtsnd hal
txtsnd A6:DE:12:64:DA:C5:B4:2B 10␍␊

[15:08:05:476] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:08:05:481] [sx126x] netdev: send: wrote data to payload buffer.␊

[15:08:05:485] [sx126x] netdev: send: wrote data to payload buffer.␊

[15:08:05:494] [sx126x] writing (size: 31).␊

[15:08:05:494] IEEE802154_HAL: ACK_ONLY␊

[15:08:05:494] [sx126x] netdev: set NETOPT_STATE_TX state␊

[15:08:05:569] [sx126x] netdev: SX126X_IRQ_TX_DONE␊

[15:08:05:573] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:08:05:573] [sx126x] netdev: set NETOPT_STATE_RX state␊

[15:08:05:578] ␊

[15:08:05:578] ␊

[15:08:05:578] > IEEE802154_HAL: FILTER_ACCEPT␊
receive packet hal
[15:07:50:295] > [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊
[15:08:05:504] [sx126x] netdev: SX126X_IRQ_NONE␊
[15:08:05:533] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊
[15:08:05:533] [sx126x] netdev: SX126X_IRQ_NONE␊
[15:08:05:570] [sx126x] netdev: SX126X_IRQ_RX_DONE␊
[15:08:05:578] [sx126x] netdev: SX126X_IRQ_NONE␊
[15:08:05:578] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊
[15:08:05:591] [sx126x] netdev: read received data.␊
[15:08:05:591] Frame received:␊
[15:08:05:600] 00000000  41  DC  00  23  00  2B  B4  C5  DA  64  12  DE  A6  05  84  4E␊
[15:08:05:600] 00000010  08  50  68  EE  DE  4C  6F  72  65  6D  20  69  70  73  75␊
[15:08:05:600] LQI: 255, RSSI: 220␊

And tests/ieee802154_submac:

txtsnd
[15:14:21:556] txtsnd A6:DE:12:64:DA:C5:B4:2B 10␍␊

[15:14:21:560] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:21:565] [sx126x] netdev: send: wrote data to payload buffer.␊

[15:14:21:569] [sx126x] netdev: send: wrote data to payload buffer.␊

[15:14:21:573] [sx126x] writing (size: 31).␊

[15:14:21:573] > [sx126x] netdev: set NETOPT_STATE_TX state␊

[15:14:21:660] [sx126x] netdev: SX126X_IRQ_TX_DONE␊

[15:14:21:660] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:660] IEEE802154_HAL: ACK_ONLY␊

[15:14:21:660] [sx126x] netdev: set NETOPT_STATE_RX state␊

[15:14:21:668] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:21:674] [sx126x] netdev: set NETOPT_STATE_TX state␊

[15:14:21:755] [sx126x] netdev: SX126X_IRQ_TX_DONE␊

[15:14:21:755] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:755] IEEE802154_HAL: ACK_ONLY␊

[15:14:21:755] [sx126x] netdev: set NETOPT_STATE_RX state␊

[15:14:21:760] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:21:769] [sx126x] netdev: set NETOPT_STATE_TX state␊

[15:14:21:844] [sx126x] netdev: SX126X_IRQ_TX_DONE␊

[15:14:21:854] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:854] IEEE802154_HAL: ACK_ONLY␊

[15:14:21:854] [sx126x] netdev: set NETOPT_STATE_RX state␊

[15:14:21:880] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:21:880] [sx126x] netdev: set NETOPT_STATE_TX state␊

[15:14:21:950] [sx126x] netdev: SX126X_IRQ_TX_DONE␊

[15:14:21:950] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:950] IEEE802154_HAL: ACK_ONLY␊

[15:14:21:950] [sx126x] netdev: set NETOPT_STATE_RX state␊

[15:14:21:968] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:21:968] [sx126x] netdev: set NETOPT_STATE_TX state␊

[15:14:22:035] [sx126x] netdev: SX126X_IRQ_TX_DONE␊

[15:14:22:049] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:22:049] IEEE802154_HAL: ACK_ONLY␊

[15:14:22:049] [sx126x] netdev: set NETOPT_STATE_RX state␊

[15:14:22:064] IEEE802154_HAL: FILTER_ACCEPT␊

[15:14:22:064] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:22:064] No ACK␊

[15:14:22:064] [sx126x] netdev: set NETOPT_STATE_RX state␊
receive packet
[15:14:17:499] > [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊

[15:14:21:586] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:604] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊

[15:14:21:604] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:660] [sx126x] netdev: SX126X_IRQ_RX_DONE␊

[15:14:21:660] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:660] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:21:670] ␊

[15:14:21:670] [sx126x] netdev: read received data.␊

[15:14:21:670] DATA␊

[15:14:21:670] Dest. PAN: 0x0023, Dest. addr.: a6:de:12:64:da:c5:b4:2b␊

[15:14:21:680] Src. PAN: 0x0023, Src. addr.: de:ee:68:50:08:4e:84:05␊

[15:14:21:680] Security: 0, Frame pend.: 0, ACK req.: 1, PAN comp.: 1␊

[15:14:21:680] Version: 1, Seq.: 0␊

[15:14:21:699] 00000000 4C 6F 72 65 6D 20 69 70 73 75␊

[15:14:21:699] txt (10 chars): Lorem ipsu␊

[15:14:21:699] RSSI: 225, LQI: 255␊

[15:14:21:699] ␊

[15:14:21:699] [sx126x] netdev: set NETOPT_STATE_RX state␊

[15:14:21:779] [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊

[15:14:21:779] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:797] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊

[15:14:21:797] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:845] [sx126x] netdev: SX126X_IRQ_RX_DONE␊

[15:14:21:858] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:858] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:21:858] ␊

[15:14:21:858] [sx126x] netdev: read received data.␊

[15:14:21:858] DATA␊

[15:14:21:879] Dest. PAN: 0x0023, Dest. addr.: a6:de:12:64:da:c5:b4:2b␊

[15:14:21:879] Src. PAN: 0x0023, Src. addr.: de:ee:68:50:08:4e:84:05␊

[15:14:21:879] Security: 0, Frame pend.: 0, ACK req.: 1, PAN comp.: 1␊

[15:14:21:879] Version: 1, Seq.: 0␊

[15:14:21:887] 00000000 4C 6F 72 65 6D 20 69 70 73 75␊

[15:14:21:887] txt (10 chars): Lorem ipsu␊

[15:14:21:887] RSSI: 225, LQI: 255␊

[15:14:21:887] ␊

[15:14:21:887] [sx126x] netdev: set NETOPT_STATE_RX state␊

[15:14:21:970] [sx126x] netdev: SX126X_IRQ_PREAMBLE_DETECTED␊

[15:14:21:970] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:21:988] [sx126x] netdev: SX126X_IRQ_HEADER_VALID␊

[15:14:21:988] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:22:036] [sx126x] netdev: SX126X_IRQ_RX_DONE␊

[15:14:22:051] [sx126x] netdev: SX126X_IRQ_NONE␊

[15:14:22:051] [sx126x] netdev: set NETOPT_STATE_STANDBY state␊

[15:14:22:051] ␊

[15:14:22:051] [sx126x] netdev: read received data.␊

[15:14:22:051] DATA␊

[15:14:22:065] Dest. PAN: 0x0023, Dest. addr.: a6:de:12:64:da:c5:b4:2b␊

[15:14:22:065] Src. PAN: 0x0023, Src. addr.: de:ee:68:50:08:4e:84:05␊

[15:14:22:065] Security: 0, Frame pend.: 0, ACK req.: 1, PAN comp.: 1␊

[15:14:22:065] Version: 1, Seq.: 0␊

[15:14:22:076] 00000000 4C 6F 72 65 6D 20 69 70 73 75␊

[15:14:22:076] txt (10 chars): Lorem ipsu␊

[15:14:22:076] RSSI: 225, LQI: 255␊

[15:14:22:076] ␊

[15:14:22:076] [sx126x] netdev: set NETOPT_STATE_RX state␊

Probably I can’t see some obvious things but I would not like to despair and I really hope for your support.

Cheers, Klim

Hi,

Does your topology look like a cluster-tree? If so, probably RPL could do the trick. You could check e.g Release-Specs/07-multi-hop/example_test_guide.md at master · RIOT-OS/Release-Specs · GitHub

Ok, @jia200x I’ll try it. Probably this topology fits for me too. But do I get the header compression by 6LowPAN?

Hi @HoCoK

If IEEE802154_CAP_IRQ_ACK_TIMEOUT is not declared, the SubMAC will automatically attempt to transmit an ACK frame if ack_req is set. I suspect you did not update the ACK timeout. For O-QPSK radios (IEEE 802.15.4 @ 2.4 GHz) this value is 864 (54 O-QPSK symbols). You probably want to keep it 54 symbols long, but you should update the timeout to the symbol time of LoRa. This depends on the spreading factor and bandwidth (sym_time_us = (2^SF/BW)*1000000). For SF7 and BW125, you would set it to around 54000 us.

For the other commands, they are independent of the radio implementation and the failures are mostly related to missing dependencies. In general, 6LowPAN will be there out of the box if you use examples/gnrc_networking or similar. The network stack will configure everything automatically based on the device type (which is already declared by the netdev_ieee802154_submac). If you are using that example (gnrc_networking), it’s likely you are already using 6LowPAN.