Device Specific Calibration

[geekbozu]

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?

[fromeijn]

It's because it's now an open loop system, this is also a thing I might want to fix

[kanflo]

@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"?

[fromeijn]

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.

[geekbozu]

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 notifications@github.com 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 .

[kanflo]

Thanks for the explanation @fromeijn. A PID controller would be very useful, I will create a new issue to track it.

[geekbozu]

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)

[kanflo]

A PID controller would be better IMHO as people have observed voltage drops at higher loads.

[geekbozu]

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.

[kanflo]

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.

[geekbozu]

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 notifications@github.com 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 .

[Manawyrm]

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...

[fromeijn]

Good suggestion, we don't want any magic smoke. So we need a calibration routine for voltage and current.

[geekbozu]

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

[ghost]

Did anyone get somewhere with either self-calibration or PID? I have updated calibration values for my 5015. Both DAC and ADC.

[geekbozu]

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 notifications@github.com 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 .

[geekbozu]

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

[kanflo]

For OpenDPS devices there is no factory calibration but it seems a calibration function just got pushed up the TODO list.

[geekbozu]

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"

[kanflo]

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.

[antonblanchard]

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.

[ghost]

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 :>

[Robin10155]

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.

[kanflo]

@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.

[Robin10155]

Thanks for a quick reply. I will give it a slot.

[kanflo]

From #48: "I see exactly the same behaviour wrt. output voltage on my new '5005. I will look into solving this at build time."

[Xenoamor]

Thanks. If you find what is different on the schematic let us know!

[geekbozu]

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.

[kanflo]

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).

[geekbozu]

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.

[ghost]

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.

[geekbozu]

I already have my local copy loading constants from flash, I'm currently working on implementing a way to send the constants via DPSCTL, AKA learning how the commands are setup/implemented so i can make my own. Once that's functional I will be working on a UI wizard for it. Because I agree it needs something.

Once we have the ability to know out constants work across the voltage and amperage range we can/will work on some kind of run time adjustment.

[ghost]

I will help out with testing and code review, though I'm quite tight on time right now. PID loops tend to require careful design and development, it's not too difficult AFAIK but not trivial either. We have to keep in mind that any unpolished edges in this firmware means we leave people out with nearly broken PSUs.... it's a one way street to flash opendps for 99% of people.

I have to dig out the files when I was trying to exploit a flaw in STM32 (published in a paper quite some time ago) to trick the bootloader into allowing lower security levels to dump the original FW. Might be faster to just ask Ruideng for it though, but who knows... it's China. Known for exceptional customer service after-sales.

[geekbozu]

Well IMO even with out the PID loop the ability to calibrate the firmware alone will do leaps and bounds for it. And bring it back up to acceptable levels of use. More so the Current Calibration then the voltage. Most analog meters I own the displays are useless so we calibrate by hand with a multi-meter and load :) definitely moving in the right direction though!

Right now deciphering how commands are implemented is kicking my butt though. More code to read and process. heh.

[ghost]

Unrelated but: we could add MQTT capabilities to the ESP32 firmware. Not sure what is available and the code quality involved, but that would make it ridiculously useful for integration with all kinds of automation systems and metrics gathering. If some issues are ironed out, the whole package would rival (based on cost alone) pretty much anything else the average hobbyist could get his hands on.

[geekbozu]

Throw it in the SCPI support issue both would be pretty sweet

[geekbozu]

Hit a small snag where ATOF is using more memory then originally intended so I need to rework how dpsctl sends commands for calibration over. But progress is still happening. Slowly in my FORK

Reworked and now functional, Now I can start making it user interactive after a bunch of code cleanup :D

[Xenoamor]

Are there any downsides to moving from fixed point to floating point, I believe there's no floating point unit in the MCU?

Also I think there are a few lines like this: https://github.com/geekbozu/opendps/blob/c1edaaac687a703266e88f62cda0f17f033ca8cd/opendps/pwrctl.c#L275 that will lose the fractional part (i.e. 1.9 will become 1)

[geekbozu]

IMO not really it will be a bit slower but not really enough to matter for what we are doing. OCP is the only thing that will be really effected by it and OCP should be set to be more forgiving anyway then @ death point of the Device Under Load.

For the items like what was linked is not really ok but acceptable as depending on the case.

It is a value being sent to the dac and needs to be a whole number anyway. or Is a value where the LSB is 1mV, The floating point is to help with rounding/accuracy down to a few uV during calculations.

