I don’t think you’ve ever said which sketch you are using, so I assume it’s the standard default one. I also seem to remember that you’re using an ESP8266. But I do not know how the “quality” is calculated.
However, the standard sketch measures each active c.t. in order for 200 ms (in your case, I think that’s 1 & 4), parcels that up into a data packet that carries all 4 c.t. powers, voltage, 6 temperatures and the pulse count, and sends the whole lot to the ESP.
The output statements in your emonTx sketch look something like this:
if (DEBUG==1) {
Serial.print("ct1:"); Serial.print(emontx.power1);
Serial.print(",ct2:"); Serial.print(emontx.power2);
Serial.print(",ct3:"); Serial.print(emontx.power3);
Serial.print(",ct4:"); Serial.print(emontx.power4);
Serial.print(",vrms:"); Serial.print(emontx.Vrms);
Serial.print(",pulse:"); Serial.print(emontx.pulseCount);
if (DS18B20_STATUS==1){
for(byte j=0;j<numSensors;j++){
Serial.print(",t"); Serial.print(j); Serial.print(":");
Serial.print(emontx.temp[j]);
}
}
Serial.println();
delay(50);
}
My initial approach would be to take out all the unused variables and see what the effect is.
Some years ago, we had problems with the RFM modules when it was decided to send 6 temperature readings, because the long serial stream of 0 bits allowed the two clocks to drift out of sync and the checksum failed (and it’s resurfaced with 4 ‘long integer’ energy values and emonLibCM). There’s no checksum on the serial link between the emonTx and the ESP8266, but I wonder whether you have the same problem. If you have, taking out the unused variables should cure it. This might explain also your 12 kW spikes.
You might not need to amend your processing in emonCMS to cater for the change, if you’re sending the data labels (“ct1:”) as well as the data.
