Choose a right XIAO board for my next project - opinions?

Products & Technology XIAO
1

Hi, community!

I’ve read a lot of articles and checked a lot of products on the site to find a board for my next project. So far I understand there’s no single board with everything I need and there will be trade-offs, but I could be mistaken. That’s why I would like to ask for your help, as you are not new to XIAO boards.

My main criteria points:

  • Supports Bluetooth (preferably the classic one, but BLE may be probably a fit as well)
    I am planning to have an application on my PC / Phone, which will connect to the controller over Bluetooth and send some instructions, as well as controller can respond back to the paired PC. I don’t need the Bluetooth to work all the time, so only when the application is connected. Therefore I figured out I don’t need a BLE - hence I will be able to support a good stream between the controller and the PC, and don’t maintain the Bluetooth signal, when I have the application off. Talk me out if I am mistaken here and BLE works better. But as I understood BLE is good for different scenarios.
  • Supports USB (preferably Native)
    Similar idea, I want to be able to use USB instead of Bluetooth for pairing with PC. Though, I was as well thinking on using USB-Midi, to send some Midi commands to the device. I quite not sure, whether having a Native USB on the controller is an advantage here. I believe, alternatively, I will need to create my own drivers, if Native USB is not supported? I’ve had a very nice USB Midi experience with Teensy boards. So, would love to have similar capabilities.
  • Has onboard flash for user data
    This is a tough topic for me. My application will have a capability to save few configurations sent from the PC into the controller, so the controller then can use them standalone without the application. Hence, I would like to be able to store them within the micro-controller, so they are saved in the device even if the device will be shut down. I deliberately want to not use an SD card, since it is an overkill for my application. In my scenario I will use quite a limited amount of storage for several light-weight user settings.
    Also, I know it is possible to write into the EEPROM of the controller, but I want to exclude this, since it doesn’t look to be the right place for user specific things, and EEPROM has a limited amount of write cycles (yeah, it’s around 100K-1M, but anyway, rather a hack, than the best practice). I understand, that the units with QFlash onboard are specifically designed for my goal, am I correct?
  • Supports Battery Power
    And here I mean indeed the standard alkaline battery usage, not a Li-Ion one. I believe it is not an issue for almost all the XIAO boards, however, I would like to check with you. It is important for me to be able to use USB and USB power when connected to the PC, while using the battery when USB connection is absent.

I think this is it. I’ve also checked lots of Adafruit QT boards - unfortunately they either have a BLE but not Bluetooth, USB but not Native, or have WiFi, which I don’t need at all. However, any hint into the direction of any other board is welcome. Size matters, but I will be glad to hear your opinions.

2

Hi there,
So you almost ask and answer your own questions there, LOL
BLE is what you want , Support for classic is there, but not the way to go. BLE offers much more in terms of connectivity and power savings.
USB is built in omn the Xiao line, NO issue’s there.
2MB On-board Flash used for exactly that SD replacement (for small data sets) local storage
Touted as the lowest power of all the MCU’s at 5ua. power draw in deep sleep Ideal for Battery and wearable devices. Built in charger also.
Hands down better Hardware than anything presently available in production levels today
HTH
GL :slight_smile: PJ

as an aside Nordic as well as Espressif has made it there montra to build on past expertise.
So Device Backward compatibility and New features are a large consideration vs. product same old same Obsolescence. When the Next XIAO versions come out the GROUND will shakeup!

separate and in addition to the On-CHIP flash of 1MB for program and data on the XIAO

3

Hi, guys! Strange, I wasn’t able to create a new topic, but, maybe I can re-use this one.

Basically, I’ve ended up with ESP32C3 board and am quite happy about it: it does what I need, namely, BLE communication. The code is already 86% but it should be enough for me.
However, one nasty thing I’ve discovered, is that ESP32C3 demands around 60mA with BLE on, which is quite high for my project. I can’t really go deep-sleep with the things I am doing. I am playing around a light sleep these days to see how I can win few mAmps (still with no luck). I’ve learned there’s a “modem-sleep” option, which I is not trivial, but I’ll try to dig down into it.

However, I’ve just stumbled across the new board XIAO MG24 and at first glance it looks to be a more interesting option. To be honest, I don’t need all of the features MG24 has, apart from BLE. But the specs says it uses 5 mA TX current @ 0 dBm, which is around 10 times less, than the same on ESP32C3.

