10,000 writes to the flash, wow. I am beginning to understand how many hours you have spent on the application, certainly more hours than was spent on the hardware design. It would be fairly straightforward for me to replace the ARM processor, I have the rework equipment to do it properly if that would be of any assistance. When I have seen a slowdown as you describe it it is right at the end of the durability limit as all the “spare” cells have been used up already and the next complete cell failure can be terminal. Interesting that the second half is still operating at normal speed, it must manage the space in large but separate blocks. I have had similar chips slow down by a factor of 50-100 times with overuse and sometimes when left powered off for a few years slowdowns have happened but in that case rewriting the flash has fixed the problem. I still remember trying to work out why an instant on device was taking 3 minutes to boot up, the concept of bit rot in EPROMS works a bit differently with flash.
I hope over time we will get to use the whole ROM if the DFU issues and hardware variations can be addressed somehow. It is a unique device with a lot more potential if there is room for the code. I did not realise 144MHz sampling was a possibility, even with a reworked FPGA.
Thanks for the detailed answers.
There is plenty of ROM available, but at some point that will mean 2 different versions to take account of the FPGA being at different places in the earlier and later devices. Earlier versions are at a bit of a disadvantage in that they are limited to a 500KB DFU drive. We can load binary data directly to get around that but not sure if this can be split to skip over the FPGA. Some experimentation will be needed. Later DFU’s with 2MB drives and HW 2.81 with the FPGA at the end of the ROM are clearly an advantage here…
144MHZ sampling has always been POTENTIALLY available, while keeping clocks at 72MHZ. This is done by feeding the same signal to both ADC inputs, then sending out of phase clocks to each channel. For example, chA samples a signal, then a half clock cycle later, chB samples the same signal, essensially providing 144MSPS (double data rate memory style).
A mode pin on the ADC needs to be set, the same signal fed to to both ADC inputs, the out of phase clocks need to be implemented and the program needs to combine both outputs together and set up special timebases for this to work. ALL of this has been implemented from the start and works just fine EXCEPT the out of phase clocks, which while there appears to be some code in the FPGA (which is where these clocks originate) to provide this, they nevertheless remain always in phase, so the second sample is simply a repeat of the first, rather than a sample a half clock later.
A mode control line to a pin (pin 1) on the FPGA to control clock phase seems to be ignored by the FPGA code, though there also is some control through software commands. None of this ever creates out of phase clocks though. I verified this both at the hardware level with an external scope at the clock pins themselves as well as implementing the necessary software and looking at the results. Interested to see if the new FPGA code fixes this, but the official word has been that it “just doesn’t work”, so not holding hopes too high. Results from the software tests however, clearly show 144 MS per second though, so seems it should work, and the ADC is designed to work in this mode. (see screenshots).
There MAY be an issue however with the 40MHZ rated ADC’s running at 72MHZ not working correctly in this mode, so maybe why the factory states it don’t work. One of my devices has a 100MHZ ADC version (replacement for a sub standard clone that came with it), could be used for testing. Unfortunately I have no way to modify the FPGA code (and also lack the proper compiler to modify the sys files).
144MS mode engaged, with chB disabled shows this is working. In both screenshots, interpolation, which would smooth the waveform has been disabled in order to better show sampling “steps”.
However when we add chB, it’s just a repeat of the previous ChA sample since both clocks are of the same phase and sample the same thing. All we need is simply an out of phase ChB clock, IF the overclocked ADC will work properly in this mode.
Well, I just installed the Wildcat V. 4.4, using windows 10 64 bit, I have DFU V.3.43C, SYS 1.64, HW version 2.81, App V 1.13…
And I had no problems
Thank you very much Wildcat!!
PS: I have to say it was a bit complicated starting to navigate among menus of this version, so different from the factory one. It is due to the fact Wildcat added so many features, so buttons have many functions. But it is really a fantastic version, once you understand how to navigate…it becomes another product, really powerful!! By the way no problems with windows 10 both with disk and DFU.
Thank you very much again Wildcat!!!
PLEASE NOTE that initial calibration (holding button 2 down while menu is on ChA or ChB) in Wildcat V4.4 MUST
be done while in normal buffer mode (single window or full buffer ) and NOT in one of the oversampling/summing
modes. This will be fixed in any future updates, but with version 4.4 attempting calibration while in OS modes
will fail. Note that there is no need to recalibrate if already calibrated with a previous version.
Hi, a follow up on DFU 3.45c
I was able following the the tutorial to update my HW 2.81 unit from DFU 3.40C to 3.45C.
This was complicated by the example of the recommended USB Serial module I purchased being faulty with a wandering serial clock causing writes to fail after 40 to 60kB.
Changing from DFU 3.40C to DFU 3.45C does not alter the issue of Win XP or Win 7 working reliably and Win 8, 8.1 and 10 being problematic on larger files like Wildcat 4.4 although this is also hardware dependent. Based on the reports of others some USB hardware seems to work reliably with Windows 8.1 or Windows 10 and other hardware (every computer I own) does not allow me to transfer larger files reliably except with Windows 7 and Windows XP. This does not seem to be related to the DFU version in use which looks to have been a red herring. I could not find any other issues with the hardware I have available specific to DFU 3.45C that were not present on 3.40C. OS X can see the DFU volume with DFU 3.45C but will not reliably transfer files. If you are taking apart your aluminium DSO Quad don’t lose the power switch cover like I did and spend half a day searching for it.
…would it be possible to generate a 3-slot version loading into slot 2 that’s still compatible with PAWN? For some reason I want to keep original app in slot 1 (I use the fourpack version PLUS A1 1.10 which completely fits into first slot), W4.4 in slot 2 and PAWN in slot 4 (HW 2.70, 2MB version, Sys 1.52, DFU v3.11C). Current 3-slot version works perfectly in slot 2 but overwrites PAWN on install…
You probably need to explain why you want to keep the original app in slot 1. It is in my view rubbish and the main reason people regard this device as a sad toy. I am struggling to think of any function the original app does as well as Wildcat 4.4 let alone better. The time taken to code for a request like this needs a better justification than “for some reason” and just in case or I kind of like are probably not valid either. If there is a worthwhile reason for having the original craplication available I am curious, otherwise there are a lot better uses for the space it would occupy. It is simpler to use because it does a lot less and badly but if that is a valid justification we should all keep Windows 3.1 on our boot selector just in case we hanker for the uncomplicated past.
@Roger: this was just a question. I don’t think I need to justify this, but in fact I do not always need the high precision of Wildcat’s version and in such cases prefer the more intuitive interface of the factory app. I’ve also been thinking about altering the factory app because I like the interface.
btw. currently I use W3.4 in slot 2 on my DSO203 which resides peacefully next to PAWN, but want W4.4 because of the new oversampling modes which greatly improve precision. The “Wildcat series” firmwares IMHO currently are in fact the best thing that could happen to the DSO203. Because I am not an experienced programmer, I cannot tell how difficult a relocation would be.
You are talking about a custom version of the package which would require ongoing effort to maintain in subsequent versions and would only work on the 8GB hardware. It would take development and testing time equivalent to multiple sets of hardware in value and complicate ongoing support. It could be done for sure but you could have a second DSO with an “intuitive” factory interface that does a lot less and less accurately for much less effort than it would take to code and support a custom version of 4.4 for you. I am not trying to offend you but intuitive is tough for something as complex as version 4.4 limited to the switches available.
In other projects like this having two different user interfaces increases the confusion and leads to unfair criticism of the more complex UI. Based on my experience if I just use the wildcat 4.4 UI after a while it becomes more intuitive and easier to navigate. Oscilloscope user interfaces have been an issue for decades with HP’s digital models being designed like a piano with one key and a pitch control knob and affecting sales for almost a decade where people familiar with a knob for time and a knob for volts despised the new interface. (Which was a terrible design in my my view).
I would suggest try avoiding the factory app and immersing yourself in 4.4 for a while and it may well become more intuitive to use for you. If you want to see how far we have come have a look at the Apollo onboard computer user interface. It took literally months for it to become intuitive and printed instructions were normal for in flight use. The early shuttle interface was not a lot better. I have many different digital oscilloscopes with everything from touch screen to knob based designs. As the number of features increase all require use of the manual to work out how to do some things. The DSO is using a media player control set to run a complex oscilloscope so there is certainly a lot of compromise involved in the user interface but for a free product that turns it into a useable capable device I think it works really well.
Did I really miss the point so much? As far as I understood, compatibility with PAWN is a basic feature of the 4 slot version which is in fact a 5 slot version, at least to my understanding of Wildcat’s explanations in this thread. Would it really be such hard work to also feature this in the 3 slot version for slot 2 which is included in the W4.4 archive anyway? (I don’t need the high performance W4.4, as I mainly use the DSO203 to track down problems with model flight hardware)
This point is clear to me, undoubtedly making a complex thing intuitive is quite a challenge. I am not so much into oscilloscopes (DSO203 is my first and currently only one), but I am part of the linux world since 1993, there it’s quite the same. First linux versions were nearly unusable for standard folks, this has changed later.
This would be an option. Another option (about which I currently don’t know if it is an option at all) would be to enhance the UI in a way that some functions are not included by default, but provided as a plugin stored in binary form on the DSO’s “internal USB drive”. Would be a great thing, as codebase would decrease and the present issues with flashing to different hardware probably wouldn’t exist anymore. I am thinking about learning myself to program DSO203 in order to include some of Wildcat’s enhancements into the newer GUI. I’ve already played with the PAWN toolchain (that’s why I want to keep PAWN), but that’s really not the same as programming in C.
Did I get you right - you have been programming UIs for Apollo? I am not familiar to space flight, but that would really have been a great task…
Most of the Apollo coding was done at MIT in the 60s and I was still in short pants. I worked in the 80s on some of that technology and found it really interesting how so much was done in so little code. If you are interested I can post some links.
@roger: although slightly off-topic in this thread: sounds interesting, feel free to provide me those Apollo programming inks you wrote about.
Some comments on my experience with the latest upgrades. I have hdwe V2.81 and upgraded the DFU to V3.45C and Sys to 1.64.
The upgrade solved all my Win8.1 issues interfacing with the Quad. I can load Wildcat V4.4 (424KB) with no issues at all.
Win 10 is another story. Disk access in normal startup mode works OK, DFU mode is not recognized at all.
I am having problems, with version 4.4
I’m not sure if the problem was here before but I get a constant DC offset even after doing a calibration (I did the full calibration, DC offset correction and voltages from a calibrated power supply - I didn’t change the CPU frequency calibration).
With the input shorted to GND, on 50mV/div scale, I read a 50mV offset.
Is there anything that can be done ? Maybe the hardware is faultly, or there is a limit as to the offset the calibration can correct ?
I have attached a screenshot showing the offset. During the acquisition, Ch A was shorted to GND.
Interestingly the offset changes depending of the input range setting :
50mV : offset 50mV
0.1V : offset 84mV
0.2V : offset 0.152V
0.5V : offset 0.360V
1V : offset 0.400V
2V : offset 1.12V
5V : offset 3.40V
10V : offset 6.80V
I have attached my WPT file - the forum does not allow WPT files (wtf seriously this is annoying) so I changed the extension to ZIP. Please rename it to WPT. It is not a ZIP file - just rename it to WPT.
Not shure but
I found the analog calibration somewhat time consuming, but I would suggest you retry the analog calibration after loading Wildcat version 4.3 or earlier.
If this corrects your problem, the resultant WPT file can be archived and used with Wildcat 4.4.
The screenshot shows the device is in one of the OS modes (green buffer display with orange box outline at bottom of screen, this is the so called averaging or summing mode but is still oversampling).
As previously noted, performing the initial calibration while in OS mode will fail, with resulting large DC offsets and perhaps even a program lockup.
There is no need to calibrate with another version, simply shift over to a regular buffer mode (orange buffer display with white box outline) before entering calibration.
If the device was previously calibrated with an earlier version and a config file has been saved in one of the extra positions (appears as a CONF00x.CFG file on the drive) and that file was not overwritten by saving to that position after an improper calibration, it can be copied/renamed and saved, overwriting the xxxx.WPT bootup file and the previous calibration data will be retrieved. The program does not read calibration data when loading an extra config file, it only loads it from the bootup file #0 (WPT), but it does save the data to them, so they can be used as backups. This can possibly save some time and frustration.
A xxxx.BAK file is also generated from the previous WPT file when a new one is saved. If incorrect data has only been saved once this can also be used.
Was waiting for a future update to fix this. Looking to add more functions as well as update existing ones, specifically relating to triggering (adding the ability to trigger on configurable binary sequences and perhaps also data sequences in SPI and i2C decode modes). This would require reprogramming the FPGA, and while I now have the necessary software to do this, it only works with the new chips in HW V2.81, meaning these added functions would not work on earlier devices unless someone with a licensed older version (which appears to no longer be available) can generate a bitmap from the source if/when developed . Don’t have one of the new Quads with HW 2.81 at the moment, but plan to purchase one shortly.
Also having some serious health issues, so it may be a while before a new update. When I get a chance might post a minor revision with a fix for this calibration issue for anyone concerned. This will simply amount to calibration switching over to a non oversampling mode when engaged. For the time being, doing this manually will work just as well.
Just acquired a HW V2.81 Quad with the latest DFU.
A few things I noted:
The “swapped Ch B least significant bits” issue of the earlier FPGA versions has been fixed. Since the program compensated for this in the earlier devices, this now has the effect of CREATING the problem on V2.81. This just amounts to some excessive noise on CH B, but likely will also affect initial calibration somewhat. The next update will detect the device version to fix this.
Also I noted in my sample that the preamp clips below the top limit of the ADC producing visible clipping at the top of the display. This can easily be fixed by shifting the ADC “window” down, see the user guide for how to do this.
Will be posting a new update shortly, waiting to finish a few added/updated functions. This will also include removing the requirement to have config files present before being able to same them on devices with 8MB drives as well as a fix for the “calibration with OS modes” issue.
Some of the new functions I’m working on include extending the chart mode time base up to 100mS/sec, auto saving of incrementing BUF and CSV files at end of each buffer while in chart mode and the ability to create a binary file image of the entire ROM so a device can be restored to it’s original state via the internal JTAG header if ever necessary (a utility to do this was previously posted by bobtidey and jpa but will only work for devices with 2MB drives).
Good news! Thank you!
Version 4.5: fixes some issues with 8MB drives and HW 2.81, adds/updates a few functions and the user guide has also been updated. I now have the means to program the new FPGA chip so will be looking to see what can be done with that. Unfortunately, still have no way to program the earlier FPGA version.
CHANGELOG TO VERSION W4.5:
-Added version detection to properly implement the “2 least significant ChB swapped bit issue” of earlier FPGA versions.
Fixes problem of excessive noise and possible initial calibration accuracy on ChB waveforms with hardware 2.81.
-Fixed initial calibration failing if device is in oversampling mode.
-Added overwrite file warnings when saving BMP, CSV and BUF file formats.
-BMP and BUF load functions now auto increment file numbers.
-BMP load can now display next file with just one push of center button 5.
-Fixed 16 color BMP load not covering entire screen on 8MB drive devices.
-Added function to save entire ROM to an image file to restore a disabled device to it’s original state via JTAG header if ever necessary.
-Extended Chart mode time base up to 100mS/div.
-Added option to auto save incrementing BUF or CSV files at end of each acquired buffer in full buffer chart mode. Provides continuous recording of long periods of data.
-Disabled TH, TL, %duty and period time meters while in chart mode.
-Fixed T cursor delta time display while in chart mode, now works up to 1000 seconds.