Microchip ATSAMR30E18A Manual

Microchip Ikke kategoriseret ATSAMR30E18A

Læs gratis den danske manual til Microchip ATSAMR30E18A (53 sider) i kategorien Ikke kategoriseret. Denne vejledning er vurderet som hjælpsom af 17 personer og har en gennemsnitlig bedømmelse på 4.3 stjerner ud af 9 anmeldelser. Har du et spørgsmål om Microchip ATSAMR30E18A, eller vil du spørge andre brugere om produktet?

Download PDF

Side 1/53

MiWi™

MiWi™ Software Design Guide

Introduction

The MiWi is Microchip’s proprietary wireless networking stack designed to support Low Rate Personal Area Networks

(LRPANs). This guide describes the MiWi applications implemented on the MiWi protocol available in the SAM

platforms (SAMR21 and SAMR30).

The MiWi supports the following three network topologies:

• Peer-to-Peer (P2P)

• Star

• Mesh

Features

Earlier versions of the MiWi Mesh networking stack (until version 2.10), released in the MiWi protocol v5.30 of

Microchip Libraries for Applications (MLA) v2017-03-06, supports a library-based Mesh networking stack. However,

this is redesigned with the following changes:

1. Optimization of current APIs to improve simplicity.

2. Redesign of the MiWi Mesh with additional features for next generation platforms.

3. A new commissioning procedure to improve the secured inclusion of devices to the network.

4. Dynamic switching between device types in the MiWi Mesh.

5. Network secure feature for all network messages.

6. Over-The-Air Upgrade to upgrade all the nodes in the network.

Table of Contents

Introduction.....................................................................................................................................................1

Features......................................................................................................................................................... 1

1. MiWi Architecture.................................................................................................................................... 4

2. Supported Topologies............................................................................................................................. 5

2.1. Peer-To-Peer (P2P) Topology...................................................................................................... 5

2.2. Star Topology............................................................................................................................... 6

2.3. Mesh Topology............................................................................................................................. 6

3. MiWi P2P................................................................................................................................................ 8

3.1. Network Addressing..................................................................................................................... 8

3.2. Message Format.......................................................................................................................... 8

3.3. Transmitting and Receiving..........................................................................................................9

3.4. Handshaking.............................................................................................................................. 10

3.5. Custom MAC Commands for MiWi P2P Wireless Protocol........................................................11

3.6. Idle Devices Turning Off Radios.................................................................................................13

3.7. Active Scan................................................................................................................................ 14

3.8. Energy Scan...............................................................................................................................14

3.9. Frequency Agility........................................................................................................................15

4. MiWi Star...............................................................................................................................................16

4.1. Unique Features of the MiWi Star Wireless Protocol................................................................. 16

4.2. Custom MAC Commands for MiWi Star Wireless Protocol........................................................16

4.3. Handshaking In MiWi Star Wireless Protocol.............................................................................17

5. MiWi Mesh............................................................................................................................................ 19

5.1. MiWi Mesh Device Types...........................................................................................................19

5.2. MiWi Mesh Frame Format..........................................................................................................19

5.3. MAC Header – Frame Control Field...........................................................................................19

5.4. Network Header......................................................................................................................... 21

5.5. MiWi Mesh – Device Addressing Mechanism............................................................................ 23

5.6. MiWi Mesh – Networking............................................................................................................23

5.7. Macros for MiWi Mesh................................................................................................................24

5.8. Recommendation for Macros..................................................................................................... 31

5.9. Extending Battery Life for Sleeping End-device.........................................................................32

6. Network Freezer....................................................................................................................................33

6.1. Interface..................................................................................................................................... 33

6.2. Additional Notes......................................................................................................................... 33

6.3. Default Memory Layout.............................................................................................................. 33

7. Sleep Mode........................................................................................................................................... 34

7.1. Interface..................................................................................................................................... 34

8. Over-The-Air Upgrade...........................................................................................................................35

8.1. OTAU Server.............................................................................................................................. 35

MiWi™

8.2. OTAU Client............................................................................................................................... 35

8.3. Domains of OTAU...................................................................................................................... 35

8.4. Compiler Switches for OTAU......................................................................................................35

9. MiApp APIs........................................................................................................................................... 37

10. MiApp API Description.......................................................................................................................... 39

10.1. MiApp_ProtocolInit..................................................................................................................... 39

10.2. MiApp_Set..................................................................................................................................39

10.3. MiApp_StartConnection............................................................................................................. 40

10.4. MiApp_SearchConnection..........................................................................................................40

10.5. MiApp_EstablishConnection...................................................................................................... 41

10.6. MiApp_RemoveConnection........................................................................................................41

10.7. MiApp_ConnectionMode............................................................................................................ 42

10.8. MiApp_SendData....................................................................................................................... 42

10.9. MiApp_SubscribeDataIndicationCallback.................................................................................. 43

10.10. MiApp_NoiseDetection...............................................................................................................43

10.11. MiApp_TransceiverPowerState.................................................................................................. 44

10.12. MiApp_Get................................................................................................................................. 45

10.13. MiApp_RoleUpgradeNotification_Subscribe.............................................................................. 45

10.14. MiApp_Commissioning_AddNewDevice....................................................................................45

10.15. MiApp_SubscribeReConnectionCallback.................................................................................. 46

10.16. MiApp_ResetToFactoryNew.......................................................................................................46

10.17. MiApp_ReadyToSleep................................................................................................................46

10.18. MiApp_ManuSpecSendData......................................................................................................46

10.19. MiApp_SubscribeManuSpecDataIndicationCallback................................................................. 47

10.20. MiApp_IsConnected...................................................................................................................47

10.21. MiApp_MeshGetNextHopAddr...................................................................................................48

11. Limitations............................................................................................................................................. 49

12. Document Revision History...................................................................................................................50

The Microchip Website.................................................................................................................................51

Product Change Notification Service............................................................................................................51

Customer Support........................................................................................................................................ 51

Microchip Devices Code Protection Feature................................................................................................51

Legal Notice................................................................................................................................................. 51

