Loaded in Wildcat 5.1 easy on Windows 7 with DSO Quad plugged into USB2.0 port. I wanted to reproduce Wildcats test of ADC but do not know what source of sine wave is. It looks like on picture of screen that wave generator on DSO203 was not used. I want to do exactly the same just in case.
All modes have 150 samples (5 divisions or a bit less than half a screen width) pre-trigger.
The actual trigger point is at the vertical orange trigger cursor, the one that moves when shifting XPOS. Anything to the left of this cursor is the pre-trigger section. If the window is shifted all the way to the left with XPOS, the orange trigger cursor will appear to move to the right towards the middle of the screen. The window and cursor (along with the waveform if triggered) will slow down at the very end to provide fine positioning.
In Single mode, the buffer defaults to the large buffer format, even when the buffer is set to single window. In large buffer mode, the window can be shifted down the length of the entire buffer with the XPOS control, some 10 windows width so if it is shifted to the right, the trigger point along with the pre-trigger section may not be visible unless you bring the window all the way back to the start at the extreme left. The small rectangle at the bottom of the screen will show the position of the window in relation to the buffer.
If the buffer is set to one of the oversampling or averaging modes, the buffer length will be one window’s width plus the pre-trigger section, even in single mode. In this case the window can only be shifted to the right a little ways, just enough to bring the trigger point to the left of the screen.
So in summary, to see the pre-trigger section, simply shift the window all the way to the left with XPOS, until the orange trigger cursor moves to the right towards the center of the screen.
The wave frequency was about 50Hz, however this is not critical. The noise was more obvious at slow timebases (2mS in this case) and occurred at specific levels, as can be seen in the screenshot. Seems as though the wrong bits were engaged as the ADC processed the incoming analog data.
Note however, that this was only observed on hardware V2.81 devices when the accompanying FPGA was also loaded, so that the full speed mode can be engaged, and while it was most severe with this full speed mode engaged, it was also observed to a lesser degree in normal modes.
So this test is only relevant if you have installed both Wildcat 5.1 and the FPGA 1.1 included with the update. Note that this FPGA in ONLY FOR HARDWARE V2.81.
Wildcat,
I am brand new to the dso203 and am still playing around with the system and the instructions in the V5.1 upgrade. I do have a new Ver 2.81 with the new wildcat V5.1 including the new FPGA 1.1 that was in V5.1. I want to make sure that I am testing the exact same thing you are when you get the ADC error. I was wandering if you had a more standardized test that people can do to check this. I was thinking you could have a test using the wave generator in the dso203 and A and B channels connected to it for the test then save the configure file and uploading it to this forum so we could download it, run it then upload a picture to the forum for you to see.
P.S having lots of fum with Version wildcat 5.1. Comparing it to full o-scopes at work. Much better features then the original software in the dso203. Thank for the hard work you have put into it.
Just realized Ionly have 2 max leads for the dso203. Can the test be done with only a channel and the wave generator?
Wildcat,
I noticed something similar, but erratic and not as pronounced. Hard to capture in a screen shot because the imperfections in the trace pattern move around and come and go. When I switch to the new blue buffer mode some more pronounced effects.
Didn’t try adjusting the room temperature.
This is with WC5.1 and custom FPGA V1.1, Hw 2.81.
Yes, you can do one channel at a time, and you can use the built-in generator. You don’t have to do anything special, just see if you are getting the type of noise that’s in the bottom screenshot, observing any waveform while in full speed buffer mode (press right toggle center button until bottom of screen area inside orange rectangular bar turns blue). If the noise is there you will see it. It may do it on one channel and not the other, and it may not be the same as mine.
It will be more obvious in slower timebases, say slower than 200uS/div. Cooling the device down to ~45 degrees F (5 degrees C) made it MUCH worse, heating it with a hair dryer to a bit above room temp made it go away.
Using the scope for a period of time while in full speed mode will certainly reveal it, if the problem is there.
Hopefully this was just a bad chip in my device and everyone else’s units are OK…
Yes, this looks like the noise, the key is that it occurs at the same vertical level on the wave trace. Try it in full speed mode with the same waveform/timebase.
Yes, at faster buffer mode (blue) shows more pronounced.
OK, well it looks like your device is responding exactly like mine was. The height is a bit different, but that’s likely because the ADC offset was adjusted to a different level on yours (looks like yours is set to around the default of 54).
I was hoping mine was an exception, but now with 2 out of 2 doing the exact same thing, looks more like this is “normal” for these ADC’s. I would like to get some more feedback to make sure ALL units behave in exactly the same way. During the course of troubleshooting this issue, I developed a few software “work arounds” that minimized the noise, at least at warm room temperatures (mine was EXTREMELY sensitive to temp, for example it was a bit pronounced when first turned on, but gradually got better as the circuitry warmed up from being powered up).
While the best solution would be to replace the ADC (which by the way also solved the premature clipping at the top of the screen, which was a problem with mine and apparently some others) I suspect not many have the resources or the willingness to do this. Since I no longer have a unit that exhibits this problem, I can now only guess as to what was causing this. Perhaps the increased gate load in the FPGA was causing noise on the supply lines that the ADC couldn’t cope with. The extreme sensitivity to temp has me baffled though. This usually indicates a defective chip, but with the complexity of modern processors, anything is possible.
The software “work arounds” included shifting the A channel to the B ADC when channel B wasn’t being used, this way totally eliminating the problem when only ch A or only ch B was used, as well as reducing the number of gates in the FPGA by cutting down as many functions as possible and simplifying things. Before I finally took mine apart to look into the matter, I came up with a APP/FPGA version that minimized the problem pretty well, if not eliminated it altogether. It did however have some issues with time based triggering, occasionally showing some instability with some wave types while in full speed mode. Solving this would have meant adding gates, which increased the parasitic noise, but the version was nonetheless quite useable, with the triggering instability very seldom occurring, only on rare occasions.
Will see if I can bring this older version up to date with the latest changes when I get some more free time.
Thanks for checking this out. Also thanks to anyone else in advance for verifying if their units behave in the same way.
Thank you for the explanation, today I noticed the orange cursor can move back and forth in the first quarter of the screen, however is there any hardware limitation for limiting this pre trigger to the first 150 samples?
Wildcat,
I just tried WC5.1 w/FPGA W1.1 on a different HW2.81 device. Results on this second unit in two buffer modes are attached. Didn’t try placing it the frig, just another room temperature test.
150 samples is a bit more than 1 division short of half way down the screen. There’s no hardware limitation. The default is set in the FPGA at 150 and it can be changed by the program, but the program continually resets the trigger and every time it does the FPGA resets the pre-trigger to 150. All of this can be changed. I always thought 150 samples of pre-trigger was enough but I suppose it could be useful to make it adjustable.
Thanks for checking this other one. It does not appear to have the problem, I would check it with a full scale waveform though just to be sure it doesn’t show up at the top or bottom. Doesn’t matter what voltage scale you’re on, it’s all the same to the ADC, it basically sees what you see on the screen.
Wildcat,
I was wondering which AD9288 spec from Analog Devices you replaced on your DSO. Was it another 40, or did you use a faster rated chip like the 80 or 100? Are they all 48 pin LQFP packaging.
Also, I found this photo of an old pcb board with 2MB flash from an eBay seller. The photo seems to indicate an option for AD9218 (10-bit A/D). Is the AD9218 pin compatible with the AD9288 and supported by the DSO’s firmware?
I used an 80MS/Sec chip for replacement. All speed versions are the same, just different grades. The 10 bit version is not compatible with the hardware, this is only advertising hype. They do make a pin compatible 10 bit version, but the extra bit ports would be unused if installed in the Quad.
The speed rating of the chip however I don’t believe is a factor in this since the parasitic noise was still there even with the sampling rate brought down to 2MS/Sec, thought somewhat less prominent. I chose a 80M for replacement simply because it’s proper engineering practice, but the 40M devices seem to work OK at 72M.
What I would be curious to know though, is the difference, if any, between the ADC versions used in the 2 devices you tested. The schematic for HW 2.81 specifies a HWD9288 from Chengdu Sino (CSMT), which is what I had in my device. Another, earlier HW V2.70 device I have might also have had one of these or possibly something from another source, can’t remember, while the early V2.60 versions have Analog Devices chips.
Single Channel A. Looks good to me. Let me know if this is the sample with the new dso203 with the new FPGA chip and the wildcat 5.1 and the new FPGA 1.1 you are looking for.
attachment=0]image.jpg[/attachment]
Thanks for checking this out. You should however engage the full speed oversampling mode (center press the right toggle until the orange zig-zag line at the bottom turns blue). Also, a larger portion of the screen should be covered, you can use the 0.2V/div range for example and adjust the waveform for close to full scale.
I have expanded the waveforms and attached screenshots for both devices, each in two buffer modes.
I ordered the AD-9288-80 from Digikey.com. When I find out, I’ll let you know what chip is installed, but I expect both units have the same chip you found. May be a couple weeks before I do the transplant surgery.
Interesting, some units don’t show the problem at all. Thanks again.