Open Xenoamor opened 5 years ago
In my opinion this is how the ADC ISR should look:
void adc1_2_isr(void)
{
#ifdef CONFIG_ADC_BENCHMARK
if (adc_counter == 0) {
adc_tick_start = get_ticks();
}
#endif // CONFIG_ADC_BENCHMARK
ADC_SR(ADC1) &= ~ADC_SR_JEOC; /** Clear Injected End Of Conversion (JEOC) */
i_out_adc = adc_read_injected(ADC1, adc_cha_i_out + 1); // Yes, this is correct
v_in_adc = adc_read_injected(ADC1, adc_cha_v_in + 1); // Yes, this is correct
v_out_adc = adc_read_injected(ADC1, adc_cha_v_out + 1); // Yes, this is correct
adc_counter++;
/** Check to see if an over current limit has been triggered */
if (pwrctl_i_limit_raw) {
if (i_out_adc > pwrctl_i_limit_raw && pwrctl_vout_enabled()) { /** OCP! */
handle_ocp(i_out_adc);
}
}
/** Check to see if an over voltage limit has been triggered */
if (pwrctl_v_limit_raw) {
if (v_out_adc > pwrctl_v_limit_raw && pwrctl_vout_enabled()) { /** OVP! */
handle_ovp(v_out_adc);
}
}
}
Also what is ADC_CHA_IOUT_GOLDEN_VALUE
used for?
We could try to remove STARTUP_SKIP_COUNT
but reading the old comments (glad I wrote 'em) I am thinking we might still need them. My first DPS was actually calibrated but still required the ADC zeroing as I saw quite a current surge when the output was enabled. OTH there has been lots of HW improvements on the DPS:es so this might not be needed anymore. If removed though, I will try on my older DPS:es as I would not want to break support for the golden oldies.
ADC_CHA_IOUT_GOLDEN_VALUE
is definitely obsolete now that we have proper calibration.
Okay this makes sense. There's no real downside to leaving a lot of this code in there. Although removing ADC_CHA_IOUT_GOLDEN_VALUE
does make sense now
Here some ideas and experiences about calibration precision and experience for my DPS3003.
I have been trying to calibrate my DPS3003 and run into some issues as described in #130 (also refer to #147). I ended up using Xenoamor's suggestion about the adc1_2_isr(void) ISR for my DPS3003 and removed the STARTUP_SKIP_COUNT. I thought I would not need the zeroing because we now have a calibration routine. But I could not get good results using the python script (#130). This lead to my own calibration routines written in VB.NET where I could do the single steps of a calibration not neccessarily in an automated chain but being able to repeat them as much as I needed. Finally I've got a good calibration result. Voltage is rather accurate and current quite good. From my opinion the DPS3003 is more noisy as the DPS5005. And we should consider of the bad calibration span for the I_DAC. Current only uses a small range of the DAC's resolution and this is the reson why we can't get a precise and stable current. I remebered about average building in measurement tasks for noisy signals and have implemented a floating average buffer for the raw values in adc1_2_isr to get a smooth average for the values. I ended up with the following overall results:
U_IN is 28V from my external power-supply Max. Uout is 24V, max. Iout is 3.1A (I used 3.1A to avoid OCP-Event at 3.0A) Due to resolution of DACs and a small drop in precision of the internal DC-DC-converter my final precison is: output volatges < 10V @ I (1 - 2.8A): dUout = 1,3 - 2.6%, dIout <= 0.25% output voltages > 10-24V @ R=1Ohm dUout < 1%, dIout < 2%
So overall, I built-up my power-supply 0-24VDC, max. 3A @ global precision < 2%
I have been trying to calibrate DPS3003 but without success. May be hseibel12 can publish VB.NET utility ?
Moin, I just searched why my DPS3005 runs in OCP when switching output to enable, with currentsettings leth than 400mA even without load. While digging in the sources I noticed that adc_counter in never initialized or set to a value, only incremented and heavily used in OCP processing. Bug or feature ?
Hi @fisherman-cp. As adc_counter
is a global variable it will be zeroed by the C runtime before main(...)
is called. This is different from local function variables that needs zeroing. The compiler will not complain about the former but definitely about the latter.
The DPS300x issue with OCP should be now solved in #226 with any normally obtained calibration parameters. See also https://github.com/kanflo/opendps/issues/147#issuecomment-774533362
Is the following code still necessary? https://github.com/kanflo/opendps/blob/bc665f3840c12b66808b7b3f871b2935865f60a9/opendps/hw.c#L290-L298
I have the impression that this is now not needed as any device calibration should account for this. It also causes the ADC to return values that aren't "true" and may differ on each startup
Of course we still want to have the OCP but the
adc_i_offset
value seems unnecessary