The future of OpenDPS

Johan DPS5005, OpenDPS, Software 26 Comments

Creating OpenDPS was a lot of fun and I am really enjoying seeing it in use on other peoples DPS:es. In this post I will elaborate on the future of OpenDPS, feel free to join the discussion in the comments below.

Architectural overhaul

The original OpenDPS firmware was “an application displaying a user interface allowing the user to set output voltage and current limit”. Over time the constant current mode was added due to popular demand 😉 Remote control is possible using dpsctl, a tool that “knows” what functions the OpenDPS firmware supports.

All that functionality still exists, but from a software architectural point of view the firmware today is completely different. With the recent UI overhaul, the firmware is “an application supporting functions and allowing the user to change parameters specific to these functions”. Sounds a bit dry, doesn’t it? The good news is that the “functions” implemented are CV and CC so the user will not notice things changed under the hood. Even better news is that it is now trivial to add new functions. The original CC mode was somewhat shoehorned into place while the rewritten one fit right into the software architecture. One new function I am thinking of is a signal generator.

Remote control

Remote control unfortunately is a bit broken at the moment. This is currently being fixed while performing some architectural changes to dpsctl too. My idea is that dpsctl should not have any knowledge about the functionality of the OpenDPS it controls. It will know about “functions”, “function parameters” and “activation/deactivation” of said functions. With this change there will be no need to maintain dpsctl when adding new functions to OpenDPS. Here is what it looks like right now on my local master:

% dpsctl -d 127.0.0.1 -F
Selected OpenDPS supports the cv and cc functions.

% dpsctl -d 127.0.0.1 -f cv
Changed function.

% dpsctl -d 127.0.0.1 -p v=3300 i=500

The commands above list the supported functions, selects constant voltage and sets output to 3.3V and current limit to 500mA. The OpenDPS will complain if the function does not exist or the parameters are incorrect.

Emulation

Did you notice the localhost IP address above? That was no typo, the OpenDPS firmware can now be run as a standalone application on your computer. This accelerates development of non hardware related application code and I am using it for the function and function parameter code right now. The emulator listens to UDP port 5005 and behaves just as an ESP8266 joined with a DPS. It additionally listens to UDP port 5006 where UI events can be injected:

% nc -u 127.0.0.1 5006
draw

This causes the emulator to draw an ascii version of the UI on its stdout (currently not that exciting)

0.00V
0.000A
0.0V

The parameter setting code is currently being worked on and I will push to GitHub it as fast as I can to restore remote control of OpenDPS. The function generator will arrive later this summer, its timeframe being weather dependent. Got any ideas for other functions? Let me know.

