This is an account of a first look at the XIAO ESP32C6, the eighth and latest member of the XIAO family of tiny development boards from Seeed Studio. I had been looking forward to using the board's Zigbee capabilities in a practical project probably in conjunction with the low current drain of the board when the microcontroller is in deep sleep. However, it must be reported that at this point I have not been able to attain my goals with respect to Zigbee. But there's every reason to believe that it will be possible in the not too distant future. The situation is very fluid as Espressif is rapidly issuing new releases of the ESP-IDF (11 since the beginning of the year) and there have been 3 versions of the ESP32 Arduino core released since the first version of this post.

It is all fun and exciting and for that reason, this remains a work in progress... There may be more to come, even if its only corrections.

Table of Content

1. Disclosure
2. Arduino IDE Only... For Now
3. First Connection
4. A Big Brother to the XIAO ESP32C3
5. Pin Numbers and Names
6. Blinky, Blinky
7. Internal vs External Antenna
8. The Wi-Fi Blackhole - An Unexpected Quirk
9. Connection Time vs Transmit Power
10. Web Controlled LED
11. Bluetooth Controlled LED
12. Oh... the Zigbee
13. Deep Sleep
14. Resources

Disclosure

Clearly Seeed Studio does not count on me to promote their products to millions or thousands of potential buyers. For one thing this site and its associated GitHub account have a limited readership. Secondly, the friendly staff at Seeed sent an email saying they would be sending some samples almost at the same time the XIAO ESP32C6 was released to the public. I am most grateful for this gesture from Seeed which wasn't necessary by any means. I would have purchased some boards even if they hadn't reached out to me once again. If it's not clear, I really like the XIAO series, and even before the gift boards arrived, I purchased more ESP32C6s. Now I have six boards and can afford to fry one or two while performing stupid experiments with them.

Actually, no XIAO has ever been harmed in this household. They have all survived so far.

Just to dot the i's and cross the t's, Seeed Studio supplied boards free of charge but otherwise did not provide any other payment. Furthermore, Seeed did not request that I write this post, or anything else for that matter, and it does not have any editorial control.

Arduino IDE Only... For Now

The current platform-espressif32 (version 6.7.0 dated May 14, 2024) for Espressif 32 bit devices use in PlatformIO (PIO) is based on the rather old ESP32 Arduino core version 2.0.16. Consequently it does not support the XIAO ESP32C6. Indeed, PIO will not support the ESP32-C6 until such time as it moves to version 3.0 (or better) of the ESP32 Arduino core. See the last comment in the Add board support for Seeed XIAO ESP32C6 issue in the platform-espressif32 repository that confirms this situation. For that reason, I have used the latest version (2.3.2) of the Arduino IDE to write sketches to investigate the new XIAO. There is no real doubt that, some time in the future, PIO will move on to the new ESP32 Arduino core and will support the ESP32-C6 and the XIAO ESP32C6 explicitly. In preparation for that situation, the example sketches are set up in a way that will make it easier to add PIO compatibility. In the meantime, all sketches presented in this post will compile in the Arduino IDE provide the following configuration is done.

1. Add https://espressif.github.io/arduino-esp32/package_esp32_index.json in the Additional Boards Manager URLS in the Preferences window in the IDE.
2. Install platform esp32 by Espressif version 3.0.2 or newer with the Boards Manager. Hopefully, version 3.0.3 released on July 17 did not introduce incompatibilities.
3. Select the XIAO_ESP32C6 board

The Arduino IDE does have some annoying quirks. The Copy-paste data from the serial monitor problem has been around for some time. Typically I use the venerable cu terminal program to work with serial ports, but picocom is a better to grab the serial output. Here is the command line for anyone wishing to do the same.

Of course, it could be necessary to adjust the device name (or COM port in Windows). The mapping from lf (linefeed) to crlf (carriage return, linefeed) is necessary otherwise, new lines will not start in the first column. Be careful, picocom will not work if the serial monitor of the Arduino IDE has control of the serial port connected to the XIAO.

First Connection

When a XIAO is connected to a USB port on a Windows machine, the distinctive billy boop sound should be heard as the device is recognized by the operating system. The board will then be assigned a COM port such as COM6.

In Linux one can listen to bus messages as the operating system recognizes the device. Start the dmesg command line utility with the -w flag and then plug in the XIAO ESP32C6.

Use the CtrlC keyboard combination to close that application. One could instead hunt for the device once it is plugged in.

More information can be obtained with the sudo lsusb -v -d 303a:1001. Much of it is not that useful for me, but it does display the serial number which I believe is the MAC address of the device.

