Implementing the Matter Protocol

Using the Arduino Nano Matter or Sparkfun Thing Plus Matter Boards

Following up on his earlier columns on Alexa connectivity, Brian investigates using the Matter protocol with IoT boards from Arduino and Sparkfun.

However, when Arduino announced their Nano Matter development board, it promised to provide compatibility with my Alexa devices using a combination of the Thread and Matter protocols. This seemed to offer a higher level of integration than I had been able to achieve with my projects, which merely emulated some popular commercial devices (i.e. Philips Hue lightbulbs).

The Arduino Nano Matter board achieves Matter compatibility by using an RF-enabled MCU by Silicon Labs: the MGM240S. I use the Arduino IDE regularly and felt that having an Arduino-based Matter library available would simplify the programming process considerably. Before the Nano Matter board was available to customers, Arduino ported Silicon Lab’s Matter library to the Arduino platform. I’m using Arduino IDE version 2.3.4 and downloaded version 1.0 of the board support package (BSP) for the Nano Matter board. I was able to compile several of their example sketches with no errors displayed.

However, when I received my Nano Matter board during Arduino’s Early Adopters promotion, I was unable to get it to work with any of the examples, apart from the lightbulb example (connecting to my Alexa hub). However, a few months later, when BSP version 2.2.0 became available, I downloaded it and suddenly everything started working correctly with my Alexa devices.

In this article, I’m going to outline the features of the Arduino Nano Matter board. I’ll also describe Sparkfun’s Thing Plus Matter board, which is also based upon the same Silicon Labs MCU. Actually, the Sparkfun Thing Plus board became available somewhat earlier than the Arduino Nano Matter board- Sparkfun saw the advantages of the availability of the Arduino Silabs BSP, to target the large Arduino community. Let’s start by looking closely at the Silicon Labs MGM240S RF-enabled MCU that is found on both boards.

The Silicon Labs MGM240S RF-enabled MCU

Generally speaking, older Arduino development boards didn’t contain either WiFi or Bluetooth capability. Some newer models contained a separate RF module, handling one or more of these RF protocols, such as the u-blox NINA-W102. Also, there were a few Arduino boards which contained an ESP32 for WiFi/Bluetooth or a Nordic nRF52840 (Bluetooth only).

The Nano Matter board contains an RF-enabled MCU: the Silicon Labs MGM240S. This device contains an ARM M33 processor as the main MCU, as well as an ARM M0 co-processor acting as the Radio Controller. This MCU handles Bluetooth LE as well as the 802.15.4 protocol, which is the basis for Zigbee, Open Thread and the Matter protocols. In the case of the MGM240S, all these RF protocols operate on the 2.4 GHz band. Note that this MCU does not handle the Wi-Fi communication protocol.

Note that the MGM240S MCU is part of Silicon Labs’ EFR32MG24 wireless SoC family, which is a bit confusing, considering the variation in naming (MG24 vs MGM24). If you are doing any in-depth work with this MCU, you’ll need to download the EFR32XG24 Wireless SoC Reference manual from this URL: https://www.silabs.com/documents/public/reference-manuals/efr32xg24-rm.pdf [1].

The MGM240s has a maximum transmit power of +10dBm, which is 10dBm lower than the typical ESP32 transmit power level for Wi-Fi operations, but comparable to the ESP32’s transmit power for the Bluetooth mode. The MGM240S has a very sensitive RF receiver at -104.5dBm, (@ 250Kbps data rate). I’ll discuss power consumption in more detail later. However, where you would normally expect an ESP32 to draw an average of 50-70mA with lots of sharp, 350mA current spikes during RF operations, my measurements on the Nano Matter board showed a steady 5.7mA current draw when running a Matter sketch (although not using the maximum available Tx power). Similarly, the MGM240S has much lower sleep current in the various sleep modes, than the ESP32. I haven’t been able to get an ESP32 to operate properly below 3V, but the MGM240S is rated down to 1.8V. All in all, the Nano Matter board is a good candidate for battery-operated devices. Like most ARM MCUs, the MGM240S runs on 3.3V and is not 5V-tolerent in terms of either the power supply or the IO lines.

The MGM240S has a very nice complement of I/O functions. It has the usual asynchronous serial ports- a single USART and 2 extended EUSARTs. Even its standard USART can handle SPI, Smartcard (ISO7816), IrDA and I²S. The 2 EUSARTs add DALI (Digital Addressable Lighting Interface) to the list of supported protocols. While you can configure the three (E)USARTs for these specialized protocols, the current Arduino board support package only includes SPI and UART support on these 3 ports.

