Rigol DS1052E nasty surprise!

[A Hellene]

Thank you Richard, I will!

Now, regarding the decisions not to open any of these entry-level designs, even if most of them are so similar that they seem to be products of extensive plagiarism, blame it to the standard myopic marketing departments most of the companies have, in global scale...


-George

[krater]

Thanks to Krater, who published an IDA plug-in for the BlackFin processor he wrote, I am attempting to reverse engineer the Rigol firmware. Actually, it is not as difficult as it sounds to be: I have quickly spotted four ELF headers that boot the FLASH memory contents into the SDRAM system memory space, using the internal processor Boot-ROM. Funny thing is that even though C-type identifiers can be spotted within the firmware, some small portions of it seem to have been written in pure assembly! Of course, I could be wrong in that because the compiler could be using ready-made assembly routines in the background, since the .ASM black arts seem to be too difficult for the newer breeds of "engineers," who do not feel the need to know the inner workings of things, to be exercised...


-George

Hey, cool work !
Maybee the pure assembly routines come directly from the virtual dsp linker libs. I think the firmware is compiled with virtual dsp 4.5. I started to work on a little apllication that makes flirt signatures from this libs, but have stopped to work more on the rest of the toolchain.

[A Hellene]

Thank you Krater,

On the other hand, I am a hardware guy; this makes me see software as a necessary evil I have to deal with!

Since the time I have in my hands to spare is limited these days, I have not made any significant progress. Anyway, I know that this is not much but here it is:

After a hardware reset, and if the the processor boot-mode pins BMODE1:0 == 0b01, code execution begins at address 0x2000.0000, where the FLASH memory lies attached to the processor's asynchronous memory bus interface.
Here are the first 212 bytes of code, directly executed after power up or a hardware/watchdog reset:

Code: [Select]

