RadioShuttle Program Installation for Turtle

After the generated “Turtle_RadioShuttle.NUCLEO_L432KC.bin” file has been dragged & dropped into the “RadioShuttle STM32 Utility” window, the RadioShuttle software is flashed to the Turtle board.

Fig. 1: The binary file has been loaded to the board

Define properties for “RadioTest”

In order to work correctly, certain properties need to be set for the sample application “RadioTest”. These can be defined using the “PropertyEditor” application, a useful tool to write properties in the permanent (“non-volatile”) memory of the Turtle board. The next steps describe how this is done.

The simple RadioShuttle test application (“RadioTest”) is meant for beginners. There are two devices which communicate with each other and share a simple message. One device is called Node, the other is a so-called Station. At the touch of the “User” button a message is transmitted from the node to the station. This also works the other way around, the station can also transmit a message to the node, assuming the node has been configured as Node Online (default is Node Offline).

After the software has been successfully flashed under macOS, a “Terminal” program window is automatically opened (Fig. 2) showing any output of the flashed program, e.g. Arm compiler version, voltage and type of source, available memory, etc.

If “Terminal” does not start automatically (as described above), please open the menu entry “Terminal > ttyusbmodem<…>” in the “RadioShuttle STM32 Utility”.

Under Windows, the terminal emulator (e.g. “Tera Term”) must connect to the new COM port. The “Connect target serial UART to host terminal” section on the Nucleo ST-Link Interface page explains this in detail.

Fig. 2: macOS “Terminal” output

This will open the RadioShuttle PropertyEditor. This tool can be used to list all properties (l), to set a property (s<property allocation number>=<value>, and to delete a property (d) from the permanent memory.

  • Type l (for list) and press ENTER to see a list of all available properties (“LORA_DEVICE_ID” and “LORA_CODE_ID” are already preset, see Fig. 3).
Fig. 3: Listing the properties
LORA_DEVICE_IDT_32BITBoard device ID (preset at factory, do not touch!)
LORA_CODE_IDT_32BITBoard code (preset at factory, do not touch!)
LORA_RADIO_TYPET_32BITType of use (not set):
1 = Node offline (usage as a radio sensor in “deepsleep” mode)
3 = Node online (usage as a radio sensor, always ready to receive)
4 = Station basic (operation as server for small networks)
5 = Station server (operation as server for larger networks)
LORA_REMOTE_IDT_32BITRemote station’s communications ID (not set)
T_STRSets the AES-128 encryption password per app

As mentioned before, one device (i.e. Turtle board) functions as Node, the other as Station. The RadioShuttle “PropertyEditor” allows specifying whether the board works as a node or a station.


  • For the Turtle board that should be the Station, type s14=4 (for Station Basic) and press ENTER

To allow the station to send messages to a node, the “LORA_REMOTE_ID” of the node must be entered in the station board. In this case the node must be configured as Node Online to receive messages from others:

  • Type s12=11002 and press ENTER
Fig. 4: Defined as LoRa Station Basic


  • For the Turtle board that should be the Node, type s14=1 (for Node Offline) and press ENTER

To allow the node to send messages to a station, the “LORA_REMOTE_ID” of the station must be entered in the node board:

  • Type s12=11000 and press ENTER
Fig. 5: Defined as LoRa Node Offline

Technical training video: Non-volatile settings (NV Property)

Run the “RadioTest” sample program

After the required properties are set in both Turtle boards, the “RadioTest” example program, which is included in the RadioShuttle software, can be executed to test the configuration of the boards:

  • Windows: Open “Tera Term” and set the port number and baud rate via “Setup” > “Serial port…” (see the Connect target serial UART to host terminal section for detailed information)
  • macOS: Open “Terminal”
  • Press the “User” button on any of the Turtle boards, Node or Station

The “RadioTest” program sends a message (“TxSend”) which is received by the addressed device (“RxDone”).

In the following example (Fig. 6) the node (ID “11002”) successfully transmitted a message to the station (ID “11000”). The transmission protocol also informs about the used radio frequency, spreading factor and bandwith, the air time of the message, the Rx frequency offset, etc. Using a node in offline mode, the transmission protocol ends with the line Putting the radio into Sleep.

Fig. 6: Sending a message from a node in offline mode to the station

This example (Fig. 7) shows the other way round; the station (ID “11000”) successfully transmitted a message to a node in offline mode (ID “11002”).

Fig. 7: Sending a message from the station to a node in offline mode

Reset the board

If the “Reset” button is pressed, the green LED on the Turtle board quickly flashes, indicating that it waits for a terminal connection via the USB virtual COM port. If no connection has been established after 30 seconds the board continues without USB serial console.

Statuses of the LEDs in the “RadioTest” example

LED (green):

  • Quickly flashing
    The board waits 30 seconds to connect a terminal program (via USB virtual COM port)
  • Off
    The board is idle in deepsleep and has no CPU activity
  • Partly flashing
    The board is processing tasks, while it is busy the green LED is on
  • Permanently glowing
    The board is connected to a USB virtual COM port, the CPU becomes active every milliisecond to service the USB channel
  • Permanently on
    A polling or hanging program that runs forever without going into sleep mode
  • Briefly on
    After a LoRa message has been transmitted (TX)

LED (red):

  • Pulse
    After the RadioShuttle software has started the LED shortly flashes every 2 seconds indicating that the board is active. This can be shut off by disabling timerUpdate() in the “main.cpp” file
  • Briefly on
    After a LoRa message has been received (RX)

Of course, the LEDs can also be assigned individually by the user.

The whole idea of the LEDs is to detect CPU and/or radio activity. This is very helpful to figure out whether the board is busy. For example, if the green LED is permanently lit, the board will not rest to save energy (sleep), but it is busy with USB protocols or other activity instead. The two-second impulse of the red LED mainly indicates that the board is “alive”. For final deployments with best energy savings, this behavior can be turned off.

Complete examples overview

CPUBenchCPUBench.cppMeasures the float and integer CPU performance
PropertyEditorNVPEditor.cppProgram for setting properties, which are stored in the board non-volatile. Remains after restarting or even after installing a new program. See also Non-Volatile Memory for Properties
LoRaPingPongLoRaPingPong.cppRaw LoRa ping pong example
RadioContinuousTXRadioContinuousTX.cppDiagnostic program that transmits continuously, e.g. for RF antenna measurements
BlinkyBlinky.cppPeriodic LED flashing using low-power timers
RadioTestNewRadioTestNew.cppSee detailed explanation above
PanicButtonPanicButton.cppSends sensor data to a remote station. This includes temperature, humidity and battery status. It supports an additional basic buzzer sound to confirm the help searching person that the panic alarm is on its way
RemoteTempSensorRemoteTempSensor.cppRadioShuttle remote temperature sensor, client and server implementation
RemoteRelayRemoteRelay.cppRadioShuttle remote relay control, client and server implementation
  • Press “h” followed by the program shortcut to see the corresponding command help, e.g. h b (“Blinky” help lines)

Technical training video: Non-volatile settings (NV Property)

PDF data sheet