Submitted by 321liftoff on Fri, 27/11/2015 - 07:22
I'm a noob to emonTx so thanks to everyone for their contributions to getting the project this far.
I have seen a few libraries and sketches posted on the forums and github: DiscreteSampling (Trystan), ContinuousPLL (Martin), ContinuousFree (Robin), ContinuousPLL flexible (Nuno), etc. What I have noticed in all of these is that there is no standard foundation of common objects and methods. In this post, I propose we take steps to standardize the most basic and common ways of processing an ADC sample and calculating power. Regulating this to a library helps de-clutter code of higher-level sketches and reduces the amount of code that has to be repeated for each ADC channel or CT.
My proposal is for an energy monitor firmware to have three layers: (1) Standard Object/Method Library, (2) Process Library, (3) Sketch with setup() and loop(). For example, in this scheme, the standard firmware would be comprised of (1) the proposed object library, (2) EmonLib, (3) DiscreteSampling.
I have attached a very rough draft of what the new object library could look like. (The only testing I have done is that it compiles, so keep this in mind) You will notice that the concept is object-oriented in a way that I have not seen anywhere. In a sketch using this library, a user defines an array to describe which ADC channels are used and what they are for (CT or VT). Then, the user constructs an Emon object, that contains CT and VT objects and the methods for computing power. This library should contain all standard methods needed for processing ADC samples and calculating power. Also, this library should be generic enough to be used by libraries/sketches, regardless of the process or approach (Discrete, continuous, PLL, etc).
With an object-oriented approach, it's possible that there is a time cost that the existing sketches/libraries does not have. This would have to be tested to characterize what the cost in time is to using an approach such as this. Maybe this is why nobody is doing it this way?
At this stage, I'm soliciting the community for whether an approach of standardizing basic energy monitoring functions would be supported. If so, we can begin collaborating on the best way to achieve this.
Standardization of various Libraries?
Submitted by 321liftoff on Fri, 27/11/2015 - 07:22I'm a noob to emonTx so thanks to everyone for their contributions to getting the project this far.
I have seen a few libraries and sketches posted on the forums and github: DiscreteSampling (Trystan), ContinuousPLL (Martin), ContinuousFree (Robin), ContinuousPLL flexible (Nuno), etc. What I have noticed in all of these is that there is no standard foundation of common objects and methods. In this post, I propose we take steps to standardize the most basic and common ways of processing an ADC sample and calculating power. Regulating this to a library helps de-clutter code of higher-level sketches and reduces the amount of code that has to be repeated for each ADC channel or CT.
My proposal is for an energy monitor firmware to have three layers: (1) Standard Object/Method Library, (2) Process Library, (3) Sketch with setup() and loop(). For example, in this scheme, the standard firmware would be comprised of (1) the proposed object library, (2) EmonLib, (3) DiscreteSampling.
I have attached a very rough draft of what the new object library could look like. (The only testing I have done is that it compiles, so keep this in mind) You will notice that the concept is object-oriented in a way that I have not seen anywhere. In a sketch using this library, a user defines an array to describe which ADC channels are used and what they are for (CT or VT). Then, the user constructs an Emon object, that contains CT and VT objects and the methods for computing power. This library should contain all standard methods needed for processing ADC samples and calculating power. Also, this library should be generic enough to be used by libraries/sketches, regardless of the process or approach (Discrete, continuous, PLL, etc).
With an object-oriented approach, it's possible that there is a time cost that the existing sketches/libraries does not have. This would have to be tested to characterize what the cost in time is to using an approach such as this. Maybe this is why nobody is doing it this way?
At this stage, I'm soliciting the community for whether an approach of standardizing basic energy monitoring functions would be supported. If so, we can begin collaborating on the best way to achieve this.