[...]
SRAM0:20000000 # ===========================================================================
SRAM0:20000000
SRAM0:20000000 # Segment type: Pure data
SRAM0:20000000 LOADER_00:      dd 0xFF800060           # First LOADER from RESET
SRAM0:20000004 _COUNT_00:      dd 4                    # LDR_01 at: 0x20000000 + 0x0004 = 0x2000000E
SRAM0:20000008 _FLAGS_00:      dw 0x10                 # Action: IGNORE
SRAM0:2000000A _BLOCK_00:      dd 0xAE
SRAM0:2000000E # ---------------------------------------------------------------------------
SRAM0:2000000E LOADER_01:      dd 0xFFA08000           # LDR_00 at: 0x20000000
SRAM0:20000012 _COUNT_01:      dd 0x98                 # LDR_02 at: 0x20000018 + 0x0098 = 0x200000B0
SRAM0:20000016 _FLAGS_01:      dw 0                    # Action: BLOCK_COPY
SRAM0:20000018 # ---------------------------------------------------------------------------
SRAM0:20000018
SRAM0:20000018 _BLOCK_01:
SRAM0:20000018                 [--SP] = ASTAT;         # Register-file preservation to the stack
SRAM0:2000001A                 [--SP] = RETS;
SRAM0:2000001C                 [--SP] = (R7:0);
SRAM0:2000001E                 [--SP] = (P5:0);
SRAM0:20000020                 [--SP] = I0;
SRAM0:20000022                 [--SP] = I1;
SRAM0:20000024                 [--SP] = I2;
SRAM0:20000026                 [--SP] = I3;
SRAM0:20000028                 [--SP] = B0;
SRAM0:2000002A                 [--SP] = B1;
SRAM0:2000002C                 [--SP] = B2;
SRAM0:2000002E                 [--SP] = B3;
SRAM0:20000030                 [--SP] = M0;
SRAM0:20000032                 [--SP] = M1;
SRAM0:20000034                 [--SP] = M2;
SRAM0:20000036                 [--SP] = M3;
SRAM0:20000038                 [--SP] = L0;
SRAM0:2000003A                 [--SP] = L1;
SRAM0:2000003C                 [--SP] = L2;
SRAM0:2000003E                 [--SP] = L3;
SRAM0:20000040                 P0.L = 0xa18;           # P0=0xffc00a18
SRAM0:20000044                 P0.H = 0xffc0;          # SDRAM Refresh Rate Control Register
SRAM0:20000044                       -> EBIU_SDRRC
SRAM0:20000048                 R0 = 0xfff (Z);         # RDIV = 0xFFF (slowest refresh rate)
SRAM0:2000004C                 W[P0] = R0;
SRAM0:2000004E                 SSYNC;
SRAM0:20000050                 P0.L = 0xa14;           # P0=0xffc00a14
SRAM0:20000054                 P0.H = 0xffc0;          # SDRAM Bank Control Register
SRAM0:20000054                       -> EBIU_SDBCTL
SRAM0:20000058                 R0 = 0x11 (Z);          # SDRAM enabled; size: 16 MB; column address width: 9 bits
SRAM0:2000005C                 [P0] = R0;
SRAM0:2000005E                 SSYNC;
SRAM0:20000060                 P0.L = 0xa10;           # P0=0xffc00a10
SRAM0:20000064                 P0.H = 0xffc0;          # SDRAM Global Control Register
SRAM0:20000064                       -> EBIU_SDGCTL
SRAM0:20000068                 R0.L = 0x998d;          # R0=0x998d
SRAM0:2000006C                 R0.H = 0x91;            # R0=0x91998d
SRAM0:2000006C                       -> 0x91998d
SRAM0:20000070                 [P0] = R0;
SRAM0:20000072                 SSYNC;
SRAM0:20000074                 P0.L = 0xa00;           # P0=0xffc00a00
SRAM0:20000078                 P0.H = 0xffc0;          # Asynchronous Memory Global Control Register
SRAM0:20000078                       -> EBIU_AMGCTL
SRAM0:2000007C                 R0 = 0x4 (Z);           # Asynchronous Memory Bank0 and Bank1 enabled
SRAM0:20000080                 W[P0] = R0;
SRAM0:20000082                 SSYNC;
SRAM0:20000084                 SSYNC;
SRAM0:20000086                 L3 = [SP++];            # Register-file restoration
SRAM0:20000088                 L2 = [SP++];
SRAM0:2000008A                 L1 = [SP++];
SRAM0:2000008C                 L0 = [SP++];
SRAM0:2000008E                 M3 = [SP++];
SRAM0:20000090                 M2 = [SP++];
SRAM0:20000092                 M1 = [SP++];
SRAM0:20000094                 M0 = [SP++];
SRAM0:20000096                 B3 = [SP++];
SRAM0:20000098                 B2 = [SP++];
SRAM0:2000009A                 B1 = [SP++];
SRAM0:2000009C                 B0 = [SP++];
SRAM0:2000009E                 I3 = [SP++];
SRAM0:200000A0                 I2 = [SP++];
SRAM0:200000A2                 I1 = [SP++];
SRAM0:200000A4                 I0 = [SP++];
SRAM0:200000A6                 (P5:0) = [SP++];
SRAM0:200000A8                 (R7:0) = [SP++];
SRAM0:200000AA                 RETS = [SP++];
SRAM0:200000AC                 ASTAT = [SP++];
SRAM0:200000AE                 RTS;                    # Return from Subroutine
SRAM0:200000AE # ---------------------------------------------------------------------------
SRAM0:200000B0 LOADER_02:      dd 0xFFA08000           # LDR_01 at: 0x2000000E
SRAM0:200000B4 _COUNT_02:      dd 2                    # LDR_03 at: 0x200000BA + 0x0002 = 0x200000BC
SRAM0:200000B8 _FLAGS_02:      dw 8                    # Action: INIT @ 0xFFA08000
SRAM0:200000BA _BLOCK_02:      dw 0x166
SRAM0:200000BC # ---------------------------------------------------------------------------
SRAM0:200000BC LOADER_03:      dd 0xFF800060           # LDR_02 at: 0x200000B0
SRAM0:200000C0 _COUNT_03:      dd 4                    # LDR_03 at: 0x200000C6 + 0x0004 = 0x200000CA
SRAM0:200000C4 _FLAGS_03:      dw 0x10                 # Action: IGNORE
SRAM0:200000C6 _BLOCK_03:      dd 0x1494C8
SRAM0:200000CA # ---------------------------------------------------------------------------
SRAM0:200000CA LOADER_04:      dd 4                    # LDR_03 at: 0x200000BC
SRAM0:200000CE _COUNT_04:      dd 0xFFFE               # LDR_05 at: 0x200000D4 + 0xFFFE = 0x200100D2
SRAM0:200000D2 _FLAGS_04:      dw 0                    # Action: BLOCK_COPY
SRAM0:200000D4 # ---------------------------------------------------------------------------
SRAM0:200000D4
SRAM0:200000D4 _BLOCK_04:      LINK 0x14;              # CODE XREF: sub_2000017A+6C
[...]
This is what happens there:
* LOADER_01 copies the _BLOCK_01 code chunk (that initialises the SDRAM and the FLASH memory interfaces) to the INSTRUCTION SRAM space at address 0xFFA0.8000
* LOADER_02 forces the processor to execute the _BLOCK_01 code at the INSTRUCTION SRAM space
* LOADER_04 copies the 65,534 following FLASH bytes to SDRAM at address 0x0000.0004
[...]
* LOADER_231 quits the Boot-ROM and starts program execution after having copied a last chunk of 15,800 FLASH bytes to L1 INSTRUCTION SRAM at address 0xFFA1.0000

