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.

That introduction was written in June. It is now early November and the major change to the project is that it is now PlatformIO compatible thanks to pioarduino a fork of the Platformio Espressif 32 development platform for PlatformIO by Jason2866. It is based on version 3.x of the Espressif Arduino core which supports ESP32-C6 SoC and other newer devices.

Table of Content

1. Disclosure
2. A Big Brother to the XIAO ESP32C3
3. First Connection
4. Initially for the Arduino IDE Only
5. Now Available in PlatformIO Also
   1. Using the Stable Branch of pioarduino
   2. Which Branch and Fork?
   3. About the New Board Definition
6. Pin Numbers and Names
7. Blinky, Blinky
8. Internal vs External Antenna
9. The Wi-Fi Blackhole - An Unexpected Quirk
10. Connection Time vs Transmit Power
11. Web Controlled LED
12. Bluetooth Controlled LED
13. Oh... the Zigbee
14. Deep Sleep
15. 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.

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. All symbolic names associated with the edge pads are the same as they conform to the XIAO form factor. However, the I/O pin assigned to each peripheral is totally different. There is a lesson in that: always use the symbolic Arduino pin names when writing a sketch for a XIAO board. That way it will be simpler to port a sketch to another board in the XIAO series.

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.

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. The most obvious visual difference is the antenna. The new board has an on-board ceramic antenna for wireless connections, but there is a U.FL coaxial connector for an optional external antenna. The boot and reset buttons have been moved from the bottom of the board to the top, which is not significant. However they are now much smaller, domed metal, tactile switches which are noticeably harder to activate.

There are significant differences between the boards that are not visible. 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.

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. Or if the board is already connected to the computer, try the following command michel@M7:~$ dmesg | grep -E 'usb|cdc_acm' | tail -n 7. Alternatively, list, using the long format, all serial devices.

A copious amount of information can be obtained with the sudo lsusb -v -d 303a:1001 where the device ID was obtained with the . 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.

After this long introduction, it's finally time to look at the serial output from the XIAO ESP32C6 which arrived with preloaded firmware. While in the past cu (actually opencu) was my preferred terminal emulation program, I now use picocom because it has a simple mapping feature to take care of the end of line encoding.

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).

Initially, Arduino IDE Only

Initially, only the Arduino IDE (available here) supported the newer ESP32-C6 SoC. Here is how to configure the IDE.

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.
   
   There can be more than one board manager as can be seen.
2. Install the newest version of the esp32 by Espressif Systems in the BOARDS MANAGER.
   
   If there are too many board managers, enter esp32 in the search box at the top to shrink the list. Version 3.0.2 or newer is needed; as of Nov. 6 version 3.0.7 is available.
3. Select the XIAO_ESP32C6 board and its port
   Plug in the board to a USB port on the computer.
   Click on the board combo box on the action bar where the IDE is already showing some board. A drop-down list of possible boards will be displayed. The first choice is almost correct here, but the actual board is not defined properly. So click on Select other board and port....
   Start typing xiao or esp32c6 in the search box. The XIAO_ESP32C6 should show up in the list. Presumably the correct serial port will be shown on the right. select both these elements and click on OK.

The Arduino IDE does have some annoying quirks. The Copy-paste data from the serial monitor problem has been around for some time. Copying the serial output is much easier with picocom. Be careful, picocom will not work if the serial monitor of the Arduino IDE has control of the serial port connected to the XIAO.

Now Available in PlatformIO Also

The ESP32 platform (platform-espressif32 version 6.9.0 dated September 26, 2024) from PlatformIO is based on version 2.0.17 of the Arduino core for the ESP32 by Espressif which does not support the ESP32-C6. Initially, I thought it was just a matter of time before platform-espressif32 would be migrated to version 3.0. Given that PIO is developed in Ukraine which faces unbearable hardship, patience seemed to be in order.

While I only found out about it in the last week, Jason2866 announced the creation of the pioarduino fork of platform-espressif32 on July 16th. He wrote [since] it is now clear that there will be no official support for Arduino core 3.0.x from Platformio team, [...] i decided to fork the needed repo(s) and build a community version to support core 3.0.x (starting with core 3.0.3). I can't pretend to understand the responsibilities and actions of the Espressif and PlatformIO developers in this matter. Consequently, I will not comment on the situation. However, PIO is my preferred development environment for embedded devices (even if version 2.x of the Arduino IDE was a major improvement) so I am most grateful for Jason2866's work which made it possible to add PlatformIO support to the xiao_esp32c6_sketches project on GitHub on November 5th.

Let's be clear; I am still using PlatformIO in VSCode (actually, in VSCodium, but that's a more complicated story). What has changed is the "integration" of the Arduino core into PlatformIO. I am no longer using platform-espressif32 maintained by the PlatformIO team, instead I am using the pioarduino fork by Jason2866. In practice all that's required is to change one line in the platformio.ini configuration file of projects that use an ESP32. Where the configuration file contained the following line

now it contains this line

As a complete example, here is the configuration file for the 01_pin_names project.

