In summary, both modes leverage Bluetooth Low Energy (BLE) and make use of the Generic Attribute Profile (GATT) protocol, a communication framework that sets standardized rules for how two – or more – devices connect, interact, and exchange data. For example, it structures data into services, each with specific, defined characteristics. Simply put: "Reliability" Mode prioritizes secure, error-free data transfer, while "Speed" Mode emphasizes fast, real-time performance, allowing you to choose the best fit for your application needs.

Reliability Mode: Uses Write with Response, where each packet is acknowledged to ensure reliable and accurate data transfer. Ideal for critical updates like firmware upgrades, it prioritizes data integrity over speed, making it suitable for scenarios where errors are unacceptable.

Speed Mode: Uses Write Without Response instead, resulting in faster data transfer by skipping acknowledgments. While it does not guarantee delivery, it is preferred for non-critical updates, such as sensor data or telemetry, where speed is more important than reliability.

No, it is not possible to change the default UART pin mapping and assignment of RX, TX, RTS, and CTS pins, as they are hardcoded in the source code of our AT interface solution; however, that being said, if you require a different setup or, for example, cannot implement the standard configuration, please contact your local sales representative or FAE. We would be happy to discuss this further and explore a customized solution tailored to your application needs. Don’t hesitate to reach out — just ask!

Download + Install via Google Play and Apple App Store:

Android: https://play.google.com/store/apps/details?id=com.siliconlabs.bledemo
iOS: https://apps.apple.com/us/app/simplicity-connect/id1030932759

Access, Review, and Edit Source Code on GitHub:

Android: https://github.com/SiliconLabs/SimplicityConnect-android
iOS: https://github.com/SiliconLabs/SimplicityConnect-ios

Copyright 2021 Silicon Laboratories
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.


The EFR Connect app has been rebranded as Simplicity Connect (or Si Connect for short) with the release of version 2.9.0 for both Android and iOS in September 2024. This update reflects the app’s evolution beyond Bluetooth Low Energy (BLE) to also include support for Wi-Fi and Matter protocols. The rebranding aligns the app with Silicon Labs' Simplicity Studio 5, creating a unified tool for developers who are working with multiple wireless technologies. Simplicity Connect retains *all* the features of EFR Connect while introducing new functionality to support the expanded protocols, making it even more versatile and easier to use.

No, neither the Lyra (22) nor the Lyra 24 series have been certified for AEC-Q100, and there are no plans to do so in the near future. 

AEC-Q100 is a qualification standard for integrated circuits (ICs) used in automotive applications, developed by the Automotive Electronics Council (AEC). It defines the testing and performance requirements that electronic components must meet to ensure their robustness in harsh automotive environments. This includes factors like extreme temperatures, vibrations, and long-term usage.

In summary, this specification covers and defines the following three grades: Grade 1 supports temperatures from -40°C to +125°C and is used in critical systems like engine control units and airbags; Grade 2 supports -40°C to +105°C for less demanding applications; and Grade 3 supports -40°C to +85°C, typically for non-critical automotive or other applications. Please refer here for additional information.

Secure Vault is Silicon Labs' security solution integrated into their 32-bit microcontrollers to protect devices from a wide range of security threats once deployed in the field. By assigning each device a unique digital fingerprint, Secure Vault ensures the secure management of cryptographic keys. It also prevents unauthorized firmware from running by verifying that only authenticated code is executed during the boot process. Additionally, Secure Vault offers protection against physical tampering, restricts access to debug ports, and defends against side-channel attacks, such as those targeting power consumption patterns … and much more!

By default, three different security levels are available: Base (SVB), Mid (SVM), and High (SVH), allowing you to choose the right level of protection that best suits your application and device needs. The Lyra (22) series is equipped with Secure Vault "Mid" for robust security, while the 24 series provides maximum protection with Secure Vault "High". For more information and a detailed comparison of these security levels, please visit https://www.silabs.com/security.

NFC (Near Field Communication) allows devices to communicate wirelessly when positioned in close proximity, usually within a few centimetres. One device creates a small magnetic field that powers the other, enabling them to transfer data. This short-range setup is secure, making NFC ideal for tasks like contactless payments, access control, and quick data transfers. Unfortunately, neither the Lyra (22) nor the Lyra 24 series support NFC right out of the box; both are designed as Bluetooth Low Energy 5 (BLE)-only solutions.

The reason for this is primarily because Silicon Labs does not natively support NFC, as they lack built-in NFC hardware. Instead, NFC functionality, when needed, is typically achieved by interfacing with external components. In this case, developers often integrate other NFC modules or chips alongside the EFR32 to enable the desired features. Silicon Labs offers NFC libraries (https://github.com/SiliconLabs/nfc) and examples to help incorporate NFC capabilities, such as with the NXP NT3H2111, for example: https://github.com/SiliconLabs/bluetooth_applications/tree/master/bluetooth_nfc_pairing.

No, only the Normal Mode is available for both the Lyra (22) and Lyra 24 series. The Incremental Analog-to-Digital Converter (IADC) from Silicon Labs is a feature in their EFR32-based microcontrollers that converts analog signals to digital data, offering up to three different sampling modes, depending on the chip version: Normal Mode for balanced performance and typical use, High-Speed Mode for faster sampling rates, useful for quick data collection, and High-Accuracy Mode for precise readings, ideal when accuracy is critical. These three modes are helpful and allow developers to adjust the device’s performance according to their unique application needs.

No, the Backup Real Time Counter (BURTC) is not available in either the Lyra (22) or Lyra 24 series, both in terms of software and hardware. The BURTC is a timer that supports timekeeping across all energy modes, including EM4, with a total current consumption of less than 0.5 μA. It includes a 32-bit counter and can be clocked by a 32.768 kHz crystal oscillator, a 32.768 kHz RC oscillator, or a 2 kHz ultra-low-frequency RC oscillator.

Our Lyra series includes two main versions: Lyra 22 and Lyra 24. Lyra 22 is based on the EFR32BG22 SoC, whereas Lyra 24 uses the EFR32BG24 SoC from Silicon Labs. Both are built and featuring the Wireless Gecko Series 2. This naming scheme helps distinguish between the two series and their parts.

Please keep in mind that Lyra and Lyra 22 are the same and refer to the identical version. There is no difference between Lyra or Lyra 22 (and vice versa). Typically, when we mention or just say Lyra, we mean Lyra 22, unless otherwise specified, as it was the first hardware generation we released.

First Lyra Generation = Lyra aka. Lyra 22: https://www.ezurio.com/lyra-series.
Second Lyra Generation = Lyra 24: https://www.ezurio.com/lyra24-series.

When a GitHub release is created, it automatically zips up any source that is in that repo. However, we do not provide the source code for our firmware, as it is proprietary. We just use the repo to provide our releases which are only available as binaries. This is why the source archives will be empty. 

Ezurio did provide breakout boards for our older BL600(EOL) modules but we do not produce breakout boards for any of our current range of Bluetooth modules as of 2024.

This includes all BL65x, BL53xx, BL54xxx, BTxxx, Vela and Lyra modules.

We do provide development kits for all of our module offerings. To learn more, visit any product page on ezurio.com. 

Before contacting our support team, please follow the below mentioned steps for troubleshooting the connection between your Lyra development board and PC.

Hardware: Inspect the Lyra development board visually for any mechanical or physical damage. Try a different USB port on your PC and use the supplied micro USB cable. Also, verify that the SEGGER J-Link LED (in the bottom-right corner) is active when powered. If you own another DVK or got a spare board somewhere, then please connect it for validation and cross-checks to see if it works or not with the same setup.

Software: In Simplicity Studio 5, go to "Help" -> "Update Software" and apply all available updates if prompted. Check that both Simplicity Studio 5 installation and Silicon Labs Gecko SDK (GSDK) are up to date. Also, try to start Simplicity Studio 5 as an Administrator for testing reasons only. Make sure that your local firewall or antivirus program is not blocking any traffic / access. Install the latest version of the J-Link Software and Documentation Pack manually.

The Silicon Labs Proprietary Flex SDK is a complete software development suite for proprietary wireless applications. Per its namesake, Flex offers two software implementation options and paths:

• RAIL (Radio Abstraction Interface Layer) is an intuitive and easy customizable radio interface layer designed to support both proprietary and standards-based wireless protocols. It simplifies and accelerates the development process. This is the lowest layer available for all networking stacks in the Bluetooth Gecko SDK (GSDK).
• Connect is an IEEE 802.15.4-based networking stack designed for customizable broad-based proprietary wireless networking solutions that require low power consumption and operates in either the sub-GHz or 2.4 GHz frequency bands. This solution is targeted towards simple network topologies.

No. Unfortunately, we do not provide any support for a Remote Command Mode in our own AT Interface application at the moment which would e.g. allow AT commands to be sent, received, and processed over a BLE link (via GATT) – between two Lyra devices – for remote configuration reasons.

Yes. This feature is already on our Lyra (22) and 24 software roadmap. We’ve received many requests from different customers in the past asking us this question. The plan is to make it available in conjunction with both existing VSP (Virtual Serial Port) and non-VSP modes. See also our Lyra (22) and 24 Series – AT Interface Application User Guide for further details. We will provide more information on this topic once the implementation has been fully evaluated and finalized.

Yes, it is possible. You can for example downgrade in Simplicity Studio 5 from the Bluetooth Gecko SDK (GSDK) version 4.4.0 to 4.2.1 at any time. Refer to https://www.silabs.com/developers/gecko-software-development-kit for the latest release notes documents.

First, launch Simplicity Studio 5 and go to the Welcome / Launcher page if necessary. Next make sure that you are logged in with your Silicon Labs account – otherwise please apply and register under https://www.silabs.com. Now open the "Install" window which by default can be located in the upper-left corner of the submenu.

Go to "SDKs" and search for "Gecko SDK - 32-bit and Wireless MCUs". Click on the three dots (...) right next to the current installed version number shown and select "Change Version". Confirm your choice and GSDK release by pressing the "Finish" button. This process may take a few minutes to complete.

Yes, indeed we do. Similar like with other Silicon Labs based devices which you may have worked before already. Currently, all below mentioned RM126x and Lyra (22) + 24 development boards are automatically recognized and added to the “Debug Adapters” list once you connect them to your PC. They are displayed and found on the (Welcome) Launcher page within Simplicity Studio 5 – as usual. Simply speaking: This would be the starting point if you want to develop custom LoRaWAN / BLE applications in C when using our modules.

RM126x Series

• Ezurio RM1261 Development Kit (BRD2900A Rev A00),
• Ezurio RM1262 Development Kit (BRD2901A Rev A00).
  
  

Lyra 24 Series

• Ezurio Lyra 24P 10dBm (Built-in) Ant Development Kit (BRD2902A Rev A00),
• Ezurio Lyra 24P 20dBm (Built-in) Ant Development Kit (BRD2904A Rev A00),
• Ezurio Lyra 24P 20dBm (RF) Pin Development Kit (BRD2903A Rev A00),
• Ezurio Lyra 24S 10dBm Development Kit (BRD2905A Rev A00).
  
  

Lyra (22) Series

• Ezurio Lyra P Development Kit (BRD4330A Rev A00),
• Ezurio Lyra S Development Kit (BRD4331A Rev A00).

Both ATE1 and ATE0 commands are pretty common in the modem world which would turn on and off the echo mode. In this case, any typed character(s) will be displayed to the screen or terminal – otherwise they are completely suppressed. This behaviour can be very useful for debugging or in some applications. However, there is currently no support for any echoing in our own AT Interface app and implementation. We recommend (if possible) to use a terminal application as an alternative such as UwTerminalX. In PuTTY, Tera Term or RealTerm this can be configured and enabled if needed.

Yes. For the Lyra 24P USB Dongle with part number #450-00184 it is required (in the very first instance) to configure the GPIO of LED (SIO1) with the AT+SIOC 1,2,0 command as an output. 

Now you can simply use AT+SIOW 1,1 and AT+SIOW 1,0 to turn on and off the LED. This information can also be found in our Lyra 24P USB Dongle User Guide on page 8, section 5.3: Using the Dongle LED with AT Commands.

The blue LED is mapped to PA08 (Pin 17) internally and not active by default. See the Lyra 24P Datasheet for further details about the pinout.

Yes. User functions are available for both Lyra (22) and 24 series. In this case, please verify and make sure that you run a recent version of our AT Interface app such as >= GA2 for Lyra (22) and >= GA1 for Lyra 24 on your module.

They can be used to trigger a specific behaviour when a module event occurs. For example, you can toggle a GPIO when establishing a BLE connection, remove bonding information on disconnect, change TX power or the BLE device appearance, modify scan and advertising intervals, and a lot more – with less work and logic to be handled by an external MCU.

In the past, initial support for user functions was added to allow customers migrating from Wireless Xpress (and a BGX-based design) to our AT Interface application more easily. User functions can be used in conjunction with the AT+UFU and AT+SIOC commands. Refer to our latest Lyra Series – AT Interface Application User Guide and Lyra Series – Peripheral Interface Application Note for more details and examples. The usage of user functions is optional and disabled (not active) by default.

Please consider the following: Currently, only one AT command can be associated with each user function. Supported are SIO (Signal Input/Output) and BLE connection events as well as the boot event which gets triggered each time after resetting or rebooting the Lyra module. The number of user functions is limited, and not more than 320 bytes of total storage can be reserved for all AT command parameters.

No. It is not possible to use any of our Lyra (22) or 24 development boards for such task(s). This is not supported by the hardware. In this case, please refer to Which out of the box hardware can be used to externally debug and flash Lyra modules via the Serial Wire Debug (SWD) interface in development and production stage? for further information.

In order to debug and program our Lyra (22) and 24 modules externally via the Serial Wire Debug (SWD) interface in development or production stage, we recommend using the Simplicity Link Debugger (BRD1015A) board for example or any SLWSTK* part number which is listed under https://www.silabs.com/development-tools (Starter Kits) that comes with an onboard SEGGER J-Link debugger and debug out functionality.

Of course, it is also possible to use a debug probe from SEGGER directly or any other SEGGER compatible hardware with no vendor lock which does support EFR32BG22* and EFR32BG24* target devices / SoCs. See https://www.segger.com/supported-devices/silicon-labs/blue-gecko for more details and an overview.

Yes. For Lyra, the below command can be used to merge an existing bootloader and application hex file into a single hex image with the help of the Simplicity Commander CLI. See also: What is the „Simplicity Commander“ and where can I get it from?

Syntax: C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\commander\commander.exe convert <BOOTLOADER-IMAGE>.hex <APPLICATION-IMAGE>.hex -o <COMBINED-IMAGE>.hex

Example: C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\commander\commander.exe convert LYRA-P_Bootloader_480-00184-R126.1.0.3.hex LYRA-P_Bluetooth_Xpress.hex -o combined.hex

The Simplicity Commander is a utility that provides a graphical user interface (GUI) and command line interfaces (CLI) to the debug features of an EFR32-based device. We highly recommend using it in conjunction with our Lyra (22) and 24 series. It for example allows you to reprogram the Lyra module, update development board firmware, and lock, or unlock debug access if needed. This tool is part of the Simplicity Studio 5 Software & IDE by default. A portable version for Windows, GNU/Linux and macOS can also be found at https://www.silabs.com/developers/simplicity-studio#commander.

Silicon Labs provides a Wireless Direct Test Mode (DTM) application that can programmed onto a Lyra module that allows for DTM commands to be completed wirelessly from another device such as a mobile phone using EFR Connect Mobile app.

There is an existing page (Implementing Wireless Direct Test Mode (DTM)) in the Silicon Labs Bluetooth Docs that explains operation and provides source to be added to a Simplicity Studio project. However, at the time of the writing of this FAQ the source is based on much older Simplicity Studio 4 and doesn’t build properly with Simplicity Studio 5. An updated Wireless DTM application is available on the following Silicon Labs GIT page and source provided will build using Simplicity Studio 5.

Bluetooth Wireless DTM

An application is created in Simplicity Studio IDE based on Bluetooth_soc_empty application. The existing app.c file is replaced with app.c provided from the src folder in Bluetooth Wireless DTM. GATT table configuration is also made available in the config folder in Bluetooth Wireless DTM.

With the Wireless DTM application loaded and programmed the Lyra module will begin advertising and show as dtm_test. 

Once connected to Lyra dtm_test you can see the GATT Services; DTM Control, DTM RX and DTM TX. Note the services will not be presented as shown below. You will need to determine each service based on UUID which is shown on Bluetooth Wireless DTM but also provided below for demonstration.

Expanding on the DTM Control Service the characteristics for that service can be observed. Each characteristic is written to configure the test as detailed at in Bluetooth Wireless DTM.

Further command and command argument information can be found on the Testing Commands page.

Many thanks for your interest in our products. The Ezurio AT Interface implementation for both Lyra (22) and 24 series is closed source and proprietary, hence, we do not share any source code. This also applies to Wireless Xpress which was developed and released by Silicon Labs.

There are currently no plans to make any source files available to the public nor to open source our software projects on GitHub. For more details or individual requests, please reach out to your local sales representative or FAE at Laird.

Unfortunately, no. You cannot run Wireless Xpress on Lyra 24. There is no software and hardware support for it, and as now (2024) we have no plans to port, develop and/or release a compatible version for this hardware platform.

In you are migrating from a BGX-based device such as the BGX13 or BGX220, please feel free to investigate and review our Lyra (22) Series under https://www.ezurio.com/lyra-series in case you would like to continue using Wireless Xpress in your current design – but with one of our BLE modules as an alternative.

Also, please be advised that the Wireless Xpress software solution from Silicon Labs is frozen at its current release and therefore will not receive any further development or bug fixing in the future.

All Lyra development boards are by default in a floating state and use an "auto" configuration for the virtual COM Port (VCOM); therefore, it is highly recommended to do so whenever possible. In this case, please refer here for instructions and more details on how to set up UART hardware flow control (RTS/CTS) properly with your Lyra hardware for evaluation.

Yes. It is possible to enable and disable UART hardware flow control on your Lyra development board through Simplicity Studio 5 by modifying the Virtual COM Port (VCOM) settings. This for example can be helpful in cases where you would like to perform reference tests with or without having UART hardware flow control in place.

In Simplicity Studio 5 go to the Launcher page in the Debug Adapters view and right click on your Ezurio | Lyra Development Kit (ID:XXXXXXXXX). Select Launch Console and open the Admin tab. Now type "serial vcom config handshake rtscts" to enable or "serial vcom config handshake disable" for disabling UART hardware flow control.

Please make sure to reset or power cycle your Lyra development board once the settings have been applied. The default settings can be restored with the "serial vcom config handshake auto" command at any time.

As per the AT Interface User Guide, the AT+LSCN has four parameters, all of which are optional: timeout, escape pattern, rssi, and scan type, using the following syntax:

AT+LSCN <,scanType>>>>

Therefore, the correct syntax for AT+LSCN without using all optional parameters would be to leave the unused parameters blank (not a "0", just blank) while still dividing each of the optional parameters using commas. For example, if the only parameter required is to configure it the scan type (last parameter) to enable scanning for 1M and Coded PHY (256k) with extended advertisements you would use the following syntax:

AT+LSCN ,,,7

Please see the AT Interface User Guide for the module you are working with for more information.

Lyra Series Modules – AT Interface User Guide

BL65x Series Modules – AT Interface User Guide

Lyra 24 modules do support Wirepas 2.4GHz Mesh. Wirepas added support of the EFR32BG24 BLE MCU in v5.4.0 FW release:

Wirepas Mesh 2.4 GHz Firmware v5.4.0 for EFR32xG24 Release Notes: Wirepas Developer Portal

With the larger 256K RAM size on the EFR32BG24 BLE MCU used on Lyra 24, Wirepas Nodes can be configured for LE Mode and Low Latency Node (Sink/Router Modes).

For more details on Lyra P and Lyra S Wirepas solution refer to the following page:

Wirepas Partnership (ezurio.com)

For information related to the Wirepas Mesh 2.4GHz FW v5.3.0 refer to the following Release Notes:

When making a connection to a mobile device using Lyra VSP service there is a 15 second delay between the "Ring" indication and the "Connect" indication. This issue is not actually a firmware issue and more of a use case issue. In a scenario whereby two LYRAs are connecting the central LYRA will kickstart the process and once a BT connection is established a series of commands will be sent to the peripheral LYRA to ensure the VSP is ready. These things include writing the Modem in & out descriptors to ensure that the devices are in a good state to send data (set to '1') and also to enable notifications on the Modem out and TX characteristics so that the central can view the incoming data. 

In the case where a different non-LYRA device is acting as a central for a VSP connection these extra commands are not automatically sent therefore it is the central devices responsibility to send these commands. 

Writing to the Modem In characteristic is the write that specifically breaks the peripheral LYRA out of the delay state and to output the connect message. This does not necessarily mean that the VSP system is ready the other commands must also be sent for the system to work properly.

If the 15 second delay is not tolerable for an application, then simply writing any value to the MODEM_IN Characteristic will allow the connection handshake to proceed. For example, using nRF Connect to connect to the Lyra DVK running VSP and connected to a UwTerminalX terminal, a simple write of 0xFF results will then show connect.

Lyra modules must be preloaded with AT Interface firmware, while BL65x modules must be updated to the most current smartBASIC firmware version and programmed with the AT Interface smartBASIC sample application in order to use any AT Interface commands.

To configure a static passkey using AT Interface it is necessary to ensure that the I/O capability of the modules will result in Passkey Entry authentication (per the Bluetooth SIG's IO Capabilities mapping). The Lyra or BL65x module must be configured with the I/O Capability set to Keyboard Only (2) or Keyboard + Display (4), via S Register 107, using the command, ATS 107=x, where x=2 for Keyboard Only or x=4 for Keyboard + Display.

Then the "AT+PKEY " command can be used to issue a static passkey to the underlying stack for use during a pairing procedure in future connections. The passkey must be a 6-digit integer in the range of 000000 – 999999.

The pairing will still use LESC Diffie-Hellman based exchanges.  If a randomly generated number is used for the passkey the static passkey will be used.

Note: Pairing using a pre-programmed passkey makes pairing vulnerable to MITM attacks.

For more information on AT Interface configurations please reference the AT Interface User Guide for the specified module series.

User Guide - BL65x AT Interface Application

User Guide - AT Interface Application - Lyra Series

The AT+PKEY nnnnnn command, used by AT Interface to configure a static passkey, is an on-the-fly command and will not be persistent through a power-cycle/reset. Only S Register settings, using the ATS & AT%S commands, can be saved using AT&W followed by ATZ. All other AT commands are on-the-fly.

NOTE: Using a static, pre-programmed, passkey makes pairing vulnerable to MITM attacks.

For additional information on configuring a static passkey with AT Interface please refer to the appropriate AT Interface User Guide for the Ezurio module you are working with linked below:

User Guide - AT Interface Application - Lyra Series

User Guide - AT Interface Application - BL65x 

These instructions are intended for Linux or Macintosh OS. They may work using WSL, Cigwin, or other bash style terminals in Windows although this is untested. 

It may be desired to communicate with a device attached to the USB-SWD without terminal emulation, I.E. Picocom, Screen, Putty.  This can be useful for writing bash scripts, or if you're using Zephyr's "west flash" and would like a quick way to check your output. 

1. Verify you have the program "stty" available using the command "which stty", if this does not return a value you will need to install it.  Fortunately "stty" generally comes standard with Linux and MacOS.  
2. Identify your serial device.  This can be done using the command "dmesg -w" then connecting the USB-SWD.  You will see output like this (In Linux).

3. (Optional) Assign the device name to a variable, for example "DEVICE=/dev/ttyACM0".
4. Configure "stty" to talk with the device "stty -F $DEVICE 115200 -echo -echoe -echok"
5. To see output from the device execute "cat $DEVICE &".  This will send serial communication from the device to Linux's standard output.  The "&" is to run this program in the background.
6. Now press the reset button on the USB-SWD, you should see the output from your device.  In this example the Zephyr "Hello World" example has been flashed to a BT510. 

7. (Optional) if you would like to send commands back to the device you can use "echo" or add an argument to your shell, "foo() { echo -n -e "$1\r" > $DEVICE; }".  Now commands can be issued directly from the command line, for example "foo "my_command"" will send the string "my_command" to the device. 

No, it is optional. However, Laird strongly recommends that developers make use of UART hardware flow control by implementing and connecting both RTS (Request to Send) and CTS (Clear to Send) lines in their Lyra designs – beside the regular RX (Receive) and TX (Transmit) pins.

Hardware flow control (also known as RTS/CTS flow control) is called so because the control is handled by the hardware. It is useful in scenarios where the transmitter is able to send data faster than the receiver is able to process. The RTS and CTS lines are turned off and on from alternate ends to control data flow, for instance when a buffer is almost full. This design approach is an effective way to prevent data loss and helps to guarantee data integrity in your application.

Our AT Interface application and implementation for both Lyra (22) + 24 series are making use of the Silicon Labs Stack. They are based on the following − different − Bluetooth Gecko SDK (GSDK) versions:

• Lyra (22) series with Ezurio's GA release >= 2.2 (https://github.com/LairdCP/Lyra_Firmware/releases) is based on the Silicon Labs GSDK v4.0.2 (https://www.silabs.com/documents/public/release-notes/gecko-platform-release-notes-4.0.2.0.pdf)

• Lyra 24 series with Ezurio's GA release >= 1.1 (https://github.com/LairdCP/Lyra_24_Firmware/releases) is based on the Silicon Labs GSDK v4.2.0 (https://www.silabs.com/documents/public/release-notes/gecko-platform-release-notes-4.2.0.0.pdf)

Please also refer to https://www.silabs.com/developers/gecko-software-development-kit for additional information.