The MGM240S contains two I²C ports. While I have used the I²C port on the Nano Matter board, I have not tried the setClock() function to see whether it can handle higher bus speeds, like 400kHz and up, but that function is part of the Wire library.

This MCU contains 32 GPIO lines and the Nano Matter board has pinouts for 22 of these lines. The various internal peripheral functions (USART, I²C , Timers, ADC etc.) can be routed to various GPIO lines using the ABUS and DBUS multiplexers. You don’t have to worry about doing this routing yourself, as the Arduino BSP has assigned the various peripherals to default pins. These are shown in the Pinout diagram found in the Nano Matter User Manual, or by referring to Table 1.

Note the pins labelled ADC. The MGM240S has a 12-bit ADC, which is a higher resolution than you would normally expect with MCU-based ADCs. Not only is this ADC a higher resolution, but it is also quite fast at 1Msps. The ADC can be configured for oversampling, which can extend the resolution to 16-bits at a lower rate of 76.9kbps. I doubt that you can do any such re-configuration using the Arduino analogRead() commands- apart from the ability to change the ADC reference from the internal 1.21V band-gap reference, VDD, 0.8VDD or an external 1.25V reference (connected to the AREF pin). The ADC is multiplexed to many of the MGM240S’ GPIO lines, and 8 of these are pinned out on the Nano Matter board. The ADC is preceded by a Programmable Gain Amplifier with gains from 0.5x to 4x, but this feature is not implemented in the Arduino BSP.

As an extra bonus, the MGM240S contains two 12-bit DACs- this is a feature that most MCUs don’t have. The DACs are followed by rail-to-rail buffers and can be combined to produce a single differential output, if desired. While these DACs can be fed by the MCU’s LDMA controller, when using the Arduino BSP, the LDMA controller is not available and the AnalogWrite() command is what is used.

Rounding out the analog peripherals, there are 2 analog comparators, which are not supported by the Arduino BSP. There is also an MCU die temperature sensor which is available using the BSP’s getCPUTemp() function.

Changing the pins for the various peripheral devices from their default assignment can be done by manipulating MCU registers. I didn’t attempt this- the Reference manual is 1100+ pages and there are many hundreds of registers!

The MGM240S’ GPIO lines can be configured as outputs or inputs (with various pullup, pulldown options). There is nothing unusual here except that the GPIO outputs can source or sink 20mA, which is higher than you normally see on ARM MCUs. Those 20mA figures are what is quoted in the Silicon Labs MG240S datasheet. The Arduino documentation for the Nano Matter board quotes 40mA Source and 28mA sink. The Arduino figures may apply to a single GPIO line being driven, while the Silicon Labs’ numbers may be a more conservative, general usage figure.

The MGM240S contains a 16-channel Peripheral Reflex System (PRS). On first glance, you might think that this is the GPIO pin multiplexer function, but it’s not. Instead, it is a way to route various peripheral device inputs/outputs to other peripherals without involving the MCU itself. A routine use of this would be to configure an MGM240S timer to trigger an ADC or DAC at a fixed rate. The Arduino BSP does not currently support the PRS subsystem.

The MGM240S MCU contains many timers, several of which operate in various low power/sleep modes. Not many of these timers are directly available via the library functions contained in the Arduino BSP. However, the standard Arduino millis() and micros() functions are available. Also, if you use the deep sleep mode, you can configure it to wake up via a GPIO pin change or a millisecond timer.

In my projects, I seldom get involved with any security measures that may or may not be present in an MCU. For interest’s sake I’ll mention that the MGM240S contains the following security features:

• Secure Boot with Root of Trust and Secure Loader
• Hardware Cryptographic Acceleration
• True Random Number Generation
• ARM Trustzone®
• Secure Debug interface lock/unlock
• Secure Key management and Anti-Tamper provisions

Uploading Code and Debugging

Getting your code into the MGM240S is different than what you may be accustomed to, if you routinely use other ARM MCUs or the ESP32. The ESP32 contains its own bootloader in ROM and uploads code via its serial port, using a Serial-USB bridge chip. Newer ESP32 MCUs can upload code directly using their onboard USB port. Many ARM chips (RP2040, etc.) come with a UF2 ROM bootloader, which causes the MCU to appear as a flash drive to the host computer, allowing drag/drop programming.

The MGM240S MCU is programmed via its software debugging port (SWD). This would normally mean that you need a programming/debugging device, such as those made by Segger, J-Link etc. to go between the MGM240S and your host PC.

The Nano Matter board contains an Atmel SAM-D11-D14A Arm MCU which has been programmed to perform the following functions:

• Upload your code to the MGM240S via a USB port.
• Perform hardware debugging
• Implement a serial-USB bridge function- useful for software debugging using Serial.println() statements.

Generally speaking, you would need to load a driver for debugging devices like the Segger units, as well as installing a debugging application like OCD. However, when you load the Arduino “Silicon Labs” board support package, this is taken care of for you. If you are not going to be doing any hardware debugging, all that is necessary to upload code to the MGM240S is to press the normal upload icon present in the Arduino IDE. While the uploading is taking place, you will see a status report detailing what is happening, and it’s obvious that the OCD software on the PC is handling the uploading process. Figure 1 shows the status screen after a successful program upload.

The Sparkfun Thing Plus Matter board works in much the same manner but instead of using the SAM-D11 MCU for the debug interface, it has a second Silicon Labs MCU (EFM32GG128416F1) on board. In addition to this debugger MCU, they also needed to add 2 EEPROMs: one for the debugger ID and the other for Serial Flash memory.

While I have had some experience with hardware debugging on other MCUs that I have used in the past, in those cases hardware debug support was built into that MCU’s development IDE. Also, the actual debug hardware was contained on the development board itself, and the IDE would automatically confirm the existence of the debugger as well as identify the specific target MCU.

The original Arduino IDE was never designed for hardware debugging, since the 8-bit Atmel Mega328 AVR MCU didn’t support it. When Arduino expanded its focus to handle 32-bit ARM MCUs, hardware debugging was added to the IDE, but it was never really integrated into the IDE, nor was it easy to use. I haven’t spent enough time investigating debugging with the Nano Matter board to include any details in this article.

If you are using the various MCU hardware peripheral functions supported by the Arduino BSP, you may be interested in the folder location containing the related source code. These are “buried” at the following, rather deep file hierarchy:

Windows C > Users > Username > AppData > Local > Arduino15 > Packages >
SiliconLabs > Hardware > Silabs > 2.2.0 >

Below that level, there are folders for “cores” and “libraries” which contain the source code for various hardware (peripheral) functions and other standard functions such as the Matter routines.

A comparison between the two boards

In terms of implementing the Matter or BLE protocols, the two boards are equally capable, since they both use the same MGM240S MCU. However, each board has its own distinct features. I’ve highlighted some of those differences in Table 2. If compact size is important, the Arduino Nano Matter is clearly the smaller of the two boards. If you are designing a carrier PCB, each of the boards uses a different, but industry-standard, footprint. The Sparkfun board is well-equipped for operation with a LiPo cell, including a JST socket, charger and a dedicated battery fuel gauge chip. Both boards contain 21 or 22 GPIO pins but the Sparkfun board also contains a QWIIC socket and a µSD card socket. I have connected a µSD card to the Nano Matter board, using the default SPI pins shown in Table 1, and it works properly. If you use the Thing Plus Matter’s µSD card socket, it’s also connected to the MGM240S using the default SPI port (MCU pins PC02, PC03, PC06 and PA07). Plugging a µSD card into the Sparkfun Thing Plus Matter board worked fine, using the SD card examples included with this board’s BSP. In both cases, you must properly define which GPIO pin you are using for the SPI -CS line, in your sketch. The 3 GPIO lines driving the Nano Matter board’s RGB LED (PC01, PC02, PC03) are not shared with the GPIO lines that are pinned out to the board’s header connectors.

The Sparkfun Thing Plus Matter board contains a standard 0.05” 10-pin debug connector, labelled Mini Simplicity. This socket is connected directly to the MGM240S SWD and JTAG/trace pins. This allows you to use an external Segger or J-Link debugging tool instead of the on-board debugging circuit, implemented by the EFM32GG128416F1 MCU on the Thing Plus Matter board itself. To do so you would need to cut the link labelled LP on the bottom of the board. This places the EFM32GG128416F1 J-Link debugger in a low power sleep state (which tri-states its debugging pins).

If you are interested in the lowest possible current consumption, in deep-sleep mode, the Nano Matter board accommodates this in the following ways:

• The power LED can be de-activated by cutting a link on the top of the board.
• The SAM-D11 debugger is powered only when the Nano Matter board is powered via the USB port.
• In deep-sleep mode (with debugger and power LED de-activated), I measured the Nano Matter’s current consumption at 1.5µA, with my Joulescope JS220 Energy Analyser. This matches almost exactly the figure quoted in the MGM240S datasheet.

