A few days ago I ordered a DSO202, but something went wrong with the order. This will be fixed soon, but I’m now thinking of cancelling the order to get this DSO203 instead.
Its price is a bit higher, but I think it might be worth it.
I haven’t owned an oscilloscope for 30 years now, but would like to have one again. If I’m getting much more “bang for the buck” with this one I will cancel that order of the DSO202.
I didn’t know anything about a custom firmware like this one.
Is there one for the DSO202…
I would love to get some input before that order goes through…
Thanks
Frater,
DSO203 has many custom firmwares to try out. 4 channels to work with. Bandwidth is much better.
My choice is DSO203.
Jerson
I appreciate your reply and I know it’s somewhat off-topic, but I had no time to research it.
It seems my order for the Nano is now cancelled and I can order this DSO203.
The order needed cancelling anyhow, even if I still took that DSO202
It does seem to be a much newer device (the touch), but I think
Another question.
They speak of 2 analog channels and 2 digital channels on this one.
The dso202 has 2 analog channels, does it?
The touch 202 is a newer device and has good eyecandy but less analog bandwidth. However, I can swear by the DSO203 I own for a some time now. If you need more info, please open another thread so as not to divert this thread topic.
Hi, WildCat! I want to thank you for excellent operation and to wish a good health!
I updated the DSO203(HW 2.81 SYS1.64 DCU 3.43) on version 5.1 and used FPGA 1.1. I checked operation of an oscillograph in the mode of the complete buffer. Results are visible on a photo. Problems begin in the AC1V,AC2V,AC5V mode. In channel B there are no such problems.
Thanks for the feedback.
This is not an issue with the ADC. This is noise picked up by the preamp. Noise from the ADC would show up the same on the screen regardless of the vertical range used.
I had a similar problem with my unit, causing thickening of the trace on ChA in full speed mode similar to yours. Turned out to be a bad ground. The metal frame that holds the LCD is grounded by a stick-on metalized tape to one of the input or generator output jacks and it was making an intermittent connection. You could move the plugs around when inserted into the jacks and the noise would cut in and out.
In any case, this is definitively noise picked up by the front end in the input section. The device switches in a different op-amp when set to ranges of 1V/div and above. Looks to me like noise from the rest of the circuitry is being leaked into that section, possibly from a bad ground, capacitive coupling, power supply issues, etc… ChA seems more susceptible to this for some reason, probably because of the location of the circuit traces on the board. The LCD is also a prime cause of radiation into the circuitry if it’s frame is not properly grounded, since it covers the entire board. The grounding method is rather poor, relying on simple pressure of part of the frame onto the metalized stick-on tape.
As I mentioned previously, the full speed mode will, by it’s more sensitive nature more readily reveal any noise, whether generated by the circuit you are monitoring or generated inside the scope itself. This is in fact part of what makes it useful. Also, loose or defective probe plugs making a poor ground connection where inserted into the input jacks can cause problems like this.
You could try reverting to an earlier FPGA, it’s possible the extra circuitry for the full speed mode is causing an increase of noise on the supply lines, and an increase in this noise, but since it’s only appearing on some of the ranges, I suspect that some hardware issue in the preamp is causing this, and that it would also show up with earlier FPGA’s, though possibly to a lesser extent. Notice that the “spike” part of the noise shows up in your screenshots even when not in full speed mode.
Hi, Wildcat! Thanks for the detailed answer, I have understood you. It is interesting whether other owners of this version have such effect?
Prompt how you have solved a problem with grounding of LCD?
Hello Wildcat,
it seems there is an error in setting the trigger level.
If I select the trigger level for chan A and select level with button 4 I can lower the level with the left toggle,
but if I want to increase the level with the left toggle it just cycles through the sub-options as if pressing
button 4!
I am using your version 5.1 wit hardware 2.81 and the FPGA W1.1 file recommended for that version.
Then, after selecting something else the setting even refuses to go to the LEV section while pressing
button 4.
Any idea?
Best regards DK8HI
DK8HI,
The trigger LEV function is so commonly used, others with your hardware version and WC5.1 would have reported that weeks ago. Also doesn’t sound like a mechanical switch problem.
Try reloading your SYS & WC5.1, one at a time, to see if that issue is resolved by a reload.
You have to take the unit apart, of course. On the front side of the board, the frame of the LCD presses against a small wire mesh covered square that is glued to the Gen Out jack body. I first tried to solder a wire directly from ground to the LCD frame but the metal it was made out of didn’t seem solderable. I was reluctant to apply too much heat for fear of cracking or otherwise damaging the display, so I just soldered a piece of thin copper over the wire mesh and onto the jack which built up the thickness and allowed for a better contact with the LCD frame.
I just looked at pictures of some earlier hardware versions, and these seem to ground the LCD frame in a different location. There appears to be more than one display version being used, so not all units may be the same.
The only thing I can think of is maybe you have inadvertently pressed button 2, which sets the trigger level to AUTO. In this mode, cycling though the trigger menu with button 4, the “LEV” sub menu will be skipped. Press and HOLD button 2 until it beeps, this sets the trigger level to manual and moves the focus to the LEV sub menu. To the right of “LEV” will show “MAN”. In manual mode, button 4 can also be used to select LEV. When in auto level mode, MAN changes and cycles through 1/2, 3/4, then 1/4 with each SHORT press of button 2.
Good health to you, Wildcat! Recently bought a DSO DSO Quad. He wanted to update the firmware and searched the Internet, found. Before I HARDWARE was 2.81 and was 2.6. I do not understand what happened. Then set your firmware, it became much better. Can I create one that is not so. How to change the firmware properly? How to make CH(A) in the middle? When connected to a computer, he does not see it as a drive, format offers, but ends up formatting error. I am just learning. Help me please.
Photos from my mistakes DSO Quad could not upload here, but I can send them to you by mail.
Thanks!
Was not aware that button 2 would set auto trigger permanently.
DK8HI
You can send me a message. Explain what hardware version your DSO Quad is and what updates you have done.
Just now noticed some issues with my latest updates loaded on hardware 2.81 devices: These involve problems like loss of some meter functions or meter display after saving config files, possible temporary loss of triggering or other random problems.
The fix involves increasing RAM allocation from 48K to 64K and increasing the call stack from 8K to 16K. Since HW version 2.81 is the only version with 64K of RAM available, this would NOT be compatible with any other previous hardware version, nor would it be necessary since these problems do not appear to exist with earlier HW 2.60 and 2.70 devices.
Possibly, the larger buffer size needed for the 8MB drives is causing the stack corruption; unknown at this point if HW V2.72 is affected, these were the first to have 8MB drives. All my previous devices are of V2.70 or earlier so I can’t check those out.
I have always taken the older version devices out for field use, so this went on unnoticed until now. Will be taking the 2.81 unit for use from now on.
Will be posting an update to fix this shortly, need to check things out more thoroughly. However this will now necessitate different versions for new and older devices. Again, older HW 2.70 and earlier units should work properly with all posted versions.
Hello,
It’s possible to install your software for version HW2.82?
I’m not aware of any hardware version 2.82. As far as I know, the latest hardware version produced is V2.81. If that is what you mean, yes, you can instal the latest 5.1 post which is on page 57. In fact, you can instal that version on any hardware version.
However, as I posted above, when using 5.1 with the latest hardware version 2.81, there is not enough memory allocated and when saving files, some functions will not work right afterwards. Nothing really bad will happen, but some things (eg: meters) will malfunction. I’m surprised nobody else picked and reported on this.
You can either update it with the fixed version after I post it, or just wait and use the fixed version.
Just found out about this late last night. I had originally allocated all the memory available while developing the 2.81 compatible version, so I didn’t notice the issue at the time. But at the end had to reduce it ensure compatibility with the older hardware versions, which have less memory. I figured this should work OK with the latest version as well but didn’t think about the much larger file buffer used with the latest devices with 8MB drives.
This will now necessitate 2 different versions, 5.X which will work on older devices, and will be posting a fix the above issue with HW 2.81 devices as version 6.0 shortly, possibly later tonight if everything works well, just looking to fix any other minor issues as well before posting.
From now on, versions 5.X will be used for any future updates for the earlier hardware versions only, while 6.0 and above will be for HW version 2.81 only.
I have received it just, and it has hardware version of 2.82
Hello,
I wish to thank you for this great firmware which I just loaded on my DSO203. I’m quite new to this so I expect long hours before I can really manipulate it with ease (although since I am new to 'scopes, I have nothing to unlearn).
I wish to report (because I have not seen much on the subject) my experience loading the firmware on a mac (OSX 10.11.4).
My DS0203 is HW 2.81, Sys 1.64.
The USB disk mounts correctly and seems stable
The DFU mounts correctly and seems stable.
To minimize problems, I have disabled Spotlight on these volumes.I also used ‘cp’ in a terminal rather than Drag and Drop in the interface.
Installing the FPGA was a breeze. Both files copied and gave me the correct results.
However, copying app1.hex gave me an ERR file.
I was able to copy it correctly using VirtualBox and an XP image (and D&D in XP)
Regards,
Lga.
V6.0: Bugfix update for V5.0 and V5.1 when used on HW V2.81
Functionally identical to V5.1
Update V6.0: For HARDWARE V2.81 ONLY - Will NOT work on earlier devices.
Fixes issues that are only present on 2.81 devices loaded with V5.0 or V5.1.
V5.x loaded on older HW versions are not affected.
V5.x loaded on HW2.81 using original FPGA may not be affected, since most of these new issues originate from program support of full speed buffer mode, which is only available with the updated FPGA. However, 5.x/2.81 users with original FPGA should still update to V6.0.
V1.1 FPGA included is same as in V5.1, no need to update.
-Increased RAM allocation from 48K to 64K and stack from 8K to 16K. Fixes a variety of potential problems such as loss of meter functions or triggering issues after config file saves. (This breaks compatibility with older devices, which only have 48K RAM)
-Fixed an issue where the program would crash if loading a saved configuration file with a full speed sampling setting while in one of any of the OS modes if the saved configuration contained a long buffer mode XPOS value greater than a certain value.
-Fixed shifting ChA/B DC offset levels after engaging FFT or other functions while in full speed buffer mode, possibly leading to corrupted calibration data if saved.
Any future updates will consist of 2 separate versions: V5.x for pre-HW2.81 units, and V6.0 and up for HW2.81 units ONLY. I have several of the older version devices so I plan on supporting those with the same additions and fixes as the later one, if possible, apart from FPGA based functions such as full speed buffer mode. This will also allow future optimization for the older units, freeing up memory by removing unsupported functions.
For anyone interested, also included a config file reading utility (QUADCFG.EXE). Displays and describes saved configuration and calibration parameters. Built this to help me fix these recent issues with the program. Copy a WPT or CFG file to same directory as utility, type QUADCFG followed by a space and the name of the config file on a Windows command line. Will write a file of the same name but with a TXT extension with the information. If no config file name is supplied or utility is just clicked on, will load first WPT file found in same directory, or just display instructions on the command line if no WPT file is found. Can be used to check for config file corruption or just for informative purposes.
Works with any version WPT “style” file, should also work with early factory apps using WPT config extensions.
Re: HW 2.82 as seen in a recent post: Uses same SYS (1.64) as 2.81, unknown DFU. I would expect this to be compatible with 2.81 updates, but since I don’t have a unit on hand, I can’t verify. Perhaps some info will appear on the MiniDSO site, but don’t see anything there yet…