I have just seen this new sketch which follows the idea of e.g. Robert to use delayed voltage samples for 'real' three-phase power measurements. I think that there might be a severe inaccuracy in this sketch.
As this sketch does not use interrupts, the sampling of all the analog inputs is dependant on the runtime of the code in between the samplings. The four consecutive samples for V, I1, I2, I3 are done without any code 'in between', so more or less with the same delay between samples (not regarding interrupts).
But the time between these bursts of four samples depends on the code in between these bursts. And this time or delay depends on the number of cycles used for these calculations, which may be differing a little bit. This is the same problem with all the 'non-interrupt' sketches.
But in this sketch, the pre-sampling of the delayed voltage buffer (crossCount<=2) is done with a different 'sampling rate' as when (crossCount>2). There are much more calculations done after (crossCount>2).
Please correct me if I'm wrong there. I am not using 'Arduino' code so much, so it might be that I am wrong.
Jörg.
EDIT: I am aware of the fact that the error gets smaller the higher the number of 'cycles' is in calling
calcVI3Ph(int cycles, int timeout)
Re: new emonTx_CT123_3Phase_voltage sketch
The sketch followed exactly the algorithm of the standard example sketches - and for that matter the Atmel example application. The sketch can only deliver approximations and the limitations are clearly described in the comment. It is likely that the assumption that the same voltage is present on all phases will be the largest source of error.
If you want to include all the code in the first cycle, feel free to do so (then reset the accumulators so that the results are not used).
Perhaps you can explain what interrupts would achieve? Maybe you could time the samples more accurately, but it would be at the expense of waiting for the interrupt to happen and you would inevitably end up having fewer samples. I'm assuming your interrupts would be timed, because there's nothing else to generate them. If there is an advantage in having each sample at a known fixed time in the cycle - assuming of course the mains frequency doesn't change, I can't see it when the result ends up averaged. In fact, I would suspect that having the samples free running might actually give a more accurate result in the presence of higher harmonic content. Or is there something I don't understand and there's some magical process that can manifest processor instruction cycles out of thin air?
Re: new emonTx_CT123_3Phase_voltage sketch
The sketch followed exactly the algorithm of the standard example sketches - and for that matter the Atmel example application.
??? And?
The sketch can only deliver approximations ....
This is true for all measurements! Some are better, some are worth.
It is likely that the assumption that the same voltage is present on all phases will be the largest source of error.
Yes!
If you want to include all the code in the first cycle, feel free to do so (then reset the accumulators so that the results are not used).
Excellent idea!
Perhaps you can explain what interrupts would achieve? Maybe you could time the samples more accurately, but it would be at the expense of waiting for the interrupt to happen and you would inevitably end up having fewer samples.
Robert, it is the big advantage of interrupts, that you do not have to 'wait' for them to happen. This is the exact opposit to the existing 'arduino' analogRead() where the processor has to run in circles waiting for the adc to finish the conversion. After that, a lot of processor cycles are used for calculations where the adc is not doing anything. We can do better with interrupts!!!
If the code in the ISR is always shorter than the periode of the interrupt, than first the sampling point will be absolutely exact. Second, the processing time that is not 'used' up in the ISR can be used for other purposes. The timing of the interrupts can either be done with a timer or, as in Pcunhas code, by the timing of the free-running adc.
.......you would inevitably end up having fewer samples.
Using the free running adc means that you have a new sample every 104us. This gives for sure more samples than the original code!
If there is an advantage in having each sample at a known fixed time in the cycle - assuming of course the mains frequency doesn't change, I can't see it when the result ends up averaged.
The advantage is not to have the sample done at a fixed phase angle but to have it at fixed intervals at all. This has absolutely nothing to do with the mains frequency.
Or is there something I don't understand and there's some magical process that can manifest processor instruction cycles out of thin air?
??? Heh? British humour?
Re: new emonTx_CT123_3Phase_voltage sketch
I wrote the sketch to satisfy a request from someone who obviously needed help. Do you ignore a request like that, or do you start them off? I didn't have the time to research the fine details (and when I started I was not aware of another sketch that I could have used as a starting point). If you can improve on either the algorithm or the implementation, then this is what Open-Source is all about. If you have access to a 3-phase supply where you can experiment and test, so much the better. I don't have access to that facility, so the only tests I can do use theory to predict the 'wrong' results that I will get and then prove it by getting the expected 'wrong' results. I shall be the first to claim that this is less than satisfactory.
Re: new emonTx_CT123_3Phase_voltage sketch
I think that the basic idea for this sketch is very nice. Use the existing emontx hardware to achieve the best result you can get from it. And in my opinion a working three-phase solution is the final goal for a majority of the audience. I might be wrong there because I do not know exactly how widespread thre-phase systems really are in households. In Germany this is the standard. So what you normally want is a three-phase solution that gives 'good enough' results. It does not have to be perfect, just as good as possible. But if you can avoid mistakes or insufficiencies, why not try to do so.
Your solution to do the same calculations already during the first two cycles and ignore the results is very good, it does not need more than changing two or three lines in the code. If this improves accuracy by a few tenth of a percent, perfect!
I do not want to say that the 'final solution' of a three-phase monitoring has to be interrupt driven. I just think that this is the normal way an embedded software engineer would approach a problem like this. If he (or she
) is free in his 'choice of weapons'. This might not be the case here where nearly all code follows 'arduino' style (higher abstraction level, use library code, whatever this means...). And this code might be easier to understand, use, modify.
BR, Jörg.
PS: And, my approach in solving problems is a bit different than yours: I use theory to predict how 'good' results can theoretically be and then I try to achieve these results in reality (sounds more 'positive', or?
)