Unfortunately, the piece of code at _BLOCK_01 cannot be found in the disassembly listings because it will be overwritten at some point by the LOADER_229, which fills the same address (0xFFA0.8000) with code of the main program.


By the way, Krater, I have updated the following files attached. The modified loader file hopefully displays correctly all the usable address space of the BlackFin. Can you add the processor's register definitions to the IDA loader?


-George

[scrat]

Of course, I could be wrong in that because the compiler could be using ready-made assembly routines in the background, since the .ASM black arts seem to be too difficult for the newer breeds of "engineers," who do not feel the need to know the inner workings of things, to be exercised...

-George

Great work, George! Your reverse engineering is really a teaching course.

As usual, things are not too difficult, for people who know the job

I feel a little bit inadequate with respect to older engineers (and I envy them) for my lack in many fields, including experience with assembly. The thing is that, nowadays, many times there are faster solutions (ready made libraries, C language itself) and it's not worth or even allowed to use assembly. I wrote assembly only for exercise, and didn't learn the tricks. Or maybe it's just my laziness... I promise myself that at least I'll take a look at the assembly my compiler generates, next time!

[firewalker]

I am guessing that pretty soon we will have an "open source" DSO! 

Keep rocking George!

Alexander!

Thank you Krater,

On the other hand, I am a hardware guy; this makes me see software as a necessary evil I have to deal with!

Since the time I have in my hands to spare is limited these days, I have not made any significant progress. Anyway, I know that this is not much but here it is:

After a hardware reset, and if the the processor boot-mode pins BMODE1:0 == 0b01, code execution begins at address 0x2000.0000, where the FLASH memory lies attached to the processor's asynchronous memory bus interface.
Here are the first 212 bytes of code, directly executed after power up or a hardware/watchdog reset:

Code: [Select]

