DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes)

Hello WildCat. I found an issue with chart mode and long time base - 5-10M. In this mode I want to make graphs of discharging batteries, but after few minutes all readings drop down. Tried with both channels A&B, only A, only B. This is happening with all buffer modes with time base more than 1M. At 1M there are a small spikes that can confuse my readings.

This problem is since WC5.0, now with 6.0 is the same. I need both channels for measure voltage and current of discharge.

Is there a cure for this?

Not sure what the drop down to half level is shortly after the beginning of start is in the second screenshot, but both displays show shutdown after approx 10 mins.



Looks like the program is going into standby. After a 10 min. time span of not using any of the controls the device shuts down power to the scope front end and puts the processor in standby mode. Only the generator part will still function at this point. To disable the standby timer, first shut meters OFF, then long press right toggle (button 6). A notification at bottom of screen will display “standby timer off”. The timer can be turned back on by long pressing the button again. Plugging a charger into the USB port will also disable the timer while the USB cord is plugged in. I should have pointed this out in the user guide while using chart mode with long time periods.



Note that this setting is NOT saved with a config file, the program defaults to “timer on” every time it is started, so this will need to be changed again after a restart if necessary. Also note buffer mode defaults to normal while in chart mode (no oversampling), and setting A & B trig mode will force the mode out of TrOFF and into NORMAL



As far as the spikes on your display, I would guess this is likely noise picked up from interference. I would disable the generator output (your screenshot show it set to PWM, change wave type until it shows “off”). Any connection to the power line, such as to a ground from a charger, etc, can make the device MUCH more sensitive to RFI (such as motors turning on, etc), and can produce spikes of this nature. Otherwise, can’t really say, could be a number of things. Operating any of the controls can produce noise on the display. You could set up the scope in a faster time base, perhaps with one of the oversampling buffers types, and use the persistence mode, which will “record” any spikes if set to “continuous” to get a better picture of the noise, this might help identify it.

In any case, it’s something picked up by the scope’s preamp, whether it’s part of the signal you are monitoring or not.

OK, first screen is on battery with sleep timer off, second is on charger. In both cases readings drop down long before first line of the grid (10min).

Can I ask you to try this setup with your device? A simple Li-Po battery or other DC source, connected to probes with 10min timebase.

Ok, when I first looked at your first screenshots, I thought the problem was that the level was dropping down to 0 after ~ 10 mins, I didn’t notice the cursor on top indicating this was just as far as the readings had advanced, that’s why I suggested the standby timer. So the problem is the drop down to around 1/2 level.



I just let one of my devices run at 10M/div with these settings for around 40 mins, and although I didn’t get any drop in level, when first started the level was wrong, at about this 1/2 level, as if perhaps the range hadn’t been updated properly. After shifting the timebase to a faster position, it corrected itself. This may be related to what you are experiencing.



I will check this over to see what’s going on… I need to know what versions you are using. Presumably, since you loaded V6.0 of the program you have hardware 2.81, I need to verify this. I also need to know what FPGA version you are using, factory, V1.0 as included in the APP 5.0 or V1.1 included in APPS 5.1 and 6.0.

First one is taken after purchase of the device, no mods. Second is with latest WC6.0. FPGA is from 6.0. Before that there was 5.1 with FPGA from it, same problem. Never tried 5.0.

Hi



I bought a brand new DSO203: Hardware 2.82, SYS Ver 1.64, Serial No 792BD89A).

I tried to install Wildcat Version 5.1 => but uploading app1.hex via DFU results in app1.err.

So I uploaded FPGA_281.ADR, 281_FPGA.BIN and app1.hex (all Wildcat 5.1)=> uploading is perfectly done => but restarting dso hangs in splash screen showing “FGPA configuration error

After that I tried these configurations without success:

[attachment=1]screenshot.jpg[/attachment]

Uploading to DFU always looks well
[attachment=0]update.jpg[/attachment]

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. :slight_smile:

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]

  • [*]Download WC 6.0: http://www.seeedstudio.com/forum/download/file.php?id=2488
  • [*]unzip it
  • [*]open file explorer an change where you unzipped WC 6.0
  • [*]switch your dso off
  • [*]Hold >[] Button (most left button) while switching DSO on. => Screen shows "... The DFU Virtual USB Disk" (last of four lines)
  • [*]connect dso to computer with usb cable => (waiting some seconds ...) new drive letter will appear
  • [*]copy app1.hex from unzipped directory to this new drive => new drive will disappear for a moment
  • [*]new drive will reappear. => you will see app1.rdy (if you see app1.err something went wrong)
  • [*]switch dso off and on => :)
  • [/list]

    Hello dida!

    Thanks for reply!

    1. You told me " copy app1.hex " - just only 1 file from that big folder… that is enough ?
    2. And what happens if I saw " app1.err " - my device became bricked? Could I restore it in such case?

      Thanks again!

    @muslimens


    1. Yes. The rest is for advanced use. (to program additional features to WC e.g.)

      2.) estimate:
      [list]
  • [*] 95%: no changes => the old firmware works
  • [*] 4%: same problem as me => try another way to reconfigure (see man y examples here in this thread)
  • [*] 0.9%: get some help to reconfigure
  • [*] 0.09%: get some special help to reconfigure
  • [*] 0.01%: bricked
  • [/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.