However they probably should be rounded instead of truncated so your "closer" to your real target. I'll adjust it later on if needed Not particularly relevant for this issue. Once Calibration is good we can automate some data logging to see how off it may be and if we need to make adjustments :)

[Xenoamor]

I believe Kanflo pre-calculates the OCP value with pwrctl_calc_ilimit_adc() and stores it in the variable pwrctl_i_limit_raw so speed shouldn't be an issue when it comes to this

I'd be happy to test the calibration stuff when it's ready as I have a DPS5005 that's currently ~0.2V off the correct values

[ghost]

How is this progressing?

[geekbozu]

Coming back around on the round robin soon. I need to make a "ui" still and that is really it for calibration you can manually specify the values if you know what they are with my version of DPSCTL.py (supposing I pushed the right version there was a small bug last I checked). Making a case for it then its back to making this work right so i'm not developing it on my lap.

[geekbozu]

https://imgur.com/a/WwTwlj2 Welp case is made. Really happy with it so now I can sanely get back to this. Hopefully I get some free time from work soon. Is it possible to update the boot loader with out the SWD wire-up? I really don't want to attempt to solder that backup any time soon if I don't have to.

Note: Line 120 in my fork Protocol.py needs to be "f" not "d" for anyone testing will be fixed in the next commit.

[geekbozu]

So I have gotten Output Voltage calibration working 👍 Input Voltage Calibration is next. Current/Constant current mode are after that.

If anyone wants to test I would be grateful. https://github.com/geekbozu/opendps/commit/a8d7248c63a8b69777929b5a6959c5ae0520c9af

code for dpsctl for calibration dpsctl.py -d comX -c

I added a re-init function incase your DPS gets really messed up, It reverts back to the constants supplied in dps-model.h the code for that is dpsctl.py -d comX --init

Thanks! Testing Binary

[geekbozu]

@kanflo is the formula for calibrating the V_IN ADC different then V_OUT? I cant seem to produce results that match real world using the current formulas, Nor do your spread sheets match the values supplied in pwrctl.c

I forgot to add in constants for VIN my apologies for the nag :)

VIN calibration is done, Wording is a little rough but it gets the job done. https://github.com/geekbozu/opendps/commit/1da1c1f8eab3db899b42696d3ccb18ea233ee3d4

Please use this binary to test it, The old/current firmware will not work! Testing Binary

Current display calibration is next, I am still trying to work out an easy and safe way to calibrate the current DAC.

Mental note: Ensure that Units are IN CV mode for current calibration steps.

[Xenoamor]

This is great! Thanks so much. I'll be sure to test this as soon as I'm back from an international work trip

Looking over the code you need to connect known voltages to the output terminals? And then known loads?

[geekbozu]

Kinda, For input voltage calibration we need to get a reference point on the ADC, We do that by feeding a known voltage to then INPUT on the DPS we can get known ADC values to compute our coefficients.

I am currently still debating on how I want to handle current calibration, I might have a way to handle both CC and Current display in one shot. I'm looking over if it will work well for us. :)

I Know i need to fix up the wording but thats kinda the last feature to me. We shall see what happens. I would love feed back on that once some testing has been done.

[kanflo]

Really cool work @geekbozu, hoping to try this out tomorrow!

[geekbozu]

Awesome the code needs a lot of clean up still I tend to do a clean up pass at the end. This code really needs it. Just a re-iteration,

• Input Voltage Calibration
• Output Voltage Calibration are the only modes that work Current Calibration has text and some boilerplate but should not do anything meaningful as of now. I have to re-write it after performing some test on my end, I should be able to use a multi-meter in series to calibrate both CC mode and Current Display in one pass.

As of now I am not planning on doing an ON device guided calibration, I may however make a device calibration display. That shows the current ADC/DAC values and lets you scroll through/edit the saved Co-efficents. I feel like that is enough of a on device system needed.

[ghost]

I'll try this over the weekend! I might need to look into soldering a ESP32 directly to the UART and have some sort of bridge or such for this purpose. Anyone has any custom firmware they recommend? It could be useful to have graphing or data output from the PSU (maybe fake SCPI?).

[geekbozu]

It is not wired up in the pictures but in mine I got a USB bulkhead adapter and wired up a USB -> Serial adapter for mine. https://imgur.com/a/WwTwlj2 You can see the bulkhead in the last picture.