[...]
SRAM0:20000000 # ===========================================================================
SRAM0:20000000
SRAM0:20000000 # Segment type: Pure data
SRAM0:20000000 LOADER_00:      dd 0xFF800060           # First LOADER from RESET
SRAM0:20000004 _COUNT_00:      dd 4                    # LDR_01 at: 0x20000000 + 0x0004 = 0x2000000E
SRAM0:20000008 _FLAGS_00:      dw 0x10                 # Action: IGNORE
SRAM0:2000000A _BLOCK_00:      dd 0xAE
SRAM0:2000000E # ---------------------------------------------------------------------------
SRAM0:2000000E LOADER_01:      dd 0xFFA08000           # LDR_00 at: 0x20000000
SRAM0:20000012 _COUNT_01:      dd 0x98                 # LDR_02 at: 0x20000018 + 0x0098 = 0x200000B0
SRAM0:20000016 _FLAGS_01:      dw 0                    # Action: BLOCK_COPY
SRAM0:20000018 # ---------------------------------------------------------------------------
SRAM0:20000018
SRAM0:20000018 _BLOCK_01:
SRAM0:20000018                 [--SP] = ASTAT;         # Register-file preservation to the stack
SRAM0:2000001A                 [--SP] = RETS;
SRAM0:2000001C                 [--SP] = (R7:0);
SRAM0:2000001E                 [--SP] = (P5:0);
SRAM0:20000020                 [--SP] = I0;
SRAM0:20000022                 [--SP] = I1;
SRAM0:20000024                 [--SP] = I2;
SRAM0:20000026                 [--SP] = I3;
SRAM0:20000028                 [--SP] = B0;
SRAM0:2000002A                 [--SP] = B1;
SRAM0:2000002C                 [--SP] = B2;
SRAM0:2000002E                 [--SP] = B3;
SRAM0:20000030                 [--SP] = M0;
SRAM0:20000032                 [--SP] = M1;
SRAM0:20000034                 [--SP] = M2;
SRAM0:20000036                 [--SP] = M3;
SRAM0:20000038                 [--SP] = L0;
SRAM0:2000003A                 [--SP] = L1;
SRAM0:2000003C                 [--SP] = L2;
SRAM0:2000003E                 [--SP] = L3;
SRAM0:20000040                 P0.L = 0xa18;           # P0=0xffc00a18
SRAM0:20000044                 P0.H = 0xffc0;          # SDRAM Refresh Rate Control Register
SRAM0:20000044                       -> EBIU_SDRRC
SRAM0:20000048                 R0 = 0xfff (Z);         # RDIV = 0xFFF (slowest refresh rate)
SRAM0:2000004C                 W[P0] = R0;
SRAM0:2000004E                 SSYNC;
SRAM0:20000050                 P0.L = 0xa14;           # P0=0xffc00a14
SRAM0:20000054                 P0.H = 0xffc0;          # SDRAM Bank Control Register
SRAM0:20000054                       -> EBIU_SDBCTL
SRAM0:20000058                 R0 = 0x11 (Z);          # SDRAM enabled; size: 16 MB; column address width: 9 bits
SRAM0:2000005C                 [P0] = R0;
SRAM0:2000005E                 SSYNC;
SRAM0:20000060                 P0.L = 0xa10;           # P0=0xffc00a10
SRAM0:20000064                 P0.H = 0xffc0;          # SDRAM Global Control Register
SRAM0:20000064                       -> EBIU_SDGCTL
SRAM0:20000068                 R0.L = 0x998d;          # R0=0x998d
SRAM0:2000006C                 R0.H = 0x91;            # R0=0x91998d
SRAM0:2000006C                       -> 0x91998d
SRAM0:20000070                 [P0] = R0;
SRAM0:20000072                 SSYNC;
SRAM0:20000074                 P0.L = 0xa00;           # P0=0xffc00a00
SRAM0:20000078                 P0.H = 0xffc0;          # Asynchronous Memory Global Control Register
SRAM0:20000078                       -> EBIU_AMGCTL
SRAM0:2000007C                 R0 = 0x4 (Z);           # Asynchronous Memory Bank0 and Bank1 enabled
SRAM0:20000080                 W[P0] = R0;
SRAM0:20000082                 SSYNC;
SRAM0:20000084                 SSYNC;
SRAM0:20000086                 L3 = [SP++];            # Register-file restoration
SRAM0:20000088                 L2 = [SP++];
SRAM0:2000008A                 L1 = [SP++];
SRAM0:2000008C                 L0 = [SP++];
SRAM0:2000008E                 M3 = [SP++];
SRAM0:20000090                 M2 = [SP++];
SRAM0:20000092                 M1 = [SP++];
SRAM0:20000094                 M0 = [SP++];
SRAM0:20000096                 B3 = [SP++];
SRAM0:20000098                 B2 = [SP++];
SRAM0:2000009A                 B1 = [SP++];
SRAM0:2000009C                 B0 = [SP++];
SRAM0:2000009E                 I3 = [SP++];
SRAM0:200000A0                 I2 = [SP++];
SRAM0:200000A2                 I1 = [SP++];
SRAM0:200000A4                 I0 = [SP++];
SRAM0:200000A6                 (P5:0) = [SP++];
SRAM0:200000A8                 (R7:0) = [SP++];
SRAM0:200000AA                 RETS = [SP++];
SRAM0:200000AC                 ASTAT = [SP++];
SRAM0:200000AE                 RTS;                    # Return from Subroutine
SRAM0:200000AE # ---------------------------------------------------------------------------
SRAM0:200000B0 LOADER_02:      dd 0xFFA08000           # LDR_01 at: 0x2000000E
SRAM0:200000B4 _COUNT_02:      dd 2                    # LDR_03 at: 0x200000BA + 0x0002 = 0x200000BC
SRAM0:200000B8 _FLAGS_02:      dw 8                    # Action: INIT @ 0xFFA08000
SRAM0:200000BA _BLOCK_02:      dw 0x166
SRAM0:200000BC # ---------------------------------------------------------------------------
SRAM0:200000BC LOADER_03:      dd 0xFF800060           # LDR_02 at: 0x200000B0
SRAM0:200000C0 _COUNT_03:      dd 4                    # LDR_03 at: 0x200000C6 + 0x0004 = 0x200000CA
SRAM0:200000C4 _FLAGS_03:      dw 0x10                 # Action: IGNORE
SRAM0:200000C6 _BLOCK_03:      dd 0x1494C8
SRAM0:200000CA # ---------------------------------------------------------------------------
SRAM0:200000CA LOADER_04:      dd 4                    # LDR_03 at: 0x200000BC
SRAM0:200000CE _COUNT_04:      dd 0xFFFE               # LDR_05 at: 0x200000D4 + 0xFFFE = 0x200100D2
SRAM0:200000D2 _FLAGS_04:      dw 0                    # Action: BLOCK_COPY
SRAM0:200000D4 # ---------------------------------------------------------------------------
SRAM0:200000D4
SRAM0:200000D4 _BLOCK_04:      LINK 0x14;              # CODE XREF: sub_2000017A+6C
[...]
This is what happens there:
* LOADER_01 copies the _BLOCK_01 code chunk (that initialises the SDRAM and the FLASH memory interfaces) to the INSTRUCTION SRAM space at address 0xFFA0.8000
* LOADER_02 forces the processor to execute the _BLOCK_01 code at the INSTRUCTION SRAM space
* LOADER_04 copies the 65,534 following FLASH bytes to SDRAM at address 0x0000.0004
[...]
* LOADER_231 quits the Boot-ROM and starts program execution after having copied a last chunk of 15,800 FLASH bytes to L1 INSTRUCTION SRAM at address 0xFFA1.0000

Unfortunately, the piece of code at _BLOCK_01 cannot be found in the disassembly listings because it will be overwritten at some point by the LOADER_229, which fills the same address (0xFFA0.8000) with code of the main program.


By the way, Krater, I have updated the following files attached. The modified loader file hopefully displays correctly all the usable address space of the BlackFin. Can you add the processor's register definitions to the IDA loader?


-George

[A Hellene]

Thank you, guys!


scrat, I am sorry but I do not feel that "I know the job!" I am just better at it today that what I was yesterday. Practice makes you better! For example, until recently the term Blackfin reminded me of that lovely tuna fish! It is not more than a few weeks that I begun studying the ADSP family literature in my spare time, which makes me once more a humble student with some sort of control of my spare time. How far and deep I will go with the Blackfin processor is up to me.

As for the assembly language, you are right: You are not even allowed to use it! The question is, why. Because it is not as portable as C? Of course not! This is just a sorry excuse --code portability is yet another euphemism! Just imagine what happens to a series of products developed in .ASM by a retired or a fired engineer when the industry is unable to find an equally or better skilled replacement to fill in his empty seat... The actual reason is more crude than the euphemism above: Speed, in terms of project-to-market delivery times in order to catch up with the competition at the expense of the quality of the products; and the skills* required in corporate environments, or the lack of skills if we want to be more precise. See the MISRA C coding standard, born out of the auto/motor industry in 1998: It will restrict you from directly accessing any lower level hardware recourses but it will not make you write better programs; a bad programmer will always be producing bad code, no matter what!

Anyway, whatever the tool-set of your choice is, practice is what will make you reach perfection.

( * ) Just look at the quality of the "engineers" the educational institutions spit out today. Their eduction is oriented rather in their marketing skills than in actual Electrical Engineering. Quoting a friend of mine, "The only engineers who get promoted to management are the ones who can be spared. The real walking disasters are the ones who think they got promoted because they were good."
__________


Alexander, Though I like the idea, it belongs -more or less- to the realm of wishful thinking... One of the practical reasons I can think of right now is spare time --or the lack of it...


-George

[scrat]

[...]
See the MISRA C coding standard, born out of the auto/motor industry in 1998: It will restrict you from directly accessing any lower level hardware recourses but it will not make you write better programs; a bad programmer will always be producing bad code, no matter what!

Besides the importance of looking at how the things work inside, a well-written C code is not bad, and since I'm usually on the control algorithm side, I like producing and dealing with a structured code, where you can easily recognize a control block. And some of the stupid errors that make you loose time could be avoided by a simple rule check. Could MISRA (or similar sets of rules) be just a tool? BTW, I know of some companies walking towards automatic code generation from "schematics" entry...

We are pushed to learn and work on just few things, hardware vs. firmware, low-level drivers vs. high-level software... Most of the system solutions are the same and, besides other things, creativity suffers IMHO.

( * ) Just look at the quality of the "engineers" the educational institutions spit out today. Their eduction is oriented rather in their marketing skills than in actual Electrical Engineering. Quoting a friend of mine, "The only engineers who get promoted to management are the ones who can be spared. The real walking disasters are the ones who think they got promoted because they were good."

I'm proud of not having studied much of marketing and management, although it's necessary to know something in those subjects (to know the "enemy" ).
There's also a "theory" according to which the management people must be inferior technicians because otherwise they won't ask the real technicians to do the impossible... 

[MirceaI]

Hi there,

any news related to this ugly noise problem?
My ds1052 noise look quite the same the photos in the first post.
Did anyone solve this problem?

[torch]

What firmware version does your scope have?

[MirceaI]

firmware version 3.01

[torch]

Then it's probably not a software issue. So far everything seems to point to a hardware issue for others too. I think earlier in this thread, it was suggested that the probem may be related to either incorrect PCB etching or excessive flux. If you bought yours from an authorized retailer and have not opened it up, I would consider making a warranty claim.

[A Hellene]

Hello, gang!

It's been some time; I know, it is my fault and I will take the blame for that... Anyway, I am glad to see you!
 
Mircea, I am sorry to see that you have also got a malfunctioning unit. If I were in your position I would follow Torch's fine advice, to make a warranty claim to have it replaced since it is a brand new device. Regarding my faulty unit, I have abandoned the effort trying to repair it, mostly due to my general lack of time to spare in such a time-demanding project. Not to mention my lack of motivation to spend some more of my sparse time to restore the device in its initial poorly working condition...


-George

[MirceaI]

Thank you both for your advices.
probably i'll make a warranty claim. hope they will change my unit.

[TMM]

Then it's probably not a software issue. So far everything seems to point to a hardware issue for others too. I think earlier in this thread, it was suggested that the probem may be related to either incorrect PCB etching or excessive flux. If you bought yours from an authorized retailer and have not opened it up, I would consider making a warranty claim.

my DS1052E came with v04.00 and the noise floor was terrible. Noise was present at about the same magnitude on all all vertical settings (about 5pixels peak to peak), so it could only possibly be the ADC or software.
I flashed mine to v02.04.01 SP1 after doing the DS1102 'hack' and the noise floor is significantly better - as good as the 'old DS1052' screenshots posted here. Also it doesn't flicker like it did on v04.00. If you are happy to sacrifice support of some USB storage devices (as far as i can tell, that's the only advantage to v03 and v04 FW) then run v02.04.01.

