« Previous - Version 7/16 (diff) - Next » - Current version
Anthony Rowe, 03/04/2007 08:19 pm

= BMAC =

BMAC is a low-power listen CSMA (lpl-csma) protocol. More information can be found in the original [http://www.polastre.com/papers/sensys04-bmac.pdf BMAC paper]. The main idea about low-power-listen CSMA is that instead of leaving the receiver on 100% the radio is active for short bursts used to check for channel activity. If activity is detected, the radio remains on in order to receive the data. In order to ensure that a neighboring node receives the message, an extended preamble the length of the check interval is required.


There is a trade-off between checking more often or sending a longer preamble. For any particular sampling point (sensor sampling rate etc) there is an energy optimal checking rate.


Using the optimal radio checking rate derived from the best energy efficiency at a particular sampling point you can see the following life-time relationship.


The current Nano-RK implementation of BMAC has no internal transmit or receive buffers. Applications or higher level network layers must provide their own transmit and receive buffers. BMAC will pass transmit buffers directly to the basic_rf transmit functions where additional information like a CRC checksum is added. When data is received, BMAC will store this data in the last set receive buffer until the bmac_rx_release() function is called by a higher layer or application. The reception of a packet will generate a signal notifying any waiting tasks that the packet is ready. Received packets can be checked in a polling fashion using the bmac_rx_status() function, or a task can suspend until a packet arrives using the bmac_rx_packet_get() function. Timeouts on packet reception can be achieved using the wait until next wakeup configuration commands provided by Nano-RK. If a timeout occurs, bmac_wait_until_rx_packet() will return an error code. To allow efficient network layer development, the receive buffer can be changed using the bmac_rx_pkt_set_buffer() function. This should only be done after a packet is received or at startup. If a new receive buffer pointer has been set, it is then safe to call bmac_rx_pkt_release() indicating that the BMAC task is allowed to buffer new packets at that memory location.

The application or network layer is required to allocate static buffers:

uint8_t tx_buf[RF_MAX_PAYLOAD_SIZE];
uint8_t rx_buf[RF_MAX_PAYLOAD_SIZE];

Here is a sample of how you initialize BMAC and receive data (found in the basic_bmac sample project):

{{{ {
uint8_t i,len;
int8_t rssi,val;
uint8_t *local_rx_buf;

printf( "rx_task PID=%d\r\n",nrk_get_pid());
// init bmac on channel 25 
// This sets the next RX buffer.
// This can be called at anytime before releaseing the packet
// if you wish to do a zero-copy buffer switch
// Wait until an RX packet is received
// Get the RX packet
printf( "Got RX packet len=%d RSSI=%d [",len,rssi );
for(i=0; i<len; i++ )
printf( "%c", local_rx_buf[i]);
printf( "]\r\n" );
// Release the RX buffer so future packets can arrive


chk_vs_life.png (62.1 kB) Anthony Rowe, 03/04/2007 08:03 pm

chk_vs_sample.png (42.4 kB) Anthony Rowe, 03/04/2007 08:03 pm

rx_tx.png (13 kB) Anthony Rowe, 03/05/2007 03:15 pm