Trademarks.................................................................................................................................................. 52

Quality Management System....................................................................................................................... 52

Worldwide Sales and Service.......................................................................................................................53

MiWi™

1. MiWi Architecture

The following is the MiWi protocol architecture on Advanced Software Framework (ASF) which allows the user to

obtain required components, services and drivers from ASF Wizard. For more details, refer to the ASF Wizard

section at the web page.Atmel Software Framework

Figure 1-1. MiWi™ Architecture

MiWi

MiWiMiWiTM

TMTM Stack

Stack

Stack Stack

MiApp

MiAppMiApp

SYSTEM

SYSTEMSYSTEM

(MiWi

(MiWi(MiWiTM

TMTM

Tick -

Tick -Tick -

Symbol

Symbol Symbol

timer…)

timer…)timer…)

ASF SW Frame

ASF SW FrameASF SW Framework

work

work work

Hardw

HardwHardware Platf

are Platf

are Platfare Platform (i.e., Microcontr

orm (i.e., Microcontr

orm (i.e., Microcontrorm (i.e., Microcontroller

oller

olleroller, Board, Configur

, Board, Configur

, Board, Configur, Board, Configuration)

ation)

ation) ation)

Services/Drivers

Services/DriversServices/Drivers

TRx access

TRx access TRx access –SPI,

–SPI,

–SPI, –SPI,

GPIO, IR

GPIO, IRGPIO, IRQ

Timers

TimersTimers

RTC

RTC RTC

More More

peripherals

peripheralsperipherals

Inter

InterInterchangeable RF T

changeable RF T

changeable RF Tchangeable RF Transceiver

ransceiver

ransceiverransceivers - MiPhy

s - MiPhy

s - MiPhy s - MiPhy

SAMR21

SAMR21SAMR21-RF233 T

-RF233 T

-RF233 T-RF233 Transceiver

ransceiver

ransceiverransceiver

SAMR30

SAMR30SAMR30-RF212B T

-RF212B T

-RF212B T-RF212B Transceiver

ransceiver

ransceiverransceiver

Future Micr

Future MicrFuture Microchip RF T

ochip RF T

ochip RF Tochip RF Transceiver

ransceiver

ransceiverransceivers…

s…

s… s…

MiWi

MiWiMiWiTM

TMTM P2P

P2P

P2P P2P

User Application

User ApplicationUser Application

MiWi

MiWiMiWiTM

TMTM Mesh

Mesh

Mesh Mesh

Future Micr

Future MicrFuture Microchip proprietary

ochip proprietary

ochip proprietary ochip proprietary

wireless Pr

wireless Prwireless Protocols

otocols

otocolsotocols

MiMac

MiMacMiMac

Inter

InterInterchangeable Wireless

changeable Wireless

changeable Wireless changeable Wireless Communication Pr

Communication Pr

Communication PrCommunication Protocols

otocols

otocolsotocols

MiWi™

MiWi Architecture

2. Supported Topologies

2.1 Peer-To-Peer (P2P) Topology

A typical P2P topology is shown in the following figure. From a device role perspective, this topology has one PAN

Coordinator that starts communication from the end devices. When joining the network, however, end devices do not

have to establish their connection with the PAN Coordinator.

As to functional types, the PAN Coordinator is an FFD (Full Function Device) and the end devices can be FFDs or

RFDs (Reduced Function Device). In this topology, however, end devices that are FFDs can have multiple

connections. Each of the end device RFDs, however, can connect to only one FFD and cannot connect to another

RFD.

As shown in the following figure, the application data can be sent to all the devices in the radio range only.

Figure 2-1. Peer-To-Peer Topology

MiWi™

Supported Topologies

Figure 2-3. Mesh Topology

MiWi™

Supported Topologies

3. MiWi P2P

3.1 Network Addressing

The IEEE® 802.15.4 specification defines two kinds of addressing mechanisms:

• Long Address or Extended Organizationally Unique Identifier (EUI) – an 8-byte address that is unique for each

device, worldwide. The upper three bytes are purchased from IEEE by the company that releases the product.

The lower five bytes are assigned by the device manufacturer as long as the EUI of each device is unique. The

8-byte unique address is usually called the MAC address of the wireless device/node and is predominantly

associated with the node hardware.

• Short Address – a 2-byte address that is assigned to the device by its parent when it joins the network. The

short address must be unique within the network.

The MiWi P2P protocol supports only one-hop communication; hence it transmits messages through EUI or long

address. Short addressing is used only when the stack transmits a broadcast message.

3.2 Message Format

The message format of the MiWi P2P protocol is a subset of the message format of the IEEE 802.15.4 specification.

The following figure illustrates the packet format of the stack and its fields.

Figure 3-1. MiWi P2P Wireless Protocol Packet Format

2/8

0/2

0/8

Variable

Frame

Control

Sequence

Number

Destination

PAN ID

Destination

Address

Source PAN

Source

Address

Pay Load

Frame

Check

Sequence

3.2.1 Frame Control

The following figure illustrates the format of the 2-byte Frame Control field.

Figure 3-2. Frame Control

3 1 1 1 1 3 2 2 2

Frame

Type

Security

Enabled

Frame

Pending

Acknowledgement

Request

Intra PAN

(Reserved)

Destination

Address

Mode

(Reserved)

Source

Address

Mode

Bit

The 3-bit Frame Type field defines the type of packet with the following values:

• Data frame =001

• Acknowledgement =010

• Command frame =011

The Security Enabled bit indicates if the current packet is encrypted. There is an additional security header if

encryption is used. For more information, see 2.3 Mesh Topology.

The Frame Pending bit is used only in the Acknowledgement packet handled by the MRF24J40 radio hardware. This

bit indicates if an additional packet follows the Acknowledgement after a data request packet is received from a RFD

end device.

MiWi™

MiWi P2P

The Intra-PAN bit indicates if the message is within the current PAN. If this bit is set to ‘ ’, the Source PAN ID field in1

the addressing fields is omitted. In the stack, this bit is always set to ‘ ’, but it can be set to ‘ ’ to enable inter-PAN1 0

