. neo.cortec User Guide Doc Status: Doc version: Date: Release 2.
. neo.cortec Table of Contents 1 2 3 Document revisions ..................................................................................................... 5 Introduction .................................................................................................................. 5 NeoMesh Wireless Ad-Hoc MESH-networking ............................................................ 6 3.1 Overview .........................................................................................................
. neo.cortec 4 3.4.1.3 Generic Application – Normal Mode ....................................................... 26 3.4.1.4 Generic Application – Alternate Mode .................................................... 26 3.4.1.5 Application Type ID ................................................................................... 26 3.4.1.6 AAPI CTS Interleave ................................................................................... 26 3.4.1.7 AAPI CTS Timeout ......................................
. neo.cortec 4.1 Overview ..................................................................................................................... 36 4.2 UART............................................................................................................................ 36 4.3 GPIO ............................................................................................................................ 37 4.4 HTU21D .................................................................................
. neo.cortec 1 Document revisions Document version 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2.0 2.1 2.3 2.4 Details Initial release HAPA details added Generic Application added Wireless Encrypted Setup added Minor typos fixed FHSS description updated Added Settings ID to identify settings from raw list. Major update including better system description as well as parameter descriptions for protocol rel.1.3. Added missing details for a number of parameters Major update for protocol rel1.
. neo.cortec 3 NeoMesh Wireless Ad-Hoc MESH-networking 3.1 Overview NeoMesh is a wireless system designed with versatility in mind allowing users to build products in many different application areas. It is optimised for ultra-low power operation, and allows operation on small batteries for several years. NeoMesh is ideally suited for Wireless Sensor Networks where each sensor/device does not need to send data very often, and where the payload size is small.
. neo.cortec Figure 1 - Legacy Mesh topology As can be seen, there are 3 types of nodes: Node Type Description Coordinator Is required to form and maintain the network. Organizes who gets to be neighbours with who, and as such is a single point of failure. Router Can route messages through the network on behalf of other nodes. End device Optimised for low power operation and can only send (and receive) messages on its own behalf.
. neo.cortec limitations reduces the deployment options, and effectively reduces the practical network sizes. 3.2.2 NeoMesh network characteristics NeoMesh is based on a decentralized approach, where all nodes are self-governing, and not dependent on a coordinator. Similarly, NeoMesh does not implement individual node types, and all nodes share the same low power characteristics. This provides significant advantages over existing technologies in terms of power consumption for the entire network.
. neo.cortec The scheduled communication is being used to maintain the network in terms of neighbour relations, and also to maintain routing information. As such, this communication happens periodically regardless of payload data being send or not. 3.3.2 Network Initialization The wireless mesh network is created automatically when the participating nodes are powered up.
. neo.cortec Figure 4 – beacon timing, synchronized The Beacon Event is divided into timeslots. When a node transmits its Beacon, it randomly selects between the available timeslots. During the Beacon Event each node will listen for the full duration of the Beacon Event, only interrupted by the time when it transmits its own beacon. In dense networks with many nodes within radio range, the nodes will skip beacon transmissions randomly to further decrease the likelihood of collisions.
. neo.cortec Let us consider a situation with 2 nodes (Node A & B) within radio range of each other, where their Beacon Timing is already synchronized, and they are about to become neighbours to each other: First, let us take a look at the transmission activity of Node A: Figure 5 – Single node activity pattern In this example, the Beacon Period (PB) is twice as long as the Scheduled Data Period (PSCD).
. neo.cortec Node A will in a similar fashion receive the Beacon transmission from Node B, and then wake up to receive the Scheduled Data transmissions from Node B, and as such they are now neighbours. When more nodes join, they do so in the same way as described above, and the network will initialize autonomously. 3.3.
. neo.cortec Depending on the transmission method used, payload data can be send to any device in the network. 3.3.4.1 Speed Routing Both Acknowledged and Non-Acknowledged transmissions types are using Speed Routing to route the payload data from source to destination. Speed Routing is a patented technology used exclusively in NeoMesh.
. neo.cortec This type of messaging is useful in applications where each message is important – for instance in metering and sub-metering applications where the data contained in the message is vital. Note: If the originating node is a non-sink node (i.e. Node ID > 128), the protocol cannot use Speed Routing to route the ACK message back to the originator. In this case, the protocol will route the ACK message back along the same route as the payload message was routed.
. neo.cortec As an example: A network with 1000’s of wireless NeoMesh enabled sensors, is configured such that the sensors sends measurement samples periodically to a gateway node in the network. All of the sensor devices are non-sink nodes. The gateway once in a while has to send messages to the individual sensors. It can do so by waiting until a message has been received from the sensor to which it needs to send data.
. neo.cortec To illustrate how payload data is being transmitted through a network, let us consider a very simple network consisting of 3 Nodes: Figure 7 In the example, Node A is neighbour to Node B, and Node B is neighbour to both Node A & Node C. The application layer at Node A wants to transmit a payload package to the application layer at Node C using Acknowledged Transmission.
. neo.cortec receives it. Note that the Scheduled Data transmissions of Node B is received by both Node A and Node C, but the routing protocol ensures that the payload is only received by Node C. Once the payload package has reached Node C, and if the transmission type is “Acknowledged”, an acknowledge will be routed back to the originator in the same way as the payload data was routed – this is shown by the green line in the illustration.
. neo.cortec A payload message can consist of up to 21 bytes of raw payload data. The raw payload is allocated exclusively to application data.
. neo.cortec first (acknowledged) payload data transmission from a source to a sink will fail due to the wrong response included in the datagram. However, the protocol will automatically retry the transmission with the correct challenge. This happens transparently from the application layer. The only impact is that the first payload data exchange will take twice as long time as normally due to the retransmission. 3.3.6 Reliability The delivery of payload data to the destination is very reliable.
. neo.cortec 3.3.6.2 FHSS – Frequency Hopping Spread Spectrum The protocol uses FHSS to avoid noise and to ensure that the radio communication is not blocked by problems which are typically seen when operating on a fixed frequency, such as fading and blocking due to other radio communication equipment operating at the same frequency. Each time a node is sending its Scheduled Data Transmission (either with or without payload) it does so at the next channel in the hopping list.
. neo.cortec The WES server node will then send a message to the application layer (through the application API) with the UID such that the application can decide if the node who wants to be setup is allowed or not. If the application decides to allow the node to join, it shall provide the Node ID, which the joining node is supposed to have. This means that the application layer needs to make sure the nodes inside the network has unique Node ID’s.
. neo.cortec This is particularly useful in applications where for instance the node and the battery in its entirety will be moulded into for instance a plastic cavity to ensure efficient shielding from the environment. It could also be used in situations where the network is not required to be operational in longer periods of time, such that it would be beneficial to bring the entire network into hibernation mode. Hibernation is an additional state which the node can be in.
. neo.cortec The node(s) which is targeted for the wake up, shall be within radio range of the node who sends the Wake-Up Burst. 3.3.9.2 Local Wake-Up The application layer at a Node can command the node to transmit a Wake-Up Burst. This will only wake nodes which are within radio range. See integration manual for details on how to send Wake-Up Bursts. 3.3.9.3 Global Wake-Up A node can be configured to automatically transmit Wake-Up Burst depending on a set of configurable parameters.
. neo.cortec The Scheduled data can be configured to be two different values in Normal and Alternate mode. The Generic Application can be fully configured to perform two different tasks, depending on the mode. It could for instance be: Normal HTU21D, temperature and humidity measurements send to the gateway node once every 10 minutes Alternate RSSI application sends list of neighbours including the RSSI levels for each neighbour, to the gateway node once every 10 seconds.
. neo.cortec 3.4 Configurable Parameters In the following, all parameters, which affect the performance of the network as well as the individual node, is listed and explained. Each setting has an ID which is noted in its decimal value. This ID is used when configuring the module directly without the NeoCortec tools. NOTE: All parameters must be set to the same setting for all nodes in a given network.
. neo.cortec 3.4.1.3 Generic Application – Normal Mode ID: 25 This parameter controls the application layer when the network is operating in normal mode (see section 3.3.10 for details on Normal vs. Alternate mode). The setting value is best created using the Config Application – see section 4 for more details. 3.4.1.4 Generic Application – Alternate Mode ID: 58 This parameter controls the application layer when the network is operating in alternate mode (see section 3.3.10 for details on Normal vs.
. neo.cortec 3.4.1.8 AAPI Wakeup time ID: 52 Specifies the time from which the nWU pin transitions active (low) until the module starts to send data to the host controller. This value shall be set such that the external host has enough time to receive data, when waking up from the nWU active event. Possible values are 1…255, where 16 is default. The Wakeup time parameter is in steps of 30.5uS. The default value (16) corresponds to 488uS. 3.4.2 RF settings 3.4.2.
. neo.cortec Values 0xFFF0 to 0xFFFE are broadcast/groupcast ID’s and cannot be assigned to a particular node. The value 0xFFFF is special, and can be used for an unconfigured Node. A node with this value, will automatically enter into WES Client mode, and start scanning for a network which it can be set up for using the WES feature. 0xFFFF is also a broadcast/groupcast ID. 3.4.3.2 Network ID ID: 42 Specifies the ID of the network, which the node is configured for.
. neo.cortec 3.4.4.3 Scheduled Data Receive Retry Limit ID: 23 If a receive of scheduled data from a neighbour fails, a number of retries on subsequent transmissions are done. If the number of retries exceeds the limit set with this parameter, the neighbour is removed from the neighbour list. Valid values for this parameter is: 1..15. Typical values are in the range 2..10. 3.4.4.
. neo.cortec 3.4.4.7 Beacon Full Scan Rate Initial ID: 20 The rate of which full beacon scans are performed after power up. The setting is similar to Beacon Full Scan Rate, however this initial value is only used until the number of full beacon scans exceeds the Beacon Full Scan Count Initial parameter. The parameter can be set to the following values: 2..20. To get the rate in seconds, the values should be multiplied by the Beacon Rate. 3.4.4.
. neo.cortec 3.4.5.2 Node Inclusion Increment Speed ID: 28 Node inclusion speed determines how fast a node will try to acquire new neighbours. A high setting will make the node connect to neighbours more readily, but note that if this setting is too high, neighbour connections may happen too quickly: A node will connect to neighbours based on a contention system, and if many neighbours are present, this setting must be suitably low, not to cause too much contention.
. neo.cortec 3.4.6.2 Network Maximum Roundtrip Time ID: 65 Maximum network roundtrip time, or network roundtrip for short, is the time it takes a packet to get to a destination and the destination to return an ACK / NAK to originator. The roundtrip also accounts for queue delays, and local retries. Network roundtrip time is highly dependent on network topology, and may change for networks with the same n number of nodes but different topologies by a factor of 10 or even 100 or more for large n.
. neo.cortec TTL time resolution is 125 milli seconds, and valid values are [32..992] seconds, parameter setting [256..7.936]. 3.4.6.4 Payload Data Time to Live – TTL for unacknowledged Payload ID: 67 Similar to 3.4.6.3, but applicable for unacknowledged payload transmission including broadcast messages. TTL time resolution is 125 milli seconds, and valid values are [32..992] seconds, parameter setting [256..7.936]. When a unacknowledged payload package reaches TTL it will be removed from the network.
. neo.cortec 5 4,3 2 1 0 0: Do not hibernate even if there no Route to the ACM.
. neo.cortec Value 0 255 1-254 3.4.7.5 Behaviour No Wake Up burst are transmitted Depends on setting 3.4.7.1 ACM ID. If ACM ID is 0xFFFF, no bursts are send. If ACM ID is not 0xFFFF, bursts are send as long as the ACM is present in the network A number of wake up bursts will be send corresponding to the value set. Wake Up Burst length ID: 62 Defines the length of the wake up burst transmitted to wake up hibernating nodes. The values define the maximum length in seconds.
. neo.cortec 4 Application 4.1 Overview The NEOCORTEC protocol is designed such that zero involvement at the Application layer is needed in order for the network to function. The network will be created, and routes will be generated in the background as soon as the node is powered up. The application layer only has to interface with the node when payload data is being transmitted or received.
. neo.cortec 4.3 GPIO When selecting this application type, a settings window is brought up which allows the user to configure a range of parameters specific to this application: In the Common section of the window, the user can input 3 parameters: PreId: This value can be freely selected, and will be prepended to the payload package. This allows the receiver of the payload package to identify what configuration is used for this particular package, and as such be able to interpret the data.
. neo.cortec In the GPIO section of the window, the user can select what data gets transmitted in the payload package. The following parameters can be set: Pin assignment: For each pin, it can be configured to be either; Digital Input (default), Digital Output or Analog Input. Input Mask: If enabled for a particular pin, the digital state of the pin will be transmitted in the payload package. Pull / Tri-State: Each pin can be either Tri-Stated, or pulled up or down.
. neo.cortec 4.4 HTU21D This application is capable of reading temperature and humidity using the HTU21D sensor. The parameters that can be configured are as follows: PreId: This value can be freely selected, and will be pre-pended the payload package. This allows the receiver of the payload package to identify what configuration is used for this particular package, and as such be able to interpret the data. Destination NodeId: The 2 byte NEOCORTEC address of the destination node for the payload packages.
. neo.cortec 4.6 Payload Package format When using the applications that generate data on the module, and not through the UART interface, the Payload package is structured in different ways depending on the specific application: 4.6.
. neo.cortec 𝑇= (𝑂𝑢𝑡𝑝𝑢𝑡 𝑉𝑜𝑙𝑡𝑎𝑔𝑒[𝑚𝑉 ] − 𝑜𝑓𝑓𝑠𝑒𝑡 [𝑚𝑉 ]) 𝑚𝑉 𝑐𝑜𝑒𝑓𝑓𝑖𝑐𝑖𝑒𝑛𝑡[ ℃ ] Where offset and coefficient can be found from the table below: NC2400 NC1000/NC0400 Offset 2.43mV/°C 2.
. neo.cortec 4.6.2 HTU21D Field Length PreId 1 byte Temperature 2 bytes Humidity 2 bytes PreId: The byte configured as part of the setting Temperature: is reported as a 14-bit value, aligned towards msb. Before converting the value to a temperature reading, the 2 least significant bits should be set to 0. Humidity: is reported as a 12-bit value, aligned towards msb. Before converting the value to a humidity reading, the 4 least significant bits should be set to 0.
