Archived Forum

To divide by 240 you would need to multiply by 0.004166 (recurring), alternatively you could use a "divide by input" or "divide by feed" for a more dynamic representation of voltage, (if voltage is being logged) but how accuate that sum will be without considering power factor and rms vs peak-to-peak etc I would like to say.

Paul

Thanks Paul

Only really looking for a close representation in this case. We are measuring VRMS also so could divide by that.

Where is this setup as can see that in the node, add feed I can select x input or / input but where would the calculation take place ?

If you are able to reprogram your emonTx, the rms current has already been calculated. It only needs adding to the 'payload' that's transmitted to the emonPi.

the calculation is done each time the input that hosts the processlist is updated, the result of the "/ input" will need to be logged using a "log to feed" process next in the processlist. 

Paul

Interested in this as well.

I'd like to get at the measured current rather than try and back calculate from the reported power.

I assume it is a matter of adding rx id's 12 and 13 for the measured current values, to the frame from the Arduino.

something like this in emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino  maybe?

typedef struct {
int power1;
int power2;
int power1_plus_2;                                                    
int Vrms;
int temp[MaxOnewire];
unsigned long pulseCount;
int current1;
int current2;  
} PayloadTX;   

and

if ((now - last_sample) > TIME_BETWEEN_READINGS)
  {
    single_LED_flash();                                                            // single flash of LED on local CT sample
    
    if (ACAC)                                                                      // Read from CT 1
    {
      ct1.calcVI(no_of_half_wavelengths,timeout); emonPi.power1=ct1.realPower;
      emonPi.current1 = ct1.calcIrms(no_of_samples);                               // Capture RMS current
      emonPi.Vrms=ct1.Vrms*100;
    }
    else
    {
      emonPi.current1 = ct1.calcIrms(no_of_samples);                             // Capture RMS current  
      emonPi.power1 = emonPi.current1*Vrms;                                      // Calculate Apparent Power 1  1480 is  number of samples
      emonPi.Vrms=Vrms*100;
    }  

 
   if (ACAC)                                                                       // Read from CT 2
   {
     ct2.calcVI(no_of_half_wavelengths,timeout); emonPi.power2=ct2.realPower;
     emonPi.current2 = ct2.calcIrms(no_of_samples);                                // Capture RMS current
     emonPi.Vrms=ct2.Vrms*100;
   }
   else
   {
     emonPi.current2 = ct2.calcIrms(no_of_samples);                                  // Capture RMS current
     emonPi.power2 = emonPi.current2*Vrms;                               // Calculate Apparent Power 1  1480 is  number of samples
     emonPi.Vrms=Vrms*100;  
   }

   emonPi.power1_plus_2=emonPi.power1 + emonPi.power2;                            //Create power 1 plus power 2 variable for US and solar PV installs

  //Serial.print(emonPi.pulseCount); Serial.print(" ");delay(5);
   // if (debug==1) {Serial.print(emonPi.power2); Serial.print(" ");delay(5);}  

Harry

There's absolutely no need to do
  emonPi.current1 = ct1.calcIrms(no_of_samples);                               // Capture RMS current
The current has just been calculated by calcVI and is available as ct1.Irms. (See emonLib.h) So 
  emonPi.current1 = ct1.Irms;
is all you need.
 

Thanks. I'm very new at this, my shiny new emonPi is approaching an uptime of 30 hours...

I had trouble tracking where emonLib.h lives so the above brutal hack was created without view of the internals of emonLib.  Your option is worlds better.

Am I correct that all I need to do to publish additional values is to add them to the struct, and that struct is used for both the rf frame, and the link to the Pi?

I'd rather not break my new toy finding out the hard way..

version 2

typedef struct {
int power1;
int power2;
int power1_plus_2;                                                    
int Vrms;
int temp[MaxOnewire];
unsigned long pulseCount;
int current1;
int current2;  
} PayloadTX;    

if ((now - last_sample) > TIME_BETWEEN_READINGS)
  {
    single_LED_flash();                                                            // single flash of LED on local CT sample
    
    if (ACAC)                                                                      // Read from CT 1
    {
      ct1.calcVI(no_of_half_wavelengths,timeout);
      emonPi.power1=ct1.realPower;
      emonPi.current1 = ct1.Irms;                                                 // Capture RMS current
      emonPi.Vrms=ct1.Vrms*100;
    }
    else
    {
      emonPi.current1 = ct1.calcIrms(no_of_samples);                             // Capture RMS current  
      emonPi.power1 = emonPi.current1*Vrms;                                      // Calculate Apparent Power 1  1480 is  number of samples
      emonPi.Vrms=Vrms*100;
    }  

 
   if (ACAC)                                                                       // Read from CT 2
   {
     ct2.calcVI(no_of_half_wavelengths,timeout);
     emonPi.power2=ct2.realPower;
     emonPi.current1 = ct2.Irms;                                                 // Capture RMS current
     emonPi.Vrms=ct2.Vrms*100;
   }
   else
   {
     emonPi.current2 = ct2.calcIrms(no_of_samples);                                  // Capture RMS current
     emonPi.power2 = emonPi.current2*Vrms;                               // Calculate Apparent Power 1  1480 is  number of samples
     emonPi.Vrms=Vrms*100;  
   }

   emonPi.power1_plus_2=emonPi.power1 + emonPi.power2;                            //Create power 1 plus power 2 variable for US and solar PV installs

Harry

You need to get the sketch into the Atmel386 on the "emonTx" inside the emonPi, and for that you need to compile it and transfer the hex file to the Pi, then send it across the serial link to the emon bit. The details of that are in the Hardware Wiki, "RFM69Pi V3" > "Upgrading RFM69Pi Firmware Direct from the Pi". 

Then you need to use the config editor (or edit emonhub.conf) to make it aware of the additions, else it rejects the complete packet. See http://openenergymonitor.org/emon/modules/emonpi#emonhubconfig 

TYPO ALERT! I spy a Copy & Paste error with "emonPi.current1" on channel 2.

ok fixed the typo, installed a shiny new version of arduino on my laptop, got a lot of libraries and have built a new binary. Exported the binary.

I've explained my antics to emonhub and its happily reporting two new variables, hopefully scaled and with the right units.

However I have some questions before I try and load that firmware...

I have two versions of the binary, one with built in bootloader, one without.

I'm not clear from the hardware wiki which of the two I need, and if  need the version with the bootloader, if the standard bootloader added by the arduino IDE is sufficient or if I need to set up for the optiboot loader mentioned in the hardware  wiki (or if that is any different from the standard).

On previous run ins with arduino programming, the bootloader is a preloaded fixture, and the new image is loaded above the existing bootloader, preserving it. I see nothing about that offset in the files I've amended, so I'm nervous...

I have minicom installed, and avrdude installed, and the serial console disabled, all of which have been set up already in the standard Pi image I'm running.

Help please...

Harry

Whoops, forgot to add that my firmware is targeted at Arduino/Genuino Uno, again confirmation that that is a suitable target would be much appreciated.

Harry

The target should indeed be Arduino uno. The file without the bootloader is the file to upload via the serial port. the bootloader enables code to be installed via the serial port and cannot be installed itself by that method. it would need uploading with an in-circuit programmer via the SPI bus.

Paul

Built and installed the new firmware, it sort of worked, I got some reasonable values transferred, but EmonCMS was complaining at the packet format, so I've backed out to the official firmware at the moment.

I patched the current values into the end of the message frame , but some of the errors suggest to me that there is a maximum packet size that the frame can be.

It looks rather suspiciously like the Jeenode frame that both the serial interface and the wireless use is a fixed number of bytes long, and the frame has been packed with as many thermometer values as will fit. If someone can confirm that it will save much scrabbling in the Jeenode code.

I was trying not to intrude on the original set up, but that may have been a mistake.

While I'm asking around, is the power factor that is measured as part of calculating the real power values access able in the Arduino?

Harry

The maximum payload is supposed to be 66 bytes, however...

I've had problems with over 60 bytes (it's acknowledged that there's a bug there), and
There are believed to be synchronisation problems if there is a long string of zero in the payload. If you're not using all the temperature sensors, you can cut them down or take them out completely, but in any case you need to change the emonhub configuration to suit the payload that you decide upon.

You can extract power factor and add it to your payload (if there's room!)

Thanks again Robert, I'll do that. Since my temperature monitoring comes in by a different route, I should have plenty of space for the values I want.

I notice the continuous reading code, which looks like the future, I'm using the standard code as a base presently.

How flaky is that code yet, is there value in my investigating that, or am I adding significantly to my problems?

I'm not depending critically on the emonPi yet, would additional testing of the new code be of value?

Harry

There might be the odd bug in the continuous code, but it's been derived from Robin's Mk2 Diverter and that's well proven. So any problems are likely to have been introduced in the translation (like one I reported a couple of days ago) and easily corrected. (http://openenergymonitor.org/emon/node/11722#comment-38405)

If you have a load that's rapidly switched, like an induction hob, or an energy diverter, then the 'discrete' code isn't for you. Otherwise, there won't be much difference, as the short-term errors arising from the discrete (200 ms out of every 10 s) samples will average out over time. 

I think PBudmark should get at least some of the credit for finding that bug, shouldn't he?  He may not have nailed it completely, but presumably it would still be there, but for his research.

Indeed. He spotted the original problem, and how that got past initial testing I don't know. All I did was check and report it. [Edit: Trystan has corrected it.]

My version of the Arduino code works for me as for as I've been able to test it.

The current draw goes from a base of 2 Amps, between 550 and 600 watts up to about 11 amps when I switch on a kettle, when it cools down I'll look at the rating plate, but I'm betting it's a 2.5 Kilowatt device.

There was nothing wrong with my Arduino code, I'd messed up the Emonhub.conf, and that led to the errors that frightened me off on my first attempt to deploy that code. The bitching about the packet format was at the EmonHub end not a chewed up packet coming from the Arduino.

Thanks for the sterling assistance.

Harry