That unique identifier could be very useful when trying to set up udev rules for specific devices that are connected to a USB port.

The XIAO arrived with preloaded firmware, so when it was connected to a desktop computer with a USB cable, its red LED turned on and its yellow LED flashed at least for a while. The following messages were sent to the serial port.

Clearly, the device is performing some wireless radio tests, first with the onboard antenna, with success, and then with the external antenna which failed without surprise since none was connected. I gingerly connected a PCB antenna to this new board and looked at the serial output again. Be careful when doing this, the U.FL coaxial connector is delicate and will probably not survive very many connections (the female connector on the antenna is rated for only 30 reconnections, see Hirose U.FL).

This time, the WiFi tests with the onboard and external antennas passed, and a Bluetooth test failed. The board did not seem to advertise itself as a Bluetooth device, so I had no idea what could be done at this point to see if the BLE test could be made to succeed. In any case, it does not matter because the test firmware will soon be replaced. In the meantime, we have confirmation that the XIAO is alive.

Let's conclude this section with two remarks.

• The USB device ID is the same as that of the XIAO ESP32C3 and it does not correspond to the information in the variant pins_arduino.h file. Don't know what to make of that.
• The baud setting when establishing a serial connection over USB is meaningless. It can be 115200, 9600 or 500000 or probably anything else when connecting to the board with a serial terminal program. Just like other XIAO devices, the USB data lines are connected directly to the microcontroller which has a built-in USB serial controller with a CDC-ACM virtual serial port which is USB 2.0 compliant and capable of 12 Mbits/s transfer speeds (Source ESP32c6 Series Datasheet, Version 1.2 pp 49).

A Big Brother to the XIAO ESP32C3

Being a member of the XIAO family, the ESP32C6 conforms to the XIAO 18x22 mm form factor shown on the right. There are 14 pads along the edges of the board, three of which are dedicated to power and ground connections and the remaining 11 are general-purpose input/output (I/O) pins. Four of these pins have no predefined functions, while the remaining seven are used to provide three serial peripherals: UART, I²C and SPI.

The ESP32-C6 microcontroller is the bigger sibling of the ESP32-C3, so I expected that the XIAO ESP32C6 would be very similar to the XIAO ESP32C3. That is not quite the case. Looking at the basic pin allocation of the two boards one can see differences. For one thing, the XIAO ESP32C6 has one less analog input pin which explains why A3 is not defined. Otherwise all symbolic names of the pins are the same, which, of course, corresponds to the XIAO form factor. However, the I/O pin assigned to each peripheral is totally different.

Three other I/O pads are of interest to the user.

• I/O pad 3 which enables power to the antenna RF switch.
• I/O pad 14 which select the on-board or external antenna via the RF switch control line.
• I/O pad 15 which is connected to the yellow on-board LED.

The I/O pins on the underside of the XIAO do not have Arduino names even if the XIAO ESP32C6 Pin List appears to assign such names to three of them.

There are significant differences between the boards that are not visible when just looking at the common configuration of all XIAO boards. The ESP32-C6 has a second core which is RISC-V just as the main core. However, it would be a mistake to think of the ESP32-C6 as a dual-core microcontroller in the same vein as the "classic" ESP32 and the Raspberry Pi RP-2040. The ESP32-C6 cores are very asymmetric with the main core running at 160 MHz and the second core running at a much slower 20 MHz. The second core called the ULP (presumably standing for ultra-low power) plays an important role in the nominal 15 µA current drain in deep sleep mode, where the single RISC-V core ESC32-C3 can only go down to 44 µA.

The asymmetry between the two RISC-V cores of the ESP32-C6 is not limited to their frequency. As I understand it, the ULP has access to only I/O pins 0 to 7 of the ESP32-C6. On the XIAO ESP32C6, this means that 7 of the 8 ULP I/O pins are available.

Again, these symbolic names for the ULP pin and peripheral were taken from the XIAO ESP32C6 Pin List in the Seeed Studio getting started guide, but as far as I can make out, these are not defined in any files in the ESP32 Arduino core. For me at least, this does not matter very much because there is no easy way to write code for the ULP. One either has to write assembly code for the core (example: SmoothBlink_ULP_Code.ino) or use the ESP-IDF. This may change in the future; see Add support for Low Power core of the ESP32C6.

Pin Numbers and Names

