Archived Forum

Hello Eric, your not missing anything, it would be good to add this to the discrete sampling sketch. The frequency of pulse counting is usually quite slow and the time request to process an interrupt relatively short, I dont think it would affect the time elapsed significantly but I haven't tested it.

Hi,

Ok , it will try to implement that. There is a real need.

The frequency of pulse counting can easily reach 10 Hz on buildings I'm monitoring (36 kW + 1 pulse/1Wh = 10 pulses/second). I have no idea about the time request to process an interrupt (the ISR is quite short), but one can assume that it may affect significantly the time elapsed between two sent.  Any opinion on that point ?

Correct me if I am wrong but one can't measure the exact elapsed time between two sent with millis() or micros() because these functions are not incrementing during an ISR.

So the solution would be to set up a timer interrupt to calculate kWh and send data at very precise rate. But I don't know if timer interrupt and pulse interrupt can coexist in the same sketch. I don't know either how to make the emontx sleep at low-power between two sent.

Some inputs ?

Hi,

Finally, I added the Wh totals calculation in  the emonTxV3_2_DiscreteSampling sketch (sorry, I have no TX3.4) simply by measuring the exact elapsed time between two calculation with millis().

First, I modified the emonTX payload :

typedef struct {
int power1;
int  power2;
int   power3;
int   power4;
int   Vrms;
int   temp;
float wh1;
float wh2;
float wh3;
float wh4;
} PayloadTX;     // create structure - a neat way of packaging data for RF comms
  PayloadTX emontx; 

Before calculating power and energy, it measures the time since the last calculation

 lastTime = calcTime;        //used to measure time between Wh calculation.
 calcTime = millis();
 elapsedTime = calcTime-lastTime;
 if (debug==1)  {Serial.print(elapsedTime);Serial.print("  ");}

Then it calculates the totals Wh just before updating the power like this :

ct1.calcVI(no_of_half_wavelengths,timeout);
emontx.wh1+=((ct1.realPower+emontx.power1)/2*elapsedTime/1000/3600);
emontx.power1=ct1.realPower;

As I will not try to catch interrupt with the same TX, nor try to measure temperature, it should work fine.

Doing that, I noticed that the real time between two sent is 11,2 seconds + few ms whereas the constant TIME_BETWEEN_READINGS was 10. When logging data every 10s in emoncms, many data are lost (10%). It can be problematic when using some process/grah

200 ms are "lost" here :

 delay(TIME_BETWEEN_READINGS*1000);
 digitalWrite(LEDpin, HIGH);
 delay(200);
 digitalWrite(LEDpin, LOW);    // flash LED - turn off to save power

One second is lost anywhere else (during the sampling ?)

So, I made some modification to get a time between two sent equal to 10s + few ms.

A good solution would be to set up a timer interrupt to calculate kWh and send data at very precise rate. Will it work with pulse counting or temperature sensing ? I will have a look on that later.

Eric

Eric,

TIME_BETWEEN_READINGS is actually the delay while the processor sleeps in low power mode (as you've discovered). The extra time is that taken to make the readings (200 ms per CT) plus the time to calculate the averages and process the result, get the temperature (if required), print the results to serial (if you're doing that) and to send the data.