with computer control, with limitation
of current and voltage. The user interface is fairly comfortable. The input voltage can range up to 68V,
with output reaching a little below that.
Because it was needed. Sorely needed.
The Ruideng/Riden 60xx is a line of buck converters with computer control, with limitation
of current and voltage. The user interface is fairly comfortable. The input voltage can range up to 68V,
with output reaching a little below that.
The power supply is primarily designed for charging batteries.
), a fixed-frequency PWM SMPS controller
communication, via array of registers
The output has three terminals:
The battery voltage on the green terminal can be sensed, and when charging the green terminal is connected to the red terminal by an onboard relay.
The device is split to two boards; the power board and the control board.
The control unit is based on a STM32 microcontroller, handling primarily the user interface and the communication.
The communication between the control and power boards is done via a 16-pin header, primarily using scaled analog voltages both for the voltage/current limit settings and for reading the voltage/current/temperatures.
The PSU is controlled via a UART Rx/Tx line, using a MODBUS protocol. The hardware options are:
The stock comm software is provided as a phone app and a windows software utility.
The user interface is locked (small yellow lock on display) when the communication over serial line occurs. This can get somewhat annoying during hybrid manual-computer operation.
The communication is MODBUS-based. All the settings and measured values are stored in an array of registers, which can be read/written on demand.
[Sat Dec 9 12:41:05 2023] usb 1-1.2.3: new full-speed USB device number 11 using dwc_otg [Sat Dec 9 12:41:05 2023] usb 1-1.2.3: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice=80.33 [Sat Dec 9 12:41:05 2023] usb 1-1.2.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [Sat Dec 9 12:41:05 2023] usb 1-1.2.3: Product: USB Serial [Sat Dec 9 12:41:05 2023] usbcore: registered new interface driver usbserial_generic [Sat Dec 9 12:41:05 2023] usbserial: USB Serial support registered for generic [Sat Dec 9 12:41:05 2023] usbcore: registered new interface driver ch341 [Sat Dec 9 12:41:05 2023] usbserial: USB Serial support registered for ch341-uart [Sat Dec 9 12:41:05 2023] ch341 1-1.2.3:1.0: ch341-uart converter detected [Sat Dec 9 12:41:05 2023] usb 1-1.2.3: ch341-uart converter now attached to ttyUSB0
(obtained from some russian forum, for the RD6006 version)
To keep data in memory through power-off, the unit needs a backup battery. This is a CR1016 coin cell, somewhat uncomfortably hidden under the wifi board. It can be broken out to a CR2032 cell using a suitable holder and a piece of wire. Optionally, a rechargeable cell with a voltage regulator can be used.
Based on ESP-12F module (ESP8266EX).
(from top side)
(antenna)
(ESP-12F)
+5V o o GND
Tx o o EN\ (CH-PD)
Rx o o 3.3v (n.c.)
n.c. o o n.c.
In theory can be reflashed with manual shorting of RESET and GPIO0, actual attempt failed on some bootloader corruption (intentional? accidental? one-device only or affecting all modules?).
16
o--o 5..6.3V controller board power
to LED D8 comparator (out) o o Iset (controller out)
GND o o Vset (controller out)
batt conn. relay FET gate o o internal NTC to GND (3.3V pullup)
(3.3V pullup) NTC (to GND) o o input voltage (R divider)
(3.3V pullup) Vbat (Rdiv) o o Vmeas
GND o o Imeas
GND O o fan MOSFET gate control
1
antenna side
parts bottom
ENABLE\ 1 2 SOP8 pin7/Rx
GND o o SOP8 pin8/Tx
cap-to-gnd o o GND
x o o x
(5v) o o x
(5v) from main board, unconnected on module
ENABLE\ controls gate of P-MOSFET, switches power
Rx/Tx signals connected via switches(?), to avoid backfeed via logic when powered off
Bluetooth chip: JieLi POS221-28A2 = AC6328A (A2=2Mbit flash, A4=4Mbit)
same pinout: AC6368A
Vcc -1 8- USB0DP/Tx/ADC10/I2C_SDA
ADC8/PA9/LED - - USB0DN/Rx/ADC11/I2C_SCL
GND - - BTOSCO/XTALO 24 MHz
ANT/BT_RF -4 5- BTOSCI/XTALI
The Rx/Tx signals have 3.3v level. Can be directly connected to a wifi module, same kind as the RD6024. Or an ethernet-UART interface. Or anything-UART. Isolated interfaces (wireless, Ethernet...) are preferred.
Seems the wifi interface does not accept connections from the outside, but attempts to connect to the open port of the app, to the IP from where the wifi configuration was done. When this does not happen, the power supply hangs for a considerable while when powering up, which is somewhat annoying.
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
18:35:33.009805 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.219 tell 0.0.0.0, length 28
18:35:33.825453 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.219 tell 0.0.0.0, length 28
18:35:33.840730 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.219 tell 0.0.0.0, length 28
18:35:34.341841 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.219 tell 10.0.0.219, length 28
18:35:34.342582 IP (tos 0x0, ttl 1, id 2, offset 0, flags [none], proto IGMP (2), length 32, options (RA))
10.0.0.219 > 224.0.0.1: igmp v2 report 224.0.0.1
18:35:36.003982 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.101 tell 10.0.0.219, length 28
18:35:36.086659 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.101 is-at b4:6b:fc:bb:ab:4d, length 28
18:35:36.941197 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.101 tell 10.0.0.219, length 28
18:35:37.111342 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.101 is-at b4:6b:fc:bb:ab:4d, length 28
18:35:37.113303 IP (tos 0x0, ttl 128, id 3, offset 0, flags [none], proto TCP (6), length 44)
10.0.0.219.3724 > 10.0.0.101.8080: Flags [S], cksum 0x2ff4 (correct), seq 6511, win 2920, options [mss 1460], length 0
18:35:37.113665 IP (tos 0x0, ttl 128, id 4, offset 0, flags [none], proto TCP (6), length 44)
10.0.0.219.3724 > 10.0.0.101.8080: Flags [S], cksum 0x2ff4 (correct), seq 6511, win 2920, options [mss 1460], length 0
18:35:37.940367 IP (tos 0x0, ttl 128, id 5, offset 0, flags [none], proto TCP (6), length 44)
10.0.0.219.3724 > 10.0.0.101.8080: Flags [S], cksum 0x2ff4 (correct), seq 6511, win 2920, options [mss 1460], length 0
18:35:38.941319 IP (tos 0x0, ttl 128, id 6, offset 0, flags [none], proto TCP (6), length 44)
10.0.0.219.3724 > 10.0.0.101.8080: Flags [S], cksum 0x2ff4 (correct), seq 6511, win 2920, options [mss 1460], length 0
A python library for accessing the PSU registers.
https://github.com/Baldanos/rd6006
RD6012, RD6018 or RD6024 detected == Device Model : 6024.1 SN : 00011808 Firmware: 1.38 Input : 68.02V Temp : 24°C TempProb: -191°C == Output Voltage : 0.0V Current : 0.0A Energy : 0.0Ah Power : 0.0W == Settings Voltage : 12.0V Current : 1.0A == Protection Voltage : 62.0V Current : 24.2A == Battery Capacity: 0.0Ah Energy : 0.0Wh == Memories M0: 12.0V, 1.000A, OVP:62.0V, OCP:24.200A M1: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A M2: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A M3: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A M4: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A M5: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A M6: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A M7: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A M8: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A M9: 5.0V, 24.100A, OVP:62.0V, OCP:24.200A
Based on Baldanos rd6006, needs proper install:
(ordinary git clone and then manual exec of main.py results in "ImportError: attempted relative import with no known parent package")
allows loading new firmware into the STM32 chip, not tested yet
separate article: hw_SerialOverTCP
firmware on an esp8266 module
The TCP/UART bridge chosen for the MODBUS interaction was tried on the first UART. But it was colliding with nearly everything, and the chip was sending garbage on boot (well, sending data but for MODBUS it is garbage). On a kilowatt-class power supply, not worth the risk.
The second UART has a surprise in stock. The GPIO15, on which the Rx pin resides, has to be pulled low on reset, so the chip is configured to run from flash. During operation, it has to be pulled H. (Symptoms, everything worked until the chip was reset. Then the chip went "dead".)
On the Wemos Mini board, the GPIO15 is pulled down with a fixed 10k resistor.
So, a diode to rescue; schottky, anode on the pin, cathode to the outside. And, it works - slightly. In this direction the chip sends binary garbage. Quick check with a scope shows a nice rectangular signal on the diode cathode, and just thin spikes on the anode - only what gets through the diode's capacitance. A pullup is needed. But there is a pulldown and it must be there!
The solution? A switched pullup. A small 2k2 or 3k3 resistor between the D8/GPIO15 and D6/GPIO12. D6 set to "Output Hi" mode. That way the D6 is high-Z on power-up/reset, until the firmware initializes. Then it automatically gets high.
2k2 gives some reserve. 3k3 is pushing it a bit close to the datasheet guaranteed H level (0.75x Vcc).
2k2
GPIO12/D6 o-----/\/\/\---
| small schottky
GPIO15/D8 o--------------*-----|>|-----o
|
GND o-----/\/\/\---
10k, built-in
- https://sigrok.org/wiki/RDTech_RD_series
- python control
- python control of an artificial load