Calibration issues with RPICT3

Thank you, I was assuming that it was over a few cycles. I need quicker update than that < 500 ms for all 3 CTs combined, I just hope that 5 cycles for instance is good enough. Thanks a lot!

If you can get exactly one cycle, one cycle should be good enough. But the problem is, a whole number of samples will not fit exactly into one cycle, unless you are lucky. If you happen to start and finish near the peak value, you have an error that is the peak value over the time difference between where you should have stopped and where your actual last sample was. The more cycles you can spread that error over, the smaller it gets.

(This is also why, when the voltage is available, we measure from zero crossing to zero crossing, so that the error value is small regardless.)

Thank you so much! I see calcIrms() reads in a tightest loop possible, where there is a given delay by waiting for the prescaler + maths. Is there a reason why you donā€™t want to use a hardware timer to measure the points evenly? I guess there is some jitter even in the MCU with a crystal.

MartinRā€™s PLL energy diverter does exactly that, but there seems to be no real advantage in doing so. In any case, you cannot synchronise a PLL without a (relatively) constant voltage signal. The current signal is useless, as it can vary between a nice clean wave, lots of harmonics or nothing.

If you try to use timing to synchronise, how are you going to deal with mains frequency variations? Although the generators try to maintain the frequency much closer to the nominal value, the limit here is Ā±1%. Iā€™m afraid that like many engineering problems, you have to aim for the least bad compromise because thereā€™s no easy answer.

Thank you for your insights!

So itā€™s fine doing a rough calculation over how many samples it would take to fill 5+ cycles in a loop without sleep, and go for that on a raspberry pi without RT_PREEMPT?

I would assume an MCU is more stable since there is not a scheduler in the kernel messing with it. But with all these real-world problems does it really matter if some samples are measured 135 Āµs between and some others are measured 80 Āµs in between? Thatā€™s the jitter Iā€™ve seen on my C test on Raspbian on the PI 3.

Doing it directly through an MCP3008 is vastly simpler from a production and maintenance standpoint even though I sacrifice some CPU (~9% on one core) and more jitter than MCU.

I know I am diverging from the actual measurement here and moving to more programming / platform related questions but this has been bothering me a lot. :slight_smile: Maybe I am too demanding? :slight_smile:

That could be the case! Itā€™s very easy to forget that the interface with the real world (the c.t. and resistors) is via components that come with a certain manufacturing tolerance, and you canā€™t guarantee accuracy to crystal precision, without calibration you will be guaranteed something better than about Ā± 5% (this is amplitude of course). Where inside that 10% wide band your specific set of components will lie is anyoneā€™s guess, hopefully many of the errors will at least partially cancel one another, but thereā€™s nothing to say that they wonā€™t.

Haha yeah. Now I have fought SPI on Linux

I managed to write code to send multiple transactions in one ioctl call.
Things to note: max number of transactions is 511 per ioctl call. So it has to be divided up in batches.

The CPU usage is almost the same though.

I got it fairly stable on 100 ms (4 mains cycles @ 50 hz) using 511 samples. Then the CPU was hovering around 5-7% on one core.

So if you guys ever need an SPI expert on linux, give me a shout! I worked from day to night for 3 days on this :slight_smile: I have successfully ported the calcIrms to linux C++ with JNI exports to Java.

Hi emil,
reading your post let me think that you, somehow, flashed the rpict module, could you please tell me how youā€™ve done that ?

I flash it through SPI using the ports described in the datasheet using AVRDude on raspberry PI

I wrote my own pure AVR code instead of using the arduino core. Arduino adds a ton of extra byte size and overhead.

Back to you again EMil,

Thanks for the prompt answer!

Iā€™ve tried to flash it through raspberry pi as ISP but it didnā€™t work :frowning: with the arduino core though.
Could you please tell me the steps to do it with raspberry pi ?

Thanks for any help you could provide!