Rigol DS1052E nasty surprise!

[A Hellene]

I was impressed by the DS1052E I had recently purchased and I got myself a brand new one. But, alas, it seems that the new device has some serious issues my previous one did not have; neither I have the older DS1052E in my possession anymore...

Explaining myself: The new DS1052E seems to have a higher noise floor than the older one and whenever any probe tip touches the ground of the device, the display is instantly filled with some kind of very high frequency sinusoidal noise in the range of 95MHz, making practically unable any measurements to be done; especially in the lower voltage ranges.

For example, the older device could easily read the noise of its own PSU, by simply touching the probe tip to the front USB +5V line, and it showed clearly the PSU oscillator pattern without the need of any kind of signal filtering; even with the probe's ground lead floating. The new one is totally unable to take the same reading because every time the probe tip touches the ground (or the +5V line) the aforementioned 95MHz noise covers any possible input signal; input filtering does not really help. I cannot even read the 1.0KHz probe calibration output signal without some serious filtering. Even with the use of the probe ground spring, the device does not return the clear-cut waveform my previous instrument did. I do not know what is wrong but I suspect that there is some kind of a hardware issue.

I will let the snapshots speak for themselves:


Noise 1: Probes disconnected


Noise 2: Ch1 probe connected. Notice the frequency counter.


Noise 3: Ch1 probe-tip grounded through probe's GND lead. 95.8MHz?


Noise 4: Ch1 probe-tip grounded through aluminium foil. 12.47MHz?


Noise 5: Ch1 probe on the probe calibration output: Unacceptable!


Noise 6: Ch1 probe on the probe calibration output, filtered. Still fuzzy for such a clear signal...


Noise 7: Ch1 probe on the probe calibration ground.


Noise 8: Ch1 probe on the probe calibration ground, displayed in a proper time-scale.



After a brief search, I found out that this is not an isolated case, since another brand new DS1052E had the same exactly symptoms a year ago; so the issue is independent of the new ADC markings (see below). Since I have not purchased the instrument from a Rigol authorised dealer, I do not expect to have it replaced; so, I opened it in hope of finding something that can be fixed.

The mainboard (ver. 0.2 2008/05, build 11/03) is a multi-layer PCB (the bottom layer is marked as sixth and the fifth layer mark is visible beneath it, so it is a three --at least-- layer PCB); and this fact alone rules out any serious attempt to check the PCB for any possible routing faults. So, I begun searching for inconsistencies.

It is interesting that, though the AD8370 and the LMH6552 within the analog front-end shielding retain their diacritics grinding-out, this is not the case for the ADC chips anymore! The five ADCs proudly present their identity now, being devices manufactured from AD and waving their obscure identity in three lines:

Code: [Select]

RAD0182A
#1032
1924219.1I suppose that the second figure is the mfg. time-code (32nd week of 2010).


DS1052E new ADC markings!

Of course, I guess that if I purchased those quantities of the AD9288 ADC chip Rigol does from AD, the latter ones would be happy to put a picture of my face onto the chip instead of the traditional boring identification marks!


With the help of a bit of *ahem* reverse engineering I drew the schematics of the PSU (sorry I got lazy and did not fire up the CAD-CAM), which seems to be functioning as expected (according to the biasing component values):


DS1052E PSU schematic. (Go to the last picture at the end of the message for a high resolution image of the schematics)

Taking a few readings, the PSU generates the following:
1. The main supply, which is 6.40V and powers almost everything.
2. A 3.375V supply for the logic section, which is generated from the 6.4V by an LM317T.
3. A 15.0V supply for the analog section.
4. A negative supply of -12V for the analog section and the cooling fan.

Now, why the main supply is 6.4V? That is simply because the 5.0V partial supplies can be accurately generated locally on board, independently of the long wiring/routing losses.
But, why this peculiar voltage of 6.40V exactly? Well, because this specific voltage is what exactly required by the LCD module backlight!

Anyway...
Any thoughts or suggestions on the unacceptable noise issue the brand new device has are welcome.


-George




P.S. By the way, it is fun to be right! I have previously speculated that the actual power consumption of the instrument would probably lie between 10..15W. Well, these are the actual readings I took from the PSU of my unit:
A: 6.40V x 625mA = 4000mW
B: 3.40V x 1195mA = 4063mW
C: -12V x -335mA = 4020mW
D: 15V x 21mA = 315mW
E: LCD backlight: 5.98V x (447mV/5.6Ω) = 477mW
Total power consumption (by the instrument ONLY, without the PSU losses): A+B+..+E = 12.87W!
Well, yes, it is fun to be right, indeed!

[A Hellene]

No, it is in normal acquisition mode.

[alm]

I would ignore results with a probe connected for now since they might just as well be caused by RFI from some other piece of equipment and/or poor shielding of the probes. For example, clipping the probes ground lead to the probe tip can actually be a fairly good ESD detector. This appears to be what's happening in your noise 3 snapshot (not necessarily ESD, but some sort of inductive pickup). You'll likely see the signal change as you reduce the loop area (eg. compress the loop). I would also ignore counter values for signals like noise 1 and 4, which lack any well-defined trigger point. Noise 1 doesn't look that bad to me (but I don't have an DS1052E to compare). Is it outside of the specs given in the manual? Does shorting the input (eg. with a 50 ohm terminator, not a piece of wire) help? If the signal is OK without probe connected at all vertical attenuator settings, I think you can exclude the signal acquisition circuit.

Noise 5 looks bad to me. Can you verify whether the signal is actually clean with another scope? Can you try different probes? Try a simple coax cable to a (fairly clean) signal generator? Try the same tests in a different environment with less electromagnetic fields present? Something like an electronic ballast for a fluorescent light can generate a lot of RFI.

[scrat]

Are all of the ground connections ok?

[saturation]

This is good data, but sorry to read of the quality control issues.

Before going further, my analysis is identical to alms, I'd be curious to see what the results are by shorting the output with a terminator.   

I recall my measured consumption with a cheapo Killawatt power meter, ~ 24W.

I was impressed by the DS1052E I had recently purchased and I got myself a brand new one. But, alas, it seems that the new device has some serious issues my previous one did not have; neither I have the older DS1052E in my possession anymore...
..
Total power consumption (by the instrument ONLY, without the PSU losses): A+B+..+E = 12.87W!
Well, yes, it is fun to be right, indeed!

[Zero999]

1. The main supply, which is 6.40V and powers almost everything.
2. A 3.375V supply for the logic section, which is generated from the 6.4V by an LM317T.
3. A 15.0V supply for the analog section.
4. A negative supply of -12V for the analog section and the cooling fan.

Now, why the main supply is 6.4V?

I would've thought the LCD backlight would require a constant current supply? If this is true disconnecting it would be a bad idea, as the voltages around the circuit would rise but this does seem like an odd way of doing it.

[A Hellene]

alm & sat,

I am very aware of the fact that the probe ground lead connected to the probe tip forms an inductive pickup head. But the new device is standing at the same exactly location of my desk/bench the older one was. I even powered off the PC monitor (a DELL U2410 --not some el-cheapo EMI generator that produces images!) the DSL modem and the DECT phone that are located a few meters away: Nothing changed! Additionally, there are no CFL lightning devices in my place (I really hate them!) but only halogen ones --even in the bathroom! The only source of EMI is my own body; but wearing an ESD wrist strap the interference is minimised, as it can be seen on the "Noise 2" figure, above, where a few millivolts p-p of the 50Hz hum my own body was picking up were added to the VHF internal noise of the device.

I do not have a proper 50Ω terminator in hand, neither a male BNC to construct one. But I terminated the scope's BNC input using a 51Ω resistor with its leads trimmed as short as possible and, as a result, the residual HF noise of 7.20mVpp (as seen on the "Noise 1" figure, above) was instantly doubled!

The problem is that my previous unit did not have any of those issues. I could just probe any test PCB and read nice, noise-free waveforms. Using a better (lower noise, x100) probe I had even sharper edges and cleaner lines. But, this specific instrument seems to have some internal loop and/or self-oscillation and/or saturation problem that is amplified on the presence of any external test signal.

Anyway, thank you both for your thoughts!
_____



scrat,

Yes, proper grounding is one of the first steps I always take.
_____



sat,

I took those current consumption readings by inserting four 100mΩ shunt resistors directly in series to the four DC outputs of the PSU PCB connector.

Having in hand those output current figures and consulting the PSU schematics, it is very easy to calculate the total thermal losses of the rectifiers and the regulators at the flyback secondary side of the PSU. For example, the power dissipated on the 317T is equal to:
(6.40V - 3.40V) * 1195mA = 3585mW
Assuming that the Vf of the Schottky rectifier (the Tunnel diode, according to the schematics!) is 0.9V (my DS1052E is unable to take that reading in its present state...), then the power dissipated on the rectifier will be equal to:
0.9V*(625mA+1195mA+(447mV/5.1Ω)) = 1722mW
In the same manner, assuming that the Vf of the MUR460 rectifier is 1.1V, it dissipates:
1.1V * 335mA = 369mW
Up to this point, the major losses of the secondary side of the PSU are:
3585mW + 1722mW + 369mW = 5.7W
The partial power consumption level is now at 18.54W, without having included the losses of the primary side of the PSU, which is trickier to calculate since there are inductance losses at the flyback. But we can estimate those losses by subtracting the calculated partial power results of the secondary side (12.87W + 5.7W = 18.6W) from the measured consumption (which in my case was 23VA) to have another four and a half Watts estimated power loss, which is a very reasonable value for the specific stand-by PSU setup that does not have a PFC stage!
_____



Hero,

If you open the link of the LCD module datasheet in my first message, you will see that the backlight is consisted of 14 LEDs that are connected in seven parallel arrays of two LEDs in series each (thus, 6.4V=2*3.4V).

In the PSU schematics I drew, the backlight connector is supplied by the 6.40V rail through a high-side P-Ch MOSFET switch in series to a 100μH inductor of 0.3Ω and a 5.1Ω current limiting resistor.

So, the LCD baclight is not actually powered directly by the 6.4V rail but by a proper current source.


-George

[saturation]

More later, but for reference this is what the 'original' 1052e is like.  Ch 1 shorted with a 50 ohm terminator.

On the screen at max gain, auto measurements show 400uVpp at 2mV/div.  So the measured SNR is 400uV/16mV or -32dB, assuming the signal is measured for a full 8 div.

[A Hellene]

Thank you for the reference screenshot.
This is what my unit displays, respectively (probes disconnected):

[Mechatrommer]

i'm getting like saturation's if open port (~480uV/16mV) but like george's and worst noise if 50ohm terminated (600-800++uV/16mV) on my scope.

[A Hellene]

In lack of a precision waveform generator, I took some readings of a mega16 test circuit, which was battery powered in order to exclude any possible ground loop noise, since its ground is floating. I chose to read a simple waveform generated from a mega16 because these Atmel microcontrollers are notorious for their output stage drive capability, since their output stage is a true complementary one with Rds_ON=24Ω ±10% at Vcc=5.0V at room temperature.

Here are some readings from a mega16 running at Vcc=5.02V, programmed to generate a simple 1.038MHz, 50.0% duty cycle square wave, using its hardware PWM and clocked by its internal RC oscillator calibrated for optimum UART baud-rate.

Please, keep in mind that using the same exactly mega16 setup, my previous unit displayed a crisp square wave without the need of using the ground spring or any further filtering.


1: Ch1 x1 waveform using ground lead, unfiltered


2: Ch1 x10 waveform using ground lead, unfiltered


3: Ch1 x10 rising edge using ground lead, unfiltered


4: Ch1 x10 waveform using ground lead, filtered


5: Ch1 x10 rising edge using ground lead, filtered


6: Ch1 x10 waveform using ground spring, unfiltered


7: Ch1 x10 waveform using ground spring, filtered


Here is a couple of readings using a lower noise x100 probe (250MHz, 6.5pF).
Please, note that the x100 probe is properly compensated, using the 1.0KHz probe compensator connector.


8: Ch1 x100 waveform using ground lead, unfiltered


9: Ch1 x100 waveform using ground lead, filtered


-George

[saturation]

Those are ouchy photos, Hellene! Seems like you can rule out its the probe.  

Can you run your noise sample test as you did with the post quoted below on Channel 2, alone? Channel 2 looks quiet and fine based on early images you've posted, see image.

Given its potentially good performance its suggesting the issue isn't with the ADC or a major PCB issue.



Also, the noise with no input, that is reading just its internal noise seems fairly close to mine. 

Thank you for the reference screenshot.
This is what my unit displays, respectively (probes disconnected):

