This is an alternative firmware for the Riden WiFi module that provides Modbus TCP and SCPI support as well as a web interface.
It is geared towards easy remote control via both compatibility with standard lab automation tools, plus control and viewing of the essentials via its web interface.
It is not compatible with Riden's mobile app.
It supports the following Riden power supplies:
- RD6006 (might not work on the earlier china only versions, but supports the regular version)
- RD6012
- RD6018
- RD6024
- RD6030
- RD6006P
- RD6012P
The following is not yet integrated, as it is very new. If anyone has that model and can help testing, please get in touch.
- RD6018P
The firmware has been tested with various tools and libraries:
- Riden Firmware
- Riden v1.28
- Riden v1.41
- Riden v1.47 (6030)
- Unisoft v1.41.1k (6006)
- Unisoft v1.37.1p (6012)
- Modbus TCP
- Python pyModbusTCP library
- Python pymodbus library
- A modified version of ridengui with Modbus TCP support hacked in
- SCPI
- Modbus RTU client communicating with Riden power supply firmware.
- Modbus TCP bridge.
- SCPI control
- via raw socket (VISA string:
TCPIP::<ip address>::5025::SOCKET) - and via vxi-11 (VISA string:
TCPIP::<ip address>::INSTR).
- via raw socket (VISA string:
- Web interface to configure the dongle, update the firmware, and remote control, with graph functions.
- Automatically set power supply clock based on NTP.
- mDNS advertising.
- Handles approximately 65 queries/second using Modbus TCP or raw socket SCPI (tested using Unisoft v1.41.1k, UART baudrate set at 921600).
- When flashing the Riden WiFi module you will erase the existing firmware.
- The firmware provided in this repository comes with no warranty.
The regular Riden power supply firmware is considerably slower than UniSoft, handling less than 10 queries/second. It is probably best to keep the UART baud rate at or below 19200 for the regular Riden power supply firmware. With UniSoft's firmware you can go significantly higher.
An example test program can be found under /scripts/test_pyvisa.py
The VXI-11 channel (TCPIP::<ip address>::INSTR) is auto discoverable via mDNS, TCP and UDP, making it highly compatible with most tools.
While you use the VXI server, the raw socket server is disabled.
Note that when you use the web interface to kill a VXI-11 client, it will not properly inform the client. It will just kill the connection.
Raw socket capability cannot be auto discovered by pyvisa as of now. It can be discovered by lxi tools (see below)
When using the raw sockets (TCPIP::<ip address>::5025::SOCKET), you must, like with most other raw socket devices, use
inst.read_termination = "\n"
inst.write_termination = "\n"Also, be aware that when writing many commands to the device, the network layers and the device will queue them up. As a result, there can be a significant delay between the moment your client issues a command, and the moment the device handles the command. If you do not want that, insert a sleep of more than 150ms after each write command, forcing the network to send 1 command at a time. (the minimum delay depends on the configuration of your platform)
VXI-11 does not have this problem, since the commands are handled synchronously, and every command requires an ACK.
You will need the following:
- a Riden WiFi module (either the original one with ESP-12F, or the newer one with the ESP8684, which then must be retrofitted with an ESP-12F, see below).
- a computer with a serial link to flash the firmware (USB to TTL adapter, or similar).
- a soldering iron and some solder.
- 10k resistors. Depending on the module, you will need 1 or 2 at least. If you do not have 10k, any value between 4k7 and 47k will do.
- a 5V power supply
- some wires to connect to the modules' header pins.
- a WiFi network to connect the module to, using 2.4GHz b/g/n WiFi (the module does not support 5GHz WiFi, nor any recent security protocols).
You will need to make some changes to the dongle. The 2 most important being:
- do the adaptations listed below, depending on your dongle.
- program the dongle.
Either you solder on the needed components and pins directly to the WiFi module, either you put a small PCB on top of the ESP metal housing (do not cover the antenna!) with the required resistors and maybe buttons, and connect that PCB to the WiFi module.
Whatever you use, in order to program the device, you will need the following:
- power of course: 5V + GND (on the existing header).
- connect your serial link to GND, RX, TX (on the existing header)
- pull EN to 3V3 all the time via a resistor (10k). Take the 3V3 from the insides of the module, and not from the header, as some dongles do not have the 3V3 header pin connected.
- remove the EN pin from the header. If you have retrofitted a newer dongle, also remove the ISP pin.
- during boot, connect GPIO0 (aka PGM) to GND for a short period, and after that, pull it to 3V3 via a resistor (10k). A push button may be helpful here.
- not strictly needed, but helpful: a reset button connected to RST/RESET and GND. If used, programming will be easier, as there is no need for power cycling to do programming. To initiate programming, push both RESET and PGM, let go of RESET, and then let go of PGM.
Dongle with ESP-12F:
The original dongles used this module.
Lately there have been ESP-12F based dongles in a new form factor. They are difficult to obtain now.
Here is how to adapt it:
Dongle with ESP8684:
These are the newer dongles.
That ESP8684 is not supported, and is not likely to be supported soon, as Riden has flashed its own proprietary firmware on it and has encrypted it (the SPI_BOOT_CRYPT_CNT eFuse = 0b111). Unless we get access to their encryption key, we will not be able to flash it.
But you can make the dongle work by removing the ESP8684 and soldering a ESP-12F in place. Those WiFi modules can still be found. See here how to do it:
(the led on the board will not be used by the software)
Be aware that some sellers of Riden dongles may deliver you an ESP8684 dongle, even if their images show a ESP-12F on the dongle.
There are reports of retrofitting the newer dongles with a ESPC5-12E (see rdtech-esphome), which is an almost pin compatible ESP32 version of the ESP-12F. This firmware is not (yet) suited for that module.
Firmware files will be released on GitHub as part of the repository.
If you want to compile, you will need PlatformIO in order to compile the firmware.
No configuration is necessary; simply execute pio run and wait.
The firmware is located at .pio/build/esp12e/firmware.bin.
Provided you have prepared the hardware as described, and have either compiled, or downloaded a binary, you must connect the dongle to your computer as you would when flashing any other ESP12F module.
You can use multiple tools to flash the firmware. The most well known are:
- platformio
- esptool (also available without installation: https://espressif.github.io/esptool-js/)
Example with PlatformIO:
pio run -t upload --upload-port <ESP12F serial port>and wait for the firmware to be flashed.
Before re-inserting the module into your power supply,
it may be a good idea to make the necessary configuration
changes. You need to select TTL as the UART Interface mode,
9600 as the speed/UART baudrate, and (modbus) Address as 1 (the default).
Re-insert the module and power up the power supply.
At startup, the module will begin to flash, first slowly and then faster. If it starts flashing really fast (5 flashes per second), you probably misconfigured the power supply. Double-check, and if you are still having issues, add an issue to the Github repository.
The WiFi connection process is the same as with many other ESP based devices, and is handled by a module called WiFiManager. In essence:
The module wants to know your WiFi credentials. If it knew them from before, it will try to connect automatically. If not, it sets up its own WiFi, asks you to connect to it, shows a web page asking you to enter YOUR WiFi's credentials in there, and then it can connect to your WiFi.
If it did not have your WiFi credentials, the module will have created a new WiFi access
point, named RDxxxx-ssssssss or ESP_xxxx (xxxx is the model
and ssssssss is the serial number), e.g.
RD6006-00001234.
Connect to this access point, and you will be greeted by a web page (the technology's name is "captive portal") allowing you to configure the WiFi network that the module should connect to.
Notes:
Please be aware that some phones detect that there is no internet on that WiFi and fall back to another WiFi or to 4G/5G. That will cause the captive portal page to not show up. That is a common issue with captive portals, and not specific to this firmware. If that happens, either deactivate that 'feature' on your phone or quickly open a web browser and navigate to
http://192.168.4.1, and the configuration page should show up. Or use another phone/tablet/PC.
You should not need to enter any password in order to get to that configuration page, as the module's WiFi is open. If you are asked for a password before arriving on the web page, you likely have tried connecting to another WiFi. Double-check that you are connecting to the correct WiFi.
Don't be disturbed by the IP address of that configuration page, as it is on the dongle's Wifi, it has nothing to do with your WiFi network.
Follow the instructions, enter YOUR WiFi's credentials, and submit the form. The module will now try to connect to your WiFi.
If all goes well, the blue LED will start to flash slowly
after a short while, and eventually stop. You should now
be able to connect to the dongle at
http://RDxxxx-ssssssss.local. If that does not work, try
http://<ip address>, where <ip address> is the IP address of
the dongle on your WiFi. You can find that in your router's DHCP client list.
Make sure that you have set
- the 'UART Interface' setting to 'TTL' or 'TTL+EN'
- the 'UART Baudrate' to the same speed as you have set the dongle. 9600 is good for starters, but PSUs with Unisoft custom firmware can easily handle 115200
- the 'Address' setting to '1'
If you have the Unisoft custom firmware, the 'Server IP' is not used, as the dongle firmware will take care of that now.
Execute the command
lxi discover -mto get a list of discovered SCPI devices on the network.
This firmware sneakily advertised lxi support in order
for lxi-tools to recognise it.
Execute the command
lxi scpi -a RDxxxx-ssssssss.local -r "*IDN?"to retrieve the SCPI identification string containing power supply model, and firmware version.
Execute the command
lxi scpi -a RDxxxx-ssssssss.local -r "VOLT?"to retrieve the currently set voltage.
Invoke
lxi scpi -a RDxxxx-ssssssss.local -r "VOLT 3.3"to set the voltage to 3.3V
A description of the implemented commands is available in SCPI_COMMANDS.md.
The web interface is available under http://RDxxxx-ssssssss.local (see above). When using from a small screen (ex: mobile), it is best to use landscape mode.
The Home page shows general information about the PSU and information regarding remote connectivity and active remote connections.
The Details page shows more detailed information about the PSU status and configuration. In essence, it shows all information that can be read from the PSU, like voltage, current, and power settings and readings, but also the presets and the calibration data.
The Control web page allows remote control over:
- Voltage and Current setting
- Output On/Off
It also allows reading various values:
- Output values
- CV/CC mode, OVP/OCP protection
- temperatures
- ...
The output values are graphed (updated every second), and will allow different time scales and zooming in.
The Configure web page allows configuration of the time settings, the baud rate,
allows rebooting of the PSU or the module, but also allows OTA firmware updates
of the WiFi module (not of the PSU).
You may prefer to use OTA update instead of having to remove the module from the power supply and connecting it to a computer.
'Reboot Dongle' will reboot the WiFi module (not the PSU), and no data will be lost.
'Reboot Dongle to Web Configuration Portal' will take you back to the WiFi installation process. See First startup, and how to connect to your WiFi above.
The Riden power supply firmware has some quirks as described below. The firmware provided here err towards caution, and does not implement functionality that is known to be unreliable.
There is no way to reliably retrieve these values. If they are set by selecting a preset, M0 does not reflect the new values. If they are set via the front panel, M0 does reflect the new values.
Therefore I have decided NOT to support *SAV. *RCL is implemented.
The Preset register (19) only reflects the active preset if changed via the modbus interface. It is not updated if a preset is selected using the front panel. Therefore it is currently not possible to retrieve the selected preset.
Only 0 and 1 are recognised when setting the Language register. Reading the register matches the language set from the front panel.
It is not possible to control the keypad lock.
Note that when you have the Riden firmware, while you use remote control or the web server (and especially the Control page), the keypad is locked automatically. That lock will be released a couple of seconds after the last use.
Older versions of the UniSoft custom firmware, before "1p", like RD6006 V1.41.1k, return an inverted value for modbus register 69 (buzzer enabled).
The outcome is that, depending on the Riden firmware installed,
writing the register works as expected, but reading it back may
produce an incorrect result. Likewise the SCPI command
SYST:BEEP:STATE? may also return an incorrect value.
Riden standard firmware, and Unisoft "1p" versions and up, do not exhibit this issue.
- If your dongle is programmed, but you cannot connect to it, try setting the PSU's 'UART Interface' setting to 'WiFi' again to see if it now works (this is only for testing). If the dongle then reacts, you likely have not done all required hardware modifications, especially:
- the resistor to EN.
- removing/cutting the EN pin from the header.
- If your local network uses IPv6 or has multiple subnets that are not subdivided by
/24(255.255.255.0, "class C"), you may have problems connecting to it or have problems getting the correct time on the dongle and PSU. The dongle will expect IPv4, a subnet mask of255.255.255.0and a router + DNS server at address*.*.*.1. (it uses DNS for NTP, it will connect to pool.ntp.org) - In very rare cases, the dongle will not detect the PSU after a cold start. If that happens, reboot the dongle via the web interface (do not reboot the PSU), as will be shown anyway in the web interface.