So many words before but simple:
2 ----------------- 2
3 ----------------- 3
5 ----------------- 5
My recommendation is that cable is not long, only < 3 meters. Cable shield is good to connect only one end (to connector metal ground) and other end isolated..
Remember: 9600 baud, 8 bit, NO parity, 1 stop (not 1,5 or 2), no any kind of handshake. (very stupid but, this is Rigol way to do it)
Before try any mod, try communicate with scope (normal documented command) enough time. Watch all errors, if you see ANY error in communication (example missing answer from scope or corrupted data) As long as you find any kind of error in communicaton do NOT mod!)
If you see any or some errors after your training time then you need check PC - Rigol communication first. (one problem may be windows or computer RS232 port. (all RS232 ports are not good. Some are neraly or full out of original specifications. With other machines I have find this problem as long as there have be PC computers in world and I have make professional critical communication solutions lot of (mainly in old times
)
I recommend to use some kind of terminal software what can make Macros (you find many of these free in net)... so you make macro for whole strings what you need send. (this is good becouse if you need repeat you have ready strings and can not make typing errors)
Then you send it by one mouse click. (one for serial, one for model)
LF is always last character you send and remember also space is character!) LF is (decimal coded just as type with ALT 010) Some softwares read #010 for LF. (it is HEX coded 0A)
Also remember that there is NO any kind of handshaking. So Rigol RS port is open all times. If you connect cable there may be some garbage inside buffer allready waiting next LF. (Connect cable first then power on to Scope)
Go to system display just after you turn on scope. (do not send anything after power on in this time... )
In system window send these 2 mod commands (exactly as you have see and better to send them as "macro" string), you see that things what you send change in display. Just as you send. If they do not, if both or just one do not follow you... shut OFF!
(if you need repeat, even if example model or serial have already change as you want... you need send BOTH of these strings.
Do not touch anything (now RUN/STOP is red)
Send reset command.
Run/stop change green. (if uou now try use scope it do not follow any key)
Do not send anything to scope.
Just turn it off and then on.
If all is ok... nice... if not.. repeat (but first think if all serial communication is really ok and without ANY mistakes)
There are many other way also to do this what maybee are ok. I do it this way...becouse <censored>
I have experience of many mods with several 1052E's and still one machine do not work as others.. in this one machine serial numbers prefix (some numbers just after last letter in serial) is lot of different as others.
But main thing: If you are not sure how to do or you have not good gnowledge and experience with serial communications. Make first lot of training with normal documented commands with oscilloscope, it is very safe and it can teach you how to do. After you are sure that all works just exactly without errors then you can try mod more safe. Windows hyperterm is possible most bad terminal what you ever can find. (But also it can use but it need extremely careful becouse all you type all go to port)
For other communication solutions with windows and RS232 it is also good to read this Agilent note... (this is also qualid for Rigol's)
Problems Using RS-232 on Agilent Instruments with Laptop PCs running any Microsoft OS
Symptoms: Timeouts, corrupt data, missing data, error messages while uploading data
Cause: The RS-232 I/O chip (UART) used on PCs has only a 16-byte buffer. Without real-time flow control, it is possible for buffer overruns to occur, causing a loss of data. If the missing character happens to be a line feed, timeouts can result from the software never seeing the end-of-line terminator.Other missing characters can cause returned data to be wrong.
The Microsoft serial driver does not implement true hardware flow control. It implements all flow control in the software driver. This makes it susceptible to PCI-bus lockouts, higher priority interrupts and interrupt disables. The reason for the software-based flow control is historical, due to the very unreliable early hardware designs: there were a myriad of clones of the 16550 UART, most of them defective. The only solution for Microsoft was to develop a software driver that used as few features as possible, and hardware flow control was therefore done in the driver. Microsoft is unable to change the driver at this point to fix this problem.
The problem has been observed only on laptop PCs, perhaps due to software overhead associated with power management and/or PCMCIA adapters, but theoretically it could occur on desktop PCs too. Faster processors and slower RS-232 baud rates do not help enough to be a satisfactory workaround.
Resolution: Do not use RS-232 for mission critical applications. Instead (1) Consider using 34972A with USB and LAN connectivity built in OR (2) take advantage of the 34970A´s GPIB port.
The 82357A USB / GPIB converter can be connected to a USB port on the portable PC and to the GPIB port on the 34970A. This option will work with laptops that have USB, and Windows 2000, 98 SE, or XP. Windows 3.1, 95 and NT do not support USB.
Use an E5810A LAN to GPIB gateway. The gateway can be connected to the GPIB port on the 34970A then attached to the PC´s LAN (or directly to the PC´s LAN port). The LAN gateway is compatible with Windows® 98 (SE)/Me/NT/2000/XP.
Install a PCMCIA GPIB card. Several vendors supply PCMCIA GPIB cards and typically support Windows® 98 (SE)/Me/NT/2000/XP.
Switch to a desktop PC using a 82350B GPIB card or the 82357A USB-GPIB converter. The 82350A is compatible with Windows® 98 /Me/NT/2000/XP. The RS-232 problem has not been observed on a desktop PC - they use the same hardware and theoretically could have the same problem.
Note: Any of these choices will necessitate changes in your control program. Command strings remain the same, but the communications setups will need to be changed. The instrument mode can be changed programmatically using the SCPI command "SYSTem:INTerface {GPIB | RS232}" or via the front panel. In addition, any code used to initialize RS-232 parameters such as baud rate, parity, and flow control can be removed from the program. Code used to open the RS-232 port needs to be changed such that the GPIB interface is opened instead. This is done from Visual Basic via the commands:
Dim A_34970A As AgtIOServer
Dim iomgr As AgilentIOUtilsLib.AgtIOManager
Set iomgr = New AgtIOManager
Set A_34970A = io_mgr.ConnectToInstrument ("GPIB::9").
If the GPIB address must be changed to something other than the default (9), this can only be done from the front panel. Consult the manual for more information.
(yes, this is well known problem...)
Thank you Mr Bill Gates
Your pants are ....... in every corner with problems.