This first sketch prints out the values defined in the variant pin definition file pins_arduino.h of the Arduino Espressif32 package found in the following directory: ~/.arduino15/packages/esp32/hardware/esp32/3.0.1/variants/XIAO_ESP32C6/. The source is sufficiently boring to not be printed here, but it can be found in the associated GitHub repository. Here is the serial output from the sketch.

The Antenna I/O pin consts were added in version 3.0.4 of the ESP32 core (see pull request 10066 Enabled the onboard ceramic antenna by default when creating a new project with XIAO_ESP32C6) released on August 2, 2024. If the sketch is compiled in an older core, then the output will be different.

Some definitions and omissions are somewhat perplexing. The pin definition header file does not contain symbolic names for the pins on the back side of the board. One could have expected to find the following definitions in pins_arduino.h.

Because these missing definitions can always be added when needed that omission is not very important. Also I do not know the purpose of the empty USB_SERIAL string macro but it's probably harmless enough. The USB_VID:USB_PID values do not match the USB ID of the boards I have tested so far which was 303A:1001.

Prior to the 3.0.2 version of the core, the ARDUINO_XIAO_ESP32C6 macro was not defined properly (see Issue 9929 where, amazingly I managed to repeat the error while supposedly pointing it out. Thanks to SuGlider for correcting the correction in the commit).

Blinky, Blinky

it's time to run a blink sketch, the microcontroller equivalent of the "Hello world!" program. The Seeed Studio Wiki already contains a blink sketch in Getting Started with Seeed Studio XIAO ESP32c6, but I have modified it slightly do that it blinks, it pulses and it responds to button presses. Let's start with the blink. First the I/O pin has to be defined and its mode needs to be set in the setup function.

A static variable, ledPin, is used in the sketch instead of the predefined LED_BUILTIN variable. That way, the sketch could easily be adapted should we want to attach a LED to any one of the I/O pins on the XIAO. I know that the yellow LED will be turned on when I/O pin 15 is brought low because of the way the LED is connected as shown at the end of the XIAO ESP32C6 schematic. The asymmetric on and off times when the LED is blinking will confirm this. Here is the bit of code that takes care of blinking the LED.

To understand this, remember that this routine is repeatedly called from the main loop() function. The LED is blinked in a heartbeat fashion: two short ON periods separated by a longer OFF period. The beatcount variable is used as a state variable. When beatcount is equal to 0 the LED is turned on for the first short on period. When beatcount is 1 the LED is turned off for a short time. When beatcount is 2 the LED is turned off for the second short period and finally when beatcount is 3 the LED is turned off for a long period. Short and long periods are defined with the ON_TIME and OFF_TIME macros and the variable beattime is used to store the time obtained from the millis() function whenever a period has elapsed at which point the value of beatcount is incremented. Finally, when beatcount is about to be set to 4, it is reset to 0 to continue the cycle indefinitely.

Well that's easy enough, so I had to complicate things and use the PWM (pulse width modulation) capabilities of the chip to make the LED repeatedly ramp up in intensity until it reaches a maximum and then decrease in intensity until off. It's a visually pleasing pulsating effect if the parameters have appropriate values.

When an I/O pin is outputting a PWM signal what it is actually doing is sending a square wave. In other words, the current flow through the pin is repeatedly turned on and off at a usually fairly high frequency so that, if an LED is connected to the signal, the eye cannot discern the on and off periods. Because of the persistence of vision, the visual effect is that the LED seems more or less bright depending on the proportion of on time to the total on and off time. That proportion is called the duty cycle. Instead of a percentage, the duty cycle is set by a value between 0 (no on time) to 255 (no off time). So a duty cycle of 85 corresponds to a 33% duty cycle; the LED is on only a third of the time and will not be very bright. In the above code, the DELTA macro sets by how much the duty cycle will be increased or decreased in each step, while DELAY is the time (ms) spent in each step. The variable fade is used to store the current duty cycle. The value of the variable delta will be added to fade at each step. To get the ramping up or down effect, the variable delta will be either equal to DELTA or equal to -DELTA. Again, pulse will be called repeatedly by the loop(). It uses the delaytime to calculate if DELAY milliseconds have elapsed. When that's the case, it moves on the next step. And that as simple as adding delta to fade and then testing if the maximum has been reached or the minimum value has been reached and changing the sign of delta at those points. The Arduino function analogWrite() takes care of setting up all the timers needed to create a PWM output.

