Archived Forum

Yes, both MartinR and Calypso_rae have published sketches that measure frequency.

http://openenergymonitor.org/emon/node/1535

Robin's Mk2 Code variants and associated tools.

Awesome code for frequency and all the power parameters.

Looking more for adding frequency code to emonlib.cpp

It already utilizes code to access the crossings as below..

Can you tell me how to add the code to calculate frequency using crosscount?

while I'm here can a "auto reply notify" check box be added to this forum - would help.

I have used pulseIn(), but it seems to have a drift - 

Here is my frequency coding - i hope to get rid of this code anduse the emonlib.cpp crosscount as a counter of zero crosses

Hoping someone can assist.

*****************************************************************************

 //******************************
  //Frequency smoothing
  //******************************
    // subtract the last reading:
  total= total - readings[index];        
  // read from the sensor: 
  //readings[index] = analogRead(inputPin);
  readings[index] = pulseIn(inputPin,HIGH);//HIGH gives best fit
  // add the reading to the total:
  total= total + readings[index];      
  // advance to the next position in the array: 
  index = index + 1;                   

  // if we're at the end of the array...
  if (index >= numReadings)             
    // ...wrap around to the beginning:
    index = 0;                          

//************************************
//end smoothing Routine for Frequency
//************************************

  // calculate the average:
  val = total / numReadings;  //Frequency raw counts

Serial.print("  Freq= ");
  Serial.print((1000/((val*2/1000.0)-freqerror)),2); //frequency - freqerror is the calibration devised to setup
 

Any mistakes?? Please let me (and everyone else) know.

******************************************************************************

emonlib.cpp extract for crosscount follows

******************************************************************************

