Radio Driver


Radio Driver

IEEE802.15.4e very closely interacts with the radio driver. This IEEE802.15.4e-specific driver is a bit different from traditional radio drivers. This pages explains what those differences are.

In the OpenWSN stack, the radio driver is implemented in

You can see the Doxygen HTML output of the inline comments at:

No radio state machine

The difference between the radio driver and the MAC layer is always blurry, and the IEEE802.15.4e is no exception.

In the OpenWSN implementation, the radio driver does not enforce any state machine. It's IEEE802.15.4e which calls the radio driver functions in an order that makes sense. radio.c does contain a state variable, which it is only used for debugging.

Two-step transmit/received

In a traditional radio driver, when you ask it to send a packet, it will do all the housekeeping in one go: configure the channel, load the packet, enable the PLL and transmit. The problem is that each steps can take different amount of time depending on e.g. the length of the packet.

In IEEE802.15.4e we need to SFD of the packet to leave the radio exactly TsTxOffset after the beginning of the slot. We therefore transmit a packet in two steps:

  1. ti3 in the state machine:
    a. configure the frequency
    a. load the packet
    a. enable the PLL
  2. ti4 in the state machine:
    s. transmit

These steps are started by the IEEE802.15.4e state machine. The timing constraints are:

  • step 1 needs to be finished when step 2 is to start (hence the maxTxDataPrepare duration)
  • step 2 needs to be timed such that the SFD of the packet leaves the radio exactly TsTxOffset into the slot.

All radios require some time to between the 'Go' signal and the instant the SFD leave the antenna. We call this delayTx; step 2 is hence started TsTxOffset-delayTx into the slot.

We use this same 2-step approach when transmitting and receiving.