In a previous incarnation of this sketch, the loop() alternated between calling heartbeat() or pulse() for 10 seconds. This time around, I set the period to 20 seconds and added the possibility to switch from one to the other with a button press. The boot button is used for that purpose even if it’s rather tiny and fiddly to use. The transition between blinking and pulsing is a bit fancier as the switchAction() function that takes care of switching between patterns, actually turns the LED off and resets the pattern about to be started to its initial state in the process. It also outputs a message to the console stating why the pattern changed. When writing this function, I got bitten by a little gotcha even though it was solved in the older version. Once an I/O pin has been put into PWM mode with a analogWrite() function, it remains in that mode even when after a digitalWrite(). To return the pin to digital read/write mode a call to pinMode(ledPin, OUTPUT) is required.

In the setup() function the I/O pin is set in INPUT mode. I checked the schematic and verified that the pinned is pulled high by a 10K ohms resistor so that there was no need to enable an internal pull up resistor. It was not really necessary to check the schematic, I/O pin 9 is part of the so-called strapping pins and it must be high when the microcontroller is booted to enable normal operation. Again, just in case another I/O pin was to be used with a switch, the variable buttonState will be used to hold the current binary (HIGH or LOW) value read on the I/O pin and buttonActive will be set to the opposite of the initial value of the pin on the assumption that it is in its off (unpressed) position when the microcontroller boots. So in our case, the button will be deemed pressed when its value is equal to buttonActive , in other words, when digitalRead(buttonPin) return LOW

Finally, some necessary but not necessarily elegant switch debouncing is done within the loop() function itself (thank you Mackenzie King for that idiom). That avoids bringing in my button library.

Internal vs External Antenna

Version 3.0.4 of the ESP32 Arduino core undertook and hopefully finalized the handling of the antennas on the XIAO ESP32C6. By default, the RF (radio frequency) single pole double throw switch is enabled and the internal antenna is selected. The board does not detect if an external antenna is connected, so it must be selected explicitly. This would usually be done in the setup() function of a sketch with the following line of code.

As we have seen, WIFI_ANT_CONFIG defined in pins_arduino.h, is the I/O pad connected to the switch control line to select the antenna. If writing code that might be run on other ESP32 boards, I would suggest using the following code or something equivalent.

The RF switch is not enabled (i.e., not powered) by default in the hardware but it was only in version 3.0.4 of the ESP32 core that the switch was enabled in software with the addition of a .../variants/XIAO_ESP32C6/variant.cpp file containing an initVariant() function (see the Enabled the onboard ceramic antenna by default when creating a new pr… commit for details.)

The initial versions of all the sketches presented below that used wireless communication were flawed because they were based on version 3.0.2 of the ESP32 Arduino core and I was blissfully ignorant of the problem with the RF switch since all the devices were within a meter or two of each other. As of August 9, I believe that I have corrected that mistake in all the sketches. Since I wanted to maintain backward compatibility with version 3.0.2 of the ESP32 core, here is how I dealt with initializing the RF switch and selecting the internal or an external antenna.

Essentially, the setup code contains the equivalent of the version 3.0.4 initVariant() function when an ESP32 Arduino core older than 3.0.4 is used. Frankly, I have not found a good reason to complicate things this way and I would suggest that everyone use the newest version of the ESP32 Arduino core.

So now we are in a position to truly verify the difference between the on-board ceramic antenna and an external rod antenna.

When an RSSI [received signal stength indicator] value is represented in a negative form (e.g. -100), the closer the value is to 0, the stronger the received signal has been (Source). That makes sense as the RRSI values for each access point is further away from 0 the further it is from the XIAO. On that basis, the rod antenna captures measurably more of the electro-magnetic energy produced by the access point radios. And "that's a good thing" as Martha would say. Just how symmetric these antennas are when comparing their transmit and receive behaviour is not clear, but I think it's pretty safe to assume that the rod antenna will prove better when transmitting a signal than the ceramic antenna. I don't know anything about RF circuits, impedance matching, VSWR and all that so don't take my word for it, instead look at graph produced by msfujino. While it is not the purpose of the study done by msfujino, I think it additionally shows that the external antenna transmit more power than the internal antenna everything else being equal.

The source code is in the 03_scan_wifi directory of the xiao_esp32c6_sketches repository. The code has an additional macro #define DISABLE_RF_SWITCH to test the consequences of not powering the antenna selection switch. If you are intrigued by the counter-intuitive results that will obtain if the macro is defined, then you may want to look at the sketch in the 12_xiao32c6_antenna directory or just the raw data from running that sketch.

The Wi-Fi Blackhole - An Unexpected Quirk