// emon_calc procedure
// Calculates realPower,apparentPower,powerFactor,Vrms,Irms,kwh increment
// From a sample window of the mains AC voltage and current.
// The Sample window length is defined by the number of wavelengths we choose to measure.
//--------------------------------------------------------------------------------------
void EnergyMonitor::calcVI(int wavelengths, int timeout)
{
  int SUPPLYVOLTAGE = readVcc();
  int crossCount = 0;                             //Used to measure number of times threshold is crossed.
  int numberOfSamples = 0;                        //This is now incremented 

  //-------------------------------------------------------------------------------------------------------------------------
  // 1) Waits for the waveform to be close to 'zero' (500 adc) part in sin curve.
  //-------------------------------------------------------------------------------------------------------------------------
  boolean st=false;                                  //an indicator to exit the while loop

  unsigned long start = millis();    //millis()-start makes sure it doesnt get stuck in the loop if there is an error.

  while(st==false)                                   //the while loop...
  {
     startV = analogRead(inPinV);                    //using the voltage waveform
     if ((startV < 550) && (startV > 440)) st=true;  //check its within range
     if ((millis()-start)>timeout) st = true;
  }
***************************************************************************************************

end of emonlib.cpp extract

***************************************************************************************************

Thanks all.

This might help anyone trying to use my frequency code

It goes in the sketch header (above setup()

//****Frequency setup**********************************
const int numReadings = 6;// Frequency samples # of half waves samples

int readings[numReadings];      // the readings from the analog input
int index = 0;                  // the index of the current reading
float total = 0;                  // the running total
float val = 0; // the average
//*****END FREQUENCY SETUP*****************************
 

Firstly, frequency is defined as the number of cycles in a unit of time. I can't see where you are measuring time, and I can't see where you are trying to relate time to the number of cycles. What is inputPin connected to? You need to check what PulseIn( ) actually does, and think what HIGH and LOW mean - especially in terms of an analogue signal. It doesn't do what you seem to think it does.

Secondly, you will most likely suffer a lack of accuracy if you stay with emonLib. The reason is, the time to execute the loop is dependent upon the ADC, so as the crossing is detected only once within the loop, and it is not synchronous to the mains frequency, there will be a large amount of jitter if you time the loop. Clearly, if you time many loops, the amount of jitter will decrease in proportion, but it will still be present.

MartinR's phase locked loop adjusts the divider for the clock frequency of the processor to synchronise itself exactly with the mains, so the jitter is very small - as you can see if you run the code, the voltage at the crossing (which should be zero if the loop is exactly synchonous) changes by only a few volts, representing less than 50 µs and typically about 10 µs jitter. Compare that to emonLib that typically takes around 400 µs per input pair (V & I) to execute the loop.

My frequency code

#define inputPin 2  // hardware connect to a 1K resistor off the Voltage divider feeding the Voltage for emonlib

The output line below adjusts for error (calibrates per wavelength) and calculates frequency using 1000 milliseconds as the timebase.

val is the time per half cycle multiplied by 2 to get one cycle, adjust for error and calculate pulse timing in one second.

This line takes a number of readings(pulses) - take as many as you like but it slows down the loop, NOT the measurement accuracy.

const int numReadings = 6;// Frequency samples # of half waves samples

Serial.print((1000/((val*2/1000.0)-freqerror)),2); //frequency - freqerror is the calibration devised to setup

The frequency stays within +-0.1Hz

************************************************

freqerror is the calibration devised to setup

can you explain that?

Sorry, Platypus, but while your idea is good, the way you have converted it into code is wrong. Unless I am mistaken, you are taking part of the voltage wave and using pulseIn( ) to time the period when the input is high. That depends on the amplitude of the voltage wave and where the processor input decides that it will be "HIGH" and "LOW". Normally, "HIGH" is when the input  is above 0.7 x Vcc  and "LOW" is when the input is below 0.3 x Vcc.  Both these points will move along the wave as voltage changes, and they also depend on the d.c level. They might not be symmetrical about the true midpoint of your input wave. Therefore, you are not timing a true half cycle. Also, there is no guarantee that your wave is truly symmetrical, so the two halves might not be exactly equal. PulseIn( ) is designed for timing pulses with square edges, not sine waves. I think that is the reason you need freqerror.

Ah, I see what Platypus is doing now Robert, using the digital pulse input as a crude zero crossing detector on the analogue voltage input. As you say, quite clever but not very reliable. I suppose it might work reasonably well if you only used one edge.

How about this for a better solution...

Instead of using a digital input to detect a point in the waveform, use the analogue comparator in the ATmega. By connecting one input to the band gap reference and the other to the a/c input pin you can get a very consistent sampling point in the waveform. The output of the comparator can be used to trigger the input compare register in timer 1 so you can get a direct reading of the cycle period.

Here’s the code I used to test this...

float measureFrequency(byte pin)
{
  word count;
  byte oldADCSRA=ADCSRA;
  byte oldADCSRB=ADCSRB;
  byte oldADMUX=ADMUX;
 
  bitClear(ADCSRA,ADEN); // disable ADC because we are using ADMUX
  bitSet(ADCSRB,ACME); // enable ADMUX for comparator
  ADMUX=pin; // select pin for comparator -ve i/p
  ACSR = _BV(ACBG) | _BV(ACIC); // enable comparator to trigger timer 0, band gap is +ve i/p
  TCCR1A=0; // timer 1 normal mode
  TCCR1B = _BV(ICNC1) | _BV(CS11); // enable noise canceller, /8 prescaler
 
  noInterrupts(); // so we don't get delayed by other interrupts
  bitSet(TIFR1,ICF1); // clear i/p compare flag
  while(!bitRead(TIFR1,ICF1)); // wait for comparator (this will freeze if no a/c)
  count=ICR1L | ((word)ICR1H<<8); // get start timer count
  bitSet(TIFR1,ICF1); // clear flag for next comparison
  while(!bitRead(TIFR1,ICF1)); // wait for comparator (this will freeze if no a/c)
  count = (ICR1L | ((word)ICR1H<<8)) - count; // get period of cycle
  interrupts();
 
  ADCSRA=oldADCSRA; // restore ADC state
  ADCSRB=oldADCSRB;
  ADMUX=oldADMUX;

  return 2000000.0/count; // timer frequency is 2MHz
}

Call this function, passing the analogue pin you want to test, and it will return the frequency in Hertz measured over a single cycle.

The resolution is 500ns and it seems to work pretty well without any averaging, although you’d probably want some smoothing for display purposes.

-martin

edited to correct prescaler comment

Thanks Martin, I tried your code but couldn't get it to work.

Could you post the complete sketch please.

If anyone can extract the frequency only from the attached file I am sure we would all be grateful.

You need to click "List" when you attach a file, else we cannot see it. I've done it for you.

And I think you need to read the sketch carefully. If I look in sendResults( ) I can quite clearly see these lines:

  Serial.print(" ");
  Serial.print(frequency);
  Serial.print(" ");

and it seems to print the value for me too

506 513 508 257.56 3.53 0.02 0.00 50.07 300.00 0.11 PLL is locked
 

I can't get Martin's measureFrequency( ) to work either, he knows and he will look at it later.

platypus,

We've solved Robert's problem with my code, it was due to noise and I think that it's unlikely you are having the same problem.

The rest of my sketch is just...

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  Serial.println(measureFrequency(2)); // 2 is the analogue pin for the a/c input, you may need to change this
  delay(500);
}

For this sketch to work the a/c input needs to be referenced to Vcc/2, as it is in emonTx, and the amplitude of the a/c signal needs to be large enough for it to cross the 1.1V band gap reference value. Ideally this crossing should be during the steep part of the sine wave, so a large signal is better.

I suspect that the reason it doesn't work for you is that the 0.5V you are using isn't large enough for the signal to cross the 1.1V threshold. There are two things you could do to remedy this, either change your resistor divider values to get a larger signal or use a different reference voltage for the comparator.

The best reference voltage to use  is the centre of the bias circuit that your a/c signal is connected to i.e. Vcc/2. This will then trigger the comparator at the true zero crossings. To do this you need to connect a wire from the ATmega328 AIN0 input (pin 12) to the centre of the resistor divider in your bias circuit.

You also need to change the sketch to stop using the band gap reference as follows:

change ACSR = _BV(ACBG) | _BV(ACIC); // enable comparator to trigger timer 0, band gap is +ve i/p

to ACSR = _BV(ACIC); // enable comparator to trigger timer 0, AIN0 is +ve i/p

This sketch just measures the period of a cycle, as yours does. The difference is that it measures a whole cycle rather than an indeterminate part of a cycle and so doesn't need freqerror to compensate for the unknown fraction of a cycle that you are measuring.

Or you could just use the PLL sketch as Roberts suggested....

Martin

My problem appears to have been noise pickup from my laptop's power supply (which is not earthed so the laptop floats at around 100 V a.c.)  So it would be worth checking for noise on the a.c. voltage reference.

If I'm reading the data sheet correctly, the hysteresis of the comparator is about 0.33 mV with a 3.3 V supply (Figure 29-27) so without a low-pass filter of the hardware kind, I think this method could well be problematical. Putting that number into some kind of perspective, the noise only needs to be 0.01% of the signal and potentially you have a problem.

On the other hand, Martin's PLL is rock solid and faithfully follows mains frequency variations.

[Edit]
A 1 nF capacitor in parallel with the 10 k resistor of the voltage input divider suppresses the noise for me and gives steady readings, but introduces a small (< 0.2°) phase shift that can easily be corrected by adjusting the phase calibration.

Thanks Robert for the amplitude idea - will change my divider which is at about 0.5Vrms right now - how far above 1.1Vrms would you recommend - would 1.5Vrms do?

I am using the Vcc/2 on each of the voltage and CT dividers - my Vcc is 5V

Must be some confusion, but I had no problem running the emontx sketch, just Martins sketch - no output function..

I need a short form of the emontx sketch, just to measure frequency in a PLL - any ideas on how to extract just the frequency code? 

If you are running your processor at 5 V, then you want your a.c. input voltage to swing to 5 V peak-peak at maximum supply voltage less an allowance for resistor tolerances. So about 1.4 V rms seems a good number to aim for. 1.5 V gives you 15% spare, 10% for voltage tolerance leaving 5% for 4 resistors. It should be OK with 1% resistors in both the divider and the bias, but it is close (see ACAC Component tolerances for more information on how tolerances affect the design).

(It was MartinR who saw that your voltage input was too small.)

MartinR published a frequency-only sketch while he was developing the full controller, here http://openenergymonitor.org/emon/sites/default/files/phase_lock_50hz.ino

ooh - I'd forgotten about that :) Well remembered!

Well nice work Martin and Robert - I will try this.

Up to now I had not needed to look into the ADCSRA and band gap as it is complicated, although obviously useful.

But as you said we probably don't need to reference to 1.1V but rather an aref of 2.5V might be fine.

emonlib does seem to use the 1.1V though as here in emonlib.cpp (at the end of the code)

long EnergyMonitor::readVcc() {
  long result;
  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  delay(2);
  ADCSRA |= _BV(ADSC);
  while (bit_is_set(ADCSRA,ADSC));
  result = ADCL;
  result |= ADCH<<8;
  result = 1126400L / result;
  return result;

Will try your code Martin and hopefully there is no conflict with this code as above - would you have some description of this bit of code - yes its a good learning exercise.

Even though the emontx (for solar) sketch does give a nice PLL frequencythe sketch is way too large to use just for frequency. Will also look at your code link Martin.

 You have both been quite helpful, thanks.

I think many others might have learned quite a bit from this so far.

Nice frequency sketch Martin

I couldn't wait until morning so I ran your sketch, as is, Martin, just to see what would happen without making the adjustments.

Have yet to make the changes as per your post on 8-6-13, 3:07

Well at least its attempting to work.

Here is some data direct from the serial monitor

Frequency = 400000.00

Frequency  1000000.00
Frequency  400000.00
Frequency 666666.68
Frequency 49.98
Frequency  1000000.00
Frequency  1000000.00
Frequency 1000000.00
Frequency 1000000.00
Frequency  500000.00
Frequency  367.65
Frequency 50.20
Frequency  50.12
Frequency 1000000.00

This is the complete sketch - changes yet to be made:

/*
Frequency measurement
by Martin Roberts, 9 June 2013
*/

float measureFrequency(byte pin)
{
  word count;
  byte oldADCSRA=ADCSRA;
  byte oldADCSRB=ADCSRB;
  byte oldADMUX=ADMUX;

  bitClear(ADCSRA,ADEN); // disable ADC because we are using ADMUX
  bitSet(ADCSRB,ACME); // enable ADMUX for comparator
  ADMUX=pin; // select pin for comparator -ve i/p
  ACSR = _BV(ACBG) | _BV(ACIC); // enable comparator to trigger timer 0, band gap is +ve i/p
  TCCR1A=0; // timer 1 normal mode
  TCCR1B = _BV(ICNC1) | _BV(CS11); // enable noise canceller, /8 prescaler

  noInterrupts(); // so we don't get delayed by other interrupts
  bitSet(TIFR1,ICF1); // clear i/p compare flag
  while(!bitRead(TIFR1,ICF1)); // wait for comparator (this will freeze if no a/c)
  count=ICR1L | ((word)ICR1H<<8); // get start timer count
  bitSet(TIFR1,ICF1); // clear flag for next comparison
  while(!bitRead(TIFR1,ICF1)); // wait for comparator (this will freeze if no a/c)
  count = (ICR1L | ((word)ICR1H<<8)) - count; // get period of cycle
  interrupts();

  ADCSRA=oldADCSRA; // restore ADC state
  ADCSRB=oldADCSRB;
  ADMUX=oldADMUX;
  return 2000000.0/count; // timer frequency is 2MHz
}

void setup()
{
Serial.begin(9600);
 
}

void loop()
{
  Serial.print(" Frequency = ");
  Serial.println(measureFrequency(5)); // 2 is the analogue pin for the a/c input, you may need to change this
  delay(1500);

}

Just a note about the internal reference. It is a band-gap reference, the tolerance is poor ( 1.1 V ± 0.1 V) but its long-term stability is good. On the other hand, the 3.3 V or 5 V regulator - MCP1702 - has a tolerance of ± 3% (and typically 0.4% - significantly better), but is subject to 50 ppm per °C temperature drift plus 0.3%/V line regulation plus 2.5% load regulation (1 - 250 mA) plus a PSRR of 0.6%.

The purpose of scaling the input using the internal band-gap reference (which is ultimately what that emonLib method does) is to allow battery operation, where the supply will clearly drop as the battery runs down. If the 3.3 V regulator in the emonTx has a pre-regulated 5 V input and a constant load and operates at a constant temperature, many of these variations will be much reduced, and the supply from the MCP1702 will be more precise, but possibly still not as stable. If you look up one of the original papers by the inventor of the band-gap reference, he claims that with on-chip thin film resistors, a temperature stability of less than 4 ppm/ °C is possible. I have not found any specific data for the reference in the Atmega328P.

Using Martins recent  sketch..

After adjusting ACSR = _BV(ASIC_

and adding a wire from AIN0 to center of volt divider, I got this

Frequency PLL= 24691.36
Frequency PLL= 64516.13
Frequency PLL= 21978.02
Frequency PLL= 21505.38
Frequency PLL= 16000.00
Frequency PLL= 57142.85
Frequency PLL= 16000.00
Frequency PLL= 22222.22
Frequency PLL= 117647.07
Frequency PLL= 15873.02
Frequency PLL= 28169.01
Frequency PLL= 449.9

That looks similar to the numbers I got without a hardware filter. I assume you have followed all of MartinR's advice. See above for what I needed to do additionally.

Firstly platypus, this bit of code does not implement a PLL, it just times the period of 1 cycle as I explained above, so it's probably best that you remove the "Frequency PLL" comment to avoid confusion.

This simple method does seem to be sensitive to noise as Robert found, so unless you have the means and determination to track down the source and fix it you are probably better off using the old phase_lock_50Hz sketch that Robert suggested.

Thanks Martin, have removed PLL from the previous post.

Your phase lock sketch works well, by itself - from the link that Robert posted.

I ultimately want to add phase locked frequency to emonlib.

An attempt to add your phase lock code to the emonlib sketch failed - think by trying to add the code on an, as is, basis there was some conflict, perhaps with the 'already there' bandgap code in emonlib.cpp

So that's where I was heading.

Have I missed an update that already has this functionality?

And yes, you are absolutely correct, playing with this type of code is complicated and needs perseverance.

Robert and yourself have already put in quite a lot of time here, thanks - hopefully others have also benefitted by your combined experience. At least your phase locked sketch has bubbled up again and does work.

All the best..

You simply will not be able to add a PLL function to emonLib. EmonLib works in a quite different way; the correct approach is to see the whole sketch as one complete entity, not as several pieces bolted together. What is wrong with Martin's http://openenergymonitor.org/emon/node/1535 ?  If you need to read more c.t's, they can be added (but you might need to reduce the number of samples per cycle).

I have not read everything above but a photo of my emonGLCD displaying frequency sent using Martin's code is attached.

Thanks Robert, yes I guessed that there was a conflict between emonlib and Martins PLL code but just don't have the time to play with this further.

I am also getting a random glitch in display from the emonitor where suddenly the voltage goes haywire, resets, then the very next line is fine. Of course, it affects all the energy calculations

Here is the Serial Monitor display of the fault - dont worry about the unusual current, this is on a 200A test CT with 25turns active as booster. This load is a fridge on voltage regulation equipment.

The frequency is a modification of my previous crude version which used a dual pulseIn(), high followed by low with extra code to prevent wandering - so I have locked the high/low together to catch a whole cycle - its very close.

Frequency is not affected as it is sensed/calculated outside the emon code.

The lines in bold show the glitch/es

On No Load

V=221.9  I= NoLoad  KW=0.00  KVA=0.00  KVAr=0.00  PF= 0.999  PG=357.44  Freq= 75.14 Temp= 25.20 degC
V=221.8  I= NoLoad  KW=0.00  KVA=0.00  KVAr=0.00  PF= 0.999  PG=357.44  Freq= 60.04 Temp= 25.20 degC
V=221.3  I= NoLoad  KW=0.00  KVA=0.00  KVAr=0.00  PF= 0.999  PG=357.44  Freq= 50.01 Temp= 25.20 degC
V=223.1  I= NoLoad  KW=0.00  KVA=0.00  KVAr=0.00  PF= 0.999  PG=357.44  Freq= 50.00 Temp= 25.20 degC
V=-0.2  I= NoLoad  KW=0.00  KVA=0.00  KVAr=0.00  PF= 0.999  PG=357.44  Freq= 50.02 Temp= 25.68 degC
V=223.3  I= NoLoad  KW=0.00  KVA=0.00  KVAr=0.00  PF= 0.999  PG=357.44  Freq= 50.02 Temp= 25.20 degC
V=221.1  I= NoLoad  KW=0.00  KVA=0.00  KVAr=0.00  PF= 0.999  PG=357.44  Freq= 50.02 Temp= 25.20 degC
V=222.5  I= NoLoad  KW=0.00  KVA=0.00  KVAr=0.00  PF= 0.999  PG=357.44  Freq= 50.00 Temp= 24.71 degC
V=222.

With Load

V=219.0  I= 35.56  KW=5.49  KVA=7.79  KVAr=5.52  PF= 0.705  PG=314.83  Freq= 50.03 Temp= 24.71 degC
V=220.4  I= 35.68  KW=5.54  KVA=7.87  KVAr=5.59  PF= 0.704  PG=314.75  Freq= 50.00 Temp= 25.20 degC
V=219.8  I= 35.71  KW=5.53  KVA=7.85  KVAr=5.58  PF= 0.704  PG=314.74  Freq= 50.03 Temp= 25.68 degC
V=219.1  I= 35.60  KW=5.47  KVA=7.80  KVAr=5.56  PF= 0.702  PG=314.57  Freq= 50.03 Temp= 25.20 degC
V=2444.4  I= 398.11  KW=681.11  KVA=973.13  KVAr=695.03  PF= 0.700  PG=314.42  Freq= 50.03 Temp= 25.68 degC
V=219.4  I= 35.69  KW=5.49  KVA=7.83  KVAr=5.58  PF= 0.701  PG=314.50  Freq= 50.01 Temp= 25.20 degC
V=219.6  I= 35.55  KW=5.47  KVA=7.81  KVAr=5.57  PF= 0.700  PG=314.44  Freq= 50.00 Temp= 25.68 degC
V=219.7  I= 35.51  KW=5.47  KVA=7.80  KVAr=5.56  PF= 0.701  PG=314.52  Freq= 50.00 Temp= 24.71 degC
V

I need to see the code you are running to be able to even start to think about that one. When you write "the voltage goes haywire, resets, then the very next line is fine. " do you mean "resets" as in the processor restarts the sketch from the top? -and how do you know?

Robert, I suspect a connection issue here.

Also can you say for which which Arduino boards emonlib was written?

EmonLib is written not for Arduino boards, but for the emonTx with the 328P processor. However, you appear to be reading voltage, frequency and current correctly most of the time, which to me rules out a basic problem like wrong pins.

What is puzzling me is the negative voltage that you see. You cannot have a square root of a negative number (it is "nan"), so (working backwards through the emonLib method that calculates Vrms) VRATIO must be negative. Therefore either VCAL or SUPPLYVOLTAGE must be negative (but not both). If VCAL is negative, the parameters you are passing to EnergyMonitor::voltage(int _inPinV, double _VCAL, double _PHASECAL) are wrong, and why are all the other values correct?; if SUPPLYVOLTAGE is negative, then readVcc( ) is returning a negative number.

You need to find out why readVcc( ) is returning a wrong value occasionally. The first step of course is to substitute a constant value instead of the call to readVcc( ) and prove that I am correct so far.

The reason I wanted sight of your code is because "I=noload" is not part of any of the standard sketches, and it's difficult to diagnose a problem blind.