communication. Resetting the bit to ‘ ’ can be done in the application layer, if it is necessary.0

The Destination Address mode can be either 16-bit Short Address mode = or 64-bit Long Address mode10

= 11

In the MiWi P2P protocol, the Destination Address mode is usually set to the Long Address mode. The Short Address

mode is used only for a broadcast message. For broadcast messages, the Destination Address field in the

addressing fields is fixed to .0xFFFF

The Source Address mode for the MiWi P2P protocol can only be the 64-bit Long Address mode.

3.2.2 Sequence Number

The sequence number is 8 bits long. It starts with a random number and increases by one each time a data or

command packet is sent. The number is used in the Acknowledgement packet to identify the original packet. The

sequence number of the original packet and the Acknowledgement packet must be same.

3.2.3 Destination Pan ID

This is the PAN identifier for the destination device. If the PAN identifier is not known, or not required, the broadcast

PAN identifier ( ) is used.0xFFFF

3.2.4 Destination Address

The destination address can either be a 64-bit long address or a 16-bit short address. The destination address must

be consistent with the Destination Address mode defined in the Frame Control field. If the 16-bit short address is

used, it must be the broadcast address of .0xFFFF

3.2.5 Source Pan ID

The source PAN identifier is the PAN identifier for the source device and must match the intra-PAN definition in the

Frame Control field. The source PAN ID exists in the packet only if the intra-PAN value is ‘ ’.0

In the current MiWi P2P protocol implementation, all communication is intra-PAN. As a result, all packets do not have

a Source PAN ID field.

However, the stack reserves the capability for the application layer to transmit the message inter-PAN. If a message

needs to transmit inter-PAN, the source PAN ID is used.

3.2.6 Source Address

The Source Address field is fixed to use the 64-bit extended address of the source device.

3.3 Transmitting and Receiving

3.3.1 Transmitting Messages

There are two ways to transmit a message: Broadcast and Unicast.

Broadcast packets have all devices in the radio range as their destination. The IEEE 802.15.4 defines a specific short

address as the broadcast address but has no definition for the long address. As a result, for a IEEE 802.15.4

compliant transceiver, broadcasting is the only situation when the MiWi P2P stack uses a short address.

There is no Acknowledgement for broadcasting messages. Unicast transmissions have only one destination and use

the long address as the destination address. The MiWi P2P protocol requires Acknowledgement for all unicast

messages.

If the transmitting device has at least one device that turns off its radio when idle, the transmitting device saves the

message in RAM and waits for the sleeping device to wake up and request the message. This kind of data

transmitting is called .Indirect Messaging

If the sleeping device fails to acquire the indirect message, it expires and becomes discarded. Usually, the indirect

message timeout needs to be longer than the pulling interval for the sleeping device.

MiWi™

MiWi P2P

3.3.2 Receiving Messages

In the MiWi P2P protocol, only the messaged device is notified by the radio. If the messaged device turns off its radio

when idle, it can only receive a message from the device to which it is connected.

For the idling device with the turned off radio to receive the message, the device must send a data request command

to its connection peer. Then, it acquires the indirect message if there is one.

In Star topology, only the PAN Coordinator is enabled for connections and end devices (FFD/RFD) are all connected

to the PAN Coordinator. Hence, the end devices in Star topology have single connections.

3.4 Handshaking

Handshaking is the elaborate process of joining a network. A device can join only a single device as its parent and

hence, the initial handshaking is the actual process of choosing a parent.

Choosing the parent requires the following steps:

1. Listing all the possible parents

2. Choosing the right one as its parent

The MiWi P2P protocol is designed for simplicity and direct connections in Star and P2P communication topologies.

Some IEEE 802.15.4 requirements obstruct that design:

• The five-step handshaking process, plus two time-outs, requires a more complex stack.

• The association process uses one-connection communication rather than the multi-connection concept of peer-

to-peer topology.

For the preceding reasons, the MiWi P2P protocol uses its own two-step handshaking process as shown in the

following figure:

1. The initiating device sends out a P2P connection request command.

2. Any device within radio range responds with a P2P connection response command that finalizes the

connection.

This is a one-to-many process that may establish multiple connections, where possible, to establish a peer-to-peer

topology. Since this handshaking process uses a MAC layer command, CSMA-CA is applied for each transmission.

This reduces the likelihood of packet collision.

RFDs may receive the Connection Request command from several FFDs, but can connect to only one FFD. An RFD

chooses the FFD, from which it receives the first P2P connection response as its peer.

Figure 3-3. Handshaking Process For MiWi P2P Wireless Protocol

MiWi™

MiWi P2P

3.5 Custom MAC Commands for MiWi P2P Wireless Protocol

The MiWi P2P protocol extends the functionality of the IEEE 802.15.4 specification by using custom MAC commands

for removing the connection between two devices. The following table lists all of the custom MAC commands of the

protocol.

Table 3-1. Custom MAC Commands for MiWi P2P Wireless Protocol

Command

Identifier

Command Name Description

0x81 P2P Connection

Request

Request to establish a P2P connection. Usually broadcast to seek P2P

connection after powering up. Alternately, unicast to seek an individual

connection.

0x82 P2P Connection

Removal Request

Removes the P2P connection with the other end device.

0x83 P2P Data Request Similar to the IEEE 802.15.4 specification Data Request command (0x04), a

request for data from the other end of a P2P connection if the local node had

its radio turned off. Reserved for the previously sleeping device to request the

other node to send the missed message (indirect messaging).

0x84 Channel Hopping Request to change operating channel to a different channel. Usually used in

the feature of frequency agility.

0x87 Active Scan Request Checks available nodes in the current and accessible channels.

0x91 P2P Connection

Response

Response to the P2P connection request. Also can be used in active scan

process.

0x92 P2P Connection

Removal Response

Response to the P2P connection removal request.

0x97 Active Scan

Response

Response returns the node information including the Channel, PAN ID and

Node ID.

Note:

See for details on Active Scan Request and Active Scan Response.3.7 Active Scan