If so, the problem may hopefully just be related to BNC jack of Channel 1, either its faulty or the soldering is bad.  If so, realistically easy to fix.

Keep us posted!  

In lack of a precision waveform generator, I took some readings of a mega16 test circuit, which was battery powered in order to exclude any possible ground loop noise, since its ground is floating. I chose to read a simple waveform generated from a mega16 because these Atmel microcontrollers are notorious for their output stage drive capability, since their output stage is a true complementary one with

[A Hellene]

Thank you for your input, Saturation!

I will be glad to repeat the test for the second channel alone, even though I do not expect to see any differences at all... I suspect that the second test outcome will be exactly the same to the first one because I think that the problem must not be located to a single analog front-end channel.
Anyway, I have already powered up the device to warm up and I am going to do the test using the same probes, in order to rule out any possible differences due to probe-related deviations.

After figuring out the PSU of the device I also visually inspected the mainboard, expecting to see some sort of a missed soldering or an accidental short or something unusual; but I do not have any documentation related to that instrument so I can only go on through the deductive method.

On the other hand, the "Noise 8" screenshot at the first message indicates some sort of an internal self-oscillation at 100MHz and I am not sure where it comes from. I will try to recapture that, using dots instead of vectors to display the actual ADC samples; in a hopeful manner, this will shed some light to the ADC sampling section.


-George

[A Hellene]

Well, it seems that the Channel 2 test results are a carbon copy of the Channel 1 ones, above!
So, the analog front-end alone must not be held responsible for the noise issue.

Check: Two down (PSU, Analog front-end), who-knows-how-many more to go!


Here are the Channel 2 test results:


1. Ch2 x1 waveform using ground lead, unfiltered


2. Ch2 x10 waveform using ground lead, unfiltered


3. Ch2 x10 rising edge using ground lead, unfiltered


4. Ch2 x10 waveform using ground lead, filtered


5. Ch2 x10 rising edge using ground lead, filtered


6. Ch2 x10 waveform using ground spring, unfiltered


7. Ch2 x10 waveform using ground spring, filtered


Changing the probe:


8. Ch2 x100 waveform using ground lead, unfiltered


9. Ch2 x100 waveform using ground lead, filtered


Something different, now:


10. Ch1 probe on the probe calibration ground; 1GSa/s. Similar to "Noise 8" at the first message but in dot mode.

All the individual ADC samples are in the most expected positions.
Note that this is a full 1GSa/s because Ch2 is off as well as the long memory option; so, all the ten ADCs are involved and they all seem to be in order.

Three down... (!)


-George

[A Hellene]

[...]
Can you run your noise sample test as you did with the post quoted below on Channel 2, alone? Channel 2 looks quiet and fine based on early images you've posted, see image.
[...]

Thank you for the reference screenshot.
This is what my unit displays, respectively (probes disconnected):

Oops, it seems that I missed that detail in bold, above... 
Here it is:


Ch2 max. sensitivity noise (probes disconnected)


-George

[saturation]

More ouch, Hellene, it confirms that the problem is in the DAC or PCB.  More later.
The base appearance of my unit using the calibration signal.

[saturation]

I've always wondered if some of the scopes sold via 'unauthorized' channels are actually counterfeit, as suggested by this note by Rigol to the public.  I haven't heard of any counterfeit warnings from Rigol; the main problem is unauthorized channels but it doesn't explain what this letter means in regards to  ...' some products from illegal sales channels are not even originally produced by Rigol Technologies, Inc.' which suggests to me its contract factories are producing excess units for sale outside of Rigol's control and could lead to quality control issues.

[Bored@Work]

No one until now managed to present a counterfeit Rigol oscilloscope, not even Rigol. And I mean not just pointing at one and shouting 'counterfeit!', but showing evidence. Don't you think Rigol would publish information on how to distinguish an original Rigol from a counterfeit product if they have that information?

That letter just deploys scare tactics. Rigol got flack from their authorized resellers regarding the wave of gray imports and was forced to do something. Instead of stopping to supply the "illegal" Chinese exporters with oscilloscopes they wrote that letter, exaggerating things. E.g. already the use of the word "illegal" is an exaggeration.

How much can you trust that letter? Not much. Read the sentence carefully. They claim

"Some products sold ... are not even originally produced by Rigol Technologies, Inc."

They didn't dare to claim

"Some products sold as Rigol products ... are not even originally produced by Rigol Technologies, Inc."

See the difference? The original claim is a trivial statement. A vendor might of course sell other products than Rigol products. And why should these products be produced by Rigol? Second, the claim would also apply if Rigol would rebadge OEM products. These would of course also not be "originally produced by Rigol".

[A Hellene]

Saturation,

The probe calibration screenshot you posted above (300mVpp @ 1.0ms period --probably due to Ch1 probe setup mistakenly set x1 instead of x10) is very similar to what my previous unit used to display. More on the DAC/PCB comments you mentioned, below.

On the aforementioned Rigol statement, yes, I am already aware of it; but I cannot take it seriously. BoredAtWork explains that in a very rational manner.
_____


BoredAtWork,

I will fully agree with you on the scaremongering tactics any company loosing revenue will use.
I also enjoy being meticulous, meaning being careful and precise about the little details, as well as reading between the lines, in any situation!
_____


Anyway, being suspicious that the excessive noise problem of my device is probably a result of a PCB or a voltage regulator issue, I begun mapping out the mainboard, which most probably is a six-layered PCB; four layers are already visible and the bottom layer is marked as the sixth one! First step is power routing.

Please, excuse my ASCII art; but this it the fastest way for me to figure out something new to me, since working in anything new, everything is firstly constructed in a temporary place in my mind.

Anyway, this is the progress I have made so far. Mind you, this is a very early stage phase; this is an incomplete piece of work! Well, here it goes:

Code: [Select]


              Mainboard PCB, Top view:
             (rectangular units in cm)
------------------------------------

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
                                                   __     
 0  _______________________                       |  |     
 1  |      |            [4]                  _    |  |     
 2  | [1]  |            | |_________________| |___|  |___ 
 3  |      |            |                               o|
 4  |#     |            |    [5]                         |
 5  |#[2]  |____________|                                |
 6  |#[3]                   (A)           o              |
 7  |#        (D)           (A)              [6]         |
 8  \o                   o  (A)              [7]        o|
 9   \___________________________________________________|
                                                           

      PCB legend:
---------------------------
  o  : Mounting screw holes
  #  : Power connector
 [X] : Number "X" regulator
 (A) : ADC (AD9288)
 (D) : DAC (AD5660)


    Power connector:
--------------------------
    ________________
    | 1| -GND-     |
    | 2| (+15V)    |
    | 3| (+6V4)    |
    | 4| (+6V4)    |
    | 5| -GND-     |
    | 6| (+3V4)    |
    | 7| (+3V4)    |
    | 8| -GND-     |
    | 9| (-12V)    |
    |10| (50Hz_In) |
    |11| (/LCD_Bl) |
    |12| -GND-     |
    ----------------

===========================================================


Power sources:
------------------------------

    (+6V4):
----------------
- Regulator 1
- Regulator 2
-
-


    (+3V4):
----------------
- Regulator 6
- Regulator 7
- Analog Devices Blackfin I/O
- Analog Devices ADCs
- Lattice MachXO
- Spansion FLASH
- Issi SRAM
- Hynix SDRAM
- Ramtron FRAM
-
- Philips ISP1362 USB On-The-Go
- Video (UPS051, THS7316)
-
- Keypad PCB
-
-


    (-12V):
----------------
- Regulator 3
- Analog front-end
- Cooling fan
-
-


    (+15V):
----------------
- LCD module


  Regulator 1:
----------------
Type:   NCP1117
Case:   SOT-223
Output: 5.01V
Bias:   39A+85A (249Ω+750Ω)
    Powers:
- Regulator 5
- Front USB(+) through CEM4435A
- Video (UPS051, THS7316)
- 100MHz Osc. (74HC04)
- RS232 ADM202
-
-


  Regulator 2:
----------------
Type:   NCP1117
Case:   SOT-223
Output: 5.01V
Bias:   39A+85A (249Ω+750Ω)
    Powers:
- Regulator 4
-
-


  Regulator 3:
----------------
Type:   L7905CV
Case:   TO220
Output: -5.0V
Bias:   None
    Powers:
- Analog front-end
- Analog section
- Trigger
-
-


  Regulator 4:
----------------
Type:   LP5951MF-3.3
Case:   SOT23-5
Output: 3.3V
Bias:   None
SMD marking: LKHB
    Powers:
-
-


  Regulator 5:
----------------
Type:   NCP1117
Case:   SOT-223
Output: 2.50V
Bias:   39A+39A (249Ω+249Ω)
    Powers:
-
-


  Regulator 6:
----------------
Type:   NCP1117
Case:   SOT-223
Output: 1.25V
Bias:   Adj pin to GND
    Powers:
- Analog Devices Blackfin core
-
-


  Regulator 7:
----------------
Type:   NCP1117
Case:   SOT-223
Output: 1.25V
Bias:   Adj pin to GND
    Powers:
- Altera Cyclone III
-
-



Well, I guess that after this has been started, Rigol will either sue my ass (even though I am not subjected to any NDAs) or they will replace my faulty unit in order to stop me from figuring out and making public their trade secrets!


--George

[WanaGo]

Hello,

I am not sure if you have contacted Rigol at all, but I contacted them about finding a local distributor for their scopes and when I replied I mentioned this post and just my general concern - they replied with the following - It may be of some use/info

Hi James,

Very appreciate your sharing of this article with us, and we already know this case, at the same time our R&D attached highly importance to this issue, will find if it's a quality control problem or something else.

We always try every efforts to improve ourselves as to provide most high quality and performance product and service to customers, and would like to have more feedbacks from your side in the future.

Thanks again.



Best regards
Sincerely yours,
Handsun
Regional Manager
RIGOL TECHNOLOGIES, INC.
No. 156, Cai He Village, Sha He Town, Chang Ping District, Beijing, 102206 P.R  China Tel. +86-10-80706688 ext. 856 Fax +86-10-80705070 Cel. +86 15011340100 Website:www.rigol.com Skype:ssunhan@hotmail.com
Email: sunhan@rigol.com

[vk6zgo]

The answer from Rigol gives me a horrible feeling of deja vu.

It sounds like many of the answers we got from a Chinese supplier for some equipment (Radio Transmitters) we bought at my last job.
After a while,you realise that they are "just being nice" & have no real intentions of doing anything about the problem.

They did try,I suppose, when they first arrived,none of them worked,& after a while,they said "Send 'em back."
On their return,they sort of worked!
Eventually we fixed most of the problems ourselves, most of which were "Quality Control"(or lack of) problems.

They have been replaced now,& the Boss has scheduled a "sledgehammer party" so everybody can take out their
frustrations on the @#$%$#^&&&^%$!! things.

VK6ZGO

[A Hellene]

This is an interesting reply, WanaGo. Thank you for sharing it.

But, like VK6ZGO, I think that it is just a piece of meaningless pre-sales marketing-talk.
Unless, of course, it is proved otherwise.


-George

[cWal]

I just looked at my unit, bought last January from Dealexcel, so directly from China to Europe  I successfully made the hack to 100MHz, more for the fun than for utility 
And I don't really understand the letter from Rigol staff, for me it's obvious my DSO is a genuine Rigol, even the package was "Rigol printed"... Only the price would have been (very !) different if I had bought here !

What I can say about your screenies, compared to my unit :
noise 1 & 2 seem normal to me as probe is not grounded, though I get a <5Hz as frequency and 2.40mV max Vpp, no weird frequency...
noise 3, 5, 7, 8 : I can't reproduce, I mean I don't know how to get into these, strange...
When I connect a probe to the calibration output I immediately get a nice rectangular signal, same values for rise time and Vpp, but I have a very stable 1.00000KHz as frequency. Same as noise 6, but I think a bit less noisy on horizontal lines...

So it seems something is going wrong with your scope.
A stupid question (but I am often stupid with my own machines) : you did the calibration process right ? May be you could recall the factory settings then redo a calibration...
But for me everything appears to work as something was poorly grounded somewhere...

[A Hellene]

Well, yes, I have run the auto-calibration procedure; but it is irrelevant because the problem is clearly in the hardware: Some of the screenshots indicate that there is either a PCB or a component failure. I am just trying to locate the problem and this is not easy without proper documentation (schematics, test points references, etc.).

