Thanks for the feedback. I have used the chart mode extensively, but always at the faster timebases, so never noticed these issues. Checking all possible combinations of the different functions on this program is rather time consuming, I rely on feedback from users to pick up on what I may have missed.
Did a fair amount of checking over the software and running tests on this, it appears that the ADC simply doesn’t work reliably when clocked at speeds of less than 1Hz or so. (clock rate at the 10Min/div TB is 1/20Hz). This is not too surprising, given that the minimum recommended signal to noise based conversion speed rating of the ADC is 1Mhz! Nonetheless, all ADC versions seem to work well at 30Hz (1Sec/div). I suspect the limitation here is in the sample/track and hold front end in the ADC chip, which under these conditions is asked to hold much longer than it was designed.
The “glitches” in your first screenshot may also have been caused by this. I have a different version ADC in mine, which could explain the somewhat different results.
The way to fix this is to oversample the chart mode (presently the regular OS functions are disabled in this mode). The hardware is already setup for this in V2.81 when used with the FPGA that comes with 5.1/6.0 so it should be possible to get around the problem by raising the clock speed this way. This would also improve on signal acquisition, since many more samples would be taken. Averaging and peak holding could also then be selectable , as in the regular timebases.
Unfortunately, for devices prior to HW 2.81, the factory FPGA that comes with these doesn’t support oversampling, and since the FPGA chips in those are from a different manufacturer (now out of business) I cannot reprogram them. The range on these older devices may have to be restricted to speeds that work reliably.
EDIT: hardware (FPGA) OS functions have proven not well suited for slow chart speeds, so a software function was developed instead. This will also be included in 5.x versions for older devices.
Will be working on this as time permits, and post an update once a fix is implemented.
I have no way of verifying operation on devices other than up to 2.81, neither can I find any info on HW 2.82
Some suggestions:
-Older versions of Windows (XP, 7) seem to be more reliable for upgrading. What is the DFU version ? (shows on screen when updating). Later versions of Windows are fussy as to which version the DFU is. Also it’s been reported that turning on the device before plugging in the USB is more reliable on later Win versions.
-A directory on your PC screen shows both app1 and FPGA being updated. I have always updated the APP and FPGA separately, shutting off the device and re-connecting the USB in between. It appears that you updated BOTH APP and FPGA at the same time. I don’t know if there is a problem in doing this, I have just never tried it. You may want to try just uploading the APP hex file, then disconnecting and then starting over again and upload the ADR file, wait for the volume to reappear then copying the FPGA BIN file.
-Use Wildcat version 6.0 rather than 5.0 or 5.1, there have been some issues with versions 5 when used on HW2.81.
Thank you very much, Wildcat. I will wait for update.
Thank you very much WC.
Your advice was right.
I went to my neighbour, who has a computer running windows 10.
I uploaded FPGA_281.ADR, 281_FPGA.BIN and app1.hex from WC6.0.
5 minutes and the problem was solved.
Bye
Dida
I realize you have HW2.82, but it looks like your problem was initiated using Windows File Explorer in Win XP to install WC FPGA1.1. Is this correct?
I had just the opposite experience with HW2.81. My SYS was corrupted by using Window 10 to install WC’s FPGA1.0.bin in DFU mode (DFU 3.45C), then restored using Windows XP.
DSO:
Hardware 2.82
SYS: 1.64
DFU: V3.46C
FPGA: V1.1 (File: 281_FPGA.BIN)
Host OS:
Windows XP Professional
Version 2002
Service Pack 3
copy by windows file exploerer
=> runs on VirtualBox 4.3.36 Ubuntu 14.04 64bit
Before I got trouble with “fpga configuration error”, I had tried to upload firmware wc4.4, 5.1 and 6.0. Uploading app1.hex always resulted in app1.err. Therefore I tried the stuff with a new FPGA upload.
BUT!!
I have an additional DSO 203 which had smoked on short circuit against mass. :x
That DSO was HW 2.81. Ugrading to WC4.4 simply had needed to copy app1.hex. I had used the same XP machine.
There had been no problem. First try for success. 
Dear dida.poli
I just get my new DSO203 version 2.82
Would you please give me step by step guide how to flash last realize of WC firmware (6.0)?
Thank you!
Dear dida.poli
I just get my new DSO203 version 2.82
Would you please give me step by step guide how to flash last realize of WC firmware (WC 6.0)?
Thank you!
Dear WILDCAT
I have DSO203 and I need functionality from it… Like FFT…
Would you please give me advise which firmware fit for it and step by step guide for FIRMWARE update?
my mail is: muslimens(at)gmail(dot)com
Thank you!
@muslimens
Worked for me with “Windows 10” but not with Windows XP
[list]
Hello dida!
Thanks for reply!
- You told me " copy app1.hex " - just only 1 file from that big folder… that is enough ?
- And what happens if I saw " app1.err " - my device became bricked? Could I restore it in such case?
Thanks again!
- Yes. The rest is for advanced use. (to program additional features to WC e.g.)
2.) estimate:
[list]
Dear folks,
just wanted to report a minor bug I came across in wc3.4 and wc5.1 (just updated to 5.1 - fantastic work wildcat!!!).
My setup:
HW 2.70 with DFU 3.11C, sys 1.52, alterbios 0.4 (stock except alterbios)
Minor bug I just found:
When in “A&B” trigger mode, signal sometimes freezes (Ch.B) or zeroes (Ch.A). Solution is: leave “A&B” trigger mode and enter it again.
How to reproduce:
- input signal, e.g. wave out (easy to reproduce this way)
- cut input signal (for testing: set wave out to “OFF”) and reactivate again
after a few tries (in quite some cases after first try) channel A shows flat line / channel B freezes display
Leave “A&B” trigger mode and enter it again: everything is fine again.
Just wanted to report this, but is not a big problem.
Cheers
Thomas
I’m afraid I have not been able to duplicate this, tried various timebases, trigger types, etc. Might help if you describe in detail exact settings used such as timebase, trigger types, trigger levels (try auto trigger), any other functions active at the time such as trigger delay, decode modes, etc, as well as which channel you are turning the source signal on/off. Does this only happen when you FIRST engage A&B mode? After you re-engage can you still reproduce the issue by shutting off the source?
One possibility with V5.1 behaving like this could be memory allocation issues like the one when this version was loaded on HW 2.81. When loaded on earlier devices, for some reason the problems did not seem to exist, but it was not clear to me at the time why this was so. Odd triggering issues like this were typical with V5.1 loaded on HW 2.81. After working on the upcoming update (V5.2/V6.1) the same memory issues started creeping up on early devices. These have now been resolved, am in the process of finishing a chart mode update, and will be posting this shortly. If I don’t find anything else in the meantime, I would suggest trying the next update to see if it fixes the problem.
V3.4 however did not have any memory allocation issues, so if this existed in that version, would point to something else, also tried another older device with the original V5.1 loaded and still could not duplicate this. Finally, you could try resetting the configuration by removing the WPT file (save it so you can return it to the device afterwards), corrupted config files can sometimes cause strange behavior.
Dear Wildcat,
thanks for your quick reply. After reading your words, I suspect that I might have a hardware problem. After investigating a bit further, I was able to break it down to the use of “NORML” trigger mode, as I usually leave it to “AUTO” and it gets switched to “NORML” in A&B mode, just as stated in your manual.
Attached my used config file and four screenshots, where I used “NOISE” as signal input (in real life I came across this while measuring PWM signals). It has been the same in wc3.4 and wc5.1 (factory app doesn’t support A&B mode, so I cannot test with that). In all screenshots the signal generator was connected to both channels. “NOISE” I only used because it’s directly next to “OFF”, the problem persists with any signal form.
When switching from TR D (rising edge) to A&B, channel A is dead most times (nearly always)
When switching from TR A (rising edge) to A&B, channel B is dead (sometimes)
When cutting input signal while in A&B (rising edge) and activating signal again, both channels are dead (most times)
Seldomly I am able to display both signals in A&B mode, but sometimes this is the case (see IMAG007.bmp, but it took about 10 tries to achieve this).
In AUTO mode, there’s absolutely no problem. Also, as long as the signal isn’t cut off, it doesn’t freeze once it works.
Possible causes I currently see:
- my device has a hardware fault that leads to faulty triggering in NORM mode
- my config file is corrupt
- it’s normal for this mode, and I misunderstand the concept behind this
Please don’t investigate too much, as I see it as a minor bug (in fact I accidentially activated A&B mode in wc3.4 and wondered why my channel suddenly seemed dead, mostly I use AUTO trigger mode for single channel). Unfortunately I have no option to test a different DSO203, as I only have this one available.
Again, thanks for your great work!
Looking at your screenshots, I can see why you are getting these results, at least with the waveforms you are displaying:
You are using the auto trigger mode on a wave with a significant DC offset while in DC coupling mode. This pushes the waveform up away from the baseline. When not triggered, the auto trigger function looks for crossing events at the baseline, so it doesn’t “see” the wave riding on the DC offset above, unless it catches some transient while switching functions. Once triggered, it depends on the displayed waveform to establish a mid-point reference but in normal mode, no signal is displayed until it is triggered, unlike in auto mode.
The obvious solution is simply to shift the coupling mode over to AC. Notice that ALL outputs from the internal generator have this DC offset.
Another solution, if the DC offsets are desired to be displayed in DC coupling mode, is once triggering level is established with AUTO trig and waveforms are properly triggered, freeze the setting by long pressing button 2, this shifts over to manual mode. Or just simply move the trig cursor to the proper level in manual mode. When manually shifting the trigger level in A&B mode, both channels move together, so it may be necessary to shift triggering source to one or the other channel to set that level, then shifting back to A&B mode.
Setting auto trig with a short press of button 2, then following with a long press to freeze the setting is a sequence I use extensively with these devices, since auto trig can cause the trig level to fling around a lot in trying to follow rapidly changing waveforms.
Dear Wildcat,
I see, the problem was that I misunderstood the concept, and there’s no system fault at all. Using manual trigger level truly solved the problem for me.
For me it is absolutely desirable to display pulsating DC “as is”, as currently I mainly measure PPM and PWM signals in lipo powered model flight hardware (that’s why I chose a pocket device that I can use at the flying fields) and the like and need to see the true voltages next to pulse width and frequency, so AC coupling is not a solution for me.
Many thanks for your efforts and pointing me to the right direction. Again have learned something!
Greetings from germany, keep up the great work
Thomas
New updates V6.1/V5.2:
Mainly updates CHART mode to fix improper ADC operation at slowest timebases. Changed chart buffer to oversampling and added selection of either averaging or oversampling (peak hold) modes. Select while in chart mode with menu on timebase adjust, short press left toggle center to access chart mode auto file write, press again to access buffer mode. Change with left toggle. Defaults to averaging but selection is saved with config files.
FPGA based OS function proved to be not well suited for slow chart operation, so used software instead. Since this does not depend on FPGA hardware, the revised chart mode is compatible with older versions as well and so is also included in V5.2
Oversampling factors vary from 100X at 0.1S/div to 600X at 10Min/div. eg: at 10Min/div, the device obtains 30 readings per second for a total of 600 during the 20 second span for each the 30 steps in one division (600sec/30steps), then either averages them to produce one sample or stores the + and - peaks for display. Averaging will reduce noise while oversampling captures any noise or signal spikes.
Other fixes: (See readme.txt for more info):
V6.1:
-Fixed long buffer mode not always initiating when recalled from a config under some conditions.
V6.1/5.2:
-Updated detector mode frequency display.
File is broken. Download randomly 44-106kb zip. Tried on computers with win 7, 8.1 and 10.
Just tried to access the files I posted, they downloaded OK for me.
SEEED may be updating their web site, if you go to http://www.seeedstudio.com/forum/index.php for example,
the section under “DSO” is blank. Several others are as well. Perhaps this has something to do with
failed downloads.
I noticed an unusually large amount of downloads for these files, for being posted for only 1 day, perhaps
others are having difficulty as well and re-downloading the files repeatedly, bringing the counters up.
Will be keeping an eye on this. Will try re-posting if necessary…