In the case of the Sparkfun Thing Plus Matter board, it’s a bit more involved. You can deactivate the debugger, the Power and Charge LEDs, by cutting links on the bottom of the board. Table 3 shows the current consumptions with various combinations of debugger/LED s disconnected. The first 5 entries were measured running a sketch that tested the µSD card (SD->ReadWrite sketch in Examples for Sparkfun Thing Plus Matter). The last 3 entries were measured while running a Matter sketch, with the last entry in a deep-sleep mode.

From Table 3, and my measurement of 1.5µA deep-sleep current for the Nano Matter board, you can see that the Nano Matter board is much better suited to very low-power operation- assuming that you place the MGM240S in a sleep mode for most of the time.

I should mention that you should be careful when trying out the deep-sleep function. If you write a simple test sketch that puts the MGM240S into deep-sleep at any time soon after the device comes out of reset, you won’t be able to easily re-flash it with a new sketch. I found that the upload process would fail- presumably because the MGM240S has gone into a deep-sleep mode so soon after reset that the debugger chip can’t perform the flash operation. If your intent is to have the MCU come out of reset for just a short time interval, before it goes into deep-sleep, I recommend that you add a bit of code, ahead of the deep-sleep command, allowing you to skip the deep-sleep, if a specific GPIO line has been shorted to ground. Then, you can just insert a jumper when you want to re-flash the MCU for any reason.

The Arduino Nano Matter uses the standard Arduino GPIO pin convention, A0-A8, D0-D13. The Arduino Silicon Labs BSP contains definitions to convert these Arduino pin definitions to the actual MGM240S GPIO pins. However, if you have a sketch that uses the actual MGM240S GPIO pin names, check out Table 1, which shows the relationship between the Arduino pin naming conventions and the MGM240S GPIO pin designations. Also, this table shows the different Peripheral functions and their default pins (for the Nano Matter board).

The Sparkfun Thing Plus Matter board uses a pin naming convention closer to the actual MGM240S GPIO pin designations. That is, the MGM240S GPIO pin PD02 is labelled D2 on the board. However, note that it must be referred to as PD2 (not PD02 or D2) in your sketch.

With the Sparkfun Thing Plus Matter board, I initially found that it looked like I could easily upload sketches, but they didn’t work- at least in so far as they did not send out any startup message to the Serial port. Even the simple “ASCII table” example, which tests the Serial port, showed no response from the Serial port. At this point, I had not yet selected a programmer, but the status screen appeared to show that the uploads had succeeded. For no particular reason, I next decided to select Burn Bootloader from the Tools menu: this immediately prompted me to select a programmer. Once I selected the OCD programmer, the bootloader was installed properly. After this, any sketches I uploaded worked properly. I assume that the bootloader is not pre-installed by Sparkfun, and that it contains code needed to operate the Serial port, but this is just a guess on my part.

An issue I ran into with the Arduino Silicon Labs BSP concerned the SPI port library. The Sparkfun board has a µSD card socket on it. I tested it using the Arduino Silicon Labs BSP SD card example programs and it worked fine. I later added a DF Robot DFR0995 SPI-based TFT display, which worked OK (using Adafruit’s driver). However, when I later added the Matter protocol to my sketch, the TFT display stopped working. When I examined the SPI port signals on the ‘scope, I found that the SPI port was operating at 40MHz. At this high clock rate, the SCLK signal was terrible- as shown in Figure 2. This screen capture was taken while the DFR-0995 display was working, but you can see that the first clock pulse is so low in amplitude that it’s surprising that the display accepts it. When the µSD card was inserted, this clock signal degraded just a bit more, but the TFT display still worked. For some strange reason, adding the Matter protocol to the sketch also degraded the SCLK signal a bit, but not enough to stop the display from working. However, the combination of the Matter protocol plus having the µSD card installed, was enough to kill the DFR-0995 display.

It traced this problem to the “Adafruit_ST7789” library. This library configures the SPI port with a default clock rate of 32 MHz. However, when running on an MGM240S MCU, this results in an actual SPI clock rate of ½ the system clock speed or about 39MHz. While the display worked at this clock rate initially, it was not reliable. Over time, the display would display lots of random characters and even switch background colors. In the “Adafruit_ST77xx.cpp” file, on line 38, I made the following change:

#define SPI_DEFAULT_FREQ 8000000 ///< Default SPI data clock frequency

