-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Current measurements are a bit noisy #3
Comments
Ultimately I think the goal is to make current measurements stable enough to undo df7ffbf ;) |
I have made some Libreoffice Calc experiments on the actual data, and found that moving average is superior to previously suggested low pass filter. I'll assume current data is read from PAC1933 at the constant rate close to 1024Hz, which is the maximum spec for this chip. The best filter I have tested so far is to always store last 1000 samples, and upon request do the average on the last n samples, where "n" is the interval time in ms. It may be hard to query data from PAC chip at such high rate, but it can be done with a little optimization on the library side. Right now, for each measurement (voltage, current and power) there is a refresh command, and extra delay to meet PAC specs. This may be reduced to a simpler form:
|
Thank you for your issues. We will investigate the issues. And We will check the rolling average feature of PAC1933 on SmartPower3. |
Yasss! I made it! I created a new code that adapts moving average depth depending on interval. It allows for reading averaged data independently, so screen can be averaged to 300ms refresh and serial data to whatever user has selected. I also heavily modified sampling algorithm to get as many samples as possible. Sadly, the I2C handling is slow within the MCU itself, but I managed to sample at >600 samples per second. which gives results as above. Theoretical maximum is 1000 sps, and original firmware does something closer to 400. I'll clean up my code and test it with actual variable load (XU4). Then I'll do PR and let you decide what to do with it. :) |
I created a PR #1 that addresses the problem partially.
I think the problem might be with dirty 3V3 supplying analog parts of PAC1933. Otherwise I have no other ideas for hardware solution for now.
The issue seems to be completely unrelated to firmware side sampling rate, as PAC1933 maintains its own sampling rate internally.
In order to mitigate this problem, I suggest to:
The corner frequency of a filter should be high enough to meet user's expectations. Changes in current consumption should remain visible in real time, and the output would be well averaged across selected intervals. Longer intervals will render less noisy results, just like all measurement equipment does.
The text was updated successfully, but these errors were encountered: