IotaWatt Sample Rate

Hi Everybody,

I have a question on the sampling rate of the IotaWatt. Currently my setup is a Iotawatt that is pushing its data to a Raspberry Pi with a local emoncms server installed. This data gathered by Node red and sent out to a server.

So my question is why is it that there is a 30-40 inputs samples per second frequency speed but am only getting a data point every 5 seconds or so. Basically what is the actual sample speed of the IotaWatt and amount of data being collected by the iotaWatt.

To clarify, you are getting up to 15 datapoints every 5+ seconds, corresponding to the number of active channels. The 30-40 channel sample rate is individual channels.

But to your question: When IoTaWatt samples a channel, it samples one AC cycle. The resulting power and voltage are recorded and the samples for each channel are averaged with millisecond time weighting. When it comes time to make an entry in the datalog (every 5 seconds) the accumulated average is recorded. This methodology accurately accounts for variations during the posting interval and minimizes the influence of transients. Also, by oversampling, there is a statistical case for increased the accuracy beyond the resolution of the hardware.

The posting to a server is a slave process that reads the datalog and posts the data to the server. That’s why IoTaWatt can recover from long communication outage. Trying to update a server real-time is problematic, especially when the communication link is slow or error prone.

There is also the issue of what exactly is being posted. Unless you tell Emoncms what time the data represents, it assumes it represents the time from the last update until this update. But the resolution is only to the second. So I’m not sure what it would do, even if IoTaWatt could send it 2 or 3 samples per second, not to mention the storage that would be needed for that much data.

IoTaWatt timestamps the data that it send to Emoncms (or any other server if allowed in the protocol). Again, that timestamp is “unixtime” which has one second resolution. So the smallest viable datapoint is one second.

Then there is the issue of communications. It can take up to one second to send a data packet. On a good day it takes at least 250ms. During that time, no sampling is taking place. So posting every sample, or every set of 15 samples, would take from a minimum of 650ms to possibly a couple of seconds. Let’s say one second. So you get a sample every second that represents the analysis of one AC cycle of that channel. Logging the average every 5 seconds, You get the average of about 12 AC cycles during that period.

Not sure why the question anyway. The device is a power meter, and 5 second resolution seems a pretty good resolution. The current software is structured to do that well and robustly with respect to reporting it out. If you have a need for a real-time stream of samples, you could adapt the hardware with your own code. There’s very little demand for sub-5-second reporting. Most folks seem content with 10 seconds.

Hey Bob,

Want to thank you for that response. It was incredibly useful information at understanding the method used by the Iotawatt.

Our application however does have a need to have a higher sampling rate for faster paced machines, and would like to therefore know where in the firmware code we can change the sampling speed/ and or sample quantity per second. We are looking to send a message to the server close to every second.

What do you recommend we do if we would like to achieve this type of resolution?

Fork the code and have at it. What you want to do would be a fundamental change in the architecture of the firmware. My time and commitment is to the set of people who find the current device useful. I’ll be interested to see what you come up with.

Another option might be to simply issue a status API every second and get the current damped power values for each channel. That’s what the app is doing when the status screen is being displayed and updated approximately once per second. If you have an IoTaWatt, try issuing it from a browser:


The response is Json. Maybe your requirements are as simple as that.

I got the EmonPi to sample at 1 second. This did not require any significant “software architecture” changes or black magic. I just had to change the interval that the ATMEGA is sending samples over serial to the Pi for logging. Everything else just trickles through magically.

To get there, login to the EmonPi via Putty or whatever SSH terminal you have.

enable editing: rpi-rw
go to source directory: cd emonpi/firmware/src/
edit file with nano: nano src.ino
“if ((now - last_sample) > TIME_BETWEEN_READINGS)” to “if ((now - last_sample) > 1000)”

back one directory “cd …”
compile sources as admin and program ATMega “sudo pio run -t upload”
if curious check to see serial output “pio serialports monitor -b38400”
select “1”
to exit “ctrl + ]”
login to emoncms
check feed

you might have to adjust your start time if it has been logging in intervals other than 1 sec. It will error. So adjust the time to be closer to the end time. set limit to 1, fix checkbox and reload.

You can click on the csv to check the data.

if you want very fast data you can try my method UDP streaming the RAW out put from MCP3XXX devices to your server … it works fine and I can sample all inputs at 1/2 second intervals if you like or greater . my device is not the iotawatt but it similar in construction based on arduino format to fit wemosD1 so it interchangeable between arduinos and wemosd1. so you need to modify ino to match yours. I used the emonlib firmware as reference for processing the data locally but you can use iotawatt as reference if you like and build based on that…

the reason I like the UDP push method I can visualize the via oscilloscope and energy monitoring all in the same instant. though currently it operating on a esp I probably convert it to work on wire instead of wifi at some point