Good job for Wildcat 5.0!
I’ve just tried it, very nice!
I like especially shortcuts
Thanks
how many slots need Wildcat 5.0?
can I install Wildcat 5 and Gabonator ? because I try Wildcat5 in slot1 and Gabonator in slot3 but seen corrupted
¿?
…on other hand need master code for HW2.72 and licence 9420c38f, by unknown reason I can’t post and ask in <LINK_TEXT text=“http://www.minidso.com/forum.php?mod=fo … lay&fid=54”>http://www.minidso.com/forum.php?mod=forumdisplay&fid=54</LINK_TEXT>
if anybody can give me the code I will be grateful
not sure if corrupted is because lack this code. each time power on ds0203 ask me the code. and power on oscilloscope after press some buttons
Version 5.0 needs the first 3 slots, so any additional programs will need to be loaded in slot 4, but
it also uses memory in the second half of the ROM area, which Gabonator’s program also uses, so
they are not compatible.
Wildcat 4.4, downloadable from page 41 has a special “3 slot” version that is compatible with Gabonator’s program
that uses only the first 3 slots and nothing in the second half. Gabonator will have to be loaded in
slot 4.
Not sure why you need to input your license code, loading both programs on a version 2.72 HW device
should not have affected the DFU.
Note that Gabonator’s program has not as far as I know been updated to work on the later hardware versions.
Not sure where compatibility ends, but it will overwrite the FPGA on HW 2.81.
Thanks for your response. I need Gabonator because have some extra interesting programs as spectrum analyser, logic analyser and response frecuency . Have wildcat similar ?
Would be grateful if you explain better the use of ROM in dso203 ?
Yes, of course. License code don’t have any effect on wildcat or garbonator but my dso203 bricked time ago. I repair it and now ask me the code each time I power on ( real HW2.72 and licence 9420c38f)
Hi Wildcat,
on this place, I want say to you: Thanks a lot for your work over all the time and different HW Versions 
I don’t tell you unknown thinks, if I say, that other FW Versions are not so good supported as your once.
I’m owner of a DS203 HW2.81 for a very small time. After some experince how to walk through the menu’s (and I have not reached 100% of them till now ) I can say :
Good and nice work! Thank you!
There was no problem to change the SW to your Version and I’m happy to use the small nice tool, because it’s very fast beside me and in the most of the cases the measurement from the DS is enough. The Fluke need more time to get it out from the Store-Place, prepare all things, need more place on the table …
Just to let everyone know, even with DFU 3.45C some programs like Wildcat 4.1-4.4 (i haven't tested any newer yet) will FAIL to install on certain machines, even if you use windows xp. I had problems for many months, and the solution was to use a different PC. My laptop uses HM55 chipset don't know why there is incompatibility. Many thanks again to Wildcat for developing awesome software :)
Edit: Just tried WC5, i installed the FPGA under windows 10 and the problematic machine without any issues, again the hex had to be done from the other much older machine running winxp (although it is not an OS problem)
I am new to this device. Need a little assistance in installing Wildcat V5.0 on new DSO Quad. HV2.81 DSO SYS Ver 1.64
ReadMe in Wildcat V5.0 download /FPGA said:
Install by first copying the FPGA_281.ADR file to DFU virtual disk.
When volume reappears, copy 281_FPGA.BIN to DFU virtual disk. -------- Install these first?
What other files to copy to DFU virtual disk for firmware? With 2 files for FPGA?
Thank You in advance for the help. 
You will want to also install app1.hex. But first, after copying the 2 FPGA files, disconnect the device and shut it down, then boot up the DFU again, reconnect, then copy app1.hex.
If doesn’t really matter which you install first, but the 2 FPGA files must be installed together, without rebooting between them. The first (ADR) tells the DFU where to install the FPGA code, so it must be loaded first. Addressing for the HEX file is built-in, so it does not need an ADR file.
Just finished another program/FPGA update for HW V2.81, however, in the course of development, I ran into an issue with the hardware and I need help to find out how prevalent this is. The update adds a “full speed” buffer mode which samples at 72Ms/sec for all timebases.
The issue I ran into was parasitic bit toggling on ch A when using the updated FPGA (see bottom screenshot). Ch B was not affected. The problem was finally isolated to the ADC chip: Heating the IC would make this disappear, while cooling it made it worse. It should be noted though that when switching back and used with the previous FPGA versions, the noise was not seen. Apparently the added functions in the updated FPGA somehow seemed to be causing this.
However, after replacing the ADC IC with an Analog Devices unit the problem completely disappeared, showing no traces of the noise whatsoever when used with the new FPGA.
Hopefully this was an isolated problem with my particular device, and not common with the ADC’s that come with the later V2.81 units. Again, my device showed no signs of this until using the new FPGA update, and when changing back to earlier FPGA versions everything worked as it did before, while replacing the chip totally eliminated the problem.
So until I can get some feedback from other users on this I would have to consider it as a “test” version to establish the viability of posting any future FPGA updates.
WITH THIS IN MIND:
When used on HW 2.81 with accompanying revised FPGA V1.1:
Added full speed oversampling buffer mode: Will sample at full 72Ms/sec at all times, providing ~10MHz bandwidth without aliasing for all timebases, except at very slowest (50Ms/div and longer) where the rate is gradually reduced to maintain a maximum of 60,000 x OS ratio. Combines features of both digital and analog scopes. Cycle with right toggle center button: Single window > Averaging > 8x OS > Full speed sampling > Large buffer. Buffer notification will turn blue to indicate mode. Sampling speed for this mode can be changed from default of 72Ms/sec in steps down to 2Ms/sec if desired by holding button 2 for more than 3 sec while menu is on Time/Div adjust item while in full speed mode. Change with left toggle and save with boot config 0. Additional info is included in user’s guide.
By it’s very nature, this mode will capture and display any noise, no matter how intermittent, whether it’s generated from within the scope or from an outside source. For example, an intermittent ground strap between the display frame and gen out jack was also causing accumulated noise.
Once the ADC was replaced and the ground repaired, this worked quite well, increasing the sensitivity of the instrument in a very useful way. For example, when used at timebases of around 1mS/div and slower, where the display can keep up with incoming data, the mode provides continuous ~10MHz bandwidth sampling without any “dead time” or aliasing, with the ability to capture any signal or noise pulse, no matter how narrow or intermittent.
Other fixes with this update: (effective when used on all HW device versions)
-Fixed analog channels offset from each other, visible at highest 0.1uS/div when used with certain ADC’s found in later devices (shows as a 4-5 pixel offset due to interpolation). This was present with all versions from 3.3 and later due to the removal of interlace mode reset; for some reason all SYS versions set interlace on boot-up. ADC’s used on earlier devices do not seem to be affected, so this went on unnoticed.
-Added horizontal trace thickness adj: with menu on backlight adj, press RIGHT toggle (button 6) to toggle thickness adjustment menu, change with left toggle (2 steps with full speed OS, 3 with all others). Note that “vertical bright adjust” (see user guide for more info) can also be toggled in this way while in backlight menu with LEFT toggle center button. Save settings in boot menu 0. Display changes with these as well as the ADC offset adj can now be observed while changing.
-Added frequency display as alternative to delta time for Time cursors. Highlight T cursor display as sub menu item (T1 > T2 > Display), toggle between time or corresponding frequency with left toggle.
-Fixed UART generator function at times transmitting random buffer contents if trying to load a non existing file, also fixed file save function number display prematurely increasing value if file already exists.
-Trigger delay function is now disabled in oversampling modes.
-User guide has been updated.
50 nS overshoot pulses captured on a 10Hz square wave without aliasing in full speed buffer mode. On right the same pulse is expanded to 0.1uS/div.
Trace can now be adjusted for horizontal thickness.
Parasitic bit toggling in the ADC while in full speed OS mode on ch A. Ch B not affected. After replacing the IC, everything worked properly…
Hi WildCat, congratulations for your good work, I use it everyday and I find it very useful,
however I can’t find the pre-trigger function, in other words it seems not possible to move in time the trigger point.
It would be very useful to have it because I’m triggering a signal and I want to see what happens before it in SINGLE mode.
Do you have in mind to implement such a function?
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.