No I used telnet as Tom mentioned above.
you need to run ultra sigma to load the drivers. I haven’t tried pure tcp/ip to send scpi, I can give that a try ...
ah, already confirmed.
I would appreciate a write-up on how you came up with this, if that's not too much work.
@Tossu, first of all great work!
![ThumbsUp :-+](https://www.eevblog.com/forum/Smileys/default/icon_smile_thumbsup.gif)
I also would appreciate some write-up on how you came to this, because this method is maybe applicable to other rigol gear as wel. I tried to use this on my DG1032Z (upgrade to DG1062Z) but after I send the SCPI-command the communication locked up (does not respond to *IDN? any longer) and had to reboot.
On my DP832 it worked flawlessly.
Copied file to FAT formatted empty USB stick, telnet to 5555 port and pasted:
:PROJ:SET MODEL,DP831A
Enter and reboot. Worked perfectly.
Thanks!
I also didn't get a response from the power supply via telnet when I did so. It may be worth to try another command that will return a value like for example:
:SYSTem:VERSion?
This should return "1999.0" (SCPI version on the device). If this works and you're sending the correct command, you should really check the USB drive you're using. I was successful with a quite old 8GB thumb drive labeled "Verbatim" that I also use for firmware updates. But I followed @tossu's instructions to format it and then only copy the provided file on it. Worked for both my DP832 and DP811.
Good luck,
Thomas
I also had issues with the first USB drive I tried. Formatted and copied the file onto it, stuck in back of DP832, connected with telnet, but when I would send the SCPI command, the screen on the DP832 would show something like "Incorrect command". I switched to an older 512MB verbatim USB drive, formatted, and this time when I sent the SCPI command I'm pretty sure the DP832 didn't show any indication it had worked (no message on the screen or beep), until I rebooted it. Once it was rebooted though I was able to change the display mode to the DP832A ones.
Thanks @tossu, that was brilliant!
A DP800 should reply
OK if the
:PROJ:SET MODEL,DP832A command was successful. It does that, if the command is sent from the USB interface. If it is sent from the LAN interface, it won't reply anything or accept new commands until the connection is closed.
:PROJ:SET is probably not meant to be used from LAN, and it might be crashing the server process.
I tried to use this on my DG1032Z (upgrade to DG1062Z) but after I send the SCPI-command the communication locked up (does not respond to *IDN? any longer) and had to reboot.
On my DP832 it worked flawlessly.
It might be working on DP800 by coincidence. Did you try to use the USB interface?
WOW, way nicer display, easier to read (DP832A/Classic).
https://www.albinoblacksheep.com/flash/thankyouTried the upgrade with a 4GB AData USB. Worked flawless.
The upgrade from DP832 to DP832A is reversible, can be set as you like at any time as long as the USB drive is plugged in. Did it by LAN. No OK response to the change model SCPI command, but it worked.
DP832
![](https://www.eevblog.com/forum/testgear/need-help-hacking-dp832-for-multicolour-option/?action=dlattach;attach=697248;image)
DP832A
![](https://www.eevblog.com/forum/testgear/need-help-hacking-dp832-for-multicolour-option/?action=dlattach;attach=697254;image)
To be honest, I didn't expect the color display to make such a big difference, yet it does. And the digits are not 7 segments any more, much easier to read now. Very nice surprise.
![Cheesy :D](https://www.eevblog.com/forum/Smileys/default/cheesy.gif)
After changing the model and powering it off/on again, pressed the 'Display' button then clicked 'Disp Mode' button until is selected 'Dips Mode: Classic', then pressed the 'Display' button again, and that's it.
DP832A
![](https://www.eevblog.com/forum/testgear/need-help-hacking-dp832-for-multicolour-option/?action=dlattach;attach=697260;image)
DP832A
![](https://www.eevblog.com/forum/testgear/need-help-hacking-dp832-for-multicolour-option/?action=dlattach;attach=697266;image)
Now, to upgrade to the latest firmware, too, what is the latest available for DP800, and how do I interrogate for the installed firmware version, please?
Now you all need to change the channel on LEDs to match the screens.
No need to change the LEDs. A simple highlight with marker will be enough.
It happened to me in the past to power up other channel than the intended one, so coloring the buttons and the banana plugs might not be a bad idea.
About the firmware update, the latest versions are:
- bootloader 01.09
- software 00.01.14.00.03
downloaded today from
https://www.rigolna.com/products/dc-power-loads/dp800/When asked for credentials, enter whatever.
To see the installed firmware details press 'Utility' -> 'Sys Info' -> 'M1' -> 'M3' -> 'M2'
Where M1...M5 are the buttons under the screen.
On both of my PSUs (DP832 and DP811), F/W 01.16.00.02 was installed prior to applying @tossu's patch via LAN. Worked without any problem.
Obviously, installing the new firmware after applying the patch will have to work because it's supposed to work on "official" DP800A devices as well. And it pretty much seems the patch turns a non-A instrument into an "A"-version without any (technical) difference to an official one (...maybe someone may start a business by offering the
"Hello Kitty" bezels for upgrade... )
![Laughing :-DD](https://www.eevblog.com/forum/Smileys/default/smiley_laughing.gif)
.
I just upgraded the firmware to DP800 00.01.16.00.02 2019-03-28 (for a DP832 transformed yesterday into DP832A using
tossu hack - thanks again, great finding).
The new firmware seems to be working fine, except the DNS address in the LAN settings (mine are set to manual LAN settings. After a power off/on cycle, the DNS will always point to
88.218.37.64 ![Confused :-//](https://www.eevblog.com/forum/Smileys/default/confused0024.gif)
!!!!! For Firmware DP800 00.01.16.00.02 2019-03-28 the DNS address seems hardcoded to 88.218.37.64 !!!!!
========================================================================================================
IP address 88.218.37.64 location
Country:Spain
Region:Madrid
City:Madrid
Longitude:-3.7026
Latitude:40.4165
Time Zone:Europe/Madrid
Postal Code:28050
IP Whois Information For 88.218.37.64
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '88.218.36.0 - 88.218.39.255'
% Abuse contact for '88.218.36.0 - 88.218.39.255' is '@airbnb.com'
inetnum: 88.218.36.0 - 88.218.39.255
netname: IE-AIRBNB-20181214
country: IE
org: ORG-AU44-RIPE
admin-c: ARA114-RIPE
tech-c: MA19860-RIPE
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-by: ie-airbnb-1-mnt
created: 2018-12-14T12:50:04Z
last-modified: 2018-12-14T12:50:04Z
source: RIPE
organisation: ORG-AU44-RIPE
org-name: AIRBNB IRELAND ULC
org-type: LIR
address: The Watermarque Building South Lotts Road, Ringsend
address: 4
address: Dublin
address: IRELAND
admin-c: ARA114-RIPE
tech-c: MA19860-RIPE
abuse-c: AR38143-RIPE
mnt-ref: ie-airbnb-1-mnt
mnt-by: RIPE-NCC-HM-MNT
mnt-by: ie-airbnb-1-mnt
created: 2016-10-31T08:25:02Z
last-modified: 2017-05-08T12:17:29Z
source: RIPE # Filtered
phone: +14157280000
person: Eoin Hession
address: The Watermarque Building South Lotts Road, Ringsend
address: 4
address: Dublin
address: IRELAND
phone: +14157280000
nic-hdl: ARA114-RIPE
mnt-by: ie-airbnb-1-mnt
created: 2016-10-31T08:25:01Z
last-modified: 2016-11-22T21:48:25Z
source: RIPE
person: Eric Lee
address: 888 Brannan Street, San Francisco, CA 94114
phone: +14087506453
nic-hdl: MA19860-RIPE
mnt-by: ie-airbnb-1-mnt
created: 2016-11-22T21:54:00Z
last-modified: 2018-12-14T09:08:49Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.93.2 (BLAARKOP)
Anybody else having problems setting the DNS address in the DP800 LAN settings, please?
Oh dear, seems you're also in Spain, Ireland and San Fran.
Oh dear, seems you're also in Spain, Ireland and San Fran. ![Clapping :clap:](https://www.eevblog.com/forum/Smileys/default/clap.gif)
I've never heard of this before. Care to explain?
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
I successfully hacked my DP832 and turned it into a DP832A. I didn't bother updating the firmware, so I'm still at 01.14. However, one quirk I found was that the USB stick has to be connected after the PSU have booted. It's not visible if the USB stick is plugged in when the PSU is turned off.
The PSU never gave me a response on the screen, even though the hack was applied. However, when I returned to the main screen (without rebooting I noticed the negative value of CH3. Somehow a minus sign has snuck in there. When I rebooted I was greeted with a colorful DP832A screen. The minus sign was gone.
Oh dear, seems you're also in Spain, Ireland and San Fran. ![Clapping :clap:](https://www.eevblog.com/forum/Smileys/default/clap.gif)
I've never heard of this before. Care to explain? ![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
Study the code in RoGeorge's post. ![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
That's no code, it's the result of a 'whois 88.218.37.64' search. Each routable IPv4 is stored in IANA (Internet Assigned Numbers Authority) database, together with some public information about the owner of the routable IP.
For whatever reason, my DP800 disregards my manual setting for the DNS address, and instead it always shows the 88.218.37.64 as a DNS, which seems to be some computer from Madrid. The company that has that computer with the IP 88.218.37.64 is 'Airbnb Ireland' from Doublin, and so on.
A DNS is used when a computer (in this case my DP832) wants to contact some other internet address by name. Changing the DNS or enforcing a DNS other than the desired one can be the sign of a security breach. I hope this is just a bug, and not a security threat.
Anybody with the latest FW and manual IP care to check the DP832 settings please? (to check press 'Utility' -> 'IO Config' -> 'LAN')
Do you have the DNS set to 88.218.37.64 after a power cycle, like this?
Anybody with the latest FW and manual IP care to check the DP832 settings please? (to check press 'Utility' -> 'IO Config' -> 'LAN')
Do you have the DNS set to 88.218.37.64 after a power cycle, like this?
I upgraded my DP832 to 1.16, and it is doing the same thing. The DNS is set to 88.218.37.64 when a "LAN connected" notification is shown. However, the value I've set is restored if I go back to the DNS settings. I noticed FW 1.14 changes the DNS as well, but it sets it to 0.0.0.0.
I took a quick look at a DG1032Z firmware I found somewhere. I think it's version 1.06. It has a very similar check for the same magic value at sector 0x78EC.
Could someone eager to hack (or brick) their DG1032Z send these commands to it, preferably via USB, and post the results here? The keyfile.bin I made for DP832 should work.
:PROJ:STAT MCALTIMES,QUERY
*IDN?
:PROJ:STAT MODEL,DG1062Z
*IDN?
The first command is just a sanity check. It should print
CH1 = <some number>, CH2 = <some number>.
No DG1032Z here.
Tried it on a DG4102 instead, over LAN, and ':PROJ:STAT MCALTIMES,QUERY' doesn't seem to be recognized. There is no reply over LAN, and the generator's screen shortly displays the message "Error generated by remote interface command!", which is the same message as the one displayed for any unrecognized SCPI command. After that, *IDN? is working just fine.
Also tried ':PROJ:STAT MODEL,DG4162' with the same result.
Tried it on DG4102 again, this time over USB, and the results are the same: no SCPI response, only an error message displayed on the DG4102 screen as it would be an unrecognized command, "Error generated by remote interface command!".
~$ echo "*IDN?" > /dev/usbtmc1; cat /dev/usbtmc1
Rigol Technologies,DG4102,DG4E17xxxxxx3,00.01.12
cat: /dev/usbtmc1: Connection timed out
~$ echo ":PROJ:STAT MCALTIMES,QUERY" > /dev/usbtmc1; cat /dev/usbtmc1
cat: /dev/usbtmc1: Connection timed out
~$ echo "*IDN?" > /dev/usbtmc1; cat /dev/usbtmc1
Rigol Technologies,DG4102,DG4E17xxxxxx3,00.01.12
cat: /dev/usbtmc1: Connection timed out
~$ echo ":PROJ:STAT MODEL,DG4162" > /dev/usbtmc1; cat /dev/usbtmc1
cat: /dev/usbtmc1: Connection timed out
~$ echo "*IDN?" > /dev/usbtmc1; cat /dev/usbtmc1
Rigol Technologies,DG4102,DG4E17xxxxxx3,00.01.12
cat: /dev/usbtmc1: Connection timed out
~$ #power cycled the DG4102 here
~$ echo "*IDN?" > /dev/usbtmc1; cat /dev/usbtmc1
Rigol Technologies,DG4102,DG4E17xxxxxx3,00.01.12
cat: /dev/usbtmc1: Connection timed out
~$
USB drive formatted FAT32, then copied only the 'keyfile.bin', plugged in the DG4102 at all times. When it was plugged in the first time, the USB drive was recognized just fine by the generator.
Tried it on DG4102 again, this time over USB, and the results are the same: no SCPI response, only an error message displayed on the DG4102 screen as it would be an unrecognized command, "Error generated by remote interface command!".
That is to be expected if hidden commands are not enabled by whatever switch DG4102 is using.
I'm afraid my hack can't easily be modified for the DG4000 series. Doesn't it have a Blackfin CPU like most of the older Rigol products? If it does, it has to use a different RTOS also. I'm using Ghidra which can't disassemble Blackfin code, and reverse engineering parts of the OS would take significant amount of time anyway. Although, if they are using the same kind of manufacturing process for the DG4000 series, it would probably be enough to get the magic value and sector from the application code.
I was able to decode the command table of DG4000 firmware. It has a
:PROJ:STAT command and some promising strings like MODEL and SN.