I haven't ever run v3 FW so i can't comment on how that version performs.

[torch]

I believe v3 has not yet been hacked.

[MirceaI]

I must admit i'm a bit confused by this high noise levels. The noise in my unit has the same patern like the photos in first post but not at that high level. Though the noise level is higher then what i've seen in other posts in this topic (see reply 16). There is no change using a tektronics probe.

Can someone else confirm the higher noise level in firmware version 3.01?

[Farid83]

Another desperate 1052e user here! After long hesitation I finally bought this scope a week ago and I'm slowly growing frustration with it ( I'll exlain my problem with pictures.
1.Probe is not connected to BNC. Good flat measurement
2.Probe is connected but not attached to anything. 1X attenuation. Notice ~100Mhz noise
3.Probe is connected but not attached to anything. 10X attenuation

Now it's time to see Rigol in action!
Here I'm trying to check signal measurement with probe connected to probe compensator output. It just plainly looks horrible!!! Look how horizontal section of the signal gets skewed vertically below 200mV/div settings!

Here probe is connected to terminals of 1.5V AA battery. Again bad bad measurement!



Is it me that is using scope wrongly or the scope itself is of terrible quality? Should I return it to the shop or is it supposed to be like this?
Thanks!

[ifndef]

Hi Farid83,
the following are the same tracks on my rigol for your reference (0=no probe, 1=probe 1X, 2=probe 10X).
uhm.. actually the noise in your unit seems a bit high.
Try to change the probe, otherwise you should return it to shop ... 

ifndef

[sigxcpu]

Another desperate 1052e user here! After long hesitation I finally bought this scope a week ago and I'm slowly growing frustration with it ( I'll exlain my problem with pictures.
1.Probe is not connected to BNC. Good flat measurement
2.Probe is connected but not attached to anything. 1X attenuation. Notice ~100Mhz noise
3.Probe is connected but not attached to anything. 10X attenuation

If you have a flat line without probe attached, that means the scope is fine. Your probe picks up ambient noise and you are doing measurements at a very high sensitivity.
When you've put the probe in the compensator output did you also couple the probe's ground to the output ground?

[Farid83]

If you have a flat line without probe attached, that means the scope is fine. Your probe picks up ambient noise and you are doing measurements at a very high sensitivity.
When you've put the probe in the compensator output did you also couple the probe's ground to the output ground?

Yes, probe's ground is attached to the compensator ground.
If it's the noise picked up by probe then how do I use it so the noise doesn't interfere with my measurements? If I compare it to other people's experience mine is lot worse. At least with compensator output they get flat top and bottom not fuzzy like mine.

[IanB]

Is it possible there is a lot of ambient RF noise in your environment? Also, just to be certain, does your scope have a good mains ground where it is plugged in?

My scope probes pick up a huge amount of ambient noise if I just wave them around without connecting them to anything, but I do get a clean trace if I connect to the compensator output.

What happens if you plug in a probe but connect the ground clip to the probe tip? Does that reduce the noise a lot?

Another sanity check to try: if you disconnect the probe from the scope and do a continuity test from the ground clip to the BNC body, do you get a low resistance reading?

[ifndef]

What about CH1? Same noise?

[Samogon]

DS1052E new ADC markings!

Funny, i have Keysight DSO1052B open laying on my bench and it is one to one twins with Rigol DS1052E 
here is some pics of the same place on the main board.
Even PSU absolutely the same as Hellene drew in his schematic

[vinicius.jlantunes]

Samogon,

I think it's a known fact that the Agilent/Keysight DS1052B / 1072B / 1102B scopes are rebadged Rigol's. Firmware and everything is the same as far as I can tell. I have a 1072B.

[Samogon]

vinicius.jlantunes,

Oops. I thought i cracked global conspiracy 
I am relatively new to electronics. It is my comeback to this hobby from 90's.