3.5.1 P2P Connection Request

The P2P connection request (0x81) is broadcasted to establish a P2P connection with other devices after powering-

up. The request can also be unicast to a specific device to establish a single connection.

When the transmitting device receives a P2P connection response (0x91) from the other end, a P2P connection is

established.

The P2P connection request custom command can also start an active scan to determine what devices are available

in the neighborhood.

When a P2P connection request command is sent for active scan purposes, the capability information and optional

payload is not attached. The receiving device uses the attachment, or absence of capability information, and an

optional payload to determine if the command is a request to establish a connection or just an active scan.

The MiWi P2P protocol can enable or disable a device to allow other devices to establish connections. After a device

is disabled from making connections, any new P2P connection request is discarded, except under the following

conditions:

• The P2P connection request is coming from a device in which the receiving end established a connection.

• The P2P connection request is an active scan.

The following figure shows the format of the P2P connection request command frame.

MiWi™

MiWi P2P

Figure 3-4. P2P Connection Request Command Format

15/21

1 (Optional)

Various (Optional)

MAC Header

Command Identifier

(0x81)

Operating Channel

Capability

Information

Optional payload to identify the

node. It is not required for the

stack, but may be useful for

applications.

Octet

Figure 3-5. Capability Information Format

4-7

Receiver ON

when Idle

Request Data

on Wake-up

Need Time

Synchronization

(Reserved)

Security Capable

(Reserved)

Bit

The operating channel is used to bypass the effect of subharmonics that may come from another channel. It avoids

the false connections with devices that operate on different channels. The capability information byte, as shown in

Figure 3-4, uses a format as illustrated in the preceding figure.

The optional payload of the P2P connection request is provided for specific applications. A device may need

additional information to identify itself, either its unique identifier or information about its capabilities in the application.

With the optional payload, no additional packets are required to introduce or identify the device after the connection is

established. The optional payload is not used in the stack.

3.5.2 P2P Connection Removal Request

The P2P connection removal request (0x82) is sent to the other end of the connection to remove the P2P connection.

The following figure shows the format of the request.

Figure 3-6. P2P Connection Removal Request Format

15/21

MAC Header: Send to the other end of the P2P

connection to cut the communication

Command Identifier (0x82)

Octet

3.5.3 Data Request

The data request (0x83) command is the same as the data request (0x04) command of the IEEE 802.15.4

specification. The following figure shows the format of the request.

If one side of a P2P connection node is able to sleep when idle, and that node can receive a message while in sleep,

the active side of the connection must store the message in its RAM. The active side delivers the message when the

sleeping device wakes up and requests the message.

If an application involves such conditions, the feature needs to be activated. TheENABLE_INDIRECT_MESSAGE

sleeping node must send the data request command after it wakes up.

Figure 3-7. Data Request Format

MAC Header: Unicast from extended source address

to extended destination address

Command Identifier (0x83 or 0x04)

Octet

3.5.4 Channel Hopping

The channel hopping command (0x84) requests for the destination device to change the operating channel to

another channel. The following figure shows the format of the command.

This command is usually sent by the frequency agility initiator which determines when to change channels and what

channel to select.

This command is usually broadcasted to notify all devices, with their radios ON when idle, to switch channels. To

ensure that every device receives this message, the frequency agility initiator performs the broadcast three times and

all the FFD devices perform the rebroadcast.

MiWi™

MiWi P2P

When the channel hopping sequence is carried out and all FFDs hop to a new channel, RFDs have to perform

resynchronization to restore connection to their respective FFD peers.

Figure 3-8. Channel Hopping Format

15/21

MAC Header: Broadcast or

unicast from the Frequency

Agility Starter

Command Identifier

(0x84)

Current Operating

Channel

Destination Channel to

Jump to

Octet

3.5.5 P2P Connection Response

The P2P connection response (0x91) command is used to respond to the P2P connection request. The following

figure shows the format of the command.

The P2P connection response command can be used to establish a connection. Alternately, the command can be

used by a device responding to an active scan, identifying itself as active in the neighborhood.

Figure 3-9. P2P Connection Response Format

1 (Optional)

Various (Optional)

MAC Header: Unicast

Status. 0x00 means

Optional payload to identify

from extended source

Command Identifier

successful. All other

Capability

the node. Not required for the

address to extended

(0x91)

values are error

Information

stack, but possibly useful for

destination address.

codes.

applications.

Octet

3.5.6 P2P Connection Removal Response

The P2P connection removal response command (0x92) is used to respond to the P2P connection removal request.

It notifies the other end of the P2P connection that a P2P connection request is received early and the resulting

connection is removed. The following figure shows the format of the command.

Figure 3-10. P2P Connection Removal Response Format

MAC Header: Unicast from

extended source address to

extended destination address

Command Identifier (0x92)

Status.

• 0x00 means successful.

• All other values are error codes

Octet

3.6 Idle Devices Turning Off Radios

For devices operating on batteries, reducing power consumption is essential. This can be done by having the devices

turn off their radios when not transmitting data. The MiWi P2P protocol includes features for putting radios into Sleep

mode and then waking up the device.

To activate this feature, “ ” must be defined in the file, .ENABLE_SLEEP_FEATURE miwi_config.h

To determine as to when a device is put into Sleep mode is identified by the specific application. The possible triggers

include:

• Length of radio idle time

• Receipt of a packet from a connected FFD, requesting the device to go to Sleep mode

The conditions for awakening a device can be determined by the specific application. Possible triggers include:

• An external event like a button is pressed

• Expiration of a predefined timer

While a device is sleeping, its peer device may need to send a message. If no message is sent, no additional feature

must be enabled by the peer device.

If the peer device sends a message to the sleeping device, the peer device must store the message in its volatile

memory until the sleeping device wakes up and acquires the message. Since the message is not directly delivered to

the sleeping device, this process is called an .Indirect Message

MiWi™

MiWi P2P

If an indirect message is delivered, the peer device of the sleeping node must define

“ ” in the file.ENABLE_INDIRECT_MESSAGE miwi_config.h

