dBC - if you’ve done quite a bit of analysis of the options already then maybe you could point this in a sensible direction.
Assuming we’re really interested in the ADC aspect and the sample rates, which of the many choices would be a sensible starting point? The rest of the processing in an energy monitoring system or solar diversion system doesn’t need much processing power, so I’d think that the ADC aspect would be the most critical to get right.
Personally I’d like to get away from the rfm69 for comms, so for wifi, I’m assuming the simplest solution would be an ESP8266 and also given there is already a openenergy solution for this it seems like a no brainer to go down this route.
I’ve ordered a couple of ‘blue pills’ to have a play around but some of the documentation seems to suggest these haven’t got the best separation of supply to the chip and the analog inputs. Any thoughts on this?
I’m interested in where this discussion might lead too, I have seen the stm32’s mentioned frequently but know very little about them.
What I have noticed is stuff like the great ADC resolution and speeds, plus somewhere I read about 4 levels of amplification on the ADC inputs and I’m pretty sure I seen mention of ADC channel count greater than 8. But I know there are many models and even more dev boards based on those models so ADC characteristics will vary.
Some models also have a UUID which has come up in discussion more than once on these forums.
Absolutely, The best thing to happen to the esp8266 development was to get included in the Arduino IDE, it takes the thought of another language or another development environment out of the equation and more users are likely to try it, it would hopefully also save us reinventing the wheel with much of the existing code.
I agree with this too, improvements can be made and as time goes on if a new tech is fully embraced, the peculiarities and best practices will get well discussed and possibly documented here, so the additional learning curve will be minimized and shared among many Arduino capable users, rather than development racing ahead with only a handful of very advanced enthusiasts keeping up.
Definitely! Having enough ADC channels is important, 10-bit resolution as an absolute minimum and perhaps more importantly is sampling speed. The processor power and memory size are also important and demand an improvement over what we have, but as mentioned the essential “other stuff” we do doesn’t use much processing power.
I can understand that and many of us do want alternative options, but RFM is easily added to any 3.3v MCU with spi so I guess so it can always remain an option. Wifi isn’t that great for battery life and it isn’t flexible enough to be the sole solution for all. Perhaps bluetooth is another possible option to.
This seems to go against all the pro ADC comments IMO, the ADC on the esp8266 is slow and only one channel so almost useless for energy monitoring, you could add an external multiplexer or even external ADCs on I2C or SPI but since ADC’s are THE priority, the esp8266 will never fit the bill alone, when paired with an ATmega328p as per the emonESP it works well enough, but using the emonESP as an example, beyond being a dumb forwarded there isn’t much resource left after setting up a server for WiFi configuration etc so something better is required if using WiFi.
IMO WiFi is very high on the priority list but it’s presence also requires an additional bump up in resources too, unless running a server can be avoided.
I have now, It has a lot of toys wifi, gsm, gps and bluetooth, but it is expensive and only has 3 ADC inputs, so IMO not a real contender at this point.
Arduino seem to be using SAMD21 processors for the zero etc, they are Cortex M0+ based like the STM32F0’s, running at 48MHz. I know nothing about SAMD21 but happened to notice that while the Arduino offerings had 6 or 7 ADC channels, the Sparkfun SAMD21 dev board has 14x 12bit ADCs, although I don’t recall seeing any sampling speeds documented.
Sorry you misunderstood me - I was thinking only of the esp8266 to be the wifi adapter. Not as an alternative to the STM.
As a replacement for the emonTx for energy monitoring and solar diversion I’m not interested in battery power. I would think most emonTxs in these situations have 2 wall warts on an outlet near the distribution board. It’s these systems that could benefit from the faster analog on the STM micros.
emonTH doesn’t need fast analog and can obviously be battery powered.
Oh! fair enough, yes if in-built wifi is not included the esp8266 does make an excellent wifi add-on and it maybe a better solution to use something like an STM32 and provide a footprint and header to “plug in” an esp8266 module rather than including it on every device, with some clever fore thought a device could possibly be USB, WiFi, RFM, BT or Ethernet simply by fitting the module required.
Whilst WiFi is too much for both battery and AC:AC powered emonTx’s. it might be nice to find a solution that CAN be powered via an AC:AC adapter and since BT is the most used wireless comms method for battery devices, it’s more likely to be able to be AC:AC powered. To be able to power an emonTx via one wall wart and “just add it’s BT key” to a file on a Pi would be very attractive to many users, not all granted, but I think it could be closer to what we have now but neater, easier to set up and more secure to boot.
BT is possibly a discussion for another thread, my point being we should avoid opting for another single wireless solution that doesn’t work for everyone, dropping the well established RFM stuff along the way. As attractive as in-built WiFi might be, it might not work for all, just as RFM dosn’t work for everyone now.
I used around 100 emonTx’s in the latter part of last year and not one of them uses the on board RFM, that’s wasted cost in the RFM module, antenna and other components, plus wasted IO resources that are hardwired to redundant hardware, I used serial to USB boards, WiFi might have worked if I had installed a second WiFi adapter to the Pi hub’s but that too would have added additional cost in WiFi adapters and the additional wall warts wifi would demand, so USB was easier. i’m certainly not trying to convert anyone to any particular method, I am keen to promote choices rather than a single “like it or lump it” approach if new avenues are being explored.
Agreed. While I use the ADC in my project, it’s not a critical component (just used to measure a very slow moving low resolution signal) so I haven’t done an ADC comparison across the STM32 families, or across vendors. I went with their low-end F0 family and was blown away by the ADC performance. I assume the higher end families have the same ADC or better. I coded up the 1000 samples delivered to a C array in 1msec more as a proof of concept then to use in my application.
With just a 48MHz CPU, and a new ADC result arriving every usec, that’s only 48 CPU cycles to deal with it, so interrupts on a per-sample basis are pretty much out of the question. All the peripherals are connected to a DMA controller though and it does all the per-sample shuffling into SRAM for you, without any CPU involvement, interrupting the CPU only when the user-supplied buffer is half-full and again when full.
The good news is, if you go for a nice easy synchronous analogRead() approach to doing your ADC conversions like emonlib does, you’re only wasting ~48 CPU cycles while you wait. By comparison, a 16MHz AVR wastes about 1660 CPU cycles while it waits. Bringing the ADC performance much closer to the CPU performance makes that approach a lot more bearable.
Just a heads up on signal impedance. To do conversions in 1 usec you need a nice low source impedance signal (less than 5K from memory). The ADC typically runs on a 14MHz clock. The actual conversion takes 12.5 cycles, and prior to that there’s a software-configurable sampling time from as low as 1.5 clocks (giving you 1usec conversions) to as high as 239.5 clocks (giving you 18 usec conversions). So you can effectively tune the ADC to your source impedance, but at the cost of sampling speed. You’d need to check how the Arduino STM32 HAL configures that. And all those details are for the F0 family, so may or may not apply to other families.
I managed to find a Red Pill schematic, but couldn’t find a Blue Pill. And yes, it had AVDD connected directly to VDD while the STM development boards have a series ferrite bead. They also run AVDD and AGND out on two adjacent pins so you can put the decoupling cap right up against the pins… I couldn’t find that on the Red Pill either. Not having all that means the quality of your supply becomes much more critical. A lot of Arduino manufacturers take similar shortcuts with their AVR designs. That, in conjunction with noisy power supplies, is suspected to be one of the leading causes of “my monitor reads x watts when the circuit is switched off” complaints.
Whilst discussing the Arduino Due on another thread I took another look at the specs and even they are 84MHz Cortex-M3 based MCU’s with 12x 12bit ADC’s, which (although I can’t see it right now) I seem to recall reading somewhere was capable of a sample rate of 1MHz, which if that is the case, would mean it can run all 12x 12bit ADC’s around 30x faster than the emonTx can run 5x 10bit ADC’s, if I’m not mistaken. Not quite on par with the STM’s, but possibly an easier transition??
Actually, I think that’s on par with the STM32, at least the one I’m using. 1MHz and 1usec are just inverses of each other right? I just did a quick timing test of analogRead() on my Due and it takes a little under 5 usecs… still a lot better than the AVR’s 110 usecs. You’d need to poke around in analogRead() with the SAM datasheet in hand to see why it’s not 1 usec… could be they’ve slowed it down for source impedance issues like I described above for the STM32. I’d look but I don’t think I’ve got room in my head for a third ADC architecture, and don’t want to lose the two I’m still using (AVR and STM32 ;-).
From a compatibility point of view, I think the Due would be a great way to go. The only downside is it seems to be a discontinued product. No idea why.
It’s probably worth distinguishing between the number of ADCs the device has (typically 1 or 2) and how wide the MUX is that’s in front of them (often 12 or higher), which I think is what you’re referring to there. Now those that do have 2 ADCs almost all have a way of triggering synchronised conversions. Rather than starting one and then starting the other, which would introduce at least a few CPU cycles of lag, you can arm each of them, and then with a single write say “START”.
Utilising that in an OEM product would eliminate one source of phase shift as you could dedicate one ADC to the V (or Vs in the case of 3-phase) and the other to the CTs (always choosing the correct V for a particular I). Of course you won’t be able to do that if you’re sitting on top of the classic analogRead() HAL but it’s a potential performance tweak that extreme power-geeks could add later.
I should have added this on my earlier posts, but I was thinking of the emonESP as the solution for the comms. Which if you followed that protocol I guess you could design rfm69 and BT options although obviously these would need processors and code to the receive and retransmit which would put the price and complexity up. emonESP is already there so a good solution.
dBC, here’s a wiki with all the various ‘pills’ → STM32duino wiki.
This is actually a great entry point as alongside the Boards section with the schematics, poinouts etc. there’s also info on the bootloader, arduino installation, uploading sketches and the libraries as well as a link to the community forum.
Simon
EDIT
Paul, thanks for the link, now you mention it I remember that discussion. If you follow the link to Roger Clark’s post in the STM32duino forum you’ll see that he has already been there and done that so to speak, including thinking of using the ESP to transmit the data.
I believe so, but I guess since the Due has 12 ADC inputs whilst the common STM32’s seem to have 8 would give the STM32’s the edge to tune of 125KHz verses 83.3KHz per input (assuming both devices to be single ADC’s), and at the time of writing I wasn’t so sure the 1MHz quoted was for the 12bit resolution as I read it’s 10bit by default to match the AVR Arduino’s, so in my mind there was some ambiguity over whether the 1MHz was valid 12bit op,
Having now took a brief look at the headlines on the Atmel datasheet, it appears to have the 1x 1MHz 12bit ADC and it actually has a 16channel MUX, I assume Arduino have made the choice to only break out 12 of those on their Due board.
I went looking for the info after reading an interesting article that stated the Due has 16 ADC’s.
2 ADC’s could well be a really good feature to look for, I don’t think the STM’s or the SAM.
Other considerations I’ve noted are the Due doesn’t seem to have an eeprom which is a bit disappointing, but it does have a RTC which could be very useful. The SAM3X also seems to have “programmable gain stage” ADC inputs although I find no mention of such on the Arduino spec’s.
I was aware it was “older” tech but it does seem to still be a current model, sometimes a tried and test tech can be a better route than bleeding edge tech that imposes a steep learning curve and lots more trial and error.
I feel I should point out I am not suggesting we consider using the Due itself, other than just an evaluation board for that MCU, much like the current emonTX is not actually an Uno. Plus I am not pushing this particular MCU option either, rather it is just another idea thrown in the ring for discussion.
Both the wiki page’s for the red pill and the blue pill state “Analogue power and ground is connected directly to digital power and ground, which can cause additional noise on the ADC input.” as known issues, so possibly not a great starting block. perhaps for proper evaluation there is a better choice of board? I notice some of them even have Arduino connectors so that Arduino shields can be connected directly, but care for the 3.3v/5v differences still need to be observed as many shields may be set up for 5v Arduinos.
EDIT - the NUCLEO-F072RB STM32-F0 evaluation board isn’t that expensive.
Sounds like this is the kind of thing you’re speaking of:
With analogRead(), you can measure many signals, but only 1 at a time. Teensy 3.2 & 3.1 has a second ADC, so you can concurrently measure 2 analog signals. For stereo audio or power monitoring, sampling both left and right, or voltage and current at the same moment is very beneficial.
The processor is a ARM Cortex M-4 MK20DX256VLH7, but the downside as dBC has mentioned, is the issue with analogRead()
If a person wanted to tinker, a library that supports synchronous ADC operation is available.
The Teensey v3.6 seems to have 24x 16bit (13bit usable?) ADC channels across 2 ADC’s, (I really hope their software is easier to navigate than their website!!)
Actually, even many of the old AVR based Arduinos like the Mega2560 I use have that. The Arduino HAL only supports the basics, if you want to use the more powerful features you need to bang on the h/w registers directly.
Absolutely. Last time I looked at the Due page it had a big “Discontinued Product” stamp on it and the Italians had announced they were going to stop producing them. But in any case, in this thread Bill reveals the Chinese will be making them probably forever regardless of where the Italians settle.
Whether you go with the NXPs Bill found in the Teensys above, the Atmels found in the Due or the STM32s probably doesn’t much matter. They all seem to have landed on very similar ADC specs (1 usec 12-bit conversions at the least).
Do any of you have a link to the specs for the ADC on the ESP32. I can’t seem to find any detail anywhere. Probably using the wrong giggle search words. The ESP32 should also be a contender, especially as WiFi and BT are baked in.