I think an "unexpected quirk" is a superfluous, useless and inessential redundancy. Be that at it may, I ran into a problem using the wifi_tx_power to plot connect times against the transmit power of the WiFi radio. It would systematically show that the connection to the IP address was 0.0.0.0 when the connection to the Wi-Fi network was established. Adding a delay would fix that problem, but I was curious about it, so I wrote a pared down connection sketch to get an idea of the time delay involved. Here is a sample of results obtained with one of XIAO ESP32C6 using its internal antenna.

It can take anywhere from 49 to 783 milliseconds between when the Wi-Fi connection is said to be made and when a valid non 0.0.0.0 IP address is registered. The table below summarizes the similar results obtained with other ESP32 modules.

CRAP_SUPER_MINI is actually one of the marginal Super Mini ESP32-C3 cards described elsewhere. It was necessary to set the transmit power to a lower value to get it to connect to the Wi-Fi network.

Clearly this delay has nothing to do with the ESP32-C6, it occurs in all ESP modules that I could test. Why have I never observed that before? Perhaps I just added a delay without thinking about it. Perhaps I am doing something wrong and a kind soul will put me straight.

Connection Time vs Transmit Power

The table shows times needed to connect to a Wi-Fi network in milliseconds as a function of the radio TX power setting. The tests were run only twice on a XIAO ESP32C6, the first time using the internal antenna and the second time using the external FPC 1.2 antenna supplied with the XIAO ESP32C3 (something which should not have been done according to the Seeed KK Engineer Blog article XIAO Antenna.

Those tests were run in version 3.0.2 of the ESP32 Arduino core without enabling the RF switch, so it was necessary to rerun them. Because of reported connection issues (Wifi connection on xiao esp32c6 takes >10 minutes), I took care to test in a more representative environment. So instead of having the XIAO about one metre from the Wi-Fi router, another Wi-Fi access point was set up as far away as practical from the XIAO. It is the OpenWrt network in the previous test. The wireless signal had to travel about 15 metres in one direction and go through two walls. The RF switch was enabled and in this test a generic 2.4Ghz rod external antenna and a PCB antenna (tuned to 2.4158Ghz or 2.4153GHz I can't quite make out the hand-writing) were used instead of the FPC v1.2 antenna. The external antennas were oriented in two different directions. Here are the comparative results when measuring the signal strength (RSSI) from the OpenWrt Wi-Fi network and the time to connect to the latter in milliseconds.

Internal antenna vs external rod antenna – horizontal

To interpret the data, consider the first line of data which corresponds to the default Wi-Fi transmit power as set when the XIAO boots up. The signal strength is greater when using the external antenna (an RSSI closer to 0 represents a stronger signal). The variation in the RSSI obtained with the two antennas is calculated as the increase in RSSI (5 = -75 - (-80)) over the value of the RSSI measured with the internal antenna which gives a 6.25% improvement. Similarly the variation in the connection time is the ratio of the time difference over the connection time (372 - 497)/497, so in this case the connection with the external antenna was an exceptional -25.15% faster.

Internal antenna vs external rod antenna – vertical

Internal antenna vs external PCB antenna – horizontal

Internal antenna vs external PCB antenna – vertical

The good news is that the XIAO was able to connect to the Wi-Fi network no matter the transmit power setting and no matter which antenna was used. This more or less confirms that the rather poor result with the Super Mini ESP32-C3 had more to do with the particular manufacturer's implementation of the antenna coupling circuit than with the nature of the ceramic antenna. On average the XIAO ESP32C6 needed only 1 to 2% longer to connect with its on-board antenna than with the external rod antenna. That's a negligible difference. The 6% signal strength gains when using the rod antenna is more meaningful. The PCB antenna has the potential for attaining an appreciably better wireless connection but its orientation is more critical.

Of course, the source code is available in the 05_wifi_tx_power directory.

Web Controlled LED

The wireless connectivity of the ESP32-C6 is very appealing for those interested in home automation. I ported a simple sketch for controlling an LED with a web page first presented in the overview of the XIAO ESP32C3. Unfortunately, the sketch would not compile in the Arduino IDE with the AsyncTCP and ESPAsyncWebServer libraries that can be installed with the Arduino library manager. Luckily, the newest version from me-no-dev on GitHub solves this problem. Minimalist copies of these libraries are installed in a private library directory. The details about that can be found in a README file of the xiao_esp32c6_sketches repository.

The only changes made to the original code were to set the TITLE at compile time using the ARDUINO_XIAO_ESP32Cx (x = 3 or 6) macros and to handle the LED since there is none on the XIAO ESP32C3 except for the charge LED. As before the XIAO ESP32C6 onboard LED is toggled on and off by clicking on a button in a Web page.

This is just a skeleton sketch which does not contain important properties of a Web interface for an IoT device. For example, there is no update of the interface should the LED state be changed from another Web client. There is no local control via a push button or switch to control the LED and so on. The series of posts beginning with A Wi-Fi Switch for Domoticz using a XIAO ESP32C3 goes into details on how these things and many more could be done. It should be possible to adapt it without too much struggle to run on the XIAO ESP32C6.

Bluetooth Controlled LED

Given my limited knowledge of Bluetooth, be it Low or High Energy, it was loath to use the BLE library contained in the ESP32 Arduino core. Thankfully, there are numerous examples to be found, some of which were useful for a neophyte.

• ESP32 BLE Server for LED Control by konsaibakudan.
• ble_led by rbaron.
• Communication BLE avec ESP32 by Xykyo.
• ESP32 BLE Remote Control Demo by ArtsemiR.

Starting with konsaibakudan's simple clean, implementation, I had to complicate things and, dare I say, fix some issues. I added many print statements to follow along in the serial monitor as the BLE peripheral/server is set up. Remember, I am trying to learn this stuff. After that, I looked at the services and characteristics UUID.

First here is a quick word about characteristics and services. A characteristic is a data value transferred between Bluetooth devices. Logically linked characteristics are grouped into services which correspond to a function. A Health Thermometer service might include a temperature value characteristic, a time interval between measurement characteristic, and so on. The Bluetooth Special Interest Group has a set of predefined UUIDs for services and characteristics. There is an advantage to use such predefined UUIDs in a project when possible. Client apps such as nRF Connect from Nordic Semiconductor or LighBlue from Punch Through Design, will display the service name instead of the incomprehensible UUID. I have encountered some old examples that used reserved UUID that had nothing to do with the project and found that a bit disconcerting, so it would be better to choose carefully among the predefined UUIDs. An additional benefit of using an assigned UUID is that it can be shortened to 16 bits. So there are a few suggested predefined service and characteristic UUIDs at the top of the sketch as well as randomly generated valid custom UUIDS.

The two screen captures with nRF Connect illustrate the advantage of using valid preassigned UUIDs instead of custom UUIDs.

The custom UUID were generated with the Online GUID / UUID Generator following Mohammad Afaneh advice in How do I choose a UUID for my custom services and characteristics?. Also look at BLE UUIDs by Dan Editor. Links to a list of predefined UUID numbers can be found in Assigned Numbers by the Bluetooth SIG. Nordic also maintains a Bluetooth Numbers Database which is presumably wider in scope.

Once I had my version of ESP32LEDBluetoothcode.ino working well, I committed it to the repository before making a final change. Instead of polling the server to read any change in the LED characteristics to update the state of the LED, a callback function is defined as found in the other example sketches mentioned above.

Oh the Zigbee

Zigbee is a low-power, low-data-rate, and close proximity wireless ad hoc network based on the IEEE 802.15.4 standard. Four years ago a Zigbee button was added to the home automation system. Because it worked very well, we have installed additional buttons to mitigate the awkward placement of wall switches and also a few water leak detectors. Consequently, I was very much hoping that the XIAO ESP32C6 would become a platform on which I could build some Zigbee devices. So far that goal has proved elusive, but it’s early and there's still have hope.

The good news it that I did get the example sketches Zigbee_Light_Switch.ino and Zigbee_Light_Bulb.ino running on two XIAO ESP32C6 such that it was possible to turn on and off the LED of the XIAO running the bulb sketch by pressing the Boot button of the other XIAO running the switch sketch. That did require slightly modifying the bulb sketch in two respects. The first is that the original sketch assumed that an RGB LED was connected to the board whereas the XIAO has only a yellow LED available. The other modification proved a bit more tedious to track down. No matter the distance between the two devices, the Zigbee bulb would not connect to the Zigbee switch. The following debug message was continuously output as successive connection attempts failed: esp_zb_app_signal_handler(): Network steering was not successful (status: ESP_FAIL).

As is often the case, a solution was found in a repository issue, in this case the esp-zigbee-ske repository. In a reply about the ESP32C6 having a problem pairing, xieqinan suggested that a weak link between the end device and the coordinator could be the culprit. When the Link Quality Indicator is below a threshold, the end device will not attempt to connect. Lowering that threshold could be the solution. He suggested 32 as the threshold. So following xieqinan's instructions, I implemented that fix.

That worked, the XIAO could reliably pair and there was no problem controlling the LED on one XIAO remotely using the boot button of the XIAO albeit from a small distance. Actually, no problem except with fiddling with the tiny boot button. But that's OK, this is just a proof of concept.

In retrospect (August 6), the true cause for the low link quality was disabled RF switch. Once that is that's fixed, preliminary tests show that if both the Zigbee switch and Zigbee bulb sketches are run on XIAO ESP32C6, each using its internal antenna, Zigbee communication operates in a range of a metre or two. However, at the further edge of that range, the time between a button press and the toggling of the state of the LED is noticeably longer than when the two devices are near each other. It is probably an indication that the Zigbee messages need to be retransmitted. When a rod antenna is used with the XIAO running the bulb sketch, range increases to 10 metres bring no discernable degradation in the Zigbee communication. This is not saying that 10 metres is a limit, it was merely the maximum distance that could be achieved in my work space. Even if no longer needed, the LQI_THRESHOLD macro has been left in the code, just in case the problem occurs in some less than optimal circumstances.

This peer-to-peer network is not what many want. It would be truly useful if the Switch or Bulb sketch could be modified to connect to a Zigbee coordinator such as Zigbee2MQTT or Zigbee2Tasmota. That remains elusive at least in the Arduino context. Much work is being done in that direction using the esp-zigbee-sdk; see for example the Zigbee supporting Esp32 module with Arduino in the Hubitat community forum and Making a working zigbee light with an ESP32-C6. That said, the XIA0 ESP32C6 does connect to the Zigbee coordinator. This is the debug output to the serial monitor of the Zigbee_Light_Bulb sketch as it finally paired with Zigbee2MQTT.

And here is the Zigbee2MQTT log stating that the XIAO was paired but that it is unsupported.

Of course, the fact that the new Zigbee device is not supported by Zigbee2MQTT is not too surprising. All the good Zigbee cluster definitions need to be added and a manufacturer name and a device model must be defined. Over a year ago, swkim01 showed how he did that in the esp-zigbee-sdk esp_HA_customized_light example. But that is already outdated as xieqinan added basic manufacturer information to examples only 3 days ago (2024-07-03). There's every reason to believe that these examples will make their way to the ESP32 Arduino core, when mere mortals will be able to play with their new ESP32 Zigbee gadget.

Unfortunately, pairing with Zigbee2Tasmota was not successful.

It does seem that the "Tasmotized" Sonoff ZBBridge does receive the Zigbee messages from the XIAO, but basically ignores them. It is hard to be absolutely sure about this, as the bridge is in use and it receives many messages from zigbee devices about the house.

Let's end this section with a reminder that parameters need to be set manually in the Tools menu when compiling these projects. The README files for the original Light Bulb and Light Switch sketches list these. If one prefers a screen capture showing the settings then look at the Readme files for modified zigbee-bulb and zigbee-switch sketches. Be careful, the settings are not the same in all respects.

Deep Sleep

The ESP32-C6 has two major power saving modes (light sleep and deep sleep) which in turn can be modified in "sub sleep modes". Furthermore, there are several wake up sources which can be combined to bring the controller out of sleep mode. Truth be told, the sleep modes on the ESP32-C6 are rather complex and I will have to slog my way through the ESP32-C6 technical reference manual, the Sleep Modes API documentation and probably the Power Management API documentation and as many examples as possible to make sense of this.

The Deep sleep mode and wake-up examples in the Seeed Studio Getting started guide are simplifications of those found in the ESP32 Arduino core and unfortunately neither worked when I tried them. The consensus of those who responded to pleas for help on this topic was to remove all use of the Serial peripheral. Actually, this is not necessary as will be reported at the end of this section. Initially, I settled on a BASIC example by PJ Glasso published in April on the Seeed Forum as the basis for my example sketches without any output to the serial monitor. Instead all information was transmitted via the onboard LED.

Each time the board wakes up from deep sleep, it behaves just as if it had been restarted. In other words, it executes the setup() function. So the first thing the function does is ensure that the I/O pin attached to the LED is in output mode. Then it increments the boot count which is stored in non-volatile real time clock memory. It then slowly blinks the LED, counting out the value of the boot count variable. After a short 5 seconds delay, there is a quick sequence of flashes announcing that the microcontroller is going into deep sleep mode for a period of 15 seconds. When it wakes up the process repeats, but, of course, the boot count will be one greater than before.

In this example, a timer wakes the board at regular intervals. This could be the basis for a device that reads a sensor and then sends out the data in some manner such as Wi-Fi, Bluetooth, Zigbee or perhaps even via a serial interface such as I²C. Presumably, it could be a battery powered because the board would be in deep sleep mode most of the time. The more important average power consumption of such a device can only be known by testing it because the 15 µA figure is a theoretical minimum for the ESP32-C6 by itself only. Some are investigating this, msfujino in Comparison of Sleep Currents for XIAO ESP32C6, S3, and C3 for example.

Instead of data logging at regular intervals, it would be useful to put the XIAO in deep sleep mode to be wakened only when a monitored event occurs. The following example shows how that could be done with a push button that can momentarily connect an I/O pin to ground. The sketch that does this is almost identical to the previous one. The only significant difference in the code is setting up the wake source.

It was rather lucky that this sketch worked. It was also a bit unfortunate because it would not work with D1 or D2 as the wake pin nor would it work when inverting the polarity of the wake connection. I was searching for an explanation in the wrong places, until I read a note about esp_sleep_enable_ext1_wakeup in the esp_sleep.h source code.

On reading that, I left the internal pullup in place, supplemented it with an external 47K ohms pull up resistor and tested that pin D2 could reliably wake up the board when it was in deep sleep mode. Further tests proved that D0 and D1 would work reliably and that it was possible to bring the board out of deep sleep with a high signal using any of those three pins. Of course it is necessary to change the (redundant) internal and external pullup into a pull down and to change the wake up mode from ESP_EXT1_WAKEUP_ANY_LOW to ESP_EXT1_WAKEUP_ANY_HIGH. One could also use any one of I/O pads 4, 5, 6 or 7 on the underside of the XIAO to wake the processor. Trying to use any other available I/O pin on the XIAO will cause an error since only I/O pins 0 to 7 are mapped to RTC I/O pins.

The external pull up (or down) resistor will increase the current draw. Consequently, I will look into the use of the esp_sleep_pd_config function. However at this point, I am happy to have working skeleton sketches for the deep sleep mode of the ESP32-C6.

Using Serial

The Serial peripheral can in fact be used as long as it is properly closed down just before entering deep sleep. For example, these are the last four Serial methods invoked just before deep sleep is started with esp_deep_sleep_start() in the deep_sleep_io sketch.

And here is the output to the serial monitor as the XIAO was woken from deep sleep at 22:38 and then about four minutes later at 22:42.

If the macro called USE_SERIAL is defined at the start of the sketches, the Serial peripheral will be used and serial monitor messages such as those shown above will supplement the LED flashes to display the state of the ESP32C6. By default the macro is not defined.

As for the actual current draw when the device is in deep sleep, it is in the micro-ampere region. I don't have equipment nor the know-how for making such measurements. However there is a very good discussion by msfujino on the Seeed Studio forum: Comparison of Sleep Currents for XIAO ESP32C6, S3, and C3 with the following results.

That last column is a bit of a tongue-in-cheek addition. The time for a 2Ah battery to be discharged down to 2O% by a XIAO that is always in deep sleep mode was obtained with the online calculator: simple calculator for estimating a (LiPo) battery's life.

Again, the source code for these examples is available for download on the associated GitHub repository.

One final note while on this topic. Once the ESP32-C6 is in deep sleep mode, it is not possible to upload a new version of the firmware to the device. It will be necessary to put the board in bootloader mode.

Resources

Rather sparse for now, but more links may be added later.

• Espressif:
  • ESP32-C6 Technical Reference Manual.
  • ESP32-C6 Series Datasheet.
  • ESP-IDF Programming Guide - ESP32-C6
• Seeed Studio:
  • Getting Started with Seeed Studio XIAO ESP32C6.
  • Seeed Studio XIAO ESP32C6 Open-Source Material contains links to the Board schematic, KiCAD Libraries, and other resources.
  • Forum with "xiao-esp32c6" tag
  • Forum with "ESP32C6" search
• MicroPython (I have yet to test either flavour of embedded Python):
  • Using the ESP32-C6 with CircuitPython – flashing the bin file by Clovis Fritzen (FritezenLab)
  • MicroPython may soon be available: esp32c6 support (IDF v5.2)
• Similar Boards:
  • Beetle ESP32-C6 by DFRobot. Also DFR111U Beetle ESP32-C6
  • SparkFun Qwiic Dev Board ESP32-C6
  • ESP32-C6-Zero Mini Development Board from Waveshare. Also ESP32-C6-Zero Wiki

First Look at the Seeed Studio XIAO ESP32C3