Therefore, a question: are these specs real? Because I have no issues of porting the BLE related code to MG24 library, I believe, if I benefit an x10 profit in current. Do I also understand, that 1.5mb onboard memory + 4mb additional flash the board has are all available for the program code? Because on current board I am already close to 86%.
I believe, that OTA update is also a thing for MG24, so it is possible to update the device wirelessly.

So, do you think, a move from ESP32C3 to MG24 is reasonable if the device is mostly used in the active/light-sleep/modem-sleep mode? Or the true specs of MG24 will not be this bright and I will have similar consumption in the end?

4

Hi there,

So if it’s BLE and Lowest power you want ,Then you may be missing the boat as the Xiao nRF52840 has the lowest sleep >4uA as well as better BLE range @8dbm vs. pwr required.

Without knowing what other features are required in your code. I would use the online power profiler and run the numbers first.
All three considered… The answer will be Obvious. :+1:

HTH
GL :slight_smile: PJ :v:

5

Hey! Thanks for the response!

The reqs are here:

  • BLE
  • Lowest power in "active: mode (when Bluetooth connection is maintained)
  • 4mb flash (for the code and OTA)
  • Do not use any expansion boards, just the raw dev board
  • Do not use any SD cards, or so

Both MG24 and nrF have 1.5mb of Flash. I am afraid that won’t be enough, unless there’s a simple way to expand the memory myself, like adding a flash unit to the prototyping board (and then to PCB when in “production”). Is it a big deal implying the firmware re-write?

6

Hi there,

So that is a good set of req’s, I would ditch the Mg24 IMO (unless your familiar with there Dev env & lack of software support ) you may want to consider the C6 in that case, it’s got the on board 4MB flash. The BLE is Good at medium range, The sleep is the best of all of the ESP32 series Xiao’s
Adding the flash to the Nordic enviro is no issue, the softdevice and bootloaders are very stable and a couple to choose from. Next would be the BSP selection based on the LIBs and code.

is it a proprietary device can you describe the use case and the device intention. Utility with Novel design or Prior art improvement?

If seeed engineering chooses a nRF54L15 with a 4 or 8 MB flash for the next Xiao they could shred the market IMO. MOST powerful MCU set and PHAT memory with the LOWEST Power requirements in the business. Adafruit who, or SParkfun at what?
slap a PMIC on there and You got the most Bang for the buck for SMARTEST battery powered devices with 6 and 8 month battery life for non-rechargeables.

HTH
GL :slight_smile: PJ :v:

7

Hey, PJ! Appreciate your answers!

Without diving into the specifics,

  • the device needs to communicate with several SPI compatible ICs
  • the device needs to send/receive the data over bluetooth and support OTA

So, as per libraries it means I need the Bluetooth Libraries (currently I use BLEDevice, but I don’t mind switching), and SPI library. All the rest is just a business logic related code in cpp.

And the crucial thing is that unlike many devices using similar chips, where the intention is to “wake up”, send some data and go to sleep for the majority of its time, the device I am working on should stay active for a long period of time. There definitely will be times when it goes to sleep, but the Bluetooth is needed for the user to interact with the device via the PC or the Phone. In the old days similar scenarios were solved by simply connecting the device over the USB and letting user interact with the device. Nowadays, as the world goes “wireless”, I want this interaction to happen via Bluetooth. And yes, the device is battery powered. I don’t need to survive months on a single battery in active mode, but 6-10 hrs of active bluetooth is something I am looking for. And of course, the active interaction will not happen 10 hrs in a row, which mean, the user has in average month or two with a single battery if he uses the active mode here and there for some tweaking.

As per the other question: the device is intended to be patented (ideally), but it doesn’t belong to any company. We can say it is a personal “startup” which may have a potential to become a marketable product and be sold. So, the code is private. I understand this is needed to stay away from creative common’s licensed libraries which force the code to become open-source or so.

BTW, I saw a response from the developers of Nordic on additional flash memory for nrf52 and thought they have said it is possible to add QSPI flash, they’ve not recommended it due to some possible issue (QSPI: Race condition occurs in XIP, whatever it means).

I was looking again at ESP32 / MG24 / nrf stats, and I am blown away with the power consumption of MG24 and nrf. ESP32 C3, S3, C6, you name it, are simply a no go with their greedy minimum 30-60mA consumption. I, somehow thought, that nrf is the top chip in power management, but am looking into the datasheets now :

radio at 0.0dbm
nrf5280 - 6.40mA
nrf54L - 5.0 mA
mg24 - 5.0 mA

Do I read it correctly, that mg24 actually already performs at the level of nrf54L and has 4mb flash, which is what I need. If so, it may be indeed my next board to go, even without waiting for SEEED to release xiao nrf54L.

I don’t have any mg24 experience, but I tend to believe the BLE library, the SPI library are there. OTA is also there according to the data-sheet. Any issues I may fall into with porting my code to MG24? According to the getting started page should be no different from any other arduino-compatible boards.

I hope I read the power consumption right on MG24 and it is indeed this good.

8

Hi there,
Sure thing :v: Keep reading and looking before you choose, none of the libraries are fully cross-compatible. You don’t need a QSPI flash,Spi flash is good enough and the race condition is an anomaly for certain PCB’s only if you go from one flash to the other to the internal… Do you have a PCB? NO ? don’t put the kart b4 the horse.

nothing that’s rocket science here… pretty straight forward.
A’h the Battery… :nerd_face: Baseline the schematic’s power consumption. Do you have that number?
Go to the Battery life profiler (link in previous post) DigiKey. Put in your info. What size does it require to get the run time you need?
What is the Charge current the Xiao you plan on choosing?
further,
0 dbm is normal for basic BLE communications (power limits apply)
some places limit it. All the SI marketing about STRONG BLE is just hype. FCC limits it and so does the physical constraints of your enclosure (assuming it’s in one) @6-10 hrs of BLE I only can speak from experience for the nordic silicon. YOU better test the MG24 there data is suspect, as much as there libraries are.

what does that mean, LOL :upside_down_face:
and no one cares about the code, the code isn’t what gets patented
Your device isn’t open sourced.

Do you have experience with the IMU? MG24 has a surprise for you if so…I won’t spoiler alert…you.

Having successfully developed multiple PCBs and holding an active patent with two more pending, I can see that you are still in the early stages of the process.
Keep reading and do you own testing (you have been warned) Do not fall for the shiny slick text on a datasheet, especially one that has little to no reputation in the space. you said several SPI devices too, compatibility will come up forsure, stuff that compiles fine with this , doesn’t or won’t with that. also if you think a “ChatGPT” will help in cases of new LIBRARIES it may make it harder be aware.

the OTA is an Art form, Nordic has it in spades…I don’t even think an example or lib exists for the MG part? also forget about any wake up from IMU. :stuck_out_tongue_closed_eyes:

Lots to do, let us know what you find…
HTH
GL :slight_smile: PJ :v:

9

Hey, thanks for a very nice structured answer!

That’s correct, I agree. It will just be very frustrating if I put all the bids on nordic, and eventually just realize there is no option to expand the memory.

My other ICs are switches and potentiometers, and they in total require less that 0.5 amp in active mode. They are so neglectable comparing to the chip itself, that I don’t even mention that. Those chips are optimized for battery use, have nice shutdown features, etc. So, in my case the culprit is the controller. No rotors, no robotics or anything which enormously draws the current.

To be honest, with ESP32C3 I have even set it to -24db (which is the lowest possible), and with the external antenna which we have in the kit from XIAO, it was working quite good for me. In my case the device is always near the user (Computer or Phone). So, I can go really low on DBs as long as it saves the energy.

Admire your achievements, really!
That is very correct. I learn while developing. I have the prototype working end to end on ESP32C3 (on USB power, not the battery), which is a nice milestone. I was thinking to start layouting PCB, before I discovered that ugly power consumption from the chip which sagged my battery :smiley: So, I am a bit distracted from my original plan, as you see, and need to think about proceeding my development with another board.

Yep, that to be discovered. The SPI.h on ESP-arduino works as a charm for me. Who know what I will discover with other boards.

Do I read it correct, that you had some frustrating experience with Silicon Labs? To be honest, I never had an experience with them, so I don’t know what to expect. My only hope is that Seeed knows what chip to take for the board production and it was chosen for a reason. Would be very sad if the text on the paper is just a text :frowning: What’s wrong with them, could you please share some examples?