If indirect messaging is enabled, there must be a specified maximum number of indirect messages that can be stored

in the volatile memory. The maximum size of the message depends on the free RAM memory available in the peer

device and from the number of RFDs connected to the same parent FFD.

The maximum number of indirect messages is defined by the “ ” in theINDIRECT_MESSAGE_SIZE

miwi_config_p2p.hfile. For indirect messaging, the timeout period for the indirect messages also needs to be

defined. If a timeout period is not defined and an RFD device is inactive or not visible, the indirect message remains

forever in the volatile memory.

The indirect message time-out period is defined by the “ ” in theINDIRECT_MESSAGE_TIMEOUT

miwi_config_p2p.hfile, with seconds as the unit of measurement.

3.7 Active Scan

Active scan is the process of acquiring information about the local PAN. The active scan determines:

• The device’s operating channel

• The device’s signal strength in the PAN

• The PAN’s identifier code for IEEE 802.15.4 compliant transceiver

Active scan is particularly useful if there is no predefined channel or PAN ID for the local devices.

The maximum number of PANs that an active scan can acquire is defined in the stack as

ACTIVE_SCAN_RESULT_SIZE.

The scan duration and channels to be scanned are determined before the active scan begins.

The scan duration is defined by the IEEE 802.15.4 specification and its length of time, measured in symbols, is

calculated with the formula shown in the following equation (One second equals 62,500 symbols.).

Equation 3-1. Scan Duration

    960* 2 + 1

Note:

Scan duration = The user-designated input parameter for the scan. An integer is from 1 to 14.

A scan duration of 10 results in a scan time period of 61,500 symbols or about 1 second. A scan duration of 9 is

about half second.

The scan channels are defined by a bitmap with each channel number represented by its comparable bit number in

the double word. Channel 11 is .b'0000 0000 0000 0000 0000 1000 00000000

Channels 11 to 26, supported in the 2.4 GHz spectrum, is b'0000 0111 1111 1111 11111000

0000 000 or 0x07FFF800.

When an active scan broadcasts a P2P connection request command, it expects any device in radio range to answer

with a P2P connection response command. The active scan determines only what PANs are available in the

neighborhood, not how many individual devices are available for new connections. Every device responds to the

scan, including those devices that do not allow new connections.

To invoke the active scan feature, “ ” must be defined in the file.ENABLE_ACTIVE_SCAN miwi_config.h

3.8 Energy Scan

On each frequency band, there may have multiple channels, but a PAN must operate on one. The best channel to

use is the one with the least amount of energy or noise.

Energy scan is used to scan all available channels and determine the channel with the least noise.

The scan duration and channels to be scanned are determined before the energy scan is performed.

MiWi™

MiWi P2P

The scan duration is defined by the IEEE 802.15.4 specification and its length of time, measured in symbols, is

calculated with the formula as shown in . For more information on measurement, see .Equation 3-1 3.7 Active Scan

After the scan is complete, the channel identifier with the least noise is returned. To activate the energy scan feature,

“ ” must be defined in the file.ENABLE_ED_SCAN miwi_config.h

3.9 Frequency Agility

Frequency agility enables the MiWi P2P Protocol PAN to move to a different channel if required by the operating

conditions.

In implementing this feature, the affected devices fall into one of these two roles:

• Frequency agility initiators – these are devices that determine whether channel hopping is necessary and which

new channel is applicable to use.

• Frequency agility followers – these are devices that change to another channel when directed.

3.9.1 Frequency Agility Initiators

Each PAN can have one or more devices as a frequency agility initiator. An initiator must be an FFD. Each initiator

must have the energy scanning feature enabled to determine the optimal channel for the hop. The initiator broadcasts

a channel hopping command to the other devices on the PAN.

3.9.2 Frequency Agility Followers

A frequency agility follower can be an FFD or an RFD device.

The FFD makes the channel hop by performing one of the following steps:

• Receiving the channel hopping command from the initiator.

• Resynchronizing the connection, if data transmissions continuously fail.

An RFD device makes the message hop using the resynchronization method, which reconnects to the PAN when

communication fails.

3.9.3 Enable Frequency Agility Feature

The application determines when to perform a frequency agility operation. Frequency agility is usually triggered by

continuous transmission failure, either by CCA failure or no Acknowledgement received.

To activate the frequency agility feature, the “ ” must be defined in theENABLE_FREQUENCY_AGILITY

miwi_config.h file.

MiWi™

MiWi P2P

4. MiWi Star

MiWi Star protocol is an extension of the MiWi P2P protocol which is defined by Microchip. From a device role

perspective, the topology has one PAN Coordinator that initiates communications and accepts connections from

other devices. It can have several end devices that join the communication. End devices can establish connections

only with the PAN Coordinator. As to functionality type, the Star topology’s PAN Coordinator is an FFD. An end device

can be an FFD with its radios ON all the time, or an RFD with its radio OFF when idle. Regardless of its functional

type, the end devices can only communicate to the PAN Coordinator.

4.1 Unique Features of the MiWi Star Wireless Protocol

The Star topology supported by the MiWi P2PProtocol stack provides all the features supported by the peer-to-peer

topology, however, Star topology supports several more features based on the device roles.

PAN Coordinator supports the following features:

• Shares peer device connection (FFDs and RFDs) information to all the peer devices

• Forwards data packet from one end device to another end device

• Checks network health periodically(optional)

• Transmits data packet to end devices

• Handles Indirect Messages for sleeping end devices (RFDs)

• Supports software ACK to indicate successful data transmission

The FFDs (end devices) or RFDs (sleeping end devices) support the following features:

• Link status

• Leave Network command

4.2 Custom MAC Commands for MiWi Star Wireless Protocol

The MiWi Star protocol extends the functionality of the IEEE 802.15.4 specification by using custom MAC commands

for removing the connection between two devices. The following table lists all the custom MAC commands of the

protocol.

Table 4-1. Custom Mac Commands For MiWi Star Wireless Protocol

Command

Identifier

Command Name Description

0xCC Forward Packet CMD with Payload 0XCC (1 byte) Command. Destination end device

address (3 bytes). Data payload.

0xDA Software ACK to END Device N/A

0x7A LINK STATUS N/A

0x77 Connection Table Broadcast Command 0x77 (1 byte) Command. Total number of end

devices in the network.

The following figure shows the modified connection mode details in the star protocol.

MiWi™

MiWi Star

Figure 4-1. Modified Connection Mode Details in Star Protocol

Node Capacity

Sleep

Reserved

Security

Enabled

Connection

Mode

Reserved

Bit

1-2

4-5

6-7

Value

Connection Mode

Enable All Connections

Enable Previous Connections

Enable Active Scan Response

Disable All Connections

4.3 Handshaking In MiWi Star Wireless Protocol

4.3.1 MiWi Star Routing

The following figure shows that a MiWi Star network consists of two types of devices (PAN Coordinator and end

devices - FFDs or RFDs). The PAN Coordinator creates the network while the end devices join the PAN Coordinator.

The PAN Coordinator can send messages to all the end devices in the network in a single hop. If an end device

wants to communicate to another end device which may or may not be in the vicinity, the source end device must first

send the packet to the PAN Coordinator and then the PAN Coordinator forwards that packet to the destination end

device (2 hops).

Figure 4-2. MiWi Star Routing

MiWi™

MiWi Star

In a MiWi Star network, it is the responsibility of the PAN Coordinator to share the peer connections (end device

addresses). In this way, all the end devices in the network know about the existence of every other device in network.

When an end device wants to send a message to another end device, the source end device includes the address of

the destination end device in the data payload. The source end device payload comprises of the type of packet

(0xCC), destination end device address (only first 3 bytes) and the data payload. When this packet is received by the

PAN Coordinator, it indicates that this packet is intended for another end device, hence, it forwards the packet to the

destination end device.

4.3.2 MiWi Star Data Transfer

The connection requests and responses are similar to that of P2P between the nodes. However, in MiWi Star, the

PAN Coordinator forms the network, connects the end devices and also supports the end devices to communicate

between each devices (via PAN Coordinator). The following figure shows a simple data transfer between the end

devices in the MiWi Star network.

Figure 4-3. Data Transfer Between End Devices in the MiWi Star Network

MiWi™

MiWi Star

5. MiWi Mesh

5.1 MiWi Mesh Device Types

The MiWi Mesh protocol supports the following device types:

1. PAN Coordinator

1.1. Starts the network

1.2. Assigns and maintains the coordinators and its end-devices addresses

1.3. Behaves as coordinator for routing frames

1.4. Controls the devices which can be included into the network through commissioning

2. Coordinator

2.1. Joins a network as an end-device

2.2. Requests PAN coordinator for role upgrade to become a coordinator

2.3. Supports routing of frames within the network

2.4. Stores the commissioning information from PAN coordinator and allows only the commissioned

devices to participate in the network

2.5. Maintains its end-devices and their addresses

2.6. Maintains data for sleeping end-devices

3. End-Device

3.1. Joins to network though available coordinators

3.2. Supports Rx-On end-device and Sleeping end-device for battery operated devices

3.3. Supports dynamic switching between Rx-On to Sleeping end-device and vice versa

5.2 MiWi Mesh Frame Format

The network header and application payload of the MiWi Mesh are encapsulated inside the standard IEEE 802.15.4

data frame payload, but the stack does not adhere to the standard. Therefore, the MiWi Mesh does not receive and

process IEEE 802.15.4 command frames. The following figure illustrates a general frame format composed of an

IEEE 802.15.4 MAC header, network header, application payload, optional message integrity code (MIC), and a

check sum (CRC).

Figure 5-1. General MiWi Frame Format

Frame

Control

Sequence

number

Dest.

PANID

Dest.

Address

Source

PANID

Source

Address Hops Frame

Control

Sequence

number

Dest.

PANID

Dest.

Address

Source

Address

Auxiliary

Security

Header

Payload

Variable

Payload Network

Footer

MIC CRC

MAC Header Network Header

2 2 2/81 2 0/2/8 1 1 1 0/2/80/2 0/2 0/5 0/4 2

5.3 MAC Header – Frame Control Field

The following figure illustrates the Frame Control field of the MAC header.

Figure 5-2. MAC Header – Frame Control Field

Frame

Type

Security

Enabled

Frame

Pending

Ack.

Request

PAN ID

Compression Reserved

Dest.

Address

Mode

Frame

Version

Source

Address

Mode

Bits:0-2 4 53 6 7:9 10:11 12:13 14:15

MiWi™

MiWi Mesh

These are the fixed MAC Frame control field settings used in MiWi Mesh. The following table lists the settings used

for a Frame Control field of the MAC header.

Table 5-1. MAC Frame Control Field Settings

Field Name Settings

Frame Type Data

Security Enabled False

Frame Pending True if pending data available for sleeping end device,

otherwise false

Acknowledgment Request True for unicast frames and false for broadcast frames

PAN ID Compression True

Destination Addressing Mode 0 for no address fields, 2 for 16-bit short address and 3

for 64-bit extended address

Frame Version 0

Source Addressing Mode 0 for no address fields, 2 for 16-bit short address and 3

for 64-bit extended address

5.3.1 Frame Type

The Frame Type subfield is 3 bits in length and shall be set to 001 - Data.

5.3.2 Security Enabled

The Security Enabled subfield is 1 bit in length, and it shall be set to one if the frame is protected by the MAC

sublayer and set to zero otherwise. The Auxiliary Security Header field of the MHR shall be present only if the

Security Enabled subfield is set to one.

5.3.3 Frame Pending

The Frame Pending subfield is 1 bit in length and shall be set to one if the device sending the frame has more data

for the recipient. This subfield shall be set to zero otherwise.

The Frame Pending subfield shall be used only in beacon frames or frames transmitted either during the CAP by

devices operating on a beacon-enabled PAN or at any time by devices operating on a non-beacon enabled PAN. At

all other times, it shall be set to zero on transmission and ignored on reception.

5.3.4 Acknowledgment Request