The MGM240S MCU is able to generate this frequency exactly, and the much slower SPI clock rate eliminated all the display problems I had experienced before The input voltage range on the Nano Matter board is 4V- 22V, using a MC2322 switching regulator. The Sparkfun Thing Plus Matter board has a conventional LDO (XC6222B331) which has a much smaller maximum input voltage- 6V.

Building your first Matter Device

A bought my Arduino Nano Matter board during Arduino’s Early Adopter promotion. At the time, Arduino’s on-line documentation for the board was quite detailed, having separate sections describing how to connect the board to Google Home, Amazon Alexa devices, etc. This process is called commissioning. When this Early Adopter promotion ended, this detailed on-line documentation disappeared and was replaced with different content and tutorials, which cover only Google Home connectivity. This is unfortunate- had I only discovered the Nano Matter board after the Early Adopter promotion had ended, I would not have had access to the more detailed documentation, covering the Alexa hub which I have. I doubt I would have bought the Nano Matter board without having seen this earlier documentation.

What I describe in this section was tested using the Alexa smart home hub that I have in my home. The Early Adopter documentation stated that only certain Alexa devices would work- those that contained a Matter + Thread border router. I have an older model Echo device (4th Gen). This is the more expensive version of the Echo smart speaker lineup. I bought it for its superior sound performance, but also because it contains the Matter + Thread border router. Check with Amazon to see if your Alexa device has Matter + Thread capability.

Having mentioned Arduino’s warning about Matter + Thread border router capability, I should add that when you commission the Nano Matter board using your Alexa device, you end up adding 2 devices: a Thread hub plus whatever Matter device you have programmed the Nano Matter board to emulate. I’m no expert on the Matter/Thread protocols, and I guess you need both a Thread border router and a separate Thread hub, which I found to be somewhat confusing.

When you load Arduino’s Silicon Labs BSP, it will also install many example sketches. These cover some basic functions that you might do with any non RF-enabled board, but also include numerous examples of various Matter devices, as shown in Table 4. The entries with a ü are ones that I have tested out personally. Let’s go through the commissioning process step by step.

Matter Commissioning

Before loading any examples, select your specific board and go to Tools, Protocol Stack and select “Matter”. After loading one of the Matter examples, and running it, you will see a message on your Serial Terminal stating that the Nano Matter board is not yet commissioned. It will print out an 11-digit manual pairing number- which will be 34970112332. It will also display a URL which points to a QR code which can be used instead of the manual pairing code (see Figure 3). The QR code would be the easiest method, assuming you are using the Alexa app on your cellphone.

Using the Alexa app, go to Devices and click on the “+” icon at the top right side of the screen. Then select “Add device”. You then pick the device that best describes the example you have programmed into the Nano Matter board. Note that you will be giving the device a custom name later on, so the device type that you select here does not have to be a perfect match but should match in terms of whether it is a sensor (input) or a controller (output).

Once you’ve chosen the device, you’ll be presented with a list of commercial brand names, but scroll through them until you see “other” and pick that. Then select the option labelled “Matter”. You’ll be asked if your device has a Matter logo, to which you will select “Yes”. Also answer Yes when asked if the device is on. Next, either select “Scan QR code” which will launch your phone/tablet’s camera app or select “Try numeric code instead” and type in the manual pairing code. The Alexa app will display “looking for your device” and should shortly display “This device isn’t Matter certified”. This message is legit- the Nano Matter board isn’t certified for any device other than the lightbulb example. However, you must select Yes, to proceed. The app will display “connecting to your device”. As this process is happening, your Arduino Serial Terminal should display:

Waiting for Thread network…
Connected to Thread network
Waiting for Matter device discovery…
Matter device is now online

The Alexa app will display “Silicon Labs Hub and 1 component device found and connected. Pressing Next will advance to the settings page for both of those devices. The Hub will be labelled “First device” or “Second”, etc. for subsequent boards (or other device examples that you try). Select this entry, press Next, and give this device the name “Nano Hub” or “Sparkfun hub”- whatever is meaningful to you. Then select the next entry which has been labelled “First motion sensor”- assuming you had selected a motion sensor device, earlier in the procedure. You can re-name that as you see fit.

At this point you can assign the device to a room and/or set up a routine for it- this is no different than what you would do with a commercial smart home module.

There are a few things I’d like to point out at this stage. I started out with a single Arduino Nano Matter board. When I navigated to the URL that provides the QR code, it states “This QR code is unique for your device”. Knowing that the MGM240S MCU contains a unique ID number stored in its ROM, I assumed that both the manual pairing code and the QR code, were generated using this ID # in some way, and were indeed unique to the Nano Matter board that I was using. That is not the case: when I later got the Sparkfun Thing Plus Matter board, and followed the same procedure, it also gave the same manual pairing and QR codes. From this, I assume that both the pairing code and the QR code are something like the VID number of a USB device. It just represents that the product comes from a specific vendor and doesn’t differentiate it any more than that.

