[XMOVE self-designed somatosensory solution] XMove 4.0 wireless networking protocol

Document directory

• 1. node Differentiation
• 2. node Capability Description
• 3. node working status description
• 1. Work Mode Control
• 2. channel allocation algorithm
• 3. Sending control information

I. Summary

XMove 4.0 must support multi-node hybrid networking. If you have more than two or more nodes, more than 40 nodes may be connected to the system. These nodes may include compatible nodes from the previous generation, or 4.0 ultra-micro nodes and handheld nodes. It is a complex and arduous task to make these nodes work normally without interference and at low power consumption.

Wireless protocols have the following tasks:

• Transmit node data to the host computer as accurate and effective as possible without packet loss
• Transfers the control information of the upper computer to the node effectively, and changes the node to the corresponding working state.
• Supports multi-node, multi-topology hybrid networking

　　

The author is a communication professional and has a certain understanding of wireless protocols. You can solve the problem as follows:

• The flat node type simplifies the wireless protocol as much as possible
• Establish uplink (from node to PC) and downlink (from PC to node)
• All protocols are built into the PC. The PC sends commands to implement the control logic, and the node is only responsible for running the work according to the working mode.
• The multi-channel method is used to solve the wireless interference problem. The automatic channel allocation algorithm is used to achieve the optimal receiving structure.

Ii. node status description

All nodes inherit from the XNode class, which provides services for basic communication and working mode. For details, see the node design section in the collection.

1. node Differentiation

The node indicates the node type through the NodeType field:

　　

　　

For example, if the super-micro node XNodeMini is in XMOVE4.0 and the type is 1, nodeTypeID = 1.

The node uses RawID to determine its hardware ID.

Note: Different Types of nodes are allowed to have the same ID, but nodes of the same type are not allowed to have the same ID. Otherwise, the system cannot judge.

2. node Capability Description

　　

The six attributes indicate whether the node contains the identity of the corresponding sensor.

3. node working status description

Two classes are used to describe the node's working status.Node working status, AndThe operating status required by the system.This section only describes the node's working status.

　　

3. Uplink: from node to PC

The XMove uplink channel adopts the 24-byte packet length format. The labels are as follows:

The definition of battery power and three-axis sensor data varies with nodes, which is not required here.

4. downlink: from PC to Node

The XMove downlink control is simpler. The package length is the same as that of the uplink. It is 24byte. Because the PC does not have GHz wireless communication capability, it must go through the forwarding node. After receiving the data, the transfer node forwards the data to each subnode.

　　

TransferID is the ID of the bridge node to be sent. When the bridge node finds that the local ID is consistent with this field, it will be considered as its own data.

PacketType is the description of the package type. 1 indicates the RF channel configuration, which is used to configure the RF parameters of different RF Modules of the Local Machine. Each two bytes after the PacketType represents a RF module, the module ID and the channel ID to be configured.

2 indicates configuring the sub-node status. After receiving the sub-node, the bridge node will forward it directly to the sub-node without any processing. After receiving the data, the child node finds the matching RawID in the package and uses the WorkMode of the next bit to modify its working mode.

V. working mode and channel control logic

The control channel involves the control of the node operating mode and RF. But in fact, they are sent together. Next we will introduce them separately.

1. Work Mode Control

To minimize node power consumption, the node's refresh rate and gyroscope enabling status should be dynamically adjusted as needed. When you do not need a node to transmit data, the node should notify the manager that the node is still "alive" with the lowest 4s "breathing packet ". In fact, there may be a variety of applications that need the data of the node at the same time, and their requirements for the node's working status are different. Find the minimum requirements that can meet these applications. To solve this problem, we designed this class:

This class is inherited from NodeWorkMode and has a new property: myNeededList, which stores all the requirements of all applications for this node. When the outside world reads the WorkMode value of this class, it returns the minimum requirement to meet these requirements. It is actually a Dictionary: Dictionary <IProgramWPF, Tuple <bool, NodeFreshSpeed>.

For details about how to provide node working mode requirements for an application, see XMove Studio Application Development API.

2. channel allocation algorithm

In order to improve the wireless performance of the system as much as possible, the hardware adopts multiple channel allocation policies, but this also causes the problem of channel allocation. We have designed the following channel enumeration:

/// <Summary> /// channel ID /// </summary> public enum RFChannel {// <summary> /// when the basic channel is enabled by default, in this channel // </summary> RF0 = 0, RF1 = 1, RF2 = 2, RF3 = 3, RF4 = 4, RF5 = 5, RF6 = 6, RF7 = 7}

When the node is enabled, all RF nodes work on the RF0 channel at one second.

After all nodes are registered in the node ing table of the communication method, the system automatically starts the channel allocation algorithm and begins to control the logic. The principles are as follows:

• The system may contain multiple bridge nodes, and their rf channels may vary,
• The system contains large quantum nodes, which all work on the RF0 channel by default and should be evenly allocated to each channel.
• If the packet rate of a channel is too high, the node should be switched to a channel in good state.

The author designed the RFChannelDistributor class to solve the channel allocation problem:

The procedure is as follows:

　　

3. Sending control information

When the system finds that the node's work mode does not match the work mode required by the system, the system starts to control the information sending process.

Because the downlink packet length is 24 bytes, a maximum of 11 nodes can be controlled at a time.. The system sends only node control information in the incorrect status. If the node cannot be sent at a time, the node is sent separately. After each packet is sent, it will go through a ms delay and be sent again, three times in total to ensure that the data is sent correctly.

6. Monitoring node working status

　　The system provides the node working status monitoring component.

The list on the left shows all the active node queues. Click any one of them, and the monitor on the right will monitor its working status. For details about the attributes, refer to the usage instructions.

If you want to manually correct the operating modes and frequencies of all nodes, you can use the "reconfigure RF channel" option in the "communication" column on the menu bar to complete this process.

VII. Summary

　　This article describes in detail the networking problem and working mode of XMove4.0. The entire content cannot be described in an article. In the above downlink, only the data format of the 2.4G RF channel and the Bluetooth channel of the mobile phone are introduced.

Practice has proved that this configuration can solve the problem of channel allocation easily and efficiently, and achieve the best performance and the lowest power consumption under various application requirements.

If you have any questions, please discuss them.