26 thoughts on “The future of OpenDPS”

  1. Evan L Allen

    constant current, constant voltage, function generator (I assume current and voltage, because why not) and remote control. I can’t seem to imagine anything else for this device to do. The remote control really gives it the expandability to do most anything. Maybe running a CC/CV battery charger? (lithium, nicd, nimh, lead…) you could run pre-set profiles and even add up the amount of current put into the battery (although no auto-discharge capability for fully characterizing it). The only thing to do now is to make it GPIB compatible…

    reply to comment →
    1. Tom G.

      Hi Evan,

      I was working with GPIB recently – raspberryPi with TI USB->GPIB, and linux-gpib.

      And it would likely be easiest to implement the GPIB using VISA TCP/IP / VX11, or a raw-socket.

      This is easy to do, as the ESP866 which is responsible for the WIFI communication addon, can support this without too much effort.

      Hope that helps, mainly stay away from implementing a physical GPIB addon to this if possible.

      reply to comment →
  2. Kjetil Trondsen

    When I saw that this module measures input voltage, output voltage and output current I was thinking it would be perfect as an MPPT solar charger. And with all the types of units it should be possible to find the right specs for a lot of solar panels.
    The CC and CV functions already implemented would do battery charging.
    What’s needed is to monitor input voltage and output power and regulate output current to make the input voltage closest possible to the maximum power point of the solar panel.
    The maximum power point (MPP in MPPT) is printed on the panels and could be inputted as an parameter, but the best solution is if the firmware tries to scan different input voltages (the T in MPPT stands for Tracking) to see witch one gives most output power. And repeat scanning (or just checking a little higher and lower input voltage to see if power increases or lowers) to compensate for different power output from the solar panel over time.

    With the display and configuration possibilities I think this could be one of the best small to medium MPPT chargers at the price range.

    reply to comment →
  3. Nestor Groel

    THANKS JOHAN FOR YOUR INCREDIBLE WORK!!!!

    These modules are awesome, I used it for months and now found your blog. THANKS!!!

    Are you testing the DPS 5020 modules? It will be VERY interesting!

    reply to comment →
  4. Ben

    Hey Johan, great work on OpenDPS and the new cleaned up architecture seems like a great way to go forward! I’m thinking about getting a DPS or maybe DPH 3205. Do you know if OpenDPS is compatible with the latter?

    reply to comment →
  5. Ben

    Oh and something else: is it possible to turn off or PWM-control the fan based on thermal losses? Those could probably be calculated based on the measurements from the eevblog host Dave Jones and eevblog forum member HKJ:

    http://lygte-info.dk/review/Power%20DPH3205%20UK.html
    http://lygte-info.dk/review/Power%20DPS5015%20UK.html

    Another possibility would obviously be to add a little PTC/NTC or even a PT100 and hardware-hack this thing. But that would probably be more effort as it’d require stuff like calibration too.
    All that obviously depends on the fan even beeing wired up in such a way that it could be controlled by the STM. Otherwise…more hardware-hacking I guess 🙂

    reply to comment →
  6. gnbl

    Thanks for sharing your efforts!

    I just got a DPS5015 and DPH5005.
    There seems to be surprisingly little hardware info on these RD DPS/ DPH power supply modules out there.
    So far I found
    https://github.com/kanflo/opendps/tree/master/hardware/reverse-engineering/dps3003 (KiCAD schematics)
    https://circuitmaker.com/Projects/Details/Damian-Thompson-2/DPH3205-Reverse-Engineer (proprietary schematics)
    https://github.com/kanflo/opendps/issues/50 DPS5015 PCB photos

    Hardware info in the code
    https://github.com/kanflo/opendps/blob/master/opendps/hw.c#L383
    https://github.com/kanflo/opendps/blob/master/opendps/hw.h
    https://github.com/kanflo/opendps/blob/master/ocd-client.py#L64

    which means that there seem to be a few pins unused.

    Microcontroller STM32F100C8T6B (C=48 pins, 8=64 Kbytes of Flash memory, T=LQFP -> medium-
    density device, LQFP48)
    Product page: https://www.st.com/en/microcontrollers/stm32f100c8.html
    Datasheet: https://www.st.com/resource/en/datasheet/stm32f100c8.pdf
    Reference Manual: https://www.st.com/resource/en/reference_manual/cd00246267.pdf
    Errata: https://www.st.com/resource/en/errata_sheet/cd00260217.pdf

    GPIO Pin usage on MCU, according to sources above
    1 VBAT
    2 PC13 power control on ‘5015
    3 PC14 NOT CONNECTED (DPS5015)
    4 PC15 NOT CONNECTED (DPS5015)
    5 OSC_IN NOT CONNECTED (DPS5015)
    6 OSC_OUT / PD1 -> U7.1 (SOT23-5, “M2Y8”)
    7 NRST NOT CONNECTED (DPS5015)
    8 V_SSA -> U7.5 (DPS5015)
    9 VCC
    10 PA0 (RL, U7.3 on DPS5015 and DHP5005)
    11 PA1 button M2
    12 PA2 button SEL
    13 PA3 button M1
    14 PA4 DAC1 V_set
    15 PA5 DAC2 I_set
    16 PA6 NOT CONNECTED (temp sensing on DPS5015?)
    17 PA7 ADC V_out
    18 PB0 ADC V_in
    19 PB1 ADC I_out
    20 PB2 BOOT1-GND (NOT CONNECTED on DPS5015)
    21 PB10 NOT CONNECTED
    22 PB11 power control on ‘5005 / fan control on ‘5015
    23 GND
    24 VCC
    25 PB12 TFT Reset (P4.4 on DPS5015 v2.3)
    26 PB13 TFT SPI SCK (P4.5 on DPS5015 v2.3)
    27 PB14 TFT CS (P4.6 on DPS5015 v2.3)
    28 PB15 TFT SPI MOSI (P4.7 on DPS5015 v2.3)
    29 PA8 [TFT, unused?] (P4.8 on DPS5015 v2.3)
    30 PA9 TX
    31 PA10 RX
    32 PA11 NOT CONNECTED
    33 PA12 NOT CONNECTED
    34 PA13 (SWDIO)
    35 GND
    36 VCC
    37 PA14 (SWCLK)
    38 PA15 not used in opendps? connected to current sense shunt and amplifier
    39 PB3 not used in opendps? connected to current sense shunt and amplifier
    40 PB4 button power
    41 PB5 button rotary encoder
    42 PB6 NOT CONNECTED
    43 PB7 TFT backlight
    44 BOOT0 (pull-down R12)
    45 PB8 rotary encoder
    46 PB9 rotary encoder
    47 GND
    48 VCC

    So that’s 7 GPIO that are not connected but could be soldered to (pin width=0.2 mm, pitch = 0.5 mm).
    Four accessible pins: RX&TX, SWDIO/SWCLK.
    And one pin to the TFT whose usage is unclear.

    Serial connector (DPS5015 V2.3, DPH5005 V1.1)
    1 GND
    2 TXD PA9
    3 RXD PA10
    4 VCC_U5

    Programming connector (DPS5015 V2.3, DPH5005 V1.1)
    12345
    1 VCC
    2 NC
    3 GND
    4 SWCLK / PA14
    5 SWDIO / PA13

    LCD connector (see below, also warning)
    12345678

    KEY connector (see below, also warning)
    12345678

    UI PCB V2.2

    FRONT

    M1 ENC
    SET TFT
    M2 ON/OFF

    BACK

    78
    56 (LCD PCB soldered in via pin header)
    34
    12

    12345678 LCD
    12345678 KEY

    Warning: because of the keying of the connectors, pin order is reversed on the mainboard (i.e. leftmost pins on mainboard connectors LCD and KEY are GND (=OUT-).

    LDC.1 7 PA8 [TFT, unused?]
    LDC.2 3 PB15 TFT SPI MOSI
    LDC.3 1 PB14 TFT CS
    LDC.4 5 PB13 TFT SPI SCK
    LDC.5 6 PB12 TFT reset
    LDC.6 2 VCC_U5
    LDC.7 4 Backlight (PB7)
    LDC.8 8 GND

    KEY.1 M2
    KEY.2 SET
    KEY.3 M1
    KEY.4 ON_OFF
    KEY.5 ENCODER PUSH
    KEY.6 ENCODER PHASE (via 1k resistor)
    KEY.7 ENCODER PHASE
    KEY.8 GND (rightmost pin as seen from plug)

    The mysterious component U7 with marking “M2Y8” (DPH5005) / “M2PQ” (DPS5015) next to the CPU on DPS5015 and DPH5005 looks like a SOT23-5 package.
    It does not appear to be a MEMS oscillator (OSC_IN not connected).
    U7.1 OSC_OUT (PD1)
    U7.2 GND
    U7.3 PA0 (ADC) – RL – R29 + PA6 (ADC)
    + RT1 – GND
    U7.4 VCC
    U7.5 GND

    opendps initializes these as
    PA0 GPIO_CNF_OUTPUT_OPENDRAIN
    PA6 –
    PD1 GPIO_CNF_OUTPUT_PUSHPULL
    but it appears they are not actively used.

    This dump (15V-on.txt from https://github.com/kanflo/opendps/issues/50#issuecomment-429578505) of a DPS5015 PCB revision V2.3 does this:

    PA0 GPIO_CNF_OUTPUT_OPENDRAIN
    PA6 GPIO_CNF_INPUT_ANALOG
    PD1 GPIO_CNF_OUTPUT_PUSHPULL

    Voltages at room temperature
    U7.1 PD1 3.3
    U7.2 GND
    U7.3 PA0 3.3
    U7.4 VCC 3.3
    U7.5 GND

    RL – R29 3.3
    PA6 (ADC) 1.78

    Forcing PA6 to 3.3 V does not start the fan – forcing it to GND does!

    Suspected component values:
    RT1 – 10k (room temp)
    R29 – 9k6 (“01C”)
    RL – 10k (“01C”)

    So,
    is U7 a voltage reference and might PD1 be used to enable the sensing (this could be tested with debugger; set low, U7.3 should go low)?
    PA0 could be used for a reference measurement, as the LQFP48 package does not have VREF but probably uses VDDA as ADC reference.

    That’s it for now…

    reply to comment →
  7. Jan

    Hi Johan

    Is there any chance at all you could consider releasing binaries?

    I hate to ask because I know it’s work but I’ve made some attempts to compile it under cygwin and it becomes a real pain (I just get heaps of gcc: error: unrecognized command line option ‘-mthumb’; did you mean ‘-mtbm’? and similar errors.)

    I noticed your notes on needing to upload the bootloader after the rest of the firmware so any notes on that would be appreciated but I am totally happy to do whatever else needs to be done.

    Thanks,

    Jan

    reply to comment →
  8. Elias

    Feature suggestion:
    – data logging via app or sdcard (is it possible to set samples per second?)
    – live graph (if not possible on the module, may be possible on the app?)
    – arbitrary voltage output (function generator)

    Also, any chance it will be compatible with (or implement similar capabilities to) RD6006?

    Cheers and congrats for the amazing work.

    reply to comment →
  11. Nils

    Hi Johan,
    I got myself a dps5005 and thanks to the good description I managed to flash it with opendps and it really works! Very excited that I have managed to make it work. And of course I want to thank you a lot for all your work and for developing a software which I feel is exactly right.
    I always wanted to have a power supply that I can control with a pc, or even wireless and now I see it’s even a lot cheaper than I thought.

    Great Project, great achievement. Thank you Johan!

    Best
    Nils

    reply to comment →

Leave a Comment

Your email address will not be published.

*
*