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

[ThomasCaspari]

DFU always has been kind of funny. I once had a problem (not with wildcat, but with gabonator) reinstalling: always got an .err. Needed to reinstall because by accident I overwrote part of the code. Solution was: install something completely different into the same slot, and then try again. Which in fact solved the problem!

Was not Win10 though, but Win XP (my older 2.70 device with DFU 3.11C). So in case reinstalling whatever doesn't work, one could possibly succeed by following that procedure.

Have fun

Thomas

[thenaughtyfantasy]

You might say update is difficult but with a cheap USB to RS232 adapter and the tutorial i made it is very easy for anyone.

I wouldn't be too hard on the factory guys, Microsoft likely changed, on purpose just to screw things up, the way these (to them obsolete) volumes are accessed in their new Windows versions.

It would seem though there should be some way the DFU could probe the host system to find out what version of Windows is accessing it, then readjust itself accordingly. Or simply have a menu so the user can select the proper Windows version.

Not sure though how many users are willing to open their devices, solder some pins and attach a serial connection to their PC in order to do this. On a bricked unit, yes, but on a perfectly good device it seems much simpler (and safer) to just find an older computer to upgrade with.

Yes i get your point, but it is really weird that only this specific device has such an incompatibility problem, where you saw it doesn't seem to be OS specific but rather than system specific. Also it will still affect new devices sold to customers, and i think they might not being even aware of this issue. I thing i should just make a thread to see what they have to say about it at least :p

DFU always has been kind of funny. I once had a problem (not with wildcat, but with gabonator) reinstalling: always got an .err. Needed to reinstall because by accident I overwrote part of the code. Solution was: install something completely different into the same slot, and then try again. Which in fact solved the problem!

Was not Win10 though, but Win XP (my older 2.70 device with DFU 3.11C). So in case reinstalling whatever doesn't work, one could possibly succeed by following that procedure.

Have fun

Thomas

Yes i was thinking to do something like this but couldn't find the original app on that (winxp) system so i happened to try the other win10 system and it worked. If i remember i will try this next time to see if it makes a change or not Another thing worth noting though, it actually required me to re-install the fpga after installing wildcat on that win10 system, where i had already installed it multiple time successfully on the winxp system multiple times. What's up with that?:p

[Wildcat]

