Hi Jonas,
Better don´t look at [2] for now ;). Currently that PR is based on a deprecated proposal that does not poperly use the netdev interface. I hope I will have time for an update of this PR this week. Even if that is not what you are searching for, maybe it could be used to make this a base of an more advanced MAC layer. The intention of [2] is to provide an implementation of CSMA-mechanisms, random backoff-time when the channel is busy and acknowledge handling. Since this procedure is different for each driver (Hard-MAC vs. Soft-MAC) this [2] adaption MAC-layer will be necessary to avoid re-implementing in each radio-driver.
You're right that it's good idea to have some adaption layer on top of the device drivers that enables usage of hardware MAC mechanism s while providing a software approach for transceiver that don't support this. The question here is if it's possible to meet the tight timings. Need to investigate further.
We also made some research in this field. Since we want to use our sensor-nodes in combination with Linux, we came to the conclusion that a MAC layer accordingly to the IEEE 802.15.4 standard will fit most for us. The biggest benefit is the compatibility to all IEEE 802.15.4 devices. Also a high configurability (e.g. the beacon interval length) is a feature of this standard. There are some optional mechanisms like GTS that don´t have to be implemented in the first step. But I agree, there might be easier duty-cycling MAC-layers. Since the architecture of the network stack allows to choose different MAC layers there is no problem of having different ones.
I'm going to need a Linux-bridge, too. The packets my MAC protocol will send will also be 802.15.4-2006(?) compatible, but the channel access scheme will be different. So at least sniffing should be no problem. In the end I hope to be able to use my RIOT implementation on native for this bridge, but didn't look into further.
BTW: Is this also publicly availble somewhere?
I did a quick search and wasn't able to find it publicly :(
As I understand it, the routing protocol is located on top of any MAC protocol. The mechanisms of the MAC protocol will be transparent to the upper layers.
That's right. But at least multi-hop networks have some implications on the MAC scheme. Just wanted to state that this is not my first priority, because I don't want to deal with this for now.
For the sleeping periods we might have to use a low-power timer (mostly low speed clock oscillator, 32khz or so), since most 16Mhz oscillators consume to much energy for long sleeping periods.
Sure. That's why I started familiarizing with RIOT by implementing the RTT peripheral for the samr21-xpro. The RTC, at least on this board, might be the only peripheral that can run in every power mode and wake up the MCU.
Best regards, Daniel
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
