Debug Module (moduleId 7)
Purpose
The Debug module contains a collection of commands to debug network problems and test our other functionality.
Functionality
The debug module does not perform a lot of functionality itself, but will mainly trigger actions from other moduels for debug purpose. It does however have a flooding mode implemented.
Terminal Commands
Resetting Nodes
Sometimes it is necessary to reset all nodes connected to a mesh at once. This is where the reset command comes in handy. After receiving the command, each node will wait a predefined time (about 10 seconds) that can be optionally modified. This ensures that the packet is sent to other nodes as well before resetting.
//Receiving nodes will reset within a few seconds
action [nodeId] debug reset {waitSeconds}Request Discover Buffer
To debug problems with discovery, we might want to get the JOIN_ME buffer from all nodes in a mesh.
//Receiving nodes will send back their buffer contents
action [nodeId] debug get_bufferPing
To find out the latency, we might want to ping some nodes. This command will only give usable results if one node is pinged at a time. It will not keep track of timings when pinging multiple nodes at once. Mode can be unreliable (write_cmd) or reliable (write_req).
//Sends a ping to a node and logs the time
action [nodeId] debug ping [count] [mode = r / u]
//Sends one ping message to nodeId 2 using write_cmd (unreliable)
action 2 debug ping 1 uPingPong
We can have a ping packet bounce multiple times between two nodes to get a better average of the ping.
//Bounces a ping back and forth multiple times
action [nodeId] debug pingpong [count] [mode]
//Bounces a packet back and forth 10 times between the current node and node 45
action 45 debug pingpong 10 uLeaf Ping
The leaf ping will send a ping command through the mesh starting from the current node. All leaf nodes will respond and the ping times will be logged on the terminal.
//Start the leaf ping
lping [count] [mode = r / u]Flooding
The DebugModule has a flooding mode where it will generate messages every once in a while. This is helpful for generating load on the network. Supported modes are: - Off (0): No flooding and no listening - Unreliable (2): Floods with WRITE_CMD packets - Listen (3): Listens for floods from given node and counts them - SplitData (4): Sends big messages that are split into multiple packets
//Activates a flooding mode to generate packets
action [nodeID] debug flood [destinationNodeId] [mode] [packetsPer100Sec]
//E.g. Tells node 1 to flood node 2 with 1 packet each second
action 1 debug flood 2 2 100
//E.g. instructs node 2 to count packets from node 1
action 2 debug flood 1 3 0Saving and Retrieving Records
It is possible to store, retrieve or delete a record by using the terminal on the local node. This will invoke the [RecordStorage](RecordStorage.adoc) class.
//Save record with given id and data
saverec [recordId] [hexString | base64String]
//E.g. saves or updates a record with id 1234 and data AA:BB:CC
saverec 1234 AA:BB:CC
//Get record with given id
getrec [recordId]
//Delete record with given id
delrec [recordId]Print Active Advertising Jobs
Prints the registered advertising jobs of the advertising controller.
advjobsFlash Memory Map
Prints a map of used flash memory blocks (1024 kb) where 0 is empty and 1 does contain data.
memorymap