[ Another thing worth noting though, it actually required me to re-install the fpga after installing wildcat on that win10 system, where i had already installed it multiple time successfully on the winxp system multiple times. What's up with that?:p

The DFU update you downloaded from the MiniDSO site is a complete ROM update, including the V1.64 Sys and the original FPGA and LOGO, along with their APP, that's why the FPGA reverted to the original.

[thenaughtyfantasy]

[ Another thing worth noting though, it actually required me to re-install the fpga after installing wildcat on that win10 system, where i had already installed it multiple time successfully on the winxp system multiple times. What's up with that?:p

The DFU update you downloaded from the MiniDSO site is a complete ROM update, including the V1.64 Sys and the original FPGA and LOGO, along with their APP, that's why the FPGA reverted to the original.

Yes that's correct, i know this, that's why i installed your FPGA first before attempting to install the APP. However after successfully installing your APP i needed to re-install the FPGA again even though i installed it successfully. I know it sounds weird because it is.

[wotsac]

Hi guys! Hello Wildcat!

Is there a way to rename saved configs and display custom titles for the configs on the screen?

I have 9 or 10 different config files set up, each tuned to handle a different task, but it can be quite difficult remembering which config is for which task. I've used a sticky-note to keep track but I change these configs enough sometimes that it's easy to get confused or lose track of these configs.

But it would be great if I could rename these config files to something else in order to get a better idea of what they're for.

Thanks.

[Wildcat]

Hi guys! Hello Wildcat!

Is there a way to rename saved configs and display custom titles for the configs on the screen?

I have 9 or 10 different config files set up, each tuned to handle a different task, but it can be quite difficult remembering which config is for which task. I've used a sticky-note to keep track but I change these configs enough sometimes that it's easy to get confused or lose track of these configs.

But it would be great if I could rename these config files to something else in order to get a better idea of what they're for.

Thanks.

Would require a rather extensive rewrite and expansion of the config file access function. I agree it would be a nice touch. Memory is getting pretty low though, specially with the older devices. Will keep it in mind.

With regards to other suggestions made, one was automatic saving of config files: gave this some thought, one problem is that this would disrupt the display for a second or two while saving, so if done often enough on a time basis to be effective, could become annoying as well as result in lost data. Likewise if done after menu changes: It would have to be continually saving configs after changing settings to be effective enough to save the last configuration. Otherwise, when would you have the config save itself?

As far as a past suggestion to change the shortcuts, I'm reluctant to do this. I suspect most users are by now familiar with the operation as it is, changing things would likely lead to frustration.

[borland]

WC,

Great job on the latest update (v6.1). I really like Chart Mode now.

On suggestions for added features.....

It would be really nice to have a DC offset feature on CHA and CHB. This would allow adding or subtracting a fixed value of vertical offset in DC mode. This is a feature provided on more advanced oscilloscopes and allows observation of small variations of signals with large DC offsets. There is a hardware work around by using channel C's A-B mode and external adjustable DC source. Alternatively switching AC coupling on removes DC bias, but there can be reasons for wanting to see the DC bias along with the signal.

[Wildcat]

WC,

Great job on the latest update (v6.1). I really like Chart Mode now.

On suggestions for added features.....

It would be really nice to have a DC offset feature on CHA and CHB. This would allow adding or subtracting a fixed value of vertical offset in DC mode. This is a feature provided on more advanced oscilloscopes and allows observation of small variations of signals with large DC offsets. There is a hardware work around by using channel C's A-B mode and external adjustable DC source. Alternatively switching AC coupling on removes DC bias, but there can be reasons for wanting to see the DC bias along with the signal.

The hardware is not designed to be able to do this. The only software access to the signal path is at the output of the preamp, at the unity gain inverter that drives the ADC, so while you can shift the wave up/down, any DC applied to the input beyond one screen's height will clip at the top just the same, so if you shift the wave down you will just see the clipped signal.

This has already been observed with some devices that clipped at a lower level than the top of the screen, and required the ADC "window" shifted down to hide the clipping.

Likewise, using ChD's A-B mode with what I presume you mean is a DC signal on the B channel balancing the wave on ChA, if DC on ChA is large enough it will still still clip the waveform at the same level (roughly at the top of the screen), even though it may appear at a lower position. The A-B mode is mixed by the software, after the ADC has processed the signal, so it has no real effect on either ChA or ChB's DC offsets.

To work properly, DC compensation for this purpose needs to be done at the input, so that the preamp doesn't "see" it, and there is no provision for this in the device. Otherwise the very small dynamic range of these devices, limited to just about one screen's height will just not allow it.

This is a compromise that must be made to keep power consumption down when running on batteries, voltage levels must be kept low, limiting dynamic range.

[borland]

I guess a hardware circuit could be how those advanced scopes are handling the DC offset function.

Is it possible to set the ADC’s upper and lower reference voltages? I was thinking you might be able raise the lower reference voltage while still keeping the higher reference voltage above the signal level.

This excellent youtube.com video doesn’t discuss clipping, but explains the usage of oscilloscope offset function with DC offset waveforms.

[Wildcat]

Is it possible to set the ADC’s upper and lower reference voltages? I was thinking you might be able raise the lower reference voltage while still keeping the higher reference voltage above the signal level.

The only thing you can change with the software is the DC offset going into the ADC by varying the bias of the op-amp that drives it. This is what you do when you change the Ypos control. However, this is only limited to the height of the screen. When you have a DC level at the input that moves the signal up above the top of the screen, you will be clipping, thus losing the signal in the PREVIOUS op-amp that drives the ADC section.

So nothing you can do around the last op-amp/ADC section (which is the only access point for the software) will help because the signal will have been lost in the previous stage, clipped to either the power supply rail or ground, depending on the polarity of the DC offset.

The solution is to inject a DC current at the INPUT of the first op-amp, balancing and "neutralizing" the DC offset at the input, so that the first op-amp doesn't "see" this large DC offset, restoring the signal position to within the screen.

This could be done by adding a PWM output from the microprocessor, filtering it into a DC level, then feeding it to the INPUT stage, like the one at the output does now to adjust the waveform's vertical position. This is essentially the difference between position controls and DC offset controls. The position controls adjust the signal at the ADC input, while the DC offset controls balance out the DC at the input of the first stage, before it can get amplified and cause mayhem by overloading subsequent stages. Remember that the preamp stages in these things only run at 3 or 4 volts, giving a +/- 1.5 V range, barely enough to clear the top/bottom of the screen. Special op-amps, so called "rail to rail" needed to be used to operate within such a narrow window.

So to implement this properly, you would need to have a spare PWM port available from the processor, construct the proper connections and filter network on the circuit board, and add the proper software function to adjust this, along with some display for the compensating voltage value. An additional series of steps to calibrate this would likely be needed in the calibration routine. Also, careful attention would need to be given as to exactly where and how this is injected at the input so as to not disrupt the attenuator calibration for the various ranges.