Feb 2007WSN Training: MICA2/z Radio Stack1 MoteWorks Radio Stack Objectives Background Radio Stack...

Feb 2007WSN Training: MICA2/z Radio Stack 1

MoteWorks Radio Stack

Objectives Background Radio Stack API MICA2 radio stack MICAz radio stack Configure radio stack at Compile

time Lab: Radio enable your Sensor

Applications and XSniffer GUI

WSN Training: MICA2/z Radio Stack 2 Feb 2007

Background

The Radio Stack provides a packet interface for single hop transmission.

Compared to the ISO modle, the Radio Stack consists of a subset of the Data Link Layer and the Physical Layer.

XMesh consists of the network layer and directly interfaces to the Radio Stack.

Physical

Data Link

NetworkXMesh

Radio Stack


Background

The main features of the Radio Stack include: Frame transmission / reception Error checking Address filtering Link Level acknowledgements Synchronization Multiplexing single radio between multiple application

users CSMA/CA (carrier sense multiple access / collision

avoidance) Platform support for Mica2 and derivatives (<1 GHz ISM) Platform support for MicaZ and derivatives (2.4 GHz

ISM)


Radio Stack API

Objectives Send interface Receive interface Addressing TOS_Msg Buffer Management AM Types


Send Interface

interface SendMsg { /** * Send a Message to address. * @param addresss desitantion address * @param length number of bytes of the .data field in msg that needs

to be transmitted * @param msg ptr to a TOS_Msg that holds the packet in the .data portion * @retrun result_t SUCCESS if packet queued for transmission */ command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg);

/** * Send complete * @param msg ptr to the TOS_Msg that was just sent * @param success was the packet sent successfully * @return result_t SUCCESS */ event result_t sendDone(TOS_MsgPtr msg, result_t success);}


Receive Interface

interface ReceiveMsg { /** * Packet Received * @param m ptr to the TOS_Msg that was just received * @return TOS_MsgPtr a fresh pointer to a buffer that is passed back */ event TOS_MsgPtr receive(TOS_MsgPtr m);}


Node Addressing

Every node in a network must have a unique address Analogous to an IP address Must be no longer than 16 bits Node 0 is conventionally used to denote the Base station Certain nodes address are special and should not be

assigned to a real node

Special Nodes Addresses TOS_UART_ADDR

Macro expands to 0x007F This address denotes the UART channel

TOS_BCAST_ADDR Macro expands to 0xFFFF This address denotes a broadcast over the radio

TOS_LOCAL_ADDRESS A variable which holds the node id assigned


TOS_Msg – a Data Structure That Encapsulates a Packet

TOS_Msg is a general data structure for representing packets in TinyOS.

TOS_Msg allocates space for a packet by holding a char array called data whose length is determined at compile time by the TOSH_DATA_LENGTH symbol. The length of this field must not be less that the longest packet in the application.

The only field in TOS_Msg that is writable by the user is the data array holding the packet. All other fields must not be modified by the user.

Fields in the extra section hold useful information such as packet rssi and crc.


TOS_Msg Mica2 (MoteWorks/tos/types/am.h)

#define TOSH_DATA_LENGTH 29

typedef struct TOS_Msg { uint16_t addr; uint8_t type; uint8_t group; uint8_t length; int8_t data[TOSH_DATA_LENGTH]; uint16_t crc; // CRC

//Extra uint16_t strength; // RSSI uint8_t ack; // link-level uint16_t time; uint8_t sendSecurityMode; uint8_t receiveSecurityMode; } TOS_Msg;

TransmittedTransmitted

Can be defined at compile time


Only field that user can

Modify.


Modify.


TOS_Msg MicaZ (MoteWorks/tos/platforms/micaz/am.h)

#define TOSH_DATA_LENGTH 29typedef struct TOS_Msg { uint8_t length; uint8_t fcfhi; uint8_t fcflo; uint8_t dsn; uint16_t destpan; uint16_t addr uint8_t type; uint8_t group; int8_t data[TOSH_DATA_LENGTH];

//Extra uint16_t strength; // RSSI uint8_t lqi; // LQI bool crc; // CRC on RCB uint8_t ack; // link-level uint16_t time; } TOS_Msg;

TransmittedTransmitted




Modify.


Modify.


Buffer Management

If buffers are need, it must be allocated by the user. Since TOS_Msg encapsulates a packet, buffers are declared in

units of TOS_Msgs Buffers are typically allocated at COMPILE time

When using the send and receive interface, buffer ownership alternates between application and messaging layers

Send message Active message (AM) layer “owns” the TX buffer once called User must NOT modify buffer until .sendDone event from AM

layerReceive event

AM layer passes a RX message buffer pointer User must return a valid “free” buffer pointer for the next

received message


Message Buffer Exchange

TX SideAM Component gets ownership of TXBuffer until Signals Transmission has completed

RX SideEvent Handler gets RXBuffer. Returns a buffer for next RX message.

TX Component

AM Component

AM Component

RX Event Handler

return (&RXBuffer)

Signal.Rcv(&RXBuffer)

.sendDone(&TXBuffer)

.send(&TXBuffer)


AM Layer (Motivation)

Network Level IsolationIt is often necessary to deploy multiple networks on the same physical radio channel. Even though these networks are sharing the same physical medium, they need to behave in software as if they are isolated from each other. This is done with GROUP ID.

Node Level Isolation Every node typically has only 1 radio. However each node will

need to run different services that needs to send and receive different packets. Each service doesn’t need to receive packets meant for other services. As a result, there needs to be a multiplexing mechanism similar to ports in the IP space which allows filtering packets to the intended receivers on a single node. This is accomplished with AM TYPE.


AM Protocol (outgoing)

RadioStack

AM 1

AM 2

The Send Interface providedby the radio stack has a parameter for the AM Type

AM n

...

Pack

etPa

cket Pa

cket

Pack

et

Once sent each packet is tagged With the AM type used to send it

AM 1 AM 2

To send a packet with a specific AM Type, theuser wires to a send Interface with the desiredAM Type as the parameter


AM Protocol (incoming)

RadioStack

On reception, packets are routed according to the tagged AM Type.

AM 1

AM 2

AM n

...

Pack

et

Pack

etPack

et

Pack

etAM 1 AM 2

Users that wire to theReceive interface with aspecific AM Type will besignaled when a packetof that AM Type is received.

Incoming packet will Always be tagged withan AM Type


GenericComm

configuration GenericComm {

provides { //Start and Stop the Radio Stack interface StdControl as Control;

// The interface are as parameterised by the active message id interface SendMsg[uint8_t id]; interface ReceiveMsg[uint8_t id];

.

.

.


TOS_MsgPtr received(TOS_MsgPtr packet){ uint16_t addr = TOS_LOCAL_ADDRESS; counter++; if (packet->crc == 1 &&

packet->group == TOS_AM_GROUP &&(packet->addr == TOS_BCAST_ADDR || packet->addr == addr)){ uint8_t type = packet->type; TOS_MsgPtr tmp; tmp = signal receiveMsg.receive[type](packet); if (tmp) packet = tmp;} // if valid packet

return packet;}

AMStandard: Receiving Messages

Check GroupID, Node Address

Check GroupID, Node Address

Signal the assigned AM Handler

Signal the assigned AM Handler

Use the returned buffer for next Msg

Use the returned buffer for next Msg


WARNING

The Radio Stack which includes the AM layer is used by the XMesh Networking Layer. Unless you understand how to share usage of the Radio Stack with XMesh you will break the system. Option for correct usage would be.

1. Only use XMesh APIs without touching the Radio Stack APIs

2. Only use Radio Stack APIs without using any XMesh services.


MICA2 Radio Stack

Objectives Radio Features Module Design Send/Recv Message Flow and Call Stack Basic State Machine Packet Structure


MICA2: CC1000 Radio

Byte Level Radio Radio accepts data byte by byte Packet information handled in software Frequency shift keying with Manchester encoding

Power On/Off Sleep current: ~2 A Frequency stable: 2 msec Radio Signal Strength (RSSI Valid): ~250 sec Receiver Packet Acquire Time: ~750 sec

SPI data port interrupt triggers every 8 bit times = 416 s While the radio is on, data streams in to the ATmega128L

at this rate


MICA2 Radio Stack in TinyOS

AM

CC1000Control

SpiByteFifo RandomLFSR ADC

Control(Freq, power,

etc)

CC1000RadioIntM

Wires the control and data paths:Implementation hidden from app

CC1000RadioC

Send(TOSMsg) Receive Event(TOSMsg)

UART

Generic Comm

Application

Sample RSSIBus-level control of CC1000 Radio

Chip

Hardware Specific


MICA2: CC1000 SendMsg Flow

1. Message travels down stack (GenericComm -> CC1000RadioIntM) Build header: Source address, AM ID,

address Hand off to hardware level Radio registers

2. Random delay (up to 15 packet times)3. Check for clear channel (CSMA)4. Turn on transmitter & send pkt over

SPI Port 18 byte preamble (10101 pattern) & frame

Sync TOS message (34 bytes) & CRC (2 bytes)

5. Wait for acknowledgement (optional)6. Turn off transmitter & signal TX Done

event to application

AM

CC1000RadioIntM

CC1000RadioC

Generic Comm

Send out byte by byte

Application

Send Command (TOSMsg)


MICA2: CC1000 ReceiveMsg

SPI port interrupt handler Search for the preamble: 101010… Wait for frame sync word

1. Assemble TOS packet2. Check CRC and reject if bad3. Route to Active Message handler4. Check group ID5. Send acknowledgement (optional)6. Signal application ReceivedMsg event

AM

CC1000RadioIntM

CC1000RadioC

Generic Comm

Received Byte Interrupt

Application

Receive Event(TOSMsg)


IDLE

S Y N C

Preamble

N o S ync

R X

Sync OK

R X C o unt< Length

C R C o r Length E rro r

POST PacketReceived

P R E -TX

TX(su b sta te s)

TX Delay = 0

C o llis io n E rro r

No Collision

POST PacketSent

T X E rro r

CC1000RadioM State Machine

1. Idle2. Rx Related:

Sync Packet Assemble

3. Tx Related: Collision Sense Preamble Sync Packet CRC Flush Done


MICA2 TinyOS Message Packet Structure

Bytes

2 1 1 1 29 (Default, but variable length)

Destination Address

AM Type

AM Group

Length

Data PayloadTinyOS Header


MICAz Radio Stack

Objectives Radio features Module Design Basic Send/Receive Operation Packet Structure


MICAz: CC2420 Radio

Packet Level Radio Hardware accepts data as full packets and has a packet buffer Direct sequence spread spectrum O-QPSK modulation 127 bytes maximum (data plus overhead)

CC2420 SendMsg1. Message travels down stack (GenericComm -> CC2420RadioM)

Builds IEEE802.15.4 MAC Header Hand off to hardware level Radio TX FIFO

2. Random delay (up to 15 packet times)

3. Check for clear channel (CSMA = carrier sense multiple access)

4. Wait for acknowledgement (optional)

5. Signal sendDone event to application


MICAz Radio Stack in TinyOS

AM

CC2420ControlM

HPLCC2420C RandomLFSR HighSpeedTimer

CC2420RadioM

CC2420RadioC

Send(TOSMsg) Receive Event(TOSMsg)

UART

Generic Comm

Application

Hardware Specific

SPIByte

• Read/write CC2420 registers/commands

• Transfer to/from TXFIFO/RXFIFO

• Atmega128 is the SPI master


MICAz: CC2420 Radio (cont’d)

CC2420 ReceiveMsg Radio interrupt upon detection of MAC header Read packet from RXFIFO Read frame type

Acknowledge– Verify matches TX sequence number– Signal client application with TOSMsg.ack=TRUE

Data Frame– Group ID, AM type, payload– Signal strength– Signal client application with TOSMsg


MICAz TinyOS Message Packet Structure

Bytes

1 2 1 2 2 1 1 variable

Length FCF SeqNo Dest Pan ID

Destination Address

AM Type

AMGroup

Data Payload

FCF are packet types1. Data2. Acknowledgements


Configuring Radio Stack at Compile Time

ObjectivesFrequencyPowerGroupNode Id


Compile-time Radio Stack Configuration

platform

mica2

micaz

mica2dot

freq (MHz)

903 904 … 926

433 433.5 … 434.5

315

2405 2410 … 2480

Uses command line “extras” in:MoteWorks/make/avr/

make <platform> freq,<channel> power,<level>

power (dB)

min -20

-10 0 5

max 10


Settings: Radio Frequency

Any “Central Frequency” channel preset can be assigned by passing in MHz to the make tool:make micaz freq,2455

Above example will compile to use 2.455 GHz

ChannelLower

FrequencyCentral

FrequencyUpper

Frequency11 2.404 2.405 2.40612 2.409 2.410 2.41113 2.414 2.415 2.41614 2.419 2.420 2.42115 2.424 2.425 2.42616 2.429 2.430 2.43117 2.434 2.435 2.43618 2.439 2.440 2.44119 2.444 2.445 2.44620 2.449 2.450 2.45121 2.454 2.455 2.45622 2.459 2.460 2.46123 2.649 2.650 2.65124 2.469 2.470 2.47125 2.474 2.475 2.47626 2.479 2.480 2.481

USA/FCC & Canada regions have 27 total channels allocated. Channels 11 to 26 are in the 2.4 GHz band. All frequencies are in GHz

IEEE 802.15.4 Channels

No overlaps with 802.11


802.15.4 and 802.11b Spectrum Relationship

2405 MHz

5 MHzSpacing

802.15.4: Ch. 11 to Ch. 26

Co-exists with WiFi, Bluetooth Channel selection is important

2 MHz 2480 MHz

22 MHz

2412 MHz 2437 MHz

802.11: Ch. 1 to Ch. 11

2425 MHz 2462 MHz

Ch. 15 Ch. 20

2475 MHz2450 MHz

25 MHzSpacing

Note: Channels 25, 26 are non-overlappingNote: Channels 25, 26 are non-overlapping

Ch. 1

Ch. 25Ch. 26

Ch. 6 Ch. 11


Settings: Radio Power

RF Power controls how “loud” the radio transmits Measured in decibels ranging from -20dB to +10dB

Dynamic RF power level e.g., command result_t setRFPower(uint8_t power);

Static RF power level Edit the MakeXbowlocal file

For CC1000: CFLAGS += -DRADIO_XMIT_POWER=0xFF For CC2420: CFLAGS += -DCC2420_TXPOWER=0xFF


Settings: Group IDs (Review)

Nodes only communicate within a common Group ID and is determined in Makexbowlocal file or during build time

Example: Assign your group ID to be 125 (hex 7d) The line below would be used in the MakeXbowlocal file

To override the default value, you can add the word “group” followed by a comma and then a hexadecimal number (up to two bytes)

DEFAULT_LOCAL_GROUP=0x7d

make <platform> group,<0xXXXX>


Lab: MyApp_Sensor, part 2 -- RF

Objectives Enabling MyApp_Sensor to send sensor data over the

radio Using XSniffer to view data sent over the radio


MyApp_Sensor – Sending Data Over The Air

With a slight modification MyApp_Sensor can be altered to send the message packet over the Mote radio to another Mote plugged into a base station

Change line 96 of the code in MyApp_SensorM.nc from this

to this

if (call SendMsg.send(TOS_UART_ADDR,sizeof(XDataMsg),&msg_buffer) != SUCCESS)

if (call SendMsg.send(TOS_BCAST_ADDR,sizeof(XDataMsg),&msg_buffer) != SUCCESS)


MyApp_Sensor – Sending Data Over The Air

if (call SendMsg.send(TOS_BCAST_ADDR,sizeof(XDataMsg),&msg_buffer) != SUCCESS)

The SendMsg.send command uses the first parameter to decide where the message packet should be sent

Changing from TOS_UART_ADDR to TOS_BCAST_ADDR tells the communications component to send the message through the radio instead of the UART. TOS_BCAST_ADDR actually sends the message to any Mote

within RF range, i.e., broadcasts the message. If we want to send the message specifically to the base

station we can set this parameter value to 0 A Mote plugged into a gateway board and intended to

function as a base station must always have a node id of 0.


MyApp_Sensor -- Single Mote TX and XSniffer

First, flash your new remote Mote.

1. Install MyApp_Sensor (with modifications) on one Mote Use Programmer’s Notepad Select Tools > shell and type in the dialog box

make <platform> install,1 <programmer>,<IP_address> or COM<port#>

2. Remove the Mote from the programming board, plug one of the sensorboards (MDA100, MTS300 or MTS310) onto that Mote Make sure it has batteries and turn it on. You should see all three LEDs blinking every second.


MyApp_Sensor – Single Mote TX and XSniffer

XSniffer is a way to eavesdrop on messages sent over the Mote radios. It doesn’t participate in the network. The radio is in receive mode only.

3. Install the XSniffer application onto another Motea. Plug in a second Mote to the programming board

b. Open /MoteWorks/apps/general/XSniffer

c. Load the TOSBase.nc application from /MoteWorks/apps/general/XSniffer using Programmers Notepad 2make <platform> install,0 <programmer>,<IP_address> or COM<port#>


Startup XSniffer – Viewing Packet Traffic

4. Start the XSniffer GUI by clicking on the XSniffer icon on your desktop.

5. Configure it to your gateway. MIB510: Select COM port and click start MIB520: Select the higher of the two COM

ports, (i.e., the data communications COM port) and click start.

MIB600: Must start XServe, change baud rate of port 10002, then connect XSniffer to localhost using port 9001. See next slide for details.


Now Watch The Packets Fly

5. Connect XServe to XSniffer application. (A must for MIB600 users. An option for MIB510 and MIB520 users.)If using a MIB510 or MIB520

xserve –s=COM<COM#+1> –b=115200

If using a MIB600 Set port 10002 to 115200 baud via Device Manager. (Don’t forget

to switch it back when finished.) Must connect through XServe Don’t forget to switch it back later.xserve –i=<IP_address>:10002 –b=115200

6. Then connect XSniffer to XServe:Click on “TCP Socket” For host: localhost For port: 9001

Remember: For MIB520, the COM port is the higher of the two COM ports


XSniffer – Screen Shot of the Log Tab

Orange = health packet

Aqua = Sync packet

Red = Route update packet

Legend

Yellow = Undefined AM type

Pale Turq = Ack Downstrm

Steel Blue = Data Upstrm

Green = Base station messages

See next slide for complete legend to coloring


XSniffer Options Tab – Packet Coloring Guide


Q & A: MoteWorks Radio Stack

Objectives Background MICA2 radio stack MICAz radio stack Configure radio stack at Compile

time TinyOS Radio API, Active Message

Interface Lab: Radio enable your Sensor

Applications

Physical

Data Link

MAC

LLC


Supplemental / Extra Slides


1. Background, Where is the radio stack located1. What services does it provide2. Feature set (things that it does for you)3. Interfaces for starting and stopping the radio stack4. Go over split-phase, send + recv5. AM Type6. Interface Sends to both UART and Radio7. Configuring the Radio Stack

2. Theory of Operation on the CC10001. Hardware2. Packet Format3. Radio Stack Structure4. State Machine5. Message Flow???

3. Theory of Operation on the CC24201. Hardware2. Packet Format3. Radio Stack Structure4. State machine5. Message Flow???


Active Messaging Flow

AM Type similar to IP PortDifferent AM Types supply different network services

Active Message algorithm: Sender’s TOS Message

specifies: AM# (Message Type) Destination Address

Receiver’s Message filtered for: GroupID & Node Address

Packets are routed via AM parameterized interface to appropriate Message Event handler

AM Handler#m

signal[m](TOSMsg)

RXRADIOSTACK

AM Handler#n

signal[n]

AM Handler#m

signal[p]

RADIOSTACK

TX

Application GenericComm

AM

TOS Msg[AM#]

GenericComm

AM


Sending a Message – Application Send Request

Example: XSensorMTS300/XSensorMTS300M.nc

Start background task to send message

Start background task to send message

Boolean to ensure last send completed

Boolean to ensure last send completed


Communicating between Nodes

Message Flow1. Fill a Message buffer with Data to send

2. Specify node address to receive the message

3. Specify Message Type (AM Number)

4. Lock Message buffer during .send operation Buffering the incoming message

5. Processing the message on reception


Background

Physical

Data Link

MAC

LLC

Care must always be taken when comparing wireless sensor networks to the wired TCP/IP world.

If analogies were made between

the MoteWorks radio stack and the OSI model, the radio stack would be composed of the Physical Layer, and a subset of the Data Link layer.


TOSMsg Supplemental info

Strength RSSI on receive LowPower RadioStack:

On send, overloaded to specify the preamble length (Long, Short, or Standard)

ACK Whether transmission was acknowledged by the

receiver

Time Place holder for time stamp on receive

Feb 2007WSN Training: MICA2/z Radio Stack1 MoteWorks Radio Stack Objectives Background Radio Stack...

Documents

Transcript of Feb 2007WSN Training: MICA2/z Radio Stack1 MoteWorks Radio Stack Objectives Background Radio Stack...