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.
Hello Wildcat. I did some testing for the improvement of the software, I don’t seem to get the problems in full buffer mode:
The ambient temp is about 20oC. I haven’t done testing in lower temps.
Also in the manual you could add:
- Save IMG in the File Functions list
- Add colours (example blue in full buffer mode) in BUFFER SIZE, AVERAGING AND OVERSAMPLING MODES and RIGHT TOGGLE CENTER PRESS: - SHORT PRESS:
Also i’m not sure if you’ve seen one of my previous posts, the problem i had with installing your hex files from v4.x and upwards seems to be a hardware “support issue”/incompatibility with the usb controller on my specific laptop (HM55 chipset). It is not an OS problem afterall, it seems to disconnect on large hex files. On other PC’s i tested it and it is fine. I apologize for bashing you in the past, but i don’t think you can do something about it, the only software way it seems with minidso fixing it on the DFU firmware.
No problem. Just glad you got things worked out.
Thanks for posting these results, nice to see more of these units operating properly.
I agree with the user guide. Things were added in a bit of a hurry, every time I add some items, the whole guide has to be re-paged and indexed. Once I feel the program is in a reasonable state of completion I would like to update the entire guide, perhaps with more screenshots demonstrating various functions. Pretty busy right now though, will be a while before I have some free time…
Hello all. I admire the Wildcat and others for great job. The little DSO now turn into very powerful tool.
My question - can you explain step by step how to adjust the horizontal thickness? I read the guide and tried many combinations - no success. The only think that show up is ADCoffset.