Replacing RPi Pico with ESP32 Microcontroller

[JHthe4]

Servus @NuclearPhoenixx ,

first of all thanks for taking the time to develop and document this project! It looks really interesting and I love the low-cost, DIY aspect of it!

I'm curious if you've considered the possibility to replace the RPi Pico mirocontroller with an ESP32 NodeMCU board instead? It offers native Wifi support, so reporting results to MQTT for example would be very convenient for a static setup. Also, it might not have the same ADC issues we're seeing with the RPi right now. How difficult do you think this modification would be to make (on the hardware side)?

Thanks!

[NuclearPhoenixx]

Hi,

I aggree that WiFi support would be sweet, for now you can only swap the standard Pico with a Pico W and do some slight modifications to the software. The ADC issues are annoying and pretty unecessary honestly, but it's nothing too bad, I mean if you know of these four channels and their immediate surroundings, you can just ignore them and you'll be fine. It's not like 5 channels more or less will change much about your spectrum. It looks ugly sure. And you will always have more than one channel/keV and the energy resolution will be much, much worse for that to ever be some kind of bottleneck.

As for how difficult it is, it really depends on a number of things. We'd need a version with two cores that is readily and cheaply available almost everywhere. That's the biggest problems with most other (development) boards at the moment honestly. Well, the ESP32 is probably on the better side of that anyways, but you know how it is. As for the Pico, well there is only one standard and one W version and you can get it literally everywhere for cheap, that's what's really nice about it.

Also, software support for the Pico makes it a breeze to work with, also thanks to the Arduino IDE and the great Arduino-Pico library. I don't know about the ESP32, there probably is Arduino support for that, but I have no clue about how capable that is. It's nice to have interrupts and PWM on almost all the digital pins, being able to change the location of hardware I2C, SPI and UART with only very few lines of code and changing things like clock speed or core voltage on the fly. It's also nice to have a built-in temp sensor and selectable output pin strengths. And even if you don't want to program it using the Arduino IDE, you can just use my UF2 file and literally drag-and-drop it onto your Pico, how nice is that. I have no idea how easy that is for an ESP32, but I'd guess you need to have a programming software installed.

And on top of that, consider the electronics of the Pico. There is a pretty good SMPS chip already on there laid out so that you can easily modify it by adding a LiPo charger or something like this. If we drop the Pico and use a bare ESP32 or some kind of official dev board, there would need to be similar circuitry, or I'd need to add that too. The ADC of the ESP32 also seems to be a lot slower than that of the Pico, which is also a critical thing to keep in mind.

TL;DR. It's possible, but you might have to add some circuitry for the power stage and you might lose some of the ease of use/convenience, maybe also a couple of more niche features and the dead time will be higher. And depending on the layout of the ESP32, you'd have to change the board layout.

Let me know if I got anything wrong about the ESP32, please!

[JHthe4]

Thanks for sharing your thoughts!

You make a lot of good points, and especially the niche features you mentioned, as well as the standardization of there being only one Raspberry Pi Pico version and the low ADC sample rate make it seem like the ESP32 is not really a good candidate in this case. As far as I know, most versions these days are dual core, have a slightly higher clock speed and more memory than the Pico, which was driving my thinking. I've used several versions of the nodeMCU development kits from Aliexpress over the years, and have never had a problem with the silicon shortage. It's definitely an interesting little board, and although it may not fit into this project maybe you'll get an opportunity to work with it in the future if you haven't yet. Arduino is ported to it, but it probably doesn't have quite as much support as the popular RPi products.

Considering that I opened this disussion out of a desire for MQTT support, I guess that replacing the Pico with the Pico W is the best option for now. A limitation might be that apparently only Core 0 can run Wifi-related code, so maybe the work distribution will have to be switched between the two cores. Furthermore, it doesn't seem like popular MQTT libraries for the ESP32/Arduino explicitly support the Pico W, so maybe some tinkering will be required. Apart from that though, it shouldn't be too hard to set up a routine which sends the spectrum to an MQTT broker either on a fixed schedule or when it runs full. Hopefully I'll get a chance to look into this in the future. I like the idea, and I'm confident this can be done.

[NuclearPhoenixx]

Higher clock speed might be nice to have, although you can pretty reliable overclock the Pico to 200 MHz for example. Also the extra RAM isn't really necessary, I'm very wasteful with memory usage at the moment, and I'm still not even close to 100% usage. Most importantly, though, I wouldn't want to require some random nodeMCU dev board from Aliexpress for the project, so yeah.... :)

You might be right about the Pico W's core usage. Haven't looked into that much as you can tell, so that would be something to keep in mind. I'm 100% sure as well that it's possible to do somehow. I've thought about using the Pico and implementing some kind of light version of Gamma MCA directly on it, so that you just connect to its WiFi network, browse to the site and have your life readings. However, that's a LOT of work and time that I don't currently have, so it's only an idea for now.

[plamenbe]

Hi,
just a note from my side.
In fact the ADCs of ESP32 are not good for that project in my opinion. The chip has two ADCs, but one of them is not available when you use WiFi module, because it is reserved for that module, somehow. Apart of that, there are number of publications around internet, that reports about bad performance of the ADC of ESP32. For example: https://github.com/MacLeod-D/ESP32-ADC and https://randomnerdtutorials.com/esp32-adc-analog-read-arduino-ide/. I also experienced that behavior in my own project and ended up adding external ADC.

By the way, excellent project!
I received my order of the assembled MCA and now I will order the SiPMs.
Cheers!

[NuclearPhoenixx]

Thanks for your thoughts, good to know. And of course thanks for the praise ;)

[NuclearPhoenixx]

As an alternative, you can always use an external ESP32 and connect that to the Pico using the UART pins that I've broken out. Power can be taken from the VSYS and GND pins on the detector board as well. It will get all the data that your PC gets, so with that info you should be able to implement most of what you need. Might actually be the easiest solution to get MQTT and similar.

[jbeale1]

For what it's worth, I'm currently playing around with the smaller STM32 Nucleo boards like the STM32L432KC. It's definitely more costly than the Pico but the ADC isn't too bad. This version has a 12 bit 5 MHz ADC and I just got it working to generate some basic spectra, using the analog output from a Measall KC761 spectrometer that I already had. I was lazy and did not even make an analog peak detector circuit, I just did continual sampling (DMA with circular buffer) at about 2.5 MHz and then digital peak finding. Not so suitable for battery power though maybe. My result from a standard Cs137 check source looks similar to your mushrooms-with-fallout curve does (although with less energy resolution, but then the KC761 doesn't have great resolution anyway).

[NuclearPhoenixx]

Yeah, STM32 is a nice microcontroller, I've thought about using that too and 5 MHz is pretty sweet tbh. But they can be a bit of a pain to program and software support with Arduino isn't too great IIRC. And yeah also, they're more expensive like you mentioned, but it's not all too crazy. Maybe looking into some very fast, external ADCs would be a good middle ground, I'll be keeping an eye out for that!