The Acknowledgment Request subfield is 1 bit in length and specifies whether an acknowledgment is required from

the recipient device on receipt of a data or MAC command frame. If this subfield is set to one, the recipient device

shall send an acknowledgment frame only if, upon reception, the frame passes the third level of filtering. If this

subfield is set to zero, the recipient device shall not send an acknowledgment frame.

5.3.5 PAN ID Compression

The PAN ID Compression subfield is 1 bit in length and specifies whether the MAC frame is to be sent containing

only one of the PAN identifier fields when both source and destination addresses are present. If this subfield is set to

one and both the source and destination addresses are present, the frame shall contain only the Destination PAN

Identifier field and the Source PAN Identifier field shall be assumed equal to that of the destination. If this subfield is

set to zero and both the source and destination addresses are present, the frame shall contain both the Source PAN

Identifier and Destination PAN Identifier fields. If only one of the addresses is present, this subfield shall be set to

zero, and the frame shall contain the PAN Identifier field corresponding to the address. If neither address is present,

this subfield shall be set to zero, and the frame shall not contain either PAN Identifier field.

5.3.6 Destination Addressing Mode

The Destination Addressing Mode subfield is 2 bits in length and shall be set to one of the nonreserved values as

listed in the following table. If this subfield is equal to zero and the Frame Type subfield does not specify that this

MiWi™

MiWi Mesh

frame is an acknowledgment or beacon frame, the Source Addressing Mode subfield shall be nonzero, implying that

the frame is directed to the PAN coordinator with the PAN identifier as specified in the Source PAN Identifier field.

Table 5-2. Possible values of the Destination Addressing Mode and Source Addressing Mode subfields

Addressing Mode Value

b1b0Description

00 PAN Identifier and address fields are not present

01 Reserved

10 Address field contains a 16-bit short address

11 Address field contains a 64-bit extended address

5.3.7 Frame Version

The Frame Version subfield is 2 bits in length and specifies the version number corresponding to the frame. This

subfield shall be set to 0x00 to indicate a frame compatible with IEEE Std 802.15.4-2003 and 0x01 to indicate an

IEEE 802.15.4 frame. All other subfield values shall be reserved for future use.

5.3.8 Source Addressing Mode

The Source Addressing Mode subfield is 2 bits in length and shall be set to one of the nonreserved values listed in

Table 5-2. If this subfield is equal to zero and the Frame Type subfield does not specify that this frame is an

acknowledgment frame, the Destination Addressing Mode subfield shall be nonzero, implying that the frame has

originated from the PAN coordinator with the PAN identifier as specified in the Destination PAN Identifier field.

5.4 Network Header

5.4.1 Hops Field

The Hops field provides the number of hops the packet is allowed to be retransmitted. For example, 00h indicates

that the packet is not retransmitted. Maximum possible hop is 0xFF.

5.4.2 Frame Control Field

The Frame Control field is a bitmap which defines the behavior of a packet as shown in the following figure.

Figure 5-3. Network Header – Frame Control Field

Frame

Type

Security

Enabled

Ack.

Request Reserved

Address

same as MAC

Bits:0-1 4 53 6-7

Infra

Cluster

The following table details the Frame Control field of the Network Header.

Table 5-3. Network Header Frame Control Field Description

Bit Number Field Name Description

6-7 Reserved Set the bit as ‘0’ for this implementation.

5 Address same as MAC This bit is set when the MAC Address fields and

Network Address fields are same. This is useful when

the sleeping end-device polls the parent for data, with

relatively less bytes over-the-air for single hop from the

network layer.

MiWi™

MiWi Mesh

• 1 (Authentication - 4 bytes MIC)

• 4 (Encryption only)

• 5 (Encryption with Authentication - 4 bytes MIC)

5.5 MiWi Mesh – Device Addressing Mechanism

The MiWi Mesh uses a 2 bytes short address to specify nodes in the network when performing routing across the

network. The address is allocated during the joining process. The lower byte is used to identify the end-devices. The

higher byte is used to identify the coordinators.

Bit 15:8 Bit 7 Bit 6:0

Coordinator identifier RxOnWhenIdle End-device identifier

5.6 MiWi Mesh – Networking

The MiWi Mesh network features are categorized as follows:

1. Network commissioning

2. Start and join network

3. Routing in network

5.6.1 Network Commissioning

The network commissioning controls the devices which can participate in the network.

1. Application on the PAN Coordinator reads the IEEE address (for example, it can be improved to read from bar

code) from one or more devices.

2. PAN coordinator calculates the 64 byte bloom filter value with the read information.

3. Calculated bloom filter value is sent to all the coordinators in the network.

4. Coordinators provide beacon to only the devices which have its IEEE address in the bloom filter.

By default, the PAN Coordinator allows any device to join since BLOOM_AUTO_JOIN is enabled which means no

filtering of IEEE addresses.

If the user wants to filter devices based on the IEEE addresses set through MiApp_Commissioning_AddNewDevice,

then the user needs to set BLOOM_AUTO_JOIN to 0 using MiApp_Set API.

The user can add new devices using MiApp_Commissioning_AddNewDevice during run time as well. The network

will allow those newly added devices.

5.6.2 Start and Join Network

1. Only the PAN coordinator can start a network.

2. Joining device sends a beacon request to obtain information about the available networks in its personal

operating space.

3. The PAN coordinator or coordinator evaluates the beacon request by parsing the given IEEE address with the

bloom filter value. If found, it sends a beacon frame with a beacon payload which includes PAN coordinator

hop count and bloom filter value (64 bytes). If not found, it discards the packet.

4. Upon receiving the beacon frames, the joining device parses it and checks its own address in the bloom filter

value and then decides its parent based on associate permit, children capacity and Link Quality Indicator (LQI)

of the received beacons. After choosing the parent, it unicasts Mesh Connection Request packet (includes its

capability and JoinWish field) to the selected parent.

The JoinWish field has 2-bits C and ED, and remaining bits are reserved.

– If both bits are set in JoinWish, then the particular device joins as an end-device if the coordinator