So, it looks like I need to buy two boards nrf52 and mg24 to check myself how they work.

I use PlatformIO (the project is quite big for Arduino IDE) and both of the boards are not there, unfortunately. So, will be an adventure as well.

10

Hi gmrck,
The link below shows a comparison of advertisement current. nRF52840 has by far the lowest current consumption compared to MG24. It may be helpful to you.

The output of the MG24 is designed for 20dBm or higher. On the other hand, the nRF52840 is designed for an output of 8 dBm, which is by far the best choice for small output power.
The nRF52840 automatically sleeps when there are no events by RTOS, but the MG24 BSP does not seem to support this feature yet and consumes current unless it is explicitly put to sleep.

1 Like
11

Hey! Thanks for the link. Have you measured the current in active mode past the advertisement, when the device was connected already?

As for dbms, does it mean mg24 won’t work with 8db transmit power or even 0? Or just that it will work worse?

12

Please refer to the following link.
The MG24 is limited by firmware to BLE power from -3 to 8 dBm.
Designed for 20dBm output, the MG24 is inefficient and requires significantly more current consumption than the nRF52840 for the same 0dBm output.

Have you measured the current in active mode past the advertisement, when the device was connected already?

After connecting, the nRF52840 consumes some current to wake up at regular intervals to check the connection, even when it is not transmitting.
The MG24 will continue to consume current unless explicitly put to sleep.
(This is only the result of using the current BSP2.2.0.)
Considering future development, I would recommend getting ppk2.

13

Hi there,

Your very welcome, we are all here to help, some of my experience may be of benefit so I offer it as ancillary information. Yes PLIO is the way to go for larger projects, the Nrf52 IS indeed available for both the sense and NON sense versions. The debugging works very well also for the nRF52 series, I can’t speak on that for the MG24 as I understand it if you want to do more than blink LED’s you will need to use their SDK. and Most of the juice isn’t worth the squeeze from my POV. See my threads, If you want to spend almost NO money and GET ALL of the info and training for FREE without a GIGANTIC RUG PULL in the end. (espressif) there’s only ONE choice IMO.

Not to mention the future proof the stuff is. The NRF_SDK along with the (TRUE) Dev_boards that don’t cost as much as a game console by the time you get the debugging going. There’s come with a Jlink probe built -in , with Customisable Device trees and Overlays based on YOUR own PCB that include a Nordic SOC.
The stuff goes together like “cake & Ice-cream” or "peanut butter & jelly " @msfujino info is the “receipts” so follow those threads and get up to speed on the many facets of the Xiao family of MCU’s doesn’t take long , just reading and trying some experiments. Lots of smart folks here to help so ask away and always have some fun. :+1:

If your comfortable with PLIO on VS, then it’s the same. see some of the threads on it.
If your going to be doing BLE work as well the Nrf_dongle $9 is the best money you can spend for testing and using BLE in any code base. NRF_for Desktops leads the way.
HTH
GL :slight_smile: PJ :v:

Without knowing the codes purpose, even the lightest sleep modes can improve battery life and not effect BLE connection Latency if it’s an issue. I see a lot of opportunity for it in the brief flow description.
forsure use the battery life calculator as a starting point. :+1:

1 Like
14

Hey, guys! Thanks for tons of useful information.

I think I read it correctly, that the nRF is the only way to go.

I’ve done some search online and MG24 doesn’t look to be a very popular platform.

I believe, I see my following journey as:

  • I’ll try to port the code in Arduino/PlatformIO to nRF52
  • If the compiler shows me I have enough of memory for the program still, I’ll order the board itself and try to run the program there

Also, as far as I understood, it is quite easy to port nRF52 program to nRF54, so, basically, when I am on a stage of custom PCB, I may squeeze in the upgrade from nrf52 to nrf54 there.

1 Like
15

Hey, guys! Just some follow up update.

I’ve recently migrated the BLE related code from using BLEDevice library to Nimble-Arduino, and my god, that library is TINY! The BLEDevice library is HUUUGE and it ate more than a half of the available space on the ESP32C3.
I’ve just received the nrf52 Xiao version and will try to port the whole project there. Maybe, I will not be out of the free space after all with the Nimble!