On the other hand, this is not the first DS1052E I lay my hands on, so I can say with a fair amount of certainty that my unit is a legitimate Rigol one; it came with all the paperwork (user's manual, warranty, calibration certificate, etc.) and drivers in a Rigol packaging, just like the previous one I had that was functioning flawlessly. It has just not been purchased from the official Rigol distribution channels for Europe.


-George

[saturation]

Thanks Hellene for sharing, marvelous work!  I will follow your progress closely Even if unresolved, t at least will provide as new insights into the construction of their scope.  

Board@Work, I cannot disagree with you.  I have no direct evidence this is happening except one fact, it goes by an unauthorized channel from a Chinese source; and China items are a major source of counterfeit.  

Counterfeit is a very good these days, here is just one example the 'third shift' model, and the product can be nearly identical to the real McCoy.  Sometimes the only differences can be subtle quality control issues.  I will poll users to see if unauthorized channel scope purchases have slightly more defects reported than those bought from authorized channels.

http://grantfidelity.com/factories/?p=163

http://money.cnn.com/magazines/fortune/fortune_archive/2006/05/01/8375455/index.htm

In the old days, grey market goods sold in the US were cheaper than US focused  goods, but today its no longer the case, and grey market means something different.  For example, grey market VHS players focused for EU were PAL vs SECAM vs NTSC decoding, or even just fixed PSU at 220V at 50Hz vs 110V and 60Hz.  Today, there is more unification, and 'grey' market is mostly product positioning for a given region, and dealing with intellectual property and local tax laws.

http://en.wikipedia.org/wiki/Parallel_import#United_States

Grey market channels are more close to what Board@Work describes, and it would for the most part be factory blessed Rigol products sent to an "unauthorized" market region.  So beyond upsetting their dealer contracts, it allows consumers access to favorable pricing, and Rigol responds to this tactic by dropping warranty on those scopes.

[A Hellene]

Thank you, Saturation!

Working on-and-off on this costs me time because it disrupts my concentration... Hopefully, I'll have some more time to spend on it during the weekend, in order to make the schematics of the analog section, which, being in the signal path, could always be a major contributor to the overall signal noise.

By the way, this is an updated mainboard map populated with all the semiconductors with the exception of the discrete transistors, FETs and diodes; but there are still some points that need more investigation like the actual need for the Regulator #4 and the role of Regulator #5.

Code: [Select]


              Mainboard PCB, Top view:
             (rectangular units in cm)
------------------------------------

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
                                                  ___     
 0  _______________________                      |   |   
 1  |      |            [4]                  _   |   |   
 2  | [1]  |            | |_________________| |__|   |__ 
 3  |  E   |     A     A|aa           (h) i  k      o  @|
 4  |%     |   B C   B C|    [5]    g     j    l   m  n |
 5  |%[2]  |_D_____D____|             f                 |
 6  |%[3]    F D L  K        b   d        @             |
 7  |%      F  I          (b)b  c     e      [6]     p  |
 8  \@      F  F H  F     (b)b               [7] q     @|
 9   \____G__G_J_______@________________________________|
                                                         

------------------------------------------------------------------------------------------------------------------
|     PCB components & peripherals:      |                            Power source(s):                           |
|                                        |-----------------------------------------------------------------------|
|                                        | -5V0  |+1V25#1|+1V25#2| +2V50 | +3V4  | +5V0a | +5V0d | +15V0 | +3V3#2|
|----------------------------------------+-------+-------+-------+-------+-------+-------+-------+-------+-------|
| @ : Mounting holes                     |   -   |   -   |   -   |   -   |   -   |   -   |   -   |   -   |   -   |
| % : Power connector                    |   -   |   -   |   -   |   -   |   -   |   -   |   -   |   -   |   -   |
|[*]: Numbered voltage regulator         |   -   |   -   |   -   |   -   |   -   |   -   |   -   |   -   |   -   |
|----------------------------------------+-------+-------+-------+-------+-------+-------+-------+-------|-------|
| A : AD8510 (Low input bias Op-Amp)     |   Y   |       |       |       |       |   Y   |       |       |       |
| B : AD8370 (Variable Gain Amp)         |       |       |       |       |       |   Y   |       |       |       |
| C : LMH6552 (Differential Amp)         |   Y   |       |       |       |       |   Y   |       |       |       |
| D : 74AHC595 (8-bit shift reg)         |       |       |       |       |       |   Y   |       |       |       |
| E : TLC272 (Dual Op-Amps)              |   Y   |       |       |       |       |   Y   |       |       |       |
| F : TLC274 (Quad Op-Amps)              |   Y   |       |       |       |       |   Y   |       |       |       |
| G : 74HC4051 (Single 8-Ch mux/demux)   |   Y   |       |       |       |       |   Y   |       |       |       |
| H : 74HC4053 (Tripple 2-Ch mux/demux)  |   Y   |       |       |       |       |   Y   |       |       |       |
| I : AD5660 (16-bit DAC)                |       |       |       |       |       |   Y   |       |       |       |
| J : EL1881 (Sync. separator)           |       |       |       |       |       |   Y   |       |       |       |
| K : ADCMP562 (Dual PECL comparators)   |   Y   |       |       |       |   Y   |   Y   |       |       |       |
| L : LMH6574 (4 to 1 video multiplexer) |   Y   |       |       |       |   Y   |       |       |       |       |
| a : 74LVC2G17 (Dual Schmitt-trigger)   |       |       |       |       |       |       |       |       |   Y   |
| b : AD9288 (Dual 8-bit ADC)            |       |       |       |       |   Y   |       |       |       |       |
| c : EP3C5F256C8N (Cyclone III FPGA)    |       |       |   Y   |   Y   |   Y   |       |       |       |       |
| d : LCMXO256C (Lattice LUT)            |       |       |       |       |   Y   |       |       |       |       |
| e : IS61LPS25636A (Issi SRAM)          |       |       |       |       |   Y   |       |       |       |       |
| f : 74AHC04 (100MHz oscillator)        |       |       |       |       |       |       |   Y   |       |       |
| g : UPS051 (LCD controller)            |       |       |       |       |   Y   |       |   Y   |       |       |
|(h): THS7316 (3-Ch video amplifier)     |       |       |       |       |       |       |   Y   |       |       |
| i : TCM809 (3.08V Reset Monitor)       |       |       |       |       |   Y   |       |       |       |       |
| j : TL072C (Dual OpAmp)                |   Y   |       |       |       |       |       |       |   Y   |       |
| k : FM24CL04 (Ramtron FRAM)            |       |       |       |       |   Y   |       |       |       |       |
| l : ADSP-BF531 (BlackFin)              |       |   Y   |       |       |   Y   |       |       |       |       |
| m : H57V1262GTR (Hynix SDRAM)          |       |       |       |       |   Y   |       |       |       |       |
| n : S29GL064N90 (Spansion FLASH)       |       |       |       |       |   Y   |       |       |       |       |
| o : CEM4435A (20m? P-Ch MOSFET)        |       |       |       |       |       |       |   Y   |       |       |
| p : ISP1362 (USB controller)           |       |       |       |       |       |       |   Y   |       |       |
| q : ADM202E (RS232 interface)          |       |       |       |       |       |       |   Y   |       |       |
|----------------------------------------+-------+-------+-------+-------+-------+-------+-------+-------+-------|
|     TM056KDH02 (LCD module)            |       |       |       |       |       |       |   Y   |   Y   |       |
|----------------------------------------+-------+-------+-------+-------+-------+ ------+-------+-------+-------|
|     Keypad PCB                         |       |       |       |       |   Y   |       |       |       |       |
------------------------------------------------------------------------------------------------------------------

(*) mounted on the Bottom Layer.
TCM809 reset supervisor directly resets the DSP, the USB and the LCD controllers and probably the FPGA,
as well as the DS1000D series Active Logic Head.


    Power connector:
--------------------------
    ________________
    | 1| -GND-     |
    | 2| (+15V)    |
    | 3| (+6V4)    |
    | 4| (+6V4)    |
    | 5| -GND-     |
    | 6| (+3V4)    |
    | 7| (+3V4)    |
    | 8| -GND-     |
    | 9| (-12V)    |
    |10| (50Hz_In) |
    |11| (/LCD_Bl) |
    |12| -GND-     |
    ----------------

===========================================================



Power distribution:
-----------------------------------



            PSU PCB voltage outputs:
        --------------------------------

    PSU (+6V4):
-----------------
- Regulator #1
- Regulator #2


    PSU (+3V4):
-----------------
- Regulator #6
- Regulator #7
- Keypad PCB
- ADCMP562 (Dual PECL comparators)
- LMH6574 (4 to 1 video multiplexer)
- AD9288 (Dual 8-bit ADC)
- EP3C5F256C8N (Cyclone III FPGA) I/O
- LCMXO256C (Lattice LUT) I/O
- IS61LPS25636A (Issi SRAM)
- UPS051 (LCD controller)
- TCM809 (3.08V Reset Monitor)
- FM24CL04 (Ramtron FRAM)
- ADSP-BF531 (BlackFin) I/O
- H57V1262GTR (Hynix SDRAM)
- S29GL064N90 (Spansion FLASH)


    PSU (-12V):
-----------------
- Regulator #3
- Cooling fan


    PSU (+15V):
-----------------
- LCD module (TM056KDH02), through a 100? (01A) resistor
- TL072C (Dual Op-Amp)



            Mainboard voltage regulators:
        -------------------------------------

  Regulator #1: (+5V0d)
------------------------
Type:    NCP1117
Case:    SOT-223
Output:  5.01V
Bias:    39A+85A (249?+750?)
Marking: 1117B
Powers: 
- Regulator #5
- TM056KDH02 (LCD module)
- Front USB(+), through CEM4435A MOSFET
- 74AHC04 (100MHz oscillator)
- UPS051 (LCD controller)
- THS7316 (3-Ch video amplifier)
- ISP1362 (USB controller)
- ADM202E (RS232 interface)


  Regulator #2: (+5V0a)
------------------------
Type:    NCP1117
Case:    SOT-223
Output:  5.01V
Bias:    39A+85A (249?+750?)
Marking: 1117B
Powers: 
- Regulator #4
- AD8510 (Low input bias Op-Amp)
- AD8370 (Variable Gain Amp)
- LMH6552 (Differential Amp)
- 74AHC595 (8-bit shift reg)
- TLC272 (Dual Op-Amps)
- TLC274 (Quad Op-Amps)
- 74HC4051 (Single 8-Ch mux/demux)
- 74HC4053 (Tripple 2-Ch mux/demux)
- AD5660 (16-bit DAC)
- EL1881 (Sync. separator)
- ADCMP562 (Dual PECL comparators)


  Regulator #3 (-5V0):
------------------------
Type:    L7905CV
Case:    TO220
Output:  -5.0V
Bias:    None
Marking: L7905CV
Powers: 
- AD8510 (Low input bias Op-Amp)
- LMH6552 (Differential Amp)
- TLC272 (Dual Op-Amps)
- TLC274 (Quad Op-Amps)
- 74HC4051 (Single 8-Ch mux/demux)
- 74HC4053 (Tripple 2-Ch mux/demux)
- ADCMP562 (Dual PECL comparators)
- LMH6574 (4 to 1 video multiplexer)
- TL072C (Dual OpAmp)


  Regulator #4: (3V3#2)
------------------------
Type:    LP5951MF-3.3
Case:    SOT23-5
Output:  3.3V
Bias:    None
Marking: LKHB
Powers: 
- 74LVC2G17 (Dual Schmitt-trigger)


  Regulator #5: (+2V50)
------------------------
Type:    NCP1117
Case:    SOT-223
Output:  2.50V
Bias:    39A+39A (249?+249?)
Marking: 1117B
Powers: 
- EP3C5F256C8N (Cyclone III FPGA)


  Regulator #6: (+1V25#1)
------------------------
Type:    NCP1117
Case:    SOT-223
Output:  1.25V
Bias:    Adj pin to GND
Marking: 1117B
Powers: 
- ADSP-BF531 (BlackFin) core


  Regulator #7: (+1V25#2)
------------------------
Type:    NCP1117
Case:    SOT-223
Output:  1.25V
Bias:    Adj pin to GND
Marking: 1117B
Powers: 
- EP3C5F256C8N (Cyclone III FPGA) core



-George



[EDIT, 2011.06.21]: Mainboard PCB map update.

[saturation]

A Hellene, thanks for taking time to share your discoveries.  If you find differences between your PCB and the detailed hi-resolution images Dave has on his original tear down, please feel free to compare and contrast.  It would be interesting to see any revisions.

[A Hellene]

I will tear my credentials up!
All of them!!!

Having dismantled the DS1052E in order to figure it out, I connected the PSU, the LCD and the Keypad PCBs to the mainboard to take some live readings, in this non-trivial task of repairing this sort of a black box. Well, I realise that this kind of repair is probably next to impossible, due to the lack of any schematics or any kind of service documentation. But not everyone is an easy quitter, especially not someone who loves to play with his toys!

I dismantled the problematic DS1052E to trace down the source of the instrument's excessive noise. After having taken some readings, I decided to power it up for further investigation of its noise issue.
Well, here is something not so commonly encountered, even in the Internet Era:


Noise levels of the DS1052E dismantled!

Please, compare the noise levels of the device in this state, to the original noise levels posted at the first message of this thread:


Noise 5: Ch1 probe on the probe calibration output.

It is obvious that the noise level of the dismantled DS1052E is less than half in amplitude of the properly assembled unit noise level!

This can be partially explained, since the noise generated by the switching PSU is further away from the ADC and the Analog sections of the oscilloscope's mainboard, and in a different orientation (polarization).



Operating DS1052E dismantled!

In the picture above, it can be seen that the oscilloscope operates outside its metal shielding (its Faraday Cage), in front of a non-trivial in EMI emission terms LCD monitor, and it has its Analog Front-End wide open(!). It can also be seen the current shunt resistors directly connected to the PSU output, as well as the non-EMI protected workspace.

I think it is time for me to have a drink, to clear my mind up!


-George

[kkontak]

George,

since your problem seems to be noise related rather than some other fault, I would suggest to try some noise rejection technics.

1. Put some ferrites on the cabling harness, specifically the cable coming out of the PSU PCB. You can use the ferrites from old ATX PSUs.
2. Proper cleaning (with alcohol, brush and patient) of suspect PCBs.
3. Additional shielding with copper/aluminium foils, adhesive or not.(Yes it's ugly but if it works...)

Finally you could try to swap the AC plug into another wall socket or turn it 180 degrees to reverse N an L, if you have also 50Hz noise.

Kyriakos
Another Greek fellow.

[A Hellene]

Hello Kyriakos,

Welcome to the forum!


About my DS1052E issues, I am afraid that noise is only the symptom of the problem.

For example, in the first page of this thread there are a few screenshots of Channel 1 and Channel 2 readings, taken using a 100MΩ x100 probe: A residual noise problem alone should not distort the specific waveforms (see: "8. Ch1 x100," "9. Ch1 x100," "8. Ch2 x100" and "9. Ch2 x100". The strange thing about these screenshots is that, though the x100 probe was properly compensated using the 1.0KHz/3.0Vpp probe compensator connector, it seemed to be under-compensated when reading the 1.0MHz/5.0Vpp test signal. Noise alone, cannot do that...

Anyway, I would like to thank you for the recommendations to help reduce the PSU noise!


-George

[saturation]

Great work Hellene.  Would be good to see how the noise mitigation assists, as kkontak suggested, since removing it from its case helped a bit.

[A Hellene]

I could try to bypass the switching PSU by supplying the unit with pure, regulated DC; applying all the partial supplies at the same time will be a challenge, though.

However, my suspicion is that there will not be any major improvement, since I am almost convinced that the noise is a symptom; not the actual problem... But I think that I should let this interesting experiment speak for itself.


-George

[Zero999]

Hero,

If you open the link of the LCD module datasheet in my first message, you will see that the backlight is consisted of 14 LEDs that are connected in seven parallel arrays of two LEDs in series each (thus, 6.4V=2*3.4V).

In the PSU schematics I drew, the backlight connector is supplied by the 6.40V rail through a high-side P-Ch MOSFET switch in series to a 100?H inductor of 0.3? and a 5.1? current limiting resistor.

So, the LCD baclight is not actually powered directly by the 6.4V rail but by a proper current source.

Thanks, I missed that.

[A Hellene]

After a week and a half of on-and-off play, with the invaluable help of the magnifying glass and the continuity tester, I have managed to draw the 1052's schematics of the the whole analog section, hoping to see some kind of inconsistency in order to blame the PCB. But the schematics drawn make a perfect scene to me, so the PCB must probably he healthy. Naturally, I cannot know whether a blind/buried via/trace in this 6-layered board is functioning properly, because that was my suspicion in the first place. Of course, it could always be a latched-up (SCR) or leaky P-N junction issue to give me that ~100MHz self-oscillation noise readout symptom...

Anyway, I think I have found something that does not make sense to me. It is a weird voltage reading of -2.50V at the third output of the third 274 op-amp that drives the non inverting input B (pin 12) of the ADCMP562 (dual high speed PECL comparator). That weird voltage of -2.50V is also reflected at the test point TP105.

The bias of the specific op-amp is -18.5mV at the inverting input, +3.1mV at the non inverting input and according to its biasing components it should have a DC gain of 3.00V/V. Well, I think that this is clearly a fault, even if the scope seems to be functioning properly (excluding the increased noise issue, documented at the previous pages of that thread).

I guess that I will additionally have to program a sniffer to log and analyse the serial communications of the analog section, in order to find out whether that voltage is actually produced by the DAC or not; which I highly doubt, since the DAC cannot go below 0V and the visible driving and biasing components of the op-amp do not allow a negative voltage output.

My only objection to all this is that my day has only twenty four hours...


-George

[A Hellene]

It has been some time since I have resolved the issue mentioned above and I have not updated the thread, because these days I have visitors at home and my spare time has almost been vanished!

The specific voltage reading at the test point TP105 mentioned in the previous message is perfectly healthy. Due to a minor mistake in copying the schematics I have drawn, it seemed to be impossible for the specific op-amp to produce a negative voltage; but I was wrong. The voltage present at the TP105 is the second trigger level, used in slope triggering mode only; it was constantly negative because slope triggering mode was inactive during my initial tests. When I sniffed, read and analysed the digital communications of the analog section, the specific signal was present and healthy! Sorry about the false alarm...

Anyway, these are the schematics of the DS1052E HW58 (2011.03 batch) Channel 1 analog front-end I have drawn:



Please, note that the values of the chip capacitors are estimated (meaning read on board and recalculated), since they have no markings and were measured while in circuit. I will update the schematics when I find the time needed to measure the critical components properly, removing them from the PCB.


-George


[EDIT]: Schematics corrected and re-uploaded.
[EDIT 2]: The specific schematic sheet above has minor errors. For corrected and updated schematics look here.

[scrat]

Wow, amazing work...
But, the original problem? Still unsolved, right?

[A Hellene]

Thank you!

As for the original problem, unfortunately it is still there waiting to be resolved...


-George

[saturation]

KUDOS, Hellene, superb work.  I suspected how the inputs work but its good to see the real layout.  Look forward to your further discoveries and follow this thread closely.

Wow, amazing work...
But, the original problem? Still unsolved, right?

[scrat]

I was just looking at the schematic...
Maybe it's just me not understanding much of analogue...The AD8510 is spec'ed for a GBWP of 8MHz, and even for a very low gain it doesn't guarantee the needed bandwidth (100MHz), apart from being perhaps unstable. So how does it work, there?

[A Hellene]

Thank you, saturation.

I guess that the next step after repairing the hardware issues of the scope would be the decompilation of the firmware and the recompilation of a better one without restrictions and full of additional functionality!

Alright, I am just kidding! Everyone is free to be dreaming!
But I think that now it is my turn to thank you, for your encouraging attitude!
_____


scrat,

In the schematics it can be clearly seen that the under test signal has a separate DC path through the AD8510 amplifier via the 4.7M resistor and a separate AC path through the 330pF capacitor directly to the JFET input stage.

Signal splitting into its DC and AC components is the most popular topology for this kind of test equipment. See the links here.
_____


-George

[scrat]

Thanks! Although I'm not an expert, that capacitor was right there "speaking" by itself.
I can justify myself with the excuse the image is difficult to be seen on my lapop screen, where I see only a portion at a time

Good luck for the FW!

[A Hellene]

No worries, scrat! Neither I consider myself to be an expert in any department, despite what people say.

According to my personal cultivation, «? ». It is literally translated into "I am always learning as I am getting old" and meaning that I will always be learning as long as I live.

This wise apothegm belongs to Socrates, one of the greatest teachers of critical thinking the world has ever known.


-George



[EDIT]: The unreadable characters were a famous Classical Greek adage:
"Girasko Aei Didaskomenos" in Greeklish until our kind host, Dave, fixes the Greek characters support!

[A Hellene]

Oh, no!
My cover is blown...

[A Hellene]

Ah, I see! You are talking about the Nespresso & falling pianos commercial George Clooney!


I am afraid that this is another George Clooney, an even more better looking one than the previous one in the commercial, who does not believe in the Abrahamic delusions or in commercials; but I like espresso!
Sorry, wrong person...


-George

[A Hellene]

Thank you, my friend!


-George

[seattle]

Anyway, these are the schematics of the DS1052E HW58 (2011.03 batch) Channel 1 analog front-end I have drawn:

Oh man, some tedious and spectacular work!

What is the purpose of the varactor after the AD8370? Looks like this is a bandwidth limiting cap depending on the signal on HA595.QA pin.

Do you know is this the signal they use to hobble a 100 MHz scope into a 50 MHz scope, or is this doing the normal UI-selectable BW limit function?

[A Hellene]

Thank you, seattle.

The varicap (BBY65: <2.7pF @ Vr=4V7 and >29.5pF @ Vr=0V3 at 1MHz) limits the bandwidth to 20MHz when this option is enabled.

When the 20MHz limit is disabled the varicap is reverse biased, with 595.QA being at 5.0V and TP108 (generated by the AD5660 DAC) being negative. When the limit is enabled the varicap is biased forward(!) with 595.QA at 0.0V and TP108 positive (though I have measured the TP108 values I have not yet register them in order to provide some accurate figures). In the first case varicap's capacitance becomes <2.7pf and in the second case it changes to almost infinite, shunting the two 150pF in-series physical capacitors.

It is trivial to calculate the corner frequency response of the AD8370 amplifier, by its output impedance (95 Ohm differential) and the total parallel capacitance applied.

Regarding your second query, no! That filter, though it can be used in a more linear mode, is bistable (on/off) in Rigol. The firmware is responsible for the overall bandwidth of the device; thus you can purchase a 50MHz DS1052E and turn it to a 100MHz DS1102E or even a 150MHz DS1152E instrument, just by modifying a configuration string. Or turn a DS1102E to a DS1052E!


-George

[rf-loop]

Maybe you are interest about this: (reading also whole this topick is good "homework", better done homeworks - understand more.

With all "goods and bads" this whole topick is good to read if want working with Rigol.

https://www.eevblog.com/forum/index.php?topic=30.225

and forum user JimBeam shared (thank you) picture about Rigol front end amplifier filtering:
( I do not know if it is right. This time I do not work with Rigols and I can not check. I have handle (more than only some) Rigols but not anymore becouse this company customer care policy. (also this small display but with this can live as scope is USD300)

[A Hellene]

Thank you for that link, rf-loop!


-George

[tinhead]

When the 20MHz limit is disabled the varicap is reverse biased, with 595.QA being at 5.0V and TP108 (generated by the AD5660 DAC) being negative. When the limit is enabled the varicap is biased forward(!) with 595.QA at 0.0V and TP108 positive (though I have measured the TP108 values I have not yet register them in order to provide some accurate figures). In the first case varicap's capacitance becomes <2.7pf and in the second case it changes to almost infinite, shunting the two 150pF in-series physical capacitors.

It is trivial to calculate the corner frequency response of the AD8370 amplifier, by its output impedance (95 Ohm differential) and the total parallel capacitance applied.

right, almost exact the same on Hantek, the diff is the applied voltage :
2.2 reverse biased or 2.7 forward biased, thus 20/220Mhz switching.

More important is what behind the LMH6552, no idea how Rigol is exactly using 5 ADC ICs,
meaning how they will be switched together. On HanTekway is bit easier, as there are only 4 ICs (so 8 ADCs),
series resistor of 33Ohm, some multilayer par. capacitance + let say half pF from relais and then
4 ADCs per one series resistor. Knowing the ADC capacitance (2pF) and the fact they diff. driven
HanTekway does have estimated 16pF (ADCs) + 5pF (par.) on 33 series resistance = 229MHz -3db bw.

I think Rigol have one series resistor per 5 ADCs, so 5 x 2pF x 2 + 5pF and with 33Ohm series resistor
this give us 192MHz -3db bw.

*these 5pF par. capacitance might be a bit higher calculated than the real one, estimated 5cm trace on multilayer
with GND on bottom will be somethign about 2.5pF, but we don't know how they routed. AÓn the other side reials
and these resistor networks does have some cap. too, so i would say worst case 5pF par. capacitance.

[hisense999]

It is interesting that, though the AD8370 and the LMH6552 within the analog front-end shielding retain their diacritics grinding-out, this is not the case for the ADC chips anymore! The five ADCs proudly present their identity now, being devices manufactured from AD and waving their obscure identity in three lines:

Code: [Select]

RAD0182A
#1032
1924219.1
Of course, I guess that if I purchased those quantities of the AD9288 ADC chip Rigol does from AD, the latter ones would be happy to put a picture of my face onto the chip instead of the traditional boring identification marks!

Actually AD will not change even one digit on the chip maybe if you are really super customer and ordering separate version in hundred of thousands qtty, this which use RIGOL is a common service in China which cost about 1 Yuan for scratch and repaint MCU, is a big fun usually we scratch all our MCU's to not give a fun for ppl which open device, sometimes after scratching all digits we order painting in PIC or AVR style this is a big fun I wonder how many ppl try to extract this as simple PIC or AVR

[hisense999]

I didn't know that manufacturers would end with such low-tech tricks to hide their secrets

I know however that it is a pretty common practice to "decap" chips to read the actual die marking or even to decipher the Flash content bit by bit... See this hacking of a PIC 18F1320 and also this site for details.

So this kind of "protection" would only be good against naive hobbyists like us, not against real competitors. Which may be the actual purpose, anyway!

Or maybe that's just a requirement from the chip manufacturer in order to hide the ADC overclocking capabilities?

Yes this is low-tech trick but working quiet good, you look at this from advanced point of view, yes decap process is simple but first you must know where to decap second, you must contact negotiate price, make an transfer send an IC then wait for result everything need a time and if you have a lucky then person involved in copy idea start to be bored cuz nothing simple looking at start and instead of reverse engeenering this device he can pick up other more simple or even forget at second day about it.

B.R.

[marmad]

So this kind of "protection" would only be good against naive hobbyists like us, not against real competitors. Which may be the actual purpose, anyway!

I think all protection schemes are mostly aimed at competitors - not so much at hobbyists.  It seems that, in any field of electronics where competition is high, and innovation and/or price is critical to success, anything companies can do to make it more difficult to copy their designs (specially if it doesn't cost much money) often will be done.

I remember back in 1979 my Arp Odyssey analog synthesizer had it's filters completely dipped and encased in a block of colored epoxy to make it impossible for competitor Moog to identify any of the components.  And that area on the schematic - which they still delivered with products back then - just showed a block with inputs and outputs.

[rf-loop]

Maybe originally they want make copycats work more delay? I understand if there is some technical innovation in design but there is nothing if think electronics, but maybe this "big innovation" is "how it can make cheapest way keeping it still acceptable in its price class". Digital oscilloscope designed so that ADC and front end is most weak point (but still it is acceptable if think price).   Maybe they also want hide  that they use cheapest -40 models but use these as -100 specified. They use 100MHz clock for chips what are specified for 40MHz by Analog Devices. How to make oscilloscope with ~100USD, this info need try keep littlebit scrambled. Maybe this was most high level innovation as they start with this design. After then Atten make copy. In court Rigol win but still Atten/Siglent look this just as "so what".

Quality is one thing what can not copy so easy together with lower price.  Quality is very good product protection. After chinese really understand it.... they win. Quality in design can not copy only if look schematics. (in history HP understand it and all schematics was included with manuals, becouse they know... no one can copy it so that it still can be good business to copy cat.  Today situation is littlebit different with low-end products. Everyone can do these. Question is only - who can make it more cheap and so that it is still some business. (business need also name... no one buy expensive high-end product with "noname" if there is same time with nearly same price and quality class Agilent on Tektronix)


All these ADC's are made as 100MHz chips! But not all chips reach full speed and accuracy in analog sampling and conversion. It is not overclocking digital logick parts but with 100MHz adc accuracy is poor. Digital part works normally this full speed.

[A Hellene]

Hello there!

I am sorry for my short absence, my fellow EEVbloggers.
These days I am playing the good host, since I have guests at home --and my day has only 24 hours...
But I am not complaining.


tinhead,

I reassembled my unit to take some live readings: When the 20MHz BW limit option is disabled the 595.QA (that drives varicap's anode) is logic high (+5V0) and the buffered DAC output (that drives varicap's cathode) is -5V02 at the op-amp output (before the 100 ohm resistor at TP107/TP108), thus the varicap reverse bias becomes 10V0 and its capacitance becomes 1.8 .. 2.5 pF (the datasheets claim 2.7pF @ Vr=4V7). With the BW limit enabled, 595.QA is logic low (0V0) and the buffered DAC output is +3V78, so the varicap is forward biased and in full conduction, shunting the two 150p bandwidth limiting capacitors (Quick calculation: (150pf/2)//95ohm gives -3dB at 22.3MHz).

Regarding the ADCs, I believe that your estimations are spot on. By the way, only the trigger output digital lines are not sandwiched within the inner layers, since they can be seen on the bottom layer, properly terminated; the front-end signal outputs are not visible at all...

In Rigol, all the five "A" ADC differential inputs (the AD9288 pins 02 and 03) are in parallel as well as the remaining five "B" ones (the AD9288 pins 11 and 10), forming two 8-bit 500MSa/s ADC logic units (let's call them unit A and unit B) with the five physical ADCs being clocked in sequence (interleaved) by the FPGA PLL. The AD9288 S-configuration input is hardwired to logic high (S2:S1 = 0b11), so we have 180 degrees data alignment between the units A & B, making it possible to create one 8-bit 1GSa/s ADC logic unit by feeding the two partial 500MSa/s logic units with the same analog signal and clock input without the need of reconfiguring their clocking scheme.

This is the truth table of the ADC feeding relays (in my schematics: the Relay#1C that feeds the ADC logic unit A input, and Relay#2C that feeds the ADC logic unit B input):

Code: [Select]

-----------------------------------
 |1GSa/s  Ch1   Ch2  | Rl#1C Rl#2C |
 |---------------------------------|
 |  Off   Off   Off  |   1     0   |
 |  Off   Off   On   |   1     0   |
 |  Off   On    Off  |   1     0   |
 |  Off   On    On   |   1     0   |
 | - - - - - - - - - - - - - - - - |
 |  On    Off   Off  |   1     0   |
 |  On    On    Off  |   1     1   |
 |  On    Off   On   |   0     0   |
 -----------------------------------For example, when both the relays are off, the system is configured to sample Ch2 at 1GSa/s.
______



hisense999,

Isn't it obvious that I was joking about putting my face on the markings?
On the other hand, in volume customers (with purchases in the order of 10,000's or 100,000's or more units), I know that the manufacturers can agree even to pre-load some firmware and/or change the IC diacritics.

But, like Squonk, my question is, why obfuscate the ADCs only and keep grinding out the other two front-end chips (the VGA ans the diff-amp)?
______



marmad,

I agree with you. A decent EE will finally find everything out; these practices can only delay them.
After all, a real EE will mostly choose to redesign something rather than take the time to completely reverse it.
______



rf-loop,

You are absolutely right about that nasty detail, called quality: It cannot be copied and it is the worst enemy of all the cheap copycats!
______



Anyway, I have drawn the schematics of the analog section and I will publish them shortly, right after I make them a little more readable than what they currently are. Right now I am trying to trace down a couple or three blind signal lines that terminate unexpectedly, since they go to a via and disappear into the four PCB inner layers, making it unable to find their destination.

Since I have not yet found anything odd in the design, according to the schematics I have drawn, I guess that what remains to do is to reflow the BGA package FPGA. After all, the malfunction of my device points to the direction of a possible bad solder joint; and the BGAs that run hot are notorious for this kind of failures --especially after the Pb-free directives enforcement era of producing junk devices that will die with mathematical accuracy the next day after their warranty period expires...


-George



[EDIT 1]: Uploaded the Ch1 analog front-end schematic sheet*.
[EDIT 2]: Uploaded the Trigger Input front-end schematic sheet*.
[EDIT 3]: Uploaded the DAC/Demux/Sample & Hold/Buffers schematic sheet*.
[EDIT 4]: Uploaded the Trigger/Comparator schematic sheet.
[EDIT 5]: Uploaded the Keypad & Indicators PCB schematic sheet.
[EDIT 6]: Linked to the DS1000E/D PSU schematic sheet, in the first page. I am sorry for that omission...


(*) Credits go to Squonk for spotting and reporting to me two(!) of my copy-and-paste errors in the previously uploaded Ch1 front-end schematic, an omission in the Trigger Input front-end, and a clarification in the DAC/S&H sheet! So, please, get the updated, correct ones.
Thank you, once more, Squonk!

[A Hellene]

Squonk, thank you once more for pointing out the errors and omissions in my schematics!
Creating schematic sheets is an art; but my copy&paste skills seems to be getting worse, especially when my time is limited...

Anyway, I corrected the diode omission in the trigger front-end sheet and made a clarification in the S&H one, where it is now clear that the S&H capacitors are not next to the demultiplexing chips; actually, they are located next to the buffer inputs to avoid the long line noise or any oscillations.
Please, download them again.

More on your comments in a following message.


-George

[A Hellene]

Ah, that's easy --and it gets even easier if you have to create from scratch the components your CAD software does not already include within its installed libraries!

It is obvious, though, that these schematics are drafts: They are even drawn not in graph-paper (for better alignment purposes) but in blank printer-paper sheets (that are not eraser-friendly) I have in abundance!


-George

[A Hellene]

Re-edited the message above, to add another sheet of the Trigger/Comparator schematics.


-George

[saturation]

Same here, Hellene is the wizard worth watching

I still like pencil schematics, fast and easier ... schematic tools are nice for presentations and PCB outsource work, but less for works in progress and hacking!

Wonderful!

I am following each schematic release with much more interest than in Harry Potter's next episode

[tinhead]

I still like pencil schematics, fast and easier ... schematic tools are nice for presentations and PCB outsource work, but less for works in progress and hacking!

sure, but when they start to be more complex (like whole DSO) you lose the game. I just finalized (first turn,
will check again all connections just due complexity) FPGA/SRAM/DRAM/NAND/SoC section of HanTekway DSO
schematic, without proper schematic tool i would get crazy.

[A Hellene]

Well, this is how it is: I have had a 256GB Crucial M4 SSD (a real rocket!) in my hands for almost a month, watching it collecting dust in a corner of my office, impatiently awaiting to see what this babe can do in my three years old PC box (one of the first eight-threaded quad core Intel i7 920 with blazing fast triple-channel memory of the lowest possible DDR3 latency, overclocked everything, including the buses, at 135% and going strong on a 24/7 basis since the time it was assembled!).

Since my system was very well tuned, I was extremely hesitant to be setting up again and configuring everything (the OS plus the programs plus their data plus their settings plus -you name it) from scratch, for the next ten days or so; I usually set up the system once, only when I change the motherboard or the OS. If I was running WinXP x64, migrating the whole system to a new HDD would be like going for a walk in the park; but Win7-x64 ostensively refused to copy the whole setup to a HDD of a different serial number! Thank you, again, M$... Anyway, I finally managed to migrate the system successfully to this blazing-fast SSD and the results were more than satisfactory; they were beyond any expectation! Even though I had my previous system installed on a Black-family Western Digital HDD (one of the fastest and most reliable commercial-grade drives with 5 years warranty)! I was amazed with the unexpected responsiveness my three years old system reacts to any of my commands, after the installation of the aforementioned SSD!

Well, I guess that now it is time for me to play with my other toys; and the forgotten and dismantled DS1052 came to my mind! I have purchased fresh flux and solder paste to reflow (meaning to de-solder, clean up, re-ball with 62/36/2 solder, and finally re-solder in place) the BGA package! But I am hesitating to do it because I know that I will be tempted to leave the FPGA un-soldered untill I draw the schematics of the digital section, as well...

You see, the thing for me is the nostalgia trip regarding the "old days" when I was hand-drawing everything; and I was raised with OC71's and AC126's! And, from the schematics I have published, I think that it is most obvious to the experienced eye the fact that it has been eons since I grabbed a real pencil for the last time and started penciling lines on a piece of blank paper! You see, though I used to be a calligrapher, I have not touched a pencil since the very early '90s, when my very first CAD software was a (paid) version of the QuickRoute Pro, just before I met with the the 32-bit Protel for Windows v1.5 (for Windows 3.1) that came in 2+4 1.44 floppies: Ahh, love at first sight! It is the DOS-ish flavor that I cannot stand in Eagle, for example, one of the remains of those days...
Halcyon days indeed!


-George

[A Hellene]

This is a minor update, since there has been some progress done --despite the lack of my spare time.

I am sorry though for the quotes that follow but I have already written the following down in a similar thread:

Ah, do not worry, tinhead! Copy mistakes are in order when reversing even a single-side PCB --not a six-layer one!

For example, I have also spotted a couple of these errors in the Rigol schematics I have posted: The Comparator Hysteresis driver in the "DAC, Demux, Sample & Hold and Buffer" sheet actually is a driver with a 5V0 to 3V3 level-shifter section implemented. By the way, I have de-soldered, cleaned-up and re-balled the Cyclone III FBGA chip, and when I will find some spare time I will draw the digital schematics sleets, too! You see, Rigol has a couple more DAC output signals (a 500.00mHz triangular (not sawtooth) waveform output and a waveform_start(?) signal extra circuitry that do not make any sence to exist in the analog section) that cannot be traced anywhere in the PCB; so, I removed the FPGA to see if these "blind" signals are fed into the Cyclone III.

Though I have not reversed the digital section of the Rigol yet, I think that the Lattice LUT (as well as the CLPD in your device) are RAM address lines generators for the FPGA configuration (which does not seem to have a dedicated address bus for the config. memory, so it probably clocks an external address-bus generator) and the BlackFin that cannot address the 22bit-wide boot-up Spansion FLASH memory alone because it has a 20-bit wide address bus hardware. But I could be wrong; I cannot really tell until I fully reverse the PCB...

What?!?
I am curious to know how do you do that?

With patience!

I think is is time for a short tutorial on the BGA and Flat Pachage rework process, using home equipment:

Equipment used: A hot-air rework station, a soldering iron, soldering wick (ERSA 2mm/3mm/4mm wide), flux paste (I prefer the RMA flavor but I've only found a no-clean syringe container at the local stores -that is fine for this job), SMD rework solder-wire (sub-millimeter Alpha-Fry 62/36/2) and flux soldering paste (EDSYN 62/36/2 no-clean).
Remember that the activated flux (RA/RMA) based products have only a few months self-life, even if stored in the refrigerator.

This is the rework strategy:
1. Preheat the PCB using 130 degrees hot air for 2-3 minutes, to avoid any thermal expansion artifacts,
2. Use conventional (kitchen) aluminium foil to protect the surrounding components, by cutting off a small window to expose ONLY the target chip to the hot air flow,
3. Desolder the BGA using 300..320 degrees hot air, remove the chip and wait for everything to cool down,
4. Clean the old solder, holding the BGA package in a small plastic vice using solder wick and lots of flux; always clean the used flux (I use medical alcohol of 95 degrees or better),
5. Clean the PCB, as above,
6. Reball the BGA with the soldering iron, Ag-containing solder-wire (I use 62/36/2) and lots of fresh flux; always clean the used flux,
7. [Optional step] Reverse the PCB (that takes tiiiiiiime...),
8. Reball the PCB pads as well, as in step (6), since chip re-balling has not provided the pads with enough solder,
9a. Carefully apply flux soldering paste on the PCB pads only and flux at the chip pads, or
9b. Apply flux in lack of flux soldering paste,
10. Carefully place the BGA package on the PCB (in a single move, if possible) and
11. Preheat the whole PCB area around the chip using 130 degrees hot air for 2-3 minutes,
12. Raise the hot air temperature at 280..300 degrees and apply it to the chip in a slow circular motion,
13. Wait for the molten solder surface tension to move the chip in place when the solder melts,
14. Tap the chip gently towards the PCB, to make sure that all its pads are in contact with the solder underneath,
15. Remove the hot air and wait for everything to cool down naturally (by themselves); always clean the used flux, and
16. Done! Power the device up.

Right now I am at the seventh step...


NOTE: It is not as difficult as it sounds to be; but you need to practice enough before daring to touch your actual device without destroying it!

A second note is about the chip size: As a rule of thumb, use a hot air nozzle of half the diameter of the chip size. For chips smaller than 20mm x 20mm you may skip the PCB preheating step, only if the PCB is very thin. Unfortunately, this is not the case with Rigol's mainboard.

A third and very important note: Always know what you are doing. Always use your common sense! Miracles happen only in fairy tales...

Finally, remember that a good tool is NEVER expensive enough to have it. Just consider the possible extra cost of a damage done by using cheap ("affordable" in the marketing jargon) tools...


-George

[IanB]

Remember that the activated flux (RA/RMA) based products have only a few months self-life, even if stored in the refrigerator.

Do you refer here to solder paste specifically, or to other solder/flux products too?

Correspondingly, do you imply that no-clean flux solder paste has a longer shelf life than the RA/RMA based product?

[A Hellene]

According to the datasheets of the products I use, I have never seen any mentions about the self-life of the no-clean fluxes, with the exception of the no-clean solder paste that has no more than six months self-life.

I am under the impression that the RMA fluxes have a typical self-life of a couple of years, and the RA ones even less. Additionally, I think that most, if not all, of the soldering wires have non-activated rosin (R) flux cores.

Are you aware of any no-clean flux products (with the exception of soldering paste) that have limited self-life?


-George

[IanB]

I have solder wire with RA flux and also some with no-clean flux. I do not know how to choose between them so I have tended to pick the RA flux. Apart from solder wire I also have some different containers of rosin paste flux and rosin liquid flux. The liquid flux says RA, the paste flux just says "rosin".

I have always thought that flux cored solder wire and rosin flux would last indefinitely. I have certainly seen rosin flux that still seems to work after many years of storage, although the paste flux can apparently dry out if not kept in an airtight container.

I have never used solder paste, but I have heard many people tell it has a short shelf life. I was therefore interested when you seemed to mention that no-clean solder paste might not have such a limitation. Apparently though, it doesn't, and all solder paste needs to be used within a short time of purchase.

[flolic]

6. Reball the BGA with the soldering iron, Ag-containing solder-wire (I use 62/36/2) and lots of fresh flux; always clean the used flux,
7. [Optional step] Reverse the PCB (that takes tiiiiiiime...),
8. Reball the PCB pads as well, as in step (6), since chip re-balling has not provided the pads with enough solder,

I tried that method few times, and while in general that works, I was never really satisfied with it. So in the end I purchased various size solder balls and direct heat stencils and that works so much better and quicker.

14. Tap the chip gently towards the PCB, to make sure that all its pads are in contact with the solder underneath,

Be veeery careful doing this because any excessive pressure/movement of chip will displace molten solder from pads and squeeze it out, create shorts and various other nasty problems. Remember, we are talking of allowed tap motion of a fraction of millimeter! I learned that hard way despite being very careful...
So I don't do that any more, and simply let gravity do the job.
Also, when using reballing method with solder balls and stencil every ball is exactly the same size. When you heat up the chip and PCB to the solder melting point, you can see the chip "drop" as the balls melt and collapse.
I done that so many times with 100% success... 

[A Hellene]

Ian,

Thank you for the information. I was confused about the rosin and the resin based fluxes. After looking that up, it seems that the only difference between them is that rosin fluxes are based on the natural pine tree rosin and the resin ones are based on synthetic or modified rosins...

I was mostly using resin flux paste but switched lately to liquid synthetic flux, which seem to be more efficient but its residue is stickier and more difficult to be removed with alcohol. A three years old ERSA liquid no-clean flux I still have seems to be working as it did when it was purchased. The mildly activated flux (RMA) seems to be ideal for manual soldering, since it is even stronger and easier to remove. I have no experience with the activated (RA) fluxes, though.

Until recently, I used to solder the flat packages with the soldering iron; but it was a pain to de-solder them. The hot air rework station solved this problem for me and made soldering even easier; but it requires better ventilation. Using solder paste has been a fairly new experience to me and I really like the way it works. It is very easy though to short any neighboring pins if not applied carefully; but it does not really take long to become familiar with. The solder paste limited self-life does not became an issue by purchasing smaller quantity packages (e.g. 10g product in syringe).
_____



flolic,

Thank you for sharing your experience! Yes, I am aware of the dangers you mentioned. Re-balling with the stencil method is ideal; doing it manually, the secret is to apply the same amount of solder everywhere!

This can be done by applying smaller solder balls to both the chip and the PCB pads. By re-balling each pin individually, some pins will receive more solder that the others. This can be prevented by pouring solder to the pads by steadily dragging the soldering iron tip along them all, and not insisting on each one of them. With plenty of flux, of course. If there is not so much solder, it becomes safe to gently tap the chip towards the PCB, as a last move to ensure the sitting of all its pads.


-George

[IanB]

I've just discovered after doing a bit of investigation that no-clean flux and rosin flux (R, RMA or RA) are variations of the same thing. The no-clean flux is a kind of RA flux with very similar properties. Neither RA flux nor no-clean flux need to be cleaned from a finished board to prevent corrosion, but they may need to be removed for appearance sake or to allow conformal coating.

On the other hand, water soluble flux is totally different from rosin flux, and this flux residue must be completely removed from the board after soldering by thorough and complete washing with water or a suitable solvent.

A general trend and recommendation for both home build and industrial users is to avoid water soluble fluxes and prefer rosin type fluxes, especially including solder paste and SMT applications. This is because water soluble flux residues may get trapped under SMT components where the washing process cannot reach them, and in that case corrosion from the aggressive flux residues may cause trouble down the line.

Although RMA type rosin fluxes might seem milder, my reading suggests no great concern about leaving RA flux residues behind. One may as well use RA flux as it is likely to work better on dirty or oxidized surfaces.

[Lightages]

All this soldering and BGA information is very useful, very much more useful in its own thread instead of buried in a thread about the performance of the DS1052E.....

I know that it is inevitable that a thread always gets sidetracked or hijacked but this is really mixing things up. I was hoping that we would see less threads going off track in this forum. Humans will be humans I guess 

[IanB]

I'm sorry. I was thinking of this when I posted it, but unfortunately threads are not the best way to organize information. What forums really need is keywords and labels the way Google mail has it. For me, I always resort to search tools when I want to find stuff...

[IanB]

I have started a new thread on solder fluxes in the technical info section.

[A Hellene]

Ian,

Thank you for the quite interesting pieces of information you posted. I was already aware of the water soluble fluxes aggressive corrosiveness. But I was under the impression that the fully activated (RA) rosin flux was also corrosive. Having no further investigated about the no-clean fluxes, other than just reading the data sheets of the specific products I used or randomly selected other ones in comparison, I was avoiding the RA fluxes as well.

I used to have as a generic guide a piece written in 2003 by Colin O'Flynn, a member of the AVRFreaks community I am also a member of. Let me cite a few of his words, regarding the differences between the Kester Rosin flux RMA 186 pen (Kester PN. 83-1000-0186) and the Kester Rosin flux 951 no-clean pen (Kester PN. 23-6337-8806):

The flux is very very important. It comes in pens, which makes applying the flux very easy. The pen's have a shelf life of 2 years, so they should be good for a while. The lower the number with the flux the more active it is. As a flux's activity increases, it normally makes soldering easier as it resists solder bridges more. If the activity is high enough though you MUST clean the flux off the board or it will eat the board away. The RMA 186 flux is nice in resisting bridge's, but it doesn't need to be cleaned off the board. Some applications might need you to clean it though, and to do that you can use rubbing alcohol and some sort of brush or swab. The 951 no-clean is designed to not need cleaning off the board. If you need a high-impedance application or very sensitive boards you will probably have to clean it anyway. The 951 doesn't resist bridges as well though. Will discuss which one to apply later.
[...]
IC's are slightly harder than the two-pin devices, but not too bad. However first we have to discuss the flux pen. You can use either the 186 RMA or the 951 noclean. If you will be doing a fairly fine lead pitch the 186 would probably be the better choice. If you don't need as an active flux because you will be doing a fairly large pin pitch you can use the 951 flux. For example the TQFP package will benefit from the 186 flux, but a SOIC package might not need the 186. However if you only want to buy one flux pen it should probably be the 186 as it is more universal.

Emphasis in mine.

Regarding sidetracking/hijacking of this thread, this in not the case to me, therefore there is no need for apologies. On the contrary, the information contributed is essential and absolutely in line with the subject matter of this discussion, which is now about the reverse engineering of a PCB suspected to be faulty. Please, feel free to pop in at any time!
_____


Lightages,

Thank you for your concern. You described it very well, yourself: It the human nature factor that makes the progress, after all!

Please, feel free to quote any parts of my messages (since I can only speak for myself) you like or find interesting enough in order to contribute, either by adding to the conversation or by summurising them in an existing or in a new discussions thread.

After all, what we really do is exchanging views!
_____


Squonk,

Do not worry, my friend! Things will take their natural course, since it seems that we have a lot of cultivated, educated and caring people over here.

Furthermore, I would invite our host, Dave, to add to rather than subtract from this discussion!



-George

[A Hellene]

I think I should quote a couple of additional views I have exchanged with tinhead about the manual BGA reballing technique, since his solution is superior to this I described in the BGA/FP rework mini guide I published yesterday:

ahh, you using the ugly method (self-made "balls"). I tried it once, for K4S561633F because i didn't had right balls here.
The first run was "disaster" (because of the DIE encapsulat in the middle or the RAM chip), second run was finally working - few weeks later this board started to crashing so i had to resolder again (with proper balls), since them (more than a year) the board is working (24/7).

Therefore i can only say, buy proper balls, they didn't cost that much to risk the FPGA. Sure the best is to have reballing set with stencil to place balls, but believe me, even without stencil you can easily place them one by one.
Just put a bit of flux on FPGA - note too much and they will "swim" away, to less and they will not stay in place when using hot air - better is to use IR (or whatever oven for reballing) - watch them careful during this process, when one starting to move around remove it and place new one (with tweezers or preheated soldering iron).

Thank you, tinhead!

This is a great idea! Re-balling manually the BGA chip with standard solder balls is the best solution, in order to have a homogeneous and uniform solder quantity on every pad! Without even the need of the special stencil equipment!

All I will have to do is to wait for the local stores to open after their summer break; or, to place an online order. But, something tells me than I may have not yet finished reversing the PCB...

Anyway, your idea is marvelous! Thank you, again, for the solution you gave me!

It seems that this is not only a better solution but an easier to implement as well!
Thank you, tinhead!

-George

[IanB]

Thank you for the quite interesting pieces of information you posted. I was already aware of the water soluble fluxes aggressive corrosiveness. But I was under the impression that the fully activated (RA) rosin flux was also corrosive.

I believe at this stage one must move from the general to the specific, since not all RA fluxes from different sources might have the same properties. The RA flux in my possession comes from MG Chemicals, and this is what they have to say about it:

Liquid Rosin Flux 835

For leaded and lead free soldering. Fully activated. Offers superior fluxing ability. Instant wetting. After soldering, the rosin residue is non-corrosive, non-conductive, moisture and fungus resistant.

Although they do not call this a no-clean flux, I infer from their description that there is no specific requirement to clean off any flux residues left behind after soldering.

[A Hellene]

Ah, yes, I see. A lot of more specially formulated products, not necessarily closely related to other ones of the same category.

Incidentally, what I have lately purchased is their No-clean flux paste 8341, whose also "the residues do not need to be removed for most applications."


-George

[Lawsen]

I have the same 1052E oscilloscope on my cart table top.  It shows noisy, when nothing connected to it.  It is not as clean as the 2200 series analog Tektronix oscilloscopes in my memories.  Agilent oscilloscopes the noise is fuzz line, but not a with spikes as shown here in your posted pictures.  The 1052E does show what I need to see.  The input channel filtering capacitors are designed to leave the signal as original as possible or the probe?  I have not tried other 1X or 10X probes or earlier 1052E models.  I will not be able to, because I do not need two 1052E.

[alm]

Measuring the open circuit noise measures inherent noise, shielding and the amount of EMI in your environment. Amplifier/digitizer noise is usually measured with shorted inputs.

[A Hellene]

I have the same 1052E oscilloscope on my cart table top.  It shows noisy, when nothing connected to it.

This is normal, since it displays the internal self-generated noise of the instrument plus the noise generated by the unshielded switching power supply it has, or anything else the probes are picking up from the environment when connected. The truth is that the RP2200 probes are quite noisy; using better probes you should have cleaner waveforms, as I did.

[In] Agilent oscilloscopes the noise is fuzz line, but not a with spikes as shown here in your posted pictures.

As I have written in another thread, my first DS1052E was working quite well, in contrary to the second one I received, which I am currently discussing about, that came defective straight from the factory:

I wrote: "If this specific device was the first one I laid my hands on I would think that this is the average quality of those instruments and --probably-- I would not even bother complaining about it. BUT this is my second DS1052E and the first one was perfect in comparison. If you recall my very first message, where I posted the 2.05 SP2 hack, I was happy with the instrument, even though I called it "a quite noisy oscilloscope." The truth is that I was able to read almost perfect waveforms of a few millivolts p-p amplitude on shunt resistors of a switching power supply I was working on; and I was pretty happy with it. Now, I only have to touch the ground clip to the probe tip to literally fill the display with a ~100MHz noise garbage that prevents me from reading even the 3.0V calibration output..."

You can try to do a test, yourself: Set a single channel to maximum vertical sensitivity (20mV/div), probe & probe settings x10, no filtering and timescale 5.0 ms/div; you will see a noise level floor of a small fraction of one division, which is normal for those settings. Now, short the probe tip to the probe ground lead alligator: The noise level should decrease, in contrary to my defective unit where it literally jumps to a five divisions noise mess, as depicted in my snapshot called Noise 3.


-George

[torch]

You can try to do a test, yourself: Set a single channel to maximum vertical sensitivity (20mV/div), probe & probe settings x10, no filtering and timescale 5.0 ms/div; you will see a noise level floor of a small fraction of one division, which is normal for those settings. Now, short the probe tip to the probe ground lead alligator: The noise level should decrease, in contrary to my defective unit where it literally jumps to a five divisions noise mess, as depicted in my snapshot called Noise 3.

Ok, I tried it. And the results were pretty much as described. Then I tried touching the probe tip to the chassis ground just below the calibration contact: My screen then looked very similar to your screenshot -- 6 or 7 divisions of noise. I repeated this experiment with various other probes (the Rigol 150MHz ones that came with the scope, a set of 250MHz Coline probes, even a 100MHz 100x probe -- all with similar results (although the Rigol probes possibly had the greatest amplitude). I tried it against all the exposed BNC connector ground points too, with the same results.

I don't know enough about the insides of these things, but could your problem have something to do with matching the probes? I get the cleanest line by setting the coupling type to GND. Obviously that must by-pass something in the input or I would see similar noise to touching the probe tip to chassis ground. What happens if you set yours to GND? Perhaps that experiment might help localize the source of the problem?

[A Hellene]

[...]
Ok, I tried it. And the results were pretty much as described. Then I tried touching the probe tip to the chassis ground just below the calibration contact: My screen then looked very similar to your screenshot -- 6 or 7 divisions of noise.
[...]

I am sorry to read that, dear torch. It seems that not only my device has this noise problem... My previous (brand-new also) DS1052E, the one I had used a few months ago to do the hack (that is not in my possession anymore), did not have this problem: Shorting the probe input decreased the noise further instead of creating this ~100MHz noise mess that covers half the screen.

If you have a 50 Ohm terminator, connect it to the BNC input and repeat the test. This way you eliminate any possible probe-induced noise and errors.

Unfortunately, I cannot power-up my device right now, since I have de-soldered the FPGA (the Cyclone III) in order to create the PCB schematics of the digital section also. But I remember that setting the input coupling to GND, the residual noise disappeared completely, which means that a lot of circuitry and code functions were bypassed, since it is unnatural not to see on the screen the ADC digitation error noise of +/-1 LSB (the sum of the quantization errors introduced during the ADC conversions).

I do not know yet what causes this malfunction, which has also been reported in April 2010.


-George

[torch]

I am sorry to read that, dear torch. It seems that not only my device has this noise problem... My previous (brand-new also) DS1052E, the one I had used a few months ago to do the hack (that is not in my possession anymore), did not have this problem: Shorting the probe input decreased the noise further instead of creating this ~100MHz noise mess that covers half the screen.

I may not have been perfectly clear: I have very little noise (< 1/4 division), with the probe open. A touch more if there is a retractable hook mounted to the probe, and a bit of 60Hz sine wave overlaid if I touch it to my finger (mains are 60Hz here). Shorting the probe to the ground clip on the test lead itself (as you describe) reduces the noise further. It is only when I touch the probe to the chassis that the excessive noise appears.

If you have a 50 Ohm terminator, connect it to the BNC input and repeat the test. This way you eliminate any possible probe-induced noise and errors.

Ok, tried that (using a BNC tee and 50 ohm terminator as I don't have an in-line one) Connecting the terminator to the open BNC connector reduces the noise slightly (similar to grounding the tip with the lead ground clip). Installing the probe makes no difference. Touching the ground clip to the probe tip reveals a 3/4 division 130kHz signal, as the ground clip lead is acting as an antenna and picking up some RF. Shorting the tip with tinfoil confirms this, as the noise quiets and the 130kHz signal is not present then. Touching the tip to chassis ground produces 3-4 divisions of noise -- not as bad as without the terminator, but certainly present! Touching the chassis ground with the tip shorted in tinfoil does not produce any additional noise.

The difference in noise levels makes me think of the problems associated with having an unmatched cable on a radio transmitter. Years ago, I used to play with CB radios (~27MHz) and we would tune the cable length by cutting off a bit of co-ax at a time to find the sweet spot where reflections in the cable/antenna combination canceled each other out. I wonder if this noise could be tuned out with a variable inductor?

But I remember that setting the input coupling to GND, the residual noise disappeared completely,

Same with mine.

[A Hellene]

I am sorry for misreading your message, torch. It seems that I need to be sleeping some more...

From the description of the noise you are reading, your device seems to be working fine. The 130KHz signal you read when probing the grounded parts of the device is the switching PSU generated noise and if you play with the triggering point & edge you will be able to see the switching pattern of the TOP24x based PSU with the trailing ringing after the power pulses.

The noise my device has is of a very high frequency (~95..100MHz), as it is revealed in the "Noise 8" and "10" figures, which makes me associate it with the 100.0MHz device internal main time-base.


-George

[A Hellene]

Hehe! It is perfect!

Thank you both, flolic and tinhead, for your suggestions to use proper solder balls to reball the Cyclone III FPGA instead of improvising with a soldering iron and solder wire.

The FPGA 256-Pin FineLine Ball-Grid Array (FBGA) package has pads of 0.50mm diameter and 1.00mm pitch. Reballing was done by hand (without a stencil), using regular 63/37 alloy solder balls. It took me almost half an hour to do it, by applying gel flux to the cleaned chip pads and pushing every individual solder ball in place before baking the chip using 220°C low velocity hot air to avoid blowing the solder balls away. Surface tension magic did the solder balls alignment.

Before resoldering the FPGA back to the mainboard, in order to power the device up, I will have to verify the connections diagram I have drawn.
__________


Anyway, this is a quick preview of the DS1000X design (that may be partially erroneous since I have not yet drawn the final schematics, to have the whole picture available):

What I find kind of strange in the design is the use of two global buses; a 16-bit wide data bus and a 22-bit wide address bus, interconnecting almost all the stages: The BlackFin DSP to the Spansion boot FLASH RAM & the Hynix system SDRAM chips as well as the Lattice LUT that is a peripherals and memory manager, the Altera FPGA that handles the ADCs and the data acquisition storage Issi SRAM, the Philips USB controller and the optional logic analyser Logic Head.

The FPGA and the Logic Head share of the global address bus is 8-bits wide only, feeding the BlackFin with one screen of data (256 points of two channels data) at a time, on demand.

The DSP feeds the LCD controller with the display data using a local 8-bit wide data bus and talks serially to the Keypad PCB and to a 4Kbit FRAM system preferences memory.

The LUT is in charge of addressing the upper three MSB of the Spansion FLASH RAM and the 18-bit wide Issi SRAM local address bus. It also controls the analog front-end and the analog & triggering section parameters.

The Issi SRAM holds the ADC aquisition data read from & fed to by the FPGA that uses a 4x8-bit wide local data bus to talk to the memory.

The FPGA configuration scheme is set to Active Serial Interface mode (MSEL2:0 = 0b100) and the the BlackFin acts as a passive serial configuration device during FPGA configuration.

Finally, the JTAG ports run on 3.3V
More to come, soon.


-George



EDIT: After a closer examination of the picture, it seems that the C16 solder ball (the third one up, counting from bottom right) needs to be replaced...

EDIT 2: A few corrections and additions.

[saturation]

Wow, that's great hand work George, it takes balls to fix those balls 

I'd be afraid to touch chips of that type, I fear damaging something permanently that I just paid $400 for, but your work looks fantastic.

This is a great unfolding story, thanks for posting.  Its also fun to read the enthusiasm you project in your writing as you go through this scope dissection.

[A Hellene]

Thank you, dear Saturation!

Your first line gave me a really big smile!
Thank you, also, for your nice words. You are very kind.

You are right; if this was a commercial job I would think twice before touching such components. On the other hand, this was a calculated risk I took: This $15 worth FPGA chip keeps no secrets inside of it; when powered off it becomes 100% identical to a brand new one. So, the fear of destroying the chip is actually reduced to a mere concern of having to replace it in the worst case.

Dissecting the DS1052 without having the complete service literature for it is, at least, a sacrilege. Of course, throwing $400 away is not a constructive nor an enjoyable thing to do. But, since I purchased a malfunctioning device without having the safety net of the official after sales support, viewing the same situation from another angle it certainly becomes an exciting challenge and one hell of a learning experience, as well as a relentless spare time killer! The bottom line is that even if I fail to restore the DSO to an acceptable working condition, I will have only thrown €240 out of the window; the learning experience (not to mention the game itself --you know, boys with toys!) is always a bonus!

You see, according to my personal views, everything we do, or we not do, has its risks, its cost and its returns...


-George

[rigol_owner]

Hi George,

I have found this thread by googling. I have recently bought a Rigol DS1052E.
I am also experiencing strange, quite strong 100MHz-or-so-ish noise when shorting the probe and touching ground somewhere. My scope is very quiet with an open (nothing connected) BNC input. Noise is then about 200uV RMS.

I have used the FFT function to view the spectrum of the strange noise signal.
Surprisingly, the spectrum shows that most of the energy is in the 88-108MHz band. I my country (Netherlands); that is the FM broadcast band! I also see a lot of energy in the 6-7MHz region. Don't know what that is, maybe SW radio?

Anyhow, my guess is that the noise is caused by external RF pickup. Maybe there is something wrong with the grounding of the BNC plug inside the scope. I haven't opened my scope yet as I've bought mine through the official distributor but maybe this is something to check on your scope?

Regards,

Rigol_owner

[Lawsen]

The Rigol 1052e is the standard oscilloscope for many.  We should take survey of which oscilloscope is our favorite out of the many.  It is like the sciences, which microscope is your favorite?  If one of you is an amateur astronomy, then the conversation is which telescope is the favorite?  From my experience, all digital oscilloscope have some noise.  The Atten 1102CAL has noise, but if your signal is larger than the noise, then it is no problem.  For my application for checking signals inside a giant plotter, the signal is larger than the noise, then no problem.  Those working in product development like low voltage signals, then that might be a problem.  What matters here is signal to noise ratio.  As long as the signal is larger than the noise, that is not a problem with my interests and needs. 

Oscilloscopes that I have experienced with more noises are :
Atten 1102CAL
Rigol 1052e
Tektronix 2002c

The oscilloscope with the least noise is the Agilent 2002a at 70 MHz and two channels.

The most used oscilloscope in my place and for the on call jobs with giant plotters are the Rigol 1052e, smaller and compact and inexpensive to use.  I do not use the Agilent 2002a much for fear of dropping it or breaking it.  I cannot afford to have it repaired, if broken.  I do not have a Tektronix 2002c, but dream of trying it.  The Tektronix 2002c feels like an Atten 1102CAL.  I have tried the Tektronix 2002c like, on display in the Fry's Electronic store in San Jose, California.  It has that noise.  The smoothest oscilloscope is the analog oscilloscope like older Tektronix, Hameg, and Hitachi oscilloscopes.  I do not have any of these.  Analog oscilloscopes simply feel different and smooth.  It cannot record waveforms, that will need a camera film or digital to take a picture of the screen with a camera macro lens. 

[alm]

Try to use a proper RF short (eg. BNC shorting cap), not an antenna if you want to check scope noise performance. Clipping the ground lead to the tip is not a short at 100MHz. A BNC 50ohm terminator works fairly well in my experience, since it has a very small loop area and typically low inductance.

One reason why analog scopes may appear less noisy is that a cheap DSO without any DPO-like features only has a 1-bit intensity resolution. That means that a very rare noise peak will appear the same intensity as a constant signal. An analog scope has an intensity more or less proportional to how frequent something happens, so uncorrelated noise will appear fairly faint.

[rigol_owner]

I know that shorting the probe tip with the ground clip is not the best way to measure scope noise.
I also know that noise looks different on an analog scope.
But what the Rigol is showing is excessive. I also have an analog Philips PM3055 scope here that doesn't show a hint of RF pickup in the same setup.
I also use Agilent scopes at work that have never shown this behaviour.

In my opinion the noise could be explained if the BNC plug is not properly (low impedance at all frequencies) grounded to the ground plane of the scope's front end.
This way, any common-mode noise picked up by the probe lead and connected circuits are directly coupled into the front-end amplifier.
Looking at the photo's from the ds1052e teardown (eevblog #37it "seems" like the BNC plug is grounded through a small PCB track instead of soldered firmly.
However, I cannot see it clearly. I haven't checked on my scope as my scope is still under warranty.

Btw, I love the Rigol DS1052e, even with the noise problem! I use it at home for my hobby stuff (currently designing/building an integrated tube amplifier) and it's better than any scope I've ever had. Offcourse, the Agilents at work are better but for the money, it can't be beat imho.

Regards,

Rigol_owner

[saturation]

Yes, hellene has found that some of the newer production units are noiser than the older models; see photos of my older Rigol near the start of the thread.  The spectra I've found of the noise using FFT is similar to your first post, but at lower amplitudes.

..Btw, I love the Rigol DS1052e, even with the noise problem! I use it at home for my hobby stuff (currently designing/building an integrated tube amplifier) and it's better than any scope I've ever had. Offcourse, the Agilents at work are better but for the money, it can't be beat imho.

Regards,

Rigol_owner

[A Hellene]

Hello, Rigol_owner,

Thank you for joining in to share your observations and opinions.

I also like the DS1052E design and behaviour, and this was the reason why I got myself the same device after having given away the first unit I purchased. Though I acquired both the units within a couple of months, the first one returned decent results; I could probe current shunt resistors (of a few milliohms value, being electrically equivalent to shorting the probes) of a switching PSU I was working on and the device returned nice waveforms. But this is not the case for my second unit. Though the noise floor of both the units was almost the same, when grounding the probes of the second one its display was literally filled with very high levels of an apparent VHF sinusoidal-like noise, of a frequency that was suspiciously identical to the 100.0MHz internal timebase of the device. See the "Noise 8" and the "10. Ch1 probe" screenshots, I posted in the first page:


Noise 8: Ch1 probe on the probe calibration ground (sampled at 500MSPS)


10. Ch1 probe on the probe calibration ground, in dot mode (sampled at 1GSPS)

In both the waveforms above, the signal period width seems to be very close, if not equal, to 10.0ns. Is it a coincidence? I think not, since there is a 10.0ns period crystal oscillator timebase on board (based on the 'AHC04 hex inverter) that feeds with a 100.0MHz clock directly the CPLD (that clocks the DSP, the SRAM, the FLASH and the LCD controller), the FPGA (that clocks the ADCs) and the optional logic analyser Logic Head header.

Furthermore, there seems to be a small pause of the 10.0ns signal in the "Noise 8" figure, interpreted and depicted as a glitch at the time point -0.8 .. -0.2 div, where the signal phase is somehow inverted by 180.0°; this might be the missing pulse that prevents the (hardware) frequency counter from reporting a 100.0MHz signal and shows a ~95MHz signal only.

Is this a poor decoupling related problem? It might be; but this is a 6-layer PCB and it is next to impossible to verify the ground and the ground plane vias continuity. The very noisy internal SMPS certainly contributes to the overall noise of the device; but its switching frequency (~200KHz) is nowhere near the 100MHz region...

Does it also seem to be the result of an overloading I/O stage? Some sort of excessive subthreshold drain currents or crowbar power dissipation? Probably, since the noise problem seems to be symmetrical for both the input channels, something that suggests that the problem exists in the common sections beyond the analog front ends...

Anyway, I will agree with you that I have never seen these levels of VHF noise when grounding the probes in any other oscilloscopes. I guess that we have both been, amongst others, the lucky winners of this specific (non-)QC market...


-George

[firewalker]

I hadn't read this thread for a while.

Go go George!!!

Kala, milame, ta SPAS!!!

Alexander.

[A Hellene]

Thank you, firewalker!

Special thanks, also, for your encouraging comment!


-George

[rigol_owner]

First of all George,

You have done a impressive job investigating this problem. Removing, reballing and resoldering an FPGA is not something I would have dared 
Also , I'm sure I can live with the problem as the digital filter function of the DS1052E does a real good job of filtering out the noise. After all this scop is just a tool.
If you now it's weaknesses and it's strengths and you know what you're doing you can do anything with it.

As for the noise however, I'm still not convinced it is noise picked up from the internals of the scope.
Take a look at the screenshots i've attached.

The first one shows the result of a large loop; a 1:1 probe with the tip connected to the ground test point.
You can see the FM broadcast spectrum with a large peak around 106.6 MHz or so.

The second one is with a small loop; the probe lead is loosely twisted together. Notice the main peak is almost 10dB lower.

The third one is interesting. It is a large loop with a small transistor radio nearby tuned to 106.6MHz. You can clearly see the radio's LO 10.7MHz apart from the 106.6MHz peak!
When turning the tuning knob I can move this LO peak from left to right.

To me, all this indicates (at least in my scope) that the noise picked up is external. However, why is the Rigol so sensitive to this kind of noise? I still suspect it has something to do with grounding or with the layout of the front end.

Regards,

rigol_owner

PS This scope is really wonderful, even with it's 50MHz bandwidth it can be used as a spectrum analyzer to diagnose an FM radio 

[tinhead]

buy IPA, open both input stages and cleanup the PCB, this looks for me as self self oscilations from varicap or AD8370.

[scrat]

Interesting. Did something similar already happen to you?

[tinhead]

the varicap can easily self oscilate and pickup every crap, AD8370 as well. Especially when the manufacturer
didn't cleaned up the PCB properly or when the gridding (on AD8370 or LMH6552) was too deep.
And yes, it happens already on my DSOs - twice - first time AD8370 gridding too deep + dirty PCB (the scope
was self oscilating even without power, that was funny) second time (on a different scope) PCB around varicap dirty.

[scrat]

So they are probably not joking when in the AD8370 datasheet (p. 16), they state:

"Do not use silkscreen over the signal line because it alters the line impedance."

Wow, so what should be the accuracy of pcb manufacturing?

[A Hellene]

It's been a while, I know my fellow EEVBloggers, but I was busy during the last couple of months.

In an attempt to redeem myself I am posting yet another schematic sheet I have recently drawn!
This time it will be the Keypad & Indicators PCB.

In the circuit it is clear what the I/O bitstream should look like for any control asserted or any indicator activated. Now, regarding the Keypad PCB connectivity, the LEDs serial data comes from the SPORT0 primary channel of the DSP and the keypad/encoder serial data are fed to the SPORT0 secondary channel.
______________________________


As I wave written in a similar thread, when I resoldered the FPGA back on the mainboard the noise issue was neither improved nor deteriorated. After a few days, while discovering a few mistakes in the PCB wiring diagrams I drew, I removed the FPGA once again to correct them and resoldered it back; but it seems that the chip was not soldered properly aligned this time and mangled the calibration data... I am not even sure if I have damaged the FPGA by the accidental bridging. I guess I should be looking for a ZIF socket to put in there!
Fortunately, the rest of the device seems to be unaffected and the FPGA is a low cost component (~$15) that can be replaced directly.

Anyway, this was the excuse I needed in order to begin studying the Blackfin processor, since I do not have any prior experience with the ADSP family, in order to find a way to be accessing the boot FLASH memory without the need to be physically removing the chip; you see, EEPROM cells gravely hate to be heated...

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

[amspire]

George,

Please keep us informed of your discoveries.  It is really interesting for us Rigol owners.

Wouldn't it be great if one of these companies just made the hardware and let the software be a fully open-source project?

Just like Lynksys did with the WRT54G routers, they would probably have a huge leap in sales.

Richard.

[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.

[vinicius.jlantunes]

Welcome back to the best of the hobbies! 

[saturation]

Welcome Samogan, can you check last I recall the Keysight version had 16kpts of memory.  Can you confirm?

FWIW Rigol has 1Mpts and changed the control layout.

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.

[Samogon]

Welcome Samogan, can you check last I recall the Keysight version had 16kpts of memory.  Can you confirm?

FWIW Rigol has 1Mpts and changed the control layout.

saturation
Thank you
Yes it is 16kpts, and it is clearly shown on picture there is not populated SSI IS61LPS/VPS25636A 9Mb memory chip

[saturation]

Thank you Samogan.  Of interest, to save on production cost that model is one of the few instruments sold by a big name like Keysight than is CE rated for safety, versus the Rigol with full TUV, not a big issue for its intended use. 
 

Welcome Samogan, can you check last I recall the Keysight version had 16kpts of memory.  Can you confirm?
FWIW Rigol has 1Mpts and changed the control layout.

saturation
Thank you
Yes it is 16kpts, and it is clearly shown on picture there is not populated SSI IS61LPS/VPS25636A 9Mb memory chip