Here is the video: https://www.youtube.com/watch?v=Y0BOBghLsGk
It was taking too long to upload, and it was very late so i went to sleep.
Yes i renamed the file you uploaded and tried it out, it’s the same file and of course it gives the same error. Look up the video if you don’t believe me.
And note that the same exact thing happens with both DFU 3.40C + 3.45C, SYS 1.62 + 1.64, WIN 7/8/8.1/10 while as you see other versions work perfectly fine in any of the combinations above. So it’s plain simple to see that the problem resides on your development in this case as we cannot do something to MINIDSO developers to make you a custom DFU if that’s the problem. However if you need me to ask anything about the addresses etc for hw 2.81 on the minidso forum please let me know.
I’ve watched your video, and the results you are getting with the files not loading are
exactly the same I get if I try to load the files directly from the archive without copying
them first to another directory. I am NOT saying you are not copying the files, just that
the RESULTS you are getting are the SAME.
Well, you see, here are the problems I’m faced with:
- You are describing a problem (inability of a properly extracted hex file to load
using Windows 7) that NOBODY ELSE SEEMS TO HAVE.
- For the moment, I could care less about Win 8 or 10. If the latest/greatest from
Microsoft can’t handle copying a simple file to a virtual FAT12 directory, that’s
not MY problem. I have no intentions of obtaining a Win 8 or 10 machine to
test/fix this. Windows 8 has be extensively documented on this forum as having
issues with ALL prior versions as well.
-
The ONLY thing in the way of "my development" or "way I write the program"<br/> as you describe it as contributing to "my failure to fix YOUR problem" that I can<br/> change, is WHERE I put the code in the ROM. Nothing else in the content makes<br/> any difference. We are talking about LOADING the programs here, not running<br/> it. <br/>
4) The ONE THING in common with all the versions you have problems with is
that they are over a certain size. (Do not confuse this with the problem with the
2 first files in Test.zip that went a bit too far in ROM and caused an .ERR file
flag.) This clearly indicates a problem with the loading process, which only the
DFU and the host OS has any control over. Nothing in the content can alter this.
If there was a problem with WHERE the code is put in ROM, which, again is
the ONLY THING I CAN ALTER that makes any difference with all this,
it would not load on ANYONE'S machine.
5) You seem to have some sort of attitude where you are unwilling to acknowledge
any possibility that you may have made a mistake, or overlooked something,
instead of carefully reviewing your actions with the help of others, while at the
same time blatantly blaming someone else for your problem, even in light of
the fact that others are not able to duplicate the issue.
I'm sorry, but I just don't get along with people like that. My health is suffering
right now from the frustration of dealing with this and I don't want to wind up
in the hospital. I will gladly respond to anyone else, but as of now, your posts
will no longer show on my PC. Again, I'm very sorry...
Wildcat Hi. If it is any assistance, when I get the serial adapter I have ordered I will try installing DFU 3.45 and see if it causes loading issues for me. I am absolutely certain the 4.4 code is fine and the problems TnF is seeing are a result of the interaction between Windows and the DFU. The only reason this is of interest to me is if it turns out to be related to DFU 3.45 and if this is the latest shipping version we could let people know what the potential workarounds are.
One thing I was going to ask is, given the copying failure is almost certainly related to the size of the file, is it possible to split the loading into pieces to bring the size of each individual loading session down (APP1, APP2, APP3 etc.). I have no idea if this is possible or practical but thought you might know.
Thanks again for your time, I am really enjoying using the DSO now as it is working much better than I ever anticipated. I have many other high end oscilloscopes and DSOs but this has become my favourite. It was a near useless toy with the stock firmware but is a really practical tool with Wildcat 4.4 loaded. The only thing I miss from larger DSOs is an auto setup feature but that is relatively minor compared to the utility of being able to put it in my pocket and the fact it cost less than a single 10:1 probe for my Tektronix or HP oscilloscopes.
It is not worth stressing too much over these issues, the quality of the firmware and FPGA code the Mini DSO is delivered with is not great and it is a miracle to me you have been able to work around this with 4.4 so effectively. When Windows is added to the picture glitches are inevitable. I think the maxim is ‘If it has Tits, Tires or a Microsoft Sticker there’s gonna be problems’.
- LOL…calm down a bit man. You are far taking things too seriously. Wasn’t i the one offered to help in any way i could? If you have health problems you should be aiming to get well first either way. Don’t get me wrong but from where i’m coming from even the smallest issue is something to be taking care of. It’s not about pride or blaiming someone, so i apologize if it came through with that meaning but the end goal is just improvement.
- Yes that’s the weird thing. Even though we didn’t had more people do some extra tests to compare. Also the 2nd weird thing is that on HW 2.81, SYS 1.62, DFU 3.40C, other people were able to access the DFU drive regularly on win 8/8.1/10 while on my device before updating the DFU i only managed to do it once…
- Couldn’t care less too until i upgraded…plus DFU 3.45C fixes this so i’m not sure why it keeps bothering you…
- Yes that’s why i asked if i can get you memory mappings for HW 2.81…
- See 3)
I remember you.
You also almost banned on kazus.ru forum (with the nickname st0rm53) where you ask about chipp fw. http://kazus.ru/forums/showthread.php?t=100175&page=54
I think that no one do not owe anything to you here.
Pardon for my French.
Yes that was me. I posted a genuine question regarding CHIP’s fw…also asked about wildcat’s back then and made a joke since someone didn’t know what is “a wildcat” while failing to check the link i gave (which was removed by a mod, not my fault)…never came close to getting banned. It seems some people fail to read the whole story and start popping out like smucks…but who i am to judge, right? 
Ok. Also, I can well afford to purchase yet another one, and have been thinking about it but would like to be sure of getting this latest version. Several reasons for this, there are some residual flaws in the hardware that cause instability in the triggering under some conditions at the fastest timebases. Strangely this is observed with some devices and not others, on one channel and not the other, and at some triggering levels and not others, etc. Was wondering if the different FPGA chip and/or board layout used in these new devices has changed any of this, and also if the new FPGA code provides proper control of the ADC clocks to allow a 144M sample rate, or at least an attempt to make 144MS work, unknown at this point how well this could work, specially considering the 40MHz chip is overclocked at 72MHz.
Interesting idea, not sure if the DFU would let me do this, would have to try it to see if it’s possible. At this point, I’ve about worn out the flash on the devices I have, since I do debugging on the devices themselves, so I’m reluctant to engage in too much more. One device is showing slowed performance if code is loaded in the first 4 slots. Mapping the whole program to the entire second half of the ROM restores normal performance. I suspect that device has been flashed close to if not in excess of the 10,000 “durability limit”. One more reason to get another one…
It should be noted that we have been loading large programs for some time. I have loaded HEX files close to 500KB with
no problems whatsoever. Gabonator’s program is 460KB in size and has been used successfully on earlier (pre V2.81)
devices. The only reason it fails with 2.81 is because it overwrites it’s FPGA. It could be re-mapped and I suspect would
work just fine. The original authors have expanded the DFU from 500KB to 2MB in these new versions, clearly they expected to load larger programs. Theoretically, the ROM provides about 375KB of program space, which translates to an over 1MB HEX file. Unfortunately, not all HW versions have this in the same place…
Thought about including an auto setup, personally don’t care for this myself, even with DMM’s, so have focused on other
functions instead. May well include this in the future as there is still room left in the memories to expand the program.
Wildcat hi.
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!!
Enrico
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.
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