opendps
opendps copied to clipboard
kanflo
Device Specific Calibration
Not sure if this is an actual bug. But I got my DPS today flashed it with OpenDPS and was playing with it. I currently set the voltage to 5.00 and when I turn it on it drops down to 4.74 even with out a load attached? Is this normal/expected behavior?
It's because it's now an open loop system, this is also a thing I might want to fix
@geekbozu That would be unexpected behavior. Is 4.74V consistent between the display and when measured with a multimeter? Did you verify the functionality of the DPS with the original firmware?
@fromeijn Could you please explain "open loop system"?
With "open loop system" I mean, that the dac is set without reading it back. There is no PID controller of some sort between it.
From my measurements it was accurate. I will not lie how ever I did not verify before flashing I made sure an led lit up then flashed away. I did save the constants for 5V-On and OFF however.If it is any consolation the measurement of the input voltage also matches my power supply I am using. It does seems to be in agreement with what @fromeijn is saying. As the error is less drastic at lower voltages and gets worse as I get higher up.
On Thu, Oct 19, 2017 at 10:16 AM, fromeijn [email protected] wrote:
With "open loop system" I mean, that the dac is set without reading it back. There is no PID controller of some sort between it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kanflo/opendps/issues/17#issuecomment-337922044, or mute the thread https://github.com/notifications/unsubscribe-auth/AD6OiSjdOpJHpa5iEQvAok4Sdf8G-ItRks5st1nagaJpZM4P-mAL .
Thanks for the explanation @fromeijn. A PID controller would be very useful, I will create a new issue to track it.
So I quadruple checked. It seems that the on screen display is correct give or take .02v according to my multi-meter. Would using a feedback loop make more sense then say a per unit calibration? Would almost seem like its worth making a manual calibration function to tune each unit that way. (and to have power levels not have to adjust as much after initial turn on but PID to maintain underload)
A PID controller would be better IMHO as people have observed voltage drops at higher loads.
I think I was not clear. I more meant would a way to calibrate be useful In addition to the PID controller. Or do the devices seem accurate enough from the factory that the PID tuning should be quick enough to not matter. I know I have burned components up due to power supplies that jump to higher voltages on startup before settling down. So that is where my concern is from there.
Hmmm, you have a point there. The controller would have to be extremely quick to react to reductions in load as not to fry things. Calibration could be a better option for those not using higher loads.
Well the thought is you need both. One to handle initial startup/Hardware discrepancies, The PID to handle variations in Load + Drift. That being said I am more then willing to work on a calibration interface/setup if need be once the CC branch is merged (no point in starting another project on a split codebase IMO) and could probably tinker with the PID tuning if @fromeijn does not jump on that.
On Tue, Oct 24, 2017 at 5:31 AM, Johan Kanflo [email protected] wrote:
Hmmm, you have a point there. The controller would have to be extremely quick to react to reductions in load as not to fry things. Calibration could be a better option for those not using higher loads.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kanflo/opendps/issues/17#issuecomment-338931545, or mute the thread https://github.com/notifications/unsubscribe-auth/AD6OiXS2LNyMGHib41KdNa_VMgYTe1Ntks5sva5pgaJpZM4P-mAL .
Can confirm, with voltage set to 5.00V, it outputs 4.729V (and displays 4.71V)... At 34.60V set, the outpput is at 32.70V, so almost 2V difference. Not too nice ):
I'd also say that a calibration/offset setting would probably be better than a PID loop, which could overshoot and kill sensitive things...
Good suggestion, we don't want any magic smoke. So we need a calibration routine for voltage and current.
I guess I will start familiarizing my self with the code base. :D Seems like a worthwhile effort to me. EDIT: Looking at the CC branch it seems like default calibration constants per device have been broken out. Thats nice
Did anyone get somewhere with either self-calibration or PID? I have updated calibration values for my 5015. Both DAC and ADC.
I have been waiting for CC mode to be implemented to not fracture the code more before I started working on it, I do plan on implementing it soon that being said.
On Sat, Jan 13, 2018 at 8:41 PM, vogelfreiheit [email protected] wrote:
Did anyone get somewhere with either self-calibration or PID? I have updated calibration values for my 5015. Both DAC and ADC.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kanflo/opendps/issues/17#issuecomment-357481966, or mute the thread https://github.com/notifications/unsubscribe-auth/AD6OifAdoLpp8aYVPo9Zn3fPzb6wZYDrks5tKVtlgaJpZM4P-mAL .
So over time it seems my device has also lost its factory calibration. Im reading 7.8v when I supply it 5v.
5v out is only putting out like 3.3v
For OpenDPS devices there is no factory calibration but it seems a calibration function just got pushed up the TODO list.
I will dig into it a bit more once I have some time my self, and as noted I'll gladly tackle setting up some kind of calibration UI/scheme once the CC branch is "merged"
Adding a calibration UI scheme would be quite easy now as the UI supports different screens with editable widgets. See func_cv.c and func_cc.c.
My DPS5005 exhibited the same issue. Before flashing I had taken dumps at a few voltage levels, so I could work out the correct V_DAC_K and V_DAC_C settings:
#define V_DAC_K (double)0.0776
#define V_DAC_C (double)2.0
My mulitmeter, while not calibrated, showed voltages were spot on after this change. I then adjusted V_ADC_K so that the voltages displayed matched:
#define V_ADC_K (double)12.8891
I tested the open circuit voltage as well as under almost 5A of load, and the voltage was consistent. This suggests the issue is just a calibration one, and a PID is not required.
Late to the party, I will go through the comments.... glad other people are still working on this. I'm still working towards a successful dump of the original firmware :>
Can somebody please explain what does V_DAC_C and V_DAC_K means? I am trying to calibrate the DPS5005. Currently it is off by 300mV at 5V.
@Robin10155 It's the equation of the straight line describing the output voltage as a function of the DAC setting:
V_out = DAC_setting * V_DAC_K + V_DAC_C
See this spreadsheet. You can calibrate your unit by measuring V_out given a series of DAC settings and plotting the values.
From #48: "I see exactly the same behaviour wrt. output voltage on my new '5005. I will look into solving this at build time."
Could, At your leisure, Explain how to use the PAST library you have included as well as clarify the bug that is noted in your comments? I plan to get to this soon (finally) and want to make sure that we can save the configs to start >.>
With that would getting a command line based calibrator make more sense first? Or should we go for from panel interface-able calibration right off the bat?
And what do you think the best way to handle input DAC calibration is? rely on a separate "calibrated" set of reference points to power it by or is there a more sensible way? (havent looked at the hardware enough to know if the input voltage measurement is very different then the output and there fore really has the need for separate co-efficients.
The past library offers functionality for storing non volatile parameter data in flash. Eg. the voltage and current settings are stored when power is enabled meaning the user does not have to dial in these settings following the next power cycle. The bug relates to storing data < 4 bytes and until I get to that I should block storing of smaller units. I actually discovered another bug I am currently addressing.
A command line based calibrator is an excellent idea. dpsctl could be extended to support calibration by dialling one setting, allowing for the user to enter the actual output voltage, calculating the needed constants and writing these to past (the equivalent of the work done in this google sheet.
As the DAC is linear so two or three points should suffice (see the V_out tab in the linked google sheet).
Yeah that is what I was thinking instead of writing on on hardware ui to start.
Process something like such.
"Set Dac to value" -> User types in real value x2-3 times Once voltage is done, Ask user for Resistor value, -> set output voltage and measure current @ known value x2-3 times
Save and have a well calibrated output.
Input calibration will be a little trickier but not horrid. Working on this now starting with getting it to load constants from past then we can extend dpsctl.
I second both the PID controller loop idea and also having an UI "debug menu" of sorts (text screen is plenty good) that we could activate and do the calibration there. Adding a requirement for dpsctl means another layer of complexity and extra hardware when we could literally just do this with a barebones UI that takes Vin and Vout and perhaps Cin Cout and adjust things internally.
Nobody should use the firmware AS-IS with the built-in calibration constants because there is no guarantee whatsoever of those being accurate. These values are directly tied to the hardware. Every board will differ. The original firmware uses a PID loop if I am not mistaken.