Comments (19)
fiechr
commented on September 15, 2024
$ cd libopencm3
$ make clean V=1
CLNHDR include/libopencm3/vf6xx/irq.json
CLNHDR include/libopencm3/lpc17xx/irq.json
CLNHDR include/libopencm3/lpc43xx/m0/irq.json
CLNHDR include/libopencm3/lpc43xx/m4/irq.json
CLNHDR include/libopencm3/sam/3a/irq.json
CLNHDR include/libopencm3/sam/3u/irq.json
CLNHDR include/libopencm3/sam/3n/irq.json
CLNHDR include/libopencm3/sam/3x/irq.json
CLNHDR include/libopencm3/sam/d/irq.json
CLNHDR include/libopencm3/sam/3s/irq.json
CLNHDR include/libopencm3/efm32/lg/irq.json
CLNHDR include/libopencm3/efm32/gg/irq.json
CLNHDR include/libopencm3/efm32/g/irq.json
CLNHDR include/libopencm3/efm32/tg/irq.json
CLNHDR include/libopencm3/lm3s/irq.json
CLNHDR include/libopencm3/stm32/f3/irq.json
CLNHDR include/libopencm3/stm32/l1/irq.json
CLNHDR include/libopencm3/stm32/f1/irq.json
CLNHDR include/libopencm3/stm32/f2/irq.json
CLNHDR include/libopencm3/stm32/l4/irq.json
CLNHDR include/libopencm3/stm32/f4/irq.json
CLNHDR include/libopencm3/stm32/f0/irq.json
CLNHDR include/libopencm3/stm32/l0/irq.json
CLNHDR include/libopencm3/stm32/f7/irq.json
CLNHDR include/libopencm3/lpc13xx/irq.json
if [ -d lib/stm32/f0 ]; then \
printf " CLEAN lib/stm32/f0\n"; \
make -C lib/stm32/f0 clean SRCLIBDIR="/home/cf/src/opendps/libopencm3/lib\" || exit ; \
fi;
/bin/sh: -c: line 3: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 5: syntax error: unexpected end of file
make: *** [Makefile:75: lib/stm32/f0.clean] Error 2
I think the backslash right before the " is the issue, since it escapes it.
So something in this line maybe:
SRCLIBDIR:= $(subst $(space),\$(space),$(realpath lib))
realpath on the shell gives me a correct path without backslash though...
I think I'm really close, but not there yet...
from opendps.
fiechr
commented on September 15, 2024
Ok, it seems to work by simply removing the insertion of the backslash.
#SRCLIBDIR:= $(subst $(space),\$(space),$(realpath lib))
SRCLIBDIR:= $(realpath lib)
from opendps.
fiechr
commented on September 15, 2024
Ok, building works fine now, as far as I can tell.
I've connected the PCB with a STLinkV2 and using other software I can read the chip ID and type, so the connection seems to be working (I've flashed STM8/32 type µCs before, so not a total noob).
But if I try to connect using openocd, like described in the howto/documentation, I get this:
$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
DEPRECATED! use 'swj_newdap' not 'hla newtap'
[... 331 lines more of that ...]
embedded:startup.tcl:265: Error: Infinite eval recursion
in procedure 'script'
at file "embedded:startup.tcl", line 26
in procedure 'swj_newdap' called at file "target/stm32f1x.cfg", line 38
in procedure 'hla' called at file "target/swj-dp.tcl", line 28
in procedure 'swj_newdap' called at file "embedded:startup.tcl", line 265
in procedure 'hla' called at file "target/swj-dp.tcl", line 28
[... 331 times the same over and over again ...]
at file "embedded:startup.tcl", line 265
Am I doing something basically wrong here?
from opendps.
kanflo
commented on September 15, 2024
Build problems with libopencm3 is probably handled more efficiently in the libopencm3 repo.
As for the OpenOCD issue I noted last week that the script syntax changed some time ago. The maintainers probably had good reasons but nevertheless it's a bit of a bother if you ask me. I guess you are using the scripts from the openocd dir of this repo. Try upgrading the scripts or downgrading the version of OpenOCD you are using.
from opendps.
fiechr
commented on September 15, 2024
Thank you for your reply!
I found out, that OpenOCD starts, when I first change into the opendps folder and run
openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
It doesn't work in the openocd/scripts folder (errors, see above post).
Now it seems to work as expected:
$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.210000
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections
I could then connect to port 4444 and erase the flash of the µC.
After that building and flashing a DPS3003 with firmware and bootloader worked also fine.
Still not exactly sure about the Makefile thing, but it seems to work just fine without the backslash.
Thank you for your work on this! :)
from opendps.
hseibel12
commented on September 15, 2024
I have a working DPS3003! If you like, I can send you my binaries for flashing. Also for me: It took some time to get it calibrated. I tried the method of dpsctl several times but did not succeed. Finally I wrote my own calibration software using VB.NET. The release I have been using is a little bit older (somewher in the middle of 2019 I think). Feel free to contact me again if you like!
Regards, Horst
from opendps.
fiechr
commented on September 15, 2024
Thank you for your offer, maybe I will get back to you about that!
Using dpsctl.py I've now completed the calibration process, but something is still off, the displayed input voltage jumps up and down, which it didn't do before. Also the display only flashes when I enable the output. But I will try it again.
At first I've used a generic USB to serial adapter (PL2303 IC) connected to RX/TX and some things worked (like --ping), but others don't. Now I've connected one of the "original" RDTech adapters (using a CH340 IC), which somehow seems to work better.
$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 --calibrate
For calibration you will need:
A multimeter
A known load capable of handling the required power
A thick wire for shorting the output of the DPS
2 stable input voltages
Please ensure nothing is connected to the output of the DPS before starting calibration!
Would you like to proceed? (y/n): y
Input Voltage Calibration:
Please hook up the first lower supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 2494
Please hook up the second higher supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 4992
Output Voltage Calibration:
Finding maximum output V_DAC value.......................... Done
Calibration Point 1 of 2, 10% of Max
Type measured voltage on output in mV: 3269
Calibration Point 1 of 2, 90% of Max
Type measured voltage on output in mV: 18653
Output Current Calibration:
Max output current of your DPS (e.g 5 for the DPS5005) in amps: 3
Load resistance in ohms: 10
Load wattage rating in watts: 100
Please connect the load to the output of the DPS, then press enter
Calibrating output current ADC............... Done
Constant Current Calibration:
Please short the output of the DPS with a thick wire capable of carrying 3.0A, then press enter
Finding maximum output A_DAC value.......................... Done
Calibrating output current DAC............... Done
Calibration Complete!
$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
A_ADC_K = 0.9988852143287659
A_ADC_C = -22.790977478027344
A_DAC_K = 0.0
A_DAC_C = 204.0
V_ADC_K = 8.156081199645996
V_ADC_C = -117.81263732910156
V_DAC_K = 0.2129485160112381
V_DAC_C = -287.1286926269531
VIN_ADC_K = -49959.9921875
VIN_ADC_C = 56819496.0
VIN_ADC = 1134
VOUT_ADC = 15
IOUT_ADC = 5
IOUT_DAC = 0
VOUT_DAC = 0
from opendps.
hseibel12
commented on September 15, 2024
When analyzing your calibration report I’ve found an error in two values:
VIN_ADC_K = -49959.9921875
VIN_ADC_C = 56819496.0
This are the values for input voltage calculation. They are expected to be much smaller than yours. In file dps_model.h you can find the values similar to your own specific device:
VIN_ADC_K shozld be around 16.8, means the max. calculatable input voltage is 16.8 * 4095 = 68.8V. DPS3003 are designed having an input voltage range of +6 … 40V.
And this is the second error I have found. The report shows input calibration voltages of ~ 2.5V and ~ 5V. Due to the specs of the device this is not enough!
Otherwise your reports also shows an output adc calibration voltage of ~3.2V and ~ 18.6V. That’s physically not possible because the DPS only has a step down converter.
I assume, your real input voltage is about 20V or higher?
So, please repeat your calibration. Appy the input voltage to your dps and measure this value with your DMM. Omit the smaller value and use it as 0.
Please find below as it should look now:
Von: Christian Fiebig ***@***.***>
Gesendet: Samstag, 29. Mai 2021 22:18
An: kanflo/opendps ***@***.***>
Cc: hseibel12 ***@***.***>; Comment ***@***.***>
Betreff: Re: [kanflo/opendps] unexpected EOF while looking for matching ... (#242)
Thank you for your offer, maybe I will get back to you about that!
Using dpsctl.py I've now completed the calibration process, but something is still off, the displayed input voltage jumps up and down, which it didn't do before. Also the display only flashes when I enable the output. But I will try it again.
At first I've used a generic USB to serial adapter (PL2303 IC) connected to RX/TX and some things worked (like --ping), but others don't. Now I've connected one of the "original" RDTech adapters (using a CH340 IC), which somehow seems to work better.
$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 --calibrate
For calibration you will need:
A multimeter
A known load capable of handling the required power
A thick wire for shorting the output of the DPS
2 stable input voltages
Please ensure nothing is connected to the output of the DPS before starting calibration!
Would you like to proceed? (y/n): y
Input Voltage Calibration:
Please hook up the first lower supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 2494
Please hook up the second higher supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 4992
Output Voltage Calibration:
Finding maximum output V_DAC value.......................... Done
Calibration Point 1 of 2, 10% of Max
Type measured voltage on output in mV: 3269
Calibration Point 1 of 2, 90% of Max
Type measured voltage on output in mV: 18653
Output Current Calibration:
Max output current of your DPS (e.g 5 for the DPS5005) in amps: 3
Load resistance in ohms: 10
Load wattage rating in watts: 100
Please connect the load to the output of the DPS, then press enter
Calibrating output current ADC............... Done
Constant Current Calibration:
Please short the output of the DPS with a thick wire capable of carrying 3.0A, then press enter
Finding maximum output A_DAC value.......................... Done
Calibrating output current DAC............... Done
Calibration Complete!
$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
A_ADC_K = 0.9988852143287659
A_ADC_C = -22.790977478027344
A_DAC_K = 0.0
A_DAC_C = 204.0
V_ADC_K = 8.156081199645996
V_ADC_C = -117.81263732910156
V_DAC_K = 0.2129485160112381
V_DAC_C = -287.1286926269531
VIN_ADC_K = -49959.9921875
VIN_ADC_C = 56819496.0
VIN_ADC = 1134
VOUT_ADC = 15
IOUT_ADC = 5
IOUT_DAC = 0
VOUT_DAC = 0
—
You are receiving this because you commented.
Reply to this email directly, <#242 (comment)> view it on GitHub, or <https://github.com/notifications/unsubscribe-auth/AMPLUQS7LQRV6KDMZGH54CLTQFDWDANCNFSM45O2L3WQ> unsubscribe. <https://github.com/notifications/beacon/AMPLUQXAGT2NGWK4SJJHGUTTQFDWDA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK3ZQVQ.gif>
from opendps.
fiechr
commented on September 15, 2024
Ok, I've re-run everything with the best multimeter I have, hooked on a 2.2 (2.27 to be exact) Ohms load with 100W for measuring and successfully completed the --calibrate process.
The input voltage is showing up stable now in the LCD and doesn't jump around anymore.
Unfortunately the device won't output any voltage or current when I enable it. I tried CV with 12 Volts, no output. Display shows 0V 0A (which is correct but not expected).
I also tried to power a bunch of LEDs with constant current (80 mA, Voltage set to max, in CC mode) -- also no output.
from opendps.
fiechr
commented on September 15, 2024
@hseibel12: You're right the input voltage I entered was nonsense! I repeated the above mentioned calibration with about 6.5 V and 19 V. I additionally measured the exact value with my DMM and put in the actually value.
from opendps.
hseibel12
commented on September 15, 2024
When analyzing your post I have found some mistakes in the calibration report! First please have a look to the file dps-model.h. The values for the input voltage calibration are to be expected somewhere like
Your values are much to high. I think you did an error with the input voltage calibration. Your values of approx.. 2.5 and 5 volts are much too low. The DPS3030 hat an input operation range of 6V to 40V DC. I had the same problems when trying to calibrate at the beginning.
from opendps.
fiechr
commented on September 15, 2024
This is the output I get now after calibration with the correct (and higher) input voltages (and all other) values:
$ dpsctl/dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
A_ADC_K = 1.0069375038146973
A_ADC_C = -83.07911682128906
A_DAC_K = -1.3510895155839012e-17
A_DAC_C = 245.0
V_ADC_K = 8.158334732055664
V_ADC_C = -119.56439208984375
V_DAC_K = 0.21321184933185577
V_DAC_C = -287.9895324707031
VIN_ADC_K = 16.752090454101562
VIN_ADC_C = 30.79538345336914
VIN_ADC = 1134
VOUT_ADC = 15
IOUT_ADC = 0
IOUT_DAC = 0
VOUT_DAC = 0
But as mentioned above, no output when enabled.
from opendps.
hseibel12
commented on September 15, 2024
The error is with the A-DAC_K. It should be around 0.12 not 0,00000000……
The formular for calculation is Amp = mx + b
x -> ADC-Count
m -> V_DAC_K
b -> V_DAC_C
this always calculates to around 0!
Von: Christian Fiebig ***@***.***>
Gesendet: Sonntag, 30. Mai 2021 11:53
An: kanflo/opendps ***@***.***>
Cc: hseibel12 ***@***.***>; Mention ***@***.***>
Betreff: Re: [kanflo/opendps] unexpected EOF while looking for matching ... (#242)
This is the output I get now after calibration with the correct (and higher) input voltages (and all other) values:
$ dpsctl/dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
A_ADC_K = 1.0069375038146973
A_ADC_C = -83.07911682128906
A_DAC_K = -1.3510895155839012e-17
A_DAC_C = 245.0
V_ADC_K = 8.158334732055664
V_ADC_C = -119.56439208984375
V_DAC_K = 0.21321184933185577
V_DAC_C = -287.9895324707031
VIN_ADC_K = 16.752090454101562
VIN_ADC_C = 30.79538345336914
VIN_ADC = 1134
VOUT_ADC = 15
IOUT_ADC = 0
IOUT_DAC = 0
VOUT_DAC = 0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#242 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPLUQTNM4TXV44KUSTYCQDTQIDHTANCNFSM45O2L3WQ> . <https://github.com/notifications/beacon/AMPLUQUBI7XS2I5GF74NKYDTQIDHTA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK4M6MY.gif>
from opendps.
fiechr
commented on September 15, 2024
Ok, I give up.
The calibration process also doesn't seem to work correctly.
I reset the calibration data and tried manually setting VOUT_DAC by pressing M1 + M2 and enter the value, but that also doesn't generate any voltage output. Not sure if this option is broken or I don't understand how it works. My idea was to measure the values manually and then calculate the K and C values. Like it is described here:
https://leo.leung.xyz/wiki/DPS5005
But if I enter for example 50 for VOUT_DAC and enable the output, it still shows 0 Volts (even after resetting all calibration data to the defaults, like the are in the dps-model.h).
I think I put it in the trash, buy a new one and keep using the original firmware. I may not be perfect but at least it works. ;-)
Also the dpsctl.py script somehow differs in behavior from the description on this page:
https://johan.kanflo.com/upgrading-your-dps5005/
I can change the function mode, calibrate and stuff like that, but can't set any voltage or current with --voltage 3000 for example, using the serial connection. I can enable the device and ping it, though.
Also the --status option doesn't work or doesn't exist (anymore?).
from opendps.
hseibel12
commented on September 15, 2024
I understand your frustration. Similar happened to me ….
Attached the binaries of my working device. If it generally works, I expect the calibration not being absolutely perfect. If this basically works, the reason should be in the version you are using or in the compilation process … But, if it does, I would not suggest to use the calibration routines of the distro. There are some reasons that may lead to your problems.
from opendps.
hseibel12
commented on September 15, 2024
Sorry, forgot to say:
My files are working at the former baudrate setting of 115200 Baud! You should not use the original converter because it does not work at this higher baudrate. (I’ve been using very successfully a DIY FTDI-version!). If the files basically work, I can make a 9600 Buad version for you. Here’s the makefile I have been using for my binaries:
BINARY = opendps
# Build with commandline interface rather than serial interface
COMMANDLINE := 0
# The baudrate used for serial communications, defaults to 115200
BAUDRATE ?= 115200
# Set build model, defaults to DPS5005
MODEL := DPS3003
# Include splash screen
SPLASH_SCREEN := 0
# Build wifi version (only change being that the wifi icon will start flashing
# on power up)
WIFI := 0
# Maximum current your DPS model can provide. Eg 5000mA for the DPS5005
# This is usually set by MODEL but you can override it here
#MAX_CURRENT := 3000
# Please note that the UI currently does not handle settings larger that 9.99A
# Print debug information on the serial output
DEBUG ?= 0
# Font file
METER_FONT_FILE ?= gfx/Ubuntu-C.ttf
METER_FONT_SMALL_SIZE ?= 18
METER_FONT_MEDIUM_SIZE ?= 24
METER_FONT_LARGE_SIZE ?= 48
FULL_FONT_FILE ?= gfx/ProggyClean.ttf
FULL_FONT_SMALL_SIZE ?= 16
# Color space for the DPS display. Most units use GBR but RGB has been spotted in the wild
COLORSPACE ?= 0
# Colors for the main UI elements -- see ili9163c.h for list of colors
COLOR_VOLTAGE ?= WHITE
COLOR_AMPERAGE ?= WHITE
COLOR_INPUT ?= WHITE
# Optional tinting for UI elements
TINT ?= ffffff
# Enable CC mode
CC_ENABLE ?= 1
# Enable merged mode
MERGED_ENABLE ?= 1
GIT_VERSION := $(shell git describe --abbrev=4 --dirty --always --tags)
CFLAGS = -I. -DGIT_VERSION=\"$(GIT_VERSION)\" -Wno-missing-braces
# Output voltage and current limit are persisted in flash,
# this is the default setting
CFLAGS += \
-DCONFIG_DEFAULT_VOUT=5000 \
-DCONFIG_DEFAULT_ILIMIT=500 \
-DCONFIG_BAUDRATE=$(BAUDRATE) \
-DCOLORSPACE=$(COLORSPACE) \
-DCOLOR_VOLTAGE=$(COLOR_VOLTAGE) \
-DCOLOR_AMPERAGE=$(COLOR_AMPERAGE) \
-DCOLOR_INPUT=$(COLOR_INPUT) \
-D$(MODEL)
# Application linker script
LDSCRIPT = stm32f100_app.ld
OBJS = \
flashlock.o \
bootcom.o \
crc16.o \
uui.o \
uui_number.o \
func_cv.o \
settings_calibration.o \
hw.o \
pwrctl.o \
event.o \
past.o \
tick.o \
tft.o \
spi_driver.o \
ringbuf.o \
ili9163c.o \
mini-printf.o \
gfx_lookup.o \
font-full_small.o \
font-meter_small.o \
font-meter_medium.o \
font-meter_large.o \
gfx-cc.o \
gfx-crosshair.o \
gfx-cv.o \
gfx-merged.o \
gfx-padlock.o \
gfx-power.o \
gfx-thermometer.o \
gfx-wifi.o
ifdef MAX_CURRENT
CFLAGS +=-DCONFIG_DPS_MAX_CURRENT=$(MAX_CURRENT)
endif
ifeq ($(DEBUG),1)
CFLAGS +=-DCONFIG_DEBUG
OBJS += dbg_printf.o
endif
ifeq ($(CC_ENABLE),1)
CFLAGS +=-DCONFIG_CC_ENABLE
OBJS += func_cc.o
endif
ifeq ($(MERGED_ENABLE),1)
CFLAGS +=-DCONFIG_MERGED_ENABLE
OBJS += func_merged.o
endif
ifeq ($(SPLASH_SCREEN),1)
CFLAGS +=-DCONFIG_SPLASH_SCREEN
endif
ifeq ($(WIFI),1)
CFLAGS +=-DCONFIG_WIFI
endif
ifeq ($(COMMANDLINE),1)
CFLAGS +=-DCONFIG_COMMANDLINE
OBJS += cli.o command_handler.o
else
CFLAGS +=-DCONFIG_SERIAL_PROTOCOL
OBJS += uframe.o protocol.o protocol_handler.o
endif
include ../libopencm3.target.mk
fonts:
@python ./gen_lookup.py -l -o gfx_lookup
@python ./gen_lookup.py -f $(FULL_FONT_FILE) -s $(FULL_FONT_SMALL_SIZE) -o full_small -a
@python ./gen_lookup.py -f $(METER_FONT_FILE) -s $(METER_FONT_SMALL_SIZE) -o meter_small
@python ./gen_lookup.py -f $(METER_FONT_FILE) -s $(METER_FONT_MEDIUM_SIZE) -o meter_medium
@python ./gen_lookup.py -f $(METER_FONT_FILE) -s $(METER_FONT_LARGE_SIZE) -o meter_large
test:
@make -C tests
doxygen:
@doxygen config.dox
from opendps.
fiechr
commented on September 15, 2024
I've added some debug messages to the dpsctl.py script and found something.
Near at the end of the calibration process, I get this (part of it):
Debug: Calculated DAC value: 204
Debug: iout_adc: 5 (sample #1)
Debug: iout_adc: 65534 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 4 (sample #4)
Debug: iout_adc: 65533 (sample #5)
Debug: iout_adc: 4 (sample #6)
Debug: iout_adc: 5 (sample #7)
Debug: iout_adc: 9 (sample #8)
Debug: iout_adc: 5 (sample #9)
Debug: iout_adc: 65534 (sample #10)
Debug: iout_adc: 5 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 1 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 5 (sample #15)
Debug: iout_adc: 65535 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 65534 (sample #18)
Debug: iout_adc: 4 (sample #19)
Debug: iout_adc: 5 (sample #20)
Debug: Average: 16387.1
Debug: Calculated DAC value: 204
Debug: iout_adc: 4 (sample #1)
Debug: iout_adc: 65534 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 65534 (sample #4)
Debug: iout_adc: 5 (sample #5)
Debug: iout_adc: 65533 (sample #6)
Debug: iout_adc: 65532 (sample #7)
Debug: iout_adc: 5 (sample #8)
Debug: iout_adc: 65535 (sample #9)
Debug: iout_adc: 5 (sample #10)
Debug: iout_adc: 4 (sample #11)
Debug: iout_adc: 1 (sample #12)
Debug: iout_adc: 5 (sample #13)
Debug: iout_adc: 0 (sample #14)
Debug: iout_adc: 4 (sample #15)
Debug: iout_adc: 4 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 4 (sample #18)
Debug: iout_adc: 5 (sample #19)
Debug: iout_adc: 4 (sample #20)
Debug: Average: 16386.4
Debug: Calculated DAC value: 204
Debug: iout_adc: 5 (sample #1)
Debug: iout_adc: 5 (sample #2)
Debug: iout_adc: 4 (sample #3)
Debug: iout_adc: 2 (sample #4)
Debug: iout_adc: 4 (sample #5)
Debug: iout_adc: 4 (sample #6)
Debug: iout_adc: 8 (sample #7)
Debug: iout_adc: 9 (sample #8)
Debug: iout_adc: 9 (sample #9)
Debug: iout_adc: 4 (sample #10)
Debug: iout_adc: 1 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 4 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 9 (sample #15)
Debug: iout_adc: 3 (sample #16)
Debug: iout_adc: 4 (sample #17)
Debug: iout_adc: 2 (sample #18)
Debug: iout_adc: 4 (sample #19)
Debug: iout_adc: 4 (sample #20)
Debug: Average: 4.75
Debug: Calculated DAC value: 204
Debug: iout_adc: 65535 (sample #1)
Debug: iout_adc: 6 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 6 (sample #4)
Debug: iout_adc: 5 (sample #5)
Debug: iout_adc: 1 (sample #6)
Debug: iout_adc: 4 (sample #7)
Debug: iout_adc: 65535 (sample #8)
Debug: iout_adc: 4 (sample #9)
Debug: iout_adc: 5 (sample #10)
Debug: iout_adc: 7 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 0 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 2 (sample #15)
Debug: iout_adc: 4 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 65534 (sample #18)
Debug: iout_adc: 5 (sample #19)
Debug: iout_adc: 65533 (sample #20)
Debug: Average: 13110.3
There are some "wrong" values, that mess up the average.
I wonder where they come from. I thought about removing the outliers, but that maybe only fix the symptom but not the actual issue.
All other readings seem to be fine:
For example:
Debug: Getting current reading at 4086.0000000000005 mV:
Debug: vout_adc: 594 (sample #1)
Debug: vout_adc: 595 (sample #2)
Debug: vout_adc: 595 (sample #3)
Debug: vout_adc: 595 (sample #4)
Debug: vout_adc: 595 (sample #5)
Debug: vout_adc: 594 (sample #6)
Debug: vout_adc: 596 (sample #7)
Debug: vout_adc: 594 (sample #8)
Debug: vout_adc: 595 (sample #9)
Debug: vout_adc: 595 (sample #10)
Debug: vout_adc: 595 (sample #11)
Debug: vout_adc: 595 (sample #12)
Debug: vout_adc: 595 (sample #13)
Debug: vout_adc: 594 (sample #14)
Debug: vout_adc: 595 (sample #15)
Debug: vout_adc: 596 (sample #16)
Debug: vout_adc: 596 (sample #17)
Debug: vout_adc: 595 (sample #18)
Debug: vout_adc: 595 (sample #19)
Debug: vout_adc: 596 (sample #20)
Debug: Average: 595.0
Debug: iout_adc: 2114 (sample #1)
Debug: iout_adc: 2112 (sample #2)
Debug: iout_adc: 2112 (sample #3)
Debug: iout_adc: 2114 (sample #4)
Debug: iout_adc: 2113 (sample #5)
Debug: iout_adc: 2116 (sample #6)
Debug: iout_adc: 2113 (sample #7)
Debug: iout_adc: 2124 (sample #8)
Debug: iout_adc: 2115 (sample #9)
Debug: iout_adc: 2117 (sample #10)
Debug: iout_adc: 2121 (sample #11)
Debug: iout_adc: 2113 (sample #12)
Debug: iout_adc: 2116 (sample #13)
Debug: iout_adc: 2113 (sample #14)
Debug: iout_adc: 2116 (sample #15)
Debug: iout_adc: 2122 (sample #16)
Debug: iout_adc: 2112 (sample #17)
Debug: iout_adc: 2113 (sample #18)
Debug: iout_adc: 2112 (sample #19)
Debug: iout_adc: 2115 (sample #20)
Debug: Average: 2115.15
or
Calibration Point 1 of 2, 10% of Max
Type measured voltage on output in mV: 3270
Debug: vout_adc: 416 (sample #1)
Debug: vout_adc: 415 (sample #2)
Debug: vout_adc: 415 (sample #3)
Debug: vout_adc: 415 (sample #4)
Debug: vout_adc: 415 (sample #5)
Debug: vout_adc: 415 (sample #6)
Debug: vout_adc: 415 (sample #7)
Debug: vout_adc: 415 (sample #8)
Debug: vout_adc: 416 (sample #9)
Debug: vout_adc: 415 (sample #10)
Debug: vout_adc: 415 (sample #11)
Debug: vout_adc: 415 (sample #12)
Debug: vout_adc: 415 (sample #13)
Debug: vout_adc: 415 (sample #14)
Debug: vout_adc: 415 (sample #15)
Debug: vout_adc: 415 (sample #16)
Debug: vout_adc: 416 (sample #17)
Debug: vout_adc: 416 (sample #18)
Debug: vout_adc: 415 (sample #19)
Debug: vout_adc: 416 (sample #20)
Debug: Average: 415.25
Calibration Point 1 of 2, 90% of Max
Type measured voltage on output in mV: 26430
Debug: vout_adc: 3254 (sample #1)
Debug: vout_adc: 3255 (sample #2)
Debug: vout_adc: 3255 (sample #3)
Debug: vout_adc: 3257 (sample #4)
Debug: vout_adc: 3257 (sample #5)
Debug: vout_adc: 3255 (sample #6)
Debug: vout_adc: 3257 (sample #7)
Debug: vout_adc: 3253 (sample #8)
Debug: vout_adc: 3256 (sample #9)
Debug: vout_adc: 3258 (sample #10)
Debug: vout_adc: 3257 (sample #11)
Debug: vout_adc: 3257 (sample #12)
Debug: vout_adc: 3255 (sample #13)
Debug: vout_adc: 3256 (sample #14)
Debug: vout_adc: 3258 (sample #15)
Debug: vout_adc: 3261 (sample #16)
Debug: vout_adc: 3257 (sample #17)
Debug: vout_adc: 3253 (sample #18)
Debug: vout_adc: 3256 (sample #19)
Debug: vout_adc: 3257 (sample #20)
Debug: Average: 3256.2
from opendps.
hseibel12
commented on September 15, 2024
I assume this is an integer error. Just do not know where it comes from but please have a look to the below calculation (I used the values of the second block):
Original
Interger
Correct values
4
0
4
65534
65536
-2
5
0
5
65534
65536
-2
5
0
5
65533
65536
-3
65532
65536
-4
5
0
5
65535
65536
-1
5
0
5
4
0
4
1
0
1
5
0
5
0
0
0
4
0
4
4
0
4
5
0
5
4
0
4
5
0
5
4
0
4
Average:
16386,4
2,4
I also have had errors with the original software. As the output of the step-down regulator contains noise which overlaps the DC-value we run into problems near zero:
If you subtract 1 from 0 the value of an 16 bit integer counts to 65535, on 2 it calculates 65534 and so on. This seems to be the result of an underrun error somewhere when subtracting an calibration offset from the adc-reading. See above table. I am sure the right column should be the correct values (Its’s average is 2.4 which is nearly Zero!). Logically this is much closer to your small DAC value (204). In your calibration the _DAC_C = 245.0 is the value for 0,00A.
I do not know where this happens. My workaround was modifying the original software mainly in the hw.c implementing a modified ADC_ISR and also averages for this values to reduce the impact of noise. If you like I can send you my files to look into and verify if this helps in your case.
from opendps.
cyber-murmel
commented on September 15, 2024
The original issue was also addressed in the libopencm repo libopencm3/libopencm3#1321
from opendps.
Related Issues (20)
- Blank screen on DPS3005 HOT 22
- White screen after flashing DPS5005 HOT 9
- wz5005e support possible? HOT 12
- Support Request: build/upload doesn't work HOT 1
- No respond beside ping over uart, calibration menu has no effect HOT 1
- Display is cut off at the bottom HOT 5
- What serial connector type does RuiDeng DPS5005 uses? HOT 3
- modbus
- Switching modes from the device HOT 3
- DPS5015 v2.6 Display blank HOT 2
- Support for DPH5005? Would be really useful because DPH can do StepUp
- remote control: show ascii strings to display from client
- Future of this project HOT 14
- Firmware HOT 4
- Support for Miniware MDP-XP HOT 1
- Rename master branch to main
- Weird behaviour DPS5015
- WZ3605E aka JL3605E-B (V1.0) Support, Buck-Boost, 36V, 5A HOT 2
- Feature request for Battery input power HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opendps.