I assume that the 34970112332 manual pairing code and associated QR code, have been assigned to either Silicon Labs or Arduino in terms of the Matter protocol. In other words, you can’t commission your board using Alexa with just any 11-digit pairing code that you randomly choose.

After you have commissioned your Nano Matter board with Alexa, the Matter authentication information, supplied by the Alexa hub, is stored in the MGM240S’ flash memory. Exactly where in flash is not documented, but it does not get erased when you upload either a modified version of your sketch or a completely new sketch, to the MGM240S.

What if you decide to try out/upload a different Matter example sketch to your Nano board? The first thing you will notice is that the Serial terminal will no longer display the message:

Matter device is not commissioned
Commission it to your Matter hub with the manual pairing code or QR code
Manual pairing code: 34970112332

The reason for this is that the sketch first checks flash memory for authentication information. However, this time it will find it. Therefore, it won’t enter the routine in which it attempts to connect with the Alexa app and identifies itself as a new Matter device. Therefore, when you try to “add a new device”, using the Alexa app, it will fail to find anything new. I also found that making even minor changes to a Matter-enabled sketch (not changing the device’s Matter definition in any way) also required that the de-commissioning process be performed. Otherwise, my Alexa device wouldn’t re-discover the presence of the device. The process described above is handled in the sketch by the following function Matter.isDeviceCommissioned().

The de-commissioning documentation, that was available during the Arduino Nano Matter Early Adopter promotion, has disappeared. I don’t see that information in the current Arduino documentation anywhere. However, if you wish to re-purpose your Nano Matter board to be a different sort of Matter device, you must first de-commission it, as mentioned above. There are 2 ways to do this:

• Load the example sketch “matter_decommission”, which can be found among the other Matter examples supplied with the Arduino Silicon Labs BSP.
• In the Arduino IDE Tools menu, select the “Burn bootloader” option (the easiest way).

As well as this de-commissioning, if you re-program your Nano Matter to be a new device, you should check in the Alexa app to see if it still shows the original Nano Matter device that you added. If so, you should delete the original hub entry, which should also remove the original device as well. I note that the Alexa app doesn’t always refresh discovered devices immediately- existing devices can take a while to show up and can disappear at times.

BLE Connectivity

The MGM240S MCU also contains BLE functionality. This is used during the Matter commissioning procedure, to allow a new device to advertise itself to the Matter host. When you specify the Matter protocol stack, it includes enough BLE functionality to allow this commissioning to work.

However, if you intend to run a sketch that includes standard BLE functions, you must specify the BLE stack in place of the Matter stack. From this I assume that you cannot have both Matter and BLE connectivity in any given Arduino sketch. I have not worked with Silicon Labs’ development IDE: Simplicity Studio, at least in terms of MGM240S program development. Possibly, the Silicon Labs board support libraries can run both protocols in the same program (not necessarily at the same time).

The Arduino Silicon Labs BSP contains two BLE stacks- a Silicon Labs BLE stack and an Arduino BLE stack. The Arduino EZ-BLE examples require the Arduino BLE stack. For the Silicon Labs stack, there are some BLE examples under the heading “Silicon Labs” in the Examples section. While both BLE stacks perform much the same operations, the way the functions are written differ between the two stacks.

My only experience with BLE involves the NUS profile. This is the Nordic Uart Service: basically, a wireless bidirectional UART link, between a BLE client and BLE server. I use this to communicate between an RF-enabled MCU and an Android cellphone/tablet. I make use of the Android GUI-O app on the cellphone to implement a dashboard on the cellphone which is controlled by the external MCU. In the past, I’ve used ESP32 MCUs for this purpose. I wrote a simple GUI-O application example which I ported over to the Arduino Nano Matter/MGM240S MCU. The link to that is: https://www.gui-o.com/examples/gui-o-and-boards [2].

The MGM240S MCU is capable of transmitting BLE packets at a transmit power of 10 dBm, which is comparable to the ESP32S3’s maximum BLE Tx power of 9dBm. At this power level, the MGM240S draws 23.4mA, according to the datasheet. When I did current consumption measurements while running a BLE sketch, I measured a current draw of around 5.7mA which corresponds to a transmit power of 0dBm. This is the default Tx power setting, and I was unable to find a function to change this.

