RIOT-OS
pkg/opendsme: add initial support for IEEE 802.15.4 DSME time-slotted MAC
Contribution description
This PR adds support for openDSME. DSME is a time-slotted MAC layer (similar to TSCH), which supports deterministic communication. It offers some promising features such as:
- Topology agnostic (peer-to-peer, star, mesh, etc).
- By design, it's possible to extend the network just adding more coordinators near the edge.
- Automatic resolution of beacon collision
- Transmission of frames using either CSMA-CA or multi-channel GTS (guaranteed time slot)
- Built-in slot negotiation
Similar to TSCH, such a MAC improves PRR drastically (with the cost of some latency) and enables low-power operation.
This work is still WIP, although the basic support is already running. This PR includes:
- Basic openDSME support as a pkg
- Implementation of GNRC interface for openDSME (IP support will be a follow up)
- An example application
~Some commits (labeled as "REMOVE_ME") will be handled in separate PRs~
Tested with nrf52840. The cc2538 needs a small change to remove the beacon filter.
Testing procedure
- Flash 2 boards (or more) with
examples/opendsme. - Choose one boards as the PAN coordinator and run:
ifconfig 3 pan_coord
ifconfig 3 up
ifconfig <--- Should display "Link: up" and show the short address.
- Join the DSME network in the shell of the other nodes. Wait a fraction of a second and get the status and address.
ifconfig 3 up
ifconfig <--- Should display "Link: up" and show the short address.
- Use the
gtsoption to enable GTS transmission (slotted). By default, the option is unset.
- Send data using CSMA-CA
ifconfig 3 -gts
txtsnd 3 <l2_addr> login
- Send data using GTS
ifconfig 3 gts
txtsnd 3 <l2_addr> login
Example session
PAN coordinator
2022-06-01 15:22:43,584 # main(): This is RIOT! (Version: 2022.07-devel-595-g61467b-pr/opendsme_v3)
ifconfig 3 pan_coord
2022-06-01 15:24:40,160 # ifconfig 3 pan_coord
2022-06-01 15:24:40,162 # success: set option
> ifconfig 3 up
2022-06-01 15:24:48,087 # ifconfig 3 up
2022-06-01 15:24:48,090 # This node is PAN coordinator
> 2022-06-01 15:25:23,347 # PKTDUMP: data received:
2022-06-01 15:25:23,352 # ~~ SNIP 0 - size: 12 byte, type: NETTYPE_NETIF (-1)
2022-06-01 15:25:23,355 # if_pid: 0 rssi: -32768 lqi: 0
2022-06-01 15:25:23,356 # flags: 0x0
2022-06-01 15:25:23,357 # src_l2addr: BD:3F
2022-06-01 15:25:23,359 # dst_l2addr: EB:82
2022-06-01 15:25:23,364 # ~~ SNIP 1 - size: 4 byte, type: NETTYPE_UNDEF (0)
2022-06-01 15:25:23,366 # 00000000 52 49 4F 54
2022-06-01 15:25:23,371 # ~~ SNIP 2 - size: 9 byte, type: NETTYPE_UNDEF (0)
2022-06-01 15:25:23,374 # 00000000 41 A8 39 23 00 82 EB 3F BD
2022-06-01 15:25:23,378 # ~~ PKT - 3 snips, total size: 25 byte
Child:
Welcome to pyterm!
Type '/exit' to exit.
ifconfig 3 up
2022-06-01 15:25:07,341 # ifconfig 3 up
> ifconfig
2022-06-01 15:25:09,228 # ifconfig
2022-06-01 15:25:09,232 # Iface 3 HWaddr: BD:3F Link: up
2022-06-01 15:25:09,234 # L2-PDU:127
2022-06-01 15:25:09,235 #
ifconfig 3 gts
2022-06-01 15:25:17,318 # ifconfig 3 gts
2022-06-01 15:25:17,319 # success: set option
txtsnd 3 EB:82 RIOT
2022-06-01 15:25:23,184 # txtsnd 3 EB:82 RIOT
>
Issues/PRs references
#15313 Depends on ~#18283, #18284~
Great PR! As discussed offline, many nits need cosmetics, e.g., get rid of magic numbers, do the todos, remove needless checks, add asserts consistently, split out unrelated changes... Furthermore, I think that the code would be even better to understand if 1. the filenames would be more descriptive (example: opendsme.cpp currently contains netif adaptation) and 2. there was a brief overview (documentation) of the openDSME OS abstraction interfaces. Otherwise, I flashed the example application on two nrf52840dk boards and successfully managed to send some packets with CAP and CFP as described above. Nice!
Not WIP anymore! But depends on https://github.com/RIOT-OS/RIOT/pull/18283 and https://github.com/RIOT-OS/RIOT/pull/18284
Could you go through the static checks' warnings (whitespace after comma etc)? They make the GitHub diffs hard to read.
Thanks for porting, I'm slowly familiarizing myself with it.
The IPv6 integration is working in another branch and we are already getting the benefits of time-slotted MACs:
ping fe80::ff:fe00:b6a4 -s 150 -c 100 -i 450
--- fe80::ff:fe00:b6a4 PING statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 258.788/320.860/439.592 ms
Therefore, it would be awesome if we could get this one in first and then add the IPv6 support.
Building the example, I get a lot of warnings a la
/home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/.././associationManager/../../mac_services/mlme_sap/./../../dsmeLayer/messages/GTSReplyNotifyCmd.h:72:84: warning: implicitly-declared 'dsme::DSMESABSpecification::DSMESABSpecification(const dsme::DSMESABSpecification&)' is deprecated [-Wdeprecated-copy]
72 | : destinationAddress(destinationAddress), channelOffset(0), SABSpec(SABSpec) {
| ^
In file included from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/./ACTUpdater.h:48,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/ACTUpdater.cc:43:
/home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/./../../mac_services/dataStructures/DSMESABSpecification.h:90:27: note: because 'dsme::DSMESABSpecification' has user-provided 'dsme::DSMESABSpecification& dsme::DSMESABSpecification::operator=(const dsme::DSMESABSpecification&)'
90 | DSMESABSpecification& operator=(const DSMESABSpecification& other) {
| ^~~~~~~~
In file included from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/.././associationManager/../../mac_services/mlme_sap/./DSME_GTS.h:48,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/.././associationManager/../../mac_services/mlme_sap/MLME_SAP.h:50,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/.././associationManager/AssociationManager.h:51,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/../DSMELayer.h:54,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/ACTUpdater.cc:48:
both when building in and outside docker. My C++-fu is weak; is this reason to worry, and/or should this be addressed "upstream"?
Trying to build a non-DSME example (gcoap) fails with
/data/riotbuild/riotbase/sys/net/gnrc/netif/init_devs/auto_init_nrf802154.c: In function 'auto_init_nrf802154':
/data/riotbuild/riotbase/sys/net/gnrc/netif/init_devs/auto_init_nrf802154.c:62:9: error: implicit declaration of function 'gnrc_netif_opendsme_create'; did you mean 'gnrc_netif_ieee802154_create'? [-Werror=implicit-function-declaration]
62 | gnrc_netif_opendsme_create(&_netif, _stack,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
| gnrc_netif_ieee802154_create
(Turning on "ready for build" now to flush any others of that kind out).
[edit: Disregard this section, see next comment]
On the master branch, the gcoap example on my microbit-v2 came up with:
2022-09-14 10:31:58,400 # Iface 6 HWaddr: 00:01 Channel: 26 NID: 0x23 PHY: O-QPSK
2022-09-14 10:31:58,404 # Long HWaddr: AA:A8:68:58:51:97:80:01
2022-09-14 10:31:58,407 # State: IDLE
[...]
i.e. there is a hardware address. When running the OpenDSME example, I see:
> ifconfig
2022-09-14 10:34:49,287 # ifconfig
2022-09-14 10:34:49,290 # Iface 3 HWaddr: FF:FF Link: down
2022-09-14 10:34:49,295 # Long HWaddr: FF:FF:FF:FF:FF:FF:FF:FF
2022-09-14 10:34:49,297 # L2-PDU:127
which looks like an uninitialized hardware address. Can anything even work with that?
Things crash after ifconfig up:
> ifconfig 3 pan_coord
ifconfig 3 pan_coord
success: set option
> ifconfig 3 up
ifconfig 3 up
>
Context before hardfault:
r0: 0x20001144
r1: 0x0000ffff
r2: 0x0000ffff
r3: 0x206823fd
r12: 0x00000000
lr: 0x00003447
pc: 0x206823fc
psr: 0x01000000
FSR/FAR:
CFSR: 0x00000100
HFSR: 0x40000000
DFSR: 0x00000000
AFSR: 0x00000000
Misc
EXC_RET: 0xffffffed
Active thread: 3 "nrf802154"
Attempting to reconstruct state for debugging...
In GDB:
set $pc=0x206823fc
frame 0
bt
ISR stack overflowed by at least 16 bytes.
*** RIOT kernel panic:
HARD FAULT HANDLER
pid | name | state Q | pri | stack ( used) ( free) | base addr | current
- | isr_stack | - - | - | 512 ( 488) ( 24) | 0x20000000 | 0x20001080
1 | main | bl mutex _ | 7 | 1536 ( 732) ( 804) | 0x200003d8 | 0x2000076c
2 | pktdump | bl rx _ | 6 | 1536 ( 240) ( 1296) | 0x20001374 | 0x20001884
3 | nrf802154 | running Q | 2 | 2048 ( 800) ( 1248) | 0x20000a70 | 0x200010ac
| SUM | | | 5632 ( 2260) ( 3372)
*** halted.
Inside isr -13
Following the instructions to get a backtrace takes several seconds per frame (whyever, that's OK), and shows:
(gdb) set $pc=0x206823fc
fra(gdb) frame 0
#0 0x206823fc in ?? ()
(gdb) bt
#0 0x206823fc in ?? ()
#1 0x00000b7c in print_ipsr () at /data/riotbuild/riotbase/cpu/cortexm_common/panic.c:33
#2 panic_arch () at /data/riotbuild/riotbase/cpu/cortexm_common/panic.c:41
#3 0x00000a28 in core_panic (crash_code=crash_code@entry=PANIC_HARD_FAULT,
message=message@entry=0x16165 "HARD FAULT HANDLER") at /data/riotbuild/riotbase/core/lib/panic.c:81
#4 0x00000f0a in hard_fault_handler (sp=0x16165, corrupted=9, exc_return=536878332,
r4_to_r11_stack=0x0 <cortex_vector_base>)
at /data/riotbuild/riotbase/cpu/cortexm_common/vectors_cortexm.c:454
#5 0x000037f2 in dsme::DSMEPlatform::getEmptyMessage (this=<optimized out>)
at /data/riotbuild/riotbase/pkg/opendsme/contrib/DSMEPlatform.cpp:502
#6 0x00008190 in dsme::BeaconManager::prepareEnhancedBeacon (nextSlotTime=<optimized out>,
this=0x0 <cortex_vector_base>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/beaconManager/BeaconManager.cc:180
#7 dsme::BeaconManager::prepareEnhancedBeacon (this=0x0 <cortex_vector_base>, nextSlotTime=<optimized out>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/beaconManager/BeaconManager.cc:178
#8 0x0000b66e in dsme::DSMELayer::preSlotEvent (this=0x20001cd8 <m_dsme+488>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/DSMELayer.cc:184
#9 0x0000b1e4 in dsme::TimerMultiplexer<dsme::EventTimers, dsme::DSMEEventDispatcher, dsme::IDSMEPlatform, dsme::IDSMEPlatform>::dispatchEvents (this=0x20001cec <m_dsme+508>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/././TimerMultiplexer.h:188
#10 dsme::TimerMultiplexer<dsme::EventTimers, dsme::DSMEEventDispatcher, dsme::IDSMEPlatform, dsme::IDSMEPlatform>::_timerInterrupt (this=0x20001cec <m_dsme+508>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/././TimerMultiplexer.h:103
#11 dsme::DSMEEventDispatcher::timerInterrupt (this=0x20001cec <m_dsme+508>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/DSMEEventDispatcher.cc:70
#12 0x00001738 in _process_events_await_msg (msg=<optimized out>, netif=<optimized out>)
at /data/riotbuild/riotbase/sys/net/gnrc/netif/gnrc_netif.c:1704
#13 _gnrc_netif_thread (args=<optimized out>) at /data/riotbuild/riotbase/sys/net/gnrc/netif/gnrc_netif.c:1872
#14 0x000006e8 in sched_switch (other_prio=15) at /data/riotbuild/riotbase/core/sched.c:298
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Disregard the "MAC address is uninitialized" comment -- when doing a (non-coordinator) ifconfig 3 up, a long HAWaddr and a HWaddr are assigned, so I guess it's just not showing / initialized before it's needed.
Thanks for the review!
/home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/.././associationManager/../../mac_services/mlme_sap/./../../dsmeLayer/messages/GTSReplyNotifyCmd.h:72:84: warning: implicitly-declared 'dsme::DSMESABSpecification::DSMESABSpecification(const dsme::DSMESABSpecification&)' is deprecated [-Wdeprecated-copy]
72 | : destinationAddress(destinationAddress), channelOffset(0), SABSpec(SABSpec) {
| ^
In file included from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/./ACTUpdater.h:48,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/ACTUpdater.cc:43:
/home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/./../../mac_services/dataStructures/DSMESABSpecification.h:90:27: note: because 'dsme::DSMESABSpecification' has user-provided 'dsme::DSMESABSpecification& dsme::DSMESABSpecification::operator=(const dsme::DSMESABSpecification&)'
90 | DSMESABSpecification& operator=(const DSMESABSpecification& other) {
| ^~~~~~~~
In file included from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/.././associationManager/../../mac_services/mlme_sap/./DSME_GTS.h:48,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/.././associationManager/../../mac_services/mlme_sap/MLME_SAP.h:50,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/.././associationManager/AssociationManager.h:51,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/../DSMELayer.h:54,
from /home/chrysn/git/RIOT/build/pkg/opendsme/dsmeLayer/gtsManager/ACTUpdater.cc:48:
I also get these warnings. They are present in the original package, so it should be fixed "upstream" (we are the upstream now, so I guess we should fix it).
Trying to build a non-DSME example (gcoap) fails with
Hmmm, it seems I messed up the dependencies. I will fix it
i.e. there is a hardware address. When running the OpenDSME example, I see:
This is "expected", as "ifconfig up" starts openDSME. As soon as you hit "ifconfig up" (and set the right role), you should be able to see addresses.
Things crash after ifconfig up:
Could you try increasing the ISR stack? CFLAGS += -DISR_STACKSIZE=1024
Could you try increasing the ISR stack?
Still crashes, just without the "ISR stack overflowed by at least 16 bytes." message.
New crash view
> ifconfig 3 pan_coord
ifconfig 3 pan_coord
success: set option
> ifconfig 3 up
ifconfig 3 up
>
Context before hardfault:
r0: 0x20001744
r1: 0x0000ffff
r2: 0x0000ffff
r3: 0x206823fd
r12: 0x00000000
lr: 0x00003447
pc: 0x206823fc
psr: 0x01000000
FSR/FAR:
CFSR: 0x00000100
HFSR: 0x40000000
DFSR: 0x00000000
AFSR: 0x00000000
Misc
EXC_RET: 0xffffffed
Active thread: 3 "nrf802154"
Attempting to reconstruct state for debugging...
In GDB:
set $pc=0x206823fc
frame 0
bt
*** RIOT kernel panic:
HARD FAULT HANDLER
pid | name | state Q | pri | stack ( used) ( free) | base addr | current
- | isr_stack | - - | - | 2048 ( 488) ( 1560) | 0x20000000 | 0x20001680
1 | main | bl mutex _ | 7 | 1536 ( 668) ( 868) | 0x200009d8 | 0x20000d6c
2 | pktdump | bl rx _ | 6 | 1536 ( 240) ( 1296) | 0x20001974 | 0x20001e84
3 | nrf802154 | running Q | 2 | 2048 ( 800) ( 1248) | 0x20001070 | 0x200016ac
| SUM | | | 7168 ( 2196) ( 4972)
*** halted.
Inside isr -13
(gdb) set $pc=0x206823fc
fram(gdb) frame 0
#0 0x206823fc in ?? ()
(gdb) bt
#0 0x206823fc in ?? ()
#1 0x00000b7c in print_ipsr () at /data/riotbuild/riotbase/cpu/cortexm_common/panic.c:33
#2 panic_arch () at /data/riotbuild/riotbase/cpu/cortexm_common/panic.c:41
#3 0x00000a28 in core_panic (crash_code=crash_code@entry=PANIC_HARD_FAULT,
message=message@entry=0x16165 "HARD FAULT HANDLER") at /data/riotbuild/riotbase/core/lib/panic.c:81
#4 0x00000f0a in hard_fault_handler (sp=0x16165, corrupted=9, exc_return=536879868,
r4_to_r11_stack=0x0 <cortex_vector_base>)
at /data/riotbuild/riotbase/cpu/cortexm_common/vectors_cortexm.c:454
#5 0x000037f2 in dsme::DSMEPlatform::getEmptyMessage (this=<optimized out>)
at /data/riotbuild/riotbase/pkg/opendsme/contrib/DSMEPlatform.cpp:502
#6 0x00008190 in dsme::BeaconManager::prepareEnhancedBeacon (nextSlotTime=<optimized out>,
this=0x0 <cortex_vector_base>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/beaconManager/BeaconManager.cc:180
#7 dsme::BeaconManager::prepareEnhancedBeacon (this=0x0 <cortex_vector_base>, nextSlotTime=<optimized out>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/beaconManager/BeaconManager.cc:178
#8 0x0000b66e in dsme::DSMELayer::preSlotEvent (this=0x200022d8 <m_dsme+488>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/DSMELayer.cc:184
#9 0x0000b1e4 in dsme::TimerMultiplexer<dsme::EventTimers, dsme::DSMEEventDispatcher, dsme::IDSMEPlatform, dsme::IDSMEPlatform>::dispatchEvents (this=0x200022ec <m_dsme+508>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/././TimerMultiplexer.h:188
#10 dsme::TimerMultiplexer<dsme::EventTimers, dsme::DSMEEventDispatcher, dsme::IDSMEPlatform, dsme::IDSMEPlatform>::_timerInterrupt (this=0x200022ec <m_dsme+508>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/././TimerMultiplexer.h:103
#11 dsme::DSMEEventDispatcher::timerInterrupt (this=0x200022ec <m_dsme+508>)
at /data/riotbuild/riotbase/build/pkg/opendsme/dsmeLayer/DSMEEventDispatcher.cc:70
#12 0x00001738 in _process_events_await_msg (msg=<optimized out>, netif=<optimized out>)
at /data/riotbuild/riotbase/sys/net/gnrc/netif/gnrc_netif.c:1704
#13 _gnrc_netif_thread (args=<optimized out>) at /data/riotbuild/riotbase/sys/net/gnrc/netif/gnrc_netif.c:1872
#14 0x000006e8 in sched_switch (other_prio=15) at /data/riotbuild/riotbase/core/sched.c:298
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Still crashes, just without the "ISR stack overflowed by at least 16 bytes." message.
Hmmm I cannot reproduce the issue.
Which board are you using? microbit-v2? Are you still running the examples/opendsme?
Hmmm I cannot reproduce the issue.
Yes, microbit-v2 and examples/opendsme on the pr/opendsme_v3 branch. I can not reproduce it on the nrf52840dongle. I don't have any other candidate boards to bisect (it'll likely work on any other nrf52840, and it can't work on the thingy:52 as it has a nrf52832 that's Bluetooth only). We don't support any alternative boards to the microbit-v2 with the same nrf52833xxaa chip :-(
Yes, microbit-v2 and examples/opendsme on the pr/opendsme_v3 branch. I can not reproduce it on the nrf52840dongle. I don't have any other candidate boards to bisect (it'll likely work on any other nrf52840, and it can't work on the thingy:52 as it has a nrf52832 that's Bluetooth only). We don't support any alternative boards to the microbit-v2 with the same nrf52833xxaa chip :-(
This line seems to be failing: https://github.com/RIOT-OS/RIOT/pull/18156/files#diff-3ad5ba79d92843820777d46c4662c033bb268c56a4f0b254d7a39481222f512cR502
That's likely a stack corruption or not enough heap. But if the packet was NULL, it should have been caught by the DSME_ASSERT macro. Strange
I think only the "no-op" comments are still open. I addressed the others.
Of my comments, the "-contrib" and "can we test on ZEP" are open -- but if you want to create a point of having open points addressed to rebase, I'm OK with it if ben is. (Rebasing would also resolve some unrelated issues when testing on that branch that result from this having branched off master quite long ago).
I've started more tests, and with nrf52840dongle I don't get very far either:
> ifconfig
2022-09-20 16:53:11,563 # ifconfig
2022-09-20 16:53:11,565 # Iface 4 HWaddr: FF:FF Link: down
2022-09-20 16:53:11,567 # Long HWaddr: FF:FF:FF:FF:FF:FF:FF:FF
2022-09-20 16:53:11,568 # L2-PDU:127
2022-09-20 16:53:11,568 #
> ifconfig 4 pan_coord
2022-09-20 16:53:14,625 # ifconfig 4 pan_coord
2022-09-20 16:53:14,626 # success: set option
> ifconfig 4 up
2022-09-20 16:53:18,122 # ifconfig 4 up
> ifconfig
At this point the board appears to hang.
I've started more tests, and with nrf52840dongle I don't get very far either:
> ifconfig 2022-09-20 16:53:11,563 # ifconfig 2022-09-20 16:53:11,565 # Iface 4 HWaddr: FF:FF Link: down 2022-09-20 16:53:11,567 # Long HWaddr: FF:FF:FF:FF:FF:FF:FF:FF 2022-09-20 16:53:11,568 # L2-PDU:127 2022-09-20 16:53:11,568 # > ifconfig 4 pan_coord 2022-09-20 16:53:14,625 # ifconfig 4 pan_coord 2022-09-20 16:53:14,626 # success: set option > ifconfig 4 up 2022-09-20 16:53:18,122 # ifconfig 4 up > ifconfigAt this point the board appears to hang.
hmmmm quite strange, I couldn't reproduce it with an nrf52840dk. I will try again with the dongle
@chrysn I cannot reproduce the issue:
/home/jialamos/Development/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200"
Twisted not available, please install it if you want to use pyterm's JSON capabilities
2022-09-26 11:16:14,817 # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
2022-09-26 11:16:15,820 # main(): This is RIOT! (Version: 2022.10-devel-397-g7eb78-pr/opendsme_v3)
> ifconfig
2022-09-26 11:16:18,535 # ifconfig
2022-09-26 11:16:18,536 # Iface 4 HWaddr: FF:FF Link: down
2022-09-26 11:16:18,537 # Long HWaddr: FF:FF:FF:FF:FF:FF:FF:FF
2022-09-26 11:16:18,538 # L2-PDU:127
2022-09-26 11:16:18,538 #
> ifconfig 4 pan_coord
2022-09-26 11:16:21,402 # ifconfig 4 pan_coord
2022-09-26 11:16:21,403 # success: set option
> ifconfig 4 up
2022-09-26 11:16:23,970 # ifconfig 4 up
> ifconfig
2022-09-26 11:16:25,367 # ifconfig
2022-09-26 11:16:25,368 # Iface 4 HWaddr: 20:07 Link: up
2022-09-26 11:16:25,369 # Long HWaddr: BB:D4:4E:6B:01:46:20:07
2022-09-26 11:16:25,370 # L2-PDU:127
2022-09-26 11:16:25,370 #
> ifconfig
2022-09-26 11:16:53,051 # ifconfig
2022-09-26 11:16:53,052 # Iface 4 HWaddr: 20:07 Link: up
2022-09-26 11:16:53,053 # Long HWaddr: BB:D4:4E:6B:01:46:20:07
2022-09-26 11:16:53,053 # L2-PDU:127
2022-09-26 11:16:53,054 #
>
I'm using https://github.com/RIOT-OS/RIOT/pull/18156/commits/7eb78b7e4768bd74887129c795c19e5774f434e6
Tested with two nrf52840dongle:
- Joining/sync works.
-
txtsndworks in both directions (without changing anything, so sending in CAP?). -
ifconfig <if> gtsonly on one nide (coordinator) works. Is this intended? I thing it woulbd be great if we had a way to analyze the transmission period somehow easily. - Something is wrong with the rssi printed by the dump function. It indicates -32768.
Will try the static setup a bit later.
Not completely sure how "Static GTS allocation" is supposed to work. I have compiled CFLAGS=-DCONFIG_IEEE802154_DSME_STATIC_GTS=1 BOARD=nrf52840dongle make clean all flash and expected that txtsnd would not work right away (after joining). But it does. This motivates to have some test mode that indicate the utilized transmission resource.
Nevertheless, I cannot reproduce the issue reported by @chrysn. Just to double check, you are using examples/opendsme directly on this branch, or did you pull the changes to some other version?
@PeterKietzmann thanks for the testing!
txtsnd works in both directions (without changing anything, so sending in CAP?).
Yes, gts flag is disabled by default.
ifconfig
gts only on one nide (coordinator) works. Is this intended? I thing it woulbd be great if we had a way to analyze the transmission period somehow easily.
That means the coordinator will transmit on a GTS and the node will reply during on CAP. Therefore, it is expected to work. What do you mean with "analyze the transmission period somehow easily"?
Something is wrong with the rssi printed by the dump function. It indicates -32768.
I suspect I never copied the actual RSSI value into the GNRC Netif Header. I will give it a look.
Not completely sure how "Static GTS allocation" is supposed to work. I have compiled CFLAGS=-DCONFIG_IEEE802154_DSME_STATIC_GTS=1 BOARD=nrf52840dongle make clean all flash and expected that txtsnd would not work right away (after joining). But it does. This motivates to have some test mode that indicate the utilized transmission resource.
Did you run ifconfig 7 gts in both sides? If not, the devices will still transmit during CAP, regardless of how many allocated slots are there. I'm not sure if I implemented the NETOPT_GTS getter, but that can be used to know the current transmission pattern (CSMA-CA or GTS). I can probably add an extra NETOPT to copy the allocation structure to the upper layer (for testing purposes).
analyze the transmission period somehow easily
Some rx info (like rssi?) or at least a print option that indicates the transmission slot on which a packet was received.
That means the coordinator will transmit on a GTS and the node will reply during on CAP
Reply with what, L2 ACK?
Some rx info (like rssi?) or at least a print option that indicates the transmission slot on which a packet was received.
Yeah, that sounds like a good plan.
Reply with what, L2 ACK?
Sorry, I got confused with the DSME ping tests ^^. There's no ping packet back in examples/opendsme.
To update the answer, it will work in both directions: with txtsnd, the coordinator will transmit on a GTS and the child device on CAP with CSMA-CA
the coordinator will transmit on a GTS and the child device on CAP with CSMA-CA
Then what is the difference to dynamic slot allocation? I would have expected, that, with CONFIG_IEEE802154_DSME_STATIC_GTS=1 set, both parties would need to allocate the slot explicitly. Maybe the README could be a bit clearer about that.
Then what is the difference to dynamic slot allocation?
I was answering this comment:
fconfig gts only on one nide (coordinator) works. Is this intended? I thing it woulbd be great if we had a way to analyze the transmission period somehow easily.
This does not relate to the STATIC GTS configuration.
I would have expected, that, with CONFIG_IEEE802154_DSME_STATIC_GTS=1 set, both parties would need to allocate the slot explicitly. Maybe the README could be a bit clearer about that.
This is the current behavior in the example and what the README states. If you do not allocate GTS slots explicitly when using CONFIG_IEEE802154_DSME_STATIC_GTS=1, you cannot transmit messages during CFP.