Archived Forum

So give us a clue - what are you doing now, that is running out of memory?

Well as an example I can use the Emonlib library using the method: ( I have used just 1 as the example of the process im using.  

"

#include "EmonLib.h"

EnergyMonitor emon0; ( x 15 of these)

#define NSENSORS 15

EnergyMonitor emon[NSENSORS];

typedef struct {
  float apparentPower;  //4
  float realPower;    // 4
  float powerFactor;  // 4
  float Irms;         // 4
} sEmonSensor;

sEmonSensor EmonTx[NSENSORS];

void setup() {

Serial.begin(9600);

emon[0].current(2, 97.7);             // Current: pin, calib.  ( x 15 of these)

}

void loop () {
 
 for (int i=0; i<NSENSORS; i++) {    
  emon[i].calcVI(20,50);
  }

Serial.print(emon[0].Irms);              
    Serial.print(F(",  "));

}

If that makes any sense at all?

Basically what im trying to achieve is to record what each three phase output of the distribution boards is doing. The largest board (at the moment) im trying to record data from has 8 x 4 pole breakers. But the maximum amount of CT's I can get running on the emonlib library is 15 before it comes up with the following issue on the Arduino IDE:

Sketch uses 19,454 bytes (67%) of program storage space. Maximum is 28,672 bytes.
Global variables use 2,784 bytes (108%) of dynamic memory, leaving -224 bytes for local variables. Maximum is 2,560 bytes.
processing.app.debug.RunnerException: Not enough memory; see http://www.arduino.cc/en/Guide/Troubleshooting#size for tips on reducing your footprint.
    at processing.app.Sketch.size(Sketch.java:1680)
    at processing.app.Sketch.build(Sketch.java:1590)
    at processing.app.Sketch.build(Sketch.java:1509)
    at processing.app.Editor$DefaultRunHandler.run(Editor.java:1915)
    at java.lang.Thread.run(Thread.java:695)

It doesn't make a lot of sense! It looks to me as if you've defined 30 instances of the class EnergyMonitor - 15 separate instances named emon0, emon1, emon2, ... emon14, and an array of 15 too. Did you mean that, or have I misread it?

Presumably the array EmonTx of structs is to accept & transmit the data, but you haven't implemented that yet?

Unfortunately, because of the way the software filters work, you do need a class instance for each channel, and I think that, unless there are some variables that you don't need, there's nothing redundant in the library. But of course if there are things you don't want, you're free to take them out.

Hello, 

Thank you for your comments. Yes i am creating up to 15 instances at the moment, as that's the maximum amount I can get to work, but eventually I'd like to do a lot more. The reason I've done them as individual instances is because i am multiplexing it all through 4051B's as there aren't enough inputs on the Yun for 32 individual analog inputs.

I have read briefly about continuous sampling, but I haven't got my head round that yet...as i believe it converts the raw data from the CT's in a different and less taxing way...(please correct me if I'm wrong and have barked up the wrong tree with that one!haha)

I also read something about Emonlibpro and in the description it says about "any number of voltage and current sensors". Is this any number above 15?? or again am I reading into this wrong....I'm having a proper research evening tomorrow so I'll hopefully answer those questions tomorrow.

Both of the above I've not had a chance to read into yet, but will so hopefully tomorrow....

I finally read in another post about doing the filtering and DC biasing on the first CT channel and just copy the result into the others (how ever many) which would also seem to save a lot of processing power??

My questions above are why I have posted...im a little lost as into the direction I should follow, and hey, who better to ask than you guys!?

thanks again!

"Yes i am creating up to 15 instances at the moment..."
Ok, if you're certain of that. It looked as if you were generating 30.

"I have read briefly about continuous sampling, but I haven't got my head round that yet...as i believe it converts the raw data from the CT's in a different and less taxing way..."

I don't know where you got that one from, but I'd say NOT TRUE. In the 'discrete' sketch, the ADC is started and when the result is returned, the loop continues and processes the numbers. It does this for each voltage and current pair for 10 cycles, then gives you the averages over that period. It achieves about 50 sample pairs per cycle. In the 'continuous' sketch, the ADC free-runs and triggers an interrupt at end of each conversion. That starts an ISR (Interrupt Service Routine) that, while the present conversion is under way, sets up the target of the next conversion and processes the result of the last conversion, which the main loop can then pick up and handle. So in fact the processor is working a lot harder, and unless you have a really fast ADC, you won't be able to handle 15 pairs of voltage and current readings at anywhere near a respectable sampling rate.

I know nothing about emonlibpro, so I cannot comment.

"I finally read in another post about doing the filtering and DC biasing on the first CT channel and just copy the result into the others (how ever many) which would also seem to save a lot of processing power??"
Oh yes, it'll save a bit of processing power. And most likely introduce steps too, which will give you wrong results. Why is the filter there in the first place? The only way to economise there is to provide all the inputs with a common DC bias (see "Op-amp bias" somewhere in Resources), and then you need to run the filter on just one channel and you can subtract the (identical to within the ADC linearity) offset value from each channel. EmonLib does all you need there and it would simply need the common offset to be shared between all the instances. But even so, there's not a lot of processing in the filter.