My First Matter-enabled Project

There are many commercial IoT products that work with Alexa, Google Home, etc. I wanted to do something more esoteric with either the Nano Matter or Sparkfun Thing Plus Matter boards. If you check out my earlier column in Circuit Cellar issue 412, you’ll see that I built an IR-Blaster to turn my Fujitsu heat pump on/off, using Alexa commands.

For this column, I decided to design a different IR-Blaster. This time, it would be a universal IR-blaster: i.e. it would be able to “learn” IR codes from many different IR remotes (i.e. those that use carrier frequencies different than the 32KHz that the Fujitsu uses). Also, it would connect to the Alexa hub using the Matter protocol and not just emulate an IoT controlled power outlet, like the project described in issue 412. Lastly, it would be able to control more than device, if necessary.

I won’t discuss the project’s software in terms of the Matter connectivity, as I’ve covered that already. I’ll just mention that I tailored the software around the Arduino example program “Matter lightbulb-multiple”. Specifically, I define 2 “lightbulbs” in the program and include code to receive Matter messages for each of these two devices. There are only 2 commands per device: on and off. Therefore, there can be 4 discrete commands arriving, and each of these is associated with a specific IR code. When a command is received over the Matter protocol, the appropriate IR code is sent- using the IR LED contained in the project. For the following discussion, please refer to Figure 4, the device’s schematic diagram.

The project’s sketch includes an IR “learning” function. This mode is entered when switch SW1 is held down as the device is being powered up. I use a TSMP98000 IR receiver module. Unlike most IR receiver modules, this unit does not contain a bandpass filter, tuned to a specific IR carrier frequency. It is designed specifically for the learning function used in IR blasters and universal remotes. That is, it will respond to any IR remote which uses a carrier frequency in the 25-60KHz region. Because it does not contain bandpass filtering, it’s more susceptible to interference, etc. Therefore, for learning purposes, you should place the IR remote that you are emulating, no further than a foot away from the TSMP98000 receiver module.

I have built projects which perform IR learning in the past using ESP32 MCUs. ESP32s have a dedicated IR remote function block (RMT) which handles the IR signal timing completely in hardware. The MGM240S does not contain anything like this RMT function block. However, I was able to handle the IR learning function, as well as IR code transmission, using only software and the micros() function.

The ESP32 contains two discrete processors: one to handle the RF functions and the other for the user’s program. This is handy, as it means that the user program has 100% control of the execution time on its dedicated processor. Any randomly timed RF packets coming in are handled in real-time, by the second processor present in the ESP32.

The MGM240S MCU contains a separate Arm Cortex M0 MCU for its RF section. However, I noticed that when Matter commands were being received at the same time as an IR packet was being transmitted, the transmission of the IR packet was sometimes interrupted. Therefore, in my sketch, I delay the sending of the IR packet a few seconds after the Matter command has arrived. I also measure the time that it takes for the IR packet to be transmitted, and if it doesn’t match the IR packet timing (measured during the learning process), I repeat the process until the timing does match. This guarantees that a valid IR packet has been transmitted.

The MGM240S MCU doesn’t contain a RMT block to handle the IR carrier generation for transmission like the ESP32 does. However, I used the Arduino “tone” function to generate the carrier frequency. I verified that the MGM240S MCU, using the “tone” command, can generate carriers up to 60KHz, quite accurately. Referring to Figure 4, you can see diodes D2, D3 connected to port pins D2 and D1. The “tone” command outputs its square wave on the D2 pin and the carrier on/off gating comes from the D3 pin. The diodes act as an AND gate, in this configuration. The gated carrier signal drives a 2N3904 transistor, which in turn powers the IR LED. The IR LED is powered by the 5V supply, but the remaining circuitry is powered by 3.3V supplied by the LDO present on the Sparkfun Thing Plus Matter board.

Initially, I planned to store the IR codes in a µSD card, so I built the project using the Sparkfun Thing Plus Matter board, since it contained a µSD card socket. However, as I mentioned earlier, I was unable to get the DFR-0995 TFT display working when both the Matter protocol was loaded, and a µSD card was installed. That led me to pivot and investigate the EEPROM function. In other MCUs that I use, including the MGM240S, there is no actual EEPROM memory block present in the device. Instead, the MCU’s flash memory is used to emulate EEPROM. It turns out that the MGM240S contains 10240 bytes of EEPROM memory. This is sufficient to store about 10 IR codes- more than needed for this project. Note however that the EEPROM function only works if you have the Matter protocol loaded with your sketch. This fooled me at first, and I cannot explain why this is the case. I also noticed that saving a 1kbyte EEPROM block took over 10 seconds, which is rather slow. It’s not important in this application, but it might be meaningful in other applications.

