Great site, I’ve had a lovely time building a current monitor based around an ESP8266-12E Devkit, setting up MQTT and node-red and all good. Now I want to monitor voltage as well to determine direction of current flow. Got all the bits, about to build and realised the devkit has only one analog input.
I’m wondering if I can build a magic sort of electronic 2 way switch. (see instructable Multiple-Analog-Inputs-on-Only-One-Analoge-Pin).
So, maybe two digital output pins to determine which of the two possible analog inputs is connected.
I’ve got things like a 4N35 optical isolator, or a bunch of PN2222 transistors.
I’m worried if I just start connecting things up I’ll damage something!!!
Any advice / guidance / don’t do it appreciated.
You could certainly try using an analogue switch to select one of two inputs - that’s exactly what is done inside the processor in the emonTx. But doubts have been expressed about the accuracy of the ADC in the ESP8266, and I think by far the best way would be to use an external multi-input ADC, which you control from, and feed the information to, the ESP in digital form. I believe the Iotawatt (which too should be Open-Source and so circuit diagrams etc should be available) works on that principle.
… which probably means it’s of limited use for our purposes. (And if it doesn’t do the job you want it to, it wasn’t cheap.) Ioatwatt runs the ADC much faster than is necessary for a single channel, so as always, there’s an engineering compromise somewhere in the middle.
And it depends on whether those numbers are genuine per channel, or whether there is a multiplexer on the front of the ADC.
The basic assumption, which Tony has stated, is he’s got two channels. To record up to the 13th harmonic (650 Hz), he needs an absolute minimum of 1300 samples/second. If he’s reading two channels pseudo-simultaneously, selected by a multiplexer like the 328P does, he needs 2600 samples/second.
I believe revenue-grade meters here cut off around 2 kHz (39th harmonic).
Well, datasheets need to be reviewed and parts need to be evaluated to determine their applicability to any particular purpose when designing a “real” product. This post said nothing about the application, so I had to guess. The OP said he was using the ADC in the ESP, which is a generally bad idea, so probably not someone with a lot of experience in this area.
Many people don’t understand all the tradeoffs and how the requirements of the project impact them. The ADS1115 is a very popular ADC with people doing Arduino projects and is readily available in a breakout, which makes it really easy to use. I did say it was slow, so definitely not suitable for measuring 50-60Hz power consumption accurately.
I am not sure what your concern with the MCP3208 is. You first seemed to be suggesting by referencing its use in Iotawatt and then in your next post seem to saying it is overkill for a single channel (since Iotawatt has 14 current channels and uses one MCP3208 for 8 channels, that seems like a strange statement, that I don’t know how to interpret).
Based on your last post, I assume that you believe that using the MCP3208 for two channels (one voltage and one current) would actually be an okay choice. I suppose I can infer that using the MCP3208 for 8 channels like Iotawatt does is not a good choice, because it can’t go out to 2KHz or even 650Hz.
From a technical perspective I can agree with that. I have a bunch of energy metering ICs in box on my bench that would probably could be much more accurate. But, I doubt that I will ever find the time to actually design a circuit board and solder them together and write the FW to talk to them. So the good enough solution of Iotawatt works for me. It gives me a pretty good approximation of my power consumption on many circuits. With it, I have been able to identify several areas where I need to make changes in my other devices. Is it the perfect solution? No. Is it good enough for what I need and can afford? Yes.
I think we determined in this thread that when measuring a channel, the IotaWatt definitely doesn’t lack bandwidth, at least while it’s looking at that channel. It goes almost all the way out to an extraordinary 20KHz. The downside is it only looks at every 25th cycle of each channel.
If you don’t have enough ADC horsepower for the job at hand you have to make compromises. Here the design choice is whether to reduce the per-channel sampling rate (and hence the bandwidth) Vs skipping cycles altogether. I would have gone with the former (especially with the bandwidth currently sitting out at ~20KHz), IotaWatt went the latter… but each to their own.
If you don’t want to be conflicted by that compromise at all, consider something like this. From the moment it first syncs to zero crossing, it measures every cycle of every channel forever, no exceptions. That’s 15 I and 3 V channels at 8,376 (V,I) sample pairs per second per channel and it’s not even breaking into a sweat. That’s actually pretty close to the rates my energy IC based monitor runs at. It does all it’s work at 8000 sample pairs per second per channel (albeit 24-bit samples instead of 12-bit) and even then, only claims 2KHz bandwidth. I guess they’re leaving themselves plenty of headroom there.
I’d like to point out that the we referenced above does not include me. I was censored. I had posted a rebuttal to the suggestion that frequent random sampling was inaccurate and pointed out that it was lacking practical evidence. At first they changed the subject to this oversampling argument, then removed my post completely.
Regarding the oversampling argument. I get that there is no significant energy in the harmonics and that capturing them does little to the prima fascie power measurement. The reason for high sample rates in IoTaWatt has nothing to do with that.
After following this forum for some time, I came to understand that the bulk of the discussion at the time (2017) was about how to connect different CTs and VTs and how to calibrate for better results. The solutions almost always required the user to recompile the firmware and upload it to the Arduino. I thought there could be a better way and that a plug-and-play solution was due. As a programmer rather than an electronics guy, I could see the forest.
One major design goal was to be able to use any VT and any combination of CTs in the 14 inputs without the need to reprogram. This required a different approach to phase correction. The buzz at the time was a paper that described a method that I think may still be in use in some of the Emon devices. I’m not finding fault with the method as used, but it doesn’t really lend itself to the any-to-any approach. That paper starts out by explaining that the method described is needed if resolution of the samples is not fine enough to correct phase errors by simple sample shifting.
So, IoTaWatt’s per-cycle sample rate at 50Hz is about 760 sample pairs per cycle. That translates to .47° per sample. If the net phase shift between the VT and CT is known, the voltage and current sample arrays can be shifted to align within an average of about .24°. IoTaWatt goes a step further and does a linear interpolation for the fraction, but I’ll concede that may be overkill.
Contrast that with a device that is taking maybe 50 samples per cycle or 7.2°. To correct a typical 1° or 2° net, some form of interpolation must be used. I recall a discussion where a seemingly knowledgeable contributor found fault with the linear method being used. I think it was purely academic and didn’t go anywhere.
I understand that the STM project is looking at using time-delays to accomplish the correction. That may be the holy grail but the devil is in the details when there is so much going on and the CT shift is changing with load.
I’ll reiterate that I think the argument for sampling every cycle vs two per second is overkill. Even when the individual cycles vary, and that is rare, random sampling will capture the average within less than 1%. There is a tendency to worship these technologies as if they make or break the effort when there are so many other important criteria like cost, ease of use, reliability, upgradeability, and complexity.
Alas, that never got off the ground… it was not flexible enough as it only really works in a one-size fits all way (although it’s still what’s used by the emontxshield demo tarfiles).
I’m not sure what the current plan is there, but I suspect the techniques used in EmonLibCM V2 are probably as good as it gets in that space. Although the techniques used in emontx3-continuous are no doubt worth a look too.
By way of reference, the energy ICs I use use a digital all-pass filter to introduce a time delay. The LSB of the register used to configure that time delay adds about 1x10-6 degrees phase shift, and there is of course one per channel, and being an all-pass it doesn’t molest the signal at all, just shifts it.
What I will say is I have two IotaWatts and I like them and find them useful. I believe they are way better than the Brultech ECM-1240 I was using. The main channels on it weren’t too bad, but the five auxiliary channels would read zero when my generator was running. Even with that significant issue, I found the ECM-1240 helpful. It gave me my first insights into how expensive my heated floor is (and my furnace which is also the blower for fresh air circulation, required by our energy code). But, the ECM-1240 software support was very primitive and it was hard to view the data and it was slow to do too, and it wasn’t open source so it was nearly impossible to improve much. I found emoncms when I was looking for something cheaper after smart energy groups implemented a pricing policy that was significantly higher than the value I got from it.
Since I knew I wanted more channels, I was planning on building my own with a bunch of energy metering ICs. But, I never found the time to actually make a device. I looked at the GEM from Brultech, but I was not convinced it wouldn’t have the same issues as the ECM-1240. I then found the IotaWatt. It had a decent number of channels and I thought it was reasonably priced for the value it provided. After having spent more time using it with different CTs and VTs, I have to say from a usability point of view, Bob has done an excellent job. From time to time I read some of the posts and the trouble that people have to go to use a different CT with and emon-something and while I know that I could do that, I like the simplicity of IotaWatt.
I also think emoncms is great and willingly pay for all the channels I am using. While I have plans to move much of it locally, I have not been in a hurry to do it as I see value in the service.
But, this discussion has moved way off topic and is sounding a little more like this one: