Simple duty cycling 802.15.4 MAC protocol#3730
Simple duty cycling 802.15.4 MAC protocol#3730daniel-k wants to merge 25 commits intoRIOT-OS:masterfrom
Conversation
|
Wooohooo, I'm excited and eager to test! |
boards/samr21-xpro/Makefile.dep
Outdated
There was a problem hiding this comment.
IMO we should discuss on the mailing list or in the next meeting what we want to configure as the default MAC.
There was a problem hiding this comment.
This is not meant to be merged as-is. There is intentionally a separate commit that replaces nomac and eases testing. Since there has only been one MAC layer, I didn't know how to integrate it properly, so I just replaced it.
|
Can we make this independent from gnrc? |
There was a problem hiding this comment.
I think you should sort out debugging messages from logging messages here.
There was a problem hiding this comment.
Off course. I don't like that I made my own logging/debugging macros either. All debug messages will need a review when this is ready to be merged. For the time being these will stay as-is.
I do think so. It only relies on netdev, netapi, netconf and timer interfaces and uses |
e25303f to
430761b
Compare
9e03c4c to
7a7862c
Compare
Lwmac for update
|
Feature freeze and still WIP -> postponed (but I hope to have it in soonish). |
|
Hi, @daniel-k, could you please rebase Lw-MAC on the new master branch? I have recently built and merged a After rebasing on master, I will help to apply those new features to Lw-MAC, by pushing adaptation PRs to Lw-MAC. :-) |
|
Hi @zhuoshuguo, will do but it may still take some days, depending on how extensive the rebasing will be. Thanks for already merging some parts :) |
|
@daniel-k Thanks! |
|
Splitting PRs by functionality is always a good idea, so 👍 |
|
Those things were never meant to be merged together with LwMAC, that's for example why there's an explicit merge commit. Let's go through them one by one:
So in the end, there's nothing that should be splitted out of the PR. Any comments? |
but it could be merged as a follow-up. |
|
@daniel-k Thanks, much more clear to me now. :-) |
|
So, what exactly is missing? |
|
I just tried rebasing this onto the current master branch, but it looks like power management has sufficiently changed over time and seems incompatible to my current approach now Any hints what has happened to |
|
@haukepetersen, @kaspar030, can you take a look? |
|
Ping~ |
|
@haukepetersen @kaspar030 ping? But also due to feature freeze we need to postpone :(. |
|
I can't really say much about the MAC layer stuff, but this PR seems to contain some unrelated items:
|
No doubt and already discussed. The ping was more into the direction of:
If the power management has changed as much as it looked like on the first sight, I won't have the time to adapt the PR in the near future. Sorry, much to busy times at the moment :( |
|
Hi, @daniel-k, to push Lw-MAC forward immediately, do you mind that I totally take over it? |
|
Hi @zhuoshuguo, that would be totally fine! Sorry that I cannot spend time on this currently. Feel free to take it over, I thought that I would have proposed this already. |
|
Closed in favor for #6554. |
I have developed a (not so) simple (anymore) duty cycling MAC protocol focused for IEEE 802.15.4 transceiver. It has the working title "LwMAC" which stands for "lightweight MAC", I really didn't have a better idea. This is still work-in-progress but has reached a point where maybe someone else might want to try it or comment on it's future development.
In the current state it behaves like the
LPEALPEASprotocol described in this paper (sorry, there doesn't seem to be a free source). This is quite similiar to ContikiMAC, but doesn't provide compatibility (yet).Later it's planned to add implicit synchronization with neighbor nodes, i.e. extent toDoneLPEAS.I created a quick overview of the overall structure. Maybe this helps to better understand all the moving parts. Yet there is no overview over the RX or TX state machines.
It still has bugs and TODOs, so I want to use this PR as my TODO list.
Currently this depends on
#3138#3619#3729#4078#3867#4081#2309Incorporates, but not critical:
#3993#3868#3887#4015#4058#3954TODOs
use gnrc pktqueueimplement broadcastverify duty cyclingimplement implicit syncHow to test
Currently you should use the
samr21-xproboard to test this, because certain features (see depending PRs) are only available on that platform. And it's the only I can test :-)Flash to board with the at86rf2xx driver test:
$ cd tests/driver_at86rf2xx $ BOARD=samr21-xpro make flash termThen manually send packet from one board to the other via interactive shell(
note: baudrate is 921600)or even as broadcast:
You can use a packet sniffer to verify the communication or just check if packets arrive at the destination by flashing the same test.