If the display is fluctuating between 2 values, it just means that the correction “step” is in between 2 values and can’t “decide” which one to use. From a practical standpoint, it makes little difference in such a case which one you choose. If you want to be real fussy, choose the one that it stays the longest in, if you can tell.
In the end, due to the relatively low resolution of an 8 bit ADC, some non-linearity inherent in the analog to digital conversion and calibration process used in the hardware, particularly at the bottom of the screen, and the fact that gain and DC offsets in the preamp stages are affected by battery/power supply level, all these will have more of an effect on accuracy.
I have extended the resolution of the calibration display, and provided some means to compensate for various influences affecting accuracy, all in an effort to eliminate at least adding more errors while calibrating. This may have given the impression that the device is capable of higher accuracy than it really is. The core function of the calibration routine is basically unchanged from the original authors, and seems to work as well as it can under the circumstances, but the fact remains that from a voltage level standpoint, this is a relatively low accuracy device. If was not unusual with the original software on earlier devices for voltage to be off by 30% or more under some conditions.
The hardware could certainly be improved, by providing better power supply regulation and analog compensation of DC offsets and gain rather than digital “steps” that distort the waveform and add ambiguity to the voltage meters, but these would greatly add to the complexity of the design. With careful calibration, errors can be brought down to the 2-3% level or less, depending on the range and the level measured, at least making it useful for troubleshooting purposes, and waveform distortion from these calibration “steps” can be disabled: long press center button 5 (left toggle) with meters off.
V5.0: Just some fixes for previously unnoticed issues with recently added functions.
Specifically,
-Fixed jitter stabilization not working at fastest timebases if either channel A or B was in invert mode.
-Fixed BUF file loads not scaling time base right if loaded while in time bases faster than 5uS/div.
-Fixed UAR file load not stopping UART GEN transmission at end of file on 8MB devices.
-Moved the “File already exists” notification off the screen so it does not get saved along with the display.
-Increased hysteresis of battery level compensation to minimize frequency of shifting DC offsets
from varying loads on battery.
-Fixed pixels left behind in meter section after loading BMP’S with meters on.
-Fixed screen update after “scope disabled” notification while in XY mode with wave generator on.
Also added button 6 center press (right toggle) to view previous BMP/BUF file.
When used with revised FPGA, provides selection of untriggered AUTO time base mode behavior
(see screenshots). Toggle selection menu by pressing left toggle center button while main menu is in
TIME BASE MODE with AUTO flashing. Change with left toggle.
V 5.x and up also will mark the starting point at which any functions added to new FPGA versions will be
accessible from the program.
Revised FPGA includes added triggering data buffer to eliminate the possibility of read/write collisions
while capturing data on the fly, as was previously done, and implementation of a freerun mode for
AUTO trig. This will also serve as a base for any possible new FPGA based functions added in the future.
Upload to device by first copying the ADR file, then when volume reappears, copy the BIN file.
NOTE: this is ONLY FOR HARDWARE V2.81, will NOT work on older devices.
“Continuous” mode on the right vs “Fast” mode on left while untriggered in AUTO mode. CONT minimizes
waveform corruption when display can’t keep up with incomming signal, but at the expense of lost
pre-trigger section when mode first comes out of freerun on a trigger event.
Wildcat,
Thanks for the update. Unfortunately, I used Windows 10 to do the FPGA update and bricked my HW2.81 with no way to recover or launch WC4.5/5.0.
Welcome screen now states:
FPGA Configuration Err!
Hardware Ver 2.81d tSerial No: 7E1AC099
DS203 Mini DSO SYS Ver 1.64
FPGA error
That’s not a typo, previously stated: Ver 2.81 Serial No:.
DFU mode (DFU 3.45c) still appears to work (Windows 10), so I tried reloading factory FPGA 2.81.ADR and FPGA2.81.Bin. They appear to load properly, but this does not correct/change the welcome screen.
These strings are in the SYS area of ROM, I would suggest reloading the SYS file.
I can’t think of any way this could have been written over unless something has gotten corrupted. I tested this a great
number of times with essentially the same SYS and HW version without any problems. Would be curious if this has happened to anyone else…
Will check more into it tomorrow, it’s very late for me right now.
Just to make sure, I just downloaded the archive, extracted the files and loaded the FPGA to my device, with no problems.
This is Hardware V 2.81 with DFU 3.45c , SYS 1.64
Does the remark about 2.81 apply only to the revised FPGA part? That’s what it sounds like
So one can load v5 app OK onto older devices to benefit from the non FPGA bits?
Yes, the app will detect whatever hardware/FPGA version is used and adjust itself accordingly.
Update …
I isolated the brick problem to using Windows 10 in DFU mode with DFU 3.45c.
Using a WinXP PC, I was able to restore everything (HW2.81, DFU 3.45c, FPGA_281, SYS 1.64) and install WC_281_FPGA, and WC5.0.
Sorry for the disruption. Win10 reports successfully loading everything, but apparently leads to corruption of the upload to DSO device.
Thanks for the help.
My update to V5.0 was OK using Win8.1, cannot use Win10 as PC will not recognize Quad in DFU mode. Works OK in normal mode.
Great work as usual Wildcat, just wish I had your talent…Beers are on me
Merle
DFU drive seems to be very fussy:
For me Win10 did not work as well (tried desktop PC and laptop); another Win7 laptop did not work as well, DSO does not come up any more :shock: 
Fortunately I had the Win7 HD form the first laptop before migrating to Win10, that worked at least … puh …V5.0 is up. 
(HW: 2.6, SYS 1.52)
TNX
I’m confused the WC5.0 will work on HW2.6 or not?
Yes, this is explained in the user guide under “HARDWARE AND COMPATIBILITY ISSUES”
COMPATIBILITY:
This version should be compatible with:
Hardware V2.6 and later (including the later 8Mb devices)
Sys V 1.51 and later
FPGA V2.61 and later
ALTERBIOS V 0.4 Should be installed on 2Mb devices to fix file corruption issues.
Note however that the revised FPGA is only for hardware V 2.81. Any functions that the new FPGA
provides will just not be available with earlier hardware, but the program will work properly otherwise.
Hello everyone,
I’ve just bought the DSO203 and i’ve a noob question.
I need the X/Y mode for tests on my Chua’s circuit and if i read right, the WC5 could be fine for this purpose.
I’ve HW 2.81 SYS 1.64 and DFU3.45C
Have i to copy only the app1.hex file to the DSO?
UPDATE: found it --> <LINK_TEXT text=“http://www.seeedstudio.com/forum/viewto … =26&t=6359”>http://www.seeedstudio.com/forum/viewtopic.php?f=26&t=6359</LINK_TEXT>
Have i to calibrate the DSO after the WC5 installation?
UPDATE: Seems no, someone have suggestions?
Thanks in advance
Luca
You do not need to calibrate the device for it to function properly in X-Y mode. There may be some DC offsets though when using it in normal scan mode which will shift the baseline off from the channel indicator. At the least, the auto calibrate part can be done for each channel, this will remove excessive DC offsets. For the voltage calibration part that comes after the auto calibrate the entry fields can just be left blank. Just shift through them with the right toggle to get to the end and save the results. Voltage calibration is provided to improve waveform amplitude and voltage meter accuracy.
To properly use the X-Y mode, keep in mind that the timebase and number of samples used will affect the quality of the display, and will need to be adjusted to the frequency of the signal to get the best results (see the user guide for more info). A bit of experimentation will be helpful to get familiar with this mode.
Ok so for now i can work with the current DSO status
Yes i saw that i have to “play” with CH A and CH B voltage measure and timebase on X/Y mode to fine tune the circuit on a perfect chaos state. For the rest i can obtain a really good “double scroll” image. I’ll post some images if someone is interested.
For firmware work: really good job mate, thank you Wildcat and your predecessors, you really saved the day.
Luca
Hello everyone,
recently i found out, that DSO FW still developing by Wildcat.
For that - thank You very much! I was trying to install one old app from PetteriAimonen’s QuadPawn
and found out that on the new HW (2.81) it won’t work - that’s i’ll try to fix. To test my toolchain i built Wildcat’s app - got it 100% working, 100% speed preserved, but the size of it concerns me - 344kb instead of original 434kb. Wildcat, is it wrong or?.. Used GCC 4.8.3 (linaro) + newest binutils (2.25.1).
The size of the executables can vary wildly depending on what compiler optimizations you use. With a different compiler version, I’m not surprised you are getting a different size. As long as everything works properly I would say it’s OK…
I know that - but i use the same optimisations as you are: -O2. Already tried out GCC 5.3 (it generated even more compact code - 323 kb), this time after successful build app not starting. My point was to free some space for Quad Pawn - but it seems it’s not enough (device refuses existing pawn 101k image - it won’t work, that’s only to check if it will be loaded).
And one more detail - i loaded all from Windows10 without any issues (except DSO should be connected to the PC after entering DFU mode - otherwise Windows recognises unknown device).
I suspect you are getting different sizes because of the different compiler versions. I’m using a much earlier version.
As far as Pawn is concerned, all my recent versions leave enough room for it as it installs in slot 4. I noticed that Pawn did not work with HW 2.81, this might have something to do with file access issues as it was originally written for 2MB devices. Also Pawn instals code in the second half of the ROM, this was for the updated file access for early devices and is loaded in the 0x40000 to 0x48000 section. The second part of my app versions load after this so as to not overwrite it.
from us9igy
Interesting find!!! I tried the same with my Win 10 and everything worked OK. Wonder what causes this Win 10 problem?
I was hesitant in updating my Win 8.1 to 10 because I wanted to insure I had access to my Quad. It seems there is now a “work-around”.
Thanks us9igy!!