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.
Hdwe V2.81
DFU V3.45C
Sys V1.64
FPGA V2.81
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.
Merle
Hi,
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.
Thanks
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.
WC,
Thanks for the update. Hope you have luck programming the later FPGA.
Can’t seem to figure out what you mean by "shifting the ADC window down? I looked in the guide, but can’t find it. Are you saying to make the adjustment while doing the analog calibration?
If you hold button 2 for more than 3 seconds, as if to enter calibration, but with the menu NOT on ChA or ChB, you will get a screen where you can change a value (with the left toggle). This is 54 by default. Changing it to a smaller value changes the operating point of the ADC window, which is advantageous to set as high as possible (EG: with a setting of 54, the window is from 54 to 254 (200 steps of the display). This was done to get away from some non linearity at the bottom of the screen.
If clipping happens in the preamp at the top or close to it, you may see it. This varies from unit to unit and maybe even from range to range or with battery level. Changing the default setting of 54 to a lower value will bring the window down and can be used to move the visible clipping out of sight. It does not stop the clipping, just moves the window so you can’t see it.
Factory apps leave the window at the very lowest point, so you don’t see it, but it is still happening…
Move the window down so it just clears the clipping. Note that you have to exit the adjustment screen for the change to take effect. Finally, save the config so it stays that way.
This is explained in the user guide at the very beginning of the calibration section (2nd paragraph).
Just uploaded 4.5 and no issues. Went thru a calibration and could not accurately calibrate the 10V range as my supply would only run to 47.8V. Set it there since I will probably never use that range anyhow.
Kudos to Wildcat. Fantastic job , just wish I had the talent to understand and program at his level.
I having trouble in getting voltages calibrated with a good accuracy. I don’t know if it is a common fault or not.
I having some fluctuation in low/med voltage readings when I am calibrating in the last two digits. I sometimes get two readings blinking,looks like DAC is peaking voltage reference fluctuations. Normally I got two values (eg: 1.045v and 1.037v) I don’t know if I have to set by the higher or the lower value.
I am using the last wildcat 4.5 Fw and all the last fixes etc.
I don’t believe it’s my calibrating power supply or else I will get the same results in my 5 digit multimeter, it’s steady.
Use the one closest to what your supply is indicating, this is only a difference of 8mV and is likely the limit of the resolution of the ADC. As has been mentioned before, voltage resolution of an 8 bit ADC is low, with only 256 coarse steps compared to that of even a cheap DVM. This is a trade off you get between speed and accuracy. The resolution of the calibration display has been extended beyond what the device is capable of providing to minimize any errors there.
One thing you can do while calibrating, if your supply source is finely adjustable is to try to get on the center of each step as indicated by the “centering” display. Often, if this jumps around too much, moving up to the next or lower “step” or two can prove helpful. The exact voltage you chose for each range is not critical, just set the display to the closest value as indicated on your supply.
Just finishing up a revised FPGA, will be posting shortly along with a new app update. New FPGA will fix inconsistent triggering at the fastest timebases under some conditions, provide more coherent AUTO mode wave display while untriggered and allow the development of 144 Ms/sec sampling and other functions and refinements hopefully in a future update.
APP update will include fixed jitter stabilization not working at fastest timebases if either channel is in invert mode and a few other minor fixes and additions.
Thank you for your quick reply and your work is amazing specially the serial decode.
Maybe I not explain well my point, or I don’t understand well your answer.
Power supply -> [color=red]1.037v
I got two types of readings with blinking :
A [color=red]1.037v <-> 1.045v
B 1.030v <->[color=red] 1.037v
I will try to adjust the PSU to have steady values. It’s a bit tricky.