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.