capacity is currently unavailable in the network.

– If only the C bit is set, then the device joins as a Coordinator only.

– If only the ED bit is set, then the device joins as an end-device only.

MiWi™

MiWi Mesh

5.7.2 KEEP_ALIVE_COORDINATOR_SEND_INTERVAL

Description Time interval in seconds on which a coordinator capable device sends keep alive frame to PAN

coordinator. Upon reception of this frame, PAN coordinator refreshes the timeout for that

particular coordinator.

Default Value 120

Range 1 – 65535

Memory Usage None

Configurable in miwi_config_mesh.h

Remarks KEEP_ALIVE_COORDINATOR_TIMEOUT_IN_SEC is based on this value.

5.7.3 KEEP_ALIVE_COORDINATOR_TIMEOUT_IN_SEC

Description Timeout in seconds for which the PAN coordinator maintains the entry of coordinator, for holding

its address. Each coordinator is expected to send at least one keep alive frame to PANC within

this timeout.

Default Value KEEP_ALIVE_COORDINATOR_SEND_INTERVAL *10

The default value is 1200 when KEEP_ALIVE_COORDINATOR_SEND_INTERVAL is set as 120.

Range 1 – 65535

Memory Usage None

Configurable in miwi_config_mesh.h

Remarks None

5.7.4 KEEP_ALIVE_RXONENDDEVICE_SEND_INTERVAL

Description Time interval in seconds on which an end-device sends keep alive frame to its coordinator. Upon

reception of this frame, coordinator refreshes the timeout for that particular end-device.

Default Value 120

Range 1 – 65535

Memory Usage None

Configurable in miwi_config_mesh.h

Remarks KEEP_ALIVE_RXONENDDEVICE_TIMEOUT_IN_SEC is based on this value.

5.7.5 KEEP_ALIVE_RXONENDDEVICE_TIMEOUT_IN_SEC

Description Timeout in seconds for which the coordinator maintains the entry of end-device, for holding its

address. Each end-device is expected to send at least one keep alive frame to coordinator within

this timeout.

Default Value KEEP_ALIVE_RXONENDDEVICE_SEND_INTERVAL *10 (that is, 1200)

The default value is 1200 when KEEP_ALIVE_COORDINATOR_SEND_INTERVAL is set as 120.

Range 1 – 65535

Memory Usage None

Configurable in miwi_config_mesh.h

Remarks None

MiWi™

MiWi Mesh

5.7.6 DATA_REQUEST_SEND_INTERVAL

Description Time interval in seconds on which a sleeping end-device sends Data Request frame to its

coordinator. Upon reception of this frame, coordinator refreshes the timeout for that particular

sleeping end-device and sends any data cached in indirect queue.

Default Value 3

Range 1 – 254

Memory Usage None

Configurable in miwi_config_mesh.h

Remarks RXOFF_DEVICE_TIMEOUT_IN_SEC MAXIMUM_DATA_REQUEST_SEND_INTERVAL and is based

on this value

5.7.7 RXOFF_DEVICE_TIMEOUT_IN_SEC

Description Timeout in seconds for which the coordinator maintains the entry of sleeping end-device, to hold

its address. Each sleeping end-device is expected to send at least one Data Request to

coordinator within this timeout.

Default Value DATA_REQUEST_SEND_INTERVAL * 20 (that is, 60)

The default value is 60 when DATA_REQUEST_SEND_INTERVAL is set as 3.

Range 1 – 65535

Memory Usage None

Configurable in miwi_config_mesh.h

Remarks None

5.7.8 MAXIMUM_DATA_REQUEST_SEND_INTERVAL

Description Maximum time interval in seconds for Data Request of end-device in the network.

Default Value DATA_REQUEST_SEND_INTERVAL * 2 (that is, 6)

Range 1 – 254

Memory Usage None

Configurable in miwi_config_mesh.h

Remarks None

5.7.9 MAX_NUMBER_OF_DEVICES_IN_NETWORK

Description This macro is used to configure the number of device’s IEEE addresses to be stored for

commissioning.

Default Value 32

Range 1 – 255

Memory Usage 256 bytes of RAM for 32 entries, that is, 8 bytes per entry

Configurable in miwi_config_mesh.h

Remarks None

MiWi™

MiWi Mesh

Produkt Specifikationer

Mærke:	Microchip
Kategori:	Ikke kategoriseret
Model:	ATSAMR30E18A

Har du brug for hjælp?

Hvis du har brug for hjælp til Microchip ATSAMR30E18A stil et spørgsmål nedenfor, og andre brugere vil svare dig

Dit navn*

Din email*

Skriv dit spørgsmål her

Ikke kategoriseret Microchip Manualer

Microchip MPFS095TS Manual

17 Juni 2025

Microchip 1520 Manual

17 Juni 2025

Microchip MPFS460T Manual

17 Juni 2025

Microchip MPFS160TS Manual

17 Juni 2025

Microchip MPFS025TL Manual

17 Juni 2025

Microchip MPFS025TLS Manual

17 Juni 2025

Microchip MPFS160TLS Manual

17 Juni 2025

Microchip MPFS250TLS Manual

17 Juni 2025

Microchip MPFS250T Manual

17 Juni 2025

Microchip MPFS460TL Manual

17 Juni 2025

Ikke kategoriseret Manualer

Nyeste Ikke kategoriseret Manualer

Festo DFM-32-20-B-PPV-A-KF Manual

17 Juni 2025

Festo DGST-25-80-E1A Manual

17 Juni 2025

OmniMount OBLED80FM Manual

17 Juni 2025

OmniMount FPK200FT Manual

17 Juni 2025

Festo ESNU-40-25-P-A Manual

17 Juni 2025

Festo DFM-25-125-B-PPV-A-GF Manual

17 Juni 2025

Playtive IAN 306800 Manual

17 Juni 2025

Playtive IAN 313534 Manual

17 Juni 2025

Festo DFM-40-50-B-PPV-A-GF Manual

17 Juni 2025

Tekron NTS 02-G Manual

17 Juni 2025