It's easy to measure I2t, isn't it? Every text book shows it as a square pulse, so just integrate the square of the current over the length of the pulse. No problem.
But real-life surges don't look like that. They are exponential, modulated by 50Hz, and decay down to the normal running current of whatever has just caused the surge, not to zero.
So where does the upper limit of integration go?

 

Thanks for the compliment.
I've got a current transformer and an A/D sampling at 1600 samples/second.
So I start when the output switches on, square and accumulate the result (I can even do that in 1 instruction with an ARM MAC instruction), but where do I stop?
Assuming it's some sort of motor - I have no control over what the customer connects - when the surge is over, the current doesn't neatly return to zero like it does in the text books, it keeps on going at the steady running current.
So, I can place the upper limit of integration anywhere, and get any result I fancy, and so it makes no sense.

 

Assuming this is start up pulses

What I do for current start up pulse,
is squares under the curve !
capture on digital scope.

crude but a good first level approximation as to d we have a problem or not.

this might be of help also
https://www.digikey.com/Site/Global/Layouts/DownloadPdf.ashx?pdfUrl=52AEB7F6D7F244A8995471B9FFED8CF0

 

Isn’t is strange how all their waveforms go back to zero after the surge is over, just like real-life waveforms don't?
They must be starting up perpetual motion machines which take no current to run!
In the case of a real motor starting up, then running at a steady current, where do I put the upper value of t?

 

All of them are showing that you calculate the area under the curve,
which is easy enough to "calculate" or count the squares.

The basis of i2t is for circuit breakers, which when break, current goes back to zero , which I think explains the "standard" curves.

Again, looking at the reason for the i2t, "heating" of a fuse / breaker
What I do for a rising , turn on waveform with a "over glitch"
is measure the area under the glitch , down to zero,
on the basis that the steady state will be cooling off.

It may not be the best way, but it seems to have worked .