In hindsight, had I known I was going to end up using the EEPROM storage and not the µSD card, I would have used the Arduino Nano Matter board for this project- saving the Sparkfun Thing Plus Matter board for a project that would have made use of the µSD card and/or the on-board LiPo charger.

Note that while this emulated EEPROM is not erased when a sketch is modified and re-loaded, it is erased when the Arduino IDE’s “burn bootloader” command is run. Therefore, if you have to de-commission the device (to allow it to be re-discovered by Alexa), and you do so by burning the bootloader, the saved IR codes will be erased and will need to be re-learned.

• The functions performed by SW1 are as follows:
• Enter “learning” mode, when pressed at power-up
• Answer “yes” to the “save IR code” question (during the “learning” process)
• Send the 1st stored IR code (during normal operation)
• The functions performed by SW2 are:
• Answer “no” to the “save IR code” question (during the “learning” process)
• Send the 2nd stored IR code (during normal operation)

In normal (non-learning) operation, the device will first attempt to join the Thread network. Assuming it can connect to the Alexa device, it will indicate on the TFT display that it has connected to the thread network- this takes only a few seconds generally. After that, it might take a little while before Alexa “discovers” that the device is online and acknowledges this. At this point the TFT display will indicate that the device is online with the Matter network.

Any subsequent commands coming in will be parsed and the applicable IR code sent out. The command number (0-3 in my existing sketch) will be displayed on the TFT display. The first 2 IR codes can also be sent out using the SW1, SW2 pushbuttons.

The Arduino Matter library was ported from the Silicon Labs library. It provides only a high-level access to the Matter protocol. For example, the matter_lightbulb library contains the following routines:

• set_onoff()
• get_onoff
• toggle()
• set_startup_onoff()

In the Nano Matter example programs, the get_onoff() routine is called periodically in the loop() function. It merely returns a true/false value which reflects the last valid Matter message it received. The reception of the Matter messages is done entirely as a background process: your MGM240S sketch has no way of knowing when such a message arrived. The Alexa hub, on the other hand, will receive an acknowledgement from your project’s MGM240S that the message has been received. With that, it can also maintain the on/off status of the device being controlled by the MGM240S.

This system works fine unless your IR-controlled device is also being turned on/off using its own IR remote. In this scenario, neither the MGM240S in your project, nor the Alexa hub can keep track of the device’s on/off status. In this case, the solution is as follows:

• If you are using the Alexa app and notice that its display of the status of the device is different than what you know to be the case, then press the on/off icon twice, to bring Alexa in sync with the device.
• If you are using a voice command, then just tell Alexa to do the opposite of what you want and then repeat the desired command.

The source code for this project can be found on Circuit Cellar’s web-site in the article support section.

Figure 5 is a photo of the project. Five-volt power for the unit is supplied by an external wall adapter.

Conclusions

When I received my Arduino Nano Matter board, as part of the Early Adopters promotion, I was unable to get it to work as anything but a Matter lightbulb. None of the other numerous examples worked, at least on my Alexa hub- so I put the board back on the shelf, where it collected dust for several months.

Luckily, the Arduino IDE presents a pop-up screen indicating when new versions of the various BSPs are available. The 2.2.0 version of the Silicon Labs BSP finally worked with my Alexa hub- I tested most of the example devices and they all worked. Table 4 shows the various example devices showing the ones which I tested out.

At this point, I can recommend you give either of the boards mentioned in this column a try, if you are interested in designing a Matter-enabled device and are familiar with the Arduino IDE. The Arduino-ported BSP and Matter library are much less complicated than the original Silicon Labs BSP and its Matter library. Also, it’s strictly a personal bias, but I found the Silicon Labs Simplicity Studio IDE hard to understand/use when I first encountered it a few years ago. 

REFERENCES
[1] EFR32XG24 Wireless SoC Reference manual: https://www.silabs.com/documents/public/reference-manuals/efr32xg24-rm.pdf[2] A simple GUI-O application example which I ported over to the Arduino Nano Matter/MGM240S MCU: https://www.gui-o.com/examples/gui-o-and-boards

RESOURCES
Arduino | www.arduino.cc
Sparkfun | www.sparkfun.com

Code and Supporting Files

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • MAY 2025 #418 – Get a PDF of the issue

Sponsor this Article