This is the multi-page printable view of this section. Click here to print...

Return to the regular view of this page

As of 2025-07-24

TWELITE STAGE SDK

A package for configuring TWELITE, displaying data, and firmware development

1 - Installation Method

How to install the TWELITE STAGE SDK

Depending on the operating environment, various settings may be required for this application to function properly. If any issues arise, please refer to this document to prepare your environment.

Installation Procedure for TWELITE STAGE SDK

① Obtain the Archive

Download the TWELITE STAGE SDK for each platform (Windows / macOS / Linux) from Download.

② Extract the Archive

Extract the downloaded Zip archive.

③ Check the Files

Check the extracted folder.

The extracted folder {MWSTAGE Installation} contains the following:

  • TWELITE STAGE APP
    • For Windows: TWELITE_Stage.exe (standard version), TWELITE_Stage_VSCode.exe (VSCode compatible version)
    • For macOS: TWELITE_Stage.command (standard version), TWELITE_Stage_VSCode.command (VSCode compatible version)
    • For Linux: TWELITE_Stage.run (standard version), TWELITE_Stage_VSCode.run (VSCode compatible version)
  • TWELITE_STAGE - related files of TWELITE STAGE APP
  • MWSDK - libraries, source code, etc.
  • Tools - toolchains for building
  • BIN - .BIN files for TWELITE referenced by the [Select from BIN] menu of TWELITE STAGE APP
  • log - storage location for logs and database files of TWELITE STAGE APP
  • flask_wsns_db - simple server using Python, Flask, and sqlite3

For details, see “Folder Structure”.

1.1 - Folder Structure

About the folder structure of TWELITE STAGE APP

TWELITE STAGE APP operates as the frontend application of TWELITE STAGE SDK.

Here, we explain its folder structure.

MWSTAGE/            : TWELITE STAGE SDK installation
  TWELITE_Stage.??? : Executable (Windows .exe, macOS .command, Linux .run)
  TWELITE_Stage.sav : Configuration file
  TWELITE_Stage.ini : Other settings
  TWELITE_Stage/    : Related files of TWELITE STAGE APP

  MWSDK/            : MWSDK libraries etc.
  BIN/              : Storage destination when [Select BIN file] is used
  log/              : Log and database storage destination

  Tools/            : A set of tools including gcc compiler

  flask_wsns_db/    : Simple server using Python, Flask, sqlite3

MWSDK folder

MWSDK/
  Act_samples/        : Sample code using mwx library
  Wks_TweApps/        : Source code of TWELITE APPS
  Act_extras/         : More specialized samples using mwx library, and those referencing other libraries
  TWENET/             : TWENET library (mwx library etc.)
  ChipLib/            : Semiconductor library
  MkFiles/            : Core processing part of Makefile
  docs/               : Library manuals etc.
  LICENSE             : License description of MWSDK
  000manifest         : Version information of MWSDK
  ReleaseNotes.md     : Update history (top page)
  ReleaseNotes_en.md  : Update history (English)
  ReleaseNotes_jp.md  : Update history (Japanese)

The MWSDK folder contains libraries for building TWELITE software, samples, and source code of TWELITE APPS.

TWELITE_Stage.sav

Stores the configuration information of TWELITE STAGE APP.

The file name is the TWELITE STAGE APP executable name + .sav.

TWELITE_Stage.ini

Details of .ini file are here.

  • MWSDK= Edit this when you want to specify a different folder instead of the MWSDK/ folder. This is useful when mixing multiple library versions. In the above example, the MWSDK2020_10 folder is used.
  • LANG= Specify LANG=en to set the display language of TWELITE STAGE APP to English.

Running TWELITE STAGE APP with different settings

Copy TWELITE_Stage.exe (for Windows) with a different file name. For example, if changed to TWS1.exe, it refers to configuration files named TRS1.sav and TRS1.ini.

BIN folder

When selecting the [Select from BIN] menu in TWELITE STAGE APP, firmware files (.BIN) in this folder are used.

log folder

When running the serial port logging function in TWELITE STAGE APP, log files are stored in this folder.

This folder is also the storage destination for database files when using the graph function and for outputting csv files.

Tools folder

Contains cross-compiler toolchains such as gcc, g++.

Platform-specific utilities are also stored in this folder. For details, see Tools/readme.txt.

flask_wsns_db folder

Python sample script to access the database created by the sensor graph viewer of TWELITE STAGE APP. This sample allows viewing tables and graphs in a web browser.

For details, see flask_wsns_db/README.html.

Build project folder

Folder search order

TWELITE STAGE APP searches build project folders (Act_samples etc.) in the following order:

  1. The folder where TWELITE STAGE APP was started
  2. The folder where the TWELITE STAGE APP executable is located
  3. {MWSDK folder}/..
  4. {MWSDK folder}

Wks_Acts

If you create a Wks_Acts folder, this folder is referenced from the [act Build & Rewrite] menu instead of the Act_samples folder.

1.2 - Platform-specific Notes

Platform-specific notes for installation

This document describes notes to consider when installing the TWELITE STAGE APP on each platform.

1.2.1 - Notes When Installing on Windows

Notes when installing the TWELITE STAGE APP on Windows
Windows

Environment

The development and operation have been confirmed in the following environment.

  • Windows 10 Version 1903
  • Visual Studio 2019 (32bit build)

Handling of Serial Ports

MONOSTICK and TWELITE R series are equipped with FTDI’s USB serial conversion ICs (FT230/FT232 series). To use these, device driver installation may be required.

If the PC does not recognize MONOSTICK or TWELITE R, please install the D2XX driver from https://www.ftdichip.com.

Additional Installation of Visual C++ Runtime Library

In some cases, the Visual C++ redistributable code (runtime library) of Visual Studio 2019 is required.

If an error occurs when starting the application and it does not launch, run TWELITE_Stage¥INSTALL¥VC_redist.x86.exe distributed in this package, or obtain it from Microsoft’s website. Note that the redistributable binary is 32bit.

1.2.2 - Notes When Installing on macOS

Notes when installing the TWELITE STAGE APP on macOS
macOS

Environment

The development and operation have been confirmed in the following environments.

  • macOS 10.14 (Mojave, Intel)
  • macOS 12 (Monterey, Apple Silicon)

Installing Rosetta 2

Rosetta 2 is required for building applications for the BLUE / RED series.


/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Dependent Software and Warning Dialogs

If the following issues occur, permission to execute or installation is required for the operation of TWELITE_Stage.command.

  • Although the toolchain is code-signed, if the code signature is not properly verified, you may be prompted to allow execution individually for each executable in the build toolchain (such as ba-elf-gcc).
  • The downloaded archive is not signed. At runtime, security warnings may appear indicating that the application was downloaded from the Internet.
  • You may be asked to allow execution from the path where TWELITE_Stage.command is installed.
  • A dialog for installing the make utility may appear during build execution.

Additional Installation of make Utility

In some cases, you may need to install the make utility.

If an error occurs when running make from the command line (zsh), install the Command Line Tools.


xcode-select --install

Once the installation is complete, enter make and check for the following output message.


make
make: *** No targets specified and no makefile found.  Stop.

Handling Serial Ports

MONOSTICK and TWELITE R series are equipped with USB serial converter ICs (FT230/FT232 series) from FTDI (https://www.ftdichip.com). To use these, device driver installation may be required.

If the serial port does not appear even after launching TWELITE_Stage.command, please unload (disable) the FTDI driver.

You can download D2xxHelper from https://www.ftdichip.com/Drivers/D2XX.htm. The same is also included in the TWELITE_Stage/INSTALL folder of the TWELITE STAGE SDK.

Reference: Manual Unloading of FTDI Device Driver

To unload FTDI-related drivers, execute the following command.


sudo kextunload -b com.apple.driver.AppleUSBFTDI

1.2.3 - Notes When Installing on Linux

Notes when installing the TWELITE STAGE APP on Linux
Linux

Environment

Development and operation have been confirmed on the following environments.

  • Ubuntu 16.04, 18.04, 20.04
  • NNLinux Beta8 64bit
  • CentOS 7

Handling Serial Ports

To recognize MONOSTICK or TWELITE-R from TWELITE STAGE, you need to unload the ftdi_sio module and grant read/write permissions to the USB device.

We provide udev setting scripts (for Ubuntu, CentOS) to automate this configuration.

Copy the definitions to /etc/udev/rules.d and reload the settings. After setting, unplug and replug the USB device, then run TWELITE_Stage.run. If the USB device appears on the initial screen, the settings have been applied.

Ubuntu 16.04, 18.04, 20.04


cd ./MWSTAGE/TWELITE_Stage/INSTALL/ubuntu/
sudo ./set_udev_sudo.sh

Definition file (line breaks added for readability)

ACTION=="add",
   ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
   MODE="0666",
   RUN+="/bin/sh -c 'rmmod ftdi_sio && rmmod usbserial'"
ACTION=="add",
   ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015",
   MODE="0666",
   RUN+="/bin/sh -c 'rmmod ftdi_sio && rmmod usbserial'"

CentOS 7


cd ./MWSTAGE/TWELITE_Stage/INSTALL/centos/
sudo ./set_udev_sudo.sh

Definition file (line breaks added for readability)

ACTION=="add",
   ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
   MODE="0666",
   RUN+="/bin/sh -c '/usr/sbin/rmmod ftdi_sio'"
ACTION=="add",
   ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015",
   MODE="0666",
   RUN+="/bin/sh -c '/usr/sbin/rmmod ftdi_sio'"

Registering the Application

Register the application according to your desktop environment as needed.

Ubuntu 16.04, 18.04, 20.04

We provide a script to generate definition files for Ubuntu.


cd ./MWSTAGE/TWELITE_Stage/INSTALL/ubuntu/
./make_launch_icon.sh

This script creates a .desktop file (application definition) in $HOME/.local/share/applications.

After running the script, the TWELITE STAGE icon will be added to the application list.

1.2.4 - Notes When Installing on Raspberry Pi

Notes for installing the TWELITE STAGE APP on Raspberry Pi
RasPi

TWELITE STAGE APP runs on Raspberry Pi except for some models.

  • Supports mouse and touch screen.
  • Comes with a build toolchain, allowing compilation.
  • In addition to the X11 version executable, there is a framebuffer version (nox), as well as a lightweight version that omits translucent effects and others.

Environment

The development and operation have been confirmed in the following environment.

Hardware

  • Raspberry Pi 3 Model B
  • LCD Screen: Raspberry Pi Touch Display (7")

Software

  • Raspberry PI OS (32bit) Lite (Version: August 2020)

Known Issues and Limitations

  • On the first startup, /dev/serial0 may fail to operate.
  • Operation of /dev/serial0 on Raspberry Pi 4B has not been verified.
  • Operation of the touchscreen on Raspberry Pi 4B has not been verified.
  • Input strings to TWELITE STAGE are also passed as-is to shells or getty running on /dev/tty1. It is recommended to start from /dev/tty1.
  • It may be affected by other installed or running programs (such as X11).

Extracting the Archive

Extract the downloaded archive file into a folder whose path does not contain spaces or Japanese characters.

Below, it is extracted into the Raspberry Pi home folder.


cd /home/pi
unzip MWSTAGE2020_XX_YYYY.zip

Folder Structure

../MWSTAGE
     TWELITE_Stage.run    TWELITE_Stage app
     BIN/                 Firmware BIN files
     MWSDK/               MWSDK libraries, etc.
     TWELITE_Stage/       TWELITE_Stage app related files

Device Drivers

To recognize MONOSTICK or TWELITE R from TWELITE STAGE, it is necessary to unload the ftdi_sio module and grant read/write permissions to the USB device.

A udev configuration script is provided to automate this setting. Copy the definition to /etc/udev/rules.d and reload the settings. After setting, unplug and plug the USB device before running TWELITE_Stage.run. If the USB device is displayed on the screen immediately after startup, the setting has been applied.


cd ./MWSTAGE/TWELITE_Stage/INSTALL/ubuntu/
sudo ./set_udev_sudo.sh

Definition file (formatted with line breaks for readability)

ACTION=="add",
   ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
   MODE="0666",
   RUN+="/bin/sh -c 'rmmod ftdi_sio && rmmod usbserial'"
ACTION=="add",
   ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015",
   MODE="0666",
   RUN+="/bin/sh -c 'rmmod ftdi_sio && rmmod usbserial'"

Handling Serial Ports

In the above environment, /dev/serial0 can be used by configuring the serial port via raspi-config.


sudo raspi-config

From the menu

  "3 Interface Options    Configure connections to peripherals"
  →"P6 Serial Port Enable/disable shell messages on the serial connection"

Select as follows to disable login shell usage and enable hardware.

  "Would you like a login shell to be accessible over serial?" -> 
  "Would you like the serial port hardware to be enabled?" → 

Wiring Example

 [TWELITE]               [Raspberry Pi]
  GND  ------------------ Ground (#6,#9,#14,#20,#25,#30,#34,#39 one of these)
  TXD(DIO6,DIP#10) ------ GPIO15/UART0 RXD (#10)
  PRG(SPIMISO,DIP#7) ---- GPIO23 (#16)
  RXD(DIO7,DIP#3) ------- GPIO14/UART0 TXD (#8)
  RST(RESETN,DIP#21) ---- GPIO22 (#15)
  VCC  ------------------ 3V3 (#1,#17 one of these)
  SET(DIO12,DIP#15) ----- GPIO12 (#32)
  • Please refer to the manuals of both TWELITE and Raspberry Pi.
  • DIP# refers to the pin number of the TWELITE DIP.
  • The above wiring does not guarantee stable operation of TWELITE.

Starting TWELITE STAGE APP

  • The framebuffer version (nox) does not work on the X11 desktop. Please exit X11.
  • Run TWELITE_Stage.run. The TWELITE STAGE APP will be displayed on the screen.

Notes

  • Supports mouse and touch panel.
  • Input characters in the TWELITE STAGE APP may also be displayed on the console screen.

Others

/dev/dri Error

If the following error appears when starting TWELITE_Stage.run, you can ignore it.

  "The path /dev/dri/ cannot be opened or is not available"

Insufficient Memory

If the number of CPUs is 4 or more, parallel compilation will be executed with one less than the number of CPUs during build (3 parallel for 4 cores). Insufficient memory may occur in some cases. In that case, please change the number of parallel jobs.

Raspberry Pi 4

Raspberry Pi OS (bookworm)

2 - TWELITE STAGE APP

An application for building, rewriting, configuring, and displaying data.
TWELITE STAGE APP is an application for building and rewriting firmware, configuring TWELITE APPS, and displaying data. It is used with the evaluation and development environment TWELITE STAGE.

2.1 - TWELITE STAGE APP Manual

An application for building, rewriting, configuring, and displaying data
TWELITE STAGE APP is an application used for building and rewriting firmware, configuring TWELITE APPS, and displaying data. It is used in the TWELITE STAGE evaluation and development environment.

It operates on various platforms:

  • Windows 10
  • macOS (High Sierra or later, supports both Intel and Apple Silicon Macs)
  • Linux (Ubuntu 18.04)
  • Raspberry Pi (Raspberry Pi 3 Model B, LCD Touch Screen, Raspberry Pi OS August 2020)
  • (M5stack: Supported up to version 1.0. Versions 1.3 and later are not supported at the source level.)

※ Depending on the platform, operating conditions, distribution formats, and features may differ.

Root Menu

Root Menu

Real-time Acceleration Graph

Real-time Acceleration Graph

About this Document

  • To indicate the target platforms, some pages specify the following:
    • Windows   – Windows 10
    • macOS   – Mac OS X, OS X, macOS
    • Linux   – Ubuntu, etc. (64bit)
    • RasPi   – Raspberry Pi

2.1.1 - Obtaining the Package

How to obtain TWELITE STAGE APP

The latest TWELITE STAGE app can be obtained by one of the following methods.

Entire TWELITE STAGE SDK (Official Website)

The Mono Wireless official website distributes a complete set of development tools (for Windows/macOS/Linux), including the TWELITE STAGE app.

TWELITE STAGE-トワイライトステージ - MONO-WIRELESS.COM

TWELITE STAGE App Only (GitHub)

The Mono Wireless official repository distributes the standalone binary of the TWELITE STAGE app. Please use this if you want to update only the TWELITE STAGE app or obtain the M5Stack version. The version of each binary can be identified from the tags on GitHub.

Windows

monowireless/TWELITE_Stage_BIN_Win: Binary Distribution of TWELITE Stage.

macOS

monowireless/TWELITE_Stage_BIN_macOS: Binary distribution of TWELITE Stage for macOS

Linux

Linux binaries are not distributed separately. Please obtain binaries from the TWELITE STAGE SDK package or build from source code.

Raspberry Pi

Raspberry Pi binaries are not distributed separately. Please obtain binaries from the TWELITE STAGE SDK package or build from source code.

M5Stack

Versions up to 1.0.3a are distributed on the following page.

monowireless/TWELITE_STAGE_Bin_M5Stack

Source Code (MWM5 Library)

The MWM5 library, including the source code of TWELITE STAGE, is published on the following page.

monowireless/mwm5

The source code of the TWELITE STAGE app is placed in examples/TWELITE_Stage.

2.1.2 - How to Use

How to use TWELITE STAGE APP
This section explains the screens and operation methods of the TWELITE STAGE APP.

How to Launch the App

To launch the TWELITE STAGE app, execute the executable file located in {MWSTAGE Installation}.

The method of execution varies depending on the platform (Windows, macOS, Linux).

SystemExtensionNotes
Windows.exeDouble-click the executable file in Explorer
macOS.commandDouble-click the executable file in Finder
Linux RasPi.runDepends on the distribution and installation environment.
Execute as a command from a terminal window (such as xterm) on the X Window System

Executable Types of the App

The TWELITE STAGE APP has two types of executables.

  • TWELITE_Stage.{extension} - Launches with standard settings.
  • TWELITE_Stage_VSCode.{extension} - Configured to “Use VSCode” (settings saved in TWELITE_Stage_VSCode.ini). When the VSCode usage setting is enabled, the app operates in a way suitable for development work using VSCode.

App Interface

When you launch the app, two types of windows are displayed:

  • Main Window
    • Displays the user interface of the TWELITE STAGE APP.
      • The serial port under connection (e.g. TWELITE-R or TWELITE STICK) is displayed in the title bar.
    • All operations of the TWELITE STAGE APP are performed within this window.
      • Press the ALT (Cmd) key to display the operating aid screen.
      • The [ A ] [ B ] [ C ] buttons appear at the bottom of the screen and are used for operation. These buttons can be pressed and held down to call up sub-functions.
  • Command Window
    • Usually not used, but displays auxiliary information.
      • Shows serial communication content, making it ideal for checking logs.
      • When launched from the command line, the originating terminal acts as the command window.
Example Screen of TWELITE STAGE APP

Example Screen of TWELITE STAGE APP

Exiting the App

Exit the app by any of the following methods:

  • Move the mouse pointer to the upper right of the execution screen and press the exit button displayed within the screen.
  • Close the app window (on macOS, ⌘Q can also be used).

2.1.2.1 - Key and Mouse Operations

Key and mouse operations for TWELITE STAGE APP

Windows   macOS   Linux   RasPi

This section explains the key and mouse operations used in TWELITE STAGE APP.

Key Operations

Windows   macOS   Linux   RasPi

Key inputs performed while holding down Alt (Cmd) are assigned to operations such as changing the settings of TWELITE STAGE APP. Other key operations generally function as normal text input.

Common Keys

Windows   macOS   Linux   RasPi

KeyMeaning
ESC ESCQuickly press ESC twice. Cancel or return to the previous screen.
On some screens, pressing once returns to the previous screen.
ENTEREnter, Select
BSDelete one character
Cursor Keys
Select item

Help Screen

Windows   macOS   Linux   RasPi

Hold down Alt (Cmd) to display the help screen. The help screen shows explanations of keys that can be used together with Alt (Cmd) and some operational status.

The help screen can also be displayed by moving the mouse pointer to the top-left corner of the screen.

Help Screen

Help Screen

Alt (Cmd) + Operations

Windows   macOS   Linux   RasPi

This section explains operations performed while holding down Alt (Cmd).

In the table below, the Alt (Cmd)+ prefix is omitted. You can check the available keys from the help screen above, but supplementary explanations are provided in the table below.

Alt (Cmd)+ KeyMeaning
IInputs + + +. This is the key sequence to enter interactive mode.
※ Apps that perform intermittent operation due to sleep are not supported.
RResets the module. Controls the reset pin using the functions of TWELITE R or MONOSTICK.
A, S, DPress buttons A, B, C.
Shift+A, S, DLong press buttons A, B, C.
CCopies the text displayed on the screen to the clipboard. (The range varies depending on the screen)
VPastes from the clipboard as keyboard input.
FSwitches to full-screen display. If Shift+F is pressed, it enlarges further if possible.
GChanges the screen rendering method. It emulates a 640x480 LCD screen, but for enlargement, four rendering styles can be selected: (1. LCD monitor style / 2. CRT style / 3. Enlarged with dots emphasized / 4. Enlarged with dots blurred).
※ You can change the startup setting in the settings menu.
JSelects the screen size. Available sizes are {640,480}, {1280,720}, {1280,960}, {1920,1440}, {2560,1440}, {320,240}.
※ Can be set as startup setting in the settings menu.
QQuits TWELITE STAGE APP.
0Disconnects the serial port and shows the list of serial ports again.
1, 2, …Selects the serial port.
BChange baud rate if serial port is open (9600, 19200, 38400, 57600, 115200, 234000).
L, Shift+LStarts logging serial port input/output. When finished, the log file opens with Notepad on Windows or Log Viewer on macOS. Shift+L opens the log storage folder.

Other Operations

KeyMeaning
Alt (Cmd)+Shift+Ctrl+mOpens the MWX library code folder.
Alt (Cmd)+Shift+lOpens the log folder.

Mouse Operations

Windows   macOS   Linux   RasPi

Mouse operations mainly involve left-clicking, but right-click, right double-click, and the scroll wheel may be used.

Mouse OperationMeaning
Left clickSelect
Left click and dragUsed on some screens (e.g., dragging on graph screens)
Left double-clickNot used
Right clickUsed on some screens
Right double-clickExit the screen (same as ESC ESC)
Scroll wheelUsed on some screens (e.g., zoom in/out on graph screens)

Mouse Control of A, B, C Buttons

Windows   macOS   Linux   RasPi

When you move the mouse pointer to the menu display at the bottom of the screen, buttons labeled [ A ], [ B ], and [ C ] appear. TWELITE STAGE APP assigns functions of the hardware buttons arranged in this way to each screen. You can call the functions by left-clicking or long-pressing these buttons. (They can also be selected with Alt (Cmd)+a,s,d or Alt (Cmd)+Shift+a,s,d)

Example of virtual [ B ] button displayed at the bottom of the screen

Example of virtual [ B ] button displayed at the bottom of the screen

Mouse Control of Screen Operations

Windows   macOS   Linux   RasPi

On Windows/macOS/Linux, TWELITE STAGE APP screens are basically composed of text only, but menus, buttons, and tabs can be operated with the mouse.

Example of Commander Screen

Example of Commander Screen

The screen consists of text only, but the tabs at the top of the screen and inverted text can be selected by left-clicking with the mouse.

2.1.2.2 - Screen Operations

Operation instructions for each screen of TWELITE STAGE APP

Windows   macOS   Linux   RasPi

Example of the menu screen

Example of the menu screen

Windows / macOS / Linux / Raspberry Pi

TWELITE STAGE APP is an application launched from the console screen (command line). It outputs information to both the console screen and window screen.

The console screen displays UART output similar to a terminal.

Raspberry Pi (nox)

Displays on the framebuffer without using X11.

Normally (when started from a shell screen on the framebuffer), the console screen is not displayed.

2.1.2.2.1 - Serial Port Selection

Operation instructions for the serial port selection screen

Windows   macOS   Linux   RasPi

Overview

On Windows / macOS / Linux, a screen to select the serial port connected to TWELITE is displayed at startup. However, the serial port can also be connected later.

Example of the serial port selection screen

Example of the serial port selection screen

Windows

Press the c key to display the COM port name of the serial port currently highlighted in the list.

Raspberry Pi

On Raspberry Pi, in addition to USB devices, if /dev/serial0 and /dev/serial1 exist, serial0 and serial1 will be displayed. Normally, serial0 is used.

2.1.2.2.2 - Main Menu

Operation instructions for the main menu screen

Windows   macOS   Linux   RasPi

This is the top level of the hierarchical menu.

Example of the main menu screen

Example of the main menu screen

On this screen, you select a menu. When a menu is highlighted, a brief explanation is displayed in green text at the bottom.

  • Viewer: A viewer that interprets and displays packets received from TWELITE. In many cases, the receiving TWELITE is programmed with App_Wings.
  • Write Firmware: Build the firmware and write it to the connected TWELITE.
  • Interactive settigns mode: Configure the connected TWELITE settings via interactive mode.
  • Settings of TWELITE STAGE: Configure various settings of the TWELITE STAGE app.
  • Select SERIAL port: Select the serial port.
  • Open MANUAL: Menu to display manuals. Opens the following manuals in a browser:
    • TWELITE STAGE App (this document)
    • MWX Library
    • TWENET_C Library

2.1.2.2.2.1 - Viewer

About the viewer

Windows   macOS   Linux   RasPi

The viewer is a feature for displaying information received from a connected TWELITE and sending commands.

2.1.2.2.2.1.1 - Terminal

Operation instructions for the Terminal screen

Windows   macOS   Linux   RasPi

Example of the Terminal screen

Example of the Terminal screen

Overview

A general VT100-compatible serial terminal.

Supports TWELITE interactive mode and reset control.

Operations

OperationDescription
[ A ]Input the + + + sequence (interactive mode)
[ A ]
Long press
Exit this screen and return to the previous menu.
[ B ]Display a partial area of the first screen with a larger font.
The area is selected so that the cursor is visible on the screen, but depending on the screen output, the desired part may not be visible.
[ B ]
Long press
Toggle word wrap ON/OFF.
By default, word wrap is enabled, but you can also display without wrapping. Characters beyond the right edge of the screen will not be displayed.
[ C ]Move to the firmware update screen.
During firmware development, source code modification, operation check, build & write are frequently performed, so a shortcut is provided.
[ C ]
Long press
Control and reset the TWELITE reset pin.
ESC ESCPress the ESC key twice quickly to exit this screen.
※ In most screens, pressing the ESC key once exits the screen, but in the terminal, a single ESC key input is used for other purposes, so double input is assigned.

2.1.2.2.2.1.2 - Standard App Viewer

Operation instructions for the Standard App Viewer screen

Windows   macOS   Linux   RasPi

Example of the Standard App Viewer screen

Example of the Standard App Viewer screen

Overview

The TWELITE communicating partner should have App_Twelite (Standard App) programmed. When a message indicating the status of buttons or analog inputs of the Standard App (0x81 message) is received, its contents are interpreted and displayed using the mwm5 parser library.

Operations

OperationDescription
[ A ]No assignment
[ A ]
Long press
Exit this screen and return to the previous menu.
[ B ]Change the font.
[ B ]
Long press
Display the screen with test dummy data.
[ C ]No assignment
[ C ]
Long press
Control the reset pin of the TWELITE to reset it.
ESC ESCPress the ESC key twice to exit this screen.

2.1.2.2.2.1.3 - Graph

List of graph screens
  • Accelerometer Real-Time Graph: Displays accelerometer sensor packets in real time. Frequency domain display and CSV file saving are available.
  • Sensor Graph: Saves data from various TWELITE sensors into an sqlite3 database and displays graphs.

2.1.2.2.2.1.3.1 - Accelerometer Real-Time Graph

Operation instructions for the Accelerometer Real-Time Graph screen

Windows   macOS   Linux   RasPi

Example Display of Demo Data

Example Display of Demo Data

Overview

This refers to packets received from TWELITE CUE and TWELITE Motion Sensor PAL. It can display accelerometer data in real-time, and includes features for frequency analysis and CSV export.

It supports three modes: CUE mode, MOT mode, and 2525 FIFO mode.

When a continuous series of samples reaches a certain number (analysis window), frequency analysis of the XYZ axes is displayed. However, in 2525 FIFO mode, it is assumed to be always continuous.

When packet boundaries are explicit (e.g., when more than 3 seconds have elapsed since the previous packet, in CUE mode for each packet, or in MOT mode when the packet sequence number is discontinuous), four dummy samples are inserted and a pink background is shown.

Data from up to four nodes are stored on a first-come, first-served basis.

Operation

OperationDescription
Top right
(i)ID# button
Click to switch the ID.
(Note: Continuous sample data in FIFO mode is not suitable for multi-ID operation)
Top right
(f)SMP# button
Click to change the analysis window size among 64, 128, and 256.
Bottom right
(c)Save Display Data button
Exports data in CSV format to the log folder.
Outputs from the oldest sample in the buffer to the latest sample at the right edge of the screen.
(Note: The output is always 5120 samples, with the latest data at the end)
Bottom right
PAUSE( ) button
Pauses display updates.
(Note: Samples are still collected until the internal temporary sample buffer is full)
Mouse drag
(Graph area)
Moves the position of displayed samples.
Mouse drag
(Bottom scrollbar)
Moves the displayed sample position in larger steps.
Arrow keys
Moves the sample display area.
Arrow keys
Zooms in/out on the horizontal axis of samples (1x / 2x / 3x / 4x).
(Note: Up to 2x when the analysis sample count is 256)

Sample Rate Estimation

The sampling rate is calculated from the packet reception times. It averages the reception times of multiple past samples to estimate one sample interval, so packet drops may cause significant errors. Also, the related log timestamp (T_SMPL) is an estimated value and is delayed compared to the packet acquisition time. Once sample rate estimation completes, graph scrolling becomes smooth.

Opening the CUE Graph Mode on Startup

Specify 31 in [STAGE Common Settings → Startup App Selection].

Log Output (Save Display Data)

Pressing the (c) Save Display Data button outputs up to 512 samples starting from the current display position (rightmost sample).

Log file name is {log folder}/acc_snap_{timestamp}.csv.

  • Data has the newest sample at the right edge as sample number 512 (file end).
  • When frequency analysis is performed, the last samples used for frequency analysis are included.
  • Frequency analysis results are added to rows containing frequency analysis target samples (for 64 samples, results appear from sample 449 for 32 rows, showing from DC to high frequency components).
LabelItem NameDescription
#Sample
Number
T_PKT[ms]Packet
Reception Time
Multiple samples may be included in one packet, so samples with the same timestamp are listed.
SEQPacket
Sequence Number
Assigned to each packet; continuity indicates no packet loss.
T_SMPL[ms]Sample
Time (Virtual/Estimated)
Timestamp generated for each sample from packet reception time.
Does not match the actual sampling time.
(Note: Sample rate is estimated from packet reception intervals, and sample times are cumulatively added, so timestamps are delayed by one packet interval compared to actual sample time)
X[G]X-axis Sample ValueUnit is G. Based on sensor values.
Y[G]Y-axis Sample ValueUnit is G. Based on sensor values.
Z[G]Z-axis Sample ValueUnit is G. Based on sensor values.
FD#Frequency Analysis Calculation IndexFor 64 samples, ordered as DC,1,2,...,31.
HzFrequency Analysis Frequency Axis ValueEstimated frequency, calculated as (FD# / FD_Len) * FD_Freq.
XFrequency Analysis Value on X-axis
YFrequency Analysis Value on Y-axis
ZFrequency Analysis Value on Z-axis
LabelAdditional Info NameSee table below
InfoAdditional InfoSee table below

Additional Information

Info NameDescription
ModuleSIDSerial number of the sender
Tick[ms]System time when the log file was opened
(Note: TWELITE STAGE app side)
DateDate when the log file was opened
TimeTime when the log file was opened
Time_Msec_partSub-second part of time when the log file was opened [ms]
SamplesValid sample data
FD_LenFrequency analysis sample count
FD_Start#Frequency analysis start sample number
FD_FreqEstimated frequency range for frequency analysis [Hz]
(Note: estimated from sample reception interval)

Log Output (Auto Save)

When the Accelerometer Real-Time Graph screen is opened and data is input, log files are automatically saved.

Log file name is log folder/accel_{serial number}_{timestamp}.csv.

LabelItem NameDescription
#Sample
Number
T_PKT[ms]Packet
Reception Time
Multiple samples may be included in one packet, so samples with the same timestamp are listed.
SEQPacket
Sequence Number
Assigned to each packet; continuity indicates no packet loss.
T_SMPL[ms]Sample
Time (Virtual/Estimated)
Timestamp generated for each sample from packet reception time.
Does not match the actual sampling time.
(Note: Sample rate is estimated from packet reception intervals, and sample times are cumulatively added, so timestamps are delayed by one packet interval compared to actual sample time)
X[G]X-axis Sample ValueUnit is G. Based on sensor values.
Y[G]Y-axis Sample ValueUnit is G. Based on sensor values.
Z[G]Z-axis Sample ValueUnit is G. Based on sensor values.
LabelAdditional Info NameSee table below
InfoAdditional InfoSee table below

Additional Information

Info NameDescription
ModuleSIDSerial number of the sender
Tick[ms]System time when the log file was opened
(Note: TWELITE STAGE app side)
DateDate when the log file was opened
TimeTime when the log file was opened
Time_Msec_partSub-second part of time when the log file was opened [ms]

2.1.2.2.2.1.3.2 - Sensor Graph

Operation instructions for the Sensor Graph screen

Windows   macOS   Linux   RasPi

Example of data display

Example of data display

Overview

Various sensor data are recorded in an SQLite database and displayed on the screen in graph format. The database file can also be accessed by external applications.

  • The database uses SQLite (sqlite3) and is stored in the file {MW_STAGE Install}/log/{executable_name}_WSns.sqlite.
  • Screen navigation is [List (with graph preview)] > [24-hour Data] > [Live View].
    • From [24-hour Data], you can further navigate to [Year], [Month], and [Day (with graph preview)] selection screens.
  • About the [Live] display screen:
    • Select a specific node from the list.
    • Displays real-time data every second, showing data from the past 450 seconds.
  • About the [24-hour Data] display screen:
    • Displays data for a specific day.
    • Updates every second; if multiple data points occur during that time, some are thinned out.
    • Except at maximum zoom (1 pixel = 1 second), the average value for the data within each pixel range is displayed.
    • If values exceed the screen, measurement points are shown at the top or bottom edges.
    • If the current time is included, the display updates with new data.
    • Mouse wheel or cursor keys and : zoom in/out on the time axis.
    • Moving the mouse pointer: briefly displays the data corresponding to the time under the pointer.
      • Cursor keys and : move to the adjacent data point.
    • Mouse click & drag: scroll (only when zoomed).
    • When zoomed, scrollbar operation is also possible.
    • The [CSV Export] function outputs all data in the database.

Operations

OperationDescription
Mouse drag
(graph area)
Move the displayed sample position when zoomed.
Mouse drag
(bottom scrollbar)
Move the displayed sample position.
Cursor keys
Move the sample display area.
Cursor keys
Zoom in/out on the sample horizontal axis.
[Live]Switch to the view displaying the latest data updated every second.
[24-hour Data]Switch to the daily graph view.
[<<List]Switch to the list selection screen.
[Year] [Month] [Day]Select a specific date by year, month, and day.
[Latest]Switch to today’s data.
[CSV Export]Export one day’s data to a CSV file.
In the list, [Display]Change the list display mode.
In the list, [Sort]Change the list sorting order.
In the list, [↑]Reverse the list sorting order.

Editing Sensor Node Notes (Supplementary Information)

v1.3.9+

In the “24-hour Data” screen, left-clicking on the sensor node’s note area at the top right of the screen allows you to edit the note using a prompt.

Editing sensor node notes

Editing sensor node notes (IME enabled)

KeyDescription
Normal half-width charactersIf you directly enter normal half-width alphanumeric characters, they are displayed on the screen.
Input via IMEInput from IME is displayed as intermediate characters at the top left of the screen.
Press ENTER to confirm the input string.
BSDeletes the last character displayed.
ENTERReflects the entered string in the database.

Screen Navigation

The basic screens are divided into three types: List, 24-hour, and Live.

[List] <--> [24-hour] <--> [Live]
              ↓↑
          [Year/Month/Day Selection]

Starting Sensor Graph Mode on Launch

Specify 32 in [STAGE Common Settings → Launch App Specification].

About the Database Tables

sensor_data

Stores received data.

Column NameTypeDescription
_uqidINTEGERSequential number used in the database
sidINTEGER
int32_t
Serial number stored as int32_t type.
For example, a serial number “8123abcd” is stored as the integer value -2,128,368,691.
tsINTEGER
int64_t
Timestamp when the system received the packet, stored as int64_t.
UNIX epoch (seconds since 1970).
ts_msecINTEGERMilliseconds part of the timestamp.
yearINTEGERYear part of the local time from the timestamp.
monthINTEGERMonth part of the local time from the timestamp.
dayINTEGERDay part of the local time from the timestamp.
hourINTEGERHour part of the local time from the timestamp.
lidINTEGERIdentifier such as LID assigned by the user.
lqiINTEGERLink Quality Indicator, an estimate of reception strength.
pkt_seqINTEGERPacket sequence number. The range of values depends on the firmware.
pkt_typeINTEGERType of wireless packet.
2 PAL AMB 6 ARIA 1 PAL MAG *3 PAL MOT 5 CUE 0x101 App_Twelite *0x103 App_IO
*Currently unsupported types
valueREALMeasured value (definition varies by packet type).
pkt_type->
2,6: Temperature [°C]
1: Magnet detection (00->No magnet, 01->N pole, 02->S pole)
3,5: X-axis acceleration (average if multiple samples in packet) [G]
0x101,103: Input IO bitmap (same as lower 8 bits of val_dio)
value1REALMeasured value (definition varies by packet type).
pkt_type->
2,6: Humidity [%]
1: Unused
3,5: Y-axis acceleration (average if multiple samples in packet) [G]
0x101: ADC1 [V]
103: Unused
value2REALMeasured value (definition varies by packet type).
pkt_type->
2: Illuminance [lx]
6: Unused
1: Unused
3,5: Z-axis acceleration (average if multiple samples in packet) [G]
0x101: ADC2 [V]
103: Unused
value3REALMeasured value (definition varies by packet type).
pkt_type->
2: Unused
6: Unused
1: Unused
3,5: Unused
0x101: ADC3 [V]
103: Unused
val_vcc_mvINTEGERPower supply voltage [mV]
val_dioINTEGER
int32_t
b0..b7: Values of DI1..DI8 (1 is LOW, 0 is HIGH level)
b24..b25: Magnet value (if b28 is 1): 00->No magnet, 01->N pole, 10->S pole
b28: If 1, magnet data is stored in b24..b25
b31: Periodic transmission bit (magnet only)
val_adc1_mvINTEGERADC1 measurement value for pkt_type->
1,2,3,0x101
val_adc2_mvINTEGERADC4 measurement value for pkt_type->
0x101
val_auxINTEGERFor storing other data
ev_srcINTEGEREvent source
ev_idINTEGEREvent ID
pal_type->
5: Dice (1...6)
16→MOVE etc.Refer to documentation
ev_paramINTEGEREvent parameter

sensor_node

Stores text notes (supplementary information) for sensor nodes.

Column NameTypeDescription
sidINTEGERSID as described above
sid_textTEXTString representation of SID converted to hexadecimal for readability
descTEXT
UTF-8
Note (supplementary information) corresponding to the SID, displayed in lists, etc.

sensor_last

Manages the timestamp of the last received data.

Column NameTypeDescription
sidINTEGERSID as described above
tsINTEGERTimestamp of the last reception
lidExcerpt of data from the last reception below
lqi
pkt_type
value
value1
value2
value3
val_vcc_mv
val_dio
ev_id

2.1.2.2.2.1.4 - Simple Monitor

Simple Monitor list
  • CUE Viewer: Interprets packets from TWELITE CUE and displays them simply
  • ARIA Viewer: Interprets packets from TWELITE ARIA and displays them simply
  • Glancer: A simple monitor supporting many formats of TWELITE

2.1.2.2.2.1.4.1 - CUE Viewer

Operation instructions for the CUE Viewer screen

Windows   macOS   Linux   RasPi

Example of Dice Face Detection

Example of Dice Face Detection

Overview

Interprets and displays messages received from TWELITE CUE.

Operation of TWELITE CUE

The factory default setting of TWELITE CUE is configured to CUE mode.

In CUE mode, it operates intermittently to enable coin cell battery operation, waking from sleep due to several factors and transmitting various data.

Wake-up Factors

TWELITE CUE requires one of the following factors to wake from sleep:

  • Wake-up by timer (periodic wake-up)
  • Wake-up by acceleration detection
  • Wake-up by magnetic sensor (when a magnet is detected nearby)

Types of Data Transmitted

TWELITE CUE sends the following data in packets:

  • Detection events (see below)
  • Module power voltage
  • Magnetic sensor detection value
  • Acceleration data

Packet Attributes

The attributes of received packets provide basic information.

AttributeDescription
#????The count of received packets so far.
TypePacket type as the value of E_PKT in the mwm5 library.
Packets from TWELITE CUE are usually PKT_PAL=02.
IDLogical ID of the sender, usually a value from 0..100.
ADSerial number of the sender.
LQApproximate reception strength (Link Quality Indicator).
SQSequence number of the packet.

Events

In CUE mode, acceleration events are always output. Regardless of the wake-up factor, a fixed number of acceleration samples are measured after waking. Events are determined based on the acceleration measurement results.

EventNumberDescription
Dice1(0x00) .. 6(0x06)Determined based on periodic wake-up and magnetic sensor wake-up.
If a large acceleration is detected after waking,
an undetermined event (0xFF) may be detected.
Move16(0x10)Occurs when the acceleration sensor detects acceleration above a threshold,
resulting in a move or shake event.
Move occurs when the measured acceleration change is relatively small,
(acceleration change detected but no continuous acceleration change).
Shake0x08Occurs when the acceleration sensor detects acceleration above a threshold,
resulting in a move or shake event.
Shake occurs when the measured acceleration change is relatively large,
(continuous acceleration changes detected).

Voltage

Power supply voltage of the module [mV].

Magnet

Displays the detected magnetic pole or no detection.

Acceleration

Displays acceleration measured after waking.

  • Samples: Displays the number of acceleration samples, fixed at 10 samples.
  • Rate ID: Sample rate of acceleration, fixed at 04 (100Hz).
  • X, Y, Z: Acceleration on three axes. Calculated as the average of 8 samples. Unit is milli-G (1000mG = 1G = 9.8m/s²).

Example Screens

Example of Move Event Detection

Example of Move Event Detection

Example of Shake Event Detection

Example of Shake Event Detection

2.1.2.2.2.1.4.2 - ARIA Viewer

Operation instructions for the ARIA Viewer screen

Windows   macOS   Linux   RasPi

Example display of temperature and humidity data table

Example display of temperature and humidity data table

Overview

Interprets and displays messages received from TWELITE ARIA.

Operation of TWELITE ARIA

The factory default setting of TWELITE ARIA is TWELITE ARIA mode.

In TWELITE ARIA mode, it operates intermittently to allow coin battery power, waking from sleep due to several factors, and sending various data.

Wake-up Factors

TWELITE ARIA requires one of the following factors to wake from sleep:

  • Wake-up by timer (periodic wake-up)
  • Wake-up by magnetic sensor (when a magnet is detected nearby)

Types of Data Sent

TWELITE ARIA sends the following data packed in a packet:

  • Module power supply voltage
  • Magnetic sensor detection value
  • Temperature and humidity data

Packet Attributes

Basic information can be obtained from the attributes of the received packet.

AttributeDescription
#????Number of packets received so far.
TypePacket type based on the E_PKT value in the mwm5 library.
Packets from TWELITE ARIA are usually PKT_PAL=02.
IDLogical ID of the sender. Usually a value between 0..100.
ADSerial number of the sender.
LQApproximate received signal strength (Link Quality Indicator).
SQPacket sequence number.

Temperature and Humidity Data Table

Displays the history of the last 9 data packets received from TWELITE ARIA. The latest data is displayed at the top.

Time [s]

Time [seconds] from when the TWELITE STAGE APP started until the data was received.

ID

Logical device ID of the module.

VCC (mV)

Power supply voltage of the module [mV].

Temperature (°C)

Temperature measured by the module (°C).

Humidity (%)

Humidity measured by the module (%).

Magnet

Displays the detected magnetic pole or no detection.

2.1.2.2.2.1.4.3 - Glancer

Operation instructions for the Glancer screen

Windows   macOS   Linux   RasPi

Overview

Glancer provides a simplified display of the information contained in received messages.

By programming the connected TWELITE with App_Wings, it can display information received from communication partners’ TWELITE devices (App_Twelite, TWELITE PAL, … as long as the application ID and frequency channel match, mixed operation is possible).

Operation

Use by switching between the list display screen and the selection display screen.

List Display

Example of list display

Example of list display

Lists information from communication partners.

Displayed content includes message type, logical device ID, serial ID, LQI (Lq), power voltage (if included in the information), and timestamp.

OperationDescription
[ A ]Move to the previous item in the list.
[ A ]
Long press
Exit this screen and return to the previous menu.
[ B ]Switch to selection display.
[ B ]
Long press
Sort items.
The sort key changes sequentially each time sorting is performed.
[ C ]Move to the next item in the list.
[ C ]
Long press
Control the TWELITE reset pin and reset it.
ESCExit this screen.

Selection Display

Example of selection display

Example of selection display

By moving items and highlighting one in the list display, then performing a selection operation, you transition to this screen. It shows information related to a specific communication partner in order of arrival.

The number of received packets and the average LQI since selection are displayed.

OperationDescription
[ A ]No assignment
[ A ]
Long press
Exit this screen and return to the previous menu.
[ B ]No assignment
[ B ]
Long press
No assignment
[ C ]No assignment
[ C ]
Long press
Control the TWELITE reset pin and reset it.
ESCReturn to the list display screen.

2.1.2.2.2.1.5 - Commander

Operation instructions for the Commander screen

Windows   macOS   Linux   RasPi

Overview

Commander is a feature to send serial messages to TWELITE.

Operation

The first screen of the Commander displays important notes.

At the top of the screen, there are tabs represented by text, which you can navigate by clicking with the mouse to switch between tab screens.

OperationDescription
[ A ]Move tab (left)
[ A ]
Long press
Exit this screen and return to the selection screen.
[ B ]No assignment
[ B ]
Long press
No assignment
[ C ]Move tab (right)
[ C ]
Long press
Control the reset pin of TWELITE to reset it.
ESCExit this screen and return to the selection screen.

Tab: TWELITE

This screen generates and sends the 0x80 command of the Standard App (App_Twelite).

Make sure the connected TWELITE has App_Twelite or parent/relay app (App_Wings) programmed, and after setting the application ID and channel, confirm that messages are being received from the communication partner.

Example display of the TWELITE tab

Example display of the TWELITE tab

ItemDescription
DestinationSpecify the TWELITE to send to.
If you are a child device, specify “Parent:0”.
If you are a parent device, specify “All children = 0x78” or a specific child ID (can be specified from 1 to 8).
DI1..DI4Settings state from DI1 to DI4.
■ means selected (LOW = GND level), □ means (HIGH = VCC level).
Please specify SEL in the next item.
SELSelection bits for each DI.
(If 0, the DI specification is ignored; if 1, the specification is enabled.)
PWM1..4Set the PWM duty ratio.
0 corresponds to GND level, 1024 (100%) corresponds to VCC level.
PWM ports set to N.A. will not be changed.
(Note: On the MW-STA-KIT-0/MW-STA-SOLO-0 boards, PWM1 is pulled up to VCC, so the LED lights brightest at 0 and turns off at 100%.)

Tab: NOTICE

This screen generates the LED control command of the Notification PAL (NOTICE PAL).

Make sure the connected TWELITE has App_Wings programmed, and after setting the application ID and channel, confirm that messages are being received from the communication partner.

Example display of the NOTICE tab

Example display of the NOTICE tab

ItemDescription
DestinationSpecify the ID of the TWELITE PAL to send to.
Valid range is 1 to 8.
ColorSpecify the lighting color from 7 colors.
There are two types of white: one is RGB mixed color, and the other is a single white LED lit.
BrightnessSpecify from 0 to 15. 0 means off.
Lighting/BlinkingSelect lighting or blinking pattern.
Lighting TimeAutomatically turns off after a certain time has passed since the command was issued.
Turn off (x)Generate a turn-off message to turn off the LED.
Turn on (SPACE)Send the current settings to turn on the LED.

Display at the bottom of the screen

At the bottom of the screen, the timestamp when the command was generated and the command starting with : are displayed. The clipboard copies the contents of this screen.

2.1.2.2.2.2 - Write App Firmware

About the firmware writing function

Windows   macOS   Linux   RasPi

The firmware writing function allows you to write the TWELITE app (firmware).

  • Write pre-built .BIN files
  • Build from source files such as act and write

It eliminates the hassle of building source files, terminal disconnection, launching the writing utility, and terminal connection.

  • Automatically recognize TWELITE
  • After writing is complete, reset and then transition to interactive mode or terminal
  • From the list of projects, launch the project folder or environments like VSCode (except Raspberry Pi version)
  • From the list of projects, open related information web pages (except Linux and Raspberry Pi versions)

2.1.2.2.2.2.1 - Select from BIN

Operation instructions for the Select from BIN screen

Windows   macOS   Linux   RasPi

Overview

You can write pre-built applications ( .BIN files ).

Example of the Select from BIN screen

Example of the Select from BIN screen

When you select the menu, a list of .BIN files will be displayed. Please select the firmware to write.

If you want to use a file other than the pre-prepared .BIN files, please store the file to be written in the following location before selecting the menu.

PlatformLocation
Windows, macOS, Linux, Raspberry Pi{MWSTAGE folder}/BIN

In the BIN folder, please store .BIN files built with TWELITE STAGE without renaming the files (they are stored under the build folder of each project).

../BIN/App_Wings_MONOSTICK_BLUE_L1304_V1-1-3.bin
       App_Wings_MONOSTICK_RED_L1304_V1-1-3.bin
       App_Twelite_BLUE_L1304_V1-9-1.bin
       App_Twelite_RED_L1304_V1-9-1.bin
       ...

2.1.2.2.2.2.2 - act Build & Write

Operation instructions for the act build & write screen

Windows   macOS   Linux   RasPi

Overview

You can build and rewrite acts (act) written with the MWX library.

Example of sample act selection screen

Example of sample act selection screen

This screen displays a list of projects using acts placed in the following path.

{MWSTAGE installation folder}/MWSTAGE/Act_samples

Operation

You can build and write by selecting the project to write from the list.

After writing is finished, pressing ENTER or the [ B ] button will reset the TWELITE and transition to the interactive mode screen (or terminal screen, depending on settings).

Build and Write Screen

OperationDescription
[ A ]Menu selection up
[ A ]
Long press
Exit this screen and return to the selection screen.
[ B ]Select
[ B ]
Long press
Open related website in the OS default browser.
(If registered in 000desc.txt in the project folder)
[ C ]Menu selection down
[ C ]
Long press
Open folder (project or related folder).
You can set it to open with VS Code in the settings menu.
ESCExit this screen and return to the app rewrite menu.
Mouse click [Help]Open related website.
Mouse click [Folder] or [VSCode]Open related folder.
Mouse click [▽] or [△]Move to next page or previous page.

2.1.2.2.2.2.3 - TWELITE APPS Build & Write

Instructions for operating the TWELITE APPS Build & Write screen

Windows   macOS   Linux   RasPi

Overview

You can build and write TWELITE APPS written with the TWENET C library.

Example of the app selection screen

Example of the app selection screen

This screen displays a list of projects located in the following path:

{MWSTAGE installation folder}/MWSTAGE/Wks_TweApps

Operation

By selecting the project to write from the list, you can perform build and write operations.

After writing is completed, pressing ENTER or the [ B ] button will reset the TWELITE and transition to the interactive mode screen (or terminal screen, depending on settings).

Build and Write Screen

OperationDescription
[ A ]Menu selection up
[ A ]
Long press
Exit this screen and return to the selection screen.
[ B ]Select
[ B ]
Long press
Open the related website in the OS default browser.
(If registered in the project folder’s 000desc.txt)
[ C ]Menu selection down
[ C ]
Long press
Open folders (project, related folders).
You can set to open with VS Code in the settings menu.
ESCExit this screen and return to the App Write menu.
Mouse click [Help]Open the related website.
Mouse click [Folder] or [VSCode]Open the related folder.
Mouse click [▽] or [△]Move to the next or previous page.

2.1.2.2.2.2.4 - Act_extras

Operation instructions for the Act_extras screen

Windows   macOS   Linux   RasPi

Overview

You can build and rewrite acts written with the MWX library.

Example of the act selection screen

Example of the act selection screen

This screen displays a list of projects using acts placed in the following path:

{MWSTAGE installation folder}/MWSTAGE/Act_extras

Operation

By selecting a project to write from the list, you can perform build and write operations.

After writing is complete, pressing ENTER or the [ B ] button will reset the TWELITE and transition to the interactive mode screen (or terminal screen, depending on settings).

Build and write screen

OperationDescription
[ A ]Menu selection up
[ A ]
Long press
Exit this screen and return to the selection screen.
[ B ]Select
[ B ]
Long press
Open the related website in the OS default browser.
(If registered in the project folder’s 000desc.txt)
[ C ]Menu selection down
[ C ]
Long press
Open the folder (project or related folder).
You can set it to open with VS Code in the settings menu.
ESCExit this screen and return to the app rewrite menu.
Mouse click [Help]Open the related website.
Mouse click [Folder] or [VSCode]Open the related folder.
Mouse click [▽] or [△]Move to the next or previous page.

2.1.2.2.2.2.5 - Folder (Specify)

Write a specified firmware

Windows   macOS   Linux  

By dragging and dropping a folder or .BIN file onto the TWELITE STAGE APP screen, you can write a specific project. Select the dropped target when performing build or write operations.

2.1.2.2.2.2.6 - Last (Re-execute)

Re-execute writing the most recently written firmware

Windows   macOS   Linux   RasPi  

Re-select the most recently rewritten or specified project.

2.1.2.2.2.2.7 - Build & Write Screen

Operation instructions for the build & write screen

Windows   macOS   Linux   RasPi  

This section provides operation instructions for the screen displayed when building or writing a project.

During Build

This is the screen during the build (compile) process. The contents of the build command are output to the console screen. The ... in the middle of the screen indicates the number of files built, and the dark-colored display at the bottom shows the filenames currently being built.

Example of the screen during compilation

Example of the screen during compilation

Build Error

If a build error occurs, a screen like the one above is displayed. You can execute a rebuild or display the error log. Also, after a certain timeout, it will return to the previous menu.

Example of error display screen

Example of error display screen

Only representative error messages are displayed on the screen. When the build fails, there may be cases where the error message is not displayed.

OperationDescription
[ A ]No assignment
[ A ]
Long press
Exit this screen and return to the previous menu.
[ B ]Rebuild on error.
[ B ]
Long press
No assignment
[ C ]
[ C ]
Long press
Display the error log (Windows/macOS).
The save location is {project folder}/build/builderr.log.
ESCExit this screen and return to the write menu.
ENTERRebuild on error.

During Write

When the build succeeds, the screen to write the firmware is displayed.

Example of write-in-progress screen

Example of write-in-progress screen

Write Failure

If writing results in an error, a screen like the one below is displayed.

Example of write failure screen

Example of write failure screen

OperationDescription
[ A ]
Long press
Exit this screen and return to the selection screen.
[ B ]Rewrite again
(Returns to the previous write menu.
Since the menu item is automatically selected,
pressing [ B ] again will rewrite.)
ESCExit this screen and return to the write menu.

Write Complete

When writing completes successfully, a screen like the one below is displayed.

Example of write completion screen

Example of write completion screen

OperationDescription
[ A ]
Long press
Exit this screen and return to the selection screen.
[ B ]Reset the TWELITE and move to the interactive mode screen (or terminal screen depending on settings).
ESCExit this screen and return to the write menu.

2.1.2.2.2.3 - Interactive Settings Mode

Using Interactive Settings Mode

Windows   macOS   Linux   RasPi

Overview

From this screen, you can use the interactive mode of the connected TWELITE.

Example of the Interactive Mode screen

Example of the Interactive Mode screen

This screen behaves almost the same as a terminal, but adds functions specific to interactive mode, such as operations to transition to interactive mode and detection of exit from it.

  • The connected TWELITE must have firmware compatible with interactive mode pre-installed.
  • Since TWELITE input/output is used, if garbled characters occur in serial communication, transitions to and exits from interactive mode may not work as expected.
  • Mouse operations are not supported. Please use keyboard operations (cursor keys are usable).

Interactive Mode Screen Operation Flow

Below is an outline of the process flow.

[Set screen background to black]
  ↓
[Reset TWELITE (if controllable, SET=LO)]
  ↓
 --YES--> [Operation screen]
  ↓timeout
[Input '+' three times]
  ↓
 --YES--> [Operation screen]
  ↓timeout
[Operation screen] ※ This state is not interactive mode

[Operation screen]
  ↓
 --> [Exit]
  ↓
 --> [Exit]
  ↓
 ->  --NO-> [Exit]
  ↓            ↓
[Send input string to TWELITE]
  ↓
[Return to operation screen]

[Exit]
  ↓
[Reset TWELITE]
  ↓
[Exit screen] Exit the interactive mode screen and return to the previous screen

2.1.2.2.2.4 - Settings of TWELITE STAGE

Settings for TWELITE STAGE APP

Windows   macOS   Linux   RasPi

Overview

From this screen, you can configure various settings of the TWELITE STAGE APP.

Example of the settings screen

Example of the settings screen

Some menu items explained below may not exist on certain platforms, but all are listed and explained.

Color settings other than the common menu are omitted from the explanation.

Root Menu

Common
 Terminal
 Standard App Viewer
 Graph Viewer (Acceleration Real-time/Sensors)
 Simple Monitor (CUA/ARIA/Glancer)
 Commander
 Write firmware
 Interactive Settings Mode
Save Data Utilities (Dump/Erase)
Information

Common Settings

a: (      0x00) Startup App Specification
G: (      0x00) Screen Size and Drawing Method
F: (          ) Serial Device ID
f: (0x00FFFFFF) Foreground (Text) Color
b: (0x005A0032) Background Color
B: (    115200) Baud Rate
SettingDescription
Startup App SpecificationThis setting determines which viewer app to switch to when TWELITE STAGE starts.
The setting value is 1..{the number listed in the viewer app menu}.
Note: If the serial device ID is not set,
the startup will wait for input on the serial device selection screen.
Screen Size and Drawing Method(Except for M5Stack version) Specified by two characters XY (X: screen size, Y: drawing method).
X 0:640x480 1:1280x720 2:1280x960 3:1920x1440 4:2560x1440 5:320x240
Y 0:LCD style 1:CRT style 2:Blur 3:Block
Serial Device ID(Except for M5Stack version) Set by serial device name or a number 1..9.
Note: The number indicates the device enumeration order.
Text Color / Background ColorSpecify text and background colors.
The common settings color values are inherited by other screens’ settings.
If not set on other screens, the common settings colors are used.
Colors are specified as 24-bit RGB hexadecimal values but are internally rounded to 16-bit 565 format.
Baud RateSet to avoid garbled display in terminals etc. when the TWELITE baud rate is not 115200.

Write Firmware

f: (0x00FFFFFF) Foreground (Text) Color
b: (0x005A0032) Background Color
j: (         0) Number of make jobs at build time
v: (         0) Open a folder with VSCode
l: (         0) Disable LTO
n: (         0) Screen after rewriting is completed
SettingDescription
Number of make jobs at build time(Except for M5Stack version) Number of parallel jobs during build to shorten build time.
Default 0 calculates jobs as (physical processor count - 1).
A guideline is to set up to the number of logical processors.
Open a folder with VSCode(Requires VSCode installation) Setting 1 opens folders using the code command (VSCode) instead of the OS standard folder window.
The executable TWELITE_Stage_VSCode defaults to 1.
Screen after rewriting is completed(Except for M5Stack version) Setting 1 opens the terminal instead of the interactive mode screen.
Setting 2 returns to the rewrite menu.
TWELITE_Stage_VSCode sets this to 2.
Disable LTO(Windows only) Setting 1 disables LTO in the Windows compiler.
LTO produces smaller binaries but takes longer to link.
Disabling LTO results in faster linking.

Save Data Utilities

r: Read sector.
R: Read ALL sectors.
e: Erase sector.
E: Erase ALL sectors.

This screen is a utility for maintaining data save areas. It emulates EEPROM (64 bytes per sector, up to 60 sectors, 3840 bytes).

SettingDescription
rReads a sector.
Input 0..59 to display the contents of the specified sector.
RInput YES to read all sectors, but only the tail part is displayed.
eErases a sector (0xFF).
Input 0..59 to erase the specified sector.
EInput YES to erase all sectors.

2.1.2.2.2.5 - Select SERIAL port

Select SERIAL port menu

Windows   macOS   Linux   RasPi

Overview

On this screen, you can (re)select the serial port.

Example of the serial port selection screen

Example of the serial port selection screen

2.1.2.3 - Logging Function

Logging function between TWELITE and PC

Windows   macOS   Linux   RasPi

You can record serial communication logs between TWELITE and PC.

Operation

Start Recording

Press Alt(Cmd)+L.

Example of the log start screen

Example of the log start screen

Stop Recording

While recording, press Alt(Cmd)+L again.

Example of the log stop screen

Example of the log stop screen

The log recording will stop, and the log file at that point will be opened using the OS default application (Notepad on Windows, Console.app on macOS).

Specifications

Log Recording

Strings received from TWELITE are recorded as-is.

Strings sent to TWELITE are recorded one character at a time. On Windows, they are enclosed in 「 」, and on macOS / Linux / Raspberry Pi, they are enclosed in « ». For example, «t» means that the character t was input from the keyboard.

Log Folder and File Name

Logs are saved in the {folder where the TWELITE STAGE APP executable is located}/log folder, with a file name based on the start date and time of the logging.

Press Alt(Cmd)+Shift+L to open that folder.

Example of the log output folder

Example of the log output folder

2.1.3 - Detailed Specifications

Detailed specifications of TWELITE STAGE APP

2.1.3.1 - Detailed Settings with Command-line Arguments and ini Files

Detailed settings for TWELITE STAGE APP using command-line arguments and ini files

Command-line Arguments

Command-line arguments configure some detailed settings of the TWELITE STAGE APP.

Command-line ArgumentDescription
-E 0Disables graphical effects such as fade-out.
-R {type}Sets the rendering type with the {type} value.
0: Default
1: OpenGL
2: DirectX (Windows) Metal (macOS)
3: Software
-JEnables the game controller.
-x {x_pos},
-y {y_pos}
Sets the position of the TWELITE STAGE App graphical window at startup.
{x_pos} and {y_pos} are the screen coordinates of the top-left corner of the window.

ini Files

ini files are used to configure basic settings of the TWELITE STAGE APP (such as referencing the MWSDK folder).

The ini file name is {base name of the TWELITE STAGE APP executable} + .ini. Usually, it is TWELITE_Stage.ini.

;;; Change the MWSDK reference.
; MWSDK=MWSDK
mwsdk=mwsdk2020_10

;;; Interface language
; LANG=en

;;; Window geometry
GEOM_X=200
GEOM_Y=100

Syntax

  • ini files are written as plain text files.
  • Keys and values are stored on a single line separated by = (e.g., KEY=value).
  • The key and value strings start at the beginning of the line (no spaces or other characters allowed before the key).
  • Spaces are not allowed between the key and the value.
  • Comment lines start with ; or # at the beginning of the line.

Settings

KeyValue
MWSDKChanges the MWSDK folder. The default folder is MWSDK located in the same folder as the TWELITE STAGE APP executable. If you need to use an older or custom MWSDK, you can specify the folder name here.
LANGLANG=en changes the user interface language from the default (Japanese) to English. This setting is carried over to the make parameter (TWE_LANG_PREF) and is reflected in the interactive mode display language setting of some firmware (apps) such as TWELITE_Apps.
GEOM_X, GEOM_YChanges the location where the TWELITE STAGE App window appears.

Running TWELITE STAGE APP with Different Settings

If you need different settings for the TWELITE STAGE APP, copy the executable to the same folder as the TWELITE STAGE APP and create an .ini file with the same name.

For example, to use the English interface, copy TWELITE_Stage.exe (note: .exe is the Windows executable extension) to TWELITE_Stage_en.exe and write the setting LANG=en in TWELITE_Stage_en.ini to create an executable with the English interface enabled.

  TWELITE_Stage.exe
  TWELITE_Stage.ini | No special settings

  TWELITE_Stage_ja.exe | Copy of TWELITE_Stage.exe
  TWELITE_Stage_en.ini | LANG=en is set.

2.1.3.2 - Environment Variables

Environment variables used by TWELITE STAGE APP

Environment Variables Set Internally

Environment VariableDescription
MWSDK_ROOTBy default, the MWSDK folder located in the folder where the TWELITE STAGE APP executable is stored (that is, ../MWSTAGE/MWSDK) is specified. If MWSDK.ini is specified, the specified folder name is adopted.
MWSDK_TWENET_LIBSRCFor sample code and TWELITE APPS source code folders, definition files for Microsoft Visual Studio Code (VS Code) are pre-created. In these definition files, the library source code reference path is specified for code interpretation within the VS Code editor, and this environment variable is used for that purpose.
If the MWSDK_TWENET_LIBSRC environment variable is properly set, code interpretation will work even in project folders outside of MWSDK, enabling features such as function name completion for the library. (Reference)
LANG=CExplicitly set to make the toolchain messages appear in the default language (English).
PATHOn Windows, adds the PATH to the SDK-included msys utilities.
MWSDK_MAKE_JOBS
MWSDK_MAKE_DISABLE_LTO
MWSDK_MAKE_LANG_PREF
Used in VS Code configuration definitions.
JOBS: Passes the number of parallel builds set in STAGE APP
DISABLE_LTO: Disables LTO ( Windows )
LANG_PREF: The display language (JP: Japanese, EN: English) of the TWELITE STAGE APP is set.This setting is also inherited by the parameter (TWE_LANG_PREF) of make at build time.

Reference

Excerpt from .vscode/settings.json configuration example:

    "C_Cpp.default.includePath": [
        "${env:MWSDK_TWENET_LIBSRC}/include/**",
        "${env:MWSDK_TWENET_LIBSRC}/src/**"
    ],
    "C_Cpp.default.browse.path": [
        "${env:MWSDK_TWENET_LIBSRC}/include/**",
        "${env:MWSDK_TWENET_LIBSRC}/src/**"
    ],

Definitions starting with "../../" are unnecessary when opening a project from the TWELITE STAGE app. These specify source reference paths in the default folder structure when the environment variable MWSDK_TWENET_LIBSRC is not set.

2.1.3.3 - Adding Project Descriptions with 000desc.txt

How to add project descriptions using 000desc.txt

When you create a 000desc.txt file in the project folder, TWELITE STAGE APP displays its contents in the project folder list.

Example display of 000desc.txt

Example display of 000desc.txt

The file should be written as plain text in UTF-8 format. There are two formats as follows.

Format 1

LED lights up when the switch is pressed
act4 operates an act that lights up the LED when the switch connected to TWELITE DIP is pressed.
https://mono-wireless.com/jp/products/act/index.html
  • The first line is the title line.
  • The following lines describe details.
  • If the last line starts with http, it becomes a link to a website.

Format 2

[JAPANESE]
TITLE=act template
DESC=This file contains only empty setup() and loop() functions.
Please use it to write a new act.
URL=jp/MWX/content/Act_samples/README.html
[ENGLISH]
TITLE=act empty template
DESC=This act file only contains empty setup() and loop(),
which is intended to write a new act.
URL=en/MWX/content/Act_samples/README.html

This format is like an ini file. The item name starting from the beginning of the line and the = character define the item, and the content after = is the item’s content.

Item DefinitionDetails
[JAPANESE], [ENGLISH]Block separators
TITLE=Title line
DESC=Description. Can include multiple lines with line breaks.
URL=Link to a website or file

About URL specification

URL=Details
Starting with https:, http:Opens that address
OthersSpecify a relative folder based on {MWSDK_ROOT}/docs/.
If set as a/b/c.html, it is converted to {MWSDK_ROOT}/docs/a/b/c.html.

2.1.4 - License

About the license

The executable format of TWELITE_Stage distributed by Mono Wireless Inc. is subject to MW-SLA-1J,1E.

Open Source Components Used

We appreciate the open source projects that provided high-quality source code.

NameDescription
SDL2Simple DirectMedia Layer Copyright (C) 1997-2020 Sam Lantinga
getoptCopyright (c) 1987, 1993, 1994 The Regents of the University of California. All rights reserved.
regexregex - Regular expression pattern matching and replacement By: Ozan S. Yigit (oz) Dept. of Computer Science York University
printfCopyright (c) 2014 Marco Paland
Shinonome Font2001 The Electronic Font Open Laboratory http://openlab.ring.gr.jp/efont/
M+ BITMAP FONTSCopyright 2002-2005 COZ coz@users.sourceforge.jp
SQLiteC++Copyright (c) 2012-2021 Sebastien Rombauts (sebastien.rombauts@gmail.com)
sqlite3All of the code and documentation in SQLite has been dedicated to the public domain by the authors.

2.1.5 - Revision History

Revision history of TWELITE STAGE APP

Please refer to https://github.com/monowireless/mwm5 for the source code change history.

  • Depending on the platform, the latest version distributed and the latest version in the revision history may not match.
  • The latest version of the source code may not be registered at the above sites.

2.4.4 MWSTAGE2025_07 Release

Major Version Upgrade

  • Added support for TWELITE STICK
  • Enhanced serial port functionality
    • Added baud rate switching via ALT+B
    • Connection status now displayed in the title bar
  • Makefile error message handling
    • Extracts the message part ... from errors output in the format $(error <MWERRM>...</MWERRM>)
    • These error messages are intended to be used when attempting to build projects for unsupported architectures (e.g., GOLD only, or BLUE/RED only)
  • Support for language setting in interactive mode
    • Interactive mode language can now be specified at build time via TWE_LANG_PREF=(JP|EN)
    • When launching external tools (e.g., VSCode), the MWSDK_MAKE_LANG_PREF environment variable is now set

2.4.3

  • For projects with multiple configuration types located in subfolders (and not directly under the root build), folder listing is now limited to only those that contain a build/ directory, preventing unnecessary folders from being shown
  • Fixed a crash that occurred when error messages were too long during build errors
  • Changed the order of serial protocol checks for determining BLUE/RED/GOLD: now tries GOLD first (for GOLD-targeted SDK)

2.4.2

  • Added support for interactive mode transition control using the SET pin (CTS pin on MONOSTICK)
    • Behavior in TWELITE_Apps is as follows:
      • If SET pin is held for less than ~100ms → normal boot (prevents accidental interactive mode entry due to noise)
      • If held longer than the above → enter interactive mode on boot
      • If held for ~3 seconds or more → erase entire EEPROM on startup
      • Each app is informed of the interactive mode transition via a startup parameter
        • Apps receiving this parameter will, in principle:
          • Skip app-specific initialization
          • Skip interrupt handler setup, etc.
          • Automatically start interactive mode on UART0 at 115200 8N1
          • Suppress exit from interactive mode via +++
    • Under this spec, the STAGE app behaves as follows:
      • For regular transition to interactive mode, hold the SET pin for about 300ms
        • When holding [ C ] on the interactive mode guidance screen, SET pin is held for about 5 seconds
        • If Entering Interactive ... message is not received within timeout, fallback to trying +++ as per previous behavior
  • Additional code cleanup

2.4.1

  • Initial support for TWELITE GOLD
    • If a control command response from GOLD is received at startup, it’s recognized as GOLD; if it fails, control commands for the BLUE/RED series are attempted instead

1.3.8 MWSTAGE2022_08 Included Version

Major version upgrade.

  • Changed internal rendering resolution from 320x240 to 640x480 pixels
  • Added real-time graph for accelerometer sensor
  • Added sensor graph that saves sensor data and displays graphs
  • Supported English display
  • Changed main manuals to local HTML files

1.0.8 MWSTAGE2021_09 Included Version

  • There was a case where buttons [ A ] [ B ] [ C ] remained pressed even after the pointer moved away
  • STAGE APP sends CRLF to TWELITE when Enter is input
  • Updated Mac FTDI library to allow operation without serial intermediary program on Apple Silicon (M1)
  • Internally set PATH for msys toolset on Windows to prevent unexpected make calls
  • Allowed moving to the writing screen even if TWELITE is not connected (input B,R keys and specify the target TWELITE model)
  • When configured to use VSCode, selecting act or TweApps opens the writing screen for .bin files under build/ without building (build is done from VSCode)
  • Internally set several environment variables so that VSCode launched from TWELITE STAGE can refer to them, enabling proper builds and library resource referencing in VSCode
  • Sample code is stored under MWSDK folder, but dropping a folder for build target allows build and write operations for folders other than MWSDK (folder names must not contain spaces or Japanese characters)
  • Displayed internal folder settings and environment variable settings on the console screen at startup
  • Waited 1 second before exiting STAGE APP on termination

1.0.7pre2

  • Enhanced support for Raspberry Pi (1.0.7pre2)
    • Support for serial0 (TWELITE STAGE HAT)
    • Added build for Zero (build with supported libraries & disabled rendering fade feature)
    • Added build for X11 desktop
  • Made it usable with general FTDI devices (FT232, FT230). Firmware writing mode must be done manually
  • Added feature to display COM ports assigned in Windows by pressing c key on serial port selection screen
  • Allowed changing baud rate from 115200bps
  • Added command line option (-E 0) to disable rendering fade feature.

1.0.3 MWSTAGE2020_12 Included Version

  • Supported TWELITE CUE (parser and CUE viewer)
  • Enabled verification (comparison) during writing in the rewrite menu
  • Provisional support for Apple Silicon (TWELITE_Stage.command is a universal app; external command sersrv_ftdi.command and Tools are rebuilt Intel binaries runnable with Rosetta2; serial communication is slower due to external command)
  • Moved MWSTAGE/MWSDK/Tools to MWSTAGE/Tools (to allow direct use of MWSDK_COMMON repository)
  • TWELITE_Stage.ini (removes extension from startup filename and adds .ini) is loaded at startup to allow selecting MWSDK folder (makes it easy to switch old library sets)
  • Updated SDL2 library for screen rendering to 2.0.12 (Windows, MacOS, RaspberryPi)
  • Static build on Windows with no DLL files required
  • Set parallel build count for make -j to (number of physical CPUs - 1)
  • Explicitly reopened serial port in several places in rewrite menu to improve recovery when USB connection is disconnected due to device removal
  • When opening mwx or twesettings with Alt(Cmd)+Shift+m, t, opens folders listed in TWENET/usever.mk
  • Fixed issue where writing menu transition failed on first startup at /dev/serial0 on Raspberry Pi

Known Issues

  • Help message when pressing Alt(Cmd) at startup may not appear; can be shown by inputting Alt(Cmd)+0
  • Line wrapping may be broken when filenames are too long in rewrite menu
  • Apple Silicon operation has not been sufficiently tested

0.9.11 MWSTAGE2020_10, Raspberry Pi Version (Provisional)

(* This version is not comprehensively tested *)

  • Operation on Raspberry Pi
  • Other feature adjustments

0.9.9 - MWSTAGE2020_10 Included Version

  • Added [Web] button to the top-level menu to open related links in browser
  • Implemented folder, web, and VS Code open features for Linux version
  • Sometimes difficult to transition to writing menu when TWELITE frequently outputs UART

0.9.8a

https://github.com/monowireless/TWELITE_STAGE_Bin_M5Stack/releases/tag/0.9.8a

M5Stack version made dual-licensed for MW-SLA-1J,E / MW-OSSLA-1J,E and updated readme-j.txt.

0.9.8

Added [Web] button to viewer list to open related sites.

Revision Details

  • Added Commander to viewer
    • Standard app 0x80 command
    • NOTICE PAL LED control (send commands to App_Wings)
  • NOTICE PAL support for viewer > PAL viewer
  • Added menu for Act_extras
    • More advanced than Act_samples
    • Uses external open source libraries (e.g. sensor procedures)
  • Expanded mouse operation (lists, buttons, tabs)
    • Focus on mouse move, confirm with left click, right click inputs [ESC] key
  • Reduced screen rendering load
    • Disabled screensaver when app is in background
    • Reduced rendering frequency when app is in background to lower CPU load
  • Enhanced build project list (act, TWE_Apps, Act_extras)
    • Show summary at bottom when selecting items (reads 000desc.txt, processed by TWE_Desc class)
    • Ability to open project folder (or open in VSCode)
    • Ability to open related websites
    • Open mwx library with Alt+Shift+m and twesettings library with Alt+Shift+t
    • Open selected folder or build error files in build menu
  • Added logging (serial port input/output)
    • Start/stop log with (Alt/Cmd+L)
    • Log files saved in {folder containing TWELITE_Stage executable}/log
    • Filename format: twestage_{date-time}.log
    • Open log file folder with Shift+Alt/Cmd+L
  • Other changes and fixes
    • Changed display method for serial (FTDI) device names and IDs
    • Fixed issue where App_UART did not transition to interactive mode
    • Changed behavior on folder drop (previously sometimes triggered binary write, now transitions menu)
    • On terminal long press [C], clears screen in addition to reset

Known Issues

  • M5Stack may hang and reset settings to default when saving settings

0.8.9

2020_05 Release Version

  • Added window icon
  • Relaxed maximum list constraints on BIN file list screen (win/linux/mac)
  • Added Glancer viewer
  • Adjusted explanatory text
  • Adjusted console screen rendering
  • Fixed issue where setting destination screen after firmware write (interactive mode or terminal) did not work
  • Changed assignment of Alt(or Cmd)+W
  • Other bug fixes

0.8.6

Initial release of Linux version

0.8.5

Initial release

3 - TWELITE APPS

Ready-made software for signal transmission and serial communication, ready to use without software development.
TWELITE APPS - Twilight Apps are ready-made software for TWELITE that can be used as is without software development.

What is Interactive Mode

Interactive mode is the mode to perform detailed settings of TWELITE APPS.

You can make necessary settings when you want to communicate with multiple groups or reduce communication errors.

Connection with PC

For TWELITEFor MONOSTICK
Attach the TWELITE R series to the 7P interface prepared on the parent board and connect to the PC using a USB cable.Connect the MONOSTICK to the PC’s USB port. TWELITE R series is not required.
Connection between TWELITE (SMD) and PC

Connection between TWELITE (SMD) and PC

Connection between MONOSTICK and PC

Connection between MONOSTICK and PC

For TWELITE DIP (BLUE/RED)For Others
Attach to TWELITE R series and connect to the PC using a USB cable.For TWELITE series with 7P interface, attach TWELITE R series and connect to the PC using a USB cable.
Connection between TWELITE DIP (BLUE/RED) and PC

Connection between TWELITE DIP (BLUE/RED) and PC

Connection between other TWELITE series and PC

Connection between other TWELITE series and PC

Switching to Interactive Mode

When Using TWELITE STAGE

TWELITE STAGE APP is an integrated development tool that includes firmware writing and configuration of TWELITE, as well as a function to display received data.

  1. Launch TWELITE STAGE APP
Main menu of TWELITE STAGE APP

Main menu of TWELITE STAGE APP

  1. Select “Interactive Mode” from the menu of TWELITE STAGE APP

When Using Terminal Software

You can also use general terminal software.

  1. Launch terminal software on the PC (communication settings: 115200bps/8-N-1)
  2. Reset TWELITE.
  3. Slowly press the + key on the PC keyboard three times (interval 0.2 to 1 second). If it does not work well, keep entering + repeatedly.

To exit interactive mode, press + three times again.

Operation of Interactive Mode

Interactive mode displays a screen like the following.

--- CONFIG/TWELITE APP V1-00-2/SID=0x81000038/LID=0x78 ---
 a: set Application ID (0x67720102)
 i: set Device ID (--)
 c: set Channels (18)
 t: set mode4 sleep dur (1000ms)
 y: set mode7 sleep dur (10s)
 f: set mode3 fps (32)
---
 S: save Configuration
 R: reset to Defaults

The displayed content varies depending on the firmware type and version.

Steps

  1. Select value: press the first letter alphabet
  2. Specify value: input the value
  3. Confirm value: press Enter
  4. Save value: press S (uppercase)
  5. Apply value: restart TWELITE

Values in parentheses indicate the current setting.

Pressing R (uppercase) resets to default values (apply with S).

Example of Operation

To set the Application ID to 0xBEEFCAFE, input as follows:

Input Application ID (HEX:32bit): BEEFCAFE

Common Settings for TWELITE APPS

Frequency channel, application ID, device ID, retry count, and transmission output settings are common to TWELITE APPS.

Application ID and Frequency Channel

Image of Grouping

Image of Grouping

Devices must have the same application ID and frequency channel to communicate.

a: Application ID

Setting the same value to all devices communicating allows logical network separation.

TWELITE discards packets received from devices with different application IDs. Therefore, multiple groups can be established within the same frequency channel.

c: Frequency Channel

Setting the same value to all devices communicating allows physical network separation.

TWELITE conforms to the IEEE802.15.4 standard and divides the 2.4GHz band into 16 channels.

List of Frequency Channels

List of Frequency Channels

To change the frequency channel, press c (lowercase).

Default Values for Each TWELITE APP

TWELITE APPSApplication IDFrequency Channel
Super Simple! Standard App (App_Twelite)0x6772010218
Remote Control App (App_IO)0x6772010716
Serial Communication App (App_Uart)0x6772010318
Wireless Tag App (App_Tag)0x6772630515
Pulse App (App_PAL)0x6772630515
Queue App (App_CUE)0x6772010218
Aria App (App_ARIA)0x6772010218
Parent/Relay App (App_Wings)0x6772010218

i: Logical Device ID

The logical device ID is used to identify each device. You can assign logical IDs to each device.

Image of Assigning Logical Device ID

Image of Assigning Logical Device ID

When using multiple child devices for one parent device, assign different IDs (1 to 100) to each child device.

x: Transmission Output and Retry Count

You can weaken the transmission output to narrow the effective radio transmission range. However, power consumption does not change, so normally use the maximum output.

Retry count refers to the number of additional transmissions per one transmission request. Setting retry count may improve data arrival rate in poor communication environments. However, communication time and power consumption increase accordingly.

In interactive mode, input a two-digit number.

  • Tens place: retry count
    • 1 to 9 times
    • 0 is the default value for each app
    • F disables retry
  • Ones place: transmission output
    • 3 is the strongest
    • 2/1/0 each step down reduces output by -11.5dB

Examples

  • 32 → Retry 3 times, output one level weaker
  • 93 → Retry 9 times, maximum output

Resetting Settings

Some settings may interfere with operation (such as baud rate changes).

You can reset settings by the following steps.

  1. Rewrite to another app
  2. Switch to interactive mode
    • Reset with R
    • Save with S
  3. Write back to the original app

App-specific Settings for Each TWELITE APP

For settings that differ between apps, please see the following pages.

3.1 - TWELITE APPS (Unified) Manual

Unified firmware that consolidates all TWELITE APPS
Mainly for the TWELITE GOLD series, this firmware integrates TWELITE APPS such as the Extremely Simple! Standard App App_Twelite, allowing functionality to be switched without rewriting.

3.1.1 - TWELITE APPS (Unified) Manual

Latest Edition
TWELITE_Apps is a firmware that integrates TWELITE APPS such as the Extremely Simple! Standard App App_Twelite, allowing users to switch functionalities without rewriting. It’s like an assortment pack of TWELITE APPS.

Overview

The unified firmware bundles the following TWELITE APPS:

Switching involves a reset, but it can be performed from software without rewriting the firmware.

How to Switch

1. Open Interactive Mode

Access the Interactive Mode of TWELITE APPS and enter : (AppSel).

[CONFIG MENU/App_Wings:PARENT:0/v1-03-2/SID=8300051A]
a: (0x67720102) Application ID [HEX:32bit]
c: (18        ) Channel(s)
x: (      0x03) RF Power/Retransmissions [HEX:8bit]
b: (115200,8N1) UART Baud Alt. [XXXXX]
o: (0x00000000) Option bits [HEX:32bit]
t: (0xA5A5A5A5) Encryption key [HEX: 32bits]

[ESC]:Exit [!]:Reset System [*]:Extr Menu [:]:AppSel

2. Open the TWELITE APPS List

A menu like the following will display a list of TWELITE APPS:

[TWELITE AppSel/v0-02-1/SID=8300051A/SAVE=04-12-01]
M: AppSel           App selector (this screen)
R: Revert to DEFAULT(*DEF)
A: App_Twelite      Standar app. (App_Twelite)
B: App_IO           App for remote. (App_IO)
C: App_UART         App for SERIAL comm. (App_Uart)
D: App_Wings        Parent/Repeater (App_Wings)(*DEF)
E: App_OTA          OTA Apps for ARIA/CUE.

[!]:Reset [R]:Revert [$]:LANG=English

3. Select a TWELITE APP

Just like in Interactive Mode, you can switch to a TWELITE APP by entering the command ID letter.

For example, in the above example, entering C switches to App_Uart.

[App_UART / App for SERIAL comm. (App_Uart)]
Designed for UART (Serial) communications. UART is commonly used on MCUs.

=== Please select from the list below. Save the startup application. ===
1: Normal
2: for TWELITE UART

[BS]:Back

Initialize TWELITE APP

On the TWELITE APP list screen, entering R will revert to the default TWELITE APP.

! Clear Save Data? The next key will perform:
S: Clear App Selection.
!: Clear ALL SAVE DATA.

[BS]:Back

3.2 - Extremely Simple! Standard App Manual

Transmission of digital and analog signals
The input/output states of parent and child devices are synchronized. An all-in-one package supporting 4 digital ports, 4 analog ports, serial, and I2C. Simplified with versatile features, but does not focus on processing speed, responsiveness, or power saving.

3.2.1 - Extremely Simple! Standard App Manual

Latest Edition

Download

To install the Extremely Simple! Standard App (App_Twelite), install the TWELITE STAGE SDK and rewrite using the TWELITE STAGE App.

3.2.1.1 - Pin Assignments of Extremely Simple! Standard App

Functions of pins used by the Extremely Simple! Standard App
Functions and arrangements of pins used by the Extremely Simple! Standard App (App_Twelite)

Pin Assignments

Pin Assignment Table

Pin Assignment Table

Pin NameFunction
VCC GNDPower Input
DIx AIxDigital/Analog Input
DOx PWMxDigital/Analog Output
TX RXUART
SCL SDAI2C
Mx BPSConfiguration Input
RSTReset Input

Power Input

Connect a 3.3V (2.3-3.6V) power supply to VCC/GND.

Digital and Analog Input/Output

DIx/DOx, AIx/PWMx pins transmit signals synchronously with matching pin numbers.

DigitalAnalog
Input on DIx → Output on DOxInput on AIx → Output on PWMx

Serial Communication

UART

TX/RX are used for UART transmission and reception. Specifically, they are used in the following cases:

I2C

SCL/SDA pins are used to connect I2C target devices.

Configuration Input

By leaving the Mx pins unconnected or connecting them to GND, you can switch operation modes such as parent, child, and repeater (Operation Modes).

By leaving the BPS pin unconnected or connecting it to GND, you can change the UART baud rate from 115200bps to other values (Alternative Baudrate).

Reset Input

By connecting a push button between the reset input pin RST and GND, you can implement a reset button. RST is internally pulled up.

3.2.1.2 - Operating Modes of Extremely Simple! Standard App

Explanation of each operating mode
The Extremely Simple! Standard App (App_Twelite) has seven operating modes.

List of Operating Modes

Each mode is set by leaving the Mx pin unconnected or connecting it to GND.

M3M2M1ModeFunctionPowerSavingInitialLID
OOOChild: ContinuousSends input status to parent, and always waits for received data to reflect on output120
OOGParent: ContinuousSends input status to child, and always waits for received data to reflect on output0
OGORepeater: ContinuousAlways waits for received data and relays it122
OGGChild: Continuous 0.03sFrequently sends input status to parent, and always waits for received data to reflect on output123
GOOChild: Intermittent 1sSends input status to parent every 1 second, and disables reception to always enter power-saving mode124
GOGChild: Intermittent Reception 1sSends input status to parent every 1 second, and simultaneously performs reception, always entering power-saving mode125
GGO-Unused--
GGGChild: Intermittent 10sSends input status to parent every 10 seconds, and disables reception to always enter power-saving mode127

O: Not connected (OPEN), G: Connected to GND

Initial state is Child: Continuous mode.

The initial Logical Device ID (LID) used to identify the device varies depending on the mode.

Parent Device

Continuous Mode

Parent: Continuous Mode

When input signals change or every 1 second, data is sent to all child devices.

It always waits for data sent from child devices, providing good responsiveness but continuously consuming power.

  • Reception: Always waiting
  • Transmission: On input change / every 1 second

Child Device

Continuous Mode

Child: Continuous Mode

When input signals change or every 1 second, data is sent to all parent devices.

It always waits for data sent from parent devices, providing good responsiveness but continuously consuming power.

Communication image with parent device

Communication image with parent device

  • Reception: Always waiting
  • Transmission: On input change / every 1 second

Child: Continuous 0.03s Mode

This mode shortens the periodic transmission interval of Child: Continuous Mode from 1 second to 0.03 seconds.

Although it always waits for data sent from the parent, the communication from child to parent occupies the bandwidth, making the parent’s input response slower. It continuously consumes power.

Communication image with parent device

Communication image with parent device

  • Reception: Always waiting
  • Transmission: On input change / every 0.03 seconds

Intermittent Mode

Child: Intermittent 1s Mode

When input signals change or every 1 second, power-saving mode is canceled and data is sent to all parent devices.

Reception is disabled, so control from the parent device is not possible. This mode has excellent power-saving performance.

Communication image with parent device

Communication image with parent device

  • Reception: Disabled
  • Transmission: On input change / every 1 second

Child: Intermittent 10s Mode

When input signals change or every 10 seconds, power-saving mode is canceled and data is sent to all parent devices.

Reception is disabled, so control from the parent device is not possible. This mode has excellent power-saving performance.

Communication image with parent device

Communication image with parent device

  • Reception: Disabled
  • Transmission: On input change / every 10 seconds

Child: Intermittent Reception 1s Mode

When input signals change or every 1 second, power-saving mode is canceled and data is sent to all parent devices.

Reception is also performed every 1 second. It has excellent power-saving performance but is inferior to Child: Intermittent 1s Mode.

Communication image with parent device

Communication image with parent device

  • Reception: Every 1 second
  • Transmission: On input change / every 1 second

Repeater

Continuous Mode

Repeater: Continuous Mode

The repeater forwards received packets.

Up to three repeaters can be installed between parent and child devices, but increasing repeaters increases the number of packets, which may cause interference.

Image of relaying

Image of relaying

  • Reception: Always waiting
  • Transmission: On reception

3.2.1.3 - Alternative Baud Rate Setting for Extremely Simple! Standard App

Changing the baud rate used for UART communication
The Extremely Simple! Standard App (App_Twelite) uses 115200 bps as the default baud rate for UART communication, but this can be changed.

Enabling Alternative Baud Rate Setting

You can enable the alternative baud rate setting by connecting the BPS pin to GND.

BPSDescriptionBaud RateRemarks
ODefault115200bps
GOverride Setting38400bpsCan be changed via Interactive Mode

O: Not connected (OPEN), G: Connected to GND

3.2.1.4 - UART Function of Extremely Simple! Standard App

Data format used in UART function
This explains the data format used in the UART function of the Extremely Simple! Standard App (App_Twelite).

Digital and Analog Input/Output

0x81: Status Notification from Remote Device

Outputs the state of the received input signals.

Data Format

#DataContentNote
charHeader: only
0uint8Source Logical Device ID
1uint8Command Number0x81 only
2uint8Packet IdentifierGenerated from Application ID
3uint8Protocol Version0x01 only
4uint8LQI0-255
5uint32Source Serial ID0x8???????
9uint8Destination Logical Device ID
10uint16Timestamp64 counts per second
12uint8Relay Count
13uint16Power Supply VoltageUnit is mV
15int8-(Unused)
16uint8Digital SignalsCorresponds to DIx from LSB, 0 is High
MSB 1 means periodic transmission
17uint8Digital Signal MaskCorresponds to DIx from LSB, 1 is valid
18uint8Conversion Value of AI1See Calculation of Analog Signals, 0xFF means unused
19uint8Conversion Value of AI2See Calculation of Analog Signals, 0xFF means unused
20uint8Conversion Value of AI3See Calculation of Analog Signals, 0xFF means unused
21uint8Conversion Value of AI4See Calculation of Analog Signals, 0xFF means unused
22uint8Correction Value of AIxCorresponds to AIx in 2-bit units from LSB
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Calculation of Analog Signals

The input voltage \(V\) of AIx can be expressed using the received conversion value \(e_{r}\) and correction value \(e_{fr}\) as follows:

$$\begin{align*} V &= e+e_f \\ \text{where} \\ e &= 16e_r \\ e_f &= 4e_{fr} \\ \end{align*}$$

Unit: mV

Example Output Data

:78811501C98201015A000391000C2E00810301FFFFFFFFFB

0x80: Remote Device Output Change

Controls the output signals of the remote device.

Data Format

#DataContentNote
charHeader: only
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command Number0x80 only
2uint8Format Version0x01 only
3uint8Digital SignalsCorresponds to DOx from LSB, 0 is High
4uint8Digital Signal MaskCorresponds to DOx from LSB, 1 is valid
5uint16PWM1 Signal0-1024, 0xFFFF means disabled
7uint16PWM2 Signal0-1024, 0xFFFF means disabled
9uint16PWM3 Signal0-1024, 0xFFFF means disabled
11uint16PWM4 Signal0-1024, 0xFFFF means disabled
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

UART Input/Output

0x01: Transmission of Arbitrary Data

Data Format

#DataContentNote
charHeader: only
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command Number0x01 only
2[uint8]Arbitrary DataByte sequence of length \(N\) (recommended \(N\leqq80\))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0x01: Reception of Arbitrary Data

Data Format

#DataContentNote
charHeader: only
0uint8Source Logical Device IDParent 0x00, Child 0x01-0x64, Unset Child 0x78
1uint8Command Number0x01 only
2[uint8]Arbitrary DataByte sequence of length \(N\)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

I2C Input/Output

0x88: I2C Input

Data Format

#DataContentNote
charHeader: only
0uint8Destination Logical Device IDParent 0x00, Child 0-0x7F, All Children 0x78, Self 0xDB
1uint8Packet Identifier0x88 only
2uint8Response NumberNumber output to response message
3uint8Command NumberWrite 0x1, Read 0x2, Read/Write 0x4
4uint8I2C Address7-bit
5uint8I2C CommandFirst command byte
6uint8Data Size0 means none
7[uint8]DataByte sequence of length \(N\)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0x89: I2C Output

Data Format

#DataContentNote
charHeader: only
0uint8Source Logical Device IDParent 0x00, Child 0-0x7F, All Children 0x78, Self 0xDB
1uint8Packet Identifier0x89 only
2uint8Response NumberNumber output to response message
3uint8Command NumberWrite 0x1, Read 0x2, Read/Write 0x4
4uint8ResultFailure 0, Success 1
5uint8Data Size0 means none
6[uint8]DataByte sequence of length \(N\)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

3.2.1.5 - Interactive Mode (Extremely Simple! Standard App)

Detailed configuration changes via Interactive Mode
You can perform detailed configuration of the app via Interactive Mode.

This section explains functions specific to the Extremely Simple! Standard App (App_Twelite). For common features, please refer to the TWELITE APPS manual top page.

Display Example

The following screen is displayed.

--- CONFIG/TWELITE APP V1-08-2/SID=0x8201001f/LID=0x78 ---
 a: set Application ID (0x67720102)
 i: set Device ID (--)
 c: set Channels (18)
 x: set Tx Power (03)
 t: set mode4 sleep dur (1000ms)
 y: set mode7 sleep dur (10s)
 f: set mode3 fps (32)
 z: set PWM HZ (1000,1000,1000,1000)
 o: set Option Bits (0x00000000)
 b: set UART baud (38400)
 p: set UART parity (N)
---
 S: save Configuration
 R: reset to Defaults

Commands

Command ItemDefaultRemarks
aApplication ID0x6772010232bit
iLogical Device IDAutoChild 1-100, Parent 121, Relay 122
cFrequency Channel1811-26
xTransmission Output and Retry Count03
Retry Count01-9 times, 0 means default 2 times, F disables
Transmission Output30-3
tChild Intermittent 1-second Mode Interval1000100-10000 ms
yChild Intermittent 10-second Mode Interval102-10000 s
fChild Continuous 0.03-second Mode Cycle324/8/16/32 times per second
zPWMx Frequency10001-64000 Hz, individually set by comma separation
oOption Bits0x00000000Other detailed settings
bUART Alternative Baud Rate38400Enabled by BPS pin
pUART ParityN8-( N/O/E )-1

Details of each command are shown below.

a: Application ID

All devices communicating must share the same value. It logically separates networks.

i: Logical Device ID

Set when it is necessary to identify multiple child devices.

Set any value from 1 to 100 for child devices, 121 for parent devices, and 122 for relay devices.

c: Frequency Channel

All devices communicating must share the same value. It physically separates networks.

x: Transmission Output and Retry Count

Specify the radio transmission output and the number of additional packet transmissions.

t: Child Intermittent 1-second Mode Interval

Overrides the intermittent interval of the child intermittent 1-second mode from 1 second to another value. Unit is milliseconds.

Setting 0 disables periodic wakeup by timer. In this case, wakeup occurs on falling edge of DIx but not on rising edge.

y: Child Intermittent 10-second Mode Interval

Overrides the intermittent interval of the child intermittent 10-second mode from 10 seconds to another value. Unit is seconds.

Setting 0 disables periodic wakeup by timer. In this case, wakeup occurs on falling edge of DIx but not on rising edge.

f: Child Continuous 0.03-second Mode Cycle

Overrides the number of transmission requests per second from 32 times to 4/8/16 times. Retry count is not included.

z: PWMx Frequency

If one value is specified, it overrides the frequency of all PWM ports. If specified by comma separation, individual values for PWM1 to PWM4 can be overridden.

o: Option Bits

Specify a 32bit number. Enables settings linked to each bit.

Target BitSetting ItemInitialTransmissionReceptionContinuousIntermittent
0x00000001Low Latency Mode0️⃣
0x00000002Disable Periodic Transmission0️⃣
0x00000004Disable Periodic Transmission and UART Output0️⃣
0x00000010Disable Transmission on AIx Change0️⃣
0x00000020Disable AIx Value0️⃣
0x00000040Change PWMx Calculation Formula0️⃣
0x00000100Transmit Only When Button Pressed0️⃣
0x00000800Disable Internal Pull-up of DIx0️⃣
0x00008000Add Relay Function to Child0️⃣
0x00001000Set Max Relay Steps to 2 for Child Relay0️⃣
0x00002000Set Max Relay Steps to 3 for Child Relay0️⃣
0x00010000Invert PWMx Waveform0️⃣
0x00020000Turn Off PWMx After Startup0️⃣
0x00080000Alternative Port Assignment0️⃣
0x00100000Turn Off DOx for 2 Seconds After Startup0️⃣
0x00400000Invert DOx Output0️⃣
0x00800000Disable Internal Pull-up of DOx0️⃣

b: UART Alternative Baud Rate

Overrides the alternative baud rate selected when the BPS pin is connected to GND at startup from 38400bps.

Values can be selected from 9600/19200/38400/57600/115200/230400. Specifying other values may cause errors.

p: UART Parity

N means no parity, O means odd parity, and E means even parity.

Data bits are fixed to 8, stop bits to 1. Hardware flow control cannot be set.

Details of Option Bits

Explanation of settings linked to each bit of the Option Bits value.

00000001: Low Latency Mode

Low Latency Mode shortens the delay on the receiver side by quickly transmitting after detecting changes in DIx.

00000002: Disable Periodic Transmission

Disables periodic transmission every 1 second in continuous mode for child devices.

00000004: Disable Periodic Transmission and UART Output

For child devices: disables periodic transmission every 1 second in continuous mode and stops UART output of received data.

00000010: Disable Transmission on AIx Change

For child devices: disables transmission when AIx input changes in continuous mode.

Since released AIx ports report undefined values, connect them to VCC when analog input is not used. This option allows omission of connection to VCC.

00000020: Disable AIx Value

Sends packets treating unused ports as 0xFFFF without using ADC measurement values.

00000040: Change PWMx Calculation Formula

By default, adjusted output for volume control is applied to PWMx.

This option disables that and outputs full scale for inputs below 1.8V.

00000100: Transmit Only When Button Pressed

Continuously transmits packets when DIx input is Low.

For example, used to remotely control a motor. The motor runs while the remote button is pressed and stops when the radio signal is lost.

00000800: Disable Internal Pull-up of DIx

Disables all internal pull-ups (about 50kΩ) of DIx.

00008000: Add Relay Function to Child

Adds relay function to child devices in continuous mode. Maximum relay steps is 1.

00001000: Set Max Relay Steps to 2 for Child Relay

Changes maximum relay steps to 2 when 00008000: Add Relay Function to Child is set.

00002000: Set Max Relay Steps to 3 for Child Relay

Changes maximum relay steps to 3 when 00008000: Add Relay Function to Child is set.

00010000: Invert PWMx Waveform

Inverts the output waveform of PWMx.

When maximum value is input to AIx, PWMx becomes Low.

00020000: Turn Off PWMx After Startup

Sets PWMx output to Low state after startup or reset.

00080000: Alternative Port Assignment

Enables alternative port assignment.

Connecting transistors etc. to PWM2/PWM3 may cause unstable operation (Details). Use this option in such cases.

00100000: Turn Off DOx for 2 Seconds After Startup

Sets DOx to Low state for 2 seconds after startup or reset.

You can light LEDs connected to DOx at startup.

00400000: Invert DOx Output

Inverts DOx output.

Unlike the initial state, when one DI is Low level, the other DO is High level.

00800000: Disable Internal Pull-up of DOx

Disables all internal pull-ups (about 50kΩ) of DOx.

3.3 - Parent and Repeater App Manual

For data aggregation and communication range extension.
This app receives and relays packets from TWELITE APPS such as Extremely Simple! Standard App and Pal App, as well as act.

3.3.1 - Parent and Repeater App Manual

v1.3.2 GOLD Latest version
Acts as parent or repeater for child devices of TWELITE APPS and act.

Features

Can process all data packets of TWELITE APPS and act, and can be used as common parent or repeater.

  • Collect data from multiple TWELITE APPS and act such as Extremely Simple! Standard App and Pal App with one MONOSTICK.
  • Can operate multiple systems separately on 16 channels.
  • By setting application ID, multiple systems can coexist on the same channel.
  • Communication range extension with repeater function.

3.3.1.1 - Operating Modes of Parent and Repeater App

Operating modes of Parent and Repeater App

There are two modes: Parent mode and Repeater mode.

3.3.1.1.1 - Parent Mode of Parent and Repeater App

Receives data from child devices and sends data to child devices

Receives data sent from child devices and outputs it via the serial port. Also sends commands input from the serial port to child devices.

3.3.1.1.1.1 - Messages of Parent and Repeater Apps

Output when data is received from child devices

Receives data sent from child devices and outputs it from the serial port in a predefined format.

3.3.1.1.1.1.1 - Output from the Extremely Simple! Standard App (Parent and Repeater App)

Output format when receiving data from the Extremely Simple! Standard App

0x81: Status Notification from the Peer Device

Outputs the status of the received input signals.

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Logical Device ID of Sender
1uint8Command NumberOnly 0x81
2uint8Packet IdentifierGenerated from Application ID
3uint8Protocol VersionOnly 0x01
4uint8LQI0-255
5uint32Serial ID of Sender0x8???????
9uint8Logical Device ID of Receiver
10uint16Timestamp64 counts per second
12uint8Number of Relays
13uint16Power Supply VoltageUnit: mV
15int8-(Unused)
16uint8Digital SignalsCorresponds to DIx from LSB upwards, 0 means High
If MSB is 1, periodic transmission
17uint8Digital Signal MaskCorresponds to DIx from LSB upwards, 1 means valid
18uint8Converted Value of AI1See Calculation of Analog Signals, 0xFF means unused
19uint8Converted Value of AI2See Calculation of Analog Signals, 0xFF means unused
20uint8Converted Value of AI3See Calculation of Analog Signals, 0xFF means unused
21uint8Converted Value of AI4See Calculation of Analog Signals, 0xFF means unused
22uint8Correction Value of AIxCorresponds to AIx in 2-bit increments from LSB upwards
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Calculation of Analog Signals

The input voltage \(V\) of AIx can be expressed by the received converted value \(e_{r}\) and the correction value \(e_{fr}\) as follows:

$$\begin{align*} V &= e+e_f \\ \text{where} \\ e &= 16e_r \\ e_f &= 4e_{fr} \\ \end{align*}$$

The unit is mV

Example of Output Data

:78811501C98201015A000391000C2E00810301FFFFFFFFFB
#DataDescriptionValue
:charHeader:
780uint8Logical Device ID of Sender0x78
811uint8Command Number0x81
152uint8Packet Identifier0x15
013uint8Protocol Version0x01
C94uint8LQI201/255
8201015A5uint32Serial ID of Sender0x201015A
009uint8Logical Device ID of Receiver0x00
039110uint16TimestampApprox. 14.27 seconds
0012uint8Number of Relays0
0C2E13uint16Power Supply Voltage3118 mV
0015int8-
8116uint8Digital SignalsDI1 L DI2 H
DI3 H DI4 H
(Periodic transmission)
0317uint8Digital Signal MaskDI1 DI2
0118uint8Converted Value of AI116 mV
FF19uint8Converted Value of AI2Unused
FF20uint8Converted Value of AI3Unused
FF21uint8Converted Value of AI4Unused
FF22uint8Correction Value of AIxAI1 0x03
FBuint8Checksum0xFB
charFooter\r
charFooter\n

Data Identification Conditions

The parent and relay apps can receive data from various types of child devices.

To confirm whether the output data is from the Extremely Simple! Standard App, refer to the following:

#DataItemCondition
1uint8Command NumberMust be 0x81
3uint8Protocol VersionMust be 0x01
5uint32Serial ID of SenderMSB must be 1 (i.e., 0x8???????)
--Payload SizeMust be 23 bytes (between : and checksum)

Parser Implementation Examples

0x01: Reception of Arbitrary Data

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Logical Device ID of SenderParent 0x00, Child 0x01-0x64, Unset Child 0x78
1uint8Command NumberOnly 0x01
2[uint8]Arbitrary DataByte array of length \(N\)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

3.3.1.1.1.1.2 - Output from Remote Control App (Parent and Repeater App)

Output format when data is received from the Remote Control App

0x81: Status Notification from Remote Device

Outputs the state of the received input signal.

Data Format

#DataDescriptionRemarks
charHeader: only
0uint8Source Logical Device ID
1uint8Command NumberOnly 0x81
2uint8Packet IdentifierOnly 0x0F
3uint8Protocol VersionOnly 0x01
4uint8LQI0-255
5uint32Source Serial ID0x8???????
9uint8Destination Logical Device ID
10uint16Timestamp64 counts per second, MSB is internal flag
12uint8Relay Count
13uint16Digital SignalCorresponds to Ix from LSB, 0 is High
15uint16Digital Signal MaskCorresponds to Ix from LSB, 1 means enabled
17uint16Digital Signal FlagCorresponds to Ix from LSB, 1 means interrupt triggered
19uint8UnusedInternal management
uint8ChecksumLRC8
charFooterCR (0x0D/\r)
charFooterLF (0x0A/\n)

Example of Output Data

:01810F01DB8630000200645F000040004F00400049
#DataDescriptionValue
:charHeader:
010uint8Source Logical Device ID0x78
811uint8Command Number0x81
0F2uint8Packet Identifier0x15
013uint8Protocol Version0x01
DB4uint8LQI219/255
863000025uint32Source Serial ID0x6300002
009uint8Destination Logical Device ID0x00
645F10uint16TimestampAbout 401 seconds
0012uint8Relay Count0
004013uint16Digital SignalI7 is Low
004F15uint16Digital Signal MaskI7, I1-I4 are enabled
004017uint16Digital Signal FlagI7 has changed due to interrupt
0019uint8Unused
49uint8Checksum0x49
charFooter\r
charFooter\n

Data Identification Conditions

Parent and Repeater App can receive data from various types of child devices.

To confirm that the output data is from the Remote Control App, refer to the following conditions.

#DataItemCondition
1uint8Command NumberMust be 0x81
3uint8Protocol VersionMust be 0x02
5uint32Source Serial IDMSB must be 1 (0x8???????)
--Payload SizeMust be 20 bytes (between : and checksum)

Example Parser Implementations

3.3.1.1.1.1.3 - Output from Serial Communication App (Parent and Repeater App)

Output format when receiving data from the serial communication app

Format Mode: Simple Format

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Logical device ID of senderParent 0x00, child 0x01-0x64, unassigned child 0x78
1uint8Command numberValue less than 0x80 specified by sender
2[uint8]Arbitrary dataByte array of length (N)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example of Output Data

:780100112233AABBCCDD13
#DataDescriptionValue
:charHeader:
780uint8Logical device ID of senderUnassigned child ID
011uint8Command number0x01
00112233AABBCCDD2[uint8]Arbitrary dataAs is
13uint8Checksum0x13
charFooter\r
charFooter\n

Conditions to Identify Data

The Parent and Repeater App can receive data from various types of child devices.

To verify whether the output data is from the serial communication app (format mode: simple format), refer to the following:

#DataItemCondition
0uint8Logical device ID of senderMust be less than or equal to 0x64 or equal to 0x78
1uint8Command numberMust be less than 0x80
--Payload sizeMust be between 3 and 82 bytes

Example Implementation of Parser

Format Mode: Extended Format

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Logical device ID of senderParent 0x00, child 0x01-0x64, unassigned child 0x78
1uint8Command numberOnly 0xA0
2uint8Response IDValue specified by sender
3uint32Extended address of senderValue with 0x8 added at the start of serial ID
7uint32Extended address of receiver0xFFFFFFFF when logical device ID is used
11uint8LQIRadio communication quality at reception
12uint16Length of following byte arrayNumber of bytes (M)
14[uint8]Arbitrary dataByte array of length (M)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example of Output Data

:78A0028201015AFFFFFFFFA8000700112233AABBCCC6
#DataDescriptionNotes
:charHeader:
780uint8Logical device ID of senderUnassigned child ID
A01uint8Command number0xA0
022uint8Response ID0x02
8201015A3uint32Extended address of sender0x201015A
FFFFFFFF7uint32Extended address of receiverLogical device ID specified
A811uint8LQI168/255
000712uint16Length of following byte array7 bytes
00112233AABBCC14[uint8]Arbitrary dataAs is
C6uint8Checksum0xC6
charFooter
charFooter

Conditions to Identify Data

The Parent and Repeater App can receive data from various types of child devices.

To verify whether the output data is from the serial communication app (format mode: extended format), refer to the following:

#DataItemCondition
0uint8Logical device ID of senderMust be less than or equal to 0x64 or equal to 0x78
1uint8Command numberMust be 0xA0
2uint8Response IDMust be less than 0x80
3uint32Extended address of senderMSB must be 1 (i.e., 0x8???????)
12uint16Length of following byte arrayMust be payload size - 14 bytes

Example Implementation of Parser

3.3.1.1.1.1.4 - Output from Pal/Cue/Aria Apps (Parent and Repeater App)

Output format when data is received from Pal, Cue, and Aria apps

3.3.1.1.1.1.4.1 - Output from PAL App (Parent and Repeater App)

Output format when data is received from the PAL App

General

Data received from the PAL App is represented as a series of sensor data consisting of sensor type and its value.

Below are specific examples according to the product type.

Open/Close Sensor PAL

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x81
14uint8Number of sensor dataOnly 3
Sensor data 1
15uint8Info bitsOnly 0x11
16uint8Data sourceOnly 0x30
17uint8Extended byteOnly 0x08
18uint8Data lengthOnly 2
19uint16DataPower supply voltage (mV)
Sensor data 2
21uint8Info bitsOnly 0x11
22uint8Data sourceOnly 0x30
23uint8Extended byteOnly 0x01
24uint8Data lengthOnly 2
25uint16DataADC1 voltage (mV)
Sensor data 3
27uint8Info bitsOnly 0x00
28uint8Data sourceOnly 0x00
29uint8Extended byteOnly 0x00
30uint8Data lengthOnly 1
31uint8DataMagnetic data
End of sensor data
32uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:80000000A8001C82012B1E01808103113008020D0C1130010203E40000000101EC6E
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
A84uint8LQI168/255
001C5uint16Sequence number28
82012B1E7uint32Serial ID of sender0x2012B1E
0111uint8Logical device ID of sender0x01
8012uint8Sensor type
8113uint8PAL board version and PAL board IDOpen/Close PAL V1
0314uint8Number of sensor data3
Sensor data 1
1115uint8Info bitsWith extended byte uint16
3016uint8Data sourceVoltage
0817uint8Extended bytePower supply
0218uint8Data length2 bytes
0D0C19uint16Data3340mV
Sensor data 2
1121uint8Info bitsWith extended byte uint16
3022uint8Data sourceVoltage
0123uint8Extended byteADC1
0224uint8Data length2 bytes
03E425uint16Data996mV
Sensor data 3
0027uint8Info bitsNo extended byte uint8
0028uint8Data sourceMagnetic
0029uint8Extended byteNone
0130uint8Data length1 byte
0131uint8DataN pole approached
End of sensor data
EC32uint8Checksum 10xEC
6Euint8Checksum 20x6E
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the PAL App (Open/Close Sensor PAL), refer to the following points.

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and IDMust be 0x81
--Payload size33 bytes

Example Parser Implementations

Environmental Sensor PAL

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x82
14uint8Number of sensor dataOnly 5
Sensor data 1
15uint8Info bitsOnly 0x11
16uint8Data sourceOnly 0x30
17uint8Extended byteOnly 0x08
18uint8Data lengthOnly 2
19uint16DataPower supply voltage (mV)
Sensor data 2
21uint8Info bitsOnly 0x11
22uint8Data sourceOnly 0x30
23uint8Extended byteOnly 0x01
24uint8Data lengthOnly 2
25uint16DataADC1 voltage (mV)
Sensor data 3
27uint8Info bitsOnly 0x05
28uint8Data sourceOnly 0x01
29uint8Extended byteOnly 0x00
30uint8Data lengthOnly 2
31int16DataTemperature data
Sensor data 4
33uint8Info bitsOnly 0x01
34uint8Data sourceOnly 0x02
35uint8Extended byteOnly 0x00
36uint8Data lengthOnly 2
37uint16DataHumidity data
Sensor data 5
39uint8Info bitsOnly 0x02
40uint8Data sourceOnly 0x03
41uint8Extended byteOnly 0x00
42uint8Data lengthOnly 4
43uint32DataIlluminance data
End of sensor data
47uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

​:8000000084811F810EFF6D04808205113008020AEB11300102035A0501000209E3010200020E3A02030004000001BE6C00
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
844uint8LQI132/255
811F5uint16Sequence number33055
810EFF6D7uint32Serial ID of sender0x10EFF6D
0411uint8Logical device ID of sender0x04
8012uint8Sensor type
8213uint8PAL board version and PAL board IDEnvironmental Sensor PAL V1
0514uint8Number of sensor data5
Sensor data 1
1115uint8Info bitsWith extended byte uint16
3016uint8Data sourceVoltage
0817uint8Extended bytePower supply
0218uint8Data length2 bytes
0AEB19uint16Data2795mV
Sensor data 2
1121uint8Info bitsWith extended byte uint16
3022uint8Data sourceVoltage
0123uint8Extended byteADC1
0224uint8Data length2 bytes
035A25uint16Data858mV
Sensor data 3
0527uint8Info bitsNo extended byte int16
0128uint8Data sourceTemperature
0029uint8Extended byteNone
0230uint8Data length2 bytes
09E331int16Data25.31°C
Sensor data 4
0133uint8Info bitsNo extended byte uint16
0234uint8Data sourceHumidity
0035uint8Extended byteNone
0236uint8Data length2 bytes
0E3A37uint16Data36.42%
Sensor data 5
0239uint8Info bitsNo extended byte uint32
0340uint8Data sourceIlluminance
0041uint8Extended byteNone
0442uint8Data length4 bytes
000001BE43uint32Data446lx
End of sensor data
6C47uint8Checksum 10x6C
00uint8Checksum 20x00
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the PAL App (Environmental Sensor PAL), refer to the following points.

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and IDMust be 0x82
--Payload size48 bytes

Example Parser Implementations

Motion Sensor PAL

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x83
14uint8Number of Sensor DataOnly 18
Sensor Data 1
15uint8Info bitsOnly 0x11
16uint8Data sourceOnly 0x30
17uint8Extended byteOnly 0x08
18uint8Data lengthOnly 2
19uint16DataPower supply voltage (mV)
Sensor Data 2
21uint8Info bitsOnly 0x11
22uint8Data sourceOnly 0x30
23uint8Extended byteOnly 0x01
24uint8Data lengthOnly 2
25uint16DataADC1 voltage (mV)
Sensor Data 3
27uint8Info bitsOnly 0x15
28uint8Data sourceOnly 0x04
29uint8Extended byte0x?0 Frequency and sample number
30uint8Data lengthOnly 6
31int16DataAcceleration data
Sensor Data 4
37uint8Info bitsOnly 0x15
38uint8Data sourceOnly 0x04
39uint8Extended byte0x?1 Frequency and sample number
40uint8Data lengthOnly 6
41int16DataAcceleration data
Sensor Data 5
(Omitted)
Sensor Data 18
177uint8Info bitsOnly 0x15
178uint8Data sourceOnly 0x04
179uint8Extended byte0x?F Frequency and sample number
180uint8Data lengthOnly 6
181int16DataAcceleration data
End of sensor data
187uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:80000000BA002382011CEF01808312113008020D0211300102055C1504400600100010045015044106000800100430150442060000001004381504430600080018043015044406000000180458150445060000002004381504460600080018042815044706FFE80010042015044806FFF00010043815044906FFE80018043015044A06FFF80018044015044B06FFF80018041815044C0600000010042015044D0600000028045015044E0600000008043815044F0600000018043828A5
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
BA4uint8LQI186/255
00235uint16Sequence number35
82011CEF7uint32Serial ID of sender0x2011CEF
0111uint8Logical device ID of sender0x01
8012uint8Sensor type
8313uint8PAL board version and PAL board IDMotion PAL V1
1214uint8Number of Sensor Data18 items
Sensor Data 1
1115uint8Info bitsWith extended byte uint16
3016uint8Data sourceVoltage
0817uint8Extended bytePower supply
0218uint8Data length2 bytes
0D0219uint16Data3330mV
Sensor Data 2
1121uint8Info bitsWith extended byte uint16
3022uint8Data sourceVoltage
0123uint8Extended byteADC1
0224uint8Data length2 bytes
055C25uint16Data1372mV
Sensor Data 3
1527uint8Info bitsWith extended byte int16
0428uint8Data sourceAcceleration
4029uint8Extended byte100Hz, sample 0
0630uint8Data length6 bytes
00100010045031int16DataX16mG/Y16mG/Z1104mG
Sensor Data 4
1537uint8Info bitsWith extended byte int16
0438uint8Data sourceAcceleration
4139uint8Extended byte100Hz, sample 1
0640uint8Data length6 bytes
00080010043041uint16DataX8mG/Y16mG/Z1072mG
Sensor Data 5
(Omitted)
Sensor Data 15
15177uint8Info bitsWith extended byte int16
04178uint8Data sourceAcceleration
4F179uint8Extended byte100Hz, sample 15
06180uint8Data length6 bytes
000000180438181uint32DataX0mG/Y24mG/Z1080mG
End of sensor data
28187uint8Checksum 10x28
A5uint8Checksum 20xA5
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the PAL App (Motion Sensor PAL), refer to the following points.

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and IDMust be 0x83
--Payload size188 bytes

Example Parser Implementations

Notification PAL

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x84
14uint8Number of Sensor DataOnly 3
Sensor Data 1
15uint8Info bitsOnly 0x11
16uint8Data sourceOnly 0x30
17uint8Extended byteOnly 0x08
18uint8Data lengthOnly 2
19uint16DataPower supply voltage (mV)
Sensor Data 2
21uint8Info bitsOnly 0x11
22uint8Data sourceOnly 0x30
23uint8Extended byteOnly 0x01
24uint8Data lengthOnly 2
25uint16DataADC1 voltage (mV)
Sensor Data 3
27uint8Info bitsOnly 0x12
28uint8Data sourceOnly 0x05
29uint8Extended byteOnly 0x04
30uint8Data lengthOnly 4
31uint8DataAcceleration event data
32[uint8]Unused
End of sensor data
35uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:80000000C9BBC082014C3501808403 113008020D0C 1130010203F9 1205040410000000 97C6
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
C94uint8LQI201/255
BBC05uint16Sequence number48064
82014C357uint32Serial ID of sender0x2014C35
0111uint8Logical device ID of sender0x01
8012uint8Sensor type
8413uint8PAL board version and PAL board IDNotification PAL V1
0314uint8Number of Sensor Data3 items
Sensor Data 1
1115uint8Info bitsWith extended byte uint16
3016uint8Data sourceVoltage
0817uint8Extended bytePower supply
0218uint8Data length2 bytes
0D0C19uint16Data3340mV
Sensor Data 2
1121uint8Info bitsWith extended byte uint16
3022uint8Data sourceVoltage
0123uint8Extended byteADC1
0224uint8Data length2 bytes
03F925uint16Data1017mV
Sensor Data 3
1227uint8Info bitsWith extended byte uint32
0528uint8Data sourceEvent
0429uint8Extended byteAcceleration event
0430uint8Data length4 bytes
1031uint8DataMove
00000032[uint8]
End of sensor data
9735uint8Checksum 10x97
C6uint8Checksum 20xC6
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the PAL App (Notification PAL), refer to the following points.

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and IDMust be 0x84
--Payload size36 bytes

3.3.1.1.1.1.4.2 - Output from CUE App (Parent and Repeater App)

Output format when receiving data from the CUE App

TWELITE CUE Mode

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x05
14uint8Number of sensor dataOnly 15
Sensor Data 1
15uint8Info bitsOnly 0x00
16uint8Data sourceOnly 0x34
17uint8Extended byteOnly 0x00
18uint8Data lengthOnly 3
19[uint8]DataPacket property data
Sensor Data 2
22uint8Info bitsOnly 0x12
23uint8Data sourceOnly 0x05
24uint8Extended byte0x35, 0x04, or 0x00
25uint8Data lengthOnly 4
26uint32DataEvent data
Sensor Data 3
30uint8Info bitsOnly 0x11
31uint8Data sourceOnly 0x30
32uint8Extended byteOnly 0x08
33uint8Data lengthOnly 2
34uint16DataPower supply voltage (mV)
Sensor Data 4
36uint8Info bitsOnly 0x11
37uint8Data sourceOnly 0x30
38uint8Extended byteOnly 0x01
39uint8Data lengthOnly 2
40uint16DataVoltage of ADC1 (mV)
Sensor Data 5
42uint8Info bitsOnly 0x00
43uint8Data sourceOnly 0x00
44uint8Extended byteOnly 0x00
45uint8Data lengthOnly 1
46uint8DataMagnetic data
Sensor Data 6
47uint8Info bitsOnly 0x15
48uint8Data sourceOnly 0x04
49uint8Extended byte0x?0 Frequency and sample number
50uint8Data lengthOnly 6
51[int16]DataAcceleration data
Sensor Data 7
57uint8Info bitsOnly 0x15
58uint8Data sourceOnly 0x04
59uint8Extended byte0x?1 Frequency and sample number
60uint8Data lengthOnly 6
61[int16]DataAcceleration data
Sensor Data 8
(Omitted)
Sensor Data 15
137uint8Info bitsOnly 0x15
138uint8Data sourceOnly 0x04
139uint8Extended byte0x?9 Frequency and sample number
140uint8Data lengthOnly 6
141int16DataAcceleration data
End of sensor data
147uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to Checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Output Data Example

:80000000CF7F7382019E3B0180050F003400038135001205040406000000113008020B8611300102042E000000018015044006FFF00010FC1815044106FFF00018FC1815044206FFF00010FC0015044306FFF80000FC1015044406FFF00010FC1815044506FFE00018FBF815044606FFE80000FC0015044706FFE80010FBF815044806FFE80010FC0815044906FFE80010FC080C0E
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
CF4uint8LQI207/255
7F735uint16Sequence number32627
82019E3B7uint32Serial ID of sender0x2019E3B
0111uint8Logical device ID of sender0x01
8012uint8Sensor type
0513uint8PAL board version and PAL board IDTWELITE CUE
0F14uint8Number of sensor data15 items
Sensor Data 1
0015uint8Info bitsNo extended byte uint8
3416uint8Data sourcePacket property
0017uint8Extended byteNone
0318uint8Data length3 bytes
81350019[uint8]DataID 129, timer event occurred
Sensor Data 2
1222uint8Info bitsExtended byte present uint32
0523uint8Data sourceEvent
0424uint8Extended byteAcceleration event
0425uint8Data length4 bytes
0600000026uint32DataDice: 6
Sensor Data 3
1130uint8Info bitsExtended byte present uint16
3031uint8Data sourceVoltage
0832uint8Extended bytePower supply voltage
0233uint8Data length2 bytes
0B8634uint16Data2950 mV
Sensor Data 4
1136uint8Info bitsExtended byte present uint16
3037uint8Data sourceVoltage
0138uint8Extended byteVoltage of ADC1
0239uint8Data length2 bytes
042E40uint16Data1070 mV
Sensor Data 5
0042uint8Info bitsNo extended byte uint8
0043uint8Data sourceMagnetic
0044uint8Extended byteNone
0145uint8Data length1 byte
8046uint8DataNo magnet (periodic transmit)
Sensor Data 6
1547uint8Info bitsExtended byte present int16
0448uint8Data sourceAcceleration data
4049uint8Extended byte100Hz, sample 0
0650uint8Data length6 bytes
FFF00010FC1851[int16]DataX-16mG/Y16mG/Z-1000mG
Sensor Data 7
1557uint8Info bitsExtended byte present int16
0458uint8Data sourceAcceleration data
4159uint8Extended byte100Hz, sample 1
0660uint8Data length6 bytes
FFF00018FC1861[int16]DataX-16mG/Y24mG/Z-1000mG
Sensor Data 8
(Omitted)
Sensor Data 15
15137uint8Info bitsExtended byte present int16
04138uint8Data sourceAcceleration data
49139uint8Extended byte100Hz, sample 9
06140uint8Data length6 bytes
FFE80010FC08141int16DataX-24mG/Y16mG/Z-1016mG
End of sensor data
0C147uint8Checksum 10x0C
0Euint8Checksum 20x0E
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the CUE App (TWELITE CUE mode), refer to the following points:

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and PAL board IDMust be 0x05
--Payload sizeMust be 148 bytes

Example Parser Implementations

Magnet Sensor PAL Mode

Motion Sensor PAL Mode (Acceleration Measurement Mode)

Motion Sensor PAL Mode (Move / Dice Mode)

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x03
14uint8Number of sensor dataOnly 04
Sensor Data 1
15uint8Info bitsOnly 0x00
16uint8Data sourceOnly 0x34
17uint8Extended byteOnly 0x00
18uint8Data lengthOnly 3
19[uint8]DataPacket property data
Sensor Data 2
22uint8Info bitsOnly 0x12
23uint8Data sourceOnly 0x05
24uint8Extended byteOnly 0x04
25uint8Data lengthOnly 4
26uint32DataEvent data
Sensor Data 3
30uint8Info bitsOnly 0x11
31uint8Data sourceOnly 0x30
32uint8Extended byteOnly 0x08
33uint8Data lengthOnly 2
34uint16DataPower supply voltage (mV)
Sensor Data 4
36uint8Info bitsOnly 0x11
37uint8Data sourceOnly 0x30
38uint8Extended byteOnly 0x01
39uint8Data lengthOnly 2
40uint16DataVoltage of ADC1 (mV)
End of sensor data
42uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to Checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Output Data Example

Below is an example for Dice Mode. For Move Mode, the event in Sensor Data 2 will differ.

:80000000B400048106664801800304003400038035001205040403000000113008020D2011300102052C59B7
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
B14uint8LQI177/255
00085uint16Sequence number8
810666487uint32Serial ID of sender0x2019E3B
0111uint8Logical device ID of sender0x1066648
8012uint8Sensor type
0313uint8PAL board version and PAL board IDTWELITE CUE Dice / Move
0414uint8Number of sensor data4 items
Sensor Data 1
0015uint8Info bitsNo extended byte uint8
3416uint8Data sourcePacket property
0017uint8Extended byteNone
0318uint8Data length3 bytes
80350019[uint8]DataID 128, event occurred (only ADC1 and power supply)
Sensor Data 2
1222uint8Info bitsExtended byte present uint32
0523uint8Data sourceEvent
0424uint8Extended byteAcceleration event
0425uint8Data length4 bytes
0300000026uint32DataDice Mode, die: 3
Sensor Data 3
1130uint8Info bitsExtended byte present uint16
3031uint8Data sourceVoltage
0832uint8Extended bytePower supply voltage
0233uint8Data length2 bytes
0D2034uint16Data3360 mV
Sensor Data 4
1136uint8Info bitsExtended byte present uint16
3037uint8Data sourceVoltage
0138uint8Extended byteVoltage of ADC1
0239uint8Data length2 bytes
052C40uint16Data1324 mV
End of sensor data
5942uint8Checksum 10x0C
B7uint8Checksum 20x0E
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the CUE App (Move or Dice Mode of Motion Sensor PAL Mode), refer to the following points:

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and PAL board IDMust be 0x03
--Payload sizeMust be 43 bytes

Example Parser Implementations

3.3.1.1.1.1.4.3 - Output from Aria App (Parent and Repeater App)

Output format when data is received from the Aria app

TWELITE ARIA Mode

Data Format

#DataContentRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0 to 255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x06
14uint8Number of sensor dataOnly 7
Sensor data 1
15uint8Info bitsOnly 0x00
16uint8Data sourceOnly 0x34
17uint8Extension byteOnly 0x00
18uint8Data lengthOnly 3
19[uint8]DataPacket property data
Sensor data 2
22uint8Info bitsOnly 0x12
23uint8Data sourceOnly 0x05
24uint8Extension byte0x35 or 0x00
25uint8Data lengthOnly 4
26uint32DataEvent data
Sensor data 3
30uint8Info bitsOnly 0x11
31uint8Data sourceOnly 0x30
32uint8Extension byteOnly 0x08
33uint8Data lengthOnly 2
34uint16DataPower supply voltage (mV)
Sensor data 4
36uint8Info bitsOnly 0x11
37uint8Data sourceOnly 0x30
38uint8Extension byteOnly 0x01
39uint8Data lengthOnly 2
40uint16DataADC1 voltage (mV)
Sensor data 5
42uint8Info bitsOnly 0x00
43uint8Data sourceOnly 0x00
44uint8Extension byteOnly 0x00
45uint8Data lengthOnly 1
46uint8DataMagnetic data
Sensor data 6
47uint8Info bitsOnly 0x05
48uint8Data sourceOnly 0x01
49uint8Extension byteOnly 0x00
50uint8Data lengthOnly 2
51int16DataTemperature data
Sensor data 7
53uint8Info bitsOnly 0x01
54uint8Data sourceOnly 0x02
55uint8Extension byteOnly 0x00
56uint8Data lengthOnly 2
57uint16DataHumidity data
End of sensor data
59uint8Checksum 1CRC8 up to previous byte
uint8Checksum 2LRC8 up to Checksum 1
charFooterCR (0x0D/\r)
charFooterLF (0x0A/\n)

Data Identification Conditions

Parent and Repeater App can receive data from various types of child devices.

To confirm that the output data is from the Aria App (TWELITE ARIA Mode), refer to the following:

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor type0x80
13uint8PAL board version and PAL board ID0x06
--Payload sizeMust be 60 bytes

Parser Implementation Examples

Open/Close Sensor Pal Mode

3.3.1.1.1.1.4.4 - Details of Output from Pal, Cue, and Aria Apps (Parent and Repeater App)

Details of the common output format for Pal, Cue, and Aria apps
Data received from child devices of Pal, Cue, and Aria apps are output according to a common format. This section details that format. For specific output examples of each app, see the app pages.

Overall

Data Format

#DataDescriptionNotes
charHeader: only
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDe.g. 0x81
14uint8Number of sensor data
15[uint8]List of sensor dataByte array of length (N)
15+(N)uint8Checksum 1CRC8 up to previous byte
uint8Checksum 2LRC8 up to Checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:80000000A8001C82012B1E01808103113008020D0C1130010203E40000000101EC6E
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
A84uint8LQI168/255
001C5uint16Sequence number28
82012B1E7uint32Serial ID of sender0x2012B1E
0111uint8Logical device ID of sender0x01
8012uint8Sensor type-
8113uint8PAL board version and PAL board ID0x81
0314uint8Number of sensor data3
1130...010115[uint8]List of sensor dataByte array of length 17
EC15+17uint8Checksum 10xEC
6Euint8Checksum 20x6E
charFooter'\r'
charFooter'\n'

Sensor Data

Data Format

#DataDescriptionNotes
0uint8Info bitsData type and presence of extension byte
1uint8Data sourceType of sensor value
2uint8Extension byteAdditional info for sensor value
3uint8Data lengthLength of sensor value
4[uint8]DataSensor value

Example Output Data

113008020D0C
#DataDescriptionValue
110uint8Info bitsExtension byte present, uint16
301uint8Data sourceVoltage
082uint8Extension bytePower supply voltage
023uint8Data length2 bytes
0D0C4[uint8]Data3340 mV

Info Bits

Indicates the data type of the sensor value, presence of extension byte, and read error status.

bit76543210
FunctionERR--EXT-TYP:2TYP:1TYP:0

Each function indicates the following:

FunctionDescriptionValueMeaning
ERRRead error presence0Normal
1Error present
EXTExtension byte presence0No extension byte
1Extension byte present
TYPData type000uint8
001uint16
010uint32
011N/A
100int8
101int16
110int32
111[uint8]

Data Source

Indicates the type of sensor value.

ValueDescription
0x00Magnetic
0x01Temperature
0x02Humidity
0x03Illuminance
0x04Acceleration
0x05Event
0x30Voltage
0x34Packet properties

Extension Byte

Indicates additional information such as index for continuous data.

For data sources Magnetic / Temperature / Humidity / Illuminance / Packet Properties

None

For data source Acceleration

Indicates attributes of acceleration sample data.

bit76543210
FunctionSFQ:2SFQ:1SFQ:0SNM:4SNM:3SNM:2SNM:1SNM:0

Each function indicates the following:

FunctionDescriptionValueMeaning
SFQSampling frequency000 (`0x00SNM`)
001 (`0x20SNM`)
010 (`0x40SNM`)
011 (`0x60SNM`)
100 or higherUndefined
SNMSample number0-31Oldest first

For data source Event

Indicates cause of event occurrence.

ValueDescription
0x00Magnetic
0x01Temperature
0x02Humidity
0x03Illuminance
0x04Acceleration
0x31Digital input
0x35Timer

For data source Voltage

Indicates target.

ValueDescription
0x01ADC1
0x02ADC2
0x03ADC3
0x04ADC4
0x08Power supply

Data Length

Indicates the number of bytes of the following data.

Data

Represents the sensor value.

For data source Magnetic

Data type is uint8.

ValueDescription
0x00No magnet
0x01North pole approached
0x02South pole approached
0x80No magnet (periodic send)
0x81North pole nearby (periodic send)
0x82South pole nearby (periodic send)

For data source Temperature

Data type is int16.

Represents temperature in Celsius multiplied by 100.

For data source Humidity

Data type is uint16.

Represents relative humidity multiplied by 100.

For data source Illuminance

Data type is uint32.

Represents illuminance in lux.

For data source Acceleration

Three int16 values follow.

X, Y, Z axis values (mG) total 6 bytes.

byte012345
ContentX:15-8X:7-0Y:15-8Y:7-0Z:15-8Z:7-0

For data source Event

Four uint8 values follow.

The first data indicates the event content, the rest are unused.

byte0123
ContentUsedUnusedUnusedUnused
Extension byte for Magnetic
First valueDescription
0x00No magnet
0x01North pole nearby
0x02South pole nearby
Extension byte for Acceleration
First valueDescription
0x00Stationary (Move mode)
0x01Dice: 1
0x02Dice: 2
0x03Dice: 3
0x04Dice: 4
0x05Dice: 5
0x06Dice: 6
0x08Shake
0x10Move
Extension byte for Timer
First valueDescription
0x01Woken by timer

For data source Voltage

Data type is uint16.

Represents voltage in mV.

For data source Packet Properties

Three uint8 values follow.

byte012
DataPacket IDRoot cause of wake-upCondition of wake-up

Each data indicates the following:

DataValueDescription
Packet ID0No event, only ADC1 and power voltage
1-127No event, other data present
128Event present, only ADC1 and power voltage
129-255Event present, other data present
Root cause of wake-up0x00Magnetic
0x01Temperature
0x02Humidity
0x03Illuminance
0x04Acceleration
0x31Digital input
0x35Timer
Condition of wake-up0x00Event occurred
0x01Value changed
0x02Value exceeded threshold
0x03Value fell below threshold
0x04Value met range

3.3.1.1.1.1.5 - Output from act (Parent and Repeater App)

Output format when data is received from act

Data Received from act

Data Format

#DataContentRemarks
charHeader: only
0uint8Source Logical Device ID
1uint8Command Typeonly 0xAA
2uint8Response ID0x00-0x7F
3uint32Source Serial ID
7uint32Destination Serial ID00000000 when specifying logical device ID
11uint8LQI0-255
12uint16Number of data bytes
14[uint8]Arbitrary dataLength (N) bytes
uint8ChecksumLRC8
charFooterCR (0x0D/\r)
charFooterLF (0x0A/\n)

Example of Output Data

:FEAA008201015A00000000B7000F424154310F0CEE000B03FF03FF03FF92
#DataContentValue
:charHeader:
FE0uint8Source Logical Device ID0xFE
AA1uint8Command Type0xAA
002uint8Response ID0x00
8201015A3uint32Source Serial ID0x201015A
000000007uint32Destination Serial IDLogical Device ID specified
B711uint8LQI183/255
000F12uint16Number of data bytes15 bytes
424154310F0CEE000B03FF03FF03FF14[uint8]Arbitrary dataAs is
92uint8Checksum0x92
charFooter\r
charFooter\n

3.3.1.1.1.1.6 - Output from Wireless Tag App (Parent and Repeater App)

Output format when data is received from the Wireless Tag App
This section describes the output when connecting main sensors to the child device.

Analog Sensor

Data Format

#DataDescriptionNotes
charHeader: only
0uint32Relay device serial ID80000000 if no relay
4uint8LQI0-255
5uint16Sequence number
7uint32Source serial ID
11uint8Source logical device ID
12uint8Sensor type
13uint8Power supply voltage (mV)See Power Supply Voltage Calculation
14uint16ADC1 voltage
16uint16ADC2 voltage
18uint32Unused
22uint8Checksum

Example Output Data

:80000000B700628201015A0010DF08FD09A300000000E9
#DataDescriptionValue
:charHeader:
800000000uint32Relay device serial IDNo relay
B74uint8LQI183/255
00625uint16Sequence number98
8201015A7uint32Source serial ID0x201015A
0011uint8Source logical device ID0x00
1012uint8Sensor typeAnalog sensor
DF13uint8Power supply voltage (mV)3330mV
08FD14uint16ADC1 voltage2301mV
09A316uint16ADC2 voltage2467mV
0000000018uint32Unused
E922uint8Checksum0xE9
charFooter\r
charFooter\n

Accelerometer (ADXL34x / TWELITE 2525A)

Data Format

#DataDescriptionNotes
charHeader: only
0uint32Relay device serial ID80000000 if no relay
4uint8LQI0-255
5uint16Sequence number
7uint32Source serial ID
11uint8Source logical device ID
12uint8Sensor type
13uint8Power supply voltage (mV)See Power Supply Voltage Calculation
14uint16ADC1 voltage
16uint16ADC2 voltage
18uint8Sensor mode number
19int16X-axis accelerationUnit: mG*10
21int16Y-axis accelerationUnit: mG*10
23int16Z-axis accelerationUnit: mG*10
25uint8Checksum

Example Output Data

:8000000063001781013C850035DF057702F2000000FF96FFF0BB
#DataDescriptionValue
:charHeader:
800000000uint32Relay device serial IDNo relay
634uint8LQI99/255
00175uint16Sequence number23
81013C857uint32Source serial ID0x1013C85
0011uint8Source logical device ID0x00
3512uint8Sensor typeAccelerometer (ADXL34x)
DF13uint8Power supply voltage (mV)3330mV
057714uint16ADC1 voltage1399mV
02F216uint16ADC2 voltage754mV
0018uint8Sensor mode numberNormal
000019int16X-axis acceleration0mG
FF9621int16Y-axis acceleration-1060mG
FFF023int16Z-axis acceleration-160mG
BB25uint8Checksum0xBB
charFooter\r
charFooter\n

Switch

Data Format

#DataDescriptionNotes
charHeader: only
0uint32Relay device serial ID80000000 if no relay
4uint8LQI0-255
5uint16Sequence number
7uint32Source serial ID
11uint8Source logical device ID
12uint8Sensor type
13uint8Power supply voltage (mV)See Power Supply Voltage Calculation
14uint16ADC1 voltage
16uint16ADC2 voltage
18uint8Sensor mode number0 is Hi→Lo, 1 is Lo→Hi
19uint8DI1 state1 is Lo
20uint8Unused
21uint8Checksum

Example Output Data

:800000009C00118201015A00FEDF000709A300010064
#DataDescriptionValue
:charHeader
800000000uint32Relay device serial IDNo relay
9C4uint8LQI156/255
00625uint16Sequence number98
8201015A7uint32Source serial ID0x201015A
0011uint8Source logical device ID0x00
FE12uint8Sensor typeSwitch
DF13uint8Power supply voltage (mV)3330mV
000714uint16ADC1 voltage7mV
09A316uint16ADC2 voltage2467mV
0018uint8Sensor mode numberHi→Lo
0119uint8DI1 stateLo
0020uint8Unused
6421uint8Checksum0x64
charFooter\r
charFooter\n

Power Supply Voltage Calculation

The power supply voltage \(V_{cc}\) can be expressed using the received value \(e_{cc}\) as follows:

$$\begin{cases} V_{cc} = 1950+5e_{cc} & (e_{cc} <= 170) \\ V_{cc} = 2800+10(e_{cc}-170) & (e_{cc} > 170) \end{cases}$$

Unit is mV

3.3.1.1.1.2 - Transmit Command of Parent and Repeater App

Input for sending data to the child

Commands entered from the serial port in the specified format are sent to the child.

3.3.1.1.1.2.1 - Input to the Extremely Simple! Standard App (Parent and Repeater App)

Commands to control the output of the Extremely Simple! Standard App
You can control the output of the Extremely Simple! Standard App.

Digital and Analog Input/Output

0x80: Change Output of the Target Device

Controls the output signals of the target device.

Data Format

#DataDescriptionNotes
charHeader: only
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command Number0x80 only
2uint8Format Version0x01 only
3uint8Digital SignalCorresponds to DOx from LSB, 0 means High
4uint8Digital Signal MaskCorresponds to DOx from LSB, 1 means Enabled
5uint16PWM1 Signal0-1024, 0xFFFF means Disabled
7uint16PWM2 Signal0-1024, 0xFFFF means Disabled
9uint16PWM3 Signal0-1024, 0xFFFF means Disabled
11uint16PWM4 Signal0-1024, 0xFFFF means Disabled
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

3.3.1.1.1.2.2 - Input to the Serial Communication App (Parent and Repeater App)

Commands to send data to the serial communication app
You can send data to the child device of the serial communication app (format mode, simple format).

UART

Format Mode: ASCII Simple Format

App_Wings v1.3 and later support the simple format of format mode (A).

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command NumberAny value less than 0x80
2[uint8]Arbitrary DataByte sequence of length \(N\) (recommended \(N\leqq80\))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

3.3.1.1.1.2.3 - Input to the PAL App (Notification PAL) (Parent and Repeater App)

Commands to control the LED of the Notification PAL
You can control the LED of the Notification PAL.
:0190010004000169[CR][LF]
 ^1^2^3^^^^^^^4^5
No.BytesMeaningExample DataNotes
11Destination Logical Device ID01

Specify the logical device ID of the destination TWELITE PAL.
Valid values range from 0x01 to 0x64.

21Command Type90
31Number of Command Parameters01Specify the number of command parameters. For example, set to 1 if specifying one command parameter, or 2 if specifying two.
4Number of Commands x 4Command Parameters00040001

Specify parameters such as events and LED colors.
See the command parameters section for details.

51Checksum69

Calculate the sum of bytes 1 to 4 within 8 bits and take the two’s complement. In other words, the sum of all data bytes plus the checksum byte equals zero within 8 bits.
The checksum byte is represented by two ASCII characters.
For example, in 00A01301FF123456, the sum 0x00 + 0xA0 + … + 0x56 = 0x4F, and its two’s complement is 0xB1 (i.e., 0x4F + 0xB1 = 0).
The checksum can be omitted by using ‘X’ as the checksum.

62Footer[CR][LF]Specify [CR] (0x0D) [LF] (0x0A). However, if the checksum is omitted with ‘X’, the footer can also be omitted.

Command Parameters

Combine 4-byte command parameters to specify commands.

0x00: Send Event ID

The TWELITE PAL has predefined behaviors for each received event ID. This parameter sends an event ID to the destination TWELITE PAL to trigger the configured behavior.

No.BytesContentNotes
11Command Parameter ID0x00
21Destination PAL ID

Specify the destination PAL ID.
0x04: Notification PAL
0xFF: All TWELITE PALs

31UnusedFixed at 0x00
41Event IDSpecify event ID from 0 to 16

0x01: Send LED Color, Blinking Pattern, and Brightness

Send the LED color, blinking pattern, and brightness to the destination Notification PAL.

No.BytesContentNotes
11Command Parameter ID0x01
21Color

0: Red
1: Green
2: Blue
3: Yellow
4: Purple
5: Cyan
6: White
7: Warm White

31Blinking Pattern

0: Always on
1-3: Blinking patterns (higher value means faster blinking)

41Brightness

0: Off
0x01–0x0F: Brightness (higher value means brighter)

0x02: Send Lighting Duration

Send the lighting duration of the Notification PAL’s LED.

No.BytesContentNotes
11Command Parameter ID0x02
21UnusedFixed at 0xFF
31UnusedFixed at 0x00
41Lighting DurationSpecified in seconds (0 means always on)

0x03: Specify LED Color in RGBW

Send the LED lighting color of the Notification PAL in RGBW.

No.BytesContentNotes
11Command Parameter ID0x03
21UnusedFixed at 0xFF
32LED Lighting Color

Specify 4 bits each for RGBW in order from LSB.

Higher value means brighter.

0x04: Specify Blinking Parameters

Send the blinking cycle and duty of the Notification PAL’s LED.

No.BytesContentNotes
11Command Parameter ID0x04
21UnusedFixed at 0xFF
31Blinking Time Ratio

Specify from 0x00 to 0xFF.

Higher value means longer ON time per cycle.

0x7F means ON for half of the cycle.

41Blinking Cycle

Specify from 0x00 to 0xFF.

Each increment increases the blinking cycle by about 0.04s.

0x17 corresponds to a 1-second cycle.

Command Examples

Example 1: Send Event

Command example to send event 1 to the NOTICE PAL with logical device ID 1.

:0190010004000169
 ^1^2^3^4^5^6^7^8
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands01One command
41Command ID00Command 00
51Destination PAL ID04Sent to Notification PAL
61Unused00
71Event ID01Event 10x00 to 0x10
81Checksum69

Example 2: Send LED Lighting Color to Notification PAL

Command to send LED lighting color with brightness 8 and slow blinking white to the NOTICE PAL with logical device ID 1.

:019001010601085E
 ^1^2^3^4^5^6^7^8
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands01One command
41Command Parameter ID01Command parameter ID 0x01
51Color06White
61Blinking Pattern01Blinking
71Brightness08Brightness 8Range 0x00 to 0x0F
81Checksum5E

Example 3: Send LED Lighting Color and Lighting Duration to Notification PAL

Command to light up purple and turn off after 1 second for the NOTICE PAL with logical device ID 1.

:0190020104000802FF00015E
 ^1^2^3^4^5^6^7^8^9^a^b^c
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands02Two commands
41Command Parameter ID01Command parameter ID 0x01
51Color04Purple
61Blinking Pattern00Always on
71Brightness08Brightness 8Range 0x00 to 0x0F
81Command Parameter ID02Command parameter ID 0x02
91UnusedFF
a1Unused00
b1Lighting Duration01Turns off after 1 second
c1Checksum5E

Example 4: Send Detailed Lighting Color to Notification PAL

Command to light up purple for the NOTICE PAL with logical device ID 1.

:01900103FF0F0459
 ^1^2^3^4^5^^^6^7
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands01One command
41Command Parameter ID03Command parameter ID 0x03
51UnusedFF
62LED Lighting Color0F04Lights blue at 15 and red at 4 brightness

Specify 4 bits each for RGBW in order from LSB (0–15).

Higher value means brighter.

71Checksum59

Example 5: Send LED Lighting Color and Lighting Duration to Notification PAL

Command to light up purple and turn off after 1 second for the NOTICE PAL with logical device ID 1.

:0190020104000802FF00015E
 ^1^2^3^4^5^6^7^8^9^a^b^c
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands02Two commands
41Command Parameter ID01Command parameter ID 0x01
51Color04Purple
61Blinking Pattern00Always on
71Brightness08Brightness 8Range 0x00 to 0x0F
81Command Parameter ID02Command parameter ID 0x02
91UnusedFF
a1Unused00
b1Lighting Duration01Turns off after 1 second
c1Checksum5E

3.3.1.1.2 - Repeater Mode of Parent and Repeater App

Retransmit data received from Child or Parent
In repeater mode, retransmitting received packets can extend the communication range between Child and Parent.

Example Settings

To use as a repeater, set the Operating Mode in interactive mode to 1 or higher.

Relay Methods

TWELITE NET provides two major relay methods for wireless packet delivery, as shown in the table below, which differ depending on the application. This app can identify and relay packets of the applications shown in the table below.

Relay MethodSupported Applications
Simple NetExtremely Simple! Standard App, Remote Control App, Serial Communication App, ACT
Relay NetWireless Tag App, PAL App, CUE App

Relay Using Simple Net

When relaying applications using Simple Net, setting the operating mode to 1 or higher allows up to three relays.

For example, in case 1., if there are up to 3 Repeaters between the Parent and Child, data will reach the Parent, but in case 2., if there are 4 or more Repeaters, data will not reach the Parent.

1. Child  --->  Repeater  --->  Repeater  --->  Repeater  --->  Parent
   → Parent can receive Child's data relayed 3 times.
2. Child  --->  Repeater  --->  Repeater  --->  Repeater  --->  Repeater  -x->  Parent
   → Stops relaying at the 4th relay.

Relaying with Simple Net basically uses broadcast communication and relays all received packets. The advantage is that communication to form and maintain the relay network is not necessary, but the disadvantage is that communication volume can explode as the number of Repeaters increases.

For details, please refer to here.

Relay Using Relay Net

For relaying data of applications using Relay Net with one stage of relay, set the operating mode value to 1.

When performing multiple relays, increase the operating mode setting value as the distance from the Parent increases. (It is acceptable if the setting values are in ascending order even if some values are skipped.)

The maximum number of relays for this method is up to 63 times.

Example 1: One relay\
Child ---> Repeater (Operating Mode: 1) ---> Parent

Example 2: Two relays\
Child  --->  Repeater (Operating Mode: 2) --->  Repeater (Operating Mode: **1**)  --->  Parent

Example 3: Three relays\
Child ---> Repeater (Operating Mode: 6) ---> Repeater (Operating Mode: 3) ---> Repeater (Operating Mode: 1) ---> Parent

Relay Net is a tree-type network designed to efficiently deliver upstream packets. Repeaters search for an upper layer (Parent or Repeater with a smaller operating mode setting) and relay to one discovered upper layer device.

Therefore, even if the number of Repeaters increases, the communication volume is less likely to become large compared to Simple Net, but communication occurs to discover and maintain the connection destination.

For details, please see here.

When Performing Static Routing (Directly Specifying Relay Destination)

When relaying with Relay Net, considering the layout as shown in the figure below, Repeater 2 automatically selects either the Parent or Repeater 1 as the connection destination.

Basically, fewer relays tend to have a higher delivery rate to the Parent, but if the Parent is selected as the connection destination for Repeater 2, communication quality may deteriorate due to obstacles between Parent and Repeater 2, resulting in a lower delivery rate to the Parent than when relaying through Repeater 1.

Therefore, this app has a function (static routing function) to specify the connection destination of Repeaters by TWELITE serial number.

Relay Net

When performing static routing, set the route from Repeater 2 to Repeater 1 statically, or set all routes statically.

Setting all routes increases the amount of configuration and does not support redundancy for situations such as Repeater failure or changes in radio conditions, but it eliminates the time to determine the upper communication destination and allows prompt relay operation.

To perform static routing, set the connection destination as shown in the table below: Repeater 1’s connection destination is the Parent’s SID, and Repeater 2’s connection destination is Repeater 1’s SID.

Example: Two-stage relay (Parent ← Repeater 1 ← Repeater 2 ← Child)

TWELITE SID ExampleConnection Destination (A: Access Point Address) Setting ExampleOperating Mode (l:Mode) Setting Example
Parent810F155E-0
Repeater 1810E18E8810F155E (Parent’s SID)※1
Repeater 2810F17FF810E18E8 (Repeater 1’s SID)2

※ If you only want to deal with effects caused by walls as shown in the figure, this setting is unnecessary.

3.3.1.2 - Interactive Mode (Parent and Repeater App)

Detailed configuration changes via Interactive Mode
You can configure advanced settings of the app in Interactive Mode.

This section describes functions specific to the Parent and Repeater App (App_Wings). For common functions, refer to the top page of the TWELITE APPS manual.

Display Example

A screen like the following will appear:

[CONFIG MENU/App_Wings:ROUTER:0/v1-03-2/SID=8300051A]
a: (0x67720102) Application ID [HEX:32bit]
c: (18        ) Channel(s)
x: (      0x03) RF Power/Retransmissions [HEX:8bit]
b: (115200,8N1) UART Baud Alt. [XXXXX]
o: (0x00000001) Option bits [HEX:32bit]
t: (0xA5A5A5A5) Encryption key [HEX: 32bits]
m: (         1) [1] default, [2-63] to specify the layer of the LayerNetwork.
A: (0x00000000) Relay destination [HEX:32bit]

 [ESC]:Exit [!]:Reset System [*]:Extr Menu [:]:AppSel

Note: m and A are for repeater mode only.

Commands

ItemDefault ValueNotes
aApplication ID0x6772010232bit
cFrequency Channel181126
xTx Power and Retry Count03
Retry Count019 times, 0 = initial value
Tx Power303
bAlternative UART Settings38400,8N1Enabled via option bit
oOption Bits0x00000000Other detailed settings
kEncryption Key0xA5A5A5A532bit
mOperation Mode0Repeater only. 1=normal, 163=layer
ARelay Destination0x00000000Repeater mode only

Details of each command are as follows:

a: Application ID

All devices that communicate must use the same value. This logically separates networks.

c: Frequency Channel

All devices that communicate must use the same value. This physically separates networks.

x: Tx Power and Retry Count

Specify the radio transmission power and the number of additional transmissions per packet.

b: Alternative UART Settings

Specify UART options when Enabling Alternative UART Settings is enabled in the Option Bits.

You can choose a baud rate from 9600 / 19200 / 38400 / 57600 / 115200 / 230400.

o: Option Bits

Specify a 32-bit value. Each bit enables a corresponding setting.

Bit FlagSetting DescriptionDefault
0x00000200Enabling Alternative UART Settings0️⃣
0x00000400Suppress Periodic Transmission Output0️⃣
0x00001000Enable Encrypted Communication0️⃣
0x00002000Enable Plaintext Reception in Encrypted Mode0️⃣
0x00010000Disable LED0️⃣
0x00020000Disable LED in Standby0️⃣

k: Encryption Key

Specify a 32-bit hexadecimal encryption key when Enable Encrypted Communication is set in the Option Bits.

m: Operation Mode

Set 0 for parent mode, and 1 for repeater mode.

When using multi-hop relaying in repeater mode, you can specify the relay layer with a value from 2 to 63.

A: Relay Destination

When performing static routing in repeater mode, specify the Serial ID (0x8???????) of the upstream device. If set to 0x00000000, it will search automatically.

Details of Option Bits

This section explains the settings associated with each bit in the Option Bits value.

00000200: Enabling Alternative UART Settings

Enables b: Alternative UART Settings.

00000400: Suppress Periodic Transmission Output

Suppresses the 1-second periodic transmission and continuous UART output of the Extremely Simple! Standard App and Remote App.

00001000: Enable Encrypted Communication

Enables encrypted communication. The other side must also have encryption enabled.

00002000: Enable Plaintext Reception in Encrypted Mode

Allows reception of unencrypted packets even when encrypted communication is enabled.

00010000: Disable LED

Disables the LED on TWELITE STICK and MONOSTICK.

00020000: Disable LED in Standby

Disables the LED on TWELITE STICK and MONOSTICK while in standby.

3.3.2 - Parent and Repeater App Manual

v1.2.1 BLUE/RED Stable version
Acts as parent or repeater for child devices of TWELITE APPS and act.

Features

Can process all data packets of TWELITE APPS and act, and can be used as common parent or repeater.

  • Collect data from multiple TWELITE APPS and act such as Extremely Simple! Standard App and Pal App with one MONOSTICK.
  • Can operate multiple systems separately on 16 channels.
  • By setting application ID, multiple systems can coexist on the same channel.
  • Communication range extension with repeater function.

3.3.2.1 - Operating Modes of Parent and Repeater App

Operating modes of Parent and Repeater App

There are two modes: Parent mode and Repeater mode.

3.3.2.1.1 - Parent Mode of Parent and Repeater App

Receives data from child devices and sends data to child devices

Receives data sent from child devices and outputs it via the serial port. Also sends commands input from the serial port to child devices.

3.3.2.1.1.1 - Messages of Parent and Repeater Apps

Output when data is received from child devices

Receives data sent from child devices and outputs it from the serial port in a predefined format.

3.3.2.1.1.1.1 - Output from the Extremely Simple! Standard App (Parent and Repeater App)

Output format when receiving data from the Extremely Simple! Standard App

0x81: Status Notification from the Peer Device

Outputs the status of the received input signals.

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Logical Device ID of Sender
1uint8Command NumberOnly 0x81
2uint8Packet IdentifierGenerated from Application ID
3uint8Protocol VersionOnly 0x01
4uint8LQI0-255
5uint32Serial ID of Sender0x8???????
9uint8Logical Device ID of Receiver
10uint16Timestamp64 counts per second
12uint8Number of Relays
13uint16Power Supply VoltageUnit: mV
15int8-(Unused)
16uint8Digital SignalsCorresponds to DIx from LSB upwards, 0 means High
If MSB is 1, periodic transmission
17uint8Digital Signal MaskCorresponds to DIx from LSB upwards, 1 means valid
18uint8Converted Value of AI1See Calculation of Analog Signals, 0xFF means unused
19uint8Converted Value of AI2See Calculation of Analog Signals, 0xFF means unused
20uint8Converted Value of AI3See Calculation of Analog Signals, 0xFF means unused
21uint8Converted Value of AI4See Calculation of Analog Signals, 0xFF means unused
22uint8Correction Value of AIxCorresponds to AIx in 2-bit increments from LSB upwards
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Calculation of Analog Signals

The input voltage \(V\) of AIx can be expressed by the received converted value \(e_{r}\) and the correction value \(e_{fr}\) as follows:

$$\begin{align*} V &= e+e_f \\ \text{where} \\ e &= 16e_r \\ e_f &= 4e_{fr} \\ \end{align*}$$

The unit is mV

Example of Output Data

:78811501C98201015A000391000C2E00810301FFFFFFFFFB
#DataDescriptionValue
:charHeader:
780uint8Logical Device ID of Sender0x78
811uint8Command Number0x81
152uint8Packet Identifier0x15
013uint8Protocol Version0x01
C94uint8LQI201/255
8201015A5uint32Serial ID of Sender0x201015A
009uint8Logical Device ID of Receiver0x00
039110uint16TimestampApprox. 14.27 seconds
0012uint8Number of Relays0
0C2E13uint16Power Supply Voltage3118 mV
0015int8-
8116uint8Digital SignalsDI1 L DI2 H
DI3 H DI4 H
(Periodic transmission)
0317uint8Digital Signal MaskDI1 DI2
0118uint8Converted Value of AI116 mV
FF19uint8Converted Value of AI2Unused
FF20uint8Converted Value of AI3Unused
FF21uint8Converted Value of AI4Unused
FF22uint8Correction Value of AIxAI1 0x03
FBuint8Checksum0xFB
charFooter\r
charFooter\n

Data Identification Conditions

The parent and relay apps can receive data from various types of child devices.

To confirm whether the output data is from the Extremely Simple! Standard App, refer to the following:

#DataItemCondition
1uint8Command NumberMust be 0x81
3uint8Protocol VersionMust be 0x01
5uint32Serial ID of SenderMSB must be 1 (i.e., 0x8???????)
--Payload SizeMust be 23 bytes (between : and checksum)

Parser Implementation Examples

0x01: Reception of Arbitrary Data

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Logical Device ID of SenderParent 0x00, Child 0x01-0x64, Unset Child 0x78
1uint8Command NumberOnly 0x01
2[uint8]Arbitrary DataByte array of length \(N\)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

3.3.2.1.1.1.2 - Output from Remote Control App (Parent and Repeater App)

Output format when data is received from the Remote Control App

0x81: Status Notification from Remote Device

Outputs the state of the received input signal.

Data Format

#DataDescriptionRemarks
charHeader: only
0uint8Source Logical Device ID
1uint8Command NumberOnly 0x81
2uint8Packet IdentifierOnly 0x0F
3uint8Protocol VersionOnly 0x01
4uint8LQI0-255
5uint32Source Serial ID0x8???????
9uint8Destination Logical Device ID
10uint16Timestamp64 counts per second, MSB is internal flag
12uint8Relay Count
13uint16Digital SignalCorresponds to Ix from LSB, 0 is High
15uint16Digital Signal MaskCorresponds to Ix from LSB, 1 means enabled
17uint16Digital Signal FlagCorresponds to Ix from LSB, 1 means interrupt triggered
19uint8UnusedInternal management
uint8ChecksumLRC8
charFooterCR (0x0D/\r)
charFooterLF (0x0A/\n)

Example of Output Data

:01810F01DB8630000200645F000040004F00400049
#DataDescriptionValue
:charHeader:
010uint8Source Logical Device ID0x78
811uint8Command Number0x81
0F2uint8Packet Identifier0x15
013uint8Protocol Version0x01
DB4uint8LQI219/255
863000025uint32Source Serial ID0x6300002
009uint8Destination Logical Device ID0x00
645F10uint16TimestampAbout 401 seconds
0012uint8Relay Count0
004013uint16Digital SignalI7 is Low
004F15uint16Digital Signal MaskI7, I1-I4 are enabled
004017uint16Digital Signal FlagI7 has changed due to interrupt
0019uint8Unused
49uint8Checksum0x49
charFooter\r
charFooter\n

Data Identification Conditions

Parent and Repeater App can receive data from various types of child devices.

To confirm that the output data is from the Remote Control App, refer to the following conditions.

#DataItemCondition
1uint8Command NumberMust be 0x81
3uint8Protocol VersionMust be 0x02
5uint32Source Serial IDMSB must be 1 (0x8???????)
--Payload SizeMust be 20 bytes (between : and checksum)

Example Parser Implementations

3.3.2.1.1.1.3 - Output from Serial Communication App (Parent and Repeater App)

Output format when receiving data from the serial communication app

Format Mode: Simple Format

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Logical device ID of senderParent 0x00, child 0x01-0x64, unassigned child 0x78
1uint8Command numberValue less than 0x80 specified by sender
2[uint8]Arbitrary dataByte array of length (N)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example of Output Data

:780100112233AABBCCDD13
#DataDescriptionValue
:charHeader:
780uint8Logical device ID of senderUnassigned child ID
011uint8Command number0x01
00112233AABBCCDD2[uint8]Arbitrary dataAs is
13uint8Checksum0x13
charFooter\r
charFooter\n

Conditions to Identify Data

The Parent and Repeater App can receive data from various types of child devices.

To verify whether the output data is from the serial communication app (format mode: simple format), refer to the following:

#DataItemCondition
0uint8Logical device ID of senderMust be less than or equal to 0x64 or equal to 0x78
1uint8Command numberMust be less than 0x80
--Payload sizeMust be between 3 and 82 bytes

Example Implementation of Parser

Format Mode: Extended Format

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Logical device ID of senderParent 0x00, child 0x01-0x64, unassigned child 0x78
1uint8Command numberOnly 0xA0
2uint8Response IDValue specified by sender
3uint32Extended address of senderValue with 0x8 added at the start of serial ID
7uint32Extended address of receiver0xFFFFFFFF when logical device ID is used
11uint8LQIRadio communication quality at reception
12uint16Length of following byte arrayNumber of bytes (M)
14[uint8]Arbitrary dataByte array of length (M)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example of Output Data

:78A0028201015AFFFFFFFFA8000700112233AABBCCC6
#DataDescriptionNotes
:charHeader:
780uint8Logical device ID of senderUnassigned child ID
A01uint8Command number0xA0
022uint8Response ID0x02
8201015A3uint32Extended address of sender0x201015A
FFFFFFFF7uint32Extended address of receiverLogical device ID specified
A811uint8LQI168/255
000712uint16Length of following byte array7 bytes
00112233AABBCC14[uint8]Arbitrary dataAs is
C6uint8Checksum0xC6
charFooter
charFooter

Conditions to Identify Data

The Parent and Repeater App can receive data from various types of child devices.

To verify whether the output data is from the serial communication app (format mode: extended format), refer to the following:

#DataItemCondition
0uint8Logical device ID of senderMust be less than or equal to 0x64 or equal to 0x78
1uint8Command numberMust be 0xA0
2uint8Response IDMust be less than 0x80
3uint32Extended address of senderMSB must be 1 (i.e., 0x8???????)
12uint16Length of following byte arrayMust be payload size - 14 bytes

Example Implementation of Parser

3.3.2.1.1.1.4 - Output from Pal/Cue/Aria Apps (Parent and Repeater App)

Output format when data is received from Pal, Cue, and Aria apps

3.3.2.1.1.1.4.1 - Output from PAL App (Parent and Repeater App)

Output format when data is received from the PAL App

General

Data received from the PAL App is represented as a series of sensor data consisting of sensor type and its value.

Below are specific examples according to the product type.

Open/Close Sensor PAL

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x81
14uint8Number of sensor dataOnly 3
Sensor data 1
15uint8Info bitsOnly 0x11
16uint8Data sourceOnly 0x30
17uint8Extended byteOnly 0x08
18uint8Data lengthOnly 2
19uint16DataPower supply voltage (mV)
Sensor data 2
21uint8Info bitsOnly 0x11
22uint8Data sourceOnly 0x30
23uint8Extended byteOnly 0x01
24uint8Data lengthOnly 2
25uint16DataADC1 voltage (mV)
Sensor data 3
27uint8Info bitsOnly 0x00
28uint8Data sourceOnly 0x00
29uint8Extended byteOnly 0x00
30uint8Data lengthOnly 1
31uint8DataMagnetic data
End of sensor data
32uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:80000000A8001C82012B1E01808103113008020D0C1130010203E40000000101EC6E
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
A84uint8LQI168/255
001C5uint16Sequence number28
82012B1E7uint32Serial ID of sender0x2012B1E
0111uint8Logical device ID of sender0x01
8012uint8Sensor type
8113uint8PAL board version and PAL board IDOpen/Close PAL V1
0314uint8Number of sensor data3
Sensor data 1
1115uint8Info bitsWith extended byte uint16
3016uint8Data sourceVoltage
0817uint8Extended bytePower supply
0218uint8Data length2 bytes
0D0C19uint16Data3340mV
Sensor data 2
1121uint8Info bitsWith extended byte uint16
3022uint8Data sourceVoltage
0123uint8Extended byteADC1
0224uint8Data length2 bytes
03E425uint16Data996mV
Sensor data 3
0027uint8Info bitsNo extended byte uint8
0028uint8Data sourceMagnetic
0029uint8Extended byteNone
0130uint8Data length1 byte
0131uint8DataN pole approached
End of sensor data
EC32uint8Checksum 10xEC
6Euint8Checksum 20x6E
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the PAL App (Open/Close Sensor PAL), refer to the following points.

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and IDMust be 0x81
--Payload size33 bytes

Example Parser Implementations

Environmental Sensor PAL

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x82
14uint8Number of sensor dataOnly 5
Sensor data 1
15uint8Info bitsOnly 0x11
16uint8Data sourceOnly 0x30
17uint8Extended byteOnly 0x08
18uint8Data lengthOnly 2
19uint16DataPower supply voltage (mV)
Sensor data 2
21uint8Info bitsOnly 0x11
22uint8Data sourceOnly 0x30
23uint8Extended byteOnly 0x01
24uint8Data lengthOnly 2
25uint16DataADC1 voltage (mV)
Sensor data 3
27uint8Info bitsOnly 0x05
28uint8Data sourceOnly 0x01
29uint8Extended byteOnly 0x00
30uint8Data lengthOnly 2
31int16DataTemperature data
Sensor data 4
33uint8Info bitsOnly 0x01
34uint8Data sourceOnly 0x02
35uint8Extended byteOnly 0x00
36uint8Data lengthOnly 2
37uint16DataHumidity data
Sensor data 5
39uint8Info bitsOnly 0x02
40uint8Data sourceOnly 0x03
41uint8Extended byteOnly 0x00
42uint8Data lengthOnly 4
43uint32DataIlluminance data
End of sensor data
47uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

​:8000000084811F810EFF6D04808205113008020AEB11300102035A0501000209E3010200020E3A02030004000001BE6C00
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
844uint8LQI132/255
811F5uint16Sequence number33055
810EFF6D7uint32Serial ID of sender0x10EFF6D
0411uint8Logical device ID of sender0x04
8012uint8Sensor type
8213uint8PAL board version and PAL board IDEnvironmental Sensor PAL V1
0514uint8Number of sensor data5
Sensor data 1
1115uint8Info bitsWith extended byte uint16
3016uint8Data sourceVoltage
0817uint8Extended bytePower supply
0218uint8Data length2 bytes
0AEB19uint16Data2795mV
Sensor data 2
1121uint8Info bitsWith extended byte uint16
3022uint8Data sourceVoltage
0123uint8Extended byteADC1
0224uint8Data length2 bytes
035A25uint16Data858mV
Sensor data 3
0527uint8Info bitsNo extended byte int16
0128uint8Data sourceTemperature
0029uint8Extended byteNone
0230uint8Data length2 bytes
09E331int16Data25.31°C
Sensor data 4
0133uint8Info bitsNo extended byte uint16
0234uint8Data sourceHumidity
0035uint8Extended byteNone
0236uint8Data length2 bytes
0E3A37uint16Data36.42%
Sensor data 5
0239uint8Info bitsNo extended byte uint32
0340uint8Data sourceIlluminance
0041uint8Extended byteNone
0442uint8Data length4 bytes
000001BE43uint32Data446lx
End of sensor data
6C47uint8Checksum 10x6C
00uint8Checksum 20x00
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the PAL App (Environmental Sensor PAL), refer to the following points.

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and IDMust be 0x82
--Payload size48 bytes

Example Parser Implementations

Motion Sensor PAL

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x83
14uint8Number of Sensor DataOnly 18
Sensor Data 1
15uint8Info bitsOnly 0x11
16uint8Data sourceOnly 0x30
17uint8Extended byteOnly 0x08
18uint8Data lengthOnly 2
19uint16DataPower supply voltage (mV)
Sensor Data 2
21uint8Info bitsOnly 0x11
22uint8Data sourceOnly 0x30
23uint8Extended byteOnly 0x01
24uint8Data lengthOnly 2
25uint16DataADC1 voltage (mV)
Sensor Data 3
27uint8Info bitsOnly 0x15
28uint8Data sourceOnly 0x04
29uint8Extended byte0x?0 Frequency and sample number
30uint8Data lengthOnly 6
31int16DataAcceleration data
Sensor Data 4
37uint8Info bitsOnly 0x15
38uint8Data sourceOnly 0x04
39uint8Extended byte0x?1 Frequency and sample number
40uint8Data lengthOnly 6
41int16DataAcceleration data
Sensor Data 5
(Omitted)
Sensor Data 18
177uint8Info bitsOnly 0x15
178uint8Data sourceOnly 0x04
179uint8Extended byte0x?F Frequency and sample number
180uint8Data lengthOnly 6
181int16DataAcceleration data
End of sensor data
187uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:80000000BA002382011CEF01808312113008020D0211300102055C1504400600100010045015044106000800100430150442060000001004381504430600080018043015044406000000180458150445060000002004381504460600080018042815044706FFE80010042015044806FFF00010043815044906FFE80018043015044A06FFF80018044015044B06FFF80018041815044C0600000010042015044D0600000028045015044E0600000008043815044F0600000018043828A5
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
BA4uint8LQI186/255
00235uint16Sequence number35
82011CEF7uint32Serial ID of sender0x2011CEF
0111uint8Logical device ID of sender0x01
8012uint8Sensor type
8313uint8PAL board version and PAL board IDMotion PAL V1
1214uint8Number of Sensor Data18 items
Sensor Data 1
1115uint8Info bitsWith extended byte uint16
3016uint8Data sourceVoltage
0817uint8Extended bytePower supply
0218uint8Data length2 bytes
0D0219uint16Data3330mV
Sensor Data 2
1121uint8Info bitsWith extended byte uint16
3022uint8Data sourceVoltage
0123uint8Extended byteADC1
0224uint8Data length2 bytes
055C25uint16Data1372mV
Sensor Data 3
1527uint8Info bitsWith extended byte int16
0428uint8Data sourceAcceleration
4029uint8Extended byte100Hz, sample 0
0630uint8Data length6 bytes
00100010045031int16DataX16mG/Y16mG/Z1104mG
Sensor Data 4
1537uint8Info bitsWith extended byte int16
0438uint8Data sourceAcceleration
4139uint8Extended byte100Hz, sample 1
0640uint8Data length6 bytes
00080010043041uint16DataX8mG/Y16mG/Z1072mG
Sensor Data 5
(Omitted)
Sensor Data 15
15177uint8Info bitsWith extended byte int16
04178uint8Data sourceAcceleration
4F179uint8Extended byte100Hz, sample 15
06180uint8Data length6 bytes
000000180438181uint32DataX0mG/Y24mG/Z1080mG
End of sensor data
28187uint8Checksum 10x28
A5uint8Checksum 20xA5
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the PAL App (Motion Sensor PAL), refer to the following points.

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and IDMust be 0x83
--Payload size188 bytes

Example Parser Implementations

Notification PAL

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x84
14uint8Number of Sensor DataOnly 3
Sensor Data 1
15uint8Info bitsOnly 0x11
16uint8Data sourceOnly 0x30
17uint8Extended byteOnly 0x08
18uint8Data lengthOnly 2
19uint16DataPower supply voltage (mV)
Sensor Data 2
21uint8Info bitsOnly 0x11
22uint8Data sourceOnly 0x30
23uint8Extended byteOnly 0x01
24uint8Data lengthOnly 2
25uint16DataADC1 voltage (mV)
Sensor Data 3
27uint8Info bitsOnly 0x12
28uint8Data sourceOnly 0x05
29uint8Extended byteOnly 0x04
30uint8Data lengthOnly 4
31uint8DataAcceleration event data
32[uint8]Unused
End of sensor data
35uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:80000000C9BBC082014C3501808403 113008020D0C 1130010203F9 1205040410000000 97C6
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
C94uint8LQI201/255
BBC05uint16Sequence number48064
82014C357uint32Serial ID of sender0x2014C35
0111uint8Logical device ID of sender0x01
8012uint8Sensor type
8413uint8PAL board version and PAL board IDNotification PAL V1
0314uint8Number of Sensor Data3 items
Sensor Data 1
1115uint8Info bitsWith extended byte uint16
3016uint8Data sourceVoltage
0817uint8Extended bytePower supply
0218uint8Data length2 bytes
0D0C19uint16Data3340mV
Sensor Data 2
1121uint8Info bitsWith extended byte uint16
3022uint8Data sourceVoltage
0123uint8Extended byteADC1
0224uint8Data length2 bytes
03F925uint16Data1017mV
Sensor Data 3
1227uint8Info bitsWith extended byte uint32
0528uint8Data sourceEvent
0429uint8Extended byteAcceleration event
0430uint8Data length4 bytes
1031uint8DataMove
00000032[uint8]
End of sensor data
9735uint8Checksum 10x97
C6uint8Checksum 20xC6
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the PAL App (Notification PAL), refer to the following points.

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and IDMust be 0x84
--Payload size36 bytes

3.3.2.1.1.1.4.2 - Output from CUE App (Parent and Repeater App)

Output format when receiving data from the CUE App

TWELITE CUE Mode

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x05
14uint8Number of sensor dataOnly 15
Sensor Data 1
15uint8Info bitsOnly 0x00
16uint8Data sourceOnly 0x34
17uint8Extended byteOnly 0x00
18uint8Data lengthOnly 3
19[uint8]DataPacket property data
Sensor Data 2
22uint8Info bitsOnly 0x12
23uint8Data sourceOnly 0x05
24uint8Extended byte0x35, 0x04, or 0x00
25uint8Data lengthOnly 4
26uint32DataEvent data
Sensor Data 3
30uint8Info bitsOnly 0x11
31uint8Data sourceOnly 0x30
32uint8Extended byteOnly 0x08
33uint8Data lengthOnly 2
34uint16DataPower supply voltage (mV)
Sensor Data 4
36uint8Info bitsOnly 0x11
37uint8Data sourceOnly 0x30
38uint8Extended byteOnly 0x01
39uint8Data lengthOnly 2
40uint16DataVoltage of ADC1 (mV)
Sensor Data 5
42uint8Info bitsOnly 0x00
43uint8Data sourceOnly 0x00
44uint8Extended byteOnly 0x00
45uint8Data lengthOnly 1
46uint8DataMagnetic data
Sensor Data 6
47uint8Info bitsOnly 0x15
48uint8Data sourceOnly 0x04
49uint8Extended byte0x?0 Frequency and sample number
50uint8Data lengthOnly 6
51[int16]DataAcceleration data
Sensor Data 7
57uint8Info bitsOnly 0x15
58uint8Data sourceOnly 0x04
59uint8Extended byte0x?1 Frequency and sample number
60uint8Data lengthOnly 6
61[int16]DataAcceleration data
Sensor Data 8
(Omitted)
Sensor Data 15
137uint8Info bitsOnly 0x15
138uint8Data sourceOnly 0x04
139uint8Extended byte0x?9 Frequency and sample number
140uint8Data lengthOnly 6
141int16DataAcceleration data
End of sensor data
147uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to Checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Output Data Example

:80000000CF7F7382019E3B0180050F003400038135001205040406000000113008020B8611300102042E000000018015044006FFF00010FC1815044106FFF00018FC1815044206FFF00010FC0015044306FFF80000FC1015044406FFF00010FC1815044506FFE00018FBF815044606FFE80000FC0015044706FFE80010FBF815044806FFE80010FC0815044906FFE80010FC080C0E
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
CF4uint8LQI207/255
7F735uint16Sequence number32627
82019E3B7uint32Serial ID of sender0x2019E3B
0111uint8Logical device ID of sender0x01
8012uint8Sensor type
0513uint8PAL board version and PAL board IDTWELITE CUE
0F14uint8Number of sensor data15 items
Sensor Data 1
0015uint8Info bitsNo extended byte uint8
3416uint8Data sourcePacket property
0017uint8Extended byteNone
0318uint8Data length3 bytes
81350019[uint8]DataID 129, timer event occurred
Sensor Data 2
1222uint8Info bitsExtended byte present uint32
0523uint8Data sourceEvent
0424uint8Extended byteAcceleration event
0425uint8Data length4 bytes
0600000026uint32DataDice: 6
Sensor Data 3
1130uint8Info bitsExtended byte present uint16
3031uint8Data sourceVoltage
0832uint8Extended bytePower supply voltage
0233uint8Data length2 bytes
0B8634uint16Data2950 mV
Sensor Data 4
1136uint8Info bitsExtended byte present uint16
3037uint8Data sourceVoltage
0138uint8Extended byteVoltage of ADC1
0239uint8Data length2 bytes
042E40uint16Data1070 mV
Sensor Data 5
0042uint8Info bitsNo extended byte uint8
0043uint8Data sourceMagnetic
0044uint8Extended byteNone
0145uint8Data length1 byte
8046uint8DataNo magnet (periodic transmit)
Sensor Data 6
1547uint8Info bitsExtended byte present int16
0448uint8Data sourceAcceleration data
4049uint8Extended byte100Hz, sample 0
0650uint8Data length6 bytes
FFF00010FC1851[int16]DataX-16mG/Y16mG/Z-1000mG
Sensor Data 7
1557uint8Info bitsExtended byte present int16
0458uint8Data sourceAcceleration data
4159uint8Extended byte100Hz, sample 1
0660uint8Data length6 bytes
FFF00018FC1861[int16]DataX-16mG/Y24mG/Z-1000mG
Sensor Data 8
(Omitted)
Sensor Data 15
15137uint8Info bitsExtended byte present int16
04138uint8Data sourceAcceleration data
49139uint8Extended byte100Hz, sample 9
06140uint8Data length6 bytes
FFE80010FC08141int16DataX-24mG/Y16mG/Z-1016mG
End of sensor data
0C147uint8Checksum 10x0C
0Euint8Checksum 20x0E
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the CUE App (TWELITE CUE mode), refer to the following points:

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and PAL board IDMust be 0x05
--Payload sizeMust be 148 bytes

Example Parser Implementations

Magnet Sensor PAL Mode

Motion Sensor PAL Mode (Acceleration Measurement Mode)

Motion Sensor PAL Mode (Move / Dice Mode)

Data Format

#DataDescriptionRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x03
14uint8Number of sensor dataOnly 04
Sensor Data 1
15uint8Info bitsOnly 0x00
16uint8Data sourceOnly 0x34
17uint8Extended byteOnly 0x00
18uint8Data lengthOnly 3
19[uint8]DataPacket property data
Sensor Data 2
22uint8Info bitsOnly 0x12
23uint8Data sourceOnly 0x05
24uint8Extended byteOnly 0x04
25uint8Data lengthOnly 4
26uint32DataEvent data
Sensor Data 3
30uint8Info bitsOnly 0x11
31uint8Data sourceOnly 0x30
32uint8Extended byteOnly 0x08
33uint8Data lengthOnly 2
34uint16DataPower supply voltage (mV)
Sensor Data 4
36uint8Info bitsOnly 0x11
37uint8Data sourceOnly 0x30
38uint8Extended byteOnly 0x01
39uint8Data lengthOnly 2
40uint16DataVoltage of ADC1 (mV)
End of sensor data
42uint8Checksum 1CRC8 up to this point
uint8Checksum 2LRC8 up to Checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Output Data Example

Below is an example for Dice Mode. For Move Mode, the event in Sensor Data 2 will differ.

:80000000B400048106664801800304003400038035001205040403000000113008020D2011300102052C59B7
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
B14uint8LQI177/255
00085uint16Sequence number8
810666487uint32Serial ID of sender0x2019E3B
0111uint8Logical device ID of sender0x1066648
8012uint8Sensor type
0313uint8PAL board version and PAL board IDTWELITE CUE Dice / Move
0414uint8Number of sensor data4 items
Sensor Data 1
0015uint8Info bitsNo extended byte uint8
3416uint8Data sourcePacket property
0017uint8Extended byteNone
0318uint8Data length3 bytes
80350019[uint8]DataID 128, event occurred (only ADC1 and power supply)
Sensor Data 2
1222uint8Info bitsExtended byte present uint32
0523uint8Data sourceEvent
0424uint8Extended byteAcceleration event
0425uint8Data length4 bytes
0300000026uint32DataDice Mode, die: 3
Sensor Data 3
1130uint8Info bitsExtended byte present uint16
3031uint8Data sourceVoltage
0832uint8Extended bytePower supply voltage
0233uint8Data length2 bytes
0D2034uint16Data3360 mV
Sensor Data 4
1136uint8Info bitsExtended byte present uint16
3037uint8Data sourceVoltage
0138uint8Extended byteVoltage of ADC1
0239uint8Data length2 bytes
052C40uint16Data1324 mV
End of sensor data
5942uint8Checksum 10x0C
B7uint8Checksum 20x0E
charFooter'\r'
charFooter'\n'

Data Identification Criteria

The Parent and Repeater App can receive data from various types of child devices.

To check whether the output data is from the CUE App (Move or Dice Mode of Motion Sensor PAL Mode), refer to the following points:

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor typeMust be 0x80
13uint8PAL board version and PAL board IDMust be 0x03
--Payload sizeMust be 43 bytes

Example Parser Implementations

3.3.2.1.1.1.4.3 - Output from Aria App (Parent and Repeater App)

Output format when data is received from the Aria app

TWELITE ARIA Mode

Data Format

#DataContentRemarks
charHeaderOnly :
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0 to 255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDOnly 0x06
14uint8Number of sensor dataOnly 7
Sensor data 1
15uint8Info bitsOnly 0x00
16uint8Data sourceOnly 0x34
17uint8Extension byteOnly 0x00
18uint8Data lengthOnly 3
19[uint8]DataPacket property data
Sensor data 2
22uint8Info bitsOnly 0x12
23uint8Data sourceOnly 0x05
24uint8Extension byte0x35 or 0x00
25uint8Data lengthOnly 4
26uint32DataEvent data
Sensor data 3
30uint8Info bitsOnly 0x11
31uint8Data sourceOnly 0x30
32uint8Extension byteOnly 0x08
33uint8Data lengthOnly 2
34uint16DataPower supply voltage (mV)
Sensor data 4
36uint8Info bitsOnly 0x11
37uint8Data sourceOnly 0x30
38uint8Extension byteOnly 0x01
39uint8Data lengthOnly 2
40uint16DataADC1 voltage (mV)
Sensor data 5
42uint8Info bitsOnly 0x00
43uint8Data sourceOnly 0x00
44uint8Extension byteOnly 0x00
45uint8Data lengthOnly 1
46uint8DataMagnetic data
Sensor data 6
47uint8Info bitsOnly 0x05
48uint8Data sourceOnly 0x01
49uint8Extension byteOnly 0x00
50uint8Data lengthOnly 2
51int16DataTemperature data
Sensor data 7
53uint8Info bitsOnly 0x01
54uint8Data sourceOnly 0x02
55uint8Extension byteOnly 0x00
56uint8Data lengthOnly 2
57uint16DataHumidity data
End of sensor data
59uint8Checksum 1CRC8 up to previous byte
uint8Checksum 2LRC8 up to Checksum 1
charFooterCR (0x0D/\r)
charFooterLF (0x0A/\n)

Data Identification Conditions

Parent and Repeater App can receive data from various types of child devices.

To confirm that the output data is from the Aria App (TWELITE ARIA Mode), refer to the following:

#DataItemCondition
0uint32Serial ID of repeaterMSB is 1
7uint32Serial ID of senderMSB is 1
12uint8Sensor type0x80
13uint8PAL board version and PAL board ID0x06
--Payload sizeMust be 60 bytes

Parser Implementation Examples

Open/Close Sensor Pal Mode

3.3.2.1.1.1.4.4 - Details of Output from Pal, Cue, and Aria Apps (Parent and Repeater App)

Details of the common output format for Pal, Cue, and Aria apps
Data received from child devices of Pal, Cue, and Aria apps are output according to a common format. This section details that format. For specific output examples of each app, see the app pages.

Overall

Data Format

#DataDescriptionNotes
charHeader: only
0uint32Serial ID of repeater80000000 if no repeater
4uint8LQI0-255
5uint16Sequence number
7uint32Serial ID of sender0x8???????
11uint8Logical device ID of sender
12uint8Sensor typeOnly 0x80
13uint8PAL board version and PAL board IDe.g. 0x81
14uint8Number of sensor data
15[uint8]List of sensor dataByte array of length (N)
15+(N)uint8Checksum 1CRC8 up to previous byte
uint8Checksum 2LRC8 up to Checksum 1
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:80000000A8001C82012B1E01808103113008020D0C1130010203E40000000101EC6E
#DataDescriptionValue
:charHeader:
800000000uint32Serial ID of repeaterNo repeater
A84uint8LQI168/255
001C5uint16Sequence number28
82012B1E7uint32Serial ID of sender0x2012B1E
0111uint8Logical device ID of sender0x01
8012uint8Sensor type-
8113uint8PAL board version and PAL board ID0x81
0314uint8Number of sensor data3
1130...010115[uint8]List of sensor dataByte array of length 17
EC15+17uint8Checksum 10xEC
6Euint8Checksum 20x6E
charFooter'\r'
charFooter'\n'

Sensor Data

Data Format

#DataDescriptionNotes
0uint8Info bitsData type and presence of extension byte
1uint8Data sourceType of sensor value
2uint8Extension byteAdditional info for sensor value
3uint8Data lengthLength of sensor value
4[uint8]DataSensor value

Example Output Data

113008020D0C
#DataDescriptionValue
110uint8Info bitsExtension byte present, uint16
301uint8Data sourceVoltage
082uint8Extension bytePower supply voltage
023uint8Data length2 bytes
0D0C4[uint8]Data3340 mV

Info Bits

Indicates the data type of the sensor value, presence of extension byte, and read error status.

bit76543210
FunctionERR--EXT-TYP:2TYP:1TYP:0

Each function indicates the following:

FunctionDescriptionValueMeaning
ERRRead error presence0Normal
1Error present
EXTExtension byte presence0No extension byte
1Extension byte present
TYPData type000uint8
001uint16
010uint32
011N/A
100int8
101int16
110int32
111[uint8]

Data Source

Indicates the type of sensor value.

ValueDescription
0x00Magnetic
0x01Temperature
0x02Humidity
0x03Illuminance
0x04Acceleration
0x05Event
0x30Voltage
0x34Packet properties

Extension Byte

Indicates additional information such as index for continuous data.

For data sources Magnetic / Temperature / Humidity / Illuminance / Packet Properties

None

For data source Acceleration

Indicates attributes of acceleration sample data.

bit76543210
FunctionSFQ:2SFQ:1SFQ:0SNM:4SNM:3SNM:2SNM:1SNM:0

Each function indicates the following:

FunctionDescriptionValueMeaning
SFQSampling frequency000 (`0x00SNM`)
001 (`0x20SNM`)
010 (`0x40SNM`)
011 (`0x60SNM`)
100 or higherUndefined
SNMSample number0-31Oldest first

For data source Event

Indicates cause of event occurrence.

ValueDescription
0x00Magnetic
0x01Temperature
0x02Humidity
0x03Illuminance
0x04Acceleration
0x31Digital input
0x35Timer

For data source Voltage

Indicates target.

ValueDescription
0x01ADC1
0x02ADC2
0x03ADC3
0x04ADC4
0x08Power supply

Data Length

Indicates the number of bytes of the following data.

Data

Represents the sensor value.

For data source Magnetic

Data type is uint8.

ValueDescription
0x00No magnet
0x01North pole approached
0x02South pole approached
0x80No magnet (periodic send)
0x81North pole nearby (periodic send)
0x82South pole nearby (periodic send)

For data source Temperature

Data type is int16.

Represents temperature in Celsius multiplied by 100.

For data source Humidity

Data type is uint16.

Represents relative humidity multiplied by 100.

For data source Illuminance

Data type is uint32.

Represents illuminance in lux.

For data source Acceleration

Three int16 values follow.

X, Y, Z axis values (mG) total 6 bytes.

byte012345
ContentX:15-8X:7-0Y:15-8Y:7-0Z:15-8Z:7-0

For data source Event

Four uint8 values follow.

The first data indicates the event content, the rest are unused.

byte0123
ContentUsedUnusedUnusedUnused
Extension byte for Magnetic
First valueDescription
0x00No magnet
0x01North pole nearby
0x02South pole nearby
Extension byte for Acceleration
First valueDescription
0x00Stationary (Move mode)
0x01Dice: 1
0x02Dice: 2
0x03Dice: 3
0x04Dice: 4
0x05Dice: 5
0x06Dice: 6
0x08Shake
0x10Move
Extension byte for Timer
First valueDescription
0x01Woken by timer

For data source Voltage

Data type is uint16.

Represents voltage in mV.

For data source Packet Properties

Three uint8 values follow.

byte012
DataPacket IDRoot cause of wake-upCondition of wake-up

Each data indicates the following:

DataValueDescription
Packet ID0No event, only ADC1 and power voltage
1-127No event, other data present
128Event present, only ADC1 and power voltage
129-255Event present, other data present
Root cause of wake-up0x00Magnetic
0x01Temperature
0x02Humidity
0x03Illuminance
0x04Acceleration
0x31Digital input
0x35Timer
Condition of wake-up0x00Event occurred
0x01Value changed
0x02Value exceeded threshold
0x03Value fell below threshold
0x04Value met range

3.3.2.1.1.1.5 - Output from act (Parent and Repeater App)

Output format when data is received from act

Data Received from act

Data Format

#DataContentRemarks
charHeader: only
0uint8Source Logical Device ID
1uint8Command Typeonly 0xAA
2uint8Response ID0x00-0x7F
3uint32Source Serial ID
7uint32Destination Serial ID00000000 when specifying logical device ID
11uint8LQI0-255
12uint16Number of data bytes
14[uint8]Arbitrary dataLength (N) bytes
uint8ChecksumLRC8
charFooterCR (0x0D/\r)
charFooterLF (0x0A/\n)

Example of Output Data

:FEAA008201015A00000000B7000F424154310F0CEE000B03FF03FF03FF92
#DataContentValue
:charHeader:
FE0uint8Source Logical Device ID0xFE
AA1uint8Command Type0xAA
002uint8Response ID0x00
8201015A3uint32Source Serial ID0x201015A
000000007uint32Destination Serial IDLogical Device ID specified
B711uint8LQI183/255
000F12uint16Number of data bytes15 bytes
424154310F0CEE000B03FF03FF03FF14[uint8]Arbitrary dataAs is
92uint8Checksum0x92
charFooter\r
charFooter\n

3.3.2.1.1.1.6 - Output from Wireless Tag App (Parent and Repeater App)

Output format when data is received from the Wireless Tag App
This section describes the output when connecting main sensors to the child device.

Analog Sensor

Data Format

#DataDescriptionNotes
charHeader: only
0uint32Relay device serial ID80000000 if no relay
4uint8LQI0-255
5uint16Sequence number
7uint32Source serial ID
11uint8Source logical device ID
12uint8Sensor type
13uint8Power supply voltage (mV)See Power Supply Voltage Calculation
14uint16ADC1 voltage
16uint16ADC2 voltage
18uint32Unused
22uint8Checksum

Example Output Data

:80000000B700628201015A0010DF08FD09A300000000E9
#DataDescriptionValue
:charHeader:
800000000uint32Relay device serial IDNo relay
B74uint8LQI183/255
00625uint16Sequence number98
8201015A7uint32Source serial ID0x201015A
0011uint8Source logical device ID0x00
1012uint8Sensor typeAnalog sensor
DF13uint8Power supply voltage (mV)3330mV
08FD14uint16ADC1 voltage2301mV
09A316uint16ADC2 voltage2467mV
0000000018uint32Unused
E922uint8Checksum0xE9
charFooter\r
charFooter\n

Accelerometer (ADXL34x / TWELITE 2525A)

Data Format

#DataDescriptionNotes
charHeader: only
0uint32Relay device serial ID80000000 if no relay
4uint8LQI0-255
5uint16Sequence number
7uint32Source serial ID
11uint8Source logical device ID
12uint8Sensor type
13uint8Power supply voltage (mV)See Power Supply Voltage Calculation
14uint16ADC1 voltage
16uint16ADC2 voltage
18uint8Sensor mode number
19int16X-axis accelerationUnit: mG*10
21int16Y-axis accelerationUnit: mG*10
23int16Z-axis accelerationUnit: mG*10
25uint8Checksum

Example Output Data

:8000000063001781013C850035DF057702F2000000FF96FFF0BB
#DataDescriptionValue
:charHeader:
800000000uint32Relay device serial IDNo relay
634uint8LQI99/255
00175uint16Sequence number23
81013C857uint32Source serial ID0x1013C85
0011uint8Source logical device ID0x00
3512uint8Sensor typeAccelerometer (ADXL34x)
DF13uint8Power supply voltage (mV)3330mV
057714uint16ADC1 voltage1399mV
02F216uint16ADC2 voltage754mV
0018uint8Sensor mode numberNormal
000019int16X-axis acceleration0mG
FF9621int16Y-axis acceleration-1060mG
FFF023int16Z-axis acceleration-160mG
BB25uint8Checksum0xBB
charFooter\r
charFooter\n

Switch

Data Format

#DataDescriptionNotes
charHeader: only
0uint32Relay device serial ID80000000 if no relay
4uint8LQI0-255
5uint16Sequence number
7uint32Source serial ID
11uint8Source logical device ID
12uint8Sensor type
13uint8Power supply voltage (mV)See Power Supply Voltage Calculation
14uint16ADC1 voltage
16uint16ADC2 voltage
18uint8Sensor mode number0 is Hi→Lo, 1 is Lo→Hi
19uint8DI1 state1 is Lo
20uint8Unused
21uint8Checksum

Example Output Data

:800000009C00118201015A00FEDF000709A300010064
#DataDescriptionValue
:charHeader
800000000uint32Relay device serial IDNo relay
9C4uint8LQI156/255
00625uint16Sequence number98
8201015A7uint32Source serial ID0x201015A
0011uint8Source logical device ID0x00
FE12uint8Sensor typeSwitch
DF13uint8Power supply voltage (mV)3330mV
000714uint16ADC1 voltage7mV
09A316uint16ADC2 voltage2467mV
0018uint8Sensor mode numberHi→Lo
0119uint8DI1 stateLo
0020uint8Unused
6421uint8Checksum0x64
charFooter\r
charFooter\n

Power Supply Voltage Calculation

The power supply voltage \(V_{cc}\) can be expressed using the received value \(e_{cc}\) as follows:

$$\begin{cases} V_{cc} = 1950+5e_{cc} & (e_{cc} <= 170) \\ V_{cc} = 2800+10(e_{cc}-170) & (e_{cc} > 170) \end{cases}$$

Unit is mV

3.3.2.1.1.2 - Transmit Command of Parent and Repeater App

Input for sending data to the child

Commands entered from the serial port in the specified format are sent to the child.

3.3.2.1.1.2.1 - Input to the Extremely Simple! Standard App (Parent and Repeater App)

Commands to control the output of the Extremely Simple! Standard App
You can control the output of the Extremely Simple! Standard App.

Digital and Analog Input/Output

0x80: Change Output of the Target Device

Controls the output signals of the target device.

Data Format

#DataDescriptionNotes
charHeader: only
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command Number0x80 only
2uint8Format Version0x01 only
3uint8Digital SignalCorresponds to DOx from LSB, 0 means High
4uint8Digital Signal MaskCorresponds to DOx from LSB, 1 means Enabled
5uint16PWM1 Signal0-1024, 0xFFFF means Disabled
7uint16PWM2 Signal0-1024, 0xFFFF means Disabled
9uint16PWM3 Signal0-1024, 0xFFFF means Disabled
11uint16PWM4 Signal0-1024, 0xFFFF means Disabled
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

3.3.2.1.1.2.2 - Input to the Serial Communication App (Parent and Repeater App)

Commands to send data to the serial communication app
You can send data to the child device of the serial communication app (format mode, simple format).

UART

Format Mode: ASCII Simple Format

App_Wings v1.3 and later support the simple format of format mode (A).

Data Format

#DataDescriptionNotes
charHeaderOnly :
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command NumberAny value less than 0x80
2[uint8]Arbitrary DataByte sequence of length \(N\) (recommended \(N\leqq80\))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

3.3.2.1.1.2.3 - Input to the PAL App (Notification PAL) (Parent and Repeater App)

Commands to control the LED of the Notification PAL
You can control the LED of the Notification PAL.
:0190010004000169[CR][LF]
 ^1^2^3^^^^^^^4^5
No.BytesMeaningExample DataNotes
11Destination Logical Device ID01

Specify the logical device ID of the destination TWELITE PAL.
Valid values range from 0x01 to 0x64.

21Command Type90
31Number of Command Parameters01Specify the number of command parameters. For example, set to 1 if specifying one command parameter, or 2 if specifying two.
4Number of Commands x 4Command Parameters00040001

Specify parameters such as events and LED colors.
See the command parameters section for details.

51Checksum69

Calculate the sum of bytes 1 to 4 within 8 bits and take the two’s complement. In other words, the sum of all data bytes plus the checksum byte equals zero within 8 bits.
The checksum byte is represented by two ASCII characters.
For example, in 00A01301FF123456, the sum 0x00 + 0xA0 + … + 0x56 = 0x4F, and its two’s complement is 0xB1 (i.e., 0x4F + 0xB1 = 0).
The checksum can be omitted by using ‘X’ as the checksum.

62Footer[CR][LF]Specify [CR] (0x0D) [LF] (0x0A). However, if the checksum is omitted with ‘X’, the footer can also be omitted.

Command Parameters

Combine 4-byte command parameters to specify commands.

0x00: Send Event ID

The TWELITE PAL has predefined behaviors for each received event ID. This parameter sends an event ID to the destination TWELITE PAL to trigger the configured behavior.

No.BytesContentNotes
11Command Parameter ID0x00
21Destination PAL ID

Specify the destination PAL ID.
0x04: Notification PAL
0xFF: All TWELITE PALs

31UnusedFixed at 0x00
41Event IDSpecify event ID from 0 to 16

0x01: Send LED Color, Blinking Pattern, and Brightness

Send the LED color, blinking pattern, and brightness to the destination Notification PAL.

No.BytesContentNotes
11Command Parameter ID0x01
21Color

0: Red
1: Green
2: Blue
3: Yellow
4: Purple
5: Cyan
6: White
7: Warm White

31Blinking Pattern

0: Always on
1-3: Blinking patterns (higher value means faster blinking)

41Brightness

0: Off
0x01–0x0F: Brightness (higher value means brighter)

0x02: Send Lighting Duration

Send the lighting duration of the Notification PAL’s LED.

No.BytesContentNotes
11Command Parameter ID0x02
21UnusedFixed at 0xFF
31UnusedFixed at 0x00
41Lighting DurationSpecified in seconds (0 means always on)

0x03: Specify LED Color in RGBW

Send the LED lighting color of the Notification PAL in RGBW.

No.BytesContentNotes
11Command Parameter ID0x03
21UnusedFixed at 0xFF
32LED Lighting Color

Specify 4 bits each for RGBW in order from LSB.

Higher value means brighter.

0x04: Specify Blinking Parameters

Send the blinking cycle and duty of the Notification PAL’s LED.

No.BytesContentNotes
11Command Parameter ID0x04
21UnusedFixed at 0xFF
31Blinking Time Ratio

Specify from 0x00 to 0xFF.

Higher value means longer ON time per cycle.

0x7F means ON for half of the cycle.

41Blinking Cycle

Specify from 0x00 to 0xFF.

Each increment increases the blinking cycle by about 0.04s.

0x17 corresponds to a 1-second cycle.

Command Examples

Example 1: Send Event

Command example to send event 1 to the NOTICE PAL with logical device ID 1.

:0190010004000169
 ^1^2^3^4^5^6^7^8
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands01One command
41Command ID00Command 00
51Destination PAL ID04Sent to Notification PAL
61Unused00
71Event ID01Event 10x00 to 0x10
81Checksum69

Example 2: Send LED Lighting Color to Notification PAL

Command to send LED lighting color with brightness 8 and slow blinking white to the NOTICE PAL with logical device ID 1.

:019001010601085E
 ^1^2^3^4^5^6^7^8
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands01One command
41Command Parameter ID01Command parameter ID 0x01
51Color06White
61Blinking Pattern01Blinking
71Brightness08Brightness 8Range 0x00 to 0x0F
81Checksum5E

Example 3: Send LED Lighting Color and Lighting Duration to Notification PAL

Command to light up purple and turn off after 1 second for the NOTICE PAL with logical device ID 1.

:0190020104000802FF00015E
 ^1^2^3^4^5^6^7^8^9^a^b^c
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands02Two commands
41Command Parameter ID01Command parameter ID 0x01
51Color04Purple
61Blinking Pattern00Always on
71Brightness08Brightness 8Range 0x00 to 0x0F
81Command Parameter ID02Command parameter ID 0x02
91UnusedFF
a1Unused00
b1Lighting Duration01Turns off after 1 second
c1Checksum5E

Example 4: Send Detailed Lighting Color to Notification PAL

Command to light up purple for the NOTICE PAL with logical device ID 1.

:01900103FF0F0459
 ^1^2^3^4^5^^^6^7
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands01One command
41Command Parameter ID03Command parameter ID 0x03
51UnusedFF
62LED Lighting Color0F04Lights blue at 15 and red at 4 brightness

Specify 4 bits each for RGBW in order from LSB (0–15).

Higher value means brighter.

71Checksum59

Example 5: Send LED Lighting Color and Lighting Duration to Notification PAL

Command to light up purple and turn off after 1 second for the NOTICE PAL with logical device ID 1.

:0190020104000802FF00015E
 ^1^2^3^4^5^6^7^8^9^a^b^c
No.BytesMeaningExample DataExplanation of Example DataNotes
11Destination Logical Device ID01Logical device ID of the destination is 0x01
21Command Type900x90 commandFixed at 90
31Number of Commands02Two commands
41Command Parameter ID01Command parameter ID 0x01
51Color04Purple
61Blinking Pattern00Always on
71Brightness08Brightness 8Range 0x00 to 0x0F
81Command Parameter ID02Command parameter ID 0x02
91UnusedFF
a1Unused00
b1Lighting Duration01Turns off after 1 second
c1Checksum5E

3.3.2.1.2 - Repeater Mode of Parent and Repeater App

Retransmit data received from Child or Parent
In repeater mode, retransmitting received packets can extend the communication range between Child and Parent.

Example Settings

To use as a repeater, set the Operating Mode in interactive mode to 1 or higher.

Relay Methods

TWELITE NET provides two major relay methods for wireless packet delivery, as shown in the table below, which differ depending on the application. This app can identify and relay packets of the applications shown in the table below.

Relay MethodSupported Applications
Simple NetExtremely Simple! Standard App, Remote Control App, Serial Communication App, ACT
Relay NetWireless Tag App, PAL App, CUE App

Relay Using Simple Net

When relaying applications using Simple Net, setting the operating mode to 1 or higher allows up to three relays.

For example, in case 1., if there are up to 3 Repeaters between the Parent and Child, data will reach the Parent, but in case 2., if there are 4 or more Repeaters, data will not reach the Parent.

1. Child  --->  Repeater  --->  Repeater  --->  Repeater  --->  Parent
   → Parent can receive Child's data relayed 3 times.
2. Child  --->  Repeater  --->  Repeater  --->  Repeater  --->  Repeater  -x->  Parent
   → Stops relaying at the 4th relay.

Relaying with Simple Net basically uses broadcast communication and relays all received packets. The advantage is that communication to form and maintain the relay network is not necessary, but the disadvantage is that communication volume can explode as the number of Repeaters increases.

For details, please refer to here.

Relay Using Relay Net

For relaying data of applications using Relay Net with one stage of relay, set the operating mode value to 1.

When performing multiple relays, increase the operating mode setting value as the distance from the Parent increases. (It is acceptable if the setting values are in ascending order even if some values are skipped.)

The maximum number of relays for this method is up to 63 times.

Example 1: One relay\
Child ---> Repeater (Operating Mode: 1) ---> Parent

Example 2: Two relays\
Child  --->  Repeater (Operating Mode: 2) --->  Repeater (Operating Mode: **1**)  --->  Parent

Example 3: Three relays\
Child ---> Repeater (Operating Mode: 6) ---> Repeater (Operating Mode: 3) ---> Repeater (Operating Mode: 1) ---> Parent

Relay Net is a tree-type network designed to efficiently deliver upstream packets. Repeaters search for an upper layer (Parent or Repeater with a smaller operating mode setting) and relay to one discovered upper layer device.

Therefore, even if the number of Repeaters increases, the communication volume is less likely to become large compared to Simple Net, but communication occurs to discover and maintain the connection destination.

For details, please see here.

When Performing Static Routing (Directly Specifying Relay Destination)

When relaying with Relay Net, considering the layout as shown in the figure below, Repeater 2 automatically selects either the Parent or Repeater 1 as the connection destination.

Basically, fewer relays tend to have a higher delivery rate to the Parent, but if the Parent is selected as the connection destination for Repeater 2, communication quality may deteriorate due to obstacles between Parent and Repeater 2, resulting in a lower delivery rate to the Parent than when relaying through Repeater 1.

Therefore, this app has a function (static routing function) to specify the connection destination of Repeaters by TWELITE serial number.

Relay Net

When performing static routing, set the route from Repeater 2 to Repeater 1 statically, or set all routes statically.

Setting all routes increases the amount of configuration and does not support redundancy for situations such as Repeater failure or changes in radio conditions, but it eliminates the time to determine the upper communication destination and allows prompt relay operation.

To perform static routing, set the connection destination as shown in the table below: Repeater 1’s connection destination is the Parent’s SID, and Repeater 2’s connection destination is Repeater 1’s SID.

Example: Two-stage relay (Parent ← Repeater 1 ← Repeater 2 ← Child)

TWELITE SID ExampleConnection Destination (A: Access Point Address) Setting ExampleOperating Mode (l:Mode) Setting Example
Parent810F155E-0
Repeater 1810E18E8810F155E (Parent’s SID)※1
Repeater 2810F17FF810E18E8 (Repeater 1’s SID)2

※ If you only want to deal with effects caused by walls as shown in the figure, this setting is unnecessary.

3.3.2.2 - Interactive Mode (Parent and Repeater App)

Detailed setting changes using Interactive Mode
You can perform detailed app settings in Interactive Mode.

This section explains features specific to the Parent and Repeater App (App_Wings). For common features, please refer to the TWELITE APPS Manual Top Page.

Display Example

The screen shown below will be displayed.

[CONFIG MENU/App_Wings:0/v1-02-1/SID=820163B2]
a: (0x67720102) Application ID [HEX:32bit]
c: (18        ) Channels Set
x: (      0x03) RF Power/Retry [HEX:8bit]
b: (38400,8N1 ) UART Baud [9600-230400]
o: (0x00000000) Option Bits [HEX:32bit]
k: (0xA5A5A5A5) Encryption Key [HEX:32bit]
m: (         0) Mode (Parent or Router)
A: (0x00000000) Access point address [HEX:32bit]

 [ESC]:Back [!]:Reset System [M]:Extr Menu

Commands

ItemDefaultNotes
aApplication ID0x6772010232bit
cFrequency Channel1811-26
xRetry Count and Transmission Power03
Retry Count01-9 times, 0 means default 0 times
Transmission Power30-3
bUART Alternative Settings38400,8N1Enabled by option bit
oOption Bits0x00000000Other detailed settings
kEncryption Key0xA5A5A5A532bit
mOperating Mode0Parent 0, Repeater 1, Repeater Network 1-63
ARepeater Destination0x00000000Repeater mode only

Details of each command are shown below.

a: Application ID

All devices communicating must have the same value. It logically separates networks.

c: Frequency Channel

All devices communicating must have the same value. It physically separates networks.

x: Transmission Power and Retry Count

Specify the radio transmission power and the number of additional packet retransmissions.

b: UART Alternative Settings

Specify UART options when the option bit Enable UART Alternative Settings is set.

The value specifies baud rate and parity settings separated by a comma.

The baud rate can be selected from 9600/19200/38400/57600/115200/230400. Specifying other values may cause errors.

Parity can be set as N: None, O: Odd, E: Even. Hardware flow control cannot be set. Settings like 8N1, 7E2 can be specified, but settings other than 8N1 are unverified. Please confirm operation in advance.

o: Option Bits

Specify a 32bit numeric value. Settings linked to each bit can be enabled.

Bit MaskSettingDefault
0x00000200Enable UART Alternative Settings0️⃣
0x00000400Stop Periodic Packet Transmission Output0️⃣
0x00001000Enable Encrypted Communication0️⃣
0x00002000Enable Plain Reception During Encrypted Communication0️⃣

k: Encryption Key

Specify a 32bit hexadecimal encryption key when the option bit Enable Encrypted Communication is set.

m: Operating Mode

Set 0 for Parent mode, 1 for Repeater mode.

When performing multi-hop repeater in Repeater mode, setting 2-63 specifies the repeater layer.

A: Repeater Destination

Specify the serial ID (0x8???????) of the upper-level device connected when performing static routing in Repeater mode. When set to 0x00000000, automatic search is performed.

Details of Option Bits

Explanation of settings linked to each bit of the option bit value.

00000200: Enable UART Alternative Settings

Enables b: UART Alternative Settings.

00000400: Stop Periodic Packet Transmission Output

Stops the 1-second periodic transmission of the Extremely Simple! Standard App and Remote Control App and stops UART output during continuous mode.

00001000: Enable Encrypted Communication

Enables encrypted communication. The other party must also enable encrypted communication.

00002000: Enable Plain Reception During Encrypted Communication

When encrypted communication is enabled, allows reception of packets that are not encrypted.

3.4 - Remote Control App Manual

Transmission of digital signals
Firmware specialized in digital signal transmission. Offers rich features compared to the Extremely Simple! Standard App.

3.4.1 - Remote Control App Manual

Latest Edition

Installation

To install the Remote Control App (App_IO), install TWELITE STAGE SDK and rewrite the app using the TWELITE STAGE App. Select [App Rewrite] → [TWELITE APPS Build & Rewrite] → [App_IO].

Features

You can wirelessly transmit up to 12 switch or contact inputs.

Differences from Extremely Simple! Standard App (App_Twelite) are:

  • Increased number of ports, up to 12 ports available
  • Four types of input/output assignment (12:0, 8:4, 6:6, 0:12)
  • Frequency channel selectable externally from four types
  • Communication encryption available
  • Communication only possible with specified peers (automatic application ID setting)

3.4.1.1 - Pin Assignment of Remote Control App

Functions of pins used by the Remote Control App

TWELITE / TWELITE DIP

The functions of pins used by the Remote Control App are represented using the names from the diagram of Extremely Simple! Standard App Pins.

Super Simple! Standard App Pin Assignment Table

Super Simple! Standard App Pin Assignment Table

DIP #IOStandardRemote ControlFunction
1GNDGNDGNDPower Input
2DIO14SCLI9/O9Digital Input/Output
3DIO7RXRXSerial Input/Output
4DIO5PWMI11/O11Digital Input/Output
5DIO18DO1I5/O1Digital Input/Output
6DO0PWMLEDStatus LED Output
7DO1M3
8DIO19DO2I6/O2Digital Input/Output
9DIO4DO3I7/O3Digital Input/Output
10DIO6TXTXSerial Input/Output
11DIO8PWMI12/O12Digital Input/Output
12DIO9DO4I8/O4Digital Input/Output
13DIO10M1M1Mode Setting Input
14GNDGNDGNDPower Input
28VCCVCCVCCPower Input
27DIO3M3M3Mode Setting Input
26DIO2M2M2Mode Setting Input
25DIO1AI4C2Channel Setting Input
24ADC2AI3
23DIO0AI2C1Channel Setting Input
22ADC1AI1
21RESETNRSTRSTReset Input
22DIO17BPSBPSAlternative Baud Rate Setting Input
19DIO15SDAI10/O10Digital Input/Output
18DIO16DI4I4/O8Digital Input/Output
17DIO11DI3I3/O7Digital Input/Output
16DIO13DI2I2/O6Digital Input/Output
15DIO12DI1I1/O5Digital Input/Output

Power Input

Connect a 3.3V (2.0-3.6V) power supply to VCC/GND.

Digital Input/Output

Child: 12 inputs 0 outputs / Parent: 12 outputs 0 inputs

Default input/output assignments.

NameChildParentStandardDIP #
I1/O5I1O5DI115
I2/O6I2O6DI216
I3/O7I3O7DI317
I4/O8I4O8DI418
I5/O1I5O1DO15
I6/O2I6O2DO28
I7/O3I7O3DO39
I8/O4I8O4DO412
I9/O9I9O9SCL2
I10/O10I10O10SDA19
I11/O11I11O11PWM14
I12/O12I12O12PWM411

Child: 8 inputs 4 outputs / Parent: 8 outputs 4 inputs

Input/output assignments when the option bit: 0x00001000 setting is enabled.

NameChildParentStandardDIP #
I1/O5I1I1DI115
I2/O6I2I2DI216
I3/O7I3I3DI317
I4/O8I4I4DI418
I5/O1O1O1DO15
I6/O2O2O2DO28
I7/O3O3O3DO39
I8/O4O4O4DO412
I9/O9I5O5SCL2
I10/O10I6O6SDA19
I11/O11I7O7PWM14
I12/O12I8O8PWM411

Child: 6 inputs 6 outputs / Parent: 6 outputs 6 inputs

Input/output assignments when the option bit: 0x00002000 setting is enabled.

NameChildParentStandardDIP #
I1/O5I1I1DI115
I2/O6I2I2DI216
I3/O7I3I3DI317
I4/O8I4I4DI418
I5/O1O1O1DO15
I6/O2O2O2DO28
I7/O3O3O3DO39
I8/O4O4O4DO412
I9/O9O5I5SCL2
I10/O10O6I6SDA19
I11/O11I5O5PWM14
I12/O12I6O6PWM411

Child: 0 inputs 12 outputs / Parent: 0 outputs 12 inputs

Input/output assignments when the option bit: 0x00003000 setting is enabled.

NameChildParentStandardDIP #
I1/O5O5I1DI115
I2/O6O6I2DI216
I3/O7O7I3DI317
I4/O8O8I4DI418
I5/O1O1I5DO15
I6/O2O2I6DO28
I7/O3O3I7DO39
I8/O4O4I8DO412
I9/O9O9I9SCL2
I10/O10O10I10SDA19
I11/O11O11I11PWM14
I12/O12O12I12PWM411

Serial Input/Output

TX/RX are used for transmission and reception of the remote control (UART).

Status LED Output

Used when outputting status during automatic application ID setting.

Make the LED light up when the output is Low (sink type).

Setting Input

Mode Setting Input

By leaving the Mx pins unconnected or connecting them to GND, you can switch between operating modes such as parent, child, and repeater.

Alternative Baud Rate Setting Input

By leaving the BPS pin unconnected or connecting it to GND, you can change the UART baud rate (communication speed) to a value other than 115200bps.

Channel Setting Input

Temporarily overrides the frequency channel.

C2C1Frequency Channel
UnconnectedUnconnectedDefault (initial value is 16)
UnconnectedGND12
GNDUnconnected21
GNDGND25

Reset Input

By connecting a push button between RST and GND, you can implement a reset button. RST is internally pulled up.

3.4.1.2 - Remote Control App Operating Modes

Description of each operating mode
The Remote Control App (App_IO) has six operating modes.

List of Operating Modes

Each mode is set by connecting the Mx pins to either not connected (OPEN) or to GND.

M3M2M1ModeFunctionPowerSavingOperationInitialLID
OOOChild: ContinuousSends input states to the parent device and always waits for received data to reflect it on output120
OOGParent: ContinuousSends input states to child devices and always waits for received data to reflect it on output0
OGORepeater: ContinuousAlways waits for received data and relays it122
OGGChild: Continuous 0.03sSends input states to the parent device frequently and always waits for received data to reflect it on output123
GOOChild: Intermittent 1sSends input states to the parent device every second, disables reception, and always enters power saving mode124
GGO(Pairing Mode)Details
GGGChild: Intermittent 10sSends input states to the parent device every 10 seconds, disables reception, and always enters power saving mode127

O: Not connected (OPEN), G: Connected to GND

Initial mode is Child: Continuous mode.

The initial Logical Device ID (LID) used to identify the device differs depending on the mode.

Parent Device

Continuous Mode

Parent: Continuous Mode

When a change in signal input is detected, or every second, data is sent to all child devices.

It also always waits for data sent from child devices, so it responds quickly but continuously consumes power.

  • Reception: Always waiting
  • Transmission: On input change / every 1 second

Child Device

Continuous Mode

Child: Continuous Mode

When a change in signal input is detected, or every second, data is sent to all parent devices.

It also always waits for data sent from parent devices, so it responds quickly but continuously consumes power.

Image of communication with parent device

Image of communication with parent device

  • Reception: Always waiting
  • Transmission: On input change / every 1 second

Child: Continuous 0.03s Mode

This mode shortens the periodic transmission interval of Child: Continuous Mode from 1 second to 0.03 seconds.

Although it always waits for data sent from the parent device, it occupies the bandwidth of communication from child to parent, causing slower response to parent input. It continuously consumes power.

Image of communication with parent device

Image of communication with parent device

  • Reception: Always waiting
  • Transmission: On input change / every 0.03 seconds

Intermittent Mode

Child: Intermittent 1s Mode

When a change in signal input is detected, or every second, the power saving mode is disabled and data is sent to all parent devices.

Reception is disabled, so it cannot be controlled by the parent device. This mode has excellent power saving performance.

Image of communication with parent device

Image of communication with parent device

  • Reception: Disabled
  • Transmission: On input change / every 1 second

Child: Intermittent 10s Mode

When a change in signal input is detected, or every 10 seconds, the power saving mode is disabled and data is sent to all parent devices.

Reception is disabled, so it cannot be controlled by the parent device. This mode has excellent power saving performance.

Image of communication with parent device

Image of communication with parent device

  • Reception: Disabled
  • Transmission: On input change / every 10 seconds

Repeater Device

Continuous Mode

Repeater: Continuous Mode

The repeater transmits received packets.

You can install up to three repeaters between parent and child devices, but increasing repeaters increases the number of packets, which can cause interference.

Image of relay

Image of relay

  • Reception: Always waiting
  • Transmission: On reception

3.4.1.3 - Remote Control App Alternative Baud Rate Setting

Changing the baud rate used for UART communication
The Remote Control App (App_IO) uses 115200 bps as the default baud rate for UART communication, but this can be changed.

Enabling Alternative Baud Rate Setting

You can enable the alternative baud rate setting by connecting the BPS pin to GND.

BPSDescriptionBaud RateRemarks
ODefault115200bps
GOverride38400bpsChangeable via Interactive Mode

O: not connected (OPEN), G: connected to GND

3.4.1.4 - Remote Control App UART Function

Data format used for UART function.
Explanation of data format used in the UART function of Remote Control App (App_IO).

Digital Input and Output

0x81: Status Notification from the Remote Device

Outputs the state of the received input signal.

Data Format

#DataDescriptionRemarks
charHeader: only
0uint8Source Logical Device ID
1uint8Command Number0x81 only
2uint8Packet Identifier0x0F only
3uint8Protocol Version0x01 only
4uint8LQI0-255
5uint32Source Serial ID0x8???????
9uint8Destination Logical Device ID
10uint16Timestamp64 counts per second, MSB is internal flag
12uint8Relay Count
13uint16Digital SignalCorresponds to Ix from LSB, 0 is High
15uint16Digital Signal MaskCorresponds to Ix from LSB, 1 means valid
17uint16Digital Signal FlagCorresponds to Ix from LSB, 1 means interrupt
19uint8UnusedFor internal management
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Output Data

:01810F01DB8630000200645F000040004F00400049

0x80: Remote Device Output Change

Controls the output signals of the remote device.

Data Format

#DataDescriptionRemarks
charHeader: only
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command Number0x80 only
2uint8Format Version0x01 only
3uint16Digital SignalCorresponds to Ox from LSB, 0 is High
5uint16Digital Signal MaskCorresponds to Ox from LSB, 1 is valid
7uint16Unused0
9uint16Unused0
11uint16Unused0
13uint16Unused0
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

UART Input and Output

3.4.1.5 - Custom Default Feature of Remote Control App

Creating firmware with changed default settings
With the custom default feature, you can change the default parameters included in the firmware.

For example, if you create firmware that changes the baud rate from 115200bps to 9600bps, you can use it at 9600bps from the start.

Configuration Procedure

1. Apply the Settings

Change the settings in Interactive Mode, press S to save.

2. Download the Settings

Prepare software capable of downloading data using the xmodem protocol.

While still in Interactive Mode (before selecting items), request xmodem download.

If the download succeeds, it generates a 128-byte file (may be smaller depending on the xmodem implementation).

3. Creating Custom Binary

Concatenate the downloaded file to the end of the firmware binary file to create a custom binary.

Use command line tools or general file concatenation tools for concatenation.

Example

An example when the downloaded xmodem file is conf.bin, the original binary file is App_IO_BLUE_L1305_V1-3-X.bin, and the custom binary to be created is App_IO_custom_V1-3-X.bin.

【Windows】

copy App_IO_BLUE_L1305_V1-3-X.bin App_IO_custom_V1-3-X.bin
type conf.bin >> App_IO_custom_V1-3-X.bin

【macOS / Linux】


cat App_IO_BLUE_L1305_V1-3-X.bin conf.bin > App_IO_custom_V1-3-X.bin

4. Writing Custom Binary

Write the concatenated custom binary to TWELITE.

3.4.1.6 - Pairing Function of Remote Control App

Grouping parent and child devices by automatic application ID setting
The Remote Control App (App_IO) has a function to create groups of parent and child devices without using Interactive Mode.

Configuration Method

Create a group by generating an application ID based on the parent’s serial ID and feeding it to the child devices. Connect an LED to the LED pin to check if the configuration is successful.

Connection

Connection

  1. Connect an LED and a current limiting resistor (680Ω) to the LED pins of the parent and child devices (with correct polarity).
  2. Leave M1 open and connect M2 and M3 to GND.
  3. Power on the parent device and check that the LED blinks.
  4. Within 5 seconds, power on the child device near the parent and confirm that the LED turns off (if it stays lit, the configuration failed).

3.4.1.7 - Interactive Mode (Remote Control App)

Configuration changes via Interactive Mode
You can perform detailed settings of the app via Interactive Mode.

This section explains features specific to the Remote Control App (App_IO). For common features, please refer to the TWELITE APPS Manual Top Page.

Display Example

The screen below will be displayed.

--- CONFIG/APP_IO V1-03-2/SID=0x86300001/LID=0x00 ---
 a: set Application ID (0x67720107)
 i: set Device ID (--)
 c: set Channels (16)
 x: set Tx Power (3)
 t: set mode4 sleep dur (1000ms)
 y: set mode7 sleep dur (0s)
 f: set mode3 fps (16)
 d: set hold mask (000000000000)
 D: set hold dur (1000ms)
 o: set Option Bits (0x00000000)
 b: set UART baud (38400)
 p: set UART parity (N)
 C: set crypt mode (0)
 K: set crypt key []
---
 S: save Configuration
 R: reset to Defaults

Commands

CommandSetting ItemDefaultNotes
aApplication ID0x6772010732bit
iLogical Device ID120Parent 121, Child 1-100, ID-less Child 120, Unset 0
cFrequency Channel1611-26
xRetry Count and Transmission Output3
Retry Count01-9 times, 0 default: 2 times
Transmission Output30-3
tChild Device Intermittent 1-Second Mode Interval1000100-64000 ms
yChild Device Intermittent 10-Second Mode Interval02-10000 s, Disabled 0
fChild Device Continuous 0.03-Second Mode Cycle324/8/16/32 times per second
dHold/Long Press Mode Targets000000000000From right I1-I2, Enabled 1
DHold/Long Press Mode Duration100020-64000 ms
oOption Bits0x00000000Other detailed settings
bUART Alternative Baud Rate38400Enabled by BPS pin
pUART ParityNStop bit fixed to 1
CEncryption0Disabled 0, AES128bit 1
KEncryption Key-Up to 16 characters

Details for each command are as follows.

a: Application ID

All devices communicating should have the same value. This logically separates networks.

i: Logical Device ID

Set this when it is necessary to distinguish multiple child devices.

If distinction is not necessary or not possible, set to 120. If distinction is necessary, child devices should be any value from 1 to 100, and parent device should be 0 or 121.

c: Frequency Channel

All devices communicating should have the same value. This physically separates networks.

x: Transmission Output and Retry Count

Specify the radio transmission output and the number of additional packet transmissions in transparent mode and header-attached transparent mode.

t: Child Device Intermittent 1-Second Mode Interval

Overwrite the intermittent interval of the child device intermittent 1-second mode from 1 second to another value. Unit is milliseconds.

If 0 is set, periodic wake-up by timer is disabled. In this case, the device wakes up on the falling edge of Ix, but not on the rising edge.

y: Child Device Intermittent 10-Second Mode Interval

Overwrite the intermittent interval of the child device intermittent 10-second mode from 10 seconds to another value. Unit is seconds.

If 0 is set, periodic wake-up by timer is disabled. In this case, the device wakes up on the falling edge of Ix, but not on the rising edge.

f: Child Device Continuous 0.03-Second Mode Cycle

Overwrite the number of transmission requests per second from 32 times to 4/8/16 times. Retry count is not included.

d: Hold/Long Press Mode Targets

By default, select ports targeted by hold mode, and when Option Bit 0x00000100 is enabled, select ports targeted by remote control long press mode.

Specify the bitmask of Ix or Ox ports to target. The value consists of up to 12 characters of 0 or 1. From LSB, the order is I1 I2I12.

For example, specifying 000000001010 applies hold mode to I2 and I4. If any pin is targeted, ports not targeted output a 50ms pulse.

Hold Mode

In hold mode, targeted ports behave as follows:

Input (Transmission) side: Ix
  • After all inputs return from Lo to Hi, continuous transmission occurs for the configured duration (to release hold).
Output (Reception) side: Ox
  • For received inputs that are Lo, output holds Lo for the configured duration.
  • If during hold of any output, another Lo signal is received, the hold duration is extended.

Remote Control Long Press Mode

In remote control long press mode, targeted ports behave as follows:

Input (Transmission) side: Ix
  • Continuous transmission while any input is Lo.
  • After all inputs return from Lo to Hi, continuous transmission occurs for the configured duration.
Output (Reception) side: Ox
  • After packets with any input Lo are interrupted, outputs return Hi after the configured duration.

D: Hold/Long Press Mode Duration

By default, specify hold mode duration; when Option Bit 0x00000100 is enabled, specify hold duration or transmission interval for remote control long press mode.

Specify a value between 20 and 64000 ms.

Hold Mode

For hold mode, the configured duration applies as follows:

Input (Transmission) side: Ix

In continuous mode, the duration of continuous transmission after all inputs return from Lo to Hi.

In intermittent mode, the transmission interval while any input is Lo.

Output (Reception) side: Ox

The duration to maintain output.

Remote Control Long Press Mode

For remote control long press mode, the configured duration applies as follows:

Input (Transmission) side: Ix

The duration of continuous transmission after all inputs return from Lo to Hi.

Output (Reception) side: Ox

The time from interruption of packets with any input Lo until all outputs return to Hi.

o: Option Bits

Specify a 32bit number. Enable settings associated with each bit.

Bit MaskSetting ItemDefaultTransmitReceiveContinuousIntermittent
0x00000001Low Latency Mode0️⃣
0x00000002Low Latency Mode (Sleep Interrupt)0️⃣
0x00000010Enable Transmission with ACK0️⃣
0x00000020Disable Periodic Transmission0️⃣
0x00000100Enable Remote Control Long Press Mode0️⃣
0x00000200Disable C1/C2 Channel Switching0️⃣
0x00000400Invert Ix Input0️⃣
0x00000800Disable Internal Pull-up of Ix0️⃣
0x00001000Child: 8 Input 4 Output / Parent: 8 Output 4 Input0️⃣
0x00002000Child: 6 Input 6 Output / Parent: 6 Output 6 Input0️⃣
0x00003000Child: 0 Input 12 Output / Parent: 0 Output 12 Input0️⃣
0x00010000Force Enable Reception on Child0️⃣
0x00020000Stop UART Output on IO Change0️⃣
0x00040000Enable Watchdog Output on C20️⃣
0x00400000Invert Output on Ox0️⃣

b: UART Alternative Baud Rate

Overwrite the alternative baud rate selected when starting with the BPS pin connected to GND from 38400 bps.

Values can be selected from 9600/19200/38400/57600/115200/230400. Other values may cause errors.

p: UART Parity

Set to N (None), O (Odd), or E (Even). Stop bit is fixed to 1, hardware flow control is not supported.

C: Encryption

Specify whether encryption is enabled.

Set 1 to enable AES128bit encryption.

K: Encryption Key

Input the key used for encryption. Specify a 16-character text (binary sequences cannot be specified).

Details of Option Bits

Explanation of settings associated with each bit of the option bits value.

0x00000001: Low Latency Mode

Monitor input status and perform wireless transmission in low latency mode.

Shortens button monitoring time and minimizes transmission delay. In continuous mode, interrupts are used for input judgment but are more susceptible to chattering. In intermittent mode, reduces time to confirm input status.

Only valid for child devices.

0x00000002: Low Latency Mode (Sleep Interrupt)

When waking from sleep due to an interrupt from Ix going from Hi to Lo in intermittent mode, quickly send port information of the interrupt source.

Especially used in child device intermittent 10-second mode when periodic wake-up is disabled, combined with hold mode to detect button presses.

Only valid for child devices.

0x00000010: Enable Transmission with ACK

Enable ACK communication from child to parent. Transmission ends when parent returns ACK.

Not available for multiple parents or all repeaters, but provides efficient communication in stable environments.

In child device intermittent 10-second mode, the BPS pin is set as output pin, so baud rate override on child side is not possible.

0x00000020: Disable Periodic Transmission

Disable periodic transmission every 1 second in child continuous mode.

0x00000100: Enable Remote Control Long Press Mode

Apply remote control long press mode instead of hold mode.

0x00000200: Disable C1/C2 Channel Switching

Disable channel switching by C1/C2 pins.

0x00000400: Invert Ix Input

Send 1 when input is Hi, and 0 when Lo.

0x00000800: Disable Internal Pull-up of Ix

Disable all internal pull-ups (~50kΩ) on Ix.

0x00001000: Child: 8 Input 4 Output / Parent: 8 Output 4 Input

Change I/O port assignment from “Child: 12 Input 0 Output / Parent: 12 Output 0 Input”. Intermittent mode uses intermittent reception.

0x00002000: Child: 6 Input 6 Output / Parent: 6 Output 6 Input

Change I/O port assignment from “Child: 12 Input 0 Output / Parent: 12 Output 0 Input”. Intermittent mode uses intermittent reception.

0x00003000: Child: 0 Input 12 Output / Parent: 0 Output 12 Input

Change I/O port assignment from “Child: 12 Input 0 Output / Parent: 12 Output 0 Input”. Intermittent mode uses intermittent reception.

0x00010000: Force Enable Reception on Child

In continuous mode, force enable reception regardless of output ports.

Allows UART output of data received from other devices.

0x00020000: Stop UART Output on IO Change

Stop message output on input/output changes.

0x00040000: Enable Watchdog Output on C2

Output watchdog signal from C2 port.

Control IO in application loop and output approx. 32Hz square wave.

Used to connect external reset circuit for automatic recovery and force reset the module in case of hang-up.

0x00400000: Invert Output on Ox

Output Lo when received input port status is 0, and Hi when 1.

3.5 - Serial Communication App Manual

Wireless serial communication
Firmware specialized for wireless transmission of serial communication (UART). Offers more functions compared to Extremely Simple! Standard App.

3.5.1 - Serial Communication App Manual

v1.5.1 GOLD Latest version

Download

To install the Serial Communication App (App_Uart), install the TWELITE STAGE SDK and rewrite using the TWELITE STAGE App.

3.5.1.1 - Pin Assignments of Serial Communication App

Functions of pins used by the Serial Communication App

TWELITE / TWELITE DIP

The functions of pins used by the Serial Communication App are represented using the pin names from the Super Simple! Standard App Pins shown in the figure below.

Super Simple! Standard App Pin Assignment Table

Super Simple! Standard App Pin Assignment Table

Serial CommunicationSuper Simple! StandardFunction
VCC GNDVCC GNDPower Input
TX RXTX RXSerial Input and Output
TX_SUB RX_SUBSCL SDASerial Sub Input and Output
RTSPWM1Serial Input Permission
M1M1Parent/Child Selection
M2M2Adding Relay Function to Child
M3M3Sleep
EX1AI2Overwriting Operation Mode
BPSBPSEnabling Alternative Baud Rate Setting
RSTRSTReset Input
SETDI1Enter interactive mode

Power Input

Connect a 3.3V (2.0-3.6V) power supply to VCC/GND.

Serial Input and Output

TX/RX are used for transmitting and receiving serial communication (UART).

Serial Sub Input and Output

TX_SUB (SCL) / RX_SUB (SDA) can be used as sub-ports for serial input and output.

Serial Input Permission

When RTS (PWM1) is at Low level, it indicates that serial input to RX is being accepted.

Parent/Child Selection

Connecting M1 to GND sets the device as a parent, while leaving it open or connecting to VCC sets it as a child.

Adding Relay Function to Child

When M2 is connected to GND in child mode, relay functionality can be added.

Sleep

Connecting M3 to GND puts the device into sleep mode.

Overwriting Operation Mode

By connecting EX1 to GND at startup, the operation mode can be overwritten to format mode (binary).

Enabling Alternative Baud Rate Setting

Connecting BPS to GND enables the alternative baud rate setting specified in interactive mode.

Reset Input

By connecting a push button between RST and GND, a reset button can be implemented. RST has an internal pull-up resistor.

Enter interactive mode

By connection SET to GND on startup, the interactive mode will be ready.

TWELITE UART

The functions of pins used by the Serial Communication App are represented using the pin names of the 7P interface printed on the board (② in the figure below).

Board Antenna Type

Board Antenna Type

Coaxial Connector Type

Coaxial Connector Type

SilkscreenFunction
VCC GNDPower Input
TXD RXDSerial Input and Output
SETOverwriting Operation Mode
RSTReset Input

Power Input

Connect a 3.3V (2.0-3.6V) power supply to VCC/GND.

Serial Input and Output

TX/RX are used for transmitting and receiving serial communication (UART).

Overwriting Operation Mode

By connecting SET to GND at startup, the operation mode can be overwritten to format mode (ASCII).

Reset Input

By connecting a push button between RST and GND, a reset button can be implemented. RST has an internal pull-up resistor.

3.5.1.2 - Communication Modes of Serial Communication App

Explanation of each communication mode
The Serial Communication App (App_Uart) has five communication modes.

List of Communication Modes

Each mode is switched by Interactive Mode (some modes can be set via pin input).

IDMode
AFormat Mode (ASCII)
BFormat Mode (Binary)
CChat Mode
DTransparent Mode
EHeader Transparent Mode

Initial state is Header Transparent Mode.

A: Format Mode (ASCII)

When data is input to the transmitting terminal according to a specific format, the receiving terminal outputs data according to the same specific format.

Data represented in hexadecimal is expressed as ASCII strings.

Input on Transmitting SideOutput on Receiving Side
Simple/Extended format dataSimple/Extended format data

In TWELITE UART, this mode is enabled when started with the SET pin connected to GND.

There are two formats to represent data.

  • Simple format: Uses only logical device ID. Super simple! Compatible with the standard app’s UART transmission function.
  • Extended format: Uses transmission options such as serial ID and retransmission count in addition to logical device ID.

For example, 5-byte binary data 0x48 0x45 0x4C 0x4C 0x4F can be sent using the simple format as follows.

[Transmitting Side]

:000148454C4C4F8B  <- Input
:DBA1800103  <- Output

[Receiving Side]

:780148454C4C4F13  <- Output

In format mode, settings such as application ID can be dynamically applied not only by Interactive Mode but also by commands via UART (ASCII format).

B: Format Mode (Binary)

When data is input to the transmitting terminal according to a specific format, the receiving terminal outputs data according to the same specific format.

Data represented in hexadecimal is expressed in binary format as is.

Input on Transmitting SideOutput on Receiving Side
Simple/Extended format dataSimple/Extended format data

In TWELITE / TWELITE DIP, this mode is enabled when started with the EX1 pin connected to GND.

Like Format Mode (ASCII), there are two formats to represent data.

For example, 5-byte binary data 0x48 0x45 0x4C 0x4C 0x4F can be sent using the simple format as follows.

[Transmitting Side]

0xA5 0x5A 0x00 0x07 0x00 0x01 0x48 0x45 0x4C 0x4C 0x4F 0x43 0x04    <- Input
0xA5 0x5A 0x00 0x04 0xDB 0xA1 0x80 0x01 0xFB 0x04  <- Output

[Receiving Side]

0xA5 0x5A 0x00 0x07 0x78 0x01 0x48 0x45 0x4C 0x4C 0x4F 0x3B 0x04  <- Output

In format mode, settings such as application ID can be dynamically applied not only by Interactive Mode but also by commands via UART (binary format).

C: Chat Mode

Enables text chat.

Input on Transmitting SideOutput on Receiving Side
Any stringAuxiliary information + any string

Displays prompt and echoes back (outputs the entered characters). All terminals act as child devices and perform broadcast communication.

For example, when a terminal sends the string Hello to other terminals, the behavior is as follows.

[Transmitting Side]

810A4778:0> Hello  <- Input
810A4778:1>  <- Output

[Receiving Side]

[810A4778:0] Hello  <- Output
82018CA0:0>  <- Output

In the above example, the prompt shows the serial ID, but you can also use any handle name.

D: Transparent Mode

When arbitrary data is input to the transmitting terminal, the receiving terminal outputs the received data as is.

Input on Transmitting SideOutput on Receiving Side
Any dataAny data

Since no format is required, existing UART communication can be easily wirelessized.

On the other hand, data boundaries become ambiguous, and the receiving output cannot identify the sender, which are drawbacks.

By default, data input to the transmitting side is separated by CRLF, and data before CRLF is sent.

For example, when Hello<Enter> is input on the transmitting terminal, the receiving terminal outputs Hello as is.

[Transmitting Side]

Hello  <- Input

[Receiving Side]

Hello  <- Output

E: Header Transparent Mode

When arbitrary data is input to the transmitting terminal, the receiving terminal outputs the received content with auxiliary information added in a specific format.

Input on Transmitting SideOutput on Receiving Side
Any dataAny data + auxiliary information

By default, data input to the transmitting side is separated by CRLF, and data before CRLF is sent.

For example, when Hello<Enter> is input on the transmitting terminal, the receiving terminal outputs Hello in a format including auxiliary information. The transmitting terminal also outputs a format that conveys a transmission completion message.

[Transmitting Side]

Hello  <- Input
;U;00004;219;0x820163B2;000;000;0,1,Hel...;6E;  <- Output

[Receiving Side]

;U;00003;000;0x820163B2;255;000;Hello;42;  <- Output

The auxiliary information output by the receiving side includes the sender’s address, received signal strength, checksum, etc. The format of auxiliary information can be customized.

3.5.1.2.1 - Serial Communication App Format Mode (ASCII)

Mode that adds headers to both transmitted and received outputs (ASCII format)
Format mode adds headers to both transmitted and received outputs. In ASCII format, data is represented as hexadecimal strings.
Example network configuration with format mode

Overview

When data formatted in a specific manner is input on the transmitting side, the receiving side outputs data formatted in the same manner.

Data is represented as hexadecimal ASCII strings.

Transmitting Side InputReceiving Side Output
Simple/Extended format dataSimple/Extended format data
  • In TWELITE UART, format mode (ASCII) is enabled by starting up with the SET pin connected to GND.
  • In TWELITE / TWELITE DIP, format mode (binary) is enabled by starting up with the EX1 pin connected to GND.

There are two types of formats that can be handled.

  • Simple format: uses only the Logical Device ID. Extremely Simple! Compatible with the UART transmission function of the standard app.
  • Extended format: uses Logical Device ID plus transmission options such as Serial ID and retry count.

For example, 5-byte binary data 0x48 0x45 0x4C 0x4C 0x4F can be sent using the simple format as follows.

[Sending side]

:000148454C4C4F8B  <- Input
:DBA1800103  <- Output

[Receiving side]

:780148454C4C4F13  <- Output

Basic Format

When sending data sequences expressed in basic or extended formats, they are converted to ASCII strings (0-9, A-F).

The format is extremely simple! It starts with : and ends with CRLF, just like the output of the standard app (App_Twelite) or the parent device output of the parent/repeater app (App_Wings).

HeaderPayloadChecksumFooter
:Repeated 00-FFLRC8 of payloadCRLF
  • All ASCII characters
  • Starts with : (0x3A)
  • Checksum is the two’s complement of the sum of the payload
  • Ends with CRLF (\r\n/0x0D 0x0A)
  • Big-endian

For example, binary data 0x00 0x11 0x22 0x33 0xAA 0xBB 0xCC is expressed as follows.

:00112233AABBCC69<CR><LF>

Distinguishing Parent and Child Devices

Format mode distinguishes between parent and child devices.

The Application ID and frequency channel must be matched between parent and child devices.

Source Identification

Format mode allows identifying the source from the received data.

The simple format uses the Logical Device ID, and the extended format uses the Logical Device ID plus the extended address.

Simple Format

When using the simple format of format mode, follow the format below.

Transmitting Side Input

#DataDescriptionNotes
charHeaderOnly :
0uint8Destination Logical Device IDParent 0x00, child 0x01-0x64, all children 0x78
1uint8Command numberAny value less than 0x80
2[uint8]Arbitrary dataByte sequence of length (N) (recommended (N \leqq 80))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Receiving Side Output

#DataDescriptionNotes
charHeaderOnly :
0uint8Source Logical Device IDParent 0x00, child 0x01-0x64, unset child 0x78
1uint8Command numberValue less than 0x80 specified by the sender
2[uint8]Arbitrary dataByte sequence of length (N)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Transmitting Side Output (Response Message)

#DataDescriptionNotes
charHeaderOnly :
0uint8Source Logical Device IDOnly 0xDB: indicates itself
1uint8Command numberOnly 0xA1
2uint8Response IDContinuation number in the range 128-255 (0x80-0xFF)
3uint8ResultSuccess 1, failure 0
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Usage

An example of sending byte sequence 0x11 0x22 0x33 0xAA 0xBB 0xCC from the parent to all children is shown.

[Sending side: Parent]

:7801112233AABBCCF0<CR><LF>  <- Input
:DBA1800103<CR><LF>  <- Output

The trailing 0xF0 is the checksum: the two’s complement of the sum from 0x78 to 0xCC (LSB 8 bits).

[Receiving side: All children]

:0001112233AABBCC68<CR><LF>  <- Output

The trailing 0x68 is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

Extended Format

When using the extended format of format mode, follow the format below.

Transmitting Side Input

When specifying destination using Logical Device ID

#DataDescriptionNotes
charHeaderOnly :
0uint8Destination Logical Device IDParent 0x00, child 0x01-0x64, all children 0x78
1uint8Command numberOnly 0xA0
2uint8Response IDAny value
3[uint8]OptionsOption list of length (N) (Details of option list)
3+(N)[uint8]Arbitrary dataByte sequence of length (M) (recommended (M \leqq 80))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

When specifying destination using Extended Address

#DataDescriptionNotes
charHeaderOnly :
0uint8Extended Address SpecifierOnly 0x80
1uint8Command numberOnly 0xA0
2uint8Response IDAny value
3uint32Destination Extended AddressSerial ID with 0x8 added at the front
7[uint8]OptionsOption list of length (N) (Details of option list)
7+(N)[uint8]Arbitrary dataByte sequence of length (M) (recommended (M \leqq 80))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Details of Option List

In the extended format, you can specify fine settings by specifying the option list.

The option list is represented by repeating option IDs and their arguments. The end is 0xFF.

IDArgumentDefaultDescription
0x01NoneDisabledEnable MAC ACK
0x02uint80x00Enable application retry
0x03uint160x0000Minimum initial transmission delay
0x04uint160x0000Maximum initial transmission delay
0x05uint1610Application retry interval
0x06NoneDisabledAllow parallel requests
0x07NoneDisabledDisable response messages
0x08NoneDisabledSleep after transmission
0x01: Enable MAC ACK

Enables MAC layer ACK (acknowledgment).

Not suitable for frequent data transmission, but can improve reliability.

0x02: Enable Application Retry

When using MAC ACK, specify 0x00-0x0F. Retries 0-16 times respectively until the transmission succeeds.

When not using MAC ACK, specify 0x81-0x8F. Always retries 1-16 times.

Response messages are output after all retries are completed.

0x03: Minimum Initial Transmission Delay

Specifies the minimum delay before the first transmission in milliseconds.

0x04: Maximum Initial Transmission Delay

Specifies the maximum delay before the first transmission in milliseconds.

0x05: Application Retry Interval

Specifies the retry interval in milliseconds when application retry is enabled.

0x06: Allow Parallel Requests

Allows parallel requests.

When allowed, the next request can be accepted without blocking until the current request completes.

For example, if three requests with a 0.5-second delay are input consecutively, normally they are processed sequentially at 0.5s, 1.0s, and 1.5s. When parallel requests are allowed, they are processed in no particular order after 0.5s. Note that it cannot be used when packet fragmentation is required.

0x07: Disable Response Messages

Disables the response messages output when data is input on the transmitting side.

0x08: Sleep After Transmission

Immediately puts the device to sleep after transmission.

When RX detects a rising edge, it wakes up from sleep. Please input any 1 byte of data.

After waking up, UART initialization completes and input is accepted.

Receiving Side Output

#DataDescriptionNotes
charHeaderOnly :
0uint8Source Logical Device IDParent 0x00, child 0x01-0x64, unset child 0x78
1uint8Command numberOnly 0xA0
2uint8Response IDValue specified by the sender
3uint32Source Extended AddressSerial ID with 0x8 added at the front
7uint32Destination Extended Address0xFFFFFFFF if using Logical Device ID
11uint8LQIRadio communication quality at reception
12uint16Length of following byte sequenceNumber of bytes (M)
14[uint8]Arbitrary dataByte sequence of length (M)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Transmitting Side Output (Response Message)

#DataDescriptionNotes
charHeaderOnly :
0uint8Source Logical Device IDOnly 0xDB: indicates itself
1uint8Command numberOnly 0xA1
2uint8Response IDValue specified at input
3uint8ResultSuccess 1, failure 0
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Usage

An example of sending byte sequence 0x11 0x22 0x33 0xAA 0xBB 0xCC from the parent to a child is shown.

Example specifying Logical Device ID

An example sending from the parent to the child with Logical Device ID 0x42.

  • Response ID is 0x01
  • No options
  • Parent’s extended address is 0x81000000 (Serial ID 0x1000000)

[Sending side: Parent]

:42A001FF112233AABBCC87<CR><LF>  <- Input
:DBA1010182<CR><LF>  <- Output

The trailing 0x87 is the checksum: the two’s complement of the sum from 0x42 to 0xCC (LSB 8 bits).

[Receiving side: Child]

:00A00181000000FFFFFFFFC80006112233AABBCC7D<CR><LF>  <- Output

The trailing 0x7D is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

Example specifying Extended Address

An example sending from the parent to the child with extended address 0x81000001 (Serial ID 0x1000001).

  • Response ID is 0x01
  • No options
  • Parent’s extended address is 0x81000000 (Serial ID 0x1000000)

[Sending side: Parent]

:80A00181000001FF112233AABBCCC7<CR><LF>  <- Input
:DBA1010182<CR><LF>  <- Output

The trailing 0xC7 is the checksum: the two’s complement of the sum from 0x80 to 0xCC (LSB 8 bits).

[Receiving side: Child]

:00A0018100000081000001C80006112233AABBCCF7<CR><LF>  <- Output

The trailing 0xF7 is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

Example using MAC ACK

An example sending from the parent to the child with Logical Device ID 0x42 using MAC ACK.

  • Response ID is 0x01
  • Option 0x01: Enable MAC ACK specified
  • Parent’s extended address is 0x81000000 (Serial ID 0x1000000)

[Sending side: Parent]

:42A00101FF112233AABBCC86<CR><LF>  <- Input
:DBA1010182<CR><LF>  <- Output

The trailing 0x86 is the checksum: the two’s complement of the sum from 0x42 to 0xCC (LSB 8 bits).

[Receiving side: Child]

:00A00181000000FFFFFFFFC80006112233AABBCC7D<CR><LF>  <- Output

The trailing 0x7D is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

Example using delay

An example sending from the parent to the child with Logical Device ID 0x42 with a 768ms delay.

[Sending side: Parent]

:42A001030300FF112233AABBCC81<CR><LF>  <- Input
:DBA1010182<CR><LF>  <- Output

The trailing 0x81 is the checksum: the two’s complement of the sum from 0x42 to 0xCC (LSB 8 bits).

[Receiving side: Child]

:00A00181000000FFFFFFFFC80006112233AABBCC7D<CR><LF>  <- Output

The trailing 0x7D is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

0xDB Command

Instead of setting interactive mode, you can operate and configure the module by inputting the 0xDB command from UART.

3.5.1.2.1.1 - 0xDB Command in Serial Communication App Format Mode (ASCII)

Setting functions using the 0xDB command in format mode (ASCII) without using Interactive Mode
In format mode, dynamic configuration can be performed from devices connected via UART by using the 0xDB command instead of Interactive Mode.

Input Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB itself
1uint8Command numberSelected from values below
2[uint8]ParameterOptional length N bytes representing setting values
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

List of Command Numbers

Function
0xF0Enable ACK
0xF1Get Device Info
0xF2Apply Device Settings
0xF3Get Device Settings
0xFDErase Device Settings
0xFESave Device Settings
0xFFReset Device

0xF0: Enable ACK

Requests an ACK response.

No parameters.

Response Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF0
2uint8DataOnly 0x01
uint8Checksum0x34: LRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xF1: Get Device Info

Displays address and other information. Also output at startup.

No parameters.

Response Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF1
2uint32Default Application ID67720103
6uint32Version numberFor 1.4.7, 00010407
10uint8Logical device ID
11uint32Serial ID
15uint8Silent mode statusEnabled 1, Disabled 0
16uint8Network statusUP 1, DOWN 0
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xF2: Apply Device Settings

Applies the settings.

Response Format

On Success
#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF3
2[uint8]Settings contentIdentifier
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')
On Failure
#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF3
2uint8ErrorOnly 0xFF
uint8Checksum0x33: LRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xF3: Get Device Settings

Gets the settings.

Response Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF3
2[uint8]Settings contentIdentifier and data
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xFD: Erase Device Settings

Resets device settings and resets the device.

No parameters or response.

0xFE: Save Device Settings

Saves applied settings and resets the device.

No parameters or response.

0xFF: Reset Device

Discards applied settings and resets the device.

No parameters or response.

Parameter List (0xF2 / 0xF3)

Parameters for 0xF2: Apply Device Settings and 0xF3: Get Device Settings are represented by repeated pairs of identifiers and data (big endian).

IdentifierDataContent
0x00uint32Application ID
0x01uint32Frequency Channel Mask
0x02uint16Retry Count and Output
0x03uint8Logical Device ID
0x04uint8Role
0x05uint8Relay Layer
0x06uint8Communication Mode
0x07uint32Baud Rate
0x08uint8Parity
0x09uint8Encryption Function
0x0A[uint8]Encryption Key
0x0B[uint8]Header / Handle name
0x0Cuint16Delimiter Character
0xFFuint8Error

0x00: Application ID

Specifies the application ID.

0x01: Frequency Channel Mask

Specifies the bit mask of frequency channels.

Set bits for channels to be used. For example, to use channel 11, specify 1<<11.

0x02: Retry Count and Output

Specifies the radio transmission output and the number of additional packet transmissions in transparent mode and header-attached transparent mode.

Only the lower 1 byte is used. The upper 4 bits represent the retry count (0-9), and the lower 4 bits represent the transmission output (0-3). For example, 8 retries / output 3 is 0x0083.

0x03: Logical Device ID

Specifies the logical device ID.

0x04: Role

Effective only for slave devices. Specify one of the following values. Normally, select a delivery method that does not use the network layer.

Delivery Methods Without Network Layer

  • 0: Normal designation (parent or child device)
  • 1-3: Relay slave devices (logical device IDs are 1-100 or 120). Numbers 1-3 indicate the maximum relay hop count. This method retransmits up to the maximum relay hops, which may cause duplicate packets depending on relay device placement and count.

Delivery Methods Using Network Layer

  • 11: Parent device
  • 12: Relay device
  • 13: Child device

0x05: Relay Layer

The relay layer number. Relay devices attempt to connect to relay devices or parent devices in upper (smaller value) relay layers. Effective only when Role is set to 12.

0x06: Communication Mode

  • 0: Transparent mode
  • 1: Format mode (ASCII)
  • 2: Format mode (Binary)
  • 3: Chat mode
  • 4: Header-attached transparent mode

0x07: Baud Rate

Specifies the UART baud rate.

0x08: Parity

Specifies the sum of settings in the following combination:

  • Bit
    • 0: 8Bit
    • 8: 7Bit
  • Parity
    • 0: None
    • 1: Odd
    • 2: Even
  • Stop
    • 0: STOP 1
    • 4: STOP 2

For example, 7-E-1 is specified as 8+2+0=10(0xA).

0x09: Encryption Function

Specifies whether encryption is enabled.

  • 0: Disabled
  • 1: AES128bit encryption enabled

0x0A: Encryption Key

Specifies a 16-byte encryption key.

Can store binary sequences that cannot be set in Interactive Mode. This may cause display issues in Interactive Mode.

0x0B: Header / Handle name

Specifies a header format on the mode E or handle name on the mode C.

0x0C: Delimiter Character

Specifies the delimiter character (0x00-0xFF).

3.5.1.2.2 - Serial Communication App Format Mode (Binary)

Mode that adds headers to both transmitted and received outputs (binary format)
Format mode adds headers to both transmitted and received outputs. In binary format, data is represented as raw binary.
Example network configuration with format mode

Overview

When data formatted in a specific manner is input on the transmitting side, the receiving side outputs data formatted in the same manner.

Data represented in hexadecimal is output as raw binary.

Transmitting Side InputReceiving Side Output
Simple/Extended Format DataSimple/Extended Format Data
  • On TWELITE UART, format mode (ASCII) is enabled by connecting the SET pin to GND at startup.
  • On TWELITE / TWELITE DIP, format mode (binary) is enabled by connecting the EX1 pin to GND at startup.

There are two types of supported formats.

  • Simple format: uses Logical Device ID only; Extremely Simple! Compatible with UART transmission function of the standard app
  • Extended format: uses Logical Device ID plus options such as Serial ID and retry count

For example, 5 bytes of binary data 0x48 0x45 0x4C 0x4C 0x4F can be transmitted using the simple format as follows.

[Transmitting Side]

A5 5A 80 07 00 01 48 45 4C 4C 4F 43 04    <- Input
A5 5A 80 04 DB A1 80 01 FB 04  <- Output

[Receiving Side]

A5 5A 80 07 78 01 48 45 4C 4C 4F 3B 04  <- Output

Basic Format

When sending data expressed in basic or extended format, handle it as raw binary data.

HeaderLengthPayloadChecksumFooter
A5 5APayload LengthRepeated 00-FFXOR of PayloadEOT
  • All binary
  • Header is 2 bytes: A5 5A
  • Payload length is 2 bytes representing the byte count, OR’ed with 0x8000
  • Checksum is XOR of payload
  • Footer is EOT 0x04 (can be omitted on input)
  • Big-endian

For example, binary data 00 11 22 33 AA BB CC is expressed as follows.

A5 5A 80 07 00 11 22 33 AA BB CC DD 04

Although debugging is troublesome, it offers high efficiency for communication between microcontrollers.

Distinguishing Parent and Child Devices

Format mode distinguishes between parent and child devices.

Parent and child devices must match Application ID and Frequency Channel.

Source Identification

Format mode allows identification of the source from received data.

Simple format uses Logical Device ID, and extended format uses Logical Device ID plus extended address.

Simple Format

When using the simple format of format mode, follow the format below.

Transmitting Side Input

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command NumberAny value less than 0x80
2[uint8]Arbitrary DataByte sequence of length \(N\) (recommended \(N\leqq80\))
uint8ChecksumXOR
uint8FooterEOT (0x04)

Receiving Side Output

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Source Logical Device IDParent 0x00, Child 0x01-0x64, Unset Child 0x78
1uint8Command NumberValue less than 0x80 specified by sender
2[uint8]Arbitrary DataByte sequence of length \(N\)
uint8ChecksumXOR
uint8FooterEOT (0x04)

Transmitting Side Output (Response Message)

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length4
0uint8Source Logical Device IDOnly 0xDB: indicates itself
1uint8Command NumberOnly 0xA1
2uint8Response IDContinuation number in the range 128-255 (0x80-0xFF)
3uint8ResultSuccess 1, Failure 0
uint8ChecksumXOR
uint8FooterEOT (0x04)

Example

Example of sending byte sequence 11 22 33 AA BB CC from parent to all children.

[Transmitting Side: Parent]

A5 5A 80 08 78 01 11 22 33 AA BB CC A4 04  <- Input
A5 5A 80 04 DB A1 80 01 FB 04  <- Output

The last byte 0xA4 is the checksum: XOR from 0x78 to 0xCC.

[Receiving Side: All Children]

A5 5A 80 08 00 01 11 22 33 AA BB CC DC 04  <- Output

The last byte 0xDC is the checksum: XOR from 0x00 to 0xCC.

Extended Format

When using the extended format of format mode, follow the format below.

Transmitting Side Input

When using Logical Device ID as destination

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+\(M\)+3
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command NumberOnly 0xA0
2uint8Response IDAny value
3[uint8]OptionsOption list of length \(N\) (Details below)
3+\(N\)[uint8]Arbitrary DataByte sequence of length \(M\) (recommended \(M\leqq80\))
uint8ChecksumXOR
uint8FooterEOT (0x04)

When using Extended Address as destination

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+\(M\)+7
0uint8Extended Address SpecifierOnly 0x80
1uint8Command NumberOnly 0xA0
2uint8Response IDAny value
3uint32Destination Extended AddressSerial ID with 0x8 added at the front
7[uint8]OptionsOption list of length \(N\) (Details below)
7+\(N\)[uint8]Arbitrary DataByte sequence of length \(M\) (recommended \(M\leqq80\))
uint8ChecksumXOR
uint8FooterEOT (0x04)

Details of Option List

In extended format, detailed settings can be specified by providing an option list.

The option list consists of repeated option IDs and arguments. It ends with 0xFF.

IDArgumentDefaultDescription
0x01NoneDisabledEnable MAC ACK
0x02uint80x00Enable Application Retransmission
0x03uint160x0000Minimum Initial Transmission Delay
0x04uint160x0000Maximum Initial Transmission Delay
0x05uint1610Application Retransmission Interval
0x06NoneDisabledAllow Parallel Requests
0x07NoneDisabledDisable Response Messages
0x08NoneDisabledSleep After Transmission
0x01: Enable MAC ACK

Enables MAC layer ACK (acknowledgment).

Not suitable for frequent data transmissions but can improve reliability.

0x02: Enable Application Retransmission

When using MAC ACK, specify 0x00-0x0F. Retransmits 0-16 times until successful.

When not using MAC ACK, specify 0x81-0x8F. Always retransmits 1-16 times.

Response messages are output after all retransmissions are complete.

0x03: Minimum Initial Transmission Delay

Specifies the minimum delay before the first transmission in milliseconds.

0x04: Maximum Initial Transmission Delay

Specifies the maximum delay before the first transmission in milliseconds.

0x05: Application Retransmission Interval

Specifies the interval between application retransmissions in milliseconds.

0x06: Allow Parallel Requests

Allows parallel requests.

When allowed, the next request can be accepted without blocking until the previous request completes.

For example, if three requests each with 0.5 seconds delay are input consecutively, normally they are processed sequentially at 0.5s, 1.0s, and 1.5s. With parallel requests allowed, they are processed in any order after 0.5s. Note that this cannot be used when packet segmentation is required.

0x07: Disable Response Messages

Disables response messages output when data is input on the transmitting side.

0x08: Sleep After Transmission

Immediately puts the device to sleep after transmission.

RX detects rising edge to wake from sleep. Input any 1 byte of data.

After waking, UART initialization completes and input is accepted.

Receiving Side Output

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(M\)+14
0uint8Source Logical Device IDParent 0x00, Child 0x01-0x64, Unset Child 0x78
1uint8Command NumberOnly 0xA0
2uint8Response IDValue specified by sender
3uint32Source Extended AddressSerial ID with 0x8 added at the front
7uint32Destination Extended Address0xFFFFFFFF when using Logical Device ID
11uint8LQIRadio signal quality at reception
12uint16Length of Following BytesByte count \(M\)
14[uint8]Arbitrary DataByte sequence of length \(M\)
uint8ChecksumXOR
uint8FooterEOT (0x04)

Transmitting Side Output (Response Message)

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length4
0uint8Source Logical Device IDOnly 0xDB: indicates itself
1uint8Command NumberOnly 0xA1
2uint8Response IDValue specified on input
3uint8ResultSuccess 1, Failure 0
uint8ChecksumXOR
uint8FooterEOT (0x04)

Examples

Example of sending byte sequence 11 22 33 AA BB CC from parent to child.

Example specifying Logical Device ID

Example of sending from parent to child with Logical Device ID 0x01.

  • Response ID is 0x01
  • No options

[Transmitting Side: Parent]

A5 5A 80 0A 01 A0 01 FF 11 22 33 AA BB CC 82 04  <- Input
A5 5A 80 04 DB A1 01 01 7A 04  <- Output

The last byte 0xC1 is checksum: XOR from 0x42 to 0xCC.

[Receiving Side: Child]

A5 5A 80 14 00 A0 01 82 03 68 41 FF FF FF FF FF 00 06 11 22 33 AA BB CC 2D 04  <- Output

The last byte 0x2D is checksum: XOR from 0x00 to 0xCC.

Example specifying Extended Address

Example of sending from parent to child with Extended Address 0x820163B2 (Serial ID 0x20163B2).

  • Response ID is 0x01
  • No options

[Transmitting Side: Parent]

A5 5A 80 0E 80 A0 01 82 01 63 B2 FF 11 22 33 AA BB CC 51 04  <- Input
A5 5A 80 04 DB A1 01 01 7A 04  <- Output

The last byte 0x51 is checksum: XOR from 0x80 to 0xCC.

[Receiving Side: Child]

A5 5A 80 14 00 A0 01 82 03 68 41 82 01 63 B2 FF 00 06 11 22 33 AA BB CC 7F 04  <- Output

The last byte 0x7F is checksum: XOR from 0x00 to 0xCC.

Example using MAC ACK

Example of sending from parent to child with Logical Device ID 0x01 using MAC ACK.

[Transmitting Side: Parent]

A5 5A 80 0B 01 A0 01 01 FF 11 22 33 AA BB CC 83 04  <- Input
A5 5A 80 04 DB A1 01 01 7A 04  <- Output

The last byte 0x83 is checksum: XOR from 0x01 to 0xCC.

[Receiving Side: Child]

A5 5A 80 14 00 A0 01 82 03 68 41 00 00 01 01 FF 00 06 11 22 33 AA BB CC 2D 04  <- Output

The last byte 0x2D is checksum: XOR from 0x00 to 0xCC.

Example with Delay

Example of sending from parent to child with Logical Device ID 0x01 with 768ms delay.

[Transmitting Side: Parent]

A5 5A 80 0D 01 A0 01 03 03 00 FF 11 22 33 AA BB CC 82 04  <- Input
A5 5A 80 04 DB A1 01 01 7A 04  <- Output

The last byte 0x82 is checksum: XOR from 0x01 to 0xCC.

[Receiving Side: Child]

A5 5A 80 14 00 A0 01 82 03 68 41 FF FF FF FF FF 00 06 11 22 33 AA BB CC 2D 04  <- Output

The last byte 0x2D is checksum: XOR from 0x00 to 0xCC.

0xDB Command

Instead of setting interactive mode, you can operate and configure the module by inputting the 0xDB command from UART.

3.5.1.2.2.1 - 0xDB Command in Serial Communication App Format Mode (Binary)

Setting functions using the 0xDB command in format mode (binary) without using Interactive Mode
In format mode, you can dynamically configure settings from devices connected via UART by using the 0xDB command instead of Interactive Mode.

Input Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Destination Logical Device IDOnly 0xDB indicating itself
1uint8Command NumberSelected from values below
2[uint8]ParameterByte sequence of length \(N\) indicating setting value (optional)
uint8ChecksumXOR
uint8FooterEOT (0x04)

Command Number List

Function
0xF0Enable ACK
0xF1Get Device Info
0xF2Apply Device Settings
0xF3Get Device Settings
0xFDErase Device Settings
0xFESave Device Settings
0xFFReset Device

0xF0: Enable ACK

Requests ACK response.

No parameters.

Response Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length3
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF0
2uint8DataOnly 0x01
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xF1: Get Device Info

Displays information such as address. Also output at startup.

No parameters.

Response Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length17
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF1
2uint32Default Application ID67720103
6uint32Version NumberFor 1.4.7, 00010407
10uint8Logical Device ID
11uint32Serial ID
15uint8Silent Mode StatusEnabled 1, Disabled 0
16uint8Network StatusUP 1, DOWN 0
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xF2: Apply Device Settings

Applies settings.

Response Format

On Success
#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF3
2[uint8]Setting ContentIdentifier
uint8ChecksumXOR
uint8FooterEOT (0x04)
On Failure
#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length3
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF3
2uint8ErrorOnly 0xFF
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xF3: Get Device Settings

Retrieves settings.

Response Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF3
2[uint8]Setting ContentIdentifier and data
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xFD: Erase Device Settings

Initializes settings and resets the device.

No parameters or response.

0xFE: Save Device Settings

Saves applied settings and resets the device.

No parameters or response.

0xFF: Reset Device

Discards applied settings and resets the device.

No parameters or response.

Parameter List (0xF2/0xF3)

Parameters for 0xF2: Apply Device Settings and 0xF3: Get Device Settings are represented as repeated identifier and data (big endian) pairs.

IdentifierDataContent
0x00uint32Application ID
0x01uint32Frequency Channel Mask
0x02uint16Retry Count and Output
0x03uint8Logical Device ID
0x04uint8Role
0x05uint8Relay Layer
0x06uint8Communication Mode
0x07uint32Baud Rate
0x08uint8Parity
0x09uint8Encryption Function
0x0A[uint8]Encryption Key
0x0B[uint8]Header / Handle name
0x0Cuint16Delimiter Character
0xFFuint8Error

0x00: Application ID

Specifies the application ID.

0x01: Frequency Channel Mask

Specifies the bit mask of frequency channels.

Set bits for channels to use. For example, to use channel 11, set 1<<11.

0x02: Retry Count and Output

Specifies the radio transmission output and the number of additional packets to send in transparent mode and header-attached transparent mode.

Only the lower 1 byte is used. The upper 4 bits indicate retry count (0-9), and the lower 4 bits indicate transmission output (0-3). For example, 8 retries/output 3 is 0x0083.

0x03: Logical Device ID

Specifies the logical device ID.

0x04: Role

Valid only for child devices. Specify the following values. Usually, select a delivery method without using the network layer.

Delivery Methods Without Using Network Layer

  • 0: Normal designation (parent or child)
  • 1-3: Relay child devices (logical device IDs 1-100 or 120). Numbers 1-3 indicate maximum relay hops. This method repeats retries up to the maximum relay hops, which may cause duplicate packets depending on relay device placement and number.

Delivery Methods Using Network Layer

  • 11: Parent device
  • 12: Relay device
  • 13: Child device

0x05: Relay Layer

The relay layer number. Relay devices attempt to connect to relay devices or parent devices with higher layers (lower values). Effective only when Role is set to 12.

0x06: Communication Mode

  • 0: Transparent mode
  • 1: Format mode (binary)
  • 2: Format mode (binary)
  • 3: Chat mode
  • 4: Header-attached transparent mode

0x07: Baud Rate

Specifies UART baud rate.

0x08: Parity

Specifies the sum of settings in the following combination.

  • Bit
    • 0: 8Bit
    • 8: 7Bit
  • Parity
    • 0: None
    • 1: Odd
    • 2: Even
  • Stop
    • 0: STOP 1
    • 4: STOP 2

For example, 7-E-1 is 8+2+0=10(0xA).

0x09: Encryption Function

Specifies whether encryption is enabled.

  • 0: Disabled
  • 1: AES128bit encryption enabled

0x0A: Encryption Key

Specifies a 16-byte encryption key.

Allows storing binary sequences that cannot be set in Interactive Mode. In this case, the display in Interactive Mode may be disrupted.

0x0B: Header / Handle name

Specifies a header format on the mode E or handle name on the mode C.

0x0C: Delimiter Character

Specifies the delimiter character string (0x00-0xFF).

3.5.1.2.3 - Serial Communication App Chat Mode

Mode that displays prompts and performs echo back
Chat mode realizes text chat through prompt display and echo back.

By connecting MONOSTICK to a PC etc., chat can be performed among multiple terminals.

Overview

Enables text chat.

Sending Side InputReceiving Side Output
Any stringAny string + auxiliary information

Displays prompt and echoes back (outputs input characters). All terminals operate as child devices, performing broadcast communication.

For example, when sending the string Hello from one terminal to another, it behaves as follows.

[Sending Side]

810A4778:0> Hello  <- Input
810A4778:1>  <- Output

[Receiving Side]

[810A4778:0] Hello  <- Output
82018CA0:0>  <- Output

Chat mode displays prompt and echoes back (outputs input characters entered by itself).

All terminals are treated as child devices and broadcast their transmitted content. Communication is possible with all terminals but destination cannot be specified. Binary data cannot be sent. Only strings are supported (0x00-0x1F, 0x7F cannot be sent).

Relay supports up to 3 hops. Relay is disabled by default.

Distinction between Parent and Child Devices

Chat mode does not distinguish between parent and child devices.

If the Application ID and frequency channel are the same, data entered in any terminal is sent to other terminals.

Network configuration image

Network configuration image

Identification of Source

The auxiliary information in the received output can identify the sender.

If the Interactive Mode’s h: Header format is blank, the 7-digit serial ID with a leading 0x8 is used as the extended address. For example, the following output indicates the sender’s serial ID was 0x10A4778.

[810A4778:0] Hello

If h: Header format is set to an arbitrary string, it is used as the handle name. Handle name consumes data space in the wireless packet.

Sending Side Input Format

Enter message and newline after prompt.

DataContentRemarks
[char]Message0x00-0x1F, 0x7F not allowed
charCR (0x0D/'\r')Allowed alone
charLF (0x0A/'\n')Allowed alone
810A4778:0> Hello

Receiving Side Output Format

Outputs received message following auxiliary info.

Auxiliary information includes the module’s extended address or handle name and a sequence number.

DataContentRemarks
charAuxiliary info header[ only
[char]Identification info8-digit extended address or handle name
charAuxiliary info delimiter: only
[char]Sequence numberStarting from 0
charAuxiliary info footer] only
charSeparatorSpace only
[char]Message
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')
[810A4778:0] Hello

Other Inputs

Terminals supporting escape sequences can use the following control commands.

  • Ctrl-L: Clear screen
  • Ctrl-C: Cancel input
  • BS/DEL: Move cursor back

3.5.1.2.4 - Serial Communication App Transparent Mode

Mode that purely wirelesss UART
Transparent mode realizes behavior similar to UART connected by wires without adding headers, echo back, or prompt display.
Image connecting external microcontrollers

External microcontrollers can be easily connected, but to optimize communication using formats, format modes (ASCII / Binary) are suitable.

Overview

Purely wirelesss UART.

Sending side inputReceiving side output
Any dataAny data

Since no format is required, existing UART communication can be easily wirelessized.

However, data delimiters are ambiguous and it is impossible to identify the sender from the receiver output.

The initial state specifies CRLF as the transmission trigger character. Therefore, data input to the transmitter is separated by CRLF, and the data before CRLF is transmitted.

For example, entering Hello<Enter> on the transmitting terminal results in Hello being output on the receiving terminal.

[Sending side]

Hello  <- Input

[Receiving side]

Hello  <- Output

Continuous input strings are split and sent in chunks of 80 bytes. Data up to the trigger character should normally be 80 bytes or less.

All terminals are considered child devices, and the transmitted content is broadcast. Communication with all terminals is possible, but the destination cannot be specified. Both ASCII characters and binary data can be sent.

Relay supports up to 3 hops. By default, relay is disabled.

Distinction between Parent and Child Devices

Transparent mode does not distinguish between parent and child devices.

If application ID and frequency channel are the same, data entered into any terminal is sent to other terminals.

Network configuration image

Network configuration image

Identification of Sender

Transparent mode cannot identify the sender.

To identify sender, sender information must be included in data input to the transmitter.

Transmission Trigger

Transmission trigger must be considered, as data is divided and transmitted wirelessly packet by packet.

Therefore, the following transmission triggers must be taken into account:

  • When a timeout after data input is reached
  • When the input data reaches the minimum data size
  • When the transmission trigger character is received

Transmission trigger settings can be specified from the interactive mode k: Transmission Trigger item.

Example Setting

When setting the transmission trigger character to LF, minimum data size to 8 bytes, and timeout to 30 ms, set as follows:

 m: set UART mode (D)
 k: set Tx Trigger (sep=0x0a, min_bytes=8 dly=30[ms])
 o: set option bits (0x00000100)

3.5.1.2.5 - Serial Communication App Header Transparent Mode

Mode that adds headers only to the received output
Header Transparent Mode adds auxiliary information only to the output on the receiving side.

Overview

Enabled by default.

When arbitrary data is input to the transmitting terminal, the receiving terminal outputs data with auxiliary information in a specific format.

Transmitting side inputReceiving side output
Any dataAny data + auxiliary info

By default, data input on the transmitting side is separated by CRLF and data before CRLF is sent.

For example, entering Hello<Enter> on the transmitting side results in output Hello with auxiliary info on the receiving side. The transmitting side also outputs a message indicating transmission completion.

[Transmitting side]

Hello  <- input
;U;00004;219;0x820163B2;000;000;0,1,Hel...;6E;  <- output

[Receiving side]

;U;00003;000;0x820163B2;255;000;Hello;42;  <- output

The auxiliary information output by the receiving side includes the source address, received signal strength, checksum, etc. The format of the auxiliary information can be customized.

Distinction between Parent and Child Devices

Header Transparent Mode does not distinguish between parent and child devices.

If the Application ID and frequency channel are the same, data input to any terminal is sent to other terminals.

Network configuration image

Network configuration image

Identification of Source

The header on the received data includes the logical device ID and serial ID of the sender.

Output Format on Receiving Side

The output format is represented as semicolon (;) separated fields.

[Example output in default state]

;U;00777;120;0x81025A17;120;013;HELLO;79;

This output can be interpreted as follows.

DataDescriptionValue
UcharFixed valueU
00777uint16Timestamp at output777 seconds
120uint8Source logical device ID120 ID-less child device
0x81025A17uint32Source extended address81025A17
120uint8LQI (link quality indicator)120/255
013uint8Source sequence number13
HELLO[uint8]Input dataHELLO
79uint8XOR checksum0x79

Customization by Header Format

The output format on the receiving side follows the header format.

Changing the header format customizes the content of the auxiliary information output and the checksum calculation range.

The header format can be changed via the interactive mode command h: set header format.

Simplest Format

The simplest header format is *\n. It outputs the received data with CRLF line endings.

 h: set header format [*\n]

When sending HELLO in this case, it behaves as follows.

[Receiving side]

HELLO<CR><LF> or HELLO<LF>

[Transmitting side]

HELLO<CR><LF>

Special Characters in Header Format

You can customize the output by including the following special characters in the header format.

General
Description
*Received data
&hlArbitrary ASCII character (e.g., &20 is space)
<Start position for checksum calculation (default is start of string)
>End position for checksum calculation (only from v1.4.6)
Characters following \ (backslash)
Description
\nCRLF (0x0D 0x0A)
\tTAB
\**
\%%
\<<
\>>
\&&
Characters following %
DescriptionLengthData format
%ASource address (32bit)8 charsHexadecimal
%aSource address (32bit)10 charsHexadecimal
%ISource logical address (8bit)2 charsHexadecimal
%iSource logical address (8bit)3 charsDecimal
%TCurrent system time (seconds)4 charsHexadecimal
%tCurrent system time (seconds)5 charsDecimal
%SSource sequence number (hex)2 charsHexadecimal
%sSource sequence number (hex)3 charsHexadecimal
%QReceived signal strength2 charsHexadecimal
%qReceived signal strength3 charsDecimal
%XChecksum2 charsHexadecimal
%xChecksum3 charsDecimal

Checksum Calculation

The checksum is calculated by XOR (exclusive OR) from the start of the data or from the position indicated by < in the header format up to just before %X or %x.

Example in Default State

The default header format is ;U;%t;%i;0x%A;%q;%s;<*;%X;\n, where the checksum calculation range is *;.

That is, when sending HELLO, the binary data HELLO; is targeted, resulting in checksum 0x79.

[Verification code in Python]

from functools import reduce

def main():
    data = "HELLO;"
    checksum = reduce(lambda x, y: x ^ y, data.encode("ascii"))
    print(f"{data} -> {hex(checksum)}")

if __name__ == "__main__":
   main()  # HELLO; -> 0x79

Other Examples

For example, consider the header format ;%I;*;%X.

Since < is not specified, the checksum calculation range is ;%I;*;.

That is, when sending HELLO, the binary data ;000;HELLO; is targeted, resulting in checksum 0x49.

[Verification code in Python]

from functools import reduce

def main():
    data = ";000;HELLO;"
    checksum = reduce(lambda x, y: x ^ y, data.encode("ascii"))
    print(f"{data} -> {hex(checksum)}")

if __name__ == "__main__":
   main()  # ;000;HELLO; -> 0x49

Transmission Trigger

There is no format on the transmitting side input, but data is split and transmitted packet by packet.

Therefore, the following transmission triggers must be considered.

  • When timeout after data input occurs
  • When input data reaches the minimum data size
  • When a transmission trigger character is received

Transmission trigger settings are specified via the interactive mode k: set transmission trigger item.

Example Setting

To set the transmission trigger character to LF, minimum data size to 8 bytes, and timeout to 30 ms, use the following settings.

 m: set UART mode (E)
 k: set Tx Trigger (sep=0x0a, min_bytes=8 dly=30[ms])
 o: set option bits (0x00000100)

3.5.1.3 - Interactive Mode (Serial Communication App)

Configuration via Interactive Mode
You can configure advanced settings of the app via Interactive Mode.

This section describes features specific to the serial communication app (App_Uart). For common functions, refer to the TWELITE APPS Manual Top Page.

Display Example

[CONFIG MENU/App_Uart:0/v1-05-1/SID=8300051A]
a: (0x67720103) Application ID [HEX:32bit]
i: (       120) Device ID [1-100,etc]
c: (18        ) Channel(s)
x: (      0x03) RF Power/Retransmissions [HEX:8bit]
b: (115200,8N1) UART Baud Alt. [XXXXX]
o: (0x00000100) Option bits [HEX:32bit]
r: (      0x00) Role [0-3,11-13]
l: (         1) LayerTree repeat layer [1-63]
m: (E         ) UART mode [ABCDE]
t: (    0x0D0A) Tx trigger character [XX,XXYY]
u: (         0) Minimum data size [0,1-80]
T: (         0) Timeout [0,10-200 msec]
h: (;U;%t;%i;0x%A;%q;%s;<*;%X;\n) Header format / Handle name
C: (         0) Encryption [0,1]
K: (*CRYPT_KEY_HERE*) Encryption key [16chrs]

 [ESC]:Exit [!]:Reset System [*]:Extr Menu [:]:AppSel

Commands

ParameterDefaultRemarks
aApplication ID0x6772010332bit
iLogical Device ID120Parent 121, Child 1-100, No ID Child 120
cFrequency Channel1811-26
xTX Power & Retransmit Count0x03
Retransmit Count01-9 times, 0 disables
TX Power30-3
bUART Alternate Setting115200,`8N1Enable with BPS pin
oOption Bits0x00000000Other detailed settings
rRole0Normal 0, Relay Child 1-3, Other
lLayerTree Relay Layer0x01
mCommunication ModeEA/B/C/D/E
tTX Trigger Characters0x0D0AASCII code of trigger characters
uMinimum Data Size0Disabled 0, 1-80
TTimeout0Disabled 0, 10-200ms
hHeader Format / Handle NameDetails
Header FormatWhen using Header Transmission Mode
Handle NameWhen using Chat Mode
CEncryption0Disabled 0, AES128bit 1
KEncryption Key*CRYPT_KEY_HERE*16 characters

Each command is described in detail below.

a: Application ID

All devices participating in communication must use the same value. This logically separates networks.

i: Logical Device ID

Set this value if it is necessary to distinguish between multiple child devices.

If no distinction is needed or possible, set it to 120. If distinction is required, use any value between 1 and 100 for child devices, and use 121 for parent devices.

c: Frequency Channel

All devices participating in communication must use the same value. This physically separates networks.

x: TX Power & Retransmit Count

Specifies the RF transmission power and the number of retransmissions in Transparent Mode and Header Transmission Mode.

b: UART Alternate Setting

Overrides the default 38400bps alternate baud rate used when booting with the BPS pin connected to GND.

Select from: 9600 / 19200 / 38400 / 57600 / 115200 / 230400.

o: Option Bits

Specify a 32-bit value. Each bit enables a corresponding setting.

BitSetting ItemDefaultABCDE
0x00000001Disable Internal Pull-up of M30️⃣
0x00000100Enable TX Trigger1️⃣
0x00000200Prioritize New Input Stream0️⃣
0x00001000Suppress Response Message0️⃣
0x00004000Relax Duplicate Checker0️⃣
0x00010000Force Apply Alternate Baud Rate0️⃣
0x00020000Simultaneous Output to Sub Port0️⃣
0x00040000Switch Primary Port0️⃣
0x01000000Disable LED0️⃣
0x02000000Disable LED in Standby0️⃣

r: Role

Valid for child devices only. Select one of the following. Normally, use a transmission mode that does not rely on the network layer (LayerTree).

Transmission Modes Not Using the Network Layer

  • 0: Default (Parent or Child)
  • 13: Repeater Child (set Logical Device ID to 1100 or 120). The value indicates the maximum number of relay hops. Duplicated packets may occur depending on placement and number of repeaters.

Transmission Modes Using the Network Layer

Only supported in Header Transmission Mode.

  • 11: Parent
  • 12: Repeater
  • 13: Child

l: LayerTree Relay Layer

Specifies the relay layer number. A repeater attempts to connect to parent or repeater devices with higher relay layers (smaller values). Valid only when Role is set to 12.

m: Communication Mode

  • A: Format Mode (ASCII)
  • B: Format Mode (Binary)
  • C: Chat Mode
  • D: Transparent Mode
  • E: Header Transmission Mode

t: TX Trigger Characters

In Transparent and Header Transmission modes, entering these characters triggers transmission of a packet.

If Minimum Data Size is specified, the characters will be ignored until that size is reached.

u: Minimum Data Size

Specifies the minimum size of data to be handled continuously. TX Trigger Characters are ignored until this size is met.

In Interactive Mode, specify a number between 180 as byte count. Set to 0 to disable. The default is disabled.

T: Timeout

Time to wait from the last input before transmitting a packet.

In Interactive Mode, specify a value between 10200 in milliseconds. Set to 0 to disable. The default is disabled.

h: Header Format / Handle Name

Specifies the header format for Header Transmission Mode, or the handle name for Chat Mode.

Header (Header Transmission Mode)

Specify the Header Format Syntax for use in Header Transmission Mode.

Handle Name (Chat Mode)

Specify the handle name to display on the receiving device.

Up to 23 characters. This consumes part of the data transmission area (80 bytes).

C: Encryption

Specifies whether to enable encryption.

To enable AES128-bit encryption, set this to 1.

K: Encryption Key

Specify a 16-character encryption key when encryption is enabled.

Option Bits Details

This section describes each setting associated with the bits of the Option Bits value.

00000001: Disable Internal Pull-up of M3

Disables the internal pull-up resistor of the M3 pin used for sleep configuration on TWELITE DIP.

00000100: Enable TX Trigger

Enables the TX Trigger setting in Transparent or Header Transmission Mode.

00000200: Prioritize New Input Stream

In Format Mode (ASCII/Binary), Transparent Mode, and Header Transmission Mode, if multiple input streams are received before the previous transmission is complete, the newer input is prioritized.

00001000: Suppress Response Message

In Format Mode (ASCII/Binary) and Header Transmission Mode, suppresses the response message after transmission completes.

00004000: Relax Duplicate Checker

Relaxes the duplicate check conditions on the receiver side.

00010000: Force Apply Alternate Setting

Applies the UART Alternate Setting even if the BPS pin is not pulled low at boot.

00020000: Simultaneous Output to Sub Port

Also outputs serial TX data to the secondary TX_SUB port.

00040000: Switch Primary Port

Switches the serial I/O between the main TX/RX and the sub TX_SUB/RX_SUB ports.

About Repeater Function

When the communication range is insufficient or obstructed, using a repeater can be effective.

A repeater device retransmits packets it receives to other devices.

01000000: Disable LED

Disables the LED on TWELITE STICK and MONOSTICK.

02000000: Disable LED in Standby

Disables the LED on TWELITE STICK and MONOSTICK while in standby.

Configuring Repeater Function

Normally, enter Interactive Mode and change the Role to a value between 1 and 3. The default is 0, which does not enable the repeater function.

r: set Role (0x0)

The values 1 to 3 indicate the maximum number of relay hops. For example, setting it to 3 allows up to 3 hops.

This setting is only valid for child devices, not for parent devices.

Example Configuration

The following network configuration shows an example where the Role of red devices is set to 0, and that of blue devices is set to 3.

Example of relaying via Role setting

Example of relaying via Role setting

By adding more red devices, communication with up to three relay hops between them can be established.

Example of adding transmitters and receivers

Example of adding transmitters and receivers

3.5.1.4 - Notes on Communication in Serial Communication App

Precautions for stable communication
Precautions for achieving stable communication.

UART Data Input and Output

4KB buffers are allocated for UART input and output. When outputting two UART lines, 2KB is used for input and output buffers for each line.

In format mode and chat mode, it is rarely necessary to be aware of buffer sizes, but in header transparent mode and transparent mode when continuously inputting streams, or even in format mode when inputting many streams at once, it is necessary to be aware of the buffer size limits. On the output side, if a slow baud rate is set, the output of data received wirelessly may not keep up.

Data beyond the buffer limits is not protected at the boundary, causing data loss. Especially on the input side, consider referring to the flow control pins described below.

UART Flow Control

Input flow control is implemented to behave like the RTS pin. The pin used is PWM1 (DIO5), targeting the main UART port. When input is not accepted, the state is High; when input is accepted, the state is Low. Output flow control is not supported. Receiving devices should ensure sufficient baud rate and processing speed.

  • After power-on or reset, the pin is High. It becomes Low once UART is initialized.
  • When the UART input buffer exceeds 7/8 full, the pin goes High; it goes Low when below that threshold.
  • In transparent mode, the pin is High during packet transmission.

Countermeasures for Wireless Communication Errors

If data loss occurs on the receiving side, increase the number of wireless retransmissions.

Increasing the number of additional packets sent can improve the success rate of reception.

The number of retransmissions can be set in Interactive Mode (x: set RF Conf).

3.5.1.5 - Custom Default Feature of Serial Communication App

Creating firmware with changed default settings
With the custom default feature, you can change the default parameters included in the firmware.

For example, if you create firmware that changes the baud rate from 115200bps to 9600bps, you can use it at 9600bps from the start.

Configuration Procedure

1. Apply Settings

Change the settings in Interactive Mode and press S to save.

2. Download Settings

Prepare software that can download data using the xmodem protocol.

While still in Interactive Mode (before selecting items), request xmodem download.

If the download succeeds, a 128-byte file is generated (may be smaller depending on xmodem implementation).

3. Creating Custom Binary

Concatenate the downloaded file to the end of the firmware binary file to create a custom binary.

Use command line tools or general file concatenation tools for concatenation.

Example

Example assuming downloaded xmodem file is conf.bin, original binary file is App_Uart_BLUE_L1305_V1-4-X.bin, and custom binary to create is App_Uart_custom_V1-4-X.bin.

【Windows】

copy App_Uart_BLUE_L1305_V1-4-X.bin App_Uart_custom_V1-4-X.bin
type conf.bin >> App_Uart_custom_V1-4-X.bin

【macOS / Linux】


cat App_Uart_BLUE_L1305_V1-4-X.bin conf.bin > App_Uart_custom_V1-4-X.bin

4. Writing Custom Binary

Write the concatenated custom binary to TWELITE.

3.5.2 - Serial Communication App Manual

v1.4.7 BLUE/RED Stable version

Download

To install the Serial Communication App (App_Uart), install the TWELITE STAGE SDK and rewrite using the TWELITE STAGE App.

3.5.2.1 - Pin Assignments of Serial Communication App

Functions of pins used by the Serial Communication App

TWELITE / TWELITE DIP

The functions of pins used by the Serial Communication App are represented using the pin names from the Super Simple! Standard App Pins shown in the figure below.

Super Simple! Standard App Pin Assignment Table

Super Simple! Standard App Pin Assignment Table

Serial CommunicationSuper Simple! StandardFunction
VCC GNDVCC GNDPower Input
TX RXTX RXSerial Input and Output
TX_SUB RX_SUBSCL SDASerial Sub Input and Output
RTSPWM1Serial Input Permission
M1M1Parent/Child Selection
M2M2Adding Relay Function to Child
M3M3Sleep
EX1AI2Overwriting Operation Mode
BPSBPSEnabling Alternative Baud Rate Setting
RSTRSTReset Input

Power Input

Connect a 3.3V (2.0-3.6V) power supply to VCC/GND.

Serial Input and Output

TX/RX are used for transmitting and receiving serial communication (UART).

Serial Sub Input and Output

TX_SUB (SCL) / RX_SUB (SDA) can be used as sub-ports for serial input and output.

Serial Input Permission

When RTS (PWM1) is at Low level, it indicates that serial input to RX is being accepted.

Parent/Child Selection

Connecting M1 to GND sets the device as a parent, while leaving it open or connecting to VCC sets it as a child.

Adding Relay Function to Child

When M2 is connected to GND in child mode, relay functionality can be added.

Sleep

Connecting M3 to GND puts the device into sleep mode.

Overwriting Operation Mode

By connecting EX1 to GND at startup, the operation mode can be overwritten to format mode (binary).

Enabling Alternative Baud Rate Setting

Connecting BPS to GND enables the alternative baud rate setting specified in interactive mode.

Reset Input

By connecting a push button between RST and GND, a reset button can be implemented. RST has an internal pull-up resistor.

TWELITE UART

The functions of pins used by the Serial Communication App are represented using the pin names of the 7P interface printed on the board (② in the figure below).

Board Antenna Type

Board Antenna Type

Coaxial Connector Type

Coaxial Connector Type

SilkscreenFunction
VCC GNDPower Input
TXD RXDSerial Input and Output
SETOverwriting Operation Mode
RSTReset Input

Power Input

Connect a 3.3V (2.0-3.6V) power supply to VCC/GND.

Serial Input and Output

TX/RX are used for transmitting and receiving serial communication (UART).

Overwriting Operation Mode

By connecting SET to GND at startup, the operation mode can be overwritten to format mode (ASCII).

Reset Input

By connecting a push button between RST and GND, a reset button can be implemented. RST has an internal pull-up resistor.

3.5.2.2 - Communication Modes of Serial Communication App

Explanation of each communication mode
The Serial Communication App (App_Uart) has five communication modes.

List of Communication Modes

Each mode is switched by Interactive Mode (some modes can be set via pin input).

IDMode
AFormat Mode (ASCII)
BFormat Mode (Binary)
CChat Mode
DTransparent Mode
EHeader Transparent Mode

Initial state is Header Transparent Mode.

A: Format Mode (ASCII)

When data is input to the transmitting terminal according to a specific format, the receiving terminal outputs data according to the same specific format.

Data represented in hexadecimal is expressed as ASCII strings.

Input on Transmitting SideOutput on Receiving Side
Simple/Extended format dataSimple/Extended format data

In TWELITE UART, this mode is enabled when started with the SET pin connected to GND.

There are two formats to represent data.

  • Simple format: Uses only logical device ID. Super simple! Compatible with the standard app’s UART transmission function.
  • Extended format: Uses transmission options such as serial ID and retransmission count in addition to logical device ID.

For example, 5-byte binary data 0x48 0x45 0x4C 0x4C 0x4F can be sent using the simple format as follows.

[Transmitting Side]

:000148454C4C4F8B  <- Input
:DBA1800103  <- Output

[Receiving Side]

:780148454C4C4F13  <- Output

In format mode, settings such as application ID can be dynamically applied not only by Interactive Mode but also by commands via UART (ASCII format).

B: Format Mode (Binary)

When data is input to the transmitting terminal according to a specific format, the receiving terminal outputs data according to the same specific format.

Data represented in hexadecimal is expressed in binary format as is.

Input on Transmitting SideOutput on Receiving Side
Simple/Extended format dataSimple/Extended format data

In TWELITE / TWELITE DIP, this mode is enabled when started with the EX1 pin connected to GND.

Like Format Mode (ASCII), there are two formats to represent data.

For example, 5-byte binary data 0x48 0x45 0x4C 0x4C 0x4F can be sent using the simple format as follows.

[Transmitting Side]

0xA5 0x5A 0x00 0x07 0x00 0x01 0x48 0x45 0x4C 0x4C 0x4F 0x43 0x04    <- Input
0xA5 0x5A 0x00 0x04 0xDB 0xA1 0x80 0x01 0xFB 0x04  <- Output

[Receiving Side]

0xA5 0x5A 0x00 0x07 0x78 0x01 0x48 0x45 0x4C 0x4C 0x4F 0x3B 0x04  <- Output

In format mode, settings such as application ID can be dynamically applied not only by Interactive Mode but also by commands via UART (binary format).

C: Chat Mode

Enables text chat.

Input on Transmitting SideOutput on Receiving Side
Any stringAuxiliary information + any string

Displays prompt and echoes back (outputs the entered characters). All terminals act as child devices and perform broadcast communication.

For example, when a terminal sends the string Hello to other terminals, the behavior is as follows.

[Transmitting Side]

810A4778:0> Hello  <- Input
810A4778:1>  <- Output

[Receiving Side]

[810A4778:0] Hello  <- Output
82018CA0:0>  <- Output

In the above example, the prompt shows the serial ID, but you can also use any handle name.

D: Transparent Mode

When arbitrary data is input to the transmitting terminal, the receiving terminal outputs the received data as is.

Input on Transmitting SideOutput on Receiving Side
Any dataAny data

Since no format is required, existing UART communication can be easily wirelessized.

On the other hand, data boundaries become ambiguous, and the receiving output cannot identify the sender, which are drawbacks.

By default, data input to the transmitting side is separated by CRLF, and data before CRLF is sent.

For example, when Hello<Enter> is input on the transmitting terminal, the receiving terminal outputs Hello as is.

[Transmitting Side]

Hello  <- Input

[Receiving Side]

Hello  <- Output

E: Header Transparent Mode

When arbitrary data is input to the transmitting terminal, the receiving terminal outputs the received content with auxiliary information added in a specific format.

Input on Transmitting SideOutput on Receiving Side
Any dataAny data + auxiliary information

By default, data input to the transmitting side is separated by CRLF, and data before CRLF is sent.

For example, when Hello<Enter> is input on the transmitting terminal, the receiving terminal outputs Hello in a format including auxiliary information. The transmitting terminal also outputs a format that conveys a transmission completion message.

[Transmitting Side]

Hello  <- Input
;U;00004;219;0x820163B2;000;000;0,1,Hel...;6E;  <- Output

[Receiving Side]

;U;00003;000;0x820163B2;255;000;Hello;42;  <- Output

The auxiliary information output by the receiving side includes the sender’s address, received signal strength, checksum, etc. The format of auxiliary information can be customized.

3.5.2.2.1 - Serial Communication App Format Mode (ASCII)

Mode that adds headers to both transmitted and received outputs (ASCII format)
Format mode adds headers to both transmitted and received outputs. In ASCII format, data is represented as hexadecimal strings.
Example network configuration with format mode

Overview

When data formatted in a specific manner is input on the transmitting side, the receiving side outputs data formatted in the same manner.

Data is represented as hexadecimal ASCII strings.

Transmitting Side InputReceiving Side Output
Simple/Extended format dataSimple/Extended format data
  • In TWELITE UART, format mode (ASCII) is enabled by starting up with the SET pin connected to GND.
  • In TWELITE / TWELITE DIP, format mode (binary) is enabled by starting up with the EX1 pin connected to GND.

There are two types of formats that can be handled.

  • Simple format: uses only the Logical Device ID. Extremely Simple! Compatible with the UART transmission function of the standard app.
  • Extended format: uses Logical Device ID plus transmission options such as Serial ID and retry count.

For example, 5-byte binary data 0x48 0x45 0x4C 0x4C 0x4F can be sent using the simple format as follows.

[Sending side]

:000148454C4C4F8B  <- Input
:DBA1800103  <- Output

[Receiving side]

:780148454C4C4F13  <- Output

Basic Format

When sending data sequences expressed in basic or extended formats, they are converted to ASCII strings (0-9, A-F).

The format is extremely simple! It starts with : and ends with CRLF, just like the output of the standard app (App_Twelite) or the parent device output of the parent/repeater app (App_Wings).

HeaderPayloadChecksumFooter
:Repeated 00-FFLRC8 of payloadCRLF
  • All ASCII characters
  • Starts with : (0x3A)
  • Checksum is the two’s complement of the sum of the payload
  • Ends with CRLF (\r\n/0x0D 0x0A)
  • Big-endian

For example, binary data 0x00 0x11 0x22 0x33 0xAA 0xBB 0xCC is expressed as follows.

:00112233AABBCC69<CR><LF>

Distinguishing Parent and Child Devices

Format mode distinguishes between parent and child devices.

The Application ID and frequency channel must be matched between parent and child devices.

Source Identification

Format mode allows identifying the source from the received data.

The simple format uses the Logical Device ID, and the extended format uses the Logical Device ID plus the extended address.

Simple Format

When using the simple format of format mode, follow the format below.

Transmitting Side Input

#DataDescriptionNotes
charHeaderOnly :
0uint8Destination Logical Device IDParent 0x00, child 0x01-0x64, all children 0x78
1uint8Command numberAny value less than 0x80
2[uint8]Arbitrary dataByte sequence of length (N) (recommended (N \leqq 80))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Receiving Side Output

#DataDescriptionNotes
charHeaderOnly :
0uint8Source Logical Device IDParent 0x00, child 0x01-0x64, unset child 0x78
1uint8Command numberValue less than 0x80 specified by the sender
2[uint8]Arbitrary dataByte sequence of length (N)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Transmitting Side Output (Response Message)

#DataDescriptionNotes
charHeaderOnly :
0uint8Source Logical Device IDOnly 0xDB: indicates itself
1uint8Command numberOnly 0xA1
2uint8Response IDContinuation number in the range 128-255 (0x80-0xFF)
3uint8ResultSuccess 1, failure 0
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Usage

An example of sending byte sequence 0x11 0x22 0x33 0xAA 0xBB 0xCC from the parent to all children is shown.

[Sending side: Parent]

:7801112233AABBCCF0<CR><LF>  <- Input
:DBA1800103<CR><LF>  <- Output

The trailing 0xF0 is the checksum: the two’s complement of the sum from 0x78 to 0xCC (LSB 8 bits).

[Receiving side: All children]

:0001112233AABBCC68<CR><LF>  <- Output

The trailing 0x68 is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

Extended Format

When using the extended format of format mode, follow the format below.

Transmitting Side Input

When specifying destination using Logical Device ID

#DataDescriptionNotes
charHeaderOnly :
0uint8Destination Logical Device IDParent 0x00, child 0x01-0x64, all children 0x78
1uint8Command numberOnly 0xA0
2uint8Response IDAny value
3[uint8]OptionsOption list of length (N) (Details of option list)
3+(N)[uint8]Arbitrary dataByte sequence of length (M) (recommended (M \leqq 80))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

When specifying destination using Extended Address

#DataDescriptionNotes
charHeaderOnly :
0uint8Extended Address SpecifierOnly 0x80
1uint8Command numberOnly 0xA0
2uint8Response IDAny value
3uint32Destination Extended AddressSerial ID with 0x8 added at the front
7[uint8]OptionsOption list of length (N) (Details of option list)
7+(N)[uint8]Arbitrary dataByte sequence of length (M) (recommended (M \leqq 80))
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Details of Option List

In the extended format, you can specify fine settings by specifying the option list.

The option list is represented by repeating option IDs and their arguments. The end is 0xFF.

IDArgumentDefaultDescription
0x01NoneDisabledEnable MAC ACK
0x02uint80x00Enable application retry
0x03uint160x0000Minimum initial transmission delay
0x04uint160x0000Maximum initial transmission delay
0x05uint1610Application retry interval
0x06NoneDisabledAllow parallel requests
0x07NoneDisabledDisable response messages
0x08NoneDisabledSleep after transmission
0x01: Enable MAC ACK

Enables MAC layer ACK (acknowledgment).

Not suitable for frequent data transmission, but can improve reliability.

0x02: Enable Application Retry

When using MAC ACK, specify 0x00-0x0F. Retries 0-16 times respectively until the transmission succeeds.

When not using MAC ACK, specify 0x81-0x8F. Always retries 1-16 times.

Response messages are output after all retries are completed.

0x03: Minimum Initial Transmission Delay

Specifies the minimum delay before the first transmission in milliseconds.

0x04: Maximum Initial Transmission Delay

Specifies the maximum delay before the first transmission in milliseconds.

0x05: Application Retry Interval

Specifies the retry interval in milliseconds when application retry is enabled.

0x06: Allow Parallel Requests

Allows parallel requests.

When allowed, the next request can be accepted without blocking until the current request completes.

For example, if three requests with a 0.5-second delay are input consecutively, normally they are processed sequentially at 0.5s, 1.0s, and 1.5s. When parallel requests are allowed, they are processed in no particular order after 0.5s. Note that it cannot be used when packet fragmentation is required.

0x07: Disable Response Messages

Disables the response messages output when data is input on the transmitting side.

0x08: Sleep After Transmission

Immediately puts the device to sleep after transmission.

When RX detects a rising edge, it wakes up from sleep. Please input any 1 byte of data.

After waking up, UART initialization completes and input is accepted.

Receiving Side Output

#DataDescriptionNotes
charHeaderOnly :
0uint8Source Logical Device IDParent 0x00, child 0x01-0x64, unset child 0x78
1uint8Command numberOnly 0xA0
2uint8Response IDValue specified by the sender
3uint32Source Extended AddressSerial ID with 0x8 added at the front
7uint32Destination Extended Address0xFFFFFFFF if using Logical Device ID
11uint8LQIRadio communication quality at reception
12uint16Length of following byte sequenceNumber of bytes (M)
14[uint8]Arbitrary dataByte sequence of length (M)
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Transmitting Side Output (Response Message)

#DataDescriptionNotes
charHeaderOnly :
0uint8Source Logical Device IDOnly 0xDB: indicates itself
1uint8Command numberOnly 0xA1
2uint8Response IDValue specified at input
3uint8ResultSuccess 1, failure 0
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

Example Usage

An example of sending byte sequence 0x11 0x22 0x33 0xAA 0xBB 0xCC from the parent to a child is shown.

Example specifying Logical Device ID

An example sending from the parent to the child with Logical Device ID 0x42.

  • Response ID is 0x01
  • No options
  • Parent’s extended address is 0x81000000 (Serial ID 0x1000000)

[Sending side: Parent]

:42A001FF112233AABBCC87<CR><LF>  <- Input
:DBA1010182<CR><LF>  <- Output

The trailing 0x87 is the checksum: the two’s complement of the sum from 0x42 to 0xCC (LSB 8 bits).

[Receiving side: Child]

:00A00181000000FFFFFFFFC80006112233AABBCC7D<CR><LF>  <- Output

The trailing 0x7D is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

Example specifying Extended Address

An example sending from the parent to the child with extended address 0x81000001 (Serial ID 0x1000001).

  • Response ID is 0x01
  • No options
  • Parent’s extended address is 0x81000000 (Serial ID 0x1000000)

[Sending side: Parent]

:80A00181000001FF112233AABBCCC7<CR><LF>  <- Input
:DBA1010182<CR><LF>  <- Output

The trailing 0xC7 is the checksum: the two’s complement of the sum from 0x80 to 0xCC (LSB 8 bits).

[Receiving side: Child]

:00A0018100000081000001C80006112233AABBCCF7<CR><LF>  <- Output

The trailing 0xF7 is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

Example using MAC ACK

An example sending from the parent to the child with Logical Device ID 0x42 using MAC ACK.

  • Response ID is 0x01
  • Option 0x01: Enable MAC ACK specified
  • Parent’s extended address is 0x81000000 (Serial ID 0x1000000)

[Sending side: Parent]

:42A00101FF112233AABBCC86<CR><LF>  <- Input
:DBA1010182<CR><LF>  <- Output

The trailing 0x86 is the checksum: the two’s complement of the sum from 0x42 to 0xCC (LSB 8 bits).

[Receiving side: Child]

:00A00181000000FFFFFFFFC80006112233AABBCC7D<CR><LF>  <- Output

The trailing 0x7D is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

Example using delay

An example sending from the parent to the child with Logical Device ID 0x42 with a 768ms delay.

[Sending side: Parent]

:42A001030300FF112233AABBCC81<CR><LF>  <- Input
:DBA1010182<CR><LF>  <- Output

The trailing 0x81 is the checksum: the two’s complement of the sum from 0x42 to 0xCC (LSB 8 bits).

[Receiving side: Child]

:00A00181000000FFFFFFFFC80006112233AABBCC7D<CR><LF>  <- Output

The trailing 0x7D is the checksum: the two’s complement of the sum from 0x00 to 0xCC (LSB 8 bits).

0xDB Command

Instead of setting interactive mode, you can operate and configure the module by inputting the 0xDB command from UART.

3.5.2.2.1.1 - 0xDB Command in Serial Communication App Format Mode (ASCII)

Setting functions using the 0xDB command in format mode (ASCII) without using Interactive Mode
In format mode, dynamic configuration can be performed from devices connected via UART by using the 0xDB command instead of Interactive Mode.

Input Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB itself
1uint8Command numberSelected from values below
2[uint8]ParameterOptional length N bytes representing setting values
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

List of Command Numbers

Function
0xF0Enable ACK
0xF1Get Device Info
0xF2Apply Device Settings
0xF3Get Device Settings
0xF8Device Control
0xFDErase Device Settings
0xFESave Device Settings
0xFFReset Device

0xF0: Enable ACK

Requests an ACK response.

No parameters.

Response Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF0
2uint8DataOnly 0x01
uint8Checksum0x34: LRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xF1: Get Device Info

Displays address and other information. Also output at startup.

No parameters.

Response Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF1
2uint32Default Application ID67720103
6uint32Version numberFor 1.4.7, 00010407
10uint8Logical device ID
11uint32Serial ID
15uint8Silent mode statusEnabled 1, Disabled 0
16uint8Network statusUP 1, DOWN 0
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xF2: Apply Device Settings

Applies the settings.

Response Format

On Success
#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF3
2[uint8]Settings contentLength N repeated pairs of identifier and data
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')
On Failure
#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF3
2uint8ErrorOnly 0xFF
uint8Checksum0x33: LRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xF3: Get Device Settings

Gets the settings.

Response Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF3
2[uint8]Settings contentRepeated pairs of identifier and data
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xF8: Device Control

If silent mode was enabled at startup, this disables it.

Response Format

#DataContentRemarks
charHeader: only
0uint8Destination logical device IDOnly 0xDB
1uint8Command numberOnly 0xF8
2uint8DataOnly 0x11
3uint8StatusDisabled 1, Not disabled 0
uint8ChecksumLRC8
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')

0xFD: Erase Device Settings

Resets device settings and resets the device.

No parameters or response.

0xFE: Save Device Settings

Saves applied settings and resets the device.

No parameters or response.

0xFF: Reset Device

Discards applied settings and resets the device.

No parameters or response.

Parameter List (0xF2 / 0xF3)

Parameters for 0xF2: Apply Device Settings and 0xF3: Get Device Settings are represented by repeated pairs of identifiers and data (big endian).

IdentifierDataContent
0x00uint32Application ID
0x01uint32Frequency Channel Mask
0x02uint16Retry Count and Output
0x03uint8Logical Device ID
0x04uint8Role
0x05uint8Relay Layer
0x06uint8Communication Mode
0x07uint32Baud Rate
0x08uint8Parity
0x09uint8Encryption Function
0x0A[uint8]Encryption Key
0x0Cuint16Delimiter Character
0xFFuint8Error

0x00: Application ID

Specifies the application ID.

0x01: Frequency Channel Mask

Specifies the bit mask of frequency channels.

Set bits for channels to be used. For example, to use channel 11, specify 1<<11.

0x02: Retry Count and Output

Specifies the radio transmission output and the number of additional packet transmissions in transparent mode and header-attached transparent mode.

Only the lower 1 byte is used. The upper 4 bits represent the retry count (0-9), and the lower 4 bits represent the transmission output (0-3). For example, 8 retries / output 3 is 0x0083.

0x03: Logical Device ID

Specifies the logical device ID.

0x04: Role

Effective only for slave devices. Specify one of the following values. Normally, select a delivery method that does not use the network layer.

Delivery Methods Without Network Layer

  • 0: Normal designation (parent or child device)
  • 1-3: Relay slave devices (logical device IDs are 1-100 or 120). Numbers 1-3 indicate the maximum relay hop count. This method retransmits up to the maximum relay hops, which may cause duplicate packets depending on relay device placement and count.

Delivery Methods Using Network Layer

  • 11: Parent device
  • 12: Relay device
  • 13: Child device

0x05: Relay Layer

The relay layer number. Relay devices attempt to connect to relay devices or parent devices in upper (smaller value) relay layers. Effective only when Role is set to 12.

0x06: Communication Mode

  • 0: Transparent mode
  • 1: Format mode (ASCII)
  • 2: Format mode (Binary)
  • 3: Chat mode
  • 4: Header-attached transparent mode

0x07: Baud Rate

Specifies the UART baud rate.

0x08: Parity

Specifies the sum of settings in the following combination:

  • Bit
    • 0: 8Bit
    • 8: 7Bit
  • Parity
    • 0: None
    • 1: Odd
    • 2: Even
  • Stop
    • 0: STOP 1
    • 4: STOP 2

For example, 7-E-1 is specified as 8+2+0=10(0xA).

0x09: Encryption Function

Specifies whether encryption is enabled.

  • 0: Disabled
  • 1: AES128bit encryption enabled

0x0A: Encryption Key

Specifies a 16-byte encryption key.

Can store binary sequences that cannot be set in Interactive Mode. This may cause display issues in Interactive Mode.

0x0C: Delimiter Character

Specifies the delimiter character (0x00-0xFF).

Silent Mode

Configuration Method

Perform the following settings in Interactive Mode.

  • Add 80 to r: Role. For example, set to 80 for normal parent or child devices.
  • Set m: UART mode to format mode (A/B).

Operation Check

Check the content of the DB F1 response output immediately after startup.

Disabling Method

Send DB F8 request (ASCII format: :DBF8101D<CR><LF>).

Notes

  • Silent mode cannot be reconfigured.
  • Behavior is undefined if a command is sent while silent mode is enabled.

3.5.2.2.2 - Serial Communication App Format Mode (Binary)

Mode that adds headers to both transmitted and received outputs (binary format)
Format mode adds headers to both transmitted and received outputs. In binary format, data is represented as raw binary.
Example network configuration with format mode

Overview

When data formatted in a specific manner is input on the transmitting side, the receiving side outputs data formatted in the same manner.

Data represented in hexadecimal is output as raw binary.

Transmitting Side InputReceiving Side Output
Simple/Extended Format DataSimple/Extended Format Data
  • On TWELITE UART, format mode (ASCII) is enabled by connecting the SET pin to GND at startup.
  • On TWELITE / TWELITE DIP, format mode (binary) is enabled by connecting the EX1 pin to GND at startup.

There are two types of supported formats.

  • Simple format: uses Logical Device ID only; Extremely Simple! Compatible with UART transmission function of the standard app
  • Extended format: uses Logical Device ID plus options such as Serial ID and retry count

For example, 5 bytes of binary data 0x48 0x45 0x4C 0x4C 0x4F can be transmitted using the simple format as follows.

[Transmitting Side]

A5 5A 80 07 00 01 48 45 4C 4C 4F 43 04    <- Input
A5 5A 80 04 DB A1 80 01 FB 04  <- Output

[Receiving Side]

A5 5A 80 07 78 01 48 45 4C 4C 4F 3B 04  <- Output

Basic Format

When sending data expressed in basic or extended format, handle it as raw binary data.

HeaderLengthPayloadChecksumFooter
A5 5APayload LengthRepeated 00-FFXOR of PayloadEOT
  • All binary
  • Header is 2 bytes: A5 5A
  • Payload length is 2 bytes representing the byte count, OR’ed with 0x8000
  • Checksum is XOR of payload
  • Footer is EOT 0x04 (can be omitted on input)
  • Big-endian

For example, binary data 00 11 22 33 AA BB CC is expressed as follows.

A5 5A 80 07 00 11 22 33 AA BB CC DD 04

Although debugging is troublesome, it offers high efficiency for communication between microcontrollers.

Distinguishing Parent and Child Devices

Format mode distinguishes between parent and child devices.

Parent and child devices must match Application ID and Frequency Channel.

Source Identification

Format mode allows identification of the source from received data.

Simple format uses Logical Device ID, and extended format uses Logical Device ID plus extended address.

Simple Format

When using the simple format of format mode, follow the format below.

Transmitting Side Input

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command NumberAny value less than 0x80
2[uint8]Arbitrary DataByte sequence of length \(N\) (recommended \(N\leqq80\))
uint8ChecksumXOR
uint8FooterEOT (0x04)

Receiving Side Output

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Source Logical Device IDParent 0x00, Child 0x01-0x64, Unset Child 0x78
1uint8Command NumberValue less than 0x80 specified by sender
2[uint8]Arbitrary DataByte sequence of length \(N\)
uint8ChecksumXOR
uint8FooterEOT (0x04)

Transmitting Side Output (Response Message)

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length4
0uint8Source Logical Device IDOnly 0xDB: indicates itself
1uint8Command NumberOnly 0xA1
2uint8Response IDContinuation number in the range 128-255 (0x80-0xFF)
3uint8ResultSuccess 1, Failure 0
uint8ChecksumXOR
uint8FooterEOT (0x04)

Example

Example of sending byte sequence 11 22 33 AA BB CC from parent to all children.

[Transmitting Side: Parent]

A5 5A 80 08 78 01 11 22 33 AA BB CC A4 04  <- Input
A5 5A 80 04 DB A1 80 01 FB 04  <- Output

The last byte 0xA4 is the checksum: XOR from 0x78 to 0xCC.

[Receiving Side: All Children]

A5 5A 80 08 00 01 11 22 33 AA BB CC DC 04  <- Output

The last byte 0xDC is the checksum: XOR from 0x00 to 0xCC.

Extended Format

When using the extended format of format mode, follow the format below.

Transmitting Side Input

When using Logical Device ID as destination

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+\(M\)+3
0uint8Destination Logical Device IDParent 0x00, Child 0x01-0x64, All Children 0x78
1uint8Command NumberOnly 0xA0
2uint8Response IDAny value
3[uint8]OptionsOption list of length \(N\) (Details below)
3+\(N\)[uint8]Arbitrary DataByte sequence of length \(M\) (recommended \(M\leqq80\))
uint8ChecksumXOR
uint8FooterEOT (0x04)

When using Extended Address as destination

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+\(M\)+7
0uint8Extended Address SpecifierOnly 0x80
1uint8Command NumberOnly 0xA0
2uint8Response IDAny value
3uint32Destination Extended AddressSerial ID with 0x8 added at the front
7[uint8]OptionsOption list of length \(N\) (Details below)
7+\(N\)[uint8]Arbitrary DataByte sequence of length \(M\) (recommended \(M\leqq80\))
uint8ChecksumXOR
uint8FooterEOT (0x04)

Details of Option List

In extended format, detailed settings can be specified by providing an option list.

The option list consists of repeated option IDs and arguments. It ends with 0xFF.

IDArgumentDefaultDescription
0x01NoneDisabledEnable MAC ACK
0x02uint80x00Enable Application Retransmission
0x03uint160x0000Minimum Initial Transmission Delay
0x04uint160x0000Maximum Initial Transmission Delay
0x05uint1610Application Retransmission Interval
0x06NoneDisabledAllow Parallel Requests
0x07NoneDisabledDisable Response Messages
0x08NoneDisabledSleep After Transmission
0x01: Enable MAC ACK

Enables MAC layer ACK (acknowledgment).

Not suitable for frequent data transmissions but can improve reliability.

0x02: Enable Application Retransmission

When using MAC ACK, specify 0x00-0x0F. Retransmits 0-16 times until successful.

When not using MAC ACK, specify 0x81-0x8F. Always retransmits 1-16 times.

Response messages are output after all retransmissions are complete.

0x03: Minimum Initial Transmission Delay

Specifies the minimum delay before the first transmission in milliseconds.

0x04: Maximum Initial Transmission Delay

Specifies the maximum delay before the first transmission in milliseconds.

0x05: Application Retransmission Interval

Specifies the interval between application retransmissions in milliseconds.

0x06: Allow Parallel Requests

Allows parallel requests.

When allowed, the next request can be accepted without blocking until the previous request completes.

For example, if three requests each with 0.5 seconds delay are input consecutively, normally they are processed sequentially at 0.5s, 1.0s, and 1.5s. With parallel requests allowed, they are processed in any order after 0.5s. Note that this cannot be used when packet segmentation is required.

0x07: Disable Response Messages

Disables response messages output when data is input on the transmitting side.

0x08: Sleep After Transmission

Immediately puts the device to sleep after transmission.

RX detects rising edge to wake from sleep. Input any 1 byte of data.

After waking, UART initialization completes and input is accepted.

Receiving Side Output

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(M\)+14
0uint8Source Logical Device IDParent 0x00, Child 0x01-0x64, Unset Child 0x78
1uint8Command NumberOnly 0xA0
2uint8Response IDValue specified by sender
3uint32Source Extended AddressSerial ID with 0x8 added at the front
7uint32Destination Extended Address0xFFFFFFFF when using Logical Device ID
11uint8LQIRadio signal quality at reception
12uint16Length of Following BytesByte count \(M\)
14[uint8]Arbitrary DataByte sequence of length \(M\)
uint8ChecksumXOR
uint8FooterEOT (0x04)

Transmitting Side Output (Response Message)

#DataDescriptionNotes
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length4
0uint8Source Logical Device IDOnly 0xDB: indicates itself
1uint8Command NumberOnly 0xA1
2uint8Response IDValue specified on input
3uint8ResultSuccess 1, Failure 0
uint8ChecksumXOR
uint8FooterEOT (0x04)

Examples

Example of sending byte sequence 11 22 33 AA BB CC from parent to child.

Example specifying Logical Device ID

Example of sending from parent to child with Logical Device ID 0x01.

  • Response ID is 0x01
  • No options

[Transmitting Side: Parent]

A5 5A 80 0A 01 A0 01 FF 11 22 33 AA BB CC 82 04  <- Input
A5 5A 80 04 DB A1 01 01 7A 04  <- Output

The last byte 0xC1 is checksum: XOR from 0x42 to 0xCC.

[Receiving Side: Child]

A5 5A 80 14 00 A0 01 82 03 68 41 FF FF FF FF FF 00 06 11 22 33 AA BB CC 2D 04  <- Output

The last byte 0x2D is checksum: XOR from 0x00 to 0xCC.

Example specifying Extended Address

Example of sending from parent to child with Extended Address 0x820163B2 (Serial ID 0x20163B2).

  • Response ID is 0x01
  • No options

[Transmitting Side: Parent]

A5 5A 80 0E 80 A0 01 82 01 63 B2 FF 11 22 33 AA BB CC 51 04  <- Input
A5 5A 80 04 DB A1 01 01 7A 04  <- Output

The last byte 0x51 is checksum: XOR from 0x80 to 0xCC.

[Receiving Side: Child]

A5 5A 80 14 00 A0 01 82 03 68 41 82 01 63 B2 FF 00 06 11 22 33 AA BB CC 7F 04  <- Output

The last byte 0x7F is checksum: XOR from 0x00 to 0xCC.

Example using MAC ACK

Example of sending from parent to child with Logical Device ID 0x01 using MAC ACK.

[Transmitting Side: Parent]

A5 5A 80 0B 01 A0 01 01 FF 11 22 33 AA BB CC 83 04  <- Input
A5 5A 80 04 DB A1 01 01 7A 04  <- Output

The last byte 0x83 is checksum: XOR from 0x01 to 0xCC.

[Receiving Side: Child]

A5 5A 80 14 00 A0 01 82 03 68 41 00 00 01 01 FF 00 06 11 22 33 AA BB CC 2D 04  <- Output

The last byte 0x2D is checksum: XOR from 0x00 to 0xCC.

Example with Delay

Example of sending from parent to child with Logical Device ID 0x01 with 768ms delay.

[Transmitting Side: Parent]

A5 5A 80 0D 01 A0 01 03 03 00 FF 11 22 33 AA BB CC 82 04  <- Input
A5 5A 80 04 DB A1 01 01 7A 04  <- Output

The last byte 0x82 is checksum: XOR from 0x01 to 0xCC.

[Receiving Side: Child]

A5 5A 80 14 00 A0 01 82 03 68 41 FF FF FF FF FF 00 06 11 22 33 AA BB CC 2D 04  <- Output

The last byte 0x2D is checksum: XOR from 0x00 to 0xCC.

0xDB Command

Instead of setting interactive mode, you can operate and configure the module by inputting the 0xDB command from UART.

3.5.2.2.2.1 - 0xDB Command in Serial Communication App Format Mode (Binary)

Setting functions using the 0xDB command in format mode (binary) without using Interactive Mode
In format mode, you can dynamically configure settings from devices connected via UART by using the 0xDB command instead of Interactive Mode.

Input Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Destination Logical Device IDOnly 0xDB indicating itself
1uint8Command NumberSelected from values below
2[uint8]ParameterByte sequence of length \(N\) indicating setting value (optional)
uint8ChecksumXOR
uint8FooterEOT (0x04)

Command Number List

Function
0xF0Enable ACK
0xF1Get Device Info
0xF2Apply Device Settings
0xF3Get Device Settings
0xF8Device Control
0xFDErase Device Settings
0xFESave Device Settings
0xFFReset Device

0xF0: Enable ACK

Requests ACK response.

No parameters.

Response Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length3
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF0
2uint8DataOnly 0x01
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xF1: Get Device Info

Displays information such as address. Also output at startup.

No parameters.

Response Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length17
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF1
2uint32Default Application ID67720103
6uint32Version NumberFor 1.4.7, 00010407
10uint8Logical Device ID
11uint32Serial ID
15uint8Silent Mode StatusEnabled 1, Disabled 0
16uint8Network StatusUP 1, DOWN 0
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xF2: Apply Device Settings

Applies settings.

Response Format

On Success
#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF3
2[uint8]Setting ContentRepeated identifier and data of length \(N\)
uint8ChecksumXOR
uint8FooterEOT (0x04)
On Failure
#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length3
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF3
2uint8ErrorOnly 0xFF
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xF3: Get Device Settings

Retrieves settings.

Response Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length\(N\)+2
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF3
2[uint8]Setting ContentRepeated identifier and data of length \(N\)
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xF8: Device Control

If silent mode was enabled at startup, this disables it.

Response Format

#DataContentRemarks
uint8HeaderOnly 0xA5
uint8HeaderOnly 0x5A
uint16Data Length4
0uint8Destination Logical Device IDOnly 0xDB
1uint8Command NumberOnly 0xF8
2uint8DataOnly 0x11
3uint8StatusDisabled 1, Not Disabled 0
uint8ChecksumXOR
uint8FooterEOT (0x04)

0xFD: Erase Device Settings

Initializes settings and resets the device.

No parameters or response.

0xFE: Save Device Settings

Saves applied settings and resets the device.

No parameters or response.

0xFF: Reset Device

Discards applied settings and resets the device.

No parameters or response.

Parameter List (0xF2/0xF3)

Parameters for 0xF2: Apply Device Settings and 0xF3: Get Device Settings are represented as repeated identifier and data (big endian) pairs.

IdentifierDataContent
0x00uint32Application ID
0x01uint32Frequency Channel Mask
0x02uint16Retry Count and Output
0x03uint8Logical Device ID
0x04uint8Role
0x05uint8Relay Layer
0x06uint8Communication Mode
0x07uint32Baud Rate
0x08uint8Parity
0x09uint8Encryption Function
0x0A[uint8]Encryption Key
0x0Cuint16Delimiter Character
0xFFuint8Error

0x00: Application ID

Specifies the application ID.

0x01: Frequency Channel Mask

Specifies the bit mask of frequency channels.

Set bits for channels to use. For example, to use channel 11, set 1<<11.

0x02: Retry Count and Output

Specifies the radio transmission output and the number of additional packets to send in transparent mode and header-attached transparent mode.

Only the lower 1 byte is used. The upper 4 bits indicate retry count (0-9), and the lower 4 bits indicate transmission output (0-3). For example, 8 retries/output 3 is 0x0083.

0x03: Logical Device ID

Specifies the logical device ID.

0x04: Role

Valid only for child devices. Specify the following values. Usually, select a delivery method without using the network layer.

Delivery Methods Without Using Network Layer

  • 0: Normal designation (parent or child)
  • 1-3: Relay child devices (logical device IDs 1-100 or 120). Numbers 1-3 indicate maximum relay hops. This method repeats retries up to the maximum relay hops, which may cause duplicate packets depending on relay device placement and number.

Delivery Methods Using Network Layer

  • 11: Parent device
  • 12: Relay device
  • 13: Child device

0x05: Relay Layer

The relay layer number. Relay devices attempt to connect to relay devices or parent devices with higher layers (lower values). Effective only when Role is set to 12.

0x06: Communication Mode

  • 0: Transparent mode
  • 1: Format mode (binary)
  • 2: Format mode (binary)
  • 3: Chat mode
  • 4: Header-attached transparent mode

0x07: Baud Rate

Specifies UART baud rate.

0x08: Parity

Specifies the sum of settings in the following combination.

  • Bit
    • 0: 8Bit
    • 8: 7Bit
  • Parity
    • 0: None
    • 1: Odd
    • 2: Even
  • Stop
    • 0: STOP 1
    • 4: STOP 2

For example, 7-E-1 is 8+2+0=10(0xA).

0x09: Encryption Function

Specifies whether encryption is enabled.

  • 0: Disabled
  • 1: AES128bit encryption enabled

0x0A: Encryption Key

Specifies a 16-byte encryption key.

Allows storing binary sequences that cannot be set in Interactive Mode. In this case, the display in Interactive Mode may be disrupted.

0x0C: Delimiter Character

Specifies the delimiter character string (0x00-0xFF).

Silent Mode

Setting Method

Perform the following settings in Interactive Mode.

  • Add 80 to r: Role. For example, for normal parent or child, set 80.
  • Set m: UART mode to format mode (A/B).

Operation Check

Check the content of the DB F1 response output immediately after startup.

Disable Method

Issue a DB F8 request (binary format: A5 5A 80 03 DB F8 10 33 04).

Notes

  • Silent mode cannot be reset.
  • Behavior when sending commands while silent mode is enabled is undefined.

3.5.2.2.3 - Serial Communication App Chat Mode

Mode that displays prompts and performs echo back
Chat mode realizes text chat through prompt display and echo back.

By connecting MONOSTICK to a PC etc., chat can be performed among multiple terminals.

Overview

Enables text chat.

Sending Side InputReceiving Side Output
Any stringAny string + auxiliary information

Displays prompt and echoes back (outputs input characters). All terminals operate as child devices, performing broadcast communication.

For example, when sending the string Hello from one terminal to another, it behaves as follows.

[Sending Side]

810A4778:0> Hello  <- Input
810A4778:1>  <- Output

[Receiving Side]

[810A4778:0] Hello  <- Output
82018CA0:0>  <- Output

Chat mode displays prompt and echoes back (outputs input characters entered by itself).

All terminals are treated as child devices and broadcast their transmitted content. Communication is possible with all terminals but destination cannot be specified. Binary data cannot be sent. Only strings are supported (0x00-0x1F, 0x7F cannot be sent).

Relay supports up to 3 hops. Relay is disabled by default.

Distinction between Parent and Child Devices

Chat mode does not distinguish between parent and child devices.

If the Application ID and frequency channel are the same, data entered in any terminal is sent to other terminals.

Network configuration image

Network configuration image

Identification of Source

The auxiliary information in the received output can identify the sender.

If the Interactive Mode’s h: Header format is blank, the 7-digit serial ID with a leading 0x8 is used as the extended address. For example, the following output indicates the sender’s serial ID was 0x10A4778.

[810A4778:0] Hello

If h: Header format is set to an arbitrary string, it is used as the handle name. Handle name consumes data space in the wireless packet.

Sending Side Input Format

Enter message and newline after prompt.

DataContentRemarks
[char]Message0x00-0x1F, 0x7F not allowed
charCR (0x0D/'\r')Allowed alone
charLF (0x0A/'\n')Allowed alone
810A4778:0> Hello

Receiving Side Output Format

Outputs received message following auxiliary info.

Auxiliary information includes the module’s extended address or handle name and a sequence number.

DataContentRemarks
charAuxiliary info header[ only
[char]Identification info8-digit extended address or handle name
charAuxiliary info delimiter: only
[char]Sequence numberStarting from 0
charAuxiliary info footer] only
charSeparatorSpace only
[char]Message
charFooterCR (0x0D/'\r')
charFooterLF (0x0A/'\n')
[810A4778:0] Hello

Other Inputs

Terminals supporting escape sequences can use the following control commands.

  • Ctrl-L: Clear screen
  • Ctrl-C: Cancel input
  • BS/DEL: Move cursor back

3.5.2.2.4 - Serial Communication App Transparent Mode

Mode that purely wirelesss UART
Transparent mode realizes behavior similar to UART connected by wires without adding headers, echo back, or prompt display.
Image connecting external microcontrollers

External microcontrollers can be easily connected, but to optimize communication using formats, format modes (ASCII / Binary) are suitable.

Overview

Purely wirelesss UART.

Sending side inputReceiving side output
Any dataAny data

Since no format is required, existing UART communication can be easily wirelessized.

However, data delimiters are ambiguous and it is impossible to identify the sender from the receiver output.

The initial state specifies CRLF as the transmission trigger character. Therefore, data input to the transmitter is separated by CRLF, and the data before CRLF is transmitted.

For example, entering Hello<Enter> on the transmitting terminal results in Hello being output on the receiving terminal.

[Sending side]

Hello  <- Input

[Receiving side]

Hello  <- Output

Continuous input strings are split and sent in chunks of 80 bytes. Data up to the trigger character should normally be 80 bytes or less.

All terminals are considered child devices, and the transmitted content is broadcast. Communication with all terminals is possible, but the destination cannot be specified. Both ASCII characters and binary data can be sent.

Relay supports up to 3 hops. By default, relay is disabled.

Distinction between Parent and Child Devices

Transparent mode does not distinguish between parent and child devices.

If application ID and frequency channel are the same, data entered into any terminal is sent to other terminals.

Network configuration image

Network configuration image

Identification of Sender

Transparent mode cannot identify the sender.

To identify sender, sender information must be included in data input to the transmitter.

Transmission Trigger

Transmission trigger must be considered, as data is divided and transmitted wirelessly packet by packet.

Therefore, the following transmission triggers must be taken into account:

  • When a timeout after data input is reached
  • When the input data reaches the minimum data size
  • When the transmission trigger character is received

Transmission trigger settings can be specified from the interactive mode k: Transmission Trigger item.

Example Setting

When setting the transmission trigger character to LF, minimum data size to 8 bytes, and timeout to 30 ms, set as follows:

 m: set UART mode (D)
 k: set Tx Trigger (sep=0x0a, min_bytes=8 dly=30[ms])
 o: set option bits (0x00000100)

3.5.2.2.5 - Serial Communication App Header Transparent Mode

Mode that adds headers only to the received output
Header Transparent Mode adds auxiliary information only to the output on the receiving side.

Overview

Enabled by default.

When arbitrary data is input to the transmitting terminal, the receiving terminal outputs data with auxiliary information in a specific format.

Transmitting side inputReceiving side output
Any dataAny data + auxiliary info

By default, data input on the transmitting side is separated by CRLF and data before CRLF is sent.

For example, entering Hello<Enter> on the transmitting side results in output Hello with auxiliary info on the receiving side. The transmitting side also outputs a message indicating transmission completion.

[Transmitting side]

Hello  <- input
;U;00004;219;0x820163B2;000;000;0,1,Hel...;6E;  <- output

[Receiving side]

;U;00003;000;0x820163B2;255;000;Hello;42;  <- output

The auxiliary information output by the receiving side includes the source address, received signal strength, checksum, etc. The format of the auxiliary information can be customized.

Distinction between Parent and Child Devices

Header Transparent Mode does not distinguish between parent and child devices.

If the Application ID and frequency channel are the same, data input to any terminal is sent to other terminals.

Network configuration image

Network configuration image

Identification of Source

The header on the received data includes the logical device ID and serial ID of the sender.

Output Format on Receiving Side

The output format is represented as semicolon (;) separated fields.

[Example output in default state]

;U;00777;120;0x81025A17;120;013;HELLO;79;

This output can be interpreted as follows.

DataDescriptionValue
UcharFixed valueU
00777uint16Timestamp at output777 seconds
120uint8Source logical device ID120 ID-less child device
0x81025A17uint32Source extended address81025A17
120uint8LQI (link quality indicator)120/255
013uint8Source sequence number13
HELLO[uint8]Input dataHELLO
79uint8XOR checksum0x79

Customization by Header Format

The output format on the receiving side follows the header format.

Changing the header format customizes the content of the auxiliary information output and the checksum calculation range.

The header format can be changed via the interactive mode command h: set header format.

Simplest Format

The simplest header format is *\n. It outputs the received data with CRLF line endings.

 h: set header format [*\n]

When sending HELLO in this case, it behaves as follows.

[Receiving side]

HELLO<CR><LF> or HELLO<LF>

[Transmitting side]

HELLO<CR><LF>

Special Characters in Header Format

You can customize the output by including the following special characters in the header format.

General
Description
*Received data
&hlArbitrary ASCII character (e.g., &20 is space)
<Start position for checksum calculation (default is start of string)
>End position for checksum calculation (only from v1.4.6)
Characters following \ (backslash)
Description
\nCRLF (0x0D 0x0A)
\tTAB
\**
\%%
\<<
\>>
\&&
Characters following %
DescriptionLengthData format
%ASource address (32bit)8 charsHexadecimal
%aSource address (32bit)10 charsHexadecimal
%ISource logical address (8bit)2 charsHexadecimal
%iSource logical address (8bit)3 charsDecimal
%TCurrent system time (seconds)4 charsHexadecimal
%tCurrent system time (seconds)5 charsDecimal
%SSource sequence number (hex)2 charsHexadecimal
%sSource sequence number (hex)3 charsHexadecimal
%QReceived signal strength2 charsHexadecimal
%qReceived signal strength3 charsDecimal
%XChecksum2 charsHexadecimal
%xChecksum3 charsDecimal

Checksum Calculation

The checksum is calculated by XOR (exclusive OR) from the start of the data or from the position indicated by < in the header format up to just before %X or %x.

Example in Default State

The default header format is ;U;%t;%i;0x%A;%q;%s;<*;%X;\n, where the checksum calculation range is *;.

That is, when sending HELLO, the binary data HELLO; is targeted, resulting in checksum 0x79.

[Verification code in Python]

from functools import reduce

def main():
    data = "HELLO;"
    checksum = reduce(lambda x, y: x ^ y, data.encode("ascii"))
    print(f"{data} -> {hex(checksum)}")

if __name__ == "__main__":
   main()  # HELLO; -> 0x79

Other Examples

For example, consider the header format ;%I;*;%X.

Since < is not specified, the checksum calculation range is ;%I;*;.

That is, when sending HELLO, the binary data ;000;HELLO; is targeted, resulting in checksum 0x49.

[Verification code in Python]

from functools import reduce

def main():
    data = ";000;HELLO;"
    checksum = reduce(lambda x, y: x ^ y, data.encode("ascii"))
    print(f"{data} -> {hex(checksum)}")

if __name__ == "__main__":
   main()  # ;000;HELLO; -> 0x49

Transmission Trigger

There is no format on the transmitting side input, but data is split and transmitted packet by packet.

Therefore, the following transmission triggers must be considered.

  • When timeout after data input occurs
  • When input data reaches the minimum data size
  • When a transmission trigger character is received

Transmission trigger settings are specified via the interactive mode k: set transmission trigger item.

Example Setting

To set the transmission trigger character to LF, minimum data size to 8 bytes, and timeout to 30 ms, use the following settings.

 m: set UART mode (E)
 k: set Tx Trigger (sep=0x0a, min_bytes=8 dly=30[ms])
 o: set option bits (0x00000100)

3.5.2.3 - Custom Default Feature of Serial Communication App

Creating firmware with changed default settings
With the custom default feature, you can change the default parameters included in the firmware.

For example, if you create firmware that changes the baud rate from 115200bps to 9600bps, you can use it at 9600bps from the start.

Configuration Procedure

1. Apply Settings

Change the settings in Interactive Mode and press S to save.

2. Download Settings

Prepare software that can download data using the xmodem protocol.

While still in Interactive Mode (before selecting items), request xmodem download.

If the download succeeds, a 128-byte file is generated (may be smaller depending on xmodem implementation).

3. Creating Custom Binary

Concatenate the downloaded file to the end of the firmware binary file to create a custom binary.

Use command line tools or general file concatenation tools for concatenation.

Example

Example assuming downloaded xmodem file is conf.bin, original binary file is App_Uart_BLUE_L1305_V1-4-X.bin, and custom binary to create is App_Uart_custom_V1-4-X.bin.

【Windows】

copy App_Uart_BLUE_L1305_V1-4-X.bin App_Uart_custom_V1-4-X.bin
type conf.bin >> App_Uart_custom_V1-4-X.bin

【macOS / Linux】


cat App_Uart_BLUE_L1305_V1-4-X.bin conf.bin > App_Uart_custom_V1-4-X.bin

4. Writing Custom Binary

Write the concatenated custom binary to TWELITE.

3.5.2.4 - Notes on Communication in Serial Communication App

Precautions for stable communication
Precautions for achieving stable communication.

UART Data Input and Output

4KB buffers are allocated for UART input and output. When outputting two UART lines, 2KB is used for input and output buffers for each line.

In format mode and chat mode, it is rarely necessary to be aware of buffer sizes, but in header transparent mode and transparent mode when continuously inputting streams, or even in format mode when inputting many streams at once, it is necessary to be aware of the buffer size limits. On the output side, if a slow baud rate is set, the output of data received wirelessly may not keep up.

Data beyond the buffer limits is not protected at the boundary, causing data loss. Especially on the input side, consider referring to the flow control pins described below.

UART Flow Control

Input flow control is implemented to behave like the RTS pin. The pin used is PWM1 (DIO5), targeting the main UART port. When input is not accepted, the state is High; when input is accepted, the state is Low. Output flow control is not supported. Receiving devices should ensure sufficient baud rate and processing speed.

  • After power-on or reset, the pin is High. It becomes Low once UART is initialized.
  • When the UART input buffer exceeds 7/8 full, the pin goes High; it goes Low when below that threshold.
  • In transparent mode, the pin is High during packet transmission.

Countermeasures for Wireless Communication Errors

If data loss occurs on the receiving side, increase the number of wireless retransmissions.

Increasing the number of additional packets sent can improve the success rate of reception.

The number of retransmissions can be set in Interactive Mode (x: set RF Conf).

3.5.2.5 - Interactive Mode (Serial Communication App)

Configuration changes via Interactive Mode
You can perform detailed configuration of the app via Interactive Mode.

This section explains functions specific to the Serial Communication App (App_Uart). For common features, see the TWELITE APPS Manual top page.

Example Display

The following screen will be displayed.

--- CONFIG/TWE UART APP V1-04-5/SID=0x82018ca0/LID=0x78 -- ---
 a: set Application ID (0x67720103)
 i: set Device ID (120=0x78)
 c: set Channels (18)
 x: set RF Conf (3)
 r: set Role (0x0)
 l: set Layer (0x1)
 b: set UART baud (38400)
 B: set UART option (8N1)
 m: set UART mode (E)
 k: set Tx Trigger (sep=0x0d0a, min_bytes=0 dly=0[ms])
 h: set header format [;U;%t;%i;0x%A;%q;%s;<*>;%X;\n]
 C: set crypt mode (0)
 o: set option bits (0x00000100)
---
 S: save Configuration
 R: reset to Defaults

Commands

Setting ItemDefaultRemarks
aApplication ID0x6772010332bit
iLogical Device ID120Parent device 0/121, child device 1-100, ID-less child device 120
cFrequency Channel1811-26
xRetry count and transmission output3
Retry count01-9 times, 0 disables
Transmission output30-3
rRole0Normal 0, relay child 1-3, others
lRelay Layer0x01
bUART alternative baud rate38400Enabled with BPS pin
BUART option8N1
mCommunication modeEA/B/C/D/E
kTransmission trigger0x0d0a,0,0Trigger character, minimum size, timeout
hHeader / Handle nameReference
HeaderFor header transparent mode
Handle nameFor chat mode
CEncryption0Disabled 0, AES128bit 1
oOption bits0x00000000Other detailed settings

Details of each command are as follows.

a: Application ID

All devices communicating must use the same value. This logically separates networks.

i: Logical Device ID

Set this to distinguish multiple child devices.

If no distinction is necessary or possible, set to 120. If distinction is necessary, child devices should use any value from 1 to 100, and parent devices should be 0 or 121.

c: Frequency Channel

All devices communicating must use the same value. This physically separates networks.

x: Transmission output and retry count

Specify the RF transmission output power and the number of additional packet transmissions in transparent mode and header transparent mode.

r: Role

Valid only for child devices. Specify the following values. Normally select the delivery method that does not use the network layer.

Delivery method not using network layer

  • 0: Normal designation (parent or child)
  • 1-3: Relay child (logical device ID is 1-100 or 120). The number 1-3 indicates the maximum number of relay hops. Since retransmission is repeated up to the maximum relay hops, duplicate packets may be relayed depending on the placement and number of relay devices.

Delivery methods using network layer

Supported only in format mode.

  • 11: Parent
  • 12: Relay
  • 13: Child

l: Relay Layer

The relay layer number. Relay devices attempt to connect to relay devices or parents in upper relay layers (smaller values). Effective only when Role is set to 12.

m: Communication mode

  • A: Format mode (ASCII)
  • B: Format mode (Binary)
  • C: Chat mode
  • D: Transparent mode
  • E: Header transparent mode

b: UART alternative baud rate

Overrides the alternative baud rate selected when the BPS pin is connected to GND at startup.

Selectable values are 9600/19200/38400/57600/115200/230400. Other values may cause inaccuracies.

B: UART option

Specify three characters in the order Bit-Parity-Stop.

  • Bit
    • 8: 8 Bit
    • 7: 7 Bit
  • Parity
    • N: None
    • O: Odd
    • E: Even
  • Stop
    • 1: STOP 1
    • 2: STOP 2

k: Transmission trigger

Set the transmission trigger applied to input in transparent mode and header transparent mode.

Enter separated by commas , in the following order:

  1. Transmission trigger character
  2. Minimum data size
  3. Timeout

Transmission trigger character

Packets are sent when this character is input (except when the minimum data size is not met).

In Interactive Mode, specify the ASCII code in hexadecimal. The leading 0x is ignored. Default is CRLF.

The transmitted data includes the transmission trigger character. To enable the transmission trigger character, specify option bit 0x00000100 (enabled by default).

Minimum data size

Specify the minimum size of continuous data to be handled. Even if the trigger character is included before reaching the minimum data size, it is invalid.

In Interactive Mode, specify a number between 1 and 80 as byte count. 0 disables. Default is disabled.

Timeout

The wait time until the packet is sent after the last input.

In Interactive Mode, specify a number between 10 and 200 milliseconds. 0 disables. Default is disabled.

h: Header / Handle name

For header transparent mode, specify the header format; for chat mode, specify the handle name.

Header (header transparent mode)

Specify the header format syntax.

Handle name (chat mode)

Specify the handle name displayed on the counterpart device.

Maximum 23 characters. Consumes the data area (80 bytes) for transmission.

C: Encryption

Specify whether to enable encryption.

Specify 1 to enable AES128bit encryption.

o: Option bits

Specify a 32-bit value. Various settings linked to each bit can be enabled.

Target bitSetting itemDefaultABCDE
0x00000001Disable internal pull-up of M30️⃣
0x00000002Unused0️⃣
0x00000100Enable transmission trigger1️⃣
0x00000200Prioritize new input series0️⃣
0x00001000Disable response message0️⃣
0x00004000Loosen duplicate checker0️⃣
0x00010000Force apply alternative baud rate0️⃣
0x00020000Simultaneous output to secondary port0️⃣
0x00040000Switch main port0️⃣
0x00100000Limit relay layer0️⃣

Details of Option Bits

Explanation of settings linked to each bit of the option bit value.

00000001: Disable internal pull-up of M3

Disables the internal pull-up of the M3 pin used for sleep setting on TWELITE DIP.

00000100: Enable transmission trigger

Enables the transmission trigger setting in transparent mode or header transparent mode.

00000200: Prioritize new input series

In format modes (ASCII/Binary), transparent mode, and header transparent mode, prioritize new input series if multiple series are input before transmission completes.

00001000: Disable response message

In format modes (ASCII/Binary) and header transparent mode, disables response messages after transmission completes.

00004000: Loosen duplicate checker

Loosens the duplicate checker conditions on the receiving side.

00010000: Force apply alternative baud rate

Applies the alternative baud rate setting even if the BPS pin input is not Low at startup.

00020000: Simultaneous output to secondary port

Outputs the serial output TX also to the serial secondary output TX_SUB.

00040000: Switch main port

Swaps the serial input/output TX/RX with the serial secondary input/output TX_SUB/RX_SUB.

00100000: Limit relay layer

In format modes (ASCII/Binary), when specifying delivery methods using network layer, always send to relay devices or parent devices one layer above. Normally, delivery methods using network layer send to the relay or parent device with the best radio quality in the upper layer.

About Relay Function

When communication distance is insufficient or there are obstacles preventing communication, using relay devices is useful.

Devices with relay function retransmit packets they receive to other devices.

Relay Function Settings

Normally, change the Role value to 1-3 while in Interactive Mode. The default value is 0, which does not have relay function.

r: set Role (0x0)

The number 1-3 indicates the maximum number of relay hops. For example, specifying 3 allows up to 3 relay hops.

Distinction between parent and child devices applies only to child devices.

Setting Example

The following network configuration shows devices with red color set to Role 0 and devices with blue color set to Role 3.

Example of relay by role setting

Example of relay by role setting

Adding red devices allows communication with up to 3 relay hops between red devices.

Example of adding transmitters and receivers

Example of adding transmitters and receivers

3.6 - Cue App Manual

Wireless notification of object movement.
The Cue App (App_CUE) is an app dedicated to the magnetic and acceleration sensor tag TWELITE CUE.

3.6.1 - Cue App Manual

Latest Edition

Features

By attaching to objects, it can wirelessly transmit movement and status.

  • Collect data from multiple wireless tags on the parent device
  • Control multiple wireless tags with the parent device
  • Operate multiple systems individually on 16 channels
  • Mix multiple systems on the same channel by setting different application IDs per group
  • Encryption and encryption key settings

3.6.1.1 - Cue App Operating Modes

Operating modes of the Cue app

3.6.1.1.1 - Cue App TWELITE CUE Mode

All-in-one mode for impact detection, door open/close, and acceleration measurement

This is an all-in-one mode that supports acceleration measurement, impact detection, posture detection, and magnet detection.

This mode is set as the factory default.

Settings

If you use this mode, please set the following items.

Setting CommandSetting ItemSetting ValueRemarks
pSensor-specific parameter setting00000000

Parent Device Output

Typical Battery Life

  • About 80 days if only periodic transmission every 5 seconds
  • About 80 days if periodic transmission every 5 seconds plus TWELITE CUE moved once per minute
  • About 700 days if only periodic transmission every 1 minute
  • About 565 days if periodic transmission every 1 minute plus TWELITE CUE moved once per minute

3.6.1.1.2 - Cue App Motion Sensor Pal Mode

Mode operating as a motion sensor pal

This mode provides equivalent functionality to the motion sensor pal.

Use this mode when measuring acceleration continuously or detecting impacts.

This mode is divided into three sub-modes:

  • Acceleration measurement mode
  • Event detection mode
  • Dice mode

Acceleration Measurement Mode

This mode intermittently or continuously measures acceleration and transmits the data.

Settings

Setting CommandSetting ItemSetting ValueRemarks
tTransmission interval0 or 1–4095Unit: seconds.
0: Continuous transmission
1+: Intermittent transmission
pSensor-specific parameterx3000yyyx: TWELITE 2525A mode flag
yyy: Accelerometer properties

TWELITE 2525A Mode Flag

Setting the TWELITE 2525A mode flag to 1 (sensor-specific parameter: 13000000) makes it operate as TWELITE 2525A FIFO (normal) mode. Use this mode if you want to substitute TWELITE 2525A.

Accelerometer Properties

You can change the number of samples and sampling frequency during intermittent transmission with accelerometer properties.

These settings can be combined by adding values.

Setting Value (Hex)Description
0x?3????00–0x?3????FFNumber of samples to send during intermittent transmission, set in 16-sample units.
Sample count = 16 + 16 x value.
Examples:
0x00000000: 16 samples (default)
0x00000001: 32 samples

0x00000007: 128 samples

0x000000FF: 4096 samples
0x?3???0??–0x?3???F??Sampling frequency of acceleration:
0x00000000: 25Hz (default)
0x00000100: 50Hz
0x00000200: 100Hz
0x00000300: 190Hz
0x00000400–0x00000F00: Undefined

Parent Device Output

Move Mode

Detects movements like Move and Shake.

You can control the notification pal’s LED.

Settings

Setting CommandSetting ItemSetting ValueRemarks
pSensor-specific parameter01100000

Parent Device Output

Usage Notes

This mode detects movement and sends data accordingly. Therefore, if moved slowly, it may not detect movement and output may not change. In that case, move it a little more vigorously.

Also, setting sensor-specific parameter (p) to 01000000 makes motion detection more sensitive. If transmissions occur at unintended times, set this parameter to 01000000.

Dice Mode

Detects the face of TWELITE CUE facing upward.

Controls the notification pal’s LED similar to event detection mode.

Settings

Setting CommandSetting ItemSetting ValueRemarks
pSensor-specific parameter02100000

Parent Device Output

Usage Notes

This mode detects movement and determines the face orientation. Therefore, if moved slowly, the face may not be detected and output may not change. In that case, place it on a desk or give it a light tap.

Also, setting sensor-specific parameter (p) to 02000000 makes motion detection more sensitive. If transmissions occur at unintended times, set this parameter to 02000000.

Typical Battery Life

  • About 3.5 years if transmitting once every minute in intermittent transmission acceleration measurement mode
  • About 20 days if transmitting continuously at 25 Hz sampling frequency in acceleration measurement mode
  • About 3 years if moving once every minute in event detection or dice mode

3.6.1.1.3 - Cue App Open/Close Sensor Pal Mode

Mode operating as an open/close sensor pal

This mode attaches to objects and detects open/close by the presence or absence of a magnet. Use this mode to measure door opening/closing or factory equipment operation status.

Settings

When using this mode, set the following items.

Setting CommandSetting ItemSetting ValueRemarks
pSensor-specific parameter setting04000000

Parent Device Output

Typical Battery Life

Approximately 4 years if 200 open/close operations per day (including 1-minute periodic transmissions). Approximately 4.5 years if 0 open/close operations per day (including 1-minute periodic transmissions).

3.6.1.2 - Cue App Settings

How to configure the Cue App
There are two ways to configure the TWELITE CUE: wired and wireless.

3.6.1.2.1 - Cue App Settings via OTA

How to configure via wireless communication

OTA settings allow you to configure the interactive mode settings wirelessly.

Steps for OTA Configuration

Perform OTA configuration using the following steps.

1. Launch the TWELITE STAGE APP

Install the TWELITE STAGE SDK on your PC, then launch TWELITE_Stage in the MWSTAGE folder.

2. Write the OTA configuration app to the MONOSTICK

Open 2: Rewrite App > 1: Select from BIN, and select App_CUE_OTA_....

3. Enter configuration values in interactive mode

Select 3: Interactive Mode, then edit and save the values.

4. Execute the OTA configuration

Place the TWELITE CUE within about 20cm of the MONOSTICK. Turn on the main unit’s power or bring a magnet close to the magnetic sensor more than 5 times to confirm that the TWELITE CUE’s LED is blinking.

5. Confirm the output from the MONOSTICK

Check for the following output messages. If no output is displayed, see here.

Example output when OTA is successful

6. Rewrite the app back to the MONOSTICK

Open 2: Rewrite App > 1: Select from BIN, and select App_Wings_MONOSTICK_....

OTA Failure Cases

Distance is too far

The following message indicates that the distance is too far.

OTA FAILURE
  OTA request TS=20515[ms]
  LQI:63 (RF strength, >= 100)
  SID:810BA765
  TWELITE CUE:v1.1.1
  Protocol Version:0x11

--— LQI is small. Please make TWELITE CUE closer. —--

In this case, bring the MONOSTICK and TWELITE CUE closer together.

Wrong target

The following message indicates that the TWELITE CUE firmware is different or that the wrong TWELITE CUE is being approached.

OTA FAILURE
  OTA request TS=20515[ms]
  LQI:180 (RF strength, >= 100)
  SID:810BA765
  TWELITE CUE:v1.1.1
  Protocol Version:0x13

--— Different protocol version. Please update TWELITE CUE. —--

In this case, check that you are not approaching the wrong TWELITE CUE. Also, if you have rewritten the TWELITE CUE firmware, please use TWELITE R2/R3 to rewrite it back to App_CUE.

3.6.1.2.2 - Cue App Settings via TWELITE R2/R3

How to configure using TWELITE R2/R3

Settings can be made by connecting TWELITE R2/R3 to the 7P interface of TWELITE CUE.

Example connection with TWELITE R2

Example connection with TWELITE R2

When using TWELITE R2/R3 for configuration, please follow the steps below.

1. Launch the TWELITE STAGE APP

Install the TWELITE STAGE SDK on your PC and launch TWELITE_Stage in the MWSTAGE folder.

2. Enter setting values in Interactive Mode

Select 3: Interactive Mode, then edit and save values.

3.6.1.2.3 - Interactive Mode (Cue App)

Detailed configuration changes via Interactive Mode

This app allows detailed configuration from Interactive Mode.

This page explains functions specific to the Cue App (App_CUE). For common functions, see the TWELITE APPS Manual top page.

When entering Interactive Mode, the following screen is displayed.

--- CONFIG/App_CUE V1-00-2/SID=0x810ba765/LID=0x01 ---
 a: set Application ID (0x67720102)
 i: set Device ID (--)
 c: set Channels (18)
 x: set Tx Power (13)
 b: set UART baud (38400)
 B: set UART option (8N1)
 k: set Enc Key (0xA5A5A5A5)
 o: set Option Bits (0x00000001)
 t: set Transmission Interval (5)
 p: set Senser Parameter (0x00000000)
---
 S: save Configuration
 R: reset to Defaults

List of Setting Commands

CommandSetting ItemDefaultExplanation
aApplication ID0x67720102Multiple groups can use the same frequency channel. The value is set as a 32-bit number.
iLogical Device IDSets the logical device ID of the child device. Values from 1 to 100 can be set.
If the setting is “–”, the logical device ID is internally set to 1.
cFrequency Channel Setting18Selects the channel (11–26). Multiple channel specifications are invalid to prioritize low power operation.
xTransmission Power Setting13Specify a one- or two-digit number. The second digit is optional. The first digit sets the transmission power. 3 is the strongest, and each step down to 2, 1, 0 reduces output by -11.5 dB. Use this to limit output and reduce the effective radio range. However, transmission distance is affected by environment (noise, obstacles, etc.).
※ Theoretically, transmission distance halves for every 6 dB reduction in output, so one step reduction reduces distance to about 1/4. The second digit sets the number of retransmissions. Specify 0–9 for the second digit; 0 means no retransmission (default), 1–9 correspond to the number of retransmissions.

Example:
3 -> No retransmission, strongest output (default, omitted)
42 -> 4 retransmissions, output level 2 (one step weaker)
bUART Baud Rate Setting38400Fixed at 115200 bps regardless of input value.
BUART Parity Setting8N1Fixed at 8N1 regardless of input value.
kEncryption Key Setting0xA5A5A5A5Enter the encryption key. Set a 32-bit hexadecimal number. Use the same value within the communication group.
oOption Bits Setting0x00000001Various detailed settings can be configured.
tTransmission Interval Setting5Sets the interval for periodic transmission packets in seconds. Valid values are 1 to 4095. Behavior outside this range is undefined.
pSensor-Specific Parameter Setting0Switch modes and set parameters. Specify as a hexadecimal number greater than or equal to 0. See the page Various Modes for details.
SSave SettingsSaves settings and restarts the module.
RReset to DefaultsResets settings to default. If you save immediately after without other operations using the S key, the save area is cleared.

Option Bits Setting

Explanation of each bit in the option bit setting value.

Bit (Hex)Explanation
0x00000001Transmits to each repeater or parent device, and all information received by the repeaters is forwarded to the parent device and output via serial.
In this case, analyzing multiple received packets allows identifying the router that received the signal closest.
0x00000040Disables OTA.
0x00001000Enables encrypted communication. (Please also set encryption on the counterpart.)
0x00010000Enables message output over UART communication.

3.7 - Aria App Manual

Wireless notification of temperature and humidity.
Aria App (App_ARIA) is an app dedicated to the magnetic, humidity, and temperature sensor tag TWELITE ARIA.

3.7.1 - Aria App Manual

Latest Edition

3.7.1.1 - How to Use the Aria App

How to use the Aria App
This section explains how to use the Aria app in two steps.

3.7.1.1.1 - Checking Operation of Aria App

Using MONOSTICK and PC to check operation of TWELITE ARIA
Let’s measure temperature using TWELITE CUE and MONOSTICK.

Required Items

  1. TWELITE CUE
  2. MONOSTICK

Insert the Battery

Insert the CR2032 battery with the + side aligned with the + side of the battery holder. If the LED on the TWELITE CUE blinks 3 times, it is normal.
After startup, it transmits every 5 seconds, and the LED blinks once during transmission.

Diagram explaining how to install the battery

Battery Installation

Also, because the battery holder of TWELITE ARIA is structurally prone to solder joint detachment, please be careful when inserting the battery as follows:

  • When removing the coin battery, it is recommended to lightly press the battery holder from above with your finger to reduce force on the solder joints while removing the coin battery.
  • When using TWELITE ARIA, it is recommended to use it with a dedicated case that presses the battery holder from above.

Attach Fixing Magnet

By attaching a magnet to the recess at the position shown in the figure, you can stick TWELITE ARIA to a metal surface. Use as needed.

Location for magnet installation

Magnet Installation Location

Insert into Case

Hook the board on the claws on the edge of the case as indicated by the circle marks.

Diagram explaining how to insert the board

Inserting the Board

Open the Case

Insert a coin into the notch on the case and pry it open.

Diagram explaining where to insert the coin

Where to Insert the Coin

Prepare Parent and Repeater

A parent device is required as a communication partner. If you want to extend communication distance, a repeater can be used. You can use MONOSTICK - MonoStick as the parent and repeater devices.

Please write the app version v1-01-4 or later of the Parent/Repeater App Wings to MONOSTICK - MonoStick.

Check Operation

Try moving the TWELITE ARIA or bringing a magnet close, and check the data received by the MONOSTICK connected to the PC.

Prepare TWELITE STAGE SDK

First, install the latest version of TWELITE STAGE SDK on your PC.

Launch TWELITE STAGE APP

  1. Connect MONOSTICK to the USB port of your PC.
  2. Double-click the following files inside the MWSTAGE folder of the installed TWELITE STAGE SDK.
    ・TWELITE_stage.exe (Windows)
    ・TWELITE_stage.command (macOS)
    ・TWELITE_stage.run (Linux)
    When launched, the MONOSTICK connected via USB will be displayed on the screen.
  3. Select 1: MONOSTICK from the serial port selection screen.
  4. When the device is selected, the top menu screen of TWELITE STAGE APP will be displayed.

Prepare Parent Device

A parent device is required as a communication partner. You can use MONOSTICK - MonoStick as the parent device.
Please write the Parent/Repeater App Wings to MONOSTICK - MonoStick following the steps below.

  1. From the top menu, select 2: Rewrite App > 1: Select from BIN.\
  2. If you are using MONOSTICK BLUE, select App_Wings_MONOSTICK_BLUE_…, and if you are using MONOSTICK RED, select App_Wings_MONOSTICK_RED_…
  3. After writing is complete, do not enter interactive mode; press and hold the ESC key to return to the top menu.

Select Viewer

  1. From the top menu, select 1: Viewer > 4: CUE/ARIA Viewer.
  2. Click the TWELITE ARIA tab.
Screen of TWELITE ARIA Viewer

TWELITE ARIA Viewer

Check Operation of TWELITE ARIA

Measure Temperature and Humidity

Temperature and humidity values are updated every 5 seconds.

Detect Magnet

  • When the N pole of a magnet is brought close to the magnetic sensor, “[N pole]” is displayed.
  • When the S pole of a magnet is brought close to the magnetic sensor, “[S pole]” is displayed.
  • When the magnet is moved away from the magnetic sensor, “ —- ” is displayed.

Change Mode

You can change the behavior of TWELITE ARIA by changing the mode.

Please refer to the following page for details.

Mode Selection

Change Settings

You can set grouping and transmission frequency changes in interactive mode.

Please refer to the following page for how to enter interactive mode.

Settings

Also, please refer to the following page for the items that can be set.

Interactive Mode

Output Log

You can output data such as temperature and humidity in CSV format to a log using pulse scripts.

Please refer to the following page for details.

Pulse Script

Draw Graph

You can view temperature, humidity, and magnetic sensor values as graphs using the PalViewer.

Please refer to the following page for details.

PalViewer

3.7.1.1.2 - Aria App Operating Modes

Operating modes of the Aria app
The Aria app has two operating modes: TWELITE ARIA mode and Open/Close Sensor Pal mode.

TWELITE ARIA mode

Initial mode of TWELITE ARIA.

An all-in-one mode that can measure temperature and humidity and detect door opening and closing simultaneously.

Open/Close Sensor Pal mode

Mode that operates as an open/close sensor pal.

Use this mode to measure door opening/closing or factory equipment operation status.

3.7.1.1.2.1 - Aria App TWELITE ARIA Mode

Initial mode
This is an all-in-one mode that allows you to try measuring temperature and humidity and detect the presence or absence of a magnet.

This mode is set as the factory default.

Settings

If you use this mode, please set the following items.

Setting CommandSetting ItemSetting ValueRemarks
pSensor-specific parameter setting00000000

Parent Device Output

Typical Battery Life

  • About 340 days if only periodic transmission every 5 seconds
  • About 300 days if periodic transmission every 5 seconds plus magnet approached every 1 minute
  • About 4 years if only periodic transmission every 1 minute
  • About 2.5 years if periodic transmission every 1 minute plus magnet approached every 1 minute

3.7.1.1.2.2 - Aria App Open/Close Sensor Pal Mode

Mode operating as an open/close sensor pal
This mode attaches to objects and detects open/close by the presence or absence of a magnet.

Settings

When using this mode, set the following items.

Setting CommandSetting ItemSetting ValueRemarks
pSensor-specific parameter setting04000000
Please refer to Settings for configuration instructions.

Parent Device Output

Typical Battery Life

Approximately 4 years if 200 open/close operations per day (including 1-minute periodic transmissions).
Approximately 4.5 years if 0 open/close operations per day (including 1-minute periodic transmissions).

3.7.1.2 - Aria App Settings

Aria App Settings

There are two ways to configure the Aria app.

For details on configurable items, please check Interactive Mode.

Configuration via OTA

OTA stands for Over the Air, meaning wireless communication. OTA configuration is a feature to configure settings without cable connection using Interactive Mode.

Executing OTA requires MONOSTICK.

Configuration using TWELITE R2

It is also possible to connect TWELITE R2/R3 to the 7P interface of TWELITE CUE and configure settings via Interactive Mode.

3.7.1.2.1 - OTA Settings for Aria App

Settings of TWELITE ARIA and MONOSTICK via wireless communication.

OTA settings is a function to perform interactive mode settings via wireless communication.

Procedure for OTA Settings

Perform OTA settings following the steps below.

1. Launch the TWELITE STAGE APP

Install the TWELITE STAGE SDK on your PC, then launch TWELITE_Stage in the MWSTAGE folder.

2. Write the OTA setting app to MONOSTICK

Open 2: Rewrite App > 1: Select from BIN and select App_ARIA_OTA_....

3. Enter setting values in interactive mode

Select 3: Interactive Mode, then edit and save the values.

4. Execute OTA setting

Place the TWELITE ARIA within about 20 cm from MONOSTICK. Turn on the power of the device or bring a magnet close to the magnetic sensor more than 5 times, and confirm that the LED of TWELITE ARIA blinks.

5. Check the output of MONOSTICK

Confirm the output of messages like the following. If no output is shown, see here.

Example output when OTA succeeds

6. Write back the app to MONOSTICK

Open 2: Rewrite App > 1: Select from BIN and select App_Wings_MONOSTICK_....

If OTA Fails

Distance is too far

Messages like the following indicate that the distance is too far.

OTA FAILURE
  OTA request TS=20515[ms]
  LQI:63 (RF strength, >= 100)
  SID:810BA765
  TWELITE ARIA:v1.1.1
  Protocol Version:0x13

--— LQI is small. Please make TWELITE ARIA closer. —--

In this case, bring MONOSTICK and TWELITE ARIA closer.

Different target

Messages like the following indicate that the firmware of TWELITE ARIA is different or that TWELITE CUE was mistakenly brought close.

OTA FAILURE
  OTA request TS=20515[ms]
  LQI:180 (RF strength, >= 100)
  SID:810BA765
  TWELITE ARIA:v1.1.1
  Protocol Version:0x11

--— Different protocol version. Please update TWELITE ARIA. —--

In this case, check if you mistakenly brought TWELITE CUE close. Also, if you rewrote the firmware of TWELITE ARIA, please use TWELITE R2/R3 to write back to App_ARIA.

3.7.1.2.2 - Settings for Aria App using TWELITE R2/R3

Settings performed by connecting TWELITE ARIA and TWELITE R2/R3 via wired connection.

Settings can be made by connecting TWELITE R2/R3 to the 7P interface of TWELITE ARIA.

Example connection with TWELITE R2

Example connection with TWELITE R2

When using TWELITE R2/R3 to configure, please follow the steps below.

1. Launch the TWELITE STAGE APP

Install the TWELITE STAGE SDK on your PC and launch TWELITE_Stage in the MWSTAGE folder.

2. Enter setting values in Interactive Mode

Select 3: Interactive Mode, then edit and save values.

3.7.1.3 - Interactive Mode (ARIA App)

Interactive mode of the ARIA app
You can perform detailed settings of the app in interactive mode.

This section explains features specific to the ARIA app (App_ARIA). For common features, please refer to the TWELITE APPS Manual Top Page.

Example Display

The screen will display as follows:

 --- CONFIG/App_ARIA V1-01-0/SID=0x810a7817/LID=0x01 ---
 a: set Application ID (0x67720102)
 i: set Device ID (--)
 c: set Channels (18)
 x: set Tx Power (13)
 b: set UART baud (38400)
 B: set UART option (8N1)
 k: set Enc Key (0xA5A5A5A5)
 o: set Option Bits (0x00000001)
 t: set Transmission Interval (5)
 p: set Senser Parameter (0x00000000)
 d: set Temperature Coefficient (0)
 D: set Temperature Offset (0)
 f: set Humidity Coefficient (0)
 F: set Humidity Offset (0)
---
 S: save Configuration
 R: reset to Defaults

Commands

Setting ItemDefault ValueRemarks
aApplication ID0x6772010232bit
iLogical Device ID-Child device 1-100
cFrequency Channel1811-26
xRetransmission Count and Transmission Power13
Retransmission Count11-9 times, 0 means none
Transmission Power30-3
bUART Alternative Baud Rate38400Not applicable
BUART Option8N1Not applicable
kEncryption Key0xA5A5A5A532bit
oOption Bits0x00000001Other detailed settings
tTransmission Interval51-4095 seconds
pSensor Specific Parameter0
dTemperature Coefficient00-60000
DTemperature Offset0-2000-2000
fHumidity Coefficient00-60000
FHumidity Offset0-2000-2000

Details of each command are shown below.

a: Application ID

All devices communicating must have the same value. This logically separates the network.

i: Logical Device ID

Set this when it is necessary to identify multiple child devices.

You can set any value from 1 to 100.

c: Frequency Channel

All devices communicating must have the same value. This physically separates the network.

x: Transmission Power and Retransmission Count

Specify the radio transmission power and the number of times to retransmit packets additionally in transparent mode and header-attached transparent mode.

b: UART Alternative Baud Rate

Not applicable. Unlike products such as TWELITE DIP, there is no BPS pin.

B: UART Option

Not applicable. Unlike products such as TWELITE DIP, there is no BPS pin.

k: Encryption Key

Specify the encryption key as a 32bit hexadecimal number when enabling encryption communication with the option bit Enable Encryption Communication.

o: Option Bits

Specify a 32bit number. You can enable settings associated with each bit.

Target BitSetting ItemDefault
0x00000001Enable Transmission to Relay Devices1️⃣
0x00000040Disable OTA Setting Function0️⃣
0x00001000Enable Encryption Communication0️⃣
0x00010000Enable UART Output on Child Device0️⃣

t: Transmission Interval

Specify the data transmission interval.

p: Sensor Specific Parameter

Used to switch the Operating Mode.

pMode
0x00000000TWELITE ARIA Mode
0x04000000Open/Close Sensor PAL Mode

d: Temperature Coefficient

Specify the coefficient \(d\) of temperature data in the range 0-60000.

If 0, it is disabled. Otherwise, the final temperature is multiplied by \(\frac{d}{1024}\).

D: Temperature Offset

Specify the temperature data offset \(D\) in the range -2000 to 2000.

Add \(D\) to the temperature multiplied by 100. The final temperature changes by \(\frac{D}{100}\) °C.

f: Humidity Coefficient

Specify the coefficient \(f\) of humidity data in the range 0-60000.

If 0, it is disabled. Otherwise, the final humidity is multiplied by \(\frac{f}{1024}\).

F: Humidity Offset

Specify the humidity data offset \(F\) in the range -2000 to 2000.

Add \(F\) to the humidity multiplied by 100. The final humidity changes by \(\frac{F}{100}\) %.

Details of Option Bits

Explanation of settings associated with each bit of the option bit value.

00000001: Enable Transmission to Relay Devices

Enable transmission not only to the parent device but also to relay devices.

You can use relay devices even if this option is not set, but the parent device will eliminate duplicate packets received. At this time, there is no way to know through which relay device the packet was transmitted or if it was not relayed.

If this option is set, the parent device can output a single packet received from multiple devices separately. By analyzing the output connected to the parent device, you can determine near which device the child device was located.

00000040: Disable OTA Setting Function

Disables the OTA setting function.

00001000: Enable Encryption Communication

Enables encrypted communication. The other party must also enable encrypted communication.

00010000: Enable UART Output on Child Device

Enables message output on the child device.

3.8 - Pal App Manual

For the TWELITE PAL Series

Pal App (App_PAL) is an application dedicated to the wireless tag system TWELITE PAL Series.

It is installed on TWELITE BLUE / RED PAL at factory shipment.

3.8.1 - Pal App Manual

Latest Edition

Installation

To write the Pal App (App_PAL), install TWELITE STAGE SDK and rewrite using the TWELITE STAGE App.

Supported Hardware

  • TWELITE BLUE / RED PAL with Open/Close Sensor Pal attached
  • TWELITE BLUE / RED PAL with Environmental Sensor Pal attached
  • TWELITE BLUE / RED PAL with Motion Sensor Pal attached
  • TWELITE BLUE / RED PAL with Notification Pal attached

3.8.1.1 - Interactive Mode (Pal App)

Interactive mode for the Pal app
You can perform detailed configuration of the app in interactive mode.

This section explains features specific to the Pal app (App_PAL). For common features, please refer to the TWELITE APPS Manual main page.

Example Display

The screen will display as follows.

--- CONFIG/App_PAL V1-05-2/SID=0x810e0e23/LID=0x01 ---
 a: set Application ID (0x67726305)
 i: set Device ID (--)
 c: set Channels (15)
 x: set Tx Power (13)
 b: set UART baud (38400)
 B: set UART option (8N1)
 k: set Enc Key (0xA5A5A5A5)
 o: set Option Bits (0x00000001)
 t: set Transmission Interval (60)
 p: set Sensor Parameter (0x00000000)
 e: set Event Parameter(s) (0180002A0208002A0300802A0488002A0580802A0608802A0880000A1008000A)
 d: set Temperature Coefficient (0)
 D: set Temperature Offset (0)
 f: set Humidity Coefficient (0)
 F: set Humidity Offset (0)
---
 S: save Configuration
 R: reset to Defaults

Commands

Setting ItemDefaultRemarks
aApplication ID0x6772010732bit
iLogical Device ID120Child 1-100
cFrequency Channel1611-26
xRetry Count and Tx Power3
Retry Count01-9 times, 0 is default: none
Tx Power30-3
bUART Alternative Baud Rate38400Enabled with BPS pin
BUART Option8N1Enabled with BPS pin
kEncryption Key0xA5A5A5A532bit
oOption Bits0x00000000Other detailed settings
tTransmission Interval601-4095 seconds
pSensor-specific Parameter0
eNotification Event0180002A
0208002A
0300802A
0488002A
0580802A
0608802A
0880000A
1008000A
Notification Pal only
dTemperature Coefficient0Environmental Pal only 0-60000
DTemperature Offset0Environmental Pal only -2000-2000
fHumidity Coefficient0Environmental Pal only 0-60000
FHumidity Offset0Environmental Pal only -2000-2000

Details of each command are as follows.

a: Application ID

All devices communicating must use the same value. This logically separates networks.

i: Logical Device ID

Set when it is necessary to distinguish multiple child devices.

If there is no need or it is not possible to distinguish, set to 120. If distinction is needed, children should use any value from 1 to 100, and the parent should use 0 or 121.

c: Frequency Channel

All devices communicating must use the same value. This physically separates networks.

x: Tx Power and Retry Count

Specify the radio transmission power and the number of additional packet transmissions in transparent mode and headered transparent mode.

b: UART Alternative Baud Rate

Overrides the alternative baud rate selected when the BPS pin is connected to GND at startup.

Selectable values are 9600/19200/38400/57600/115200/230400. Specifying other values may cause errors.

B: UART Option

Overrides the alternative UART settings selected when the BPS pin is connected to GND at startup.

Parity can be set to N: None, O: Odd, or E: Even. Hardware flow control cannot be set. Settings like 8N1 or 7E2 can be used, but settings other than 8N1 are unverified. Please confirm operation in advance.

k: Encryption Key

Specify the 32-bit hexadecimal encryption key used when enabling encrypted communication in option bits.

o: Option Bits

Specify a 32-bit value. Various settings linked to each bit can be enabled.

BitSetting DescriptionDefault
0x00000001Enable Transmission to Repeater0️⃣
0x00001000Enable Encrypted Communication0️⃣
0x00010000Enable UART Output on Child0️⃣

t: Transmission Interval

Specifies the data transmission interval. For notification pals, it indicates the interval for querying control information from the parent and reflecting it on LED output.

p: Sensor-specific Parameter

Depends on the hardware.

e: Notification Event

Notification Pal

Specifies the behavior when an event number is received.

For details, see Notification Event Details.

d: Temperature Coefficient

Environmental Sensor Pal

Specify the temperature data coefficient (d) in the range 0-60000.

0 disables it. Otherwise, the final temperature is multiplied by (\frac{d}{1024}).

D: Temperature Offset

Environmental Sensor Pal

Specify the temperature data offset (D) in the range -2000 to 2000.

(D) is added to the temperature multiplied by 100. The final temperature changes by (\frac{D}{100}) °C.

f: Humidity Coefficient

Environmental Sensor Pal

Specify the humidity data coefficient (f) in the range 0-60000.

0 disables it. Otherwise, the final humidity is multiplied by (\frac{f}{1024}).

F: Humidity Offset

Environmental Sensor Pal

Specify the humidity data offset (F) in the range -2000 to 2000.

(F) is added to the humidity multiplied by 100. The final humidity changes by (\frac{F}{100}) %.

Details of Option Bits

Explanation of settings linked to each bit of the option bits value.

00000001: Enable Transmission to Repeater

Enables transmission not only to the parent but also to repeaters.

You can use repeaters even without setting this option, but the parent will remove duplicated packets. In this case, there is no way to determine which repeater the packet passed through or if it was not relayed.

If this option is set, the parent can output packets received from multiple devices separately. Devices connected to the parent can analyze the output to determine which device the child was near.

00001000: Enable Encrypted Communication

Enables encrypted communication. The other party must also enable encrypted communication.

00010000: Enable UART Output on Child

Enables message output on the child device.

Details of Sensor-specific Parameters

Explanation of settings linked to the sensor-specific parameter value.

Open/Close Sensor Pal

Not used.

Environmental Sensor Pal

Not used.

Motion Sensor Pal

Specify a 32-bit value.

bit31-2827-2423-2019-1615-1211-87-43-0
Function----ATHSFQSCT:7-4SCT:3-0
Default00000000

Each function represents the following:

NameItemDescription
SCTSample CountNumber of acceleration samples
SFQSampling FrequencySampling frequency of acceleration
ATHActive Detection ModeAcceleration threshold, 0 disables

SCT: Sample Count

SCT affects the number of samples transmitted.

Intermittent Transmission Mode

When ATH is 0 and t: Transmission Interval is non-zero, intermittent transmission mode is active.

If SCT value is (C_i), the sample count is represented as (16C_i+16).

pSCTSample Count
0x??????000x0016 samples (default)
0x??????010x0132 samples
0x??????070x07128 samples
0x??????FF0xFF4096 samples
Active Detection Mode

When ATH and t: Transmission Interval are both non-zero, active detection mode is active.

In active detection mode, when acceleration exceeds the threshold given by ATH, it transmits the samples immediately after, in addition to the previous 30 samples.

If SCT value is (C_a), the number of subsequent samples is (30C_a+30).

pSCTSubsequent Sample Count
0x??????000x0030 samples (default)
0x??????010x0160 samples
0x??????070x07240 samples
0x??????FF0xFF7680 samples

SFQ: Sampling Frequency

SFQ affects the sampling frequency of acceleration data.

pSFQSampling Frequency
0x?????0??0x025Hz (default)
0x?????1??0x150Hz
0x?????2??0x2100Hz
0x?????3??0x3190Hz

ATH: Active Detection Mode

ATH affects the behavior of active detection mode.

0 disables it. Values 1-F enable it with the value as the threshold.

pATHDescription
0x????0???0x0Disabled (default)
0x????1???0x11G (not recommended)
0x????2???0x22G
0x????F???0xF15G

Notification Pal

Specify a 32-bit value.

pDescription
0x00000000Tap & Shake Mode
0x00000001Dice Mode

00000000: Tap & Shake Mode

Sends data when tapped or shaken.

00000001: Dice Mode

Detects six different top faces and sends data.

Notification Event Details

The value is binary data up to 68 bytes, represented as a hexadecimal string.

One event consists of 4 bytes. The maximum number of events is 17.

#DataDescriptionRemarks
1st event
0uint8Event ID0x00-0x10
1uint8Red and Green BrightnessRed 0x0?-0xF?, Green 0x?0-0x?F
2uint8Blue and White BrightnessBlue 0x0?-0xF?, White 0x?0-0x?F
3uint8Blink Pattern and On Time
Blink PatternSteady 0x0?, Slow 0x1?, Medium 0x2?, Fast 0x3?
On TimeNo off 0x?0, Seconds specified 0x?1-0x?F
2nd event
4uint8Event ID0x01-0x10
5uint8Red and Green BrightnessRed 0x0?-0xF?, Green 0x?0-0x?F
6uint8Blue and White BrightnessBlue 0x0?-0xF?, White 0x?0-0x?F
7uint8Blink Pattern and On Time
Blink PatternSteady 0x0?, Slow 0x1?, Medium 0x2?, Fast 0x3?
On TimeNo off 0x?0, Seconds specified 0x?1-0x?F
3rd event
17th event
64uint8Event ID0x01-0x10
65uint8Red and Green BrightnessRed 0x0?-0xF?, Green 0x?0-0x?F
66uint8Blue and White BrightnessBlue 0x0?-0xF?, White 0x?0-0x?F
67uint8Blink Pattern and On Time
Blink PatternSteady 0x0?, Slow 0x1?, Medium 0x2?, Fast 0x3?
On TimeNo off 0x?0, Seconds specified 0x?1-0x?F

Example Configuration Data

An example of the default setting is shown.

0180002A0208002A0300802A0488002A0580802A0608802A0880000A1008000A
#DataDescriptionValue
1st event
010uint8Event ID0x01
801uint8Red and Green BrightnessRed 8/15, Green 0/15
002uint8Blue and White BrightnessBlue 0/15, White 0/15
2A3uint8Blink Pattern and On TimeMedium, 10 seconds
2nd event
024uint8Event ID0x02
085uint8Red and Green BrightnessRed 0/15, Green 8/15
006uint8Blue and White BrightnessBlue 0/15, White 0/15
2A7uint8Blink Pattern and On TimeMedium, 10 seconds
3rd event
8th event
1028uint8Event ID0x10
0829uint8Red and Green BrightnessRed 0/15, Green 8/15
0030uint8Blue and White BrightnessBlue 0/15, White 0/15
0A31uint8Blink Pattern and On TimeSteady, 10 seconds

4 - act Samples

Sample programs for act
The MWSDK/Act_Samples directory contains sample programs for act.

4.1 - act Samples

Latest Edition
The MWSDK/Act_Samples directory contains sample programs for act.

Introduction to Samples

Below are acts introduced by purpose.

Short acts using only microcontroller functions without wireless communication

act0..4

These are very simple examples that do not use wireless functions. You can understand the basic structure of act.

Example of act description using I2C sensor

This is an example of a wireless sensor implementation that connects an I2C sensor and sends wireless packets while operating simply with sleep.

BRD_I2C_TEMPHUMID

Includes typical elements for implementing wireless sensors with TWELITE (use of simple relay network <NWK_SIMPLE>, interactive mode <STG_STD>, handling of I2C sensor Wire, intermittent operation by sleep, etc.).

Basic acts that perform wireless communication

These are samples that send or send/receive wireless packets, each implemented from slightly different perspectives.

Scratch

A simple code that receives a 1-byte command from UART and performs transmission etc.

Slp_Wk_and_Tx

Uses a state machine and intermittent operation with sleep, repeating sleep wake-up → wireless transmission → sleep.

PingPong

A sample that sends packets from one side to the other, and the receiver sends back packets. It includes basic procedures for sending and receiving.

WirelessUART

Interprets ASCII format using serparser from UART input and then transmits it.

Acts for the parent device side

Please refer when implementing your own receiving parent application.

Parent-MONOSTICK

Only receives and outputs the reception result to the serial port. It can receive wireless packets addressed to the parent device (0x00) or child broadcast (0xFE). It also includes procedures to add interactive mode <STG_STD> to act.

Rcv_Univsl

Sample code for a universal packet receiver (TWENET layer tree network, App_Twelite, act, etc.). It also uses the EASTL library for containers and algorithms.

Acts for adding interactive mode

The explanation of acts using interactive mode describes the general flow (here quoting the above BRD_I2C_TEMPHUMID). There is not much difference in the explanation of any sample.

BRD_I2C_TEMPHUMID

Executes read/write commands for I2C sensor devices and wirelessly transmits measurement values obtained from the I2C sensor. It also includes procedures to add interactive mode <STG_STD> to act.

Settings

Performs more advanced customization of interactive mode <STG_STD>. Please refer to the code for details.

Acts for operating sensors and other devices

Samples that obtain sensor information from built-in peripherals or external sensor devices.

BRD_APPTWELITE

Performs two-way communication using digital input, analog input, digital output, and analog output. It also includes procedures to add interactive mode <STG_STD> to act.

BRD_I2C_TEMPHUMID

Executes read/write commands for I2C sensor devices and wirelessly transmits measurement values obtained from the I2C sensor. It also includes procedures to add interactive mode <STG_STD> to act.

PulseCounter

Uses the pulse counter function to count pulses detected at the input port, including during sleep, and wirelessly transmits them.

PAL_AMB_behavior

An example using behavior. In PAL_AMB, the temperature and humidity sensor is called inside the library code, but this sample includes its own procedures for accessing the temperature and humidity sensor.

Acts for using TWELITE PAL

TWELITE PAL has standard PAL apps written, but you can also write acts without using PAL apps. The MWX library provides standard procedures for operating sensors used in PAL.

Samples for various PAL boards. They obtain sensor values on PAL boards, transmit, and sleep.

  • PAL_AMB
  • PAL_MOT-single
  • PAL_MAG

The following are advanced examples with slightly more complex descriptions than the above acts.

  • PAL_AMB_usenap is a sample aiming for lower power by putting the TWELITE microcontroller to sleep briefly during the tens of milliseconds sensor operation time.
  • PAL_AMB_behavior is an example using behavior. In PAL_AMB, the temperature and humidity sensor is called inside the library code, but this sample includes its own procedures for accessing the temperature and humidity sensor.
  • PAL_MOT_fifo is a sample that continuously acquires and wirelessly transmits acceleration sensor FIFO data and FIFO interrupts without interrupting the sample.

Acts for using TWELITE CUE

The PAL_MOT act is available. Minor modifications may be required.

  • PAL_MOT-single
  • PAL_MOT_fifo is a sample that continuously acquires and wirelessly transmits acceleration sensor FIFO data and FIFO interrupts without interrupting the sample.

Acts for using TWELITE ARIA

  • BRD_ARIA is an act for operating TWELITE ARIA.
  • BRD_I2C_TEMPHUMID is a template for using I2C sensors, but includes code for the SHT40 sensor used with TWELITE ARIA as an implementation example.
  • Can be used by modifying acts for PAL_AMB.

Acts introducing individual functions

Unit-* are intended to introduce functions and APIs.

Obtaining the Latest Edition

Common Descriptions

The following items are common settings in act samples and are explained below.

const uint32_t APP_ID = 0x1234abcd;
const uint8_t CHANNEL = 13;
const char APP_FOURCHAR[] = "BAT1";

4.1.1 - act0..4

Simple acts to try first

The acts starting from act0 included here are introduced in Starting with act - Opening act. They are simple acts that only operate LEDs and buttons, but we recommend trying them first.

act0

A template with no processing description

act1

LED blinking

act2

LED blinking with a timer

act3

LED blinking with 2 timers

act4

LED lighting using a button (switch)

4.1.2 - Scratch

Template code
This is a template act.

setup()

void setup() {
	/*** SETUP section */
	tx_busy = false;

	// the twelite main class
	the_twelite
		<< TWENET::appid(APP_ID)    // set application ID (identify network group)
		<< TWENET::channel(CHANNEL) // set channel (physical channel)
		<< TWENET::rx_when_idle();  // open receive circuit (if not set, it can't listen packets from others)

	// Register Network
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();
	nwk	<< NWK_SIMPLE::logical_id(0xFE); // set Logical ID. (0xFE means a child device with no ID)

	/*** BEGIN section */
	Buttons.begin(pack_bits(PIN_BTN), 5, 10); // check every 10ms, a change is reported by 5 consecutive values.

	the_twelite.begin(); // start twelite!

	/*** INIT message */
	Serial << "--- Scratch act ---" << mwx::crlf;
}

Configure the_twelite with application ID APP_ID, wireless channel CHANNEL, and enable reception.

Also, generate nwk and specify child address 0xFE. This address means a child device without a specified address.

Also, initialize the Buttons object. This is a chatter suppression algorithm using consecutive references. If the same value is detected 5 times consecutively every 10ms, the port (only PIN_BTN) is confirmed as HIGH or LOW. The function pack_bits(N1, N2, ..) generates a bitmap by 1UL<<N1 | 1UL << N2 | ....

the_twelite.begin(); // start twelite!

This is the procedure to start the_twelite. Although it did not appear in act0..4, if you configure the_twelite or register various behaviors, always call this.

begin()

void begin() {
	Serial << "..begin (run once at boot)" << mwx::crlf;
}

Called only once after setup() at startup. Only displays a message.

loop()

Button (switch) input detection

if (Buttons.available()) {
	uint32_t bm, cm;
	Buttons.read(bm, cm);

	if (cm & 0x80000000) {
		// the first capture.
	}

	Serial << int(millis()) << ":BTN" << format("%b") << mwx::crlf;
}

Using consecutive references by Buttons, the state is confirmed. When the button state changes, output to serial.

Input from serial

while(Serial.available()) {
  int c = Serial.read();

	Serial << '[' << char(c) << ']';

  switch(c) {
  case 'p': ... // Display millis()
  case 't': ... // Send wireless packet (vTransmit)
        if (!tx_busy) {
					tx_busy = Transmit();
					if (tx_busy) {
						Serial  << int(millis()) << ":tx request success! ("
										<< int(tx_busy.get_value()) << ')' << mwx::crlf;
 					} else {
						Serial << int(millis()) << ":tx request failed" << mwx::crlf;;
					}
				}
  case 's': ... // Sleep
				Serial << int(millis()) << ":sleeping for " << 5000 << "ms" << mwx::crlf << mwx::flush;
				the_twelite.sleep(5000);
				break;
  }
}

If Serial.available() is true, input is stored from the serial port. Read one character from serial and process according to the input character.

Input ’t’ to send wireless

When ’t’ is input, transmission is performed. This sample uses a tx_busy flag to avoid continuous input.

Input ’s’ to sleep

the_twelite.sleep(5000);

Sleep for 5000ms = 5 seconds. After waking up, wakeup() is executed.

wakeup()

void wakeup() {
	Serial << int(millis()) << ":wake up!" << mwx::crlf;
}

Called first upon waking from sleep. Only displays a message.

Transmit()

MWX_APIRET Transmit() {
	Serial << int(millis()) << ":Transmit()" << mwx::crlf;

	if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {
		// set tx packet behavior
		pkt << tx_addr(0xFF)  // Broadcast communication
			<< tx_retry(0x1)    // Retry once
			<< tx_packet_delay(100,200,20); // Transmit delay between 100-200ms, retry interval 20ms

		// Specify transmission data (decided by application)
		pack_bytes(pkt.get_payload()
			, make_pair("SCRT", 4) // 4-character identifier
			, uint32_t(millis())   // Timestamp
		);

		// Request transmission
		return pkt.transmit();
	} else {
		// Failed at .prepare_tx_packet() stage (transmission queue full)
		Serial << "TX QUEUE is FULL" << mwx::crlf;
	  return MWX_APIRET(false, 0);
	}
}

Minimal procedure to request transmission.

At the time this function exits, the request has not yet been executed. You need to wait a while. In this example, a delay of 100-200ms before transmission start is set, so transmission will start at the earliest 100ms later.

on_tx_comp()

void on_tx_comp(mwx::packet_ev_tx& ev, bool_t &b_handled) {
	Serial 	<< int(millis()) << ":tx completed!"
			<< format("(id=%d, stat=%d)", ev.u8CbId, ev.bStatus) << mwx::crlf;
	tx_busy = false; // clear tx busy flag.
}

Called when transmission completes. ev contains transmission ID and completion status.

on_rx_packet()

void on_rx_packet(packet_rx& rx, bool_t &handled) {
	Serial << format("rx from %08x/%d",
					rx.get_addr_src_long(), rx.get_addr_src_lid()) << mwx::crlf;
}

When a packet is received, display the sender’s address information.

4.1.3 - Slp_Wk_and_Tx

Transmits a packet upon waking from sleep
Slp_Wk_and_Tx is a template source code intended for applications that perform some execution (such as sensor data acquisition) after periodic wake-up, and transmit the result as a wireless packet.

In the form of setup() and loop(), complex conditional branches tend to occur in loop(), making it difficult to read. In this act, the code readability is improved by using the SM_SIMPLE state machine with a simple _switch_ syntax for state transitions inside loop().

Functionality of the Act

  • After startup, go through initialization and then sleep once
    1. Initialize in setup()
    2. Execute sleep in begin()
  • After waking from sleep, initialize state variables and perform the following steps in order:
    1. wakeup() wakes from sleep and performs initialization
    2. loop() transitions state from INIT to WORK_JOB: performs some processing (in this act, updates a counter every 1ms TickCount and proceeds to TX state after a random count)
    3. loop() state TX requests transmission
    4. loop() state WAIT_TX waits for transmission completion
    5. loop() state EXIT_NORMAL goes to sleep (returns to 1.)
  • If an error occurs, loop() state EXIT_FATAL resets the module

Explanation of the Act

Declaration Section

Includes

#include <TWELITE>
#include <NWK_SIMPLE>
#include <SM_SIMPLE>

#include "Common.h"

<NWK_SIMPLE> is included to perform packet transmission. Basic definitions such as application ID are described in "Common.h".

State Definitions

To describe sequential processing inside loop(), this sample uses the concept of a state machine (state transitions). It uses <SM_SIMPLE>, which summarizes very simple state transitions.

The enumeration STATE corresponding to the following states is defined in Common.h.

enum class STATE {
    INIT = 0,    // INIT STATE
    WORK_JOB,    // do some job (e.g sensor capture)
    TX,          // reuest transmit
    WAIT_TX,     // wait its completion
    EXIT_NORMAL, // normal exiting.
    EXIT_FATAL   // has a fatal error (will do system reset)
};

Declare the SM_SIMPLE state machine (state transitions) using the enumeration STATE that represents states.

SM_SIMPLE<STATE> step;

The declared step includes functions for state management, timeouts, and waiting for processing.

Sensor Data

This sample does not process sensor data but prepares dummy data.

struct {
	uint16_t dummy_work_ct_now;
	uint16_t dummy_work_ct_max;  // counter for dummy work job.
} sensor;

setup()

void setup() {
	/*** SETUP section */
	step.setup(); // init state machine

	// the twelite main class
	the_twelite
		<< TWENET::appid(APP_ID)    // set application ID (identify network group)
		<< TWENET::channel(CHANNEL) // set channel (pysical channel)
		<< TWENET::rx_when_idle(false);  // open receive circuit (if not set, it can't listen packts from others)

	// Register Network
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();
	nwk	<< NWK_SIMPLE::logical_id(DEVICE_ID); // set Logical ID.

	/*** BEGIN section */
	the_twelite.begin(); // start twelite!

	/*** INIT message */
	Serial << "--- Sleep an Tx Act ---" << crlf;
}

Initializes variables and class objects.

  • Initializes the step state machine
  • Initializes the the_twelite class object
  • Registers and initializes the network <NWK_SIMPLE> (registers DEVICE_ID)

Next, starts the class object and hardware.

the_twelite.begin(); // start twelite!

This procedure starts the_twelite. Although not shown in act0..4, when setting configurations or registering behaviors of the_twelite, always call this.

begin()

void begin() {
	Serial << "..begin (run once at boot)" << crlf;
	SleepNow();
}

Called once immediately after setup(). Calls SleepNow() to perform the initial sleep procedure.

wakeup()

void wakeup() {
 memset(&sensor, 0, sizeof(sensor));
	Serial << crlf << int(millis()) << ":wake up!" << crlf;
}

Called immediately after waking up. Here, it initializes the sensor data area and outputs a wake-up message.

loop()

void loop() {
	do {
		switch(step.state()) {
		case STATE::INIT:
			sensor.dummy_work_ct_now = 0;
			sensor.dummy_work_ct_max = random(10,1000);
			step.next(STATE::WORK_JOB);
		break;

		...
		}
	} while (step.b_more_loop());
}

The above code is a simplified version of the actual code.

This control structure uses the SM_SIMPLE state machine. It is a do..while() loop. Inside the loop is a switch case statement that branches processing based on the state obtained from .state(). State transitions are done by calling .next() which writes a new state value to an internal variable in the state machine.

step.b_more_loop() is set to true when a state transition occurs by .next(). This is to execute the next state’s code (case clause) without exiting loop() when a state transition occurs.

The following explains each state.

STATE::INIT

sensor.dummy_work_ct_now = 0;
sensor.dummy_work_ct_max = random(10,1000);

step.next(STATE::WORK_JOB);

Initializes dummy sensor values. One is an increment counter, the other is a randomly determined stop count.

STATE::WORK_JOB

if (TickTimer.available()) {
	Serial << '.';
	sensor.dummy_work_ct_now++;
	if (sensor.dummy_work_ct_now >= sensor.dummy_work_ct_max) {
		Serial << crlf;
		step.next(STATE::TX);
	}
}

In the WORK_JOB state, processing is done at 1ms timer intervals. TickTimer.available() becomes true at each tick timer. The counter is incremented at each tick timer, and when it reaches dummy_work_ct_max, it transitions to the next state STATE::TX.

STATE::TX

if (Transmit()) {
	Serial << int(millis()) << ":tx request success!" << crlf;
	step.set_timeout(100);
	step.clear_flag();
	step.next(STATE::WAIT_TX);
} else {
	// normall it should not be here.
	Serial << int(millis()) << "!FATAL: tx request failed." << crlf;
	step.next(STATE::EXIT_FATAL);
}

Calls the Transmit() function to request packet transmission. If the request succeeds, it transitions to STATE::WAIT_TXEVENT to wait for transmission completion. Here, the timeout and flag functions of the SM_SIMPLE state machine are used for the wait loop (a simple judgment based on variable changes during the wait loop).

A single transmission request failure is usually not expected, but if it fails, it transitions to the exceptional state STATE::EXIT_FATAL.

STATE::WAIT_TX

if (step.is_flag_ready()) {
	Serial << int(millis()) << ":tx completed!" << crlf;
	step.next(STATE::EXIT_NORMAL);
} else if (step.is_timeout()) {
	Serial << int(millis()) << "!FATAL: tx timeout." << crlf;
	step.next(STATE::EXIT_FATAL);
}

Waiting for transmission completion is judged by setting the flag in the state machine function by on_tx_comp() described later. Timeout is judged by calling .is_timeout(), which checks the elapsed time since .set_timeout() was called.

Whether transmission succeeds or fails, a completion notification usually exists, but a timeout is set to transition to the exceptional state STATE::EXIT_FATAL.

STATE::EXIT_NORMAL

SleepNow();

Calls SleepNow() to enter sleep processing.

STATE::EXIT_FATAL

Serial << crlf << "!FATAL: RESET THE SYSTEM.";
delay(1000); // wait a while.
the_twelite.reset_system();

Performs a system reset as a critical error.

SleepNow()

void SleepNow() {
	uint16_t u16dur = SLEEP_DUR;
	u16dur = random(SLEEP_DUR - SLEEP_DUR_TERMOR, SLEEP_DUR + SLEEP_DUR_TERMOR);

	Serial << int(millis()) << ":sleeping for " << int(u16dur) << "ms" << crlf;
	Serial.flush();

	step.on_sleep(); // reset status of statemachine to INIT state.

	the_twelite.sleep(u16dur, false);
}

Performs periodic sleep. The sleep duration is randomized using the random() function to create some jitter. This is because if multiple devices synchronize their transmission cycles, the failure rate may increase significantly.

Before sleeping, the SM_SIMPLE state machine’s state is set to INIT by calling .on_sleep().

Transmit()

MWX_APIRET vTransmit() {
	Serial << int(millis()) << ":vTransmit()" << crlf;

	if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {
		// set tx packet behavior
		pkt << tx_addr(0x00)  // 0..0xFF (LID 0:parent, FE:child w/ no id, FF:LID broad cast), 0x8XXXXXXX (long address)
			<< tx_retry(0x1) // set retry (0x3 send four times in total)
			<< tx_packet_delay(0,0,2); // send packet w/ delay (send first packet with randomized delay from 0 to 0ms, repeat every 2ms)

		// prepare packet payload
		pack_bytes(pkt.get_payload() // set payload data objects.
			, make_pair(FOURCC, 4) // string should be paired with length explicitly.
			, uint32_t(millis()) // put timestamp here.
			, uint16_t(sensor.dummy_work_ct_now) // put dummy sensor information.
		);

		// do transmit
		//return nwksmpl.transmit(pkt);
		return pkt.transmit();
	}

	return MWX_APIRET(false, 0);
}

Requests wireless packet transmission to the parent device with ID=0x00. The stored data includes the 4-character identifier (FOURCC) commonly used in Act samples, the system time [ms], and the dummy sensor value (sensor.dummy_work_ct_now).

First, obtains an object to store the transmission packet. Operates this object to set transmission data and conditions.

if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {

In the MWX library, the object is obtained inside an if statement, and the object’s bool evaluation is used to proceed if true.

Here, the board object is obtained by the_twelite.network.use<NWK_SIMPLE>(), and the packet object is obtained by calling .prepare_tx_packet() on the board object. Failure to obtain the packet object is usually unexpected but occurs if the transmission queue is full and cannot accept transmission requests. This sample only sends a single transmission, so errors are limited to serious unexpected problems.

pkt << tx_addr(0x00) // Destination
		<< tx_retry(0x1) // Retry count
		<< tx_packet_delay(0,0,2); // Transmission delay

Sets transmission conditions (destination, retry, etc.) using the << operator on the obtained pkt object.

tx_addr specifies the packet destination. tx_retry is the retry count. tx_packet_delay specifies transmission delay.

pack_bytes(pkt.get_payload() // set payload data objects.
	, make_pair(FOURCC, 4) // string should be paired with length explicitly.
	, uint32_t(millis()) // put timestamp here.
	, uint16_t(sensor.dummy_work_ct_now) // put dummy sensor information.
);

The packet payload (data part) is an array derived from smblbuf<uint8_t> obtained by pkt.get_payload(). You can directly set values to this array, but here the pack_bytes() function is used to set values.

This function takes a variable number of arguments. The first parameter is the array object obtained from .get_payload().

  • make_pair(FOURCC,4): make_pair is from the C++ standard library and creates a std::pair object. For a string type, it means writing 4 bytes from the beginning explicitly. (Strings can be confusing regarding including or excluding the terminator, so here the number of bytes to write is explicitly specified.)
  • Specifying a uint32_t type writes 4 bytes in big-endian order.
  • The same applies for uint16_t data.

Finally, calls .transmit() to request transmission. The return type is MWX_APIRET. After the request, actual transmission occurs, which may take several ms to tens of ms depending on parameters and size. on_tx_comp() is called upon completion.

return pkt.transmit();

on_tx_comp()

void on_tx_comp(mwx::packet_ev_tx& ev, bool_t &b_handled) {
	step.set_flag(ev.bStatus);
}

This system event is called upon transmission completion. Here, .set_flag() is called to mark completion.

4.1.4 - Parent_MONOSTICK

Parent application (for MONOSTICK)
This act uses MONOSTICK as the parent device. It outputs the data payload of packets from child devices to the serial port. You can display packets from many sample acts.

Act Features

  • Receives packets from child devices of sample acts and outputs them to the serial port.

How to Use the Act

Required TWELITE and Wiring

RoleExample
Parent deviceMONOSTICK BLUE/RED
Child deviceTWELITE series set as child devices in sample acts
(e.g., Slp_Wk_and_Tx, PAL_AMB, PAL_MAG, PAL_MOT???, etc.)

Please check initially with the following default settings.

  • Application ID: 0x1234abcd
  • Channel: 13

Explanation of the Act

Declaration Section

Include

// use twelite mwx c++ template library
#include <TWELITE>
#include <MONOSTICK>
#include <NWK_SIMPLE>
#include <STG_STD>

Includes the board behavior <MONOSTICK> for MONOSTICK. This board support includes LED control and watchdog support.

  • <NWK_SIMPLE> loads definitions for a simple relay network
  • <STG_STD> loads definitions for interactive mode.

Others

// application ID
const uint32_t DEFAULT_APP_ID = 0x1234abcd;
// channel
const uint8_t DEFAULT_CHANNEL = 13;
// option bits
uint32_t OPT_BITS = 0;

/*** function prototype */
bool analyze_payload(packet_rx& rx);

Declares default values and function prototypes.

setup()

auto&& brd = the_twelite.board.use<MONOSTICK>();
auto&& set = the_twelite.settings.use<STG_STD>();
auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();

In setup(), first load <MONOSTICK> board behavior, <STG_STD> interactive mode behavior, and <NWK_SIMPLE> behavior using use<>. This procedure must be done inside setup().

set << SETTINGS::appname("PARENT"); // Title displayed in the settings screen
set << SETTINGS::appid_default(DEFAULT_APP_ID); // Default application ID
set << SETTINGS::ch_default(DEFAULT_CHANNEL); // Default channel
set << SETTINGS::lid_default(0x00); // Default LID
set.hide_items(E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);
set.reload(); // Load settings from non-volatile memory
OPT_BITS = set.u32opt1(); // Example of reading (option bits)

Next, set the interactive mode settings and read the settings. <STG_STD> interactive mode provides standard items but allows some customization for each act.

  • appname → Act name displayed in the title line of the settings screen
  • appid_default → Default application ID
  • ch_default → Default channel
  • lid_default → Default device ID (LID)
  • .hide_items() → Hide specific items

Always call .reload() before reading settings. Methods like .u32opt1() are provided for each setting.

the_twelite
	<< set                    // Apply interactive mode settings
	<< TWENET::rx_when_idle() // Specify to receive
	;

// Register Network
nwk << set;							// Apply interactive mode settings
nwk << NWK_SIMPLE::logical_id(0x00) // Re-set only LID
	;

Some settings can be directly applied using the <STG_STD> object. Also, if you want to overwrite certain values due to DIP switch settings, you can change them after applying settings. In the example above, application ID, channel, and wireless output are set on the_twelite object, and LID and retransmission count are set on nwk object, then LID is reset to 0.

brd.set_led_red(LED_TIMER::ON_RX, 200); // RED (on receiving)
brd.set_led_yellow(LED_TIMER::BLINK, 500); // YELLOW (blinking)

The <MONOSTICK> board behavior provides procedures for LED control.

The first line sets the red LED to light for 200ms when a wireless packet is received. The first parameter LED_TIMER::ON_RX means “on receiving a wireless packet”. The second parameter specifies the lighting time in ms.

The second line sets the LED to blink. The first parameter LED_TIMER::BLINK means blinking, and the second parameter is the ON/OFF switching time. The LED will turn on and off every 500ms (i.e., blinking with a 1-second cycle).

the_twelite.begin(); // start twelite!

Procedure to start the_twelite. Although it did not appear in act0..4, if you configure the_twelite or register various behaviors, always call this.

loop()

There is no processing inside loop() in this sample.

void loop() {
}

on_rx_packet()

This callback function is called when a packet is received. In this example, several outputs are made for the received packet data.

void on_rx_packet(packet_rx& rx, bool_t &handled) {
	Serial << ".. coming packet (" << int(millis()&0xffff) << ')' << mwx::crlf;

  ...

	// packet analyze
	analyze_payload(rx);
}
analyze_payload

The analyze_payload() called at the end of the function contains code to interpret packets from several sample acts. Please refer to the packet generation part in the sample acts for correspondence.

bool b_handled = false;

uint8_t fourchars[4]{};
auto&& np = expand_bytes(
	    rx.get_payload().begin(), rx.get_payload().end()
		, fourchars
    );

if (np == nullptr) return;

// display fourchars at first
Serial
	<< fourchars
	<< format("(ID=%d/LQ=%d)", rx.get_addr_src_lid(), rx.get_lqi())
	<< "-> ";

This function first reads 4-character identification data into the fourchars[5] array.

Reading is done using the expand_bytes() function. The first and second parameters follow the C++ standard library convention, giving the starting pointer .begin() and the pointer just after the end .end() of the received packet’s payload part. The following parameters are variadic arguments specifying the data variables to read. The return value is nullptr on error, otherwise the next interpretation pointer. If parsing reaches the end, .end() is returned. Here the parameter is uint8_t fourchars[4].

Next, process corresponding to the 4-byte header is performed. Here, the packet of the sample act Slp_Wk_and_Tx is interpreted and displayed.

// Slp_Wk_and_Tx
if (!b_handled && !strncmp(fourchars, "TXSP", 4)) {
	b_handled = true;
	uint32_t tick_ms;
	uint16_t u16work_ct;

	np = expand_bytes(np, rx.get_payload().end()
		, tick_ms
		, u16work_ct
	);

	if (np != nullptr) {
		Serial << format("Tick=%d WkCt=%d", tick_ms, u16work_ct);
	} else {
		Serial << ".. error ..";
	}
}

Set b_handled to true to skip other interpretation parts.

The "TXSP" packet contains a uint32_t system timer count and a uint16_t dummy counter value. Declare each variable and read them using expand_bytes(). The difference from above is that the first parameter for reading is np. Provide tick_ms and u16work_ct as parameters, reading values stored in big-endian byte sequence in the payload.

If reading succeeds, output the contents and finish.

Define and output a custom ASCII format

Construct ASCII format in the user-defined order.

smplbuf_u8<128> buf;
mwx::pack_bytes(buf
	, uint8_t(rx.get_addr_src_lid())		   // Source logical ID
	, uint8_t(0xCC)											   // 0xCC
	, uint8_t(rx.get_psRxDataApp()->u8Seq) // Packet sequence number
	, uint32_t(rx.get_addr_src_long())		 // Source serial number
	, uint32_t(rx.get_addr_dst())			     // Destination address
	, uint8_t(rx.get_lqi())					       // LQI: reception quality
	, uint16_t(rx.get_length())				     // Number of bytes following
	, rx.get_payload() 						         // Data payload
);

serparser_attach pout;
pout.begin(PARSER::ASCII, buf.begin(), buf.size(), buf.size());

Serial << "FMT PACKET -> ";
pout >> Serial;
Serial << mwx::flush;

The first line declares a local object buffer to store the data sequence before converting to ASCII format.

The second line uses pack_bytes() to store the data sequence into the buf. See source code comments for data structure. The parameter of pack_bytes() can be a container of type smplbuf_u8 (smplbuf<uint8_t, ???>).

Lines 13, 14, and 17 declare the serial parser, configure it, and output.

Dump output including NWK_SIMPLE header

The first output (disabled by if(0)) displays all data including control data of <NWK_SIMPLE>. The control data is 11 bytes. Normally, control information is not directly referenced but shown here for reference.

serparser_attach pout;
pout.begin(PARSER::ASCII, rx.get_psRxDataApp()->auData,
    rx.get_psRxDataApp()->u8Len, rx.get_psRxDataApp()->u8Len);

Serial << "RAW PACKET -> ";
pout >> Serial;
Serial << mwx::flush;

// Reference: Packet structure of control part
// uint8_t  : 0x01 fixed
// uint8_t  : Source LID
// uint32_t : Source long address (serial number)
// uint32_t : Destination address
// uint8_t  : Relay count

The first line declares a serial parser local object for output. It does not have an internal buffer and uses an external buffer, leveraging the parser’s output function to output the byte sequence in the buffer as ASCII.

The second line sets the buffer of the serial parser. It specifies the existing data array, i.e., the payload part of the received packet. serparser_attach pout declares a serial parser using an existing buffer. The first parameter of pout.begin() specifies the parser format as PARSER::ASCII (ASCII format). The second parameter is the start address of the buffer. The third is the valid data length in the buffer, and the fourth is the maximum buffer length. The fourth parameter is the same as the third since it is used only for output, not for format interpretation.

Line 6 outputs to the serial port using the >> operator.

Line 7 Serial << mwx::flush waits for the output of any remaining data to complete. (Equivalent to Serial.flush())

4.1.5 - PingPong

Send and receive packets
If you send a PING wireless packet from one of two serially connected TWELITE devices, the other will return a PONG wireless packet.

How to Use the Act

Required TWELITE

Prepare two units of any of the following:

  • MONOSTICK BLUE / RED
  • TWELITE R Series with UART-connected TWELITE DIP, etc.

Explanation of the Act

Declarations

Includes

// use twelite mwx c++ template library
#include <TWELITE>
#include <NWK_SIMPLE>

Include <TWELITE> in all acts. Here, we also include the simple network <NWK_SIMPLE>.

Others

// application ID
const uint32_t APP_ID = 0x1234abcd;

// channel
const uint8_t CHANNEL = 13;

// DIO pins
const uint8_t PIN_BTN = 12;

/*** function prototype */
void vTransmit(const char* msg, uint32_t addr);

/*** application defs */
// packet message
const int MSG_LEN = 4;
const char MSG_PING[] = "PING";
const char MSG_PONG[] = "PONG";
  • Common declarations for the sample act
  • Function prototypes for longer processing (transmit and receive)
  • Variables for holding data within the application

setup()

void setup() {
	/*** SETUP section */
	Buttons.setup(5); // init button manager with 5 history table.
	Analogue.setup(true, 50); // setup analogue read (check every 50ms)

	// the twelite main class
	the_twelite
		<< TWENET::appid(APP_ID)    // set application ID (identify network group)
		<< TWENET::channel(CHANNEL) // set channel (pysical channel)
		<< TWENET::rx_when_idle();  // open receive circuit (if not set, it can't listen packts from others)

	// Register Network
	auto&& nwksmpl = the_twelite.network.use<NWK_SIMPLE>();
	nwksmpl << NWK_SIMPLE::logical_id(0xFE) // set Logical ID. (0xFE means a child device with no ID)
	        << NWK_SIMPLE::repeat_max(3);   // can repeat a packet up to three times. (being kind of a router)

	/*** BEGIN section */
	Buttons.begin(pack_bits(PIN_BTN), 5, 10); // check every 10ms, a change is reported by 5 consequent values.
	Analogue.begin(pack_bits(PIN_ANALOGUE::A1, PIN_ANALOGUE::VCC)); // _start continuous adc capture.

	the_twelite.begin(); // start twelite!

	/*** INIT message */
	Serial << "--- PingPong sample (press 't' to transmit) ---" << mwx::crlf;
}

The general flow is initial setup for each part, then starting each part.

the_twelite

This object is the core class for operating TWENET.

	// the twelite main class
	the_twelite
		<< TWENET::appid(APP_ID)    // set application ID (identify network group)
		<< TWENET::channel(CHANNEL) // set channel (pysical channel)
		<< TWENET::rx_when_idle();  // open receive circuit (if not set, it can't listen packts from others)

To apply settings to the_twelite, use <<.

  • TWENET::appid(APP_ID) Specify the application ID
  • TWENET::channel(CHANNEL) Specify the channel
  • TWENET::rx_when_idle() Open the receive circuit

Next, register the network.

auto&& nwksmpl = the_twelite.network.use<NWK_SIMPLE>();
nwksmpl << NWK_SIMPLE::logical_id(0xFE);
        << NWK_SIMPLE::repeat_max(3);

The first line registers the board, specifying <NWK_SIMPLE> in <>.

The second line sets <NWK_SIMPLE> to 0xFE (child device with no ID).

The third line specifies the maximum number of repeats. Although not covered in this explanation, when operating with multiple devices, packets can be relayed.

the_twelite.begin(); // start twelite!

At the end of the setup() function, the_twelite.begin() is executed.

Analogue

This class object handles the ADC (Analog-to-Digital Converter).

Analogue.setup(true);

Initialization is done with Analogue.setup(). The parameter true means to wait until the ADC circuit is stable.

Analogue.begin(pack_bits(PIN_ANALOGUE::A1, PIN_ANALOGUE::VCC), 50);

To start the ADC, call Analogue.begin(). The parameter is a bitmap corresponding to the ADC target pins.

Use the pack_bits() function to specify the bitmap. It’s a variadic function, and each argument specifies the bit position to set to 1. For example, pack_bits(1,3,5) returns the value 101010 in binary. Since this function is constexpr, if only constants are used as parameters, it will be expanded at compile time.

The parameters specify PIN_ANALOGUE::A1 (ADC0) and PIN_ANALOGUE::VCC (module supply voltage).

The second parameter is 50. By default, ADC operation starts with TickTimer, and except for the first time, ADC starts in the interrupt handler.

Buttons

Detects changes in DIO (digital input) values. Buttons reduces the effects of mechanical button chattering by only considering a value change after the same value has been detected for a certain number of times.

Buttons.setup(5);

Initialization is done with Buttons.setup(). The parameter 5 is the maximum number of detections required to confirm a value. Internally, memory is allocated based on this number.

Buttons.begin(pack_bits(PIN_BTN),
                  5,        // history count
                  10);      // tick delta

Start with Buttons.begin(). The first parameter is the DIO to detect. Here, PIN_BTN (12) defined in BRD_APPTWELITE:: is specified. The second parameter is the number of detections needed to confirm the state. The third is the detection interval. With 10 specified, if the same value is detected 5 times every 10ms, the state is confirmed as HIGH or LOW.

Serial

The Serial object can be used without any initialization or start procedure.

Serial << "--- PingPong sample (press 't' to transmit) ---" << mwx::crlf;

Outputs a string to the serial port. mwx::crlf is a newline character.

loop()

The loop function is called as a callback from the main loop of the TWENET library. Basically, you wait until the object you want to use becomes available and then process it. Here, we explain the usage of some objects used in this act.

void loop() {
	  // read from serial
		while(Serial.available())  {
				int c = Serial.read();
				Serial << mwx::crlf << char(c) << ':';
				switch(c) {
				    case 't':
				    	  vTransmit(MSG_PING, 0xFF);
				        break;
				    default:
							  break;
				}
		}


	// Button press
	if (Buttons.available()) {
		uint32_t btn_state, change_mask;
		Buttons.read(btn_state, change_mask);

		// Serial << fmt("<BTN %b:%b>", btn_state, change_mask);
		if (!(change_mask & 0x80000000) && (btn_state && (1UL << PIN_BTN))) {
			// PIN_BTN pressed
			vTransmit(MSG_PING, 0xFF);
		}
	}
}

Serial

		while(Serial.available())  {
				int c = Serial.read();
				Serial << mwx::crlf << char(c) << ':';
				switch(c) {
				    case 't':
				    	  vTransmit(MSG_PING, 0xFF);
				        break;
				    default:
							  break;
				}
		}

While Serial.available() is true, there is input from the serial port. The data is stored in an internal FIFO queue, so there is some buffer, but you should read it promptly. Read the data with Serial.read().

Here, when the 't' key is input, the vTransmit() function is called to send a PING packet.

Buttons

When a change in DIO (digital IO) input is detected, it becomes available, and you can read it with Buttons.read().

	if (Buttons.available()) {
		uint32_t btn_state, change_mask;
		Buttons.read(btn_state, change_mask);

The first parameter is a bitmap of the current DIO HIGH/LOW states, with DIO0,1,2,… in order from bit0. For example, for DIO12, you can check if it’s HIGH/LOW by evaluating btn_state & (1UL << 12). Bits set to 1 are HIGH.

Except for the first determination, vTransmit() is called when the PIN_BTN button is released. To trigger on the press timing, invert the condition like (!(btn_state && (1UL << PIN_BTN))).

transmit()

This function requests TWENET to send a wireless packet. When this function ends, the wireless packet has not been sent yet. The actual transmission will complete a few milliseconds later, depending on the parameters. Here, typical methods for requesting transmission are explained.

void vTransmit(const char* msg, uint32_t addr) {
	Serial << "vTransmit()" << mwx::crlf;

	if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {
		// set tx packet behavior
		pkt << tx_addr(addr)  // 0..0xFF (LID 0:parent, FE:child w/ no id, FF:LID broad cast), 0x8XXXXXXX (long address)
			<< tx_retry(0x3) // set retry (0x3 send four times in total)
			<< tx_packet_delay(100,200,20); // send packet w/ delay (send first packet with randomized delay from 100 to 200ms, repeat every 20ms)

		// prepare packet payload
		pack_bytes(pkt.get_payload() // set payload data objects.
			, make_pair(msg, MSG_LEN) // string should be paired with length explicitly.
			, uint16_t(analogRead(PIN_ANALOGUE::A1)) // possible numerical values types are uint8_t, uint16_t, uint32_t. (do not put other types)
			, uint16_t(analogRead_mv(PIN_ANALOGUE::VCC)) // A1 and VCC values (note: alalog read is valid after the first (Analogue.available() == true).)
			, uint32_t(millis()) // put timestamp here.
		);

		// do transmit
		pkt.transmit();
	}
}

Obtaining the Network Object and Packet Object

	if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {

Obtain the network object with the_twelite.network.use<NWK_SIMPLE>(). Use that object to get the pkt object with .prepare_tx_packet().

Here, the pkt object is declared within the condition of the if statement and is valid until the end of the if block. The pkt object returns a bool response: true if there is space in the TWENET transmit request queue and the request is accepted, false if there is no space.

Packet Transmission Settings

		pkt << tx_addr(addr)  // 0..0xFF (LID 0:parent, FE:child w/ no id, FF:LID broad cast), 0x8XXXXXXX (long address)
			<< tx_retry(0x3) // set retry (0x3 send four times in total)
			<< tx_packet_delay(100,200,20); // send packet w/ delay (send first packet with randomized delay from 100 to 200ms, repeat every 20ms)

Packet settings are done using the << operator, just like initializing the_twelite.

  • tx_addr() Specify the destination address as a parameter. 0x00 means send to parent if you are a child device; 0xFE means broadcast to any child device if you are a parent.
  • tx_retry() Specify the number of retries. For example, 3 means retry 3 times, so a total of 4 transmissions. Even under good conditions, a single wireless packet transmission can fail a few percent of the time.
  • tx_packet_delay() Set transmission delay. The first parameter is the minimum wait time before transmission, the second is the maximum wait time. In this case, after issuing the send request, transmission starts after a random delay between 100ms and 200ms. The third parameter is the retry interval. After the first packet is sent, retries are done every 20ms.

Packet Data Payload

Payload refers to the contents being carried. In wireless packets, it usually means the main data you want to send. Besides the main data, wireless packets also contain address and other auxiliary information.

To send and receive correctly, pay attention to the order of data in the payload. Here, we use the following data order. Build the payload according to this order.

 # Index of first byte: Data type : Byte count : Contents

00: uint8_t[4] : 4 : 4-character identifier
08: uint16_t   : 2 : ADC value of AI1 (0..1023)
06: uint16_t   : 2 : Vcc voltage value (2000..3600)
10: uint32_t   : 4 : millis() system time

Let’s actually build the data payload structure as above. The payload can be accessed as a simplbuf<uint8_t> container via pkt.get_payload(). Build the data in this container according to the above specification.

You can write it as above, but the MWX library provides a helper function pack_bytes() for building data payloads.

// prepare packet payload
pack_bytes(pkt.get_payload() // set payload data objects.
	, make_pair(msg, MSG_LEN) // string should be paired with length explicitly.
	, uint16_t(analogRead(PIN_ANALOGUE::A1)) // possible numerical values types are uint8_t, uint16_t, uint32_t. (do not put other types)
	, uint16_t(analogRead_mv(PIN_ANALOGUE::VCC)) // A1 and VCC values (note: alalog read is valid after the first (Analogue.available() == true).)
	, uint32_t(millis()) // put timestamp here.
);

pack_bytesの最初のパラメータはコンテナを指定します。この場合はpkt.get_payload()です。

そのあとのパラメータは可変数引数でpack_bytesで対応する型の値を必要な数だけ指定します。pack_bytesは内部で.push_back()メソッドを呼び出して末尾に指定した値を追記していきます。

On the third line, make_pair() is a standard library function that generates a std::pair. This avoids confusion with string types (specifically, whether to include the null character in the payload). The first parameter of make_pair() is the string type (char*, uint8_t*, uint8_t[], etc). The second parameter is the number of bytes to store in the payload.

The 4th, 5th, and 6th lines store numeric values (uint8_t, uint16_t, uint32_t). Even if you have signed numbers or char types, cast them to one of these three types before storing.

analogRead() and analogRead_mv() get the ADC results. The former returns the ADC value (0..1023), the latter returns the voltage (mV, 0..2470). The module’s supply voltage is measured internally using a resistor divider, and analogRead_mv() does the conversion.

This completes the packet preparation. Finally, request transmission.

pkt.transmit();

To send the packet, use the pkt.transmit() method of the pkt object.

on_rx_packet()

This is the process when a received packet is available.

void on_rx_packet(packet_rx& rx, bool_t &handled) {
		uint8_t msg[MSG_LEN];
		uint16_t adcval, volt;
		uint32_t timestamp;

		// expand packet payload (shall match with sent packet data structure, see pack_bytes())
		expand_bytes(rx.get_payload().begin(), rx.get_payload().end()
					, msg       // 4bytes of msg
											//   also can be -> std::make_pair(&msg[0], MSG_LEN)
					, adcval    // 2bytes, A1 value [0..1023]
				  , volt      // 2bytes, Module VCC[mV]
					, timestamp // 4bytes of timestamp
        );

		// if PING packet, respond pong!
    if (!strncmp((const char*)msg, "PING", MSG_LEN)) {
				// transmit a PONG packet with specifying the address.
        vTransmit(MSG_PONG, rx.get_psRxDataApp()->u32SrcAddr);
    }

		// display the packet
		Serial << format("<RX ad=%x/lq=%d/ln=%d/sq=%d:" // note: up to 4 args!
                    , rx.get_psRxDataApp()->u32SrcAddr
                    , rx.get_lqi()
                    , rx.get_length()
					, rx.get_psRxDataApp()->u8Seq
                    )
				<< format(" %s AD=%d V=%d TS=%dms>" // note: up to 4 args!
					, msg
					, adcval
					, volt
					, timestamp
					)
               << mwx::crlf
			   << mwx::flush;
	}

First, the received packet data is passed as the parameter rx. Access the wireless packet’s address information and data payload from rx.

while (the_twelite.receiver.available()) {
		auto&& rx = the_twelite.receiver.read();

The next line refers to information such as the sender’s address (32-bit long address and 8-bit logical address) in the received packet data.

Serial << format("..receive(%08x/%d) : ",
   rx.get_addr_src_long(), rx.get_addr_src_lid());

The MWX library provides a function expand_bytes(), which is the counterpart to pack_bytes() used in transmit().

uint8_t msg[MSG_LEN];
uint16_t adcval, volt;
uint32_t timestamp;

// expand packet payload (shall match with sent packet data structure, see pack_bytes())
expand_bytes(rx.get_payload().begin(), rx.get_payload().end()
		, msg       // 4bytes of msg
								//   also can be -> std::make_pair(&msg[0], MSG_LEN)
		, adcval    // 2bytes, A1 value [0..1023]
	  , volt      // 2bytes, Module VCC[mV]
		, timestamp // 4bytes of timestamp
    );

The first to third lines specify variables to store data.

On the sixth line, expand_bytes() stores the packet payload data into variables. The first parameter is the container’s begin iterator (uint8_t* pointer), obtained with .begin(). The second parameter is the end iterator, obtained with .end(), to prevent reading beyond the end of the container.

List variables as the third and subsequent parameters. The payload is read and data is stored in the listed variables in order.

If the 4-byte string identifier read into msg is "PING", a PONG message is sent.

if (!strncmp((const char*)msg, "PING", MSG_LEN)) {
    vTransmit(MSG_PONG, rx.get_psRxDataApp()->u32SrcAddr);
}

Next, display the received packet information.

		Serial << format("<RX ad=%x/lq=%d/ln=%d/sq=%d:" // note: up to 4 args!
                    , rx.get_psRxDataApp()->u32SrcAddr
                    , rx.get_lqi()
                    , rx.get_length()
										, rx.get_psRxDataApp()->u8Seq
                    )
           << format(" %s AD=%d V=%d TS=%dms>" // note: up to 4 args!
                    , msg
                    , adcval
                    , volt
                    , timestamp
                    )
         << mwx::crlf
			   << mwx::flush;

Number formatting output is needed, so format() is used. This is a helper class that allows the same syntax as printf() for the >> operator, but the number of arguments is limited to 8 (for 32-bit parameters). (If you exceed the limit, a compile error occurs. Note that Serial.printfmt() does not have this limitation.)

mwx::crlf is a newline (CRLF), and mwx::flush waits until the output is complete (you can also write Serial.flush() instead of mwx::flush).

4.1.6 - BRD_APPTWELITE

Digital and Analog Signal Transmission
This is a sample using the board support <BRD_APPTWELITE>, assuming the same wiring as App_Twelite.

Features of the Act

  • Reads M1 to determine whether it is a parent or child device.
  • Reads the values of DI1-DI4. The Buttons class reduces the effect of chattering, and notifies change only when the same value is detected consecutively. Communication occurs when a change is detected.
  • Reads the values of AI1-AI4.
  • When DI changes or every second, sends the values of DI1-4, AI1-4, and VCC to the child if it is a parent, or to the parent if it is a child.
  • Sets DO1-4 and PWM1-4 according to the values of the received packet.

How to Use the Act

Required TWELITE and Example Wiring

RoleExample
ParentTWELITE DIP
At minimum, wire M1=GND, DI1:Button, DO1:LED.
ChildTWELITE DIP
At minimum, wire M1=Open, DI1:Button, DO1:LED.
Example wiring (AI1-AI4 are optional)

Example wiring (AI1-AI4 are optional)

Explanation of the Act

Declaration Section

Include

// use twelite mwx c++ template library
#include <TWELITE>
#include <NWK_SIMPLE>
#include <BRD_APPTWELITE>
#include <STG_STD>

<TWELITE> is included in all acts. Here, we also include the simple network <NWK_SIMPLE> and the board support <BRD_APPTWELITE>.

Additionally, <STG_STD> is included to add interactive mode.

Others

/*** Config part */
// application ID
const uint32_t DEFAULT_APP_ID = 0x1234abcd;
// channel
const uint8_t DEFAULT_CHANNEL = 13;
// option bits
uint32_t OPT_BITS = 0;
// logical id
uint8_t LID = 0;

/*** function prototype */
MWX_APIRET transmit();
void receive();

/*** application defs */
const char APP_FOURCHAR[] = "BAT1";

// sensor values
uint16_t au16AI[5];
uint8_t u8DI_BM;
  • Common declarations for sample acts
  • Prototype declarations for functions (transmit and receive) since some processing is separated into functions
  • Variables to hold data in the application

setup()

void setup() {
	/*** SETUP section */
	// init vars
	for(auto&& x : au16AI) x = 0xFFFF;
	u8DI_BM = 0xFF;

	// load board and settings
	auto&& set = the_twelite.settings.use<STG_STD>();
	auto&& brd = the_twelite.board.use<BRD_APPTWELITE>();
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();

	// settings: configure items
	set << SETTINGS::appname("BRD_APPTWELITE");
	set << SETTINGS::appid_default(DEFAULT_APP_ID); // set default appID
	set << SETTINGS::ch_default(DEFAULT_CHANNEL); // set default channel
	set.hide_items(E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);
	set.reload(); // load from EEPROM.
	OPT_BITS = set.u32opt1(); // this value is not used in this example.
	LID = set.u8devid(); // logical ID

	// the twelite main class
	the_twelite
		<< set                      // apply settings (appid, ch, power)
		<< TWENET::rx_when_idle();  // open receive circuit (if not set, it can't listen packts from others)

	if (brd.get_M1()) { LID = 0; }

	// Register Network
	nwk << set // apply settings (LID and retry)
			;

	// if M1 pin is set, force parent device (LID=0)
	nwk << NWK_SIMPLE::logical_id(LID); // write logical id again.

	/*** BEGIN section */
	// start ADC capture
	Analogue.setup(true, ANALOGUE::KICK_BY_TIMER0); // setup analogue read (check every 16ms)
	Analogue.begin(pack_bits(
						BRD_APPTWELITE::PIN_AI1,
						BRD_APPTWELITE::PIN_AI2,
						BRD_APPTWELITE::PIN_AI3,
						BRD_APPTWELITE::PIN_AI4,
				   		PIN_ANALOGUE::VCC)); // _start continuous adc capture.

	// Timer setup
	Timer0.begin(32, true); // 32hz timer

	// start button check
	Buttons.setup(5); // init button manager with 5 history table.
	Buttons.begin(pack_bits(
						BRD_APPTWELITE::PIN_DI1,
						BRD_APPTWELITE::PIN_DI2,
						BRD_APPTWELITE::PIN_DI3,
						BRD_APPTWELITE::PIN_DI4),
					5, 		// history count
					4);  	// tick delta (change is detected by 5*4=20ms consequtive same values)


	the_twelite.begin(); // start twelite!

	/*** INIT message */
	Serial 	<< "--- BRD_APPTWELITE ---" << mwx::crlf;
	Serial	<< format("-- app:x%08x/ch:%d/lid:%d"
					, the_twelite.get_appid()
					, the_twelite.get_channel()
					, nwk.get_config().u8Lid
				)
			<< mwx::crlf;
	Serial 	<< format("-- pw:%d/retry:%d/opt:x%08x"
					, the_twelite.get_tx_power()
					, nwk.get_config().u8RetryDefault
					, OPT_BITS
			)
			<< mwx::crlf;
}

The general flow is initial setup of each part, followed by starting each part.

Registering Various Behavior Objects

	auto&& set = the_twelite.settings.use<STG_STD>();
	auto&& brd = the_twelite.board.use<BRD_APPTWELITE>();
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();

Register behavior objects to determine the system’s behavior. This includes interactive mode settings management, board support, and wireless packet network description.

Setting Up Interactive Mode

// インタラクティブモードの初期化
auto&& set = the_twelite.settings.use<STG_STD>();

set << SETTINGS::appname("BRD_APPTWELITE");
set << SETTINGS::appid_default(DEFAULT_APP_ID); // set default appID
set << SETTINGS::ch_default(DEFAULT_CHANNEL); // set default channel
set.hide_items(E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);
set.reload(); // load from EEPROM.
OPT_BITS = set.u32opt1(); // this value is not used in this example.
LID = set.u8devid(); // logical ID;

Initializes interactive mode. First, the set object is obtained. Then, the following processing is performed:

  • Sets the application name to "BRD_APPTWELITE" (used in the menu)
  • Overwrites the default application ID and channel value
  • Removes unnecessary items
  • Reads the saved settings with set.reload()
  • Copies the values of OPT_BITS and LID to variables

Below is an example screen. By entering + + + (three times, with intervals of 0.2 to 1 second), you can bring up the interactive mode screen.

[CONFIG/BRD_APPTWELITE:0/SID=8XXYYYYY]
a: (0x1234ABCD) Application ID [HEX:32bit]
i: (        13) Device ID [1-100,etc]
c: (        13) Channel [11-26]
x: (      0x03) RF Power/Retry [HEX:8bit]
o: (0x00000000) Option Bits [HEX:32bit]

 [ESC]:Back [!]:Reset System [M]:Extr Menu

the_twelite

This object acts as the core of TWENET.

auto&& brd = the_twelite.board.use<BRD_APPTWELITE>();

Register the board (in this act, <BRD_APPTWELITE> is registered). Specify the board name you want to register after use with <>.

The return value obtained by universal reference (auto&&) is a reference type board object. This object includes board-specific operations and definitions. Below, the board object is used to check the state of the M1 pin. If the M1 pin is LOW, LID is set to 0, i.e., the parent address.

	if (brd.get_M1()) { LID = 0; }

Initial settings are required to operate the_twelite. Setting the application ID and wireless channel is essential.

	// the twelite main class
	the_twelite
		<< set
		<< TWENET::rx_when_idle();  // open receive circuit (if not set, it can't listen packts from others)

Use << to reflect settings in the_twelite.

  • set reflects some of the settings read from interactive mode (such as application ID and wireless channel). For details on reflected items, see the explanation of <STG_STD>.
  • TWENET::rx_when_idle() specifies to open the receive circuit.

次にネットワークを登録します。

auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();
nwk << set;
nwk << NWK_SIMPLE::logical_id(LID);

The first line registers the network in the same way as the board, specifying <NWK_SIMPLE> in <>.

The second and third lines are settings for <NWK_SIMPLE>. First, the interactive mode settings are reflected. The reflected items are LID and the retry count. In this application, since LID may be set to 0 depending on the state of the M1 pin, LID is set again in the third line.

Analogue

This is a class object that handles ADC (Analog-to-Digital Converter).

Analogue.setup(true, ANALOGUE::KICK_BY_TIMER0);

Initialization is done with Analogue.setup(). The parameter true specifies to wait until the ADC circuit is stabilized. The second parameter specifies to synchronize the start of ADC with Timer0.

	Analogue.begin(pack_bits(
						BRD_APPTWELITE::PIN_AI1,
						BRD_APPTWELITE::PIN_AI2,
						BRD_APPTWELITE::PIN_AI3,
						BRD_APPTWELITE::PIN_AI4,
				   	PIN_ANALOGUE::VCC));

To start ADC, call Analogue.begin(). The parameter is a bitmap corresponding to the ADC target pins.

The pack_bits() function is used to specify the bitmap. It is a variadic function, and each argument specifies the bit position to set to 1. For example, pack_bits(1,3,5) returns the value 101010 in binary. Since this function is marked constexpr, if the parameters are all constants, it will be expanded as a constant.

BRD_APPTWELITE:: defines PIN_AI1..4 as parameters. These correspond to AI1..AI4 used in App_Twelite. The assignments are AI1=ADC1, AI2=DIO0, AI3=ADC2, AI4=DIO2. PIN_ANALOGUE:: defines a list of pins available for ADC.

Buttons

Detects changes in the value of DIO (digital input). Buttons reduces the effect of mechanical button chattering, and only considers a value change after the same value has been detected a certain number of times.

Buttons.setup(5);

Initialization is done with Buttons.setup(). The parameter 5 specifies the maximum number of detections required to confirm the value. Internally, this number is used to allocate memory.

Buttons.begin(pack_bits(
						BRD_APPTWELITE::PIN_DI1,
						BRD_APPTWELITE::PIN_DI2,
						BRD_APPTWELITE::PIN_DI3,
						BRD_APPTWELITE::PIN_DI4),
					5, 		// history count
					4);  	// tick delta

Start is done with Buttons.begin(). The first parameter is the DIO to detect. Specify PIN_DI1-4 (DI1-DI4) defined in BRD_APPTWELITE::. The second parameter is the number of detections required to confirm the state. The third parameter is the detection interval. Since 4 is specified, when the same value is detected five times in a row every 4ms, the state is confirmed as HIGH or LOW.

Timer0

Timer0.begin(32, true); // 32hz timer

In App_Twelite, application control is based on a timer, so this act also operates timer interrupts and events in the same way. Of course, you can also use the system TickTimer, which operates every 1ms.

In the example above, the first parameter is the timer frequency, set to 32Hz. The second parameter enables the software interrupt when set to true.

After calling Timer0.begin(), the timer starts running.

the_tweliteの動作開始

the_twelite.begin(); // start twelite!

At the end of the setup() function, the_twelite.begin() is executed.

Serial

The Serial object can be used without initialization or start procedures.

	Serial 	<< "--- BRD_APPTWELITE ---" << mwx::crlf;
	Serial	<< format("-- app:x%08x/ch:%d/lid:%d"
					, the_twelite.get_appid()
					, the_twelite.get_channel()
					, nwk.get_config().u8Lid
				)
			<< mwx::crlf;
	Serial 	<< format("-- pw:%d/retry:%d/opt:x%08x"
					, the_twelite.get_tx_power()
					, nwk.get_config().u8RetryDefault
					, OPT_BITS
			)
			<< mwx::crlf;

In this sample, several system settings are displayed as a startup message. The Serial object can take a const char* string, int type (other integer types are not accepted), format() which behaves almost like printf(), and crlf for newlines, all using the << operator.

loop()

The loop function is called as a callback from the TWENET library’s main loop. The basic description here is to wait for the objects you use to become available and then process them. Below, we will explain the use of several objects used in this act.

/*** loop procedure (called every event) */
void loop() {
	if (Buttons.available()) {
		uint32_t bp, bc;
		Buttons.read(bp, bc);

		u8DI_BM = uint8_t(collect_bits(bp,
							BRD_APPTWELITE::PIN_DI4,   // bit3
							BRD_APPTWELITE::PIN_DI3,   // bit2
							BRD_APPTWELITE::PIN_DI2,   // bit1
							BRD_APPTWELITE::PIN_DI1)); // bit0

		transmit();
	}

	if (Analogue.available()) {
		au16AI[0] = Analogue.read(PIN_ANALOGUE::VCC);
		au16AI[1] = Analogue.read_raw(BRD_APPTWELITE::PIN_AI1);
		au16AI[2] = Analogue.read_raw(BRD_APPTWELITE::PIN_AI2);
		au16AI[3] = Analogue.read_raw(BRD_APPTWELITE::PIN_AI3);
		au16AI[4] = Analogue.read_raw(BRD_APPTWELITE::PIN_AI4);
	}

	if (Timer0.available()) {
		static uint8_t u16ct;
		u16ct++;

		if (u8DI_BM != 0xFF && au16AI[0] != 0xFFFF) { // finished the first capture
			if ((u16ct % 32) == 0) { // every 32ticks of Timer0
				transmit();
			}
		}
	}
}

Buttons

When a change in DIO (Digital IO) input is detected, it becomes available, and you can read it using Buttons.read().

	if (Buttons.available()) {
		uint32_t bp, bc;
		Buttons.read(bp, bc);

The first parameter is the current bitmap of DIO HIGH/LOW states, with bit0 corresponding to DIO0, bit1 to DIO1, and so on. For example, for DIO12, you can check if it is HIGH or LOW by evaluating bp & (1UL << 12). Bits set to 1 indicate HIGH.

Next, the value is extracted from the bitmap and stored in u8DI_BM. Here, we use the collect_bits() function provided by the MWX library.

u8DI_BM = uint8_t(collect_bits(bp,
		BRD_APPTWELITE::PIN_DI4,   // bit3
		BRD_APPTWELITE::PIN_DI3,   // bit2
		BRD_APPTWELITE::PIN_DI2,   // bit1
		BRD_APPTWELITE::PIN_DI1)); // bit0

/* collect_bits performs the following:
u8DI_BM = 0;
if (bp & (1UL << BRD_APPTWELITE::PIN_DI1)) u8DI_BM |= 1;
if (bp & (1UL << BRD_APPTWELITE::PIN_DI2)) u8DI_BM |= 2;
if (bp & (1UL << BRD_APPTWELITE::PIN_DI3)) u8DI_BM |= 4;
if (bp & (1UL << BRD_APPTWELITE::PIN_DI4)) u8DI_BM |= 8;
*/

collect_bits() takes integer values representing bit positions, just like the pack_bits() mentioned earlier. It is a variadic function, so you can specify as many parameters as needed. In the above process, bit0 is DI1, bit1 is DI2, bit2 is DI3, and bit3 is DI4, and the result is stored in u8DI_BM.

In App_Twelite, a wireless transmission occurs when there is a change in DI1 to DI4, so the transmission process is triggered by Buttons.available(). The contents of the transmit() process are described later.

transmit();

Analogue

After the ADC (Analog-to-Digital Converter) conversion is completed, Analogue becomes available in the next loop(). Until the next ADC starts, you can read the data as the most recently obtained value.

// After ADC conversion is completed, Analogue becomes available in loop().
// Until the next ADC starts, you can read the most recent value.

To read ADC values, use the Analogue.read() or Analogue.read_raw() methods. read() returns the value converted to mV, while read_raw() returns the ADC value in the range 0..1023. Specify the ADC pin number as a parameter. ADC pin numbers are defined in PIN_ANALOGUE:: or BRD_APPTWELITE::, so use those.

Timer0

Timer0 operates at 32Hz. It becomes available in loop() immediately after a timer interrupt occurs. In other words, processing is done 32 times per second. Here, the transmission process is performed exactly once per second.

if (Timer0.available()) {
	static uint8_t u16ct;
	u16ct++;

	if (u8DI_BM != 0xFF && au16AI[0] != 0xFFFF) { // finished the first capture
		if ((u16ct % 32) == 0) { // every 32ticks of Timer0
			transmit();
		}
	}
}

AppTwelite sends periodically about once per second. When Timer0 becomes available, u16ct is incremented. Based on this counter value, after counting 32 times, transmit() is called to send a wireless packet.

The value checks for u8DI_BM and au16AI[] are to determine whether it is right after initialization. If the values for DI1..DI4 or AI1..AI4 have not yet been stored, nothing is done.

transmit()

This function issues a request to TWENET to transmit a wireless packet. When this function returns, the wireless packet has not yet been processed. Actual transmission will be completed several milliseconds later, depending on the transmission parameters. Here, typical transmission request methods are explained.

MWX_APIRET transmit() {
	if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {
	  auto&& set = the_twelite.settings.use<STG_STD>();
		if (!set.is_screen_opened()) {
			Serial << "..DI=" << format("%04b ", u8DI_BM);
			Serial << format("ADC=%04d/%04d/%04d/%04d ", au16AI[1], au16AI[2], au16AI[3], au16AI[4]);
			Serial << "Vcc=" << format("%04d ", au16AI[0]);
			Serial << " --> transmit" << mwx::crlf;
		}

		// set tx packet behavior
		pkt << tx_addr(u8devid == 0 ? 0xFE : 0x00)  // 0..0xFF (LID 0:parent, FE:child w/ no id, FF:LID broad cast), 0x8XXXXXXX (long address)
			<< tx_retry(0x1) // set retry (0x1 send two times in total)
			<< tx_packet_delay(0,50,10); // send packet w/ delay (send first packet with randomized delay from 100 to 200ms, repeat every 20ms)

		// prepare packet payload
		pack_bytes(pkt.get_payload() // set payload data objects.
			, make_pair(APP_FOURCHAR, 4) // string should be paired with length explicitly.
			, uint8_t(u8DI_BM)
		);

		for (auto&& x : au16AI) {
			pack_bytes(pkt.get_payload(), uint16_t(x)); // adc values
		}

		// do transmit
		return pkt.transmit();
	}
	return MWX_APIRET(false, 0);
}

Function Prototype

MWX_APIRET transmit()

MWX_APIRET is a class that handles return values with a uint32_t data member. The MSB (bit31) indicates success or failure, and the other bits are used as the return value.

Obtaining Network and Packet Objects

	if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {

Obtain the network object with the_twelite.network.use<NWK_SIMPLE>(). Then use that object to obtain the pkt object with .prepare_tx_packet().

Here, it is declared within the condition of the if statement. The declared pkt object is valid until the end of the if block. The pkt object responds as a bool type: it is true if the TWENET transmission request queue has space to accept the request, and false if there is no space.

Suppressing Output While Interactive Mode Screen Is Open

auto&& set = the_twelite.settings.use<STG_STD>();
if (!set.is_screen_opened()) {
    // Not in interactive mode screen!
}

Output is suppressed when the interactive mode screen is displayed.

Packet Transmission Settings

pkt << tx_addr(u8devid == 0 ? 0xFE : 0x00)  // 0..0xFF (LID 0:parent, FE:child w/ no id, FF:LID broad cast), 0x8XXXXXXX (long address)
		<< tx_retry(0x1) // set retry (0x3 send four times in total)
		<< tx_packet_delay(0,50,10); // send packet w/ delay (send first packet with randomized delay from 100 to 200ms, repeat every 20ms)

Packet settings are configured using the << operator, similar to the initialization settings of the_twelite.

  • tx_addr(): Specifies the destination address. If 0x00, it means sending from a child to the parent; if 0xFE, it means sending from a parent as a broadcast to any child.
  • tx_retry(): Specifies the number of retransmissions. For example, 1 means retransmit once, so two packets in total are sent. Even in good conditions, sending a wireless packet only once can result in a few percent failure rate.
  • tx_packet_delay(): Sets the transmission delay. The first parameter is the minimum waiting time before transmission starts, the second is the maximum waiting time. In this case, after issuing the transmission request, the transmission starts at a random time between 0 and 50 ms. The third parameter is the retransmission interval. It means retransmitting every 10 ms after the first packet is sent.

Packet Data Payload

Payload means “cargo,” but in wireless packets it often refers to the “main data you want to send.” Wireless packets also contain auxiliary information such as address information, in addition to the main data.

To ensure correct transmission and reception, pay attention to the order of data in the payload. Here, the following data order is used. Construct the data payload according to this order.

# Index of the first byte: Data type : Byte size : Content

00: uint8_t[4] : 4 : 4-character identifier
04: uint8_t    : 1 : Bitmap of DI1..4
06: uint16_t   : 2 : Vcc voltage value
08: uint16_t   : 2 : AI1 ADC value (0..1023)
10: uint16_t   : 2 : AI2 ADC value (0..1023)
12: uint16_t   : 2 : AI3 ADC value (0..1023)
14: uint16_t   : 2 : AI4 ADC value (0..1023)

Let’s actually construct the data structure of the payload described above. The data payload can be referenced as a simplbuf<uint8_t> container via pkt.get_payload(). Build the data in this container according to the above specifications.

auto&& payl = pkt.get_payload();
payl.reserve(16); // resize to 16 bytes
payl[00] = APP_FOURCHAR[0];
payl[01] = APP_FOURCHAR[1];
...
payl[08] = (au16AI[0] & 0xFF00) >> 8; //Vcc
payl[09] = (au16AI[0] & 0xFF);
...
payl[14] = (au16AI[4] & 0xFF00) >> 8; // AI4
payl[15] = (au16AI[4] & 0xFF);

You can write it as shown above, but the MWX library provides a helper function pack_bytes() for constructing the data payload.

// prepare packet payload
pack_bytes(pkt.get_payload() // set payload data objects.
	, make_pair(APP_FOURCHAR, 4) // string should be paired with length explicitly.
	, uint8_t(u8DI_BM)
);

for (auto&& x : au16AI) {
	pack_bytes(pkt.get_payload(), uint16_t(x)); // adc values
}

The first parameter of pack_bytes() specifies the container, in this case pkt.get_payload().

The following parameters are variadic arguments, and you specify as many values of supported types as needed. Internally, pack_bytes() calls the .push_back() method to append the specified values to the end.

On the third line, make_pair() is a standard library function that generates a std::pair. This is specified to avoid confusion with string types (specifically, whether or not to include null characters in the payload). The first parameter of make_pair() should be a string type (such as char*, uint8_t*, or uint8_t[]). The second parameter is the number of bytes to be stored in the payload.

On the fourth line, the bitmap of DI1..DI4 is written as a uint8_t.

On lines 7-9, the values of the au16AI array are written sequentially. These values are of uint16_t type (2 bytes), and are written in big-endian order.

With this, preparation of the packet is complete. Now, simply issue the transmission request.

return pkt.transmit();

To send the packet, use the pkt.transmit() method of the pkt object. The return value is of type MWX_APIRET, but it is not used in this act.

on_rx_packet()

When a wireless packet is received, the reception event on_rx_packet() is called.

Here, the values of DI1..DI4 and AI1..AI4 received from the other party are set to the local DO1..DO4 and PWM1..PWM4.

void on_rx_packet(packet_rx& rx, bool_t &handled) {
	auto&& set = the_twelite.settings.use<STG_STD>();

	Serial << format("..receive(%08x/%d) : ", rx.get_addr_src_long(), rx.get_addr_src_lid());

  // expand the packet payload
	char fourchars[5]{};
	auto&& np = expand_bytes(rx.get_payload().begin(), rx.get_payload().end()
		, make_pair((uint8_t*)fourchars, 4)  // 4bytes of msg
    );

	// check header
	if (strncmp(APP_FOURCHAR, fourchars, 4)) { return; }

	// read rest of payload
	uint8_t u8DI_BM_remote = 0xff;
	uint16_t au16AI_remote[5];
	expand_bytes(np, rx.get_payload().end()
		, u8DI_BM_remote
		, au16AI_remote[0]
		, au16AI_remote[1]
		, au16AI_remote[2]
		, au16AI_remote[3]
		, au16AI_remote[4]
	);

	Serial << format("DI:%04b", u8DI_BM_remote & 0x0F);
	for (auto&& x : au16AI_remote) {
		Serial << format("/%04d", x);
	}
	Serial << mwx::crlf;

	// set local DO
	digitalWrite(BRD_APPTWELITE::PIN_DO1, (u8DI_BM_remote & 1) ? HIGH : LOW);
	digitalWrite(BRD_APPTWELITE::PIN_DO2, (u8DI_BM_remote & 2) ? HIGH : LOW);
	digitalWrite(BRD_APPTWELITE::PIN_DO3, (u8DI_BM_remote & 4) ? HIGH : LOW);
	digitalWrite(BRD_APPTWELITE::PIN_DO4, (u8DI_BM_remote & 8) ? HIGH : LOW);

	// set local PWM : duty is set 0..1024, so 1023 is set 1024.
	Timer1.change_duty(au16AI_remote[1] == 1023 ? 1024 : au16AI_remote[1]);
	Timer2.change_duty(au16AI_remote[2] == 1023 ? 1024 : au16AI_remote[2]);
	Timer3.change_duty(au16AI_remote[3] == 1023 ? 1024 : au16AI_remote[3]);
	Timer4.change_duty(au16AI_remote[4] == 1023 ? 1024 : au16AI_remote[4]);
}

Function Prototype

void on_rx_packet(packet_rx& rx, bool_t &handled)

The received packet data rx is passed as a parameter. From rx, you can access the address information and data payload of the wireless packet. The handled parameter is not typically used.

Displaying the Source Address

if (!set.is_screen_opened()) {
   Serial << format("..receive(%08x/%d) : ",
      rx.get_addr_src_long(), rx.get_addr_src_lid());
}

The received packet data refers to information such as the source address (32-bit long address and 8-bit logical address). Output is suppressed when the interactive mode screen is displayed.

Packet Identification

The MWX library provides the function expand_bytes(), which is the counterpart to pack_bytes() used in transmit().

char fourchars[5]{};
auto&& np = expand_bytes(rx.get_payload().begin(), rx.get_payload().end()
	, make_pair((uint8_t*)fourchars, 4)  // 4bytes of msg
  );

The first line declares a char array to store the data. The size is 5 bytes in order to include a null terminator for convenience in character output. The trailing {} is an initializer; although you could simply set the fifth byte to zero, here the entire array is initialized to zero by default.

On the second line, a 4-byte string is extracted using expand_bytes(). The reason for not specifying a container type as a parameter is to keep track of the read position for subsequent extraction. The first parameter specifies the beginning iterator (a uint8_t* pointer) of the container, obtained with the .begin() method. The second parameter is the iterator just past the end of the container, obtained with the .end() method. This ensures that reads do not exceed the end of the container.

For the third argument, specify the variable to read into, again using make_pair() to specify the string array and its size as a pair.

If the identifier in the extracted 4-byte string differs from the one specified in this act, the packet is ignored.

if (strncmp(APP_FOURCHAR, fourchars, 4)) { return; }

Retrieving the Data Payload

Store the values of DI1..DI4 and AI1..AI4 into separate variables.

	// read rest of payload
	uint8_t u8DI_BM_remote = 0xff;
	uint16_t au16AI_remote[5];
	expand_bytes(np, rx.get_payload().end()
		, u8DI_BM_remote
		, au16AI_remote[0]
		, au16AI_remote[1]
		, au16AI_remote[2]
		, au16AI_remote[3]
		, au16AI_remote[4]
	);

Here, the return value np from the earlier expand_bytes() call is used as the first parameter, indicating that reading should start from immediately after the 4-byte identifier just extracted. The second parameter is handled in the same way.

The third and subsequent parameters specify variables whose types and order correspond to those in the payload, matching the data structure on the sender side. When this process is complete, the extracted values from the payload are stored in the specified variables.

Displaying the Retrieved Data

For confirmation, the data is output to the serial port. Output is suppressed when the interactive mode screen is displayed.

auto&& set = the_twelite.settings.use<STG_STD>();
...
Serial << format("DI:%04b", u8DI_BM_remote & 0x0F);
for (auto&& x : au16AI_remote) {
	Serial << format("/%04d", x);
}
Serial << mwx::crlf;

The format() function is used for numeric formatting. It is a helper class that enables the use of printf-style syntax for the >> operator, but it is limited to four arguments (there is no such limit with Serial.printfmt()).

On the third line, "DI:%04b" displays the bitmap of DI1..DI4 in four digits, e.g., “DI:0010”.

On the fifth line, "/%04d" outputs the values of Vcc and AI1..AI4 sequentially as integers, such as “/3280/0010/0512/1023/1023”.

On the seventh line, mwx::crlf outputs a newline character.

Outputting the Signals

Once the required data is extracted, update the values of DO1..DO4 and PWM1..PWM4 on the board.

// set local DO
digitalWrite(BRD_APPTWELITE::PIN_DO1, (u8DI_BM_remote & 1) ? HIGH : LOW);
digitalWrite(BRD_APPTWELITE::PIN_DO2, (u8DI_BM_remote & 2) ? HIGH : LOW);
digitalWrite(BRD_APPTWELITE::PIN_DO3, (u8DI_BM_remote & 4) ? HIGH : LOW);
digitalWrite(BRD_APPTWELITE::PIN_DO4, (u8DI_BM_remote & 8) ? HIGH : LOW);

// set local PWM : duty is set 0..1024, so 1023 is set 1024.
Timer1.change_duty(au16AI_remote[1] == 1023 ? 1024 : au16AI_remote[1]);
Timer2.change_duty(au16AI_remote[2] == 1023 ? 1024 : au16AI_remote[2]);
Timer3.change_duty(au16AI_remote[3] == 1023 ? 1024 : au16AI_remote[3]);
Timer4.change_duty(au16AI_remote[4] == 1023 ? 1024 : au16AI_remote[4]);

digitalWrite() changes the value of a digital output. The first parameter is the pin number; the second specifies either HIGH (VCC level) or LOW (GND level).

Timer?.change_duty() changes the PWM output duty cycle. Specify the duty as a value between 0..1024. Note that the maximum value is not 1023. Since division operations within the library are computationally expensive, a power of two (1024) is used as the maximum value. Setting the parameter to 0 outputs GND level; setting it to 1024 outputs VCC level.

4.1.7 - BRD_I2C_TEMPHUMID

Transmit data from I2C sensor devices
This sample periodically wakes up, measures, and transmits data using an I2C sensor device.

This sample uses the I2C sensor device mounted on our AMBIENT SENSE PAL or TWELITE ARIA BLUE / RED. However, by rewriting the I2C command send/receive section, you can use other general-purpose I2C sensor devices (shown as Generic I2C Sensor Module in the diagram). In that case, please wire as shown below.

Connection of a generic I2C device

Connection of a generic I2C device

Act Features

  • Sends and receives commands to/from the I2C device.
  • Uses sleep functionality to operate on coin cell batteries.

How to Use the Act

Required TWELITE

RoleExample
ParentMONOSTICK BLUE / RED
Run act Parent_MONOSTICK.
Child- BLUE / RED PAL + AMBIENT SENSE PAL
- TWELITE ARIA BLUE / RED

Explanation of the Act

Include

#include <TWELITE>
#include <NWK_SIMPLE>// ネットワークサポート
#include <STG_STD>   // インタラクティブモード
#include <SM_SIMPLE> // 簡易ステートマシン

<NWK_SIMPLE> is required for wireless communication, <STG_STD> adds interactive mode, and <SM_SIMPLE> is included to simplify the application loop description.

Sensor Driver

In this example, there are two types of code: SHTC3 (TWELITE AMB PAL) and SHT40 (TWELITE ARIA), which are switched using #ifdef (please #define either USE_SHTC3 or USE_SHT40). For portability, both types are defined with the same function interface. Since both sensors are from the same manufacturer and series, the code is similar.

/*** sensor select, define either of USE_SHTC3 or USE_SHT40  */
// use SHTC3 (TWELITE PAL)
#define USE_SHTC3
// use SHT40 (TWELITE ARIA)
#undef USE_SHT40

以下では SHTC3 の例を示します。

#if defined(USE_SHTC3)
// for SHTC3
struct SHTC3 {
	uint8_t I2C_ADDR;
	uint8_t CONV_TIME;

    bool setup() { ... }
	bool begin() { ... }
	int get_convtime() { return CONV_TIME; }
	bool read(int16_t &i16Temp, int16_t &i16Humd) { ... }
} sensor_device;

Here, the I2C sensor-related procedures are organized into the SHTC3 struct (class) for clarity. This struct has member variables for the I2C address I2C_ADDR and the wait time for acquiring values CONV_TIME, and is declared with the instance name sensor_device.

This struct (class) has the following member functions:

Function NameDescription
setup()Initializes the struct.
begin()Starts acquiring sensor values.
After starting, you must wait a certain period for valid sensor values.
get_convtime()Returns the sensor value acquisition wait time.
read(int&, int&)Acquires the sensor values.

Let’s look at each process step by step.

setup()

bool setup() {
	// here, initialize some member vars instead of constructor.
	I2C_ADDR = 0x70;
	CONV_TIME = 10; // wait time [ms]
	return true;
}

Set the I2C address and the sensor value acquisition wait time (10ms above) to the member variables.

These values are basically fixed, so you do not need to set them as variables. Valid examples for treating them as variables include cases where you want to manage conversion time for higher-precision sensor operation depending on settings, or select a sub-address for I2C depending on configuration.

begin()

bool begin() {
	// send start trigger command
	if (auto&& wrt = Wire.get_writer(I2C_ADDR)) {
		wrt << 0x60; // SHTC3_TRIG_H
		wrt << 0x9C; // SHTC3_TRIG_L
	} else {
		return false;
	}
	return true;
}

Writes a command to operate the sensor.

The MWX library provides two different ways to read/write the I2C bus using the Wire class object; this is the helper function method.

In the if statement, Wire.get_writer(I2C_ADDR) opens the I2C device at address I2C_ADDR and generates a read/write object. The read/write object wrt returns false if the device fails to open (evaluated as (bool) in the if statement). If true, it means it opened successfully and the processing inside the if block is performed.

Here, wrt << 0x60; writes a byte to the I2C device using the stream operator <<. This operator is basically for writing a single byte of type uint8_t.

get_convtime()

int get_convtime() {
	return CONV_TIME;
}

This function returns the value of CONV_TIME.

read()

bool read(int16_t &i16Temp, int16_t &i16Humd) {
	// read result
	uint16_t u16temp, u16humd;
	uint8_t u8temp_csum, u8humd_csum;
	if (auto&& rdr = Wire.get_reader(I2C_ADDR, 6)) {
		rdr >> u16temp;      // read two bytes (MSB first)
		rdr >> u8temp_csum;  // check sum (crc8)
		rdr >> u16humd;      // read two bytes (MSB first)
		rdr >> u8humd_csum;  // check sum (crc8)
	} else {
		return false;
	}

	// check CRC and save the values
	if (   (CRC8_u8CalcU16(u16temp, 0xff) == u8temp_csum)
		&& (CRC8_u8CalcU16(u16humd, 0xff) == u8humd_csum))
	{
		i16Temp = (int16_t)(-4500 + ((17500 * int32_t(u16temp)) >> 16));
		i16Humd = (int16_t)((int32_t(u16humd) * 10000) >> 16);
	} else {
		return false;
	}

	return true;
}

Reads the sensor data.

For SHTC3, after starting sensor readout with begin(), you wait a few ms and then read the sensor values. The arrangement of sensor values is as follows:

ByteDescription
0Temperature sensor value (upper byte)
1Temperature sensor value (lower byte)
2CRC8 value for bytes 0,1
3Humidity sensor value (upper byte)
4Humidity sensor value (lower byte)
5CRC8 value for bytes 3,4

In begin(), data was written, but here, data is read. To read data, similarly generate a helper object rdr using Wire.get_reader(). If there are no errors, rdr returns true in the if block. The second parameter 6 in get_reader(I2C_ADDR, 6) is the number of bytes to read. When this number of bytes has been read, the I2C bus readout process ends. (Depending on the device, you may omit this, but usually you should provide the appropriate value.)

Reading is done with the stream operator >>. There are other ways to read; for details, see helper functions. When using the stream operator, you input values into pre-declared variables of type uint8_t, uint16_t, or uint32_t. rdr >> u16temp reads two bytes from the I2C bus into a uint16_t variable in big-endian format (first byte is upper byte). Finally, i16Temp and i16Humd are calculated and stored as 100 times the temperature [°C] and 100 times the humidity [%], respectively. For the calculation formulas, refer to the I2C device datasheet.

setup()

The setup() function is called only once when TWELITE starts. This function performs various initializations.

void setup() {
	/*** SETUP section */
	...
}

State Machine SM_SIMPLE Initialization

// application state defs
enum class STATE : uint8_t {
	INTERACTIVE = 255,
	INIT = 0,
	SENSOR,
	TX,
	TX_WAIT_COMP,
	GO_SLEEP
};

// simple state machine.
SM_SIMPLE<STATE> step;

void setup() {
	...
	/// init vars or objects
	step.setup(); // initialize state machine
	...
}

The state machine is used to simplify the description in the loop() statement, which is called repeatedly. Of course, you do not have to use SM_SIMPLE to describe your application.

SM_SIMPLE is implemented in very short code, and allows easy management of state transitions, timeouts, and flags. The states are defined in advance as an enumeration. In the example above, it’s enum class STATE. The state machine instance is declared as SM_SIMPLE<STATE> step using the defined STATE enum as a parameter.

Registering Behaviors

void setup() {
	...
	/// load board and settings objects
	auto&& set = the_twelite.settings.use<STG_STD>(); // load save/load settings(interactive mode) support
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>(); // load network support
	...
}

Behavior is a set of functions used in the program. It describes what to do when various events occur.

Here, two behaviors are used: the interactive mode screen <STG_STD> and the simple relay network <NWK_SIMPLE>.

Setting up Interactive Mode STG_STD

	...
	/// configure settings
	// configure settings
	set << SETTINGS::appname(FOURCHARS);
	set << SETTINGS::appid_default(DEFAULT_APP_ID); // set default appID
	set << SETTINGS::ch_default(DEFAULT_CHANNEL); // set default channel
	set.hide_items(E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, 	E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);

Initial settings are made for STG_STD so that the interactive mode setting items match the application being described.

  • SETTINGS::appname: Specifies the application name (string). Displayed on the first line in the interactive mode screen. Keep the string short as there is little space on the screen.
  • SETTINGS::appid_default: Default application ID. Use this if you want to set a custom default application ID for your own application.
  • SETTINGS::ch_default: Default channel. Use this if you want to set a custom default channel for your own application.

Next, set.hide_items() removes unnecessary setting items from the default interactive mode screen. If you don’t mind displaying everything, you don’t need this call.

	// if SET(DIO12)=LOW is detected, start with intaractive mode.
	if (digitalRead(PIN_DIGITAL::DIO12) == PIN_STATE::LOW) {
		set << SETTINGS::open_at_start();
		step.next(STATE::INTERACTIVE);
		return;
	}

If the DIO12 pin is LOW (GND level) when power is applied or reset, this code starts in interactive mode. It reads the pin state with digitalRead() and applies SETTINGS::open_at_start().

To prevent normal application processing from running during interactive mode, the state machine is set to STATE::INTERACTIVE. In this state, no input or other processing is performed, and it remains in the same state.

	// load values
	set.reload(); // load from EEPROM.
	OPT_BITS = set.u32opt1(); // this value is not used in this example.

	// LID is configured DIP or settings.
	LID = set.u8devid(); // 2nd is setting.
	if (LID == 0) LID = 0xFE; // if still 0, set 0xFE (anonymous child)

Finally, the data for interactive mode is loaded. Calling set.reload() reads data written to EEPROM. If no settings were made and EEPROM has no information, default values are used.

Here, the option bits (set.u32opt1()) and 8-bit logical ID (set.u8devid()) are read. If LID is 0, it is usually operated as a parent, so if this value is recorded, it is set to 0xFE (child with no assigned ID).

	/// configure system basics
	the_twelite << set; // apply settings (from interactive mode)
	nwk << set; // apply settings (from interactive mode)
	nwk << NWK_SIMPLE::logical_id(LID); // set LID again (LID can also be configured by DIP-SW.)
	...

Finally, the configuration information (part of it) is applied to the_twelite and nwk. Essential information for wireless communication, such as application ID and channel, is reflected. There is no explicit code above for reading these settings, but with set.reload(), default values are used if there are no settings, and configured values are loaded if present.

Peripheral Initialization

	/*** BEGIN section */
	Wire.begin(); // start two wire serial bus.

This initializes the I2C sensor settings.

Start MWX
	// let the TWELITE begin!
	the_twelite.begin();

	/*** INIT message */
	Serial << "--- TEMP&HUMID:" << FOURCHARS << " ---" << mwx::crlf;
	Serial	<< format("-- app:x%08x/ch:%d/lid:%d"
					, the_twelite.get_appid()
					, the_twelite.get_channel()
					, nwk.get_config().u8Lid
				)
			<< mwx::crlf;
	Serial 	<< format("-- pw:%d/retry:%d/opt:x%08x"
					, the_twelite.get_tx_power()
					, nwk.get_config().u8RetryDefault
					, OPT_BITS
			)
			<< mwx::crlf;

the_twelite.begin() declares the completion of MWX library initialization. If you do not perform this process, the MWX library will not operate properly.

Startup messages, etc. are also displayed here.

loop()

void loop() {
	do {
		switch (step.state()) {
		 // 各状態の振る舞い
		case STATE::INIT:
		...
		break;
		...
		}
	while(step.b_more_loop());
}

The loop() uses the SM_SIMPLE state machine step for control. This is to concisely represent the flow from wakeup from sleep, sensor value acquisition, wireless packet transmission, waiting for transmission completion, and sleeping.

State machine diagram

State machine diagram

The above do while control structure is described here. The state is determined by step.state(). The while condition is step.b_more_loop(). This is because, when transitioning from one state to another, you may want to process continuously without exiting loop(). In other words, when transitioning to another state and exiting the switch block, the next state’s case block is called. Be careful with this behavior.

case STATE::INTERACTIVE:

Because it is undesirable for the main loop to run during interactive mode, it is fixed to this state.

case STATE::INIT:

// start sensor capture
sensor_device.begin();
step.set_timeout(sensor_device.get_convtime()); // set timeout
step.next(STATE::SENSOR);

Starts sensor data acquisition. set_timeout() is used to wait for the sensor acquisition time.

For sensors with a very long wait time, you could describe a process here to sleep temporarily, which would extend battery life, but this is omitted in this example for simplicity. If needed, refer to the example for sleep waiting.

case STATE::SENSOR:

if (step.is_timeout()) {
	// the sensor data should be ready (wait some)
	sensor_device.read(sensor.i16temp, sensor.i16humid);

	Serial << "..finish sensor capture." << mwx::crlf
		<< "     : temp=" << div100(sensor.i16temp) << 'C' << mwx::crlf
		<< "       humd=" << div100(sensor.i16humid) << '%' << mwx::crlf
		;
	Serial.flush();

	step.next(STATE::TX);
}

Acquire sensor values using sensor_device.read() and store them in the sensor struct. First, a timeout check is performed using step.is_timeout(). The starting point for the timeout is the earlier step.set_timeout(). If not timed out, the if block is not executed, and loop() exits as is. Until the next hardware event (usually an interrupt from the TickTimer system timer every 1ms), the TWELITE microcontroller is in low-power DOZE mode with the CPU waiting.

As a wireless sensor, it is not necessary to output the results to the serial port of the sensor-side TWELITE, but for easy operation confirmation, the acquired values are displayed on the serial port. Here, Serial.flush() is used to wait for output, assuming that serial port output may not finish before TWELITE goes to sleep. This process can also cause battery drain, so you may want to avoid using Serial.flush() or not output to the serial port.

The div100() function used here performs division by 100 at low cost. Since TWELITE has no division circuit, it is recommended to avoid division processing as much as possible.

case STATE::TX:

step.next(STATE::GO_SLEEP); // set default next state (for error handling.)

// get new packet instance.
if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {
	...
}

Describes the communication procedure. No waiting is done in this state; after executing the process, it promptly transitions to the next state. The preemptive step.next(STATE::GO_SLEEP) is written to avoid having to write the same code in every place where errors are detected, as errors may be detected in multiple locations.

if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) creates a transmit packet object, and if successful, the if block is executed.

// set tx packet behavior
pkt << tx_addr(0x00)  // 0..0xFF (LID 0:parent, FE:child w/ no id, FF:LID broad cast), 0x8XXXXXXX (long address)
	<< tx_retry(0x1) // set retry (0x1 send two times in total)
	<< tx_packet_delay(0, 0, 2); // send packet w/ delay

First, transmission settings are made. The destination tx_addr(0x00) is set to parent 0x00, the number of retries tx_retry(0x1) is set to 1, and the packet delay setting tx_packet_delay(0, 0, 2) sets the initial delay to 0 and the retransmission interval to 2ms.

pack_bytes(pkt.get_payload()
	, make_pair(FOURCHARS, 4)
	, uint16_t(sensor.i16temp)
	, uint16_t(sensor.i16humid)
	);

Stores the identifier FOURCHARS and sensor data in the payload section of the packet. The obtained temperature value is int16_t, but since the transmit packet data structure stores it unsigned, it is cast to uint16_t.

// do transmit
MWX_APIRET ret = pkt.transmit();

if (ret) {
	step.clear_flag(); // waiting for flag is set.
	step.set_timeout(100); // set timeout
	step.next(STATE::TX_WAIT_COMP);}

Calling pkt.transmit() requests transmission. At this point, transmission does not start yet; the request is just placed in the internal queue. The MWX library processes the request at the appropriate timing.

If the transmit request succeeds, ret is true. To judge completion, the flag is initialized with step.clear_flag(), a timeout is set with step.set_timeout(100) to handle unexpected errors such as transmission failure, and the next state is set to STATE::TX_WAIT_COMP (overwriting the previously set STATE::GO_SLEEP).

case STATE::TX_WAIT_COMP:

Here, waits for transmission completion. Performs timeout judgment (in case of error) or transmission completion event judgment.

if (step.is_timeout()) { // maybe fatal error.
	the_twelite.reset_system();
}
if (step.is_flag_ready()) { // when tx is performed
	Serial << "..transmit complete." << mwx::crlf;
	Serial.flush();
	step.next(STATE::GO_SLEEP);
}

STATE::GO_SLEEP:

Processes sleepNow(). Calling this function puts TWELITE into sleep state.

on_tx_comp()

void on_tx_comp(mwx::packet_ev_tx& ev, bool_t &b_handled) {
	step.set_flag(ev.bStatus);
}

This is a system event called when transmission is complete. Here, .set_flag() is called to set the flag of step.

sleepNow()

void sleepNow() {
	step.on_sleep(false); // reset state machine.

	// randomize sleep duration.
	uint32_t u32ct = 1750 + random(0,500);

	// output message
	Serial << "..sleeping " << int(u32ct) << "ms." << mwx::crlf;
	Serial.flush(); // wait until all message printed.

	// do sleep.
	the_twelite.sleep(u32ct);
}

Before sleeping, .on_sleep(false) is called to initialize the state machine. The parameter false means it will start from STATE::INIT(=0) after waking up from sleep.

Here, the wakeup time is set randomly between 1750ms and 2250ms. This avoids consecutive collisions with packets from other devices transmitting at similar intervals.

Lines 8 and 9: In this example, it waits for serial port output before entering sleep. Normally, to minimize energy consumption, minimize (or eliminate) serial port output before sleep.

Line 12: To enter sleep, call the_twelite.sleep(). This call handles hardware pre-sleep procedures on the board. The sleep time is specified in ms as a parameter.

wakeup()

void wakeup() {
	Serial	<< mwx::crlf
			<< "--- PAL_AMB:" << FOURCHARS << " wake up ---"
			<< mwx::crlf
			<< "..start sensor capture again."
			<< mwx::crlf;
	...
}

When waking up from sleep, wakeup() is called. After that, loop() is called repeatedly. Before wakeup(), wakeup processing for peripherals such as UART and board devices is performed. For example, LED control is restarted.

4.1.8 - BRD_ARIA

Sample using TWELITE ARIA
TWELITE ARIA - Using Twilight ARIA to acquire sensor values.

Act Features

  • Using TWELITE ARIA - Twilight ARIA to acquire sensor values.
  • Using sleep function for operation with coin battery.

How to Use the Act

Required TWELITE

RoleExample
ParentMONOSTICK BLUE / RED
Run act Parent_MONOSTICK.
ChildTWELITE ARIA BLUE / RED

Explanation of the Act

Include

#include <TWELITE>
#include <NWK_SIMPLE>// Network support
#include <ARIA>   // TWELITE ARIA
#include <STG_STD>   // Interactive mode
#include <SM_SIMPLE> // Simple state machine

Include the board behavior of TWELITE ARIA <ARIA>.

setup()

void setup(){
	/*** SETUP section */
	/// init vars or objects
	step.setup(); // initialize state machine

	/// load board and settings objects
	auto&& brd = the_twelite.board.use<ARIA>(); // load board support
	auto&& set = the_twelite.settings.use<STG_STD>(); // load save/load settings(interactive mode) support
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>(); // load network support

	/// configure settings
	// configure settings
	set << SETTINGS::appname("ARIA");
	set << SETTINGS::appid_default(DEFAULT_APP_ID); // set default appID
	set << SETTINGS::ch_default(DEFAULT_CHANNEL); // set default channel
	set.hide_items(E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);

	// if SET=LOW is detected, start with interactive mode.
	if (digitalRead(brd.PIN_SET) == PIN_STATE::LOW) {
		set << SETTINGS::open_at_start();
		step.next(STATE::INTERACTIVE);
		return;
	}

	// load values
	set.reload(); // load from EEPROM.
	OPT_BITS = set.u32opt1(); // this value is not used in this example.

	LID = set.u8devid(); // set logical ID

	/// configure system basics
	the_twelite << set; // apply settings (from interactive mode)

	/// configure network
	nwk << set; // apply settings (from interactive mode)
	nwk << NWK_SIMPLE::logical_id(LID); // set LID again (LID can also be configured by DIP-SW.)

	/// configure hardware
	// LED setup (use periph_led_timer, which will re-start on wakeup() automatically)
	brd.set_led(LED_TIMER::BLINK, 10); // blink (on 10ms/ off 10ms)

	// let the TWELITE begin!
	the_twelite.begin();

	/*** INIT message */
	Serial << "--- ARIA:" << FOURCHARS << " ---" << mwx::crlf;
	Serial	<< format("-- app:x%08x/ch:%d/lid:%d"
					, the_twelite.get_appid()
					, the_twelite.get_channel()
					, nwk.get_config().u8Lid
				)
			<< mwx::crlf;
	Serial 	<< format("-- pw:%d/retry:%d/opt:x%08x"
					, the_twelite.get_tx_power()
					, nwk.get_config().u8RetryDefault
					, OPT_BITS
			)
			<< mwx::crlf;
}

First, initialize variables and others. Here, the state machine step is initialized.

First, register the board support <ARIA>. Sensor and DIO initialization is performed during board support initialization.

auto&& brd = the_twelite.board.use<ARIA>();

Next, initialize and load the interactive mode related settings.

// configure settings
set << SETTINGS::appname("ARIA");
set << SETTINGS::appid_default(DEFAULT_APP_ID); // set default appID
set << SETTINGS::ch_default(DEFAULT_CHANNEL); // set default channel
set.hide_items(E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);

// if SET=LOW is detected, start with interactive mode.
if (digitalRead(brd.PIN_SET) == PIN_STATE::LOW) {
	set << SETTINGS::open_at_start();
	step.next(STATE::INTERACTIVE);
	return;
}

// load values
set.reload(); // load from EEPROM.
OPT_BITS = set.u32opt1(); // this value is not used in this example.

LID = set.u8devid(); // set logical ID

Here, the set object is obtained, the application name is reflected, default application ID and communication channel are set, and unnecessary items in the settings menu are removed.

Next, read the state of the SET pin. Since this sample performs intermittent operation by sleep, transition to interactive mode by inputting +++ is not possible. Instead, it transitions to interactive mode when SET pin = LOW at startup. At this time, SETTINGS::open_at_start() is specified, which means to immediately transition to the interactive mode screen after setup() ends.

Finally, .reload() is executed to read the settings from EEPROM. The setting values are copied to each variable.

This act mainly transmits wireless packets, so the TWENET setting does not include the specification to open the receiver circuit during operation (TWENET::rx_when_idle()).

the_twelite << set; // apply settings (from interactive mode)

Next, set up the LED. Here, it is set to blink ON/OFF every 10ms (in applications with short wake-up time due to sleep, this setting is almost the same as lighting during wake-up).

brd.set_led(LED_TIMER::BLINK, 10); // blink (on 10ms/ off 10ms)

loop()

void loop() {
	auto&& brd = the_twelite.board.use<ARIA>();

	do {
		switch (step.state()) {
		 // Behavior of each state
		case STATE::INIT:
		...
		break;
		...
		}
	while(step.b_more_loop());
}

loop() controls using the SM_SIMPLE state machine step. This is to concisely express the sequence from waking from sleep, acquiring sensor values, transmitting wireless packets, waiting for transmission completion, and sleeping. The brd object is obtained at the start of the loop.

case STATE::INTERACTIVE:

Since it is inconvenient for the main loop to operate during interactive mode, it stays fixed in this state.

case STATE::INIT:

brd.sns_SHT4x.begin();

step.next(STATE::SENSOR);

Start sensor data acquisition.

case STATE::SENSOR:

//  wait until sensor capture finish
if (!brd.sns_SHT4x.available()) {
	brd.sns_SHT4x.process_ev(E_EVENT_TICK_TIMER);
}else{ // now sensor data is ready.
	sensor.i16temp = brd.sns_SHT4x.get_temp_cent();
	sensor.i16humid = brd.sns_SHT4x.get_humid_per_dmil();

	// read magnet sensor
	sensor.b_north = digitalRead(ARIA::PIN_SNS_NORTH);
	sensor.b_south = digitalRead(ARIA::PIN_SNS_SOUTH);

	Serial << "..finish sensor capture." << mwx::crlf
		<< "  MAGnet   : north=" << int(sensor.b_north) << mwx::crlf
		<< "             south=" << int(sensor.b_south) << mwx::crlf
		<< "  SHT4x    : temp=" << div100(sensor.i16temp) << 'C' << mwx::crlf
		<< "             humd=" << div100(sensor.i16humid) << '%' << mwx::crlf
		;
	Serial.flush();

	step.next(STATE::TX);
}

The sensor on the board can be accessed by the name .sns_SHT4x, and this object is operated. Wait for sensor completion. If the sensor acquisition is not yet finished (.available() is false), send a time elapsed event (.process_ev(E_EVENT_TICK_TIMER)) to the sensor.

When the sensor becomes available, acquire sensor values and transition to STATE_TX.

Temperature and humidity sensor values can be obtained as follows:

  • .get_temp_cent() : int16_t : temperature with 1°C = 100 (e.g., 25.6°C is 2560)
  • .get_temp() : float : float value (e.g., 25.6°C)
  • .get_humid_dmil() : int16_t : humidity with 1% = 100 (e.g., 56.8% is 5680)
  • .get_temp() : float : float value (e.g., 56.8%)

case STATE::TX:

The transmission procedure is the same as other act samples. Here, it is set to retry once with minimum retry delay.

pkt << tx_addr(0x00)  // to parent 0x00
	<< tx_retry(0x1)    // retry once
	<< tx_packet_delay(0, 0, 2); // minimum delay

Place the identifier FOURCHARS and sensor data in the packet payload. The temperature value among the obtained values is int16_t, but since the data structure of the transmission packet stores unsigned data, it is cast to uint16_t.

pack_bytes(pkt.get_payload() // set payload data objects.
	, make_pair(FOURCHARS, 4)  // just to see packet identification, you can design in any.
	, uint8_t(sensor.b_north)
	, uint8_t(sensor.b_south)
	, uint16_t(sensor.i16temp)
	, uint16_t(sensor.i16humid)
);

Request transmission. If the request succeeds, prepare for transmission completion wait. To wait for the completion event, .clear_flag() is called and a timeout of 100 milliseconds is set with set_timeout(100).

// do transmit
MWX_APIRET ret = pkt.transmit();

if (ret) {
	step.clear_flag(); // waiting for flag is set.
	step.set_timeout(100); // set timeout
	step.next(STATE::TX_WAIT_COMP);
}

case STATE::TX_WAIT_COMP:

Here, timeout judgment and transmission completion event judgment are performed.

if (step.is_timeout()) { // maybe fatal error.
	the_twelite.reset_system();
}
if (step.is_flag_ready()) { // when tx is performed
	Serial << "..transmit complete." << mwx::crlf;
	Serial.flush();
	step.next(STATE::GO_SLEEP);
}

STATE::GO_SLEEP:

Perform sleepNow() processing.

on_tx_comp()

void on_tx_comp(mwx::packet_ev_tx& ev, bool_t &b_handled) {
	step.set_flag(ev.bStatus);
}

System event called at transmission completion. Here, completion is indicated by .set_flag().

sleepNow()

Summarize the procedure to enter sleep.

void sleepNow() {
	step.on_sleep(false); // reset state machine.

	// randomize sleep duration.
	uint32_t u32ct = 1750 + random(0,500);

	// set an interrupt for MAGnet sensor.
	pinMode(ARIA::PIN_SNS_OUT1, PIN_MODE::WAKE_FALLING);
	pinMode(ARIA::PIN_SNS_OUT2, PIN_MODE::WAKE_FALLING);

	// output message
	Serial << "..sleeping " << int(u32ct) << "ms." << mwx::crlf;
	Serial.flush(); // wait until all message printed.

	// do sleep.
	the_twelite.sleep(u32ct);
}

Before sleep, reset the state machine by .on_sleep(false). The parameter false means to start from STATE::INIT(=0) after waking from sleep.

Here, the wake-up time is randomized between 1750ms and 2250ms. This avoids continuous collisions with packets of other devices transmitting with the same cycle.

Lines 8 and 9 set interrupt for the magnet sensor’s DIO pins before entering sleep using pinMode(). The second parameter is set to PIN_MODE::WAKE_FALLING, which wakes up when the pin state changes from HIGH to LOW.

Lines 12 and 13 wait for serial port output before sleeping. Usually, to minimize power consumption, serial port output before sleep is minimized or omitted.

Line 16 calls the_twelite.sleep() to enter sleep. This call performs pre-sleep procedures on board hardware, such as turning off LEDs.

The parameter specifies sleep duration in milliseconds.

wakeup()

wakeup() is called when waking from sleep. After that, loop() is called repeatedly. Before wakeup(), peripherals such as UART and devices on the board perform wake-up processing. For example, LED lighting control restarts.

void wakeup() {
    Serial	<< mwx::crlf
        	<< "--- ARIA:" << FOURCHARS << " wake up ";

    if (the_twelite.is_wokeup_by_wktimer()) {
        Serial << "(WakeTimer) ---";
    } else
    if (the_twelite.is_wokeup_by_dio(ARIA::PIN_SNS_NORTH)) {
        Serial << "(MAGnet INT [N]) ---";
    } else
    if (the_twelite.is_wokeup_by_dio(ARIA::PIN_SNS_SOUTH)) {
        Serial << "(MAGnet INT [S]) ---";
    } else {
        Serial << "(unknown source) ---";
    }

	Serial  << mwx::crlf
			<< "..start sensor capture again."
			<< mwx::crlf;
}

4.1.9 - PAL_AMB

Sample using the environmental sensor PAL
Using the Environmental Sensor PAL AMBIENT SENSE PAL, sensor values are acquired.

Act Features

  • Using the environmental sensor PAL AMBIENT SENSE PAL, sensor values are acquired.
  • Sleep function is used to operate on a coin battery.

How to Use the Act

Required TWELITE

RoleExample
ParentMONOSTICK BLUE / RED
Run the act Parent_MONOSTICK.
ChildBLUE / RED PAL + Environmental Sensor PAL-AMBIENT SENSE PAL

Act Explanation

Include

#include <TWELITE>
#include <NWK_SIMPLE>// Network support
#include <PAL_AMB>   // PAL_AMB
#include <STG_STD>   // Interactive mode
#include <SM_SIMPLE> // Simple state machine

Include the board behavior of the environmental sensor PAL <PAL_AMB>.

setup()

void setup() {
	/*** SETUP section */
	step.setup(); // Initialize the state machine

	// Load the board behavior of PAL_AMB
	auto&& brd = the_twelite.board.use<PAL_AMB>();

	// Load interactive mode
	auto&& set = the_twelite.settings.use<STG_STD>();
	set << SETTINGS::appname(FOURCHARS);
	set << SETTINGS::appid_default(APP_ID); // set default appID
	set.hide_items(E_STGSTD_SETID::POWER_N_RETRY, E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);

	// If the SET pin is detected, start interactive mode
	if (digitalRead(brd.PIN_BTN) == PIN_STATE::LOW) {
		set << SETTINGS::open_at_start();
		step.next(STATE::INTERACTIVE);
		return;
	}

	// Read data from interactive mode
	set.reload();
	APP_ID = set.u32appid();
	CHANNEL = set.u8ch();
	OPT_BITS = set.u32opt1();

	// Determine LID from DIP switch and interactive mode settings
	LID = (brd.get_DIPSW_BM() & 0x07); // 1st priority is DIP SW
	if (LID == 0) LID = set.u8devid(); // 2nd is setting.
	if (LID == 0) LID = 0xFE; // if still 0, set 0xFE (anonymous child)

	// Initialize LED
	brd.set_led(LED_TIMER::BLINK, 10); // blink (on 10ms/ off 10ms)

	// the twelite main object.
	the_twelite
		<< TWENET::appid(APP_ID)     // set application ID (identify network group)
		<< TWENET::channel(CHANNEL); // set channel (pysical channel)

	// Register Network
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();
	nwk << NWK_SIMPLE::logical_id(u8ID); // set Logical ID. (0xFE means a child device with no ID)

	/*** BEGIN section */
	Wire.begin(); // start two wire serial bus.
	Analogue.begin(pack_bits(PIN_ANALOGUE::A1, PIN_ANALOGUE::VCC)); // _start continuous adc capture.

	the_twelite.begin(); // start twelite!

	startSensorCapture(); // start sensor capture!

	/*** INIT message */
	Serial << "--- PAL_AMB:" << FOURCHARS << " ---" << mwx::crlf;
}

First, initialize variables and other settings. Here, the state machine step is initialized.

First, the board support <PAL_AMB> is registered. Initialization of sensors and DIO occurs during board support initialization. It is common to first check the state of the board’s DIP switches and then perform network settings and other processing.

auto&& brd = the_twelite.board.use<PAL_AMB>();

Next, initialize and read the interactive mode related settings.

// Load interactive mode
auto&& set = the_twelite.settings.use<STG_STD>();
set << SETTINGS::appname(FOURCHARS);
set << SETTINGS::appid_default(APP_ID); // set default appID
set.hide_items(E_STGSTD_SETID::POWER_N_RETRY, E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);

// If the SET pin is detected, start interactive mode
if (digitalRead(brd.PIN_BTN) == PIN_STATE::LOW) {
	set << SETTINGS::open_at_start();
	step.next(STATE::INTERACTIVE);
	return;
}

// Read data from interactive mode
set.reload();
APP_ID = set.u32appid();
CHANNEL = set.u8ch();
OPT_BITS = set.u32opt1();

// Determine LID from DIP switch and interactive mode settings
LID = (brd.get_DIPSW_BM() & 0x07); // 1st priority is DIP SW
if (LID == 0) LID = set.u8devid(); // 2nd is setting.
if (LID == 0) LID = 0xFE; // if still 0, set 0xFE (anonymous child)

Here, the set object is obtained, the application name is reflected, the default application ID and communication channel are applied, and unnecessary items in the settings menu are removed.

Next, read the state of the SET pin. This sample performs intermittent operation using sleep, so transition to interactive mode by inputting +++ is not possible. Instead, interactive mode transitions if the SET pin is LOW at startup. At this time, SETTINGS::open_at_start() is specified, which means to transition to the interactive mode screen immediately after setup() finishes.

Finally, .reload() is executed to read settings from EEPROM. The settings values are copied to variables.

Next, set up the LED. Here, it is set to blink ON/OFF every 10ms (in applications with short wake-up time due to sleep, this setting is almost the same as keeping it ON while awake).

	brd.set_led(LED_TIMER::BLINK, 10); // blink (on 10ms/ off 10ms)

Since this act mainly transmits wireless packets, the TWENET settings do not include keeping the receiver circuit open during operation (TWENET::rx_when_idle()).

	the_twelite
		<< TWENET::appid(APP_ID)     // set application ID (identify network group)
		<< TWENET::channel(CHANNEL); // set channel (pysical channel)

Since sensors on the board use the I2C bus, start using the bus.

Wire.begin(); // start two wire serial bus.

Start acquiring sensors on the board. See the explanation of startSensorCapture().

startSensorCapture();

loop()

void loop() {
	auto&& brd = the_twelite.board.use<PAL_AMB>();

	do {
		switch (step.state()) {
		 // Behavior of each state
		case STATE::INIT:
		...
		break;
		...
		}
	while(step.b_more_loop());
}

loop() performs control using the SM_SIMPLE state machine step. This is to simply express the sequence from waking up from sleep, acquiring sensor values, transmitting wireless packets, waiting for transmission completion, and sleeping. The brd object is obtained in the loop body.

case STATE::INTERACTIVE:

It is inconvenient for the main loop to operate during interactive mode, so it is fixed in this state.

case STATE::INIT:

brd.sns_SHTC3.begin();
brd.sns_LTR308ALS.begin();

step.next(STATE::SENSOR);

Start acquiring sensor data.

case STATE::SENSOR:

	if (!brd.sns_LTR308ALS.available()) {
		brd.sns_LTR308ALS.process_ev(E_EVENT_TICK_TIMER);
	}

	if (!brd.sns_SHTC3.available()) {
		brd.sns_SHTC3.process_ev(E_EVENT_TICK_TIMER);
	}

Sensors on the board can be accessed by the names .sns_LTR308ALS or .sns_SHTC3, and operations are performed on these objects. It waits for sensor completion. If the sensor acquisition is not finished yet (.available() is false), a time elapsed event (.process_ev(E_EVENT_TICK_TIMER)) is sent to the sensor.

When the sensor becomes available, sensor values are acquired and transition to STATE_TX.

// now sensor data is ready.
if (brd.sns_LTR308ALS.available() && brd.sns_SHTC3.available()) {
	sensor.u32luminance = brd.sns_LTR308ALS.get_luminance();
	sensor.i16temp = brd.sns_SHTC3.get_temp_cent();
	sensor.i16humid = brd.sns_SHTC3.get_humid_per_dmil();

	Serial << "..finish sensor capture." << mwx::crlf
		<< "  LTR308ALS: lumi=" << int(sensor.u32luminance) << mwx::crlf
		<< "  SHTC3    : temp=" << div100(sensor.i16temp) << 'C' << mwx::crlf
		<< "             humd=" << div100(sensor.i16humid) << '%' << mwx::crlf
		;
	Serial.flush();

	step.next(STATE::TX);
}

Illuminance sensor is obtained by .get_luminance() : uint32_t.

Temperature and humidity sensor values can be obtained as follows:

  • .get_temp_cent() : int16_t : temperature in Celsius multiplied by 100 (e.g., 25.6 ℃ is 2560)
  • .get_temp() : float : float value (e.g., 25.6 ℃ is 25.6)
  • .get_humid_dmil() : int16_t : humidity in % multiplied by 100 (e.g., 56.8% is 5680)
  • .get_humid() : float : float value (e.g., 56.8% is 56.8)

case STATE::TX:

The transmission procedure is the same as other act samples. Here, it is set to one retry and minimum retry delay.

pkt << tx_addr(0x00)  // To parent 0x00
	<< tx_retry(0x1)    // Retry once
	<< tx_packet_delay(0, 0, 2); // Minimum delay

The payload of the packet includes the identifier FOURCHARS and sensor data. Among the obtained values, temperature is int16_t, but since the data structure of the transmission packet stores data as unsigned, it is cast to uint16_t.

pack_bytes(pkt.get_payload()
	, make_pair(FOURCHARS, 4)
	, uint32_t(sensor.u32luminance)
	, uint16_t(sensor.i16temp)
	, uint16_t(sensor.i16humid)
);

Request transmission. If the transmission request succeeds, prepare for transmission completion event. To wait for completion event, .clear_flag() is called, and a timeout of set_timeout(100) is set. The parameter 100 is in milliseconds [ms].

// do transmit
MWX_APIRET ret = pkt.transmit();

if (ret) {
	step.clear_flag(); // waiting for flag is set.
	step.set_timeout(100); // set timeout
	step.next(STATE::TX_WAIT_COMP);
}

case STATE::TX_WAIT_COMP:

Here, timeout and transmission completion events are checked.

if (step.is_timeout()) { // maybe fatal error.
	the_twelite.reset_system();
}
if (step.is_flag_ready()) { // when tx is performed
	Serial << "..transmit complete." << mwx::crlf;
	Serial.flush();
	step.next(STATE::GO_SLEEP);
}

STATE::GO_SLEEP:

Perform sleepNow() processing.

on_tx_comp()

void on_tx_comp(mwx::packet_ev_tx& ev, bool_t &b_handled) {
	step.set_flag(ev.bStatus);
}

This system event is called upon transmission completion. Here, .set_flag() marks completion.

sleepNow()

This function summarizes the procedure to enter sleep.

void sleepNow() {
	step.on_sleep(false); // reset state machine.

	// randomize sleep duration.
	uint32_t u32ct = 1750 + random(0,500);

	// output message
	Serial << "..sleeping " << int(u32ct) << "ms." << mwx::crlf;
	Serial.flush(); // wait until all message printed.

	// do sleep.
	the_twelite.sleep(u32ct);
}

Before sleeping, .on_sleep(false) resets the state machine. The parameter false means to start from STATE::INIT(=0) after waking up.

Here, the sleep duration is randomized between 1750ms and 2250ms. This avoids continuous collisions of packets with other devices transmitting at the same period.

Lines 8 and 9: In this example, it waits for output from the serial port before sleeping. Normally, to minimize power consumption, serial port output before sleep is minimized or omitted.

Line 12: To enter sleep, call the_twelite.sleep(). This call performs hardware sleep procedures on the board, such as turning off LEDs.

The parameter specifies sleep time in milliseconds.

wakeup()

When waking up from sleep, wakeup() is called. Then loop() is called repeatedly. Before wakeup(), peripherals such as UART and devices on the board are woken up. For example, LED control is restarted.

void wakeup() {
	Serial	<< mwx::crlf
			<< "--- PAL_AMB:" << FOURCHARS << " wake up ---"
			<< mwx::crlf
			<< "..start sensor capture again."
			<< mwx::crlf;

Advanced

Reducing Power Consumption

The act PAL_AMB-UseNap performs sleep while waiting for sensor data acquisition, enabling operation with lower power consumption.

4.1.10 - PAL_AMB-usenap

Sample using the environmental sensor Pal
Using the Environmental Sensor Pal AMBIENT SENSE PAL, sensor values are acquired. This improves the PAL_AMB sample by making the waiting time (about 50ms) during sensor data acquisition a sleep period.

Act Features

  • Uses the Environmental Sensor Pal AMBIENT SENSE PAL to acquire sensor values.
  • Uses sleep function to operate with coin battery.
  • Uses sleep function even during sensor data acquisition.

Act Explanation

begin()

The begin() function is called just before the very first loop() after the setup() function finishes (and then TWENET initialization is performed).

void begin() {
	sleepNow(); // the first time is just sleeping.
}

After setup(), the initial sleep is executed. Sensor data acquisition is started during setup(), but the result is not evaluated. This is done to activate the sensor once beforehand and is not necessarily required.

wakeup()

Procedures after wake-up. The following processing is performed:

  • If sensor data acquisition has not been started yet, start sensor data acquisition and enter a short sleep.
  • Since sensor data acquisition was started immediately before, check the data and send it wirelessly.
void wakeup() {
	if (!b_senser_started) {
		// delete/make shorter this message if power requirement is harder.
		Serial	<< mwx::crlf
				<< "--- PAL_AMB:" << FOURCHARS << " wake up ---"
				<< mwx::crlf
				<< "..start sensor capture again."
				<< mwx::crlf;

		startSensorCapture();
		b_senser_started = true;

		napNow(); // short period sleep.
	} else {
		Serial << "..wake up from short nap.." << mwx::crlf;

		auto&& brd = the_twelite.board.use<PAL_AMB>();

		b_senser_started = false;

		// tell sensors waking up.
		brd.sns_LTR308ALS.process_ev(E_EVENT_START_UP);
		brd.sns_SHTC3.process_ev(E_EVENT_START_UP);
	}
}

The above branch is controlled by the global variable b_sensor_started. If !b_sensor_started, sensor acquisition start (startSensorCapture()) is performed, and a short sleep is entered by napNow(). The time is 100ms.

After waking up from the sleep by napNow(), the section where b_sensor_started==true is executed. Here, the E_EVENT_START_UP event is notified to the two sensors. This event means that enough time has passed for the sensor acquisition to be completed. Based on this notification, sns_LTR308ALS and sns_SHTC3 become available. Then it proceeds to loop(), and the wireless packet is sent.

napNow()

Executes a very short sleep.

void napNow() {
	uint32_t u32ct = 100;
	Serial << "..nap " << int(u32ct) << "ms." << mwx::crlf;
	the_twelite.sleep(u32ct, false, false, TWENET::SLEEP_WAKETIMER_SECONDARY);
}

If the second parameter of sleep is true, the next wake-up time is adjusted based on the previous sleep wake-up time. This is set when you want to wake up every 5 seconds regularly.

If the third parameter is true, the sleep does not retain memory. After waking up, wakeup() is not called, and the process is the same as power-on reset.

The fourth parameter specifies using the second wake-up timer. Here, the first timer is used for normal sleep, and the second is used for short sleep. This act has no strong reason to use the second timer, but for example, if you want to wake up every 5 seconds as mentioned above, using the first timer for short sleep resets the counter value, making elapsed time correction calculations complicated, so the second timer is used.

4.1.11 - PAL_AMB-behavior

Sample using the environmental sensor PAL
Using the Environmental Sensor PAL AMBIENT SENSE PAL to acquire sensor values.

Act Functions

  • Uses the environmental sensor PAL AMBIENT SENSE PAL to acquire sensor values.
  • Utilizes sleep functions to operate with coin batteries.

How to Use the Act

Preparing TWELITE

RoleExample
ParentMONOSTICK BLUE or RED
ChildBLUE PAL or RED PAL + Environmental Sensor PAL AMBIENT SENSE PAL

File Structure

  • PAL_AMB-behavior.hpp : Defines only setup(). Reads DIP switches, and if D1..D3 are in the up position, it operates as a parent device; otherwise, it sets the ID corresponding to the DIP switch as a child device.
  • Parent/myAppBhvParent.hpp : Behavior class definition for the parent device
  • Parent/myAppBhvParent.cpp : Implementation
  • Parent/myAppBhvParent-handlers.cpp : Handler implementation
  • Parent/myAppBhvParent.hpp : Behavior class definition for the child device
  • Parent/myAppBhvParent.cpp : Implementation
  • Parent/myAppBhvParent-handlers.cpp : Handler implementation

The behavior name for the parent device is <MY_APP_PARENT>, and for the child device is <MY_APP_CHILD>.

setup()

// now read DIP sw status can be read.
u8ID = (brd.get_DIPSW_BM() & 0x07);

// Register App Behavior (set differnt Application by DIP SW settings)
if (u8ID == 0) {
	// put settings to the twelite main object.
	the_twelite
		<< TWENET::appid(APP_ID)     // set application ID (identify network group)
		<< TWENET::channel(CHANNEL)  // set channel (pysical channel)
		<< TWENET::rx_when_idle();   // open RX channel

	the_twelite.app.use<MY_APP_PARENT>();
} else {
	// put settings to the twelite main object.
	the_twelite
		<< TWENET::appid(APP_ID)     // set application ID (identify network group)
		<< TWENET::channel(CHANNEL); // set channel (pysical channel)

	the_twelite.app.use<MY_APP_CHILD>();
}

If the DIP switch read value is 0, the parent behavior <MY_APP_PARENT> is registered; otherwise, the child behavior <MY_APP_CHILD> is registered.

Parent Behavior

The parent device behaves as a receiver that does not sleep and outputs packet information to the serial port when receiving packets from child devices.

MY_APP_PARENT::receive()

void MY_APP_PARENT::receive(mwx::packet_rx& rx) {
	uint8_t msg[4];
	uint32_t lumi;
	uint16_t u16temp, u16humid;

	// expand packet payload (shall match with sent packet data structure, see pack_bytes())
	auto&& np = expand_bytes(rx.get_payload().begin(), rx.get_payload().end(), msg);

	// if PING packet, respond pong!
	if (!strncmp((const char*)msg, (const char*)FOURCHARS, 4)) {
		// get rest of data
		expand_bytes(np, rx.get_payload().end(), lumi, u16temp, u16humid);

		// print them
		Serial << format("Packet(%x:%d/lq=%d/sq=%d): ",
							rx.get_addr_src_long(), rx.get_addr_src_lid(),
							rx.get_lqi(), rx.get_psRxDataApp()->u8Seq)
			   << "temp=" << double(int16_t(u16temp)/100.0)
			   << "C humid=" << double(int16_t(u16humid)/100.0)
			   << "% lumi=" << int(lumi)
			   << mwx::crlf << mwx::flush;
    }
}

When the parent device receives a packet, if the first four characters of the packet match (FOURCHARS), the packet content is displayed.

MY_APP_PARENT::MWX_TICKTIMER_INT()

MWX_TICKTIMER_INT(uint32_t arg, uint8_t& handled) {
  // blink LED
  digitalWrite(PAL_AMB::PIN_LED,
    ((millis() >> 9) & 1) ? PIN_STATE::HIGH : PIN_STATE::LOW);
}

The parent device’s interrupt handler blinks the LED.

MY_APP_PARENT::MWX_DIO_EVENT(PAL_AMB::PIN_BTN)

MWX_DIO_EVENT(PAL_AMB::PIN_BTN, uint32_t arg) {
	Serial << "Button Pressed" << mwx::crlf;

	static uint32_t u32tick_last;
	uint32_t tick = millis();

	if (tick - u32tick_last > 100) {
		PEV_Process(E_ORDER_KICK, 0UL);
	}

	u32tick_last = tick;
}

When the button (5) on the PAL is pressed, an E_ORDER_KICK event is issued to the state machine.

MY_APP_PARENT::MWX_STATE(E_MWX::STATE_0 .. 3)

The state machine is described as a reference for state transitions and does not have a significant meaning for the application operation. It executes state transitions triggered by the E_ORDER_KICK event from the button and timeouts.

Child Behavior

The operation flow of the child device is the same as PAL_AMB-usenap. It repeats “wake up → start sensor operation → short sleep → wake up → acquire sensor values → wireless transmission → wait for transmission completion → sleep” from the initial sleep.

MY_APP_CHILD::on_begin()

void _begin() {
    // sleep immediately.
    Serial << "..go into first sleep (1000ms)" << mwx::flush;
    the_twelite.sleep(1000);
}

The _begin() function called from on_begin() performs the initial sleep.

(You may write this process directly in on_begin() without using _begin())

MY_APP_CHILD::wakeup()

void wakeup(uint32_t & val) {
    Serial << mwx::crlf << "..wakeup" << mwx::crlf;
    // init wire device.
    Wire.begin();

    // turn on LED
    digitalWrite(PAL_AMB::PIN_LED, PIN_STATE::LOW);

    // KICK it!
    PEV_Process(E_ORDER_KICK, 0); // pass the event to state machine
}

Describes the wake-up process from sleep.

Here, the initial Wire.begin() is executed. It is redundant to include this on subsequent wake-ups from sleep. This process can also be moved to on_begin().

MY_APP_CHILD::transmit_complete()

void transmit_complete(mwx::packet_ev_tx& txev) {
    Serial << "..txcomp=" << int(txev.u8CbId) << mwx::crlf;
    PEV_Process(E_ORDER_KICK, txev.u8CbId); // pass the event to state machine
}

Processes the E_ORDER_KICK message to the state machine when transmission is complete.

MY_APP_CHILD::transmit_complete()

static const uint8_t STATE_IDLE = E_MWX::STATE_0;
static const uint8_t STATE_SENSOR = E_MWX::STATE_1;
static const uint8_t STATE_TX = E_MWX::STATE_2;
static const uint8_t STATE_SLEEP = E_MWX::STATE_3;

Defines state names.

MY_APP_CHILD::shtc3_???()

MWX_APIRET MY_APP_CHILD::shtc3_start()
MWX_APIRET MY_APP_CHILD::shtc3_read()

Example implementation for sensor acquisition of SHTC3. For details such as commands sent, please refer to the SHTC3 datasheet.

MY_APP_CHILD::ltr308als_???()

MWX_APIRET MY_APP_CHILD::ltr308als_read()
MWX_APIRET MY_APP_CHILD::ltr308als_start()
static MWX_APIRET WireWriteAngGet(uint8_t addr, uint8_t cmd)

Example implementation for sensor acquisition of LTR308ALS. For details such as commands sent, please refer to the LTR308ALS datasheet.

WireWriteAndGet() sends one byte cmd to the device at addr, then receives one byte and returns the value.

MY_APP_CHILD::STATE_IDLE (0)

MWX_STATE(MY_APP_CHILD::STATE_IDLE, uint32_t ev, uint32_t evarg) {
	if (PEV_is_coldboot(ev,evarg)) {
		Serial << "[STATE_IDLE:START_UP(" << int(evarg) << ")]" << mwx::crlf;
		// then perform the first sleep at on_begin().
	} else
	if (PEV_is_warmboot(ev,evarg)) {
		Serial << "[STATE_IDLE:START_UP(" << int(evarg) << ")]" << mwx::crlf;
		PEV_SetState(STATE_SENSOR);
	}
}

State 0 has a special meaning. It is the state immediately after startup or waking from sleep.

It is called when the startup cold boot check PEV_is_coldboot(ev,evarg) returns true. Since on_begin() immediately goes to sleep, no state transitions are included here. At this point, major initialization is not yet complete, so complex processes such as wireless packet transmission cannot be performed. To perform such processes, an event is sent from on_begin() to trigger the first state transition.

After waking from sleep, PEV_is_warmboot(ev,evarg) returns true on the first call. It calls PEV_SetState() to transition to STATE_SENSOR.

MY_APP_CHILD::STATE_SENSOR

MWX_STATE(MY_APP_CHILD::STATE_SENSOR, uint32_t ev, uint32_t evarg) {
	if (ev == E_EVENT_NEW_STATE) {
		Serial << "[STATE_SENSOR:NEW] Start Sensor." << mwx::crlf;

		// start sensor capture
		shtc3_start();
		ltr308als_start();

		// take a nap waiting finish of capture.
		Serial << "..nap for 66ms" << mwx::crlf;
		Serial.flush();
		PEV_KeepStateOnWakeup(); // stay this state on waking up.
		the_twelite.sleep(66, false, false, TWENET::SLEEP_WAKETIMER_SECONDARY);
	} else
	if (PEV_is_warmboot(ev,evarg)) {
		// on wakeup, code starts here.
		Serial << "[STATE_SENSOR:START_UP] Wakeup." << mwx::crlf;

		PEV_SetState(STATE_TX);
	}
}

When transitioning from STATE_IDLE after waking from sleep, the STATE_SENSOR handler is called with the event E_EVENT_NEW_STATE.

Here, the operation of two sensors, SHTC3 and LTR308ALS, is started. After a certain time, the sensors become ready for data acquisition. This wait time is performed by sleeping for 66 ms. Note that PEV_KeepStateOnWakeup() is called before sleeping. This call keeps the state as STATE_SENSOR after waking up, instead of returning to STATE_IDLE.

After waking from this short sleep, the first call with PEV_is_warmboot(ev,evarg) returns true. At this point, wireless packet transmission can be performed. It transitions to STATE_TX.

MY_APP_CHILD::STATE_TX

MWX_STATE(MY_APP_CHILD::STATE_TX, uint32_t ev, uint32_t evarg)
	static int u8txid;

	if (ev == E_EVENT_NEW_STATE) {
		Serial << "[STATE_TX:NEW]" << mwx::crlf;
		u8txid = -1;

		auto&& r1 = shtc3_read();
		auto&& r2 = ltr308als_read();

		Serial << "..shtc3 t=" << int(i16Temp) << ", h=" << int(i16Humd) << mwx::crlf;
		Serial << "..ltr308als l=" << int(u32Lumi) << mwx::crlf;

		if (r1 && r2) {
			if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {

Here, on the E_EVENT_NEW_STATE event, sensor data is read and the wireless packet transmission procedure begins. For transmission procedure details, please refer to other act sample examples.

void transmit_complete(mwx::packet_ev_tx& txev) {
    Serial << "..txcomp=" << int(txev.u8CbId) << mwx::crlf;
    PEV_Process(E_ORDER_KICK, txev.u8CbId); // pass the event to state machine
}

    // ↓ ↓ ↓ Message sending

} else if (ev == E_ORDER_KICK && evarg == uint32_t(u8txid)) {
		Serial << "[STATE_TX] SUCCESS TX(" << int(evarg) << ')' << mwx::crlf;
		PEV_SetState(STATE_SLEEP);
}

Waiting for transmission completion is handled differently from loop-based act descriptions. It waits for a message from transmit_complete() via PEV_Process() to confirm completion. When the message is received, it goes to sleep. The sleep process is done by transitioning to STATE_SLEEP.

	if (PEV_u32Elaspsed_ms() > 100) {
		// does not finish TX!
		Serial << "[STATE_TX] FATAL, TX does not finish!" << mwx::crlf << mwx::flush;
		the_twelite.reset_system();
	}

Finally, timeout processing is performed. This assumes the case where the transmission completion message does not return. PEV_u32Elaspsed_ms() returns the elapsed time in ms since transitioning to this state. If time passes, the system resets (the_twelite.reset_system()), assuming this timeout is a critical error.

MY_APP_CHILD::STATE_SLEEP

MWX_STATE(MY_APP_CHILD::STATE_SLEEP, uint32_t ev, uint32_t evarg) {
	if (ev == E_EVENT_NEW_STATE) {
		Serial << "..sleep for 5000ms" << mwx::crlf;
		pinMode(PAL_AMB::PIN_BTN, PIN_MODE::WAKE_FALLING_PULLUP);
		digitalWrite(PAL_AMB::PIN_LED, PIN_STATE::HIGH);
		Serial.flush();

		the_twelite.sleep(5000); // regular sleep
	}
}

Performs sleep. This is described inside the E_EVENT_NEW_STATE event immediately after transitioning from the previous state. Since other events might be called just before sleeping, always execute the_twelite.sleep() inside a condition that runs only once.

4.1.12 - PAL_MAG

Sample using magnetic sensor pal
Using Open-Close Sensor Pal OPEN-CLOSE SENSE PAL, sensor values are acquired.

Function of the Act

  • Using the Open-Close Sensor Pal OPEN-CLOSE SENSE PAL, it wakes up by interrupt when the magnetic sensor is detected and transmits wirelessly.
  • Uses sleep function for operation with coin battery.

How to Use the Act

Required TWELITE

RoleExample
Parent Device

MONOSTICK BLUE or RED

Operate the act Parent_MONOSTICK.

Child DeviceBLUE PAL or RED PAL + Open-Close Sensor Pal OPEN-CLOSE SENSE PAL

Explanation of the Act

Include

##include <TWELITE>
##include <NWK_SIMPLE>
##include <PAL_MAG>

Include the board behavior <PAL_MAG> of the Open-Close Sensor Pal.

setup()

void setup() {
	/*** SETUP section */
	// use PAL_AMB board support.
	auto&& brd = the_twelite.board.use<PAL_MAG>();
	// now it can read DIP sw status.
	u8ID = (brd.get_DIPSW_BM() & 0x07) + 1;
	if (u8ID == 0) u8ID = 0xFE; // 0 is to 0xFE

	// LED setup (use periph_led_timer, which will re-start on wakeup() automatically)
	brd.set_led(LED_TIMER::BLINK, 10); // blink (on 10ms/ off 10ms)

	// the twelite main object.
	the_twelite
		<< TWENET::appid(APP_ID)     // set application ID (identify network group)
		<< TWENET::channel(CHANNEL); // set channel (pysical channel)

	// Register Network
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();
	nwk << NWK_SIMPLE::logical_id(u8ID); // set Logical ID. (0xFE means a child device with no ID)

	/*** BEGIN section */
	the_twelite.begin(); // start twelite!

	/*** INIT message */
	Serial << "--- PAL_MAG:" << FOURCHARS << " ---" << mwx::crlf;
}

First, the board behavior <PAL_MAG> is registered. During board behavior initialization, sensors and DIO are initialized. It is common to first check the status of DIP SW on the board and then perform network settings and other processing.

auto&& brd = the_twelite.board.use<PAL_MAG>();

u8ID = (brd.get_DIPSW_BM() & 0x07) + 1;
if (u8ID == 0) u8ID = 0xFE; // 0 is to 0xFE

Here, three bits of the 4-bit DIP SW on the board are read and set as the child ID. If it is 0, it is set as a child device without ID (0xFE).

LED settings are made. Here, the LED is set to blink ON/OFF every 10ms (in applications where sleep is performed and wake-up time is short, this setting is almost the same as being lit during wake-up).

	brd.set_led(LED_TIMER::BLINK, 10); // blink (on 10ms/ off 10ms)

begin()

The begin() function is called just before the first loop() after the setup() function ends (then TWENET initialization is performed).

void begin() {
	sleepNow(); // the first time is just sleeping.
}

sleepNow() is called after setup() ends to perform the initial sleep.

sleepNow()

void sleepNow() {
	uint32_t u32ct = 60000;

	pinMode(PAL_MAG::PIN_SNS_OUT1, PIN_MODE::WAKE_FALLING);
	pinMode(PAL_MAG::PIN_SNS_OUT2, PIN_MODE::WAKE_FALLING);

	the_twelite.sleep(u32ct);
}

Before entering sleep, interrupt settings for magnetic sensor DIO pins are made using pinMode(). The second parameter specifies PIN_MODE::WAKE_FALLING, which wakes up when the pin state changes from HIGH to LOW.

On line 7, the_twelite.sleep() is called to execute sleep. The parameter 60000 is necessary to reset the watchdog of the TWELITE PAL board. Without resetting, a hardware reset occurs after 60 seconds.

wakeup()

When waking up from sleep, wakeup() is called. After that, loop() is called each time. Before wakeup(), peripherals such as UART and board devices are woken up (such as resetting the watchdog timer). For example, LED control restarts.

void wakeup() {
	if (the_twelite.is_wokeup_by_wktimer()) {
		sleepNow();
	}
}

Here, if waking up by the wake timer (the_twelite.is_wokeup_by_wktimer()), sleep is executed again. This wake-up is only for resetting the watchdog timer mentioned above.

In the case of waking up by magnetic sensor detection, it proceeds to loop() processing as is.

loop()

Here, the detected magnetic sensor DIO is checked, a packet is transmitted, and after transmission completes, it goes back to sleep.

void loop() {
	if (!b_transmit) {
		if (auto&& pkt =
      the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet())

			uint8_t b_north =
			  the_twelite.is_wokeup_by_dio(PAL_MAG::PIN_SNS_NORTH);
			uint8_t b_south =
			  the_twelite.is_wokeup_by_dio(PAL_MAG::PIN_SNS_SOUTH);

			Serial << "..sensor north=" << int(b_north)
			       << " south=" << int(b_south) << mwx::crlf;

			// set tx packet behavior
			pkt << tx_addr(0x00)
				<< tx_retry(0x1)
				<< tx_packet_delay(0, 0, 2);

			// prepare packet payload
			pack_bytes(pkt.get_payload()
				, make_pair(FOURCHARS, 4)
				, b_north
				, b_south
			);

			// do transmit
			MWX_APIRET ret = pkt.transmit();

			if (ret) {
				u8txid = ret.get_value() & 0xFF;
				b_transmit = true;
			}
			else {
				// fail to request
				sleepNow();
			}
		} else {
		  sleepNow();
		}
	} else {
		if (the_twelite.tx_status.is_complete(u8txid)) {
			b_transmit = 0;
			sleepNow();
		}
	}
}

The behavior inside loop() is controlled by the variable b_transmit. After a successful transmission request, this value is set to 1 and waits for packet transmission completion.

	if (!b_transmit) {

The detection DIO pins of the magnetic sensor are checked. There are two types of detection pins: north pole detection and south pole detection. If you simply want to know that a magnet approached, detection of either pin is the condition.

uint8_t b_north =
  the_twelite.is_wokeup_by_dio(PAL_MAG::PIN_SNS_NORTH);
uint8_t b_south =
  the_twelite.is_wokeup_by_dio(PAL_MAG::PIN_SNS_SOUTH);

To check the wake-up source pin, use the_twelite.is_wokeup_by_dio(). The parameter is the pin number. The return value is stored in uint8_t to be included in the packet payload.

After setting communication conditions and preparing the payload, transmission is performed.

// do transmit
MWX_APIRET ret = pkt.transmit();

Then, if b_transmit is true in loop(), completion check is performed, and if complete, sleep is executed again by sleepNow().

if (the_twelite.tx_status.is_complete(u8txid)) {
	b_transmit = 0;
	sleepNow();
}

Transmission completion is confirmed by the_twelite.tx_status.is_complete(u8txid). u8txid is the ID value returned at the time of transmission.

4.1.13 - PAL_MOT-single

Sample using motion sensor pal
In this act, after waking up from sleep, a few samples of acceleration data are acquired and the data is sent.

Explanation of the act

The flow is wake up → start acquiring acceleration sensor → wait for acceleration sensor FIFO interrupt → retrieve acceleration sensor data → wireless transmission → sleep.

Declaration section

Include

##include <TWELITE>    // MWX library basics
##include <NWK_SIMPLE> // Network
##include <SM_SIMPLE>  // State machine (state transition)
##include <STG_STD>    // Interactive mode

/*** board selection (choose one) */
##define USE_PAL_MOT
//#define USE_CUE
// board dependend definitions.
##if defined(USE_PAL_MOT)
##define BRDN PAL_MOT
##define BRDC <PAL_MOT>
##elif defined(USE_CUE)
##define BRDN CUE
##define BRDC <CUE>
##endif
// include board support
##include BRDC

To support MOT PAL or TWELITE CUE, the include section is macro-based. Define either USE_PAL_MOT or USE_CUE.

If USE_PAL_MOT is defined, the board behavior <PAL_MOT> of the motion sensor pal is included.

State definition

enum class E_STATE : uint8_t {
	INTERACTIVE = 255,
	INIT = 0,
	START_CAPTURE,
	WAIT_CAPTURE,
	REQUEST_TX,
	WAIT_TX,
	EXIT_NORMAL,
	EXIT_FATAL
};
SM_SIMPLE<E_STATE> step;

To perform sequential processing in loop(), states are defined, and the state machine step is declared.

Sensor data storage

struct {
	int32_t x_ave, y_ave, z_ave;
	int32_t x_min, y_min, z_min;
	int32_t x_max, y_max, z_max;
	uint16_t n_seq;
	uint8_t n_samples;
} sensor;

Data structure for storing sensor data.

setup()

/// load board and settings objects
auto&& brd = the_twelite.board.use BRDC (); // load board support
auto&& set = the_twelite.settings.use<STG_STD>(); // load save/load settings(interactive mode) support
auto&& nwk = the_twelite.network.use<NWK_SIMPLE>(); // load network support

Registers board, settings, and network behavior objects.

Interactive mode

// settings: configure items
set << SETTINGS::appname("MOT");
set << SETTINGS::appid_default(DEFAULT_APP_ID); // set default appID
set << SETTINGS::ch_default(DEFAULT_CHANNEL); // set default channel
set << SETTINGS::lid_default(0x1); // set default LID
set.hide_items(E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);

// if SET=LOW is detected, start with intaractive mode.
if (digitalRead(brd.PIN_SET) == PIN_STATE::LOW) {
	set << SETTINGS::open_at_start();
	brd.set_led(LED_TIMER::BLINK, 300); // slower blink
	step.next(STATE::INTERACTIVE);
	return;
}

// load settings
set.reload(); // load from EEPROM.
OPT_BITS = set.u32opt1(); // this value is not used in this example.

Initializes interactive mode.

First, configuration items are adjusted. Here, the menu title name SETTINGS::appname, default application ID SETTINGS::appid_default, default channel SETTINGS::ch_default, default logical device ID SETTINGS::lid_default, and hidden items .hide_items() are set.

In this sample, if the SET pin is LOW at startup, it transitions to interactive mode. If the pin is confirmed LOW by digitalRead(brd.PIN_SET), SETTINGS::open_at_start() is specified. This causes the interactive mode screen to be displayed promptly after exiting setup(). Even when the screen is displayed, begin() and loop() are executed. In this sample, the state STATE::INTERACTIVE is set so that no sleep or other actions are performed in loop().

Next, settings values are loaded. To read settings, .reload() must always be executed. In this sample, option bit setting .u32opt1() is read.

the_twelite

the_twelite << set;

the_twelite is a class object that manages the system’s basic behavior. This object performs various initializations such as application ID and channel in setup().

Here, part of the interactive mode settings is applied.

NWK_SIMPLE object

nwk << set;

Settings are also applied to the network behavior object. Logical device ID (LID) and retransmission settings of interactive mode are applied.

Other hardware initialization

brd.set_led(LED_TIMER::BLINK, 100);

LED blink settings and others are performed.

begin()

void begin() {
	auto&& set = the_twelite.settings.use<STG_STD>();
	if (!set.is_screen_opened()) {
		// sleep immediately, waiting for the first capture.
		sleepNow();
	}
}

Called after setup() finishes. Here, the initial sleep is executed. However, if the interactive mode screen is displayed, sleep is not performed.

wakeup()

void wakeup() {
	Serial << crlf << "--- PAL_MOT(OneShot):"
	       << FOURCHARS << " wake up ---" << crlf;
	eState = E_STATE::INIT;
}

After waking up, the state variable eState is set to the initial state INIT. Then loop() is executed.

loop()

void loop() {
	auto&& brd = the_twelite.board.use<PAL_MOT>();

	do {
		switch(step.state()) {
			case STATE::INTERACTIVE:
			break;
		...
	} while(step.b_more_loop());
}

The basic structure of loop() uses the <SM_STATE> state machine state and control with switch … case statements. The initial state is STATE::INIT or STATE::INTERACTIVE.

STATE::INTERACTIVE

State when the interactive mode screen is displayed. Does nothing. Serial input/output is used by interactive mode on this screen.

STATE::INIT

Initial state INIT.

case STATE::INIT:
	brd.sns_MC3630.get_que().clear(); // clear queue in advance (just in case).
	memset(&sensor, 0, sizeof(sensor)); // clear sensor data
	step.next(STATE::START_CAPTURE);
break;

In state INIT, initialization (clearing the queue for storing results) and initialization of the data structure for storing results are performed. Transition to STATE::START_CAPTURE. After this transition, the while loop is executed again.

STATE::CAPTURE

case STATE::START_CAPTURE:
	brd.sns_MC3630.begin(
		// 400Hz, +/-4G range, get four samples and will average them.
		SnsMC3630::Settings(
			SnsMC3630::MODE_LP_400HZ, SnsMC3630::RANGE_PLUS_MINUS_4G, N_SAMPLES));

	step.set_timeout(100);
	step.next(STATE::WAIT_CAPTURE);
break;

In state START_CAPTURE, FIFO acquisition of the MC3630 sensor is started. Here, FIFO interrupt occurs when 4 samples are acquired at 400Hz.

Timeout for exception handling is set, and transition to the next state STATE::WAIT_CAPTURE.

STATE::WAIT_CAPTURE

case STATE::WAIT_CAPTURE:
	if (brd.sns_MC3630.available()) {
		brd.sns_MC3630.end(); // stop now!

In state WAIT_CAPTURE, it waits for FIFO interrupt. When interrupt occurs and data is stored in the queue for results, sns_MC3630.available() becomes true. sns_MC3630.end() is called to stop processing.

sensor.n_samples = brd.sns_MC3630.get_que().size();
if (sensor.n_samples) sensor.n_seq = brd.sns_MC3630.get_que()[0].get_t();
...

The number of samples and the sequence number of the samples are obtained.

// get all samples and average them.
for (auto&& v: brd.sns_MC3630.get_que()) {
	sensor.x_ave  += v.x;
	sensor.y_ave  += v.y;
	sensor.z_ave  += v.z;
}

if (sensor.n_samples == N_SAMPLES) {
	// if N_SAMPLES == 2^n, division is much faster.
	sensor.x_ave /= N_SAMPLES;
	sensor.y_ave /= N_SAMPLES;
	sensor.z_ave /= N_SAMPLES;
}
...

All sample data is read and averaged.

// can also be:
//	int32_t x_max = -999999, x_min = 999999;
//	for (auto&& v: brd.sns_MC3630.get_que()) {
//		if (v.x >= x_max) x_max = v.x;
//		if (v.y <= x_min) x_min = v.x;
//		...
//	}
auto&& x_minmax = std::minmax_element(
	get_axis_x_iter(brd.sns_MC3630.get_que().begin()),
	get_axis_x_iter(brd.sns_MC3630.get_que().end()));
sensor.x_min = *x_minmax.first;
sensor.x_max = *x_minmax.second;
...

Here, the min and max of each axis are obtained using iterators corresponding to the acquired samples.

if (brd.sns_MC3630.available()) {
  ...
  brd.sns_MC3630.get_que().clear(); // clean up the queue
  step.next(STATE::REQUEST_TX); // next state
} else if (step.is_timeout()) {
  Serial << crlf << "!!!FATAL: SENSOR CAPTURE TIMEOUT.";
  step.next(STATE::EXIT_FATAL);
}
break;

.sns_MC3630.get_que().clear() is called to clear the data in the queue. Without calling this, subsequent sample acquisition is not possible. Then it transitions to STATE::REQUEST_TX.

.is_timeout() checks for timeout. On timeout, it transitions to STATE::EXIT_FATAL as an error.

STATE::REQUEST_TX

case STATE::REQUEST_TX:
	if (TxReq()) {
		step.set_timeout(100);
		step.clear_flag();
		step.next(STATE::WAIT_TX);
	} else {
		Serial << crlf << "!!!FATAL: TX REQUEST FAILS.";
		step.next(STATE::EXIT_FATAL);
	}
break;

In state REQUEST_TX, the locally defined function TxReq() is called to process the obtained sensor data and generate/send the transmission packet. Transmission requests may fail due to the transmission queue status, etc. If the transmission request succeeds, TxReq() returns true, but transmission is not yet performed. Transmission completion calls the on_tx_comp() callback.

Also, .clear_flag() clears the flag used to indicate transmission completion. Timeout is also set simultaneously.

E_STATE::WAIT_TX

case STATE::WAIT_TX:
	if (step.is_flag_ready()) {
		step.next(STATE::EXIT_NORMAL);
	}
	if (step.is_timeout()) {
		Serial << crlf << "!!!FATAL: TX TIMEOUT.";
		step.next(STATE::EXIT_FATAL);
	}
break;

In state STATE::WAIT_TX, it waits for wireless packet transmission completion. The flag is set by the on_tx_comp() callback function, and .is_flag_ready() becomes true after being set.

E_STATE::EXIT_NORMAL, E_STATE::EXIT_FATAL

case STATE::EXIT_NORMAL:
	sleepNow();
break;

case STATE::EXIT_FATAL:
	Serial << flush;
	the_twelite.reset_system();
break;

When the series of operations is completed, it transitions to state STATE::EXIT_NORMAL and calls the locally defined function sleepNow() to execute sleep. If an error is detected, it transitions to state STATE::EXIT_FATAL and performs a system reset.

MWX_APIRET TxReq()

MWX_APIRET TxReq() {
	auto&& brd = the_twelite.board.use<PAL_MOT>();
	MWX_APIRET ret = false;

	// prepare tx packet
	if (auto&& pkt = the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet()) {
		// set tx packet behavior
		pkt << tx_addr(0x00)  // 0..0xFF (LID 0:parent, FE:child w/ no id, FF:LID broad cast), 0x8XXXXXXX (long address)
			<< tx_retry(0x1) // set retry (0x1 send two times in total)
			<< tx_packet_delay(0, 0, 2); // send packet w/ delay

		// prepare packet (first)
		pack_bytes(pkt.get_payload() // set payload data objects.
				, make_pair(FOURCHARS, 4)  // just to see packet identification, you can design in any.
				, uint16_t(sensor.n_seq)
				, uint8_t(sensor.n_samples)
				, uint16_t(sensor.x_ave)
				, uint16_t(sensor.y_ave)
				, uint16_t(sensor.z_ave)
				, uint16_t(sensor.x_min)
				, uint16_t(sensor.y_min)
				, uint16_t(sensor.z_min)
				, uint16_t(sensor.x_max)
				, uint16_t(sensor.y_max)
				, uint16_t(sensor.z_max)
			);

		// perform transmit
		ret = pkt.transmit();

		if (ret) {
			Serial << "..txreq(" << int(ret.get_value()) << ')';
		}
	}

	return ret;
}

Finally, packet generation and transmission request are performed. The packet includes sequence number, sample count, XYZ average values, XYZ minimum sample values, and XYZ maximum sample values.

sleepNow()

void sleepNow() {
	Serial << crlf << "..sleeping now.." << crlf;
	Serial.flush();
	step.on_sleep(false); // reset state machine.
	the_twelite.sleep(3000, false); // set longer sleep (PAL must wakeup less than 60sec.)
}

Sleep procedure.

  • The serial port calls Serial.flush() before sleep to output everything.
  • The <SM_SIMPLE> state machine must perform on_sleep().

4.1.14 - PAL_MOT-fifo

Sample using motion sensor pal
The motion sensor PAL MOTION SENSE PAL is used to acquire sensor values.

Features of the Act

  • Uses the motion sensor PAL MOTION SENSE PAL to continuously measure acceleration via the accelerometer and wirelessly transmits the data.
  • Utilizes a sleep function for operation with a coin battery.

How to Use the Act

Required TWELITE

RoleExample
ParentOperate MONOSTICK BLUE or RED act Parent_MONOSTICK.
ChildBLUE PAL or RED PAL + MOTION SENSE PAL

Act Explanation

Include

##include <TWELITE>
##include <NWK_SIMPLE>
##include <PAL_MOT>

Include the board behavior <PAL_MOT> for the motion sensor PAL.

setup()

void setup() {
	/*** SETUP section */
	// board
	auto&& brd = the_twelite.board.use<PAL_MOT>();
	brd.set_led(LED_TIMER::BLINK, 100);

	// the twelite main class
	the_twelite
		<< TWENET::appid(APP_ID)
		<< TWENET::channel(CHANNEL);

	// Register Network
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();
	nwk	<< NWK_SIMPLE::logical_id(0xFE);

	/*** BEGIN section */
	the_twelite.begin(); // start twelite!
	brd.sns_MC3630.begin(SnsMC3630::Settings(
		SnsMC3630::MODE_LP_14HZ, SnsMC3630::RANGE_PLUS_MINUS_4G));

	/*** INIT message */
	Serial << "--- PAL_MOT(Cont):" << FOURCHARS
				 << " ---" << mwx::crlf;
}

First, register the board behavior <PAL_MOT>. When initializing the board behavior, the sensor and DIO are also initialized. Typically, you first check the state of the board’s DIP switches and then proceed with network settings and other processing.

auto&& brd = the_twelite.board.use<PAL_MOT>();

u8ID = (brd.get_DIPSW_BM() & 0x07) + 1;
if (u8ID == 0) u8ID = 0xFE; // 0 is to 0xFE

Here, three bits out of the four DIP switches on the board are read and set as the child device’s ID. If the value is 0, it is set as a child without an ID (0xFE).

Set the LED configuration. Here, the LED is set to blink ON/OFF every 10ms (for applications with short wake times due to sleep, this is almost equivalent to lighting the LED while awake).

	brd.set_led(LED_TIMER::BLINK, 10); // blink (on 10ms/ off 10ms)

Accelerometer Initialization

	brd.sns_MC3630.begin(SnsMC3630::Settings(
		SnsMC3630::MODE_LP_14HZ, SnsMC3630::RANGE_PLUS_MINUS_4G));

Start measurement with the accelerometer. The accelerometer settings (SnsMC3630::Settings) specify the measurement frequency and range. Here, measurement is performed at 14Hz (SnsMC3630::MODE_LP_14HZ) with a ±4G range (SnsMC3630::RANGE_PLUS_MINUS_4G).

After starting, the accelerometer measures 14 times per second, and the values are stored in the sensor’s internal FIFO queue. Notification occurs when 28 measurements are completed.

begin()

The begin() function is called after the setup() function finishes (and after TWENET initialization), right before the first loop().

void begin() {
	sleepNow(); // the first time is just sleeping.
}

After setup() ends, sleepNow() is called to enter initial sleep.

sleepNow()

void sleepNow() {
	pinMode(PAL_MOT::PIN_SNS_INT, WAKE_FALLING);
	the_twelite.sleep(60000, false);
}

Before entering sleep, configure the interrupt setting for the accelerometer’s DIO pin. This interrupt occurs when the FIFO queue reaches a certain number. Use pinMode(). The second parameter specifies PIN_MODE::WAKE_FALLING, which means the device wakes up when the pin state changes from HIGH to LOW.

On the third line, the_twelite.sleep() puts the device to sleep. The parameter 60000 is required to wake up and reset the TWELITE PAL board’s watchdog. If not reset, a hard reset will occur after 60 seconds.

wakeup()

When the device wakes up from sleep due to a FIFO interrupt from the accelerometer, the wakeup() function is called. After that, loop() is called each time. Before wakeup(), peripherals such as UART and onboard devices perform their own wake-up processing (such as resetting the watchdog timer). For example, LED control is restarted.

void wakeup() {
	Serial << "--- PAL_MOT(Cont):" << FOURCHARS
	       << " wake up ---" << mwx::crlf;

	b_transmit = false;
	txid[0] = 0xFFFF;
	txid[1] = 0xFFFF;
}

Here, variables used in loop() are initialized.

loop()

Here, the acceleration information stored in the accelerometer’s FIFO queue is retrieved and used to transmit packets. After packet transmission is completed, the device enters sleep again.

void loop() {
	auto&& brd = the_twelite.board.use<PAL_MOT>();

	if (!b_transmit) {
		if (!brd.sns_MC3630.available()) {
			Serial << "..sensor is not available."
					<< mwx::crlf << mwx::flush;
			sleepNow();
		}

		// send a packet
		Serial << "..finish sensor capture." << mwx::crlf
			<< "  seq=" << int(brd.sns_MC3630.get_que().back().t)
			<< "/ct=" << int(brd.sns_MC3630.get_que().size());

		// calc average in the queue.
		{
			int32_t x = 0, y = 0, z = 0;
			for (auto&& v: brd.sns_MC3630.get_que()) {
				x += v.x;
				y += v.y;
				z += v.z;
			}
			x /= brd.sns_MC3630.get_que().size();
			y /= brd.sns_MC3630.get_que().size();
			z /= brd.sns_MC3630.get_que().size();

			Serial << format("/ave=%d,%d,%d", x, y, z) << mwx::crlf;
		}

		for (int ip = 0; ip < 2; ip++) {
			if(auto&& pkt =
				the_twelite.network.use<NWK_SIMPLE>().prepare_tx_packet())

				// set tx packet behavior
				pkt << tx_addr(0x00)
					<< tx_retry(0x1)
					<< tx_packet_delay(0, 0, 2);

				// prepare packet (first)
				uint8_t siz = (brd.sns_MC3630.get_que().size() >= MAX_SAMP_IN_PKT)
									? MAX_SAMP_IN_PKT : brd.sns_MC3630.get_que().size();
				uint16_t seq = brd.sns_MC3630.get_que().front().t;

				pack_bytes(pkt.get_payload()
					, make_pair(FOURCHARS, 4)
					, seq
					, siz
				);

				// store sensor data (36bits into 5byts, alas 4bits are not used...)
				for (int i = 0; i < siz; i++) {
					auto&& v = brd.sns_MC3630.get_que().front();
					uint32_t v1;

					v1  = ((uint16_t(v.x/2) & 4095) << 20)  // X:12bits
						| ((uint16_t(v.y/2) & 4095) <<  8)  // Y:12bits
						| ((uint16_t(v.z/2) & 4095) >>  4); // Z:8bits from MSB
					uint8_t v2 = (uint16_t(v.z/2) & 255);   // Z:4bits from LSB
					pack_bytes(pkt.get_payload(), v1, v2); // add into pacekt entry.
					brd.sns_MC3630.get_que().pop(); // pop an entry from queue.
				}

				// perform transmit
				MWX_APIRET ret = pkt.transmit();

				if (ret) {
					Serial << "..txreq(" << int(ret.get_value()) << ')';
					txid[ip] = ret.get_value() & 0xFF;
				} else {
					sleepNow();
				}
			}
		}

		// finished tx request
		b_transmit = true;
	} else {
		if(		the_twelite.tx_status.is_complete(txid[0])
			 && the_twelite.tx_status.is_complete(txid[1]) ) {

			sleepNow();
		}
	}
}

The b_transmit variable controls the behavior within loop(). After a transmission request succeeds, this value is set to 1 to wait for packet transmission completion.

	if (!b_transmit) {

First, check whether the sensor is available. Since this is after waking up from an interrupt, it is unusual for it to be unavailable, so sleep is entered immediately in that case.

if (!brd.sns_MC3630.available()) {
	Serial << "..sensor is not available."
			<< mwx::crlf << mwx::flush;
	sleepNow();
}

Although not used in the wireless transmission packet, the retrieved acceleration information is checked here.

Serial << "..finish sensor capture." << mwx::crlf
	<< "  seq=" << int(brd.sns_MC3630.get_que().front().t)
	<< "/ct=" << int(brd.sns_MC3630.get_que().size());

// calc average in the queue.
{
	int32_t x = 0, y = 0, z = 0;
	for (auto&& v: brd.sns_MC3630.get_que()) {
		x += v.x;
		y += v.y;
		z += v.z;
	}
	x /= brd.sns_MC3630.get_que().size();
	y /= brd.sns_MC3630.get_que().size();
	z /= brd.sns_MC3630.get_que().size();

	Serial << format("/ave=%d,%d,%d", x, y, z) << mwx::crlf;
}

The measurement results from the accelerometer are stored in a FIFO queue, which can be obtained with brd.sns_MC3630.get_que().

The structure axis_xyzt that stores the measurement results contains information for the three axes x, y, z, as well as a sequence number t.

The number of stored samples can be checked by reading the queue size (brd.sns_MC3630.get_que().size()). Normally, there are 28 samples, but this may increase slightly due to processing delays, etc. The first sample can be obtained with front(), and its sequence number is front().t.

Here, before removing samples from the queue, the average of the samples is calculated. Each element of the queue can be accessed with a for statement (for (auto&& v: brd.sns_MC3630.get_que()) { ... }). Within the loop, v.x, v.y, v.z are the respective elements. The sum of each element is calculated, and after the loop, the average is computed by dividing by the number of elements.

Next, a packet is generated and a transmission request is made. Since the amount of data is large, transmission is performed in two parts, so the transmission processing is executed twice in a for loop.

		for (int ip = 0; ip < 2; ip++) {

The number of samples to be included in the transmitted packet and the sequence number of the first sample are stored at the beginning of the packet’s payload.

// prepare packet (first)
uint8_t siz = (brd.sns_MC3630.get_que().size() >= MAX_SAMP_IN_PKT)
? MAX_SAMP_IN_PKT : brd.sns_MC3630.get_que().size();
uint16_t seq = brd.sns_MC3630.get_que().front().t;

pack_bytes(pkt.get_payload()
	, make_pair(FOURCHARS, 4)
	, seq
	, siz
);

Finally, the acceleration data is stored. Previously, each element in the queue was referenced only for average calculation, but here, samples are read one by one from the queue and stored in the packet payload.

for (int i = 0; i < siz; i++) {
	auto&& v = brd.sns_MC3630.get_que().front();
	uint32_t v1;

	v1  = ((uint16_t(v.x/2) & 4095) << 20)  // X:12bits
		| ((uint16_t(v.y/2) & 4095) <<  8)  // Y:12bits
		| ((uint16_t(v.z/2) & 4095) >>  4); // Z:8bits from MSB
	uint8_t v2 = (uint16_t(v.z/2) & 255);   // Z:4bits from LSB
	pack_bytes(pkt.get_payload(), v1, v2); // add into pacekt entry.
	brd.sns_MC3630.get_que().pop(); // pop an entry from queue.
}

To read the head of the data queue from the accelerometer, use .front(). After reading, use .pop() to release the head of the queue.

The data obtained from the accelerometer is in units of milli-G, where 1G = 1000. Since the range is ±4G, the value is divided by 2 to fit within 12 bits. To save data size, the first 4 bytes store the X, Y axes and the upper 8 bits of the Z axis, and the next 1 byte stores the lower 4 bits of the Z axis, making a total of 5 bytes per sample.

The transmission IDs are stored in the txid[] array to wait for the completion of two transmissions.

MWX_APIRET ret = pkt.transmit();

if (ret) {
	Serial << "..txreq(" << int(ret.get_value()) << ')';
	txid[ip] = ret.get_value() & 0xFF;
} else {
	sleepNow();
}

After that, if b_transmit is true in loop(), a completion check is performed, and if complete, the device enters sleep via sleepNow().

} else {
	if(		the_twelite.tx_status.is_complete(txid[0])
		 && the_twelite.tx_status.is_complete(txid[1]) ) {

		sleepNow();
	}
}

Transmission completion is checked with the_twelite.tx_status.is_complete(). The txid[] array contains the ID values returned at the time of transmission.

4.1.15 - PulseCounter

Sample using pulse counter
This is an example using the PulseCounter.

A pulse counter counts the number of rising or falling edges of a signal without involving a microcontroller. It can be used to count irregular pulses and send the count via wireless packet when the count reaches a certain number.

Act Functions

  • Counts pulses connected to the child device’s DIO8 and sends wireless transmission after a certain time has elapsed or a certain count is detected.
  • The child device operates while sleeping.

How to Use the Act

Required TWELITE

RoleExample
ParentMONOSTICK BLUE or RED
Run the act Parent_MONOSTICK.
Child1. TWELITE DIP
2. BLUE PAL or RED PAL + Environmental Sensor PAL AMBIENT SENSE PAL

Explanation of the Act

setup()

// Pulse Counter setup
PulseCounter.setup();

Initializes the pulse counter.

begin()

void begin() {
	// start the pulse counter capturing
	PulseCounter.begin(
		  100 // 100 count to wakeup
		, PIN_INT_MODE::FALLING // falling edge
		);

	sleepNow();
}

Starts the pulse counter operation and performs the initial sleep. The first parameter of PulseCounter.begin() is the count number 100 to trigger the wakeup interrupt, and the second parameter specifies falling edge detection PIN_INT_MODE::FALLING.

wakeup()

void wakeup() {
	Serial	<< mwx::crlf
			<< "--- Pulse Counter:" << FOURCHARS << " wake up ---"
			<< mwx::crlf;

	if (!PulseCounter.available()) {
		Serial << "..pulse counter does not reach the reference value." << mwx::crlf;
		sleepNow();
	}
}

Checks PulseCounter.available() on wakeup. If available is true, it means the count has reached or exceeded the specified count. If false, it goes back to sleep.

If the count is above the specified value, the sending process and waiting for send completion are performed in loop().

loop()

uint16_t u16ct = PulseCounter.read();

Reads the pulse count value. The counter is reset after reading.

4.1.16 - WirelessUART

Performs serial communication.
WirelessUART performs serial communication.

Act Features

  • Communicates between two TWELITE devices connected via UART using ASCII format.

How to Use the Act

Required TWELITE Devices

Use two devices connected to the PC via serial connection as follows:

Explanation of the Act

setup()

void setup() {
	auto&& set = the_twelite.settings.use<STG_STD>();
	auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();

	/*** INTERACTIVE MODE */
	// settings: configure items
	set << SETTINGS::appname("WirelessUART");
	set << SETTINGS::appid_default(DEFAULT_APP_ID); // set default appID
	set << SETTINGS::ch_default(DEFAULT_CHANNEL); // set default channel
	set << SETTINGS::lid_default(DEFAULT_LID); // set default lid
	set.hide_items(E_STGSTD_SETID::OPT_DWORD2, E_STGSTD_SETID::OPT_DWORD3, E_STGSTD_SETID::OPT_DWORD4, E_STGSTD_SETID::ENC_KEY_STRING, E_STGSTD_SETID::ENC_MODE);
	set.reload(); // load from EEPROM.

	/*** SETUP section */
	// the twelite main class
	the_twelite
		<< set                      // from interactive mode (APPID/CH/POWER)
		<< TWENET::rx_when_idle();  // open receive circuit (if not set, it can't listen packets from others)

	// Register Network
	nwk	<< set;						// from interactive mode (LID/REPEAT)

	/*** BEGIN section */
	SerialParser.begin(PARSER::ASCII, 128); // Initialize the serial parser
	the_twelite.begin(); // start twelite!

	/*** INIT message */
	Serial << "--- WirelessUart (id=" << int(nwk.get_config().u8Lid) << ") ---" << mwx::crlf;
}

Initializes the interactive mode. In this sample, prepare two or more devices with different logical device IDs (LID).

SerialParser.begin(PARSER::ASCII, 128);

Initializes the serial parser.

loop()

while(Serial.available())  {
	if (SerialParser.parse(Serial.read())) {
		Serial << ".." << SerialParser;
		const uint8_t* b = SerialParser.get_buf().begin();
		uint8_t addr = *b; ++b; // the first byte is destination address.
		transmit(addr, b, SerialParser.get_buf().end());
	}
}

When data input is detected from the serial port, one byte is input to the serial parser. When the ASCII format is fully received, SerialParser.parse() returns true.

SerialParser allows access to the internal buffer via smplbuf. In the example above, the first byte of the buffer is extracted as the destination address, and the bytes from the second byte to the end are passed to the transmit() function.

on_rx_packet()

When a packet is received, a buffer smplbuf_u8<128> buf is created containing the sender as the first byte followed by the payload, and it is output to the serial port via the serial parser serparser_attach pout.

void on_rx_packet(packet_rx& rx, bool_t &handled) {
	// check the packet header.
	const uint8_t* p = rx.get_payload().begin();
	if (rx.get_length() > 4 && !strncmp((const char*)p, (const char*)FOURCHARS, 4)) {
		Serial << format("..rx from %08x/%d", rx.get_addr_src_long(), rx.get_addr_src_lid()) << mwx::crlf;

		smplbuf_u8<128> buf;
		mwx::pack_bytes(buf
				, uint8_t(rx.get_addr_src_lid())            // src addr (LID)
				, make_pair(p+4, rx.get_payload().end()) );	// data body

		serparser_attach pout;
		pout.begin(PARSER::ASCII, buf.begin(), buf.size(), buf.size());
		Serial << pout;
	}
}

Commands for Testing

Example

:FE00112233X

:FE001122339C

Send 00112233 to any child device.

Example

:03AABBCC00112233X

:03AABBCC0011223366

Send AABBCC00112233 to child device number 3.

Example

:FF00112233X

:00112233X

Send to any parent or child device (0xFF), or to the parent device (0x00).

4.1.17 - Universal Receiver

Receives various types of packets

By running NWK_LAYERED on twe_twelite.network and NWK_SIMPLE on twe_twelite.network2 in the MWX library, you can receive and interpret various types of packets, including Layered Tree Network packets (such as TWELITE PAL, ARIA).

However, radio packets must be on the same channel and have the same application ID.

main.cpp

setup(), loop(), and the received packet callback function on_rx_packet() are described.

setup()

These objects are declared in pkt_handler.cpp and initialized with pnew() during setup(). They mainly interpret the packet payload (data).

	mwx::pnew(g_pkt_pal);
	mwx::pnew(g_pkt_apptwelite);
	mwx::pnew(g_pkt_actsamples);
	mwx::pnew(g_pkt_unknown);

Two network objects are created. Always set the_twelite.network to NWK_LAYERED.

	auto&& nwk_ly = the_twelite.network.use<NWK_LAYERED>();
	auto&& nwk_sm = the_twelite.network2.use<NWK_SIMPLE>();

loop()

In this sample, the important process in loop() is the .refresh() operation performed approximately every 1 second. Only g_pkt_apptwelite().refresh() performs the duplicate checker timeout processing. The other objects do nothing.

	if (TickTimer.available()) {
		static unsigned t;
		if (!(++t & 0x3FF)) {
			g_pkt_pal.refresh();
			g_pkt_apptwelite.refresh();
			g_pkt_actsamples.refresh();
			g_pkt_unknown.refresh();
		}
	}

on_rx_packet()

void on_rx_packet(packet_rx& rx, bool_t &handled) {
	auto type = rx.get_network_type();
	bool b_handled = false;

	// PAL
	if (!b_handled
		&& type == mwx::NETWORK::LAYERED
		&& g_pkt_pal.analyze(rx, b_handled)
	) {
		g_pkt_pal.display(rx);
	}

	// Act samples
	if (!b_handled
		&& type == mwx::NETWORK::SIMPLE
		&& g_pkt_actsamples.analyze(rx, b_handled)
	) {
		g_pkt_actsamples.display(rx);
	}

	// Standard application (e.g. App_Twelite)
	if (!b_handled
		&& type == mwx::NETWORK::NONE
		&& g_pkt_apptwelite.analyze(rx, b_handled)
	) {
		g_pkt_apptwelite.display(rx);
	}

	// unknown
	if (!b_handled) {
		g_pkt_unknown.analyze(rx, b_handled);
		g_pkt_unknown.display(rx);
	}
}

This is the most important part of this sample code. The packet type is determined by auto type = rx.get_network_type();.

  • mwx::NETWORK::LAYERED : Packet of NWK_LAYERED Layered Tree Network
  • mwx::NETWORK::SIMPLE : Packet of NWK_SIMPLE
  • mwx::NETWORK::NONE : No network (e.g. App_Twelite)
  • Others : Error or unsupported packets

In the case of mwx::NETWORK::NONE, duplicate checker processing for the same packet that may be sent multiple times due to retransmissions is not performed internally by the MWX library. You need to implement these yourself. This sample provides dup_checker.hpp and dup_checker.cpp.

Packet interpretation refers to the packet_rx& object which wraps tsRxDataApp*. The packet_rx class itself has no special functions; it only defines access methods to some information obtained from tsRxDataApp* using get_psRxDataApp().

pkt_common.hpp

Defined to unify the interface of the packet interpretation part.

template <class D>
struct pkt_handler {
	D& self() { return static_cast<D&>(*this); }
	bool analyze(packet_rx& rx, bool &b_handled) {
		return self().pkt.analyze(rx, b_handled);
	}
	void display(packet_rx& rx) {
		Serial
			<< crlf
			<< format("!PKT_%s(%03d-%08x/S=%d/L=%03d/V=%04d)"
					, self().get_label_packet_type()
					, self().pkt.data.u8addr_src
					, self().pkt.data.u32addr_src
					, rx.get_psRxDataApp()->u8Seq
					, rx.get_lqi()
					, self().pkt.data.u16volt
					);

		self().disp_detail(rx);
	}
	void refresh() {
		self()._refresh();
	}
};

// packet analyzer for App_Twelite
class pkt_handler_apptwelite : public pkt_handler<pkt_handler_apptwelite> {
	friend class pkt_handler<pkt_handler_apptwelite>;
	pkt_apptwelite pkt;
	void disp_detail(packet_rx& rx);
	const char* get_label_packet_type() { return "AppTwelite"; }
	void _refresh() { pkt.refresh(); }
public:
	pkt_handler_apptwelite() : pkt() {}
};
  • analyze() : Interpret the packet payload.
  • display() : Display packet information.
  • refresh() : Describes processing every 1 second.
  • self() : Casts to derived class D.

Furthermore, the packet interpretation class (e.g. pkt_handler_apptwelite above) contains a member object pkt. The actual packet interpretation part is implemented in each analyze() in pkt_???.cpp.

pkt_???.hpp, pkt_???.cpp

Packet interpretation parts for each packet type define analyze() and data structure data. The member data is a struct inheriting the common struct PktDataCommon. Using this common part, the code for serial output of packet data is succinctly written.

pkt_pal

Supports packets related to PAL. PAL packet structure has a complex data structure. Here, an implementation using EASTL containers is done.

  • _vect_pal_sensors : Pool of _pal_sensor objects. This object is a dedicated class used for intrusive map.
  • _map_pal_sensors : Intrusive map structure for efficient search of sensor data.

Each time multiple data in one packet are added, entries are secured in _vect_pal_sensors and values are stored. When all data in the packet are interpreted, _map_pal_sensors keyed by sensor type is constructed.

dup_checker

Implements duplicate checker. The checker’s behavior can be customized by template parameters.

Template parameters

  • MODE : Specifying MODE_REJECT_SAME_SEQ excludes packets with the same sequence number. Used when packet order is rearranged. MODE_REJECT_OLDER_SEQ adopts the newer number.
  • TIMEOUT_ms : Interval for initializing the duplicate database. Specifying 1000 means data older than 1 second are erased. Packets previously excluded can be accepted again after the database is initialized.
  • N_ENTRIES : Maximum number of elements allocated in the data structure.
  • N_BUCKET_HASH : Maximum number of hash values. Specify a prime number. Decided based on the types of wireless nodes received.

Containers

  • _mmap_entries : Intrusive hash multi-map structure. Search key is the wireless node serial number.
  • _vect_pool : Fixed number (N_ENTRIES) of elements allocated for use in the map structure.
  • _ring_vecant_idx : Manages indexes of elements in _vect_pool not used by _mmap_entries. It is a ring buffer structure; when adding elements, one value is taken from the ring buffer, and when removing, it is returned.

Duplicate check

	bool check_dup(uint32_t u32ser, uint16_t u16val, uint32_t u32_timestamp) {
		// find entry by key:u32ser.
		auto r = _mmap_entries.equal_range(u32ser);

        ...
    }

To search data from the multi-map structure, call .equal_range(). The obtained r is an iterator enumerating elements with the same serial number.

Each element (_dup_checker_entry) records timestamp and sequence number. Duplicate checking is done based on these values.

4.1.18 - Unit_???

Sample for verifying the operation of single functions
Acts starting with Unit_ are for describing very simple functions or for verifying their operation.
NameDescription
Unit_ADCSample to operate the ADC. Continuously executes ADC every 100ms and reads and displays approximately every 1 second. Sleep with the [s] key.
Unit_I2CprobeScans the I2C bus and displays device numbers that respond (some devices may not respond during this procedure).
Unit_delayMicorosecondsVerifies the operation of delayMicroseconds(). Compares with the count of a 16MHz TickTimer.
Unit_brd_CUEVerifies the operation of the accelerometer, magnetic sensor, and LED of TWELITE CUE. Input keys [a], [s], [l] from the terminal.
Unit_brd_ARIAVerifies the operation of the temperature/humidity sensor, magnetic sensor, and LED of TWELITE ARIA. Input keys [t], [s], [l] from the terminal.
Unit_brd_PAL_NOTICETests the LED lighting of Notification Pal (NOTICE PAL). Flashes all lights at startup, then operates via serial input.
- r,g,b,w: Toggle lighting modes for each color
- R,G,B,W: Change brightness for each color (disabled when off or fully on)
- c: Change cycle (when blinking)
- C: Change duty cycle when blinking
Unit_div100Verifies division and quotient calculation for 10, 100, 1000 using div10(),div100(),div1000(). Performs calculations from -99999 to 99999 and compares elapsed time with normal / and % division.
Unit_div_formatOutputs the results of div10(),div100(),div1000() as strings.
Unit_UART1Usage sample of UART1 (Serial1). Outputs input from UART0 to UART1 and input from UART1 to UART0.
Unit_Pkt_ParserSample usage of packet parser pktparser. Can interpret output from App_Wings.
※ For connecting TWELITE wireless modules via serial, using one as App_Wings and interpreting its output on the other. For connecting to non-TWELITE wireless modules, see Other Platforms.
Unit_EEPROMEEPROM read/write test code.
Unit_Cue_MagBuzProgram that sounds a buzzer connected to the SET pin when a magnet is removed, using the magnet sensor of TWELITE CUE and a piezo buzzer.
Unit_doint-bhvExample behavior description handling IO interrupts.
Unit_EASTLCollection of fragment codes using the EASTL library.

5 - Revision History

Revision history of the TWELITE STAGE SDK

Update Method

Fixes and additions after the release of the TWELITE STAGE distribution package are stored in the GitHub repository. Please replace the distribution package location as needed for use. Other updates to MWSDK may be required. Please refer to the release notes at the time of update. For MWSDK updates, please refer here.

How to Update MWX Library Code

The library source code is published on the GitHub repository. To replace the library source code, follow the steps below.

Clone the Git repository or download the source code in zip format from the link of each release.

Replace the contents of the following folder:

.../MWSTAGE/              --- TWELITE STAGE distribution folder
        .../MWSDK         --- MWSDK folder
              .../TWENET/current/src/mwx <-- Replace this folder

Updates Before Release

Updates before release may be posted below.

https://github.com/monowireless/mwx/wiki

History

0.2.0 - 2022-03-01

Library NameDependency Version
mwx0.2.0
twesettings0.2.6
TWENET C1.3.5

Main changes

  • Changed the Wire object that allocates memory to the heap area.
  • To avoid name collisions in utils.h, changed the function name from G_OCTET() to G_BYTE().
  • Changed the order of vAHI_DioInterruptEnable() in attachIntDio().
  • Added the_twelite.network2 to support universal receivers (NWK_LAYERED, NWK_SIMPLE or receiving network-less packets in the same executable code).
  • Added NWK_LAYERED (currently only supports parent device reception)
  • Introduced the function MWX_Set_Usder_App_Ver() to set the application version during MWX initialization.
  • Added mwx::pnew() to simplify placement new notation.
  • Added EASTL support
    • Added new[] operator for EASTL
  • Precompiled most of the MWX source code to speed up compilation.
  • Fixed an issue where DIO events were passed to unrelated ports.

0.1.9 - 2021-12-15

Library NameDependency Version
mwx0.1.9
twesettings0.2.6
TWENET C1.3.5

Main changes

  • Added board support BRD_ARIA and sensor definition SHT4x for TWELITE ARIA
  • Added internal procedure to allow output using Serial class object during interactive mode (Serial._force_Serial_out_during_intaractive_mode())

0.1.8 - 2021-09-09

Library NameDependency Version
mwx0.1.8
twesettings0.2.6
TWENET C1.3.5

Main changes

  • Definitions of Serial1 port and alternative port were incorrect
  • Allowed changing the baud rate of Serial (UART0)
  • Added event callbacks to notify receiving packet (on_rx_packet()) and transmission completion (on_tx_comp())
    • If the callback function is not defined, the previous procedure is still available
  • Fixed incorrect definition ID and some default values in <STG_STD> interactive mode settings
  • Allowed changing default values of channel and logical device ID in addition to AppID in <STG_STD> interactive mode settings
  • Allowed some settings of the_twelite and <NWK_SIMPLE> objects to be done in interactive mode <STG_STD> object
  • Allowed setting default retry count in <NWK_SIMPLE>
  • Disabled Serial (UART0) input/output from application while <STG_STD> interactive mode screen is displayed
  • Added CUE::PIN_SET, PAL???"":PIN_SET (PIN_BTN is unnatural to use for CUE without button)
  • Moved random() namespace to mwx:: (alias in global name)
  • Changed MONOSTICK watchdog setting to 32ms units
  • Fixed pin initialization issue when sleeping with BRD_TWELITE

0.1.7 - 2020-12-03

Library NameDependency Version
mwx0.1.7
twesettings0.2.6
TWENET C1.3.4

Main changes

0.1.6 - 2020-10-09

Library NameDependency Version
mwx0.1.6
twesettings0.2.5
TWENET C1.3.4

Main changes

  • Added div100() that calculates quotient and remainder and outputs to Serial etc.
  • Changed implementation of smplbuf<> array class. To reduce memory usage, stopped inheriting mwx::stream and defined separate inherited and helper classes.
  • Added functions mwx_printf() and mwx_snprintf()
  • Added the_twelite.stop_watchdog() and the_twelite.restart_watchdog()
  • Maintained mwx::stream: Removed operator bool(). Specified timeout of 0xff disables timeout (.set_timeout(0xff)). Added other << operators.
  • Added support for NOTICE PAL / PCA9632 (Explanation https://mwx.twelite.info/v/latest/boards/pal/pal_notice, Sample https://github.com/monowireless/Act_samples/tree/master/Unit_using_PAL_NOTICE)
  • Added non-division scale functions for 8bit and 0..1000 range.
  • Added division by 10, 100, 1000 (calculating quotient and remainder simultaneously) div10(), div100(), div1000(). Limits value range and uses multiplication and bit shifts.
  • Added methods supporting encrypted packets
    • packet_rx::is_secure_pkt(): Checks if received packet is encrypted
    • STG_STD::u8encmode(): Gets encryption setting in interactive mode
    • STG_STD::pu8enckeystr(): Gets encryption key byte string in interactive mode
  • Serial1: Default port is DIO14,15 which overlaps I2C in semiconductor specs, but since I2C usually uses these, set to DIO11(TxD), DIO9(RxD).
  • Serial: Optimized baud rate specification which divides by 100 for main baud rates.
  • Serial: Reduced proxy function storage for available(), read() to only void*, saving 8 bytes.
  • Added typedef boolean
  • Network: Added encryption support.
    • To enable encryption, set NWK_SIMPLE::secure_pkt(const uint8_t*, bool = false). The first parameter is the encryption key, the second set to true allows receiving plaintext packets.
    auto&& nwk = the_twelite.network.use<NWK_SIMPLE>();
    nwk << NWK_SIMPLE::logical_id(0xFE) // set Logical ID. (0xFE means a child device with no ID)
        << NWK_SIMPLE::secure_pkt((const uint8_t*)"0123456789ABCDEF");
        ;
  • Added support for SHT3x and BME280 sensors
  • Sensor: Added mechanism for legacy code (C library wrapper classes) to exchange settings and status.
  • Sensor: Allowed specifying I2C address for SHT3x and BME280.
  • Settings: Added hide_items() to remove unnecessary setting items.
  • Settings: Added H/W UTIL menu. Displays DI status, I2C probe, PAL EEPROM contents.
  • Settings: Added encryption-related menu.
  • I2C related fixes (to improve compatibility with code implemented using TwoWire class)
    • Added missing NO_STOP message sending code in requestFrom(false).
    • Added class name alias for TwoWire.
    • Prevented multiple initialization in begin().
    • Added setClock() method (dummy function that does nothing).
    • Added WIRE_CONF::WIRE_???KHZ. Added major bus clock settings.

0.1.5 - 2020-08-05

Library NameDependency Version
mwx0.1.5
twesettings0.2.5
TWENET C1.3.4

Main changes

  • Added setting behavior (interactive mode feature)
  • Implemented channel manager chmgr

0.1.4 - 2020-07-29

Library NameDependency Version
mwx0.1.4
twesettings0.2.4
TWENET C1.3.3

Bulk download

MWSDK2020_07_UNOFFICIAL (ReadMe)

Main changes

  • Added delayMilliseconds()
  • Added digitalReadBitmap()
  • Improved accuracy of delay()
  • Fixed issue where Serial1 instance was not defined
  • Fixed issue where Analogue interrupt handler was not called

0.1.3 - 2020-05-29

Corresponds to MWSDK2020_05

Main changes

  • Initialization of duplicate checker duplicate_checker was inadequate and did not remove duplicates as expected
  • Replaced format() implementation with less platform-dependent one. Also limited arguments to maximum 8. Number of arguments is limited if 64-bit arguments are included.

https://github.com/monowireless/mwx/releases/tag/0.1.3

0.1.2 - 2020-04-24

Corresponds to MWSDK2020_04

Main changes

  • Fixed initialization issues of Timer0..4
  • Changed internal processing of mwx::format()
  • Added experimental code for interactive mode support

https://github.com/monowireless/mwx/releases/tag/0.1.2

0.1.1 - 2020-02-28

Main changes

  • Fixed issue with handling of relay flags inside packets

https://github.com/monowireless/mwx/releases/tag/0.1.1

0.1.0 - 2019-12-23

First release (included in SDL December 2019 issue)

https://github.com/monowireless/mwx/releases/tag/0.1.0