Basically that's it, don't bother trying to install the platform, just compile the project. PlatformIO will take care of downloading the development branch of the pioarduino platform and will install everything. Because of that, the first compilation will take longer. Later compilations will be much faster because the platform will not need to be installed again. Indeed once the first project is compiled, one can check which platforms are installed in the system.

That seems simple enough right? Yes, but there are some complications.

Using the Stable Branch of pioarduino

My instinct is to avoid development branches if at all possible. Thankfully, the GitHub documentation has the following instructions.

The stable branch of the platform was used all the examples sketches except for the first one. Currently there is a problem because the XIAO ESP32C6 board definition was not available when the stable version was released. So it was necessary to add the board definition locally and add an entry in the platformio.ini configuration file with the path to the board definition.

The following tree shows where the board definition file was added and explains why the project relative board_dir path was up one level.

The board definition file and the boards_dir entry in platformio.ini will probably not be needed in the next release of the stable version. And this brings us to the next point.

Which Branch and Fork?

After adding support for PlatformIO and compiling every example sketch to be presented below with PIO, I ended up with three Espressif 32 platforms.

That made sense because the development branch of the pioarduino fork was used in the first sketch and then the stable branch was used in all the other sketches. The original espressif32 platform from the PlatformIO was still present. Notice how it is version 6.7.0, which is not the most recent. I clicked on the Updates button near the top of the window, and the IDE reported that no platform needed updating. That was a bit perplexing since version 6.9.0 is available. Next I compiled a PIO project for an ESP32 (first generation) which had platform: espressif32 in its configuration file. Looking carefully at the output during compilation it transpired that pioarduino/platform-espressif32.git#develop was used. Since platform: espressif32 is a generic specification which PIO interprets as meaning using the latest version of the platform, it is understandable that it used the develop branch of the pioarduino fork. After all the PIO documentation is quite clear on this.

Clearly, I should never have used the ambiguous platform: espressif32 configuration. In my defence, it never caused problems in the past. Now, more care is needed. And here is one reason.

The PlatformIO team continues to develop the "official" platform-espressif32 integration and the pioarduino fork is 26 commits behind (2024-11-09). It may be that among these, there are some corrections or additions that are needed in a project. In those cases, it may be necessary to go back to the official platform. However, the point is moot for ESP32C6 based boards since the official platform does not support them at all. I hasten to add that this is in no way a criticism of the pioarduino fork. For months now Jason2866 has been doing yeoman service almost entirely on his own with his up-to-date version of platform-espressif32. He would probably appreciate some help in keeping up with the official repository.

There's work ahead for me: going through all my ESP32 projects and testing them against his pioarduino platform to see if there's a problem or not and pinning the platform to the appropriate version as recommended.

About the New Board Definition

The first attempt to build one of the projects in PlatformIO with the pioarduino fork failed because the latter did not contain a definition for the Seeed XIAO ESP32C6. The official platform-espressif32 boards directory did not contain a json definition file for any ESP32-C6 board as far as I could see. So I compared the XIAO_ESP32C3 and XIAO_ESP32C6 definitions in the boards.txt in the espressif/arduino-esp32 core. Since the only significant difference seemed to be about the JTAG, I decided to use the seeed_xiao_esp32c3.json" as a starting point. I substituted "C6" for "C3", and got rid of the "ldscrpt": "esp32c6_out.ld" key-value pair because I could not find the file. I then fixed up the definition by comparing it with two definitions for ESP32C6 based boards (adafruit_feather_esp32c6.json and sparkfun_esp32c6_thing_plus.json) found in the pioarduino boards directory. I stuck the resultant seeed_xiao_esp32c6.json definition in the boards directory of the clone on my computer and then found that every example sketch would compile and run. "Brilliant" I thought. That was not a comment on my prowess but a compliment to both the PlatformIO team and Jason2866. My contribution is fa cut-and-paste job more on the level of a parakeet repeating random phrases that are not understood.

So I promptly forked pioarduino, added the board definition and did a pull request (PR) essentially asking that Jason2866 include seeed_xiao_esp32c6 in the boards directory. Then panic set in when I got the following notification about six failed integration tests.

Quite an average, 100% as a matter of fact, because in my first ever PR, I managed to make the very mistake that I was attempting to correct. Luckily, the reviewer corrected that before committing the change. In this second case, I was surprised that Jason2866 merged the change a few hours later, I was expecting to be told that I had not done my homework... which to be honest was the truth as I could not figure out how to run any tests. As for the failed runs, none seem to have anything to do with the board definition.

The real reason for this nostalgic recounting of the events of the last week is that I want to apologize to Lucas Katayama. He had already proposed a seeed_xiao_esp32c6.json file on October 4th. However that file is languishing as an open PR in the original platformio/platform-espressif32. The fact that the PR remains open explains why it was not in the repository. I had not thought to search open pull requests when I found nothing in the boards directory. It is unfortunate that other useful contributions to the official ESP32 platform may be lost because their PR will never be merged unless there's a change of heart and the PlatformIO team moves on to the current Espressif Arduino core. Many may not be aware of Jason2866's fork, like Luca and I back in October. Be that as it may, I want to make it clear that I should have credited Lucas who was, as far as I know, the first to create a board definition file for the Seeed XIAO 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 pin 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