<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Jonas,<br>
      <br>
    </div>
    <blockquote cite="mid:5550B0CA.40406@phytec.de" type="cite">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.
      <br>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote cite="mid:5550B0CA.40406@phytec.de" type="cite">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.
      <br>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote cite="mid:5550B0CA.40406@phytec.de" type="cite">BTW: Is
      this also publicly availble somewhere?</blockquote>
    <br>
    I did a quick search and wasn't able to find it publicly :(<br>
    <br>
    <br>
    <blockquote cite="mid:5550B0CA.40406@phytec.de" type="cite"> 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.
      <br>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote cite="mid:5550B0CA.40406@phytec.de" type="cite">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.
      <br>
    </blockquote>
    <br>
    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<big>.</big><br>
    <br>
    Best regards,<br>
    Daniel<br>
  </body>
</html>