After reading your comments on the other thread, about ERR with saving CFG files, I noticed that I didn’t have any CFG files on the flash drive. Only had the one WPT file that was created from running the analog calibration. Apparently this was causing the CHA mode fault that you weren’t able to reproduce.
Funny how after saving the CFG and seeing the “OK” prompt, I was able to reload the CFG file settings from the file menu even though there were none; it must have been loading the WPT file instead.
After duplicating the WPT file as 000-009 CFG files, I noticed this fixed the problem. No more CHA mode incrementing when saving a CFG.
Actually, I was able to reproduce the issue, I stated so in my reply. It only does so under some
conditions though: The config has to be saved from the button 3 shortcut, and not from the file menu, the
active (flashing) menu has to be other than the file menu (this gets saved when you use the shortcut
so it goes back to it afterwards) and the final save has to be done with button 5 rather than pressing
button 3 again (button 3 can just be pressed again to save the file). The function that increments the
file save numbers incorrectly increments whatever menu was active when the hold button 3 was pressed,
rather than the file number.
This has already been fixed in the next update.
The #0 config file is the WPT file, the rest of the numbers (1 - 9) are CFG files. The #0 (WPT) file does
not have to have a file already present on the drive to be able to save it, unlike the #1 to 9. This is probably
the file you were saving.
Update: V4.1 (3 slot version only). Added I2C and SPI decoding. User guide has been
updated to explain how to use.
Also fixed a problem with serial decoding under some conditions intermittently triggering in the
500uS time base while in large buffer mode.
Fixed the “advancing menu item” issue while saving config files with left toggle press after selecting
save file function from button 3. Also changed some notifications to improve clarity as was
suggested in a recent post.
NOTE: For SPI decoding, the clock can be either on Ch B or Ch C. Using Ch C as clock allows
decoding both data channels simultaneously on Ch A and Ch B. Prior to hardware V2.72,
these devices had protection diodes that severely limited the bandwidth and timing of the digital
channels. Unless these are removed, at the speeds SPI typically uses, using Ch C the waveform
will be so far out of synch (if it triggers at all), that the function will be useless. For these devices,
Ch B can be used for the clock but decoding will then be restricted to Ch A only.
I2C DECODE: Master sends slave address + request for temp
to temp sensor IC, slave returns 12.0 degrees. NACK from
master ends transfers. Arrow colors show data direction
flow and ACK/NACK
SPI DECODE @ 4Mhz Chart displaying entire buffer
content for both channels can be toggled on/off.
SPI DECODE @ 8Mhz Channel B had to be used for
clock as digital Ch C would not properly display here,
even with protection diodes removed
I just got this device, HV is 2.81
how do I install this firmware?
I see many files in this .rar other than the .sys, I don’t understand the use of.
Thank you very much for your help,
The archive includes the source code and the binaries. For installing wildcats firmware, you only need
one of the hex files. I’ve no idea if you have to consider something when using the new hardware (2.81).
this is my test with my dso203 - wildcat4.1
Hardware Ver V2.72 8MB
SYS Ver 1.62
APP1 Wildcat V4.1
Usb disk msdos format (with Linux)
Save file bmp cvs buf ecc into 8Mb usb disk in normal mode fft, ecc is ok.
Save file bmp in spectrograph mode not work (err).
Open usb disk (8Mb) in Linux or Windows the bmp image is not valid is impossible open it (view it).
Load the save bmp with the dso is ok, the screenshot is show into the display.
Led for battery charge is only red.
The led remains red even at full charge. Never turns green.
Sorry for my english.
I can confirm a similar problem with hardware 2.70 and Wildcat 4.1, except with slightly different results…
No errors saving and loading BMP files in ‘Spec’ and ‘Map’ modes, however the loaded BMP file’s preview is blank (black) on upper 4/5 screen. Unlike BMP files saved in other modes, these corrupt files cannot be viewed with Windows 7 viewer.
Wondering about the 4-slot version found Wildcat 4.0, missing from 4.1?
Also, was wondering about trigger levels (LEV) for CH© & CH(D). These can’t be adjusted, so shouldn’t the trigger lines be removed and LEV be disabled? Trigger user interface seems confusing for these logic inputs.
Revision(W4.1) by Wilcat
Hardware Ver V2.70
SYS Ver 1.52
GCCv1.7W4.1 APP(2.51+SmTech1.8+PMOS69 fixes)
Configuration file not found
Have not personally had issues with file corruption (all my devices are HW V2.70
with the Alterbios plug-in with drives formatted on a Windows machine) .
Make sure drives are properly formatted, 2MB drives with 512 byte sectors
(or clusters), 8MB drives with 4096 byte sectors. On a Windows machine, this
should be the default, but if there is a choice it may need to be specified.
BMP’s saved with either the spectrograph or map mode are 64K color types, and
are 4 times the size of BMP’s saved in any of the other modes (16 colors), so
these may get corrupted more easily if there are problems with the drives.
The charging system is completely hardware controlled. The system has access to
the charging state from the charging controller, as well as the battery voltage but
does not control charging. The charge indicator is a red light only, which should go
out when the battery is fully charged. The green light is for standby. My
observations are that the charging system tends to charge these batteries a bit too
much, so I disconnect charging well before the red light goes out.
There is no 4 slot version for V4.1 since compiling this larger version with speed
optimizations would take 5 slots. HW version 2.81 should in theory support this,
with it’s larger documented ROM and remapped FPGA and LOGO code, however
it would over write the FPGA section of earlier devices unless the extra code was
mapped onto undocumented memory. Further issues with this undocumented
“remapping” would be compatibility with HW V2.81 and other programs using
Trigger level lines for ChC and ChD could be removed, but they are only there when
triggering source is set to that channel, and as such do serve as a trig source indicator.
This is a “carry over” from the original factory programming, never really gave it much
I just noticed that my previously installed AlterBIOS 0.4 failed to show on the welcome screen. Not sure why this happened. I reinstalled AlterBIOS 0.4 and although it did not reinstall without Windows errors and return RDY, AlterBIOS 0.4 OK now shows on the welcome screen again.
Result: Saved BMP files in Spec and Map modes can now be viewed on both DSO and Windows 7 viewer.
Is there any way to actually uninstall AlterBIOS? Not that anyone would need to do that right now.
Might be interesting if code optimized 4-slot versions were available in different flavors (different program features) since they could be easily swapped via PC link.
If Alterbios was not present, with HW V2.70 and earlier, you will get file
The Windows errors, and no RDY is normal, as long as it shows on boot
it should be OK.
Alterbios resides in the system section of the ROM. To remove it, you just
reinstall the Sys file and it will overwrite it.
As far as code optimized 4 slot versions, V4.0 almost completely fills all
4 slots, so adding much of anything spills over to the 5th. V4.0 just lacks
SPI and I2C decode, which take up a good amount of code in ROM. A lot
of functionality would have to be given up to include these to fit in 4 slots.
An alternate solution would be to map the extra code onto undocumented
memory, but this would now have to be hardware specific.
There is a certain amount of ROM above the 4 regular slots that all version
have available in common,this is between the end of the LOGO on earlier
devices and before the FPGA on hardware V2.81, that would ensure
compatibility with all devices, as long as other programs do not also use it.
However not having a V2.81 device to test this with, I wouldn’t be able to
verify the results.
I’m very very happy!!!
I formatted the drive with Win 7 choosing 4096 byte sectors and now everything works.
Bmp file saved and displayed correctly even from Linux and Windows computers!
Thanks for all the explanations Wildcat!
I fomatted with linux (gparted) but the program could only see 7mb space instead of 8m.
Let 1mb beginning of the partition that was untouchable.
I was forced to fomat because installing the app for the version to 2mb, the disc had been corrupted.
Anyway, with linux I mounted the disk and deleted everything with:
dd if=/dev/zero of=/dev/device
Finally DSO linking to Win7, I formatted.
The program formatting option Windows has correctly detected the disk capacity (8Mb) but not the bytes per sector, which I had set in 4096.
Finally, this is what I see now in linux with the command: fdisk -l
Note: sector size is 4096 (not 512)
Disk /dev/sdb: 8 MB, 8388608 bytes
1 heads, 16 sectors/track, 128 cylinders, total 2048 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x70707573
This doesn’t look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdb1 ? 1701998450 3638285201 3450179712 d Unknown
/dev/sdb2 ? 1701995885 2246105740 2176439424 a OS/2 Boot Manager
/dev/sdb3 ? 1769087090 3538458322 2782517636 6f Unknown
/dev/sdb4 ? 0 3519196159 1191882752 a OS/2 Boot Manager
Can someone explain to me if this is possible using only formatting option linux?
I’ve made a copy of the DSO disk image if ever come back corrupted.
Let me start off with I love the simplicity of the UI design and greater implementation of button functions, granularity of controls and modes of operation. It truly makes this device more functional. I, personally, like this layout far more then other designs developed by others.
I recently downloaded and installed the community app version of the software for the DSO 203 from the pmos69 github site. The files I installed were: Community App v 1.29, FPGA files 2.61 ADR and BIN, and Sys version 1.50 1.6. I loaded these files from a Windows XP machine. I own a 2.72 unmodified version with the 8MB flash memory chip.
On my DSO I was able to load all files sucessfully (ie copy the files to the DFU, it reboots and shows up with the *.rdy) with everything functioning as as expected however, I am unable to save the settings to the internal flash memory. It appears as if the community SYS file will load properly but does not address the 8MB flash memory properly. I can pull up the save function from the app and it states that the setting were saved however when I reboot all settings are returned to the default. If I install the vendor provided SYS file the flash memory is addressed properly and shows up as it should however it completely disables functionality of the actual application. Looking through the forums I though I saw someone saying that this issue was resolved so if someone can point me in the right direction it would be most appricated.
This is more of an inconvenience at the moment as I am not trying to save and retrieve working data from the scope as of yet and reconfiguring the scope each time I boot it up is getting me more aquainted with the way the menus and functions are laid out however, at some point I would like the ability to both save the settings and data. Thank you.
I tried using AlterBIOS v3 and v4 and while both of those loaded sucessfully I still am having the same issue as before where I am unble to save to the internal memory with either version loaded. I also tried Wildcat v4.1 and was also unable to save under either version of AlterBIOS. The internal memory always shows up as a 2MB unformattable disk on the Community verison and AlterBIOS v3 and v4. I can confirm that when I load the manufacture software, the internal memory does show up as an 8MB formattable disk. I also noticed that my DFU is version 3.12c. I dont know if this changes anything or not.
Judging by recent posts, there seems to be some confusion as to software/hardware
compatibility as it relates to file functions.
First of all, it’s important to use the proper SYS version for the hardware. The version that
came from the factory is the correct one, and should not be changed. Hardware V2.72 AND
UP needs to have SYS V1.60 AND UP (use the one that came with the device, info on this
can be had in the WIKI <LINK_TEXT text=“http://www.seeedstudio.com/wiki/DSO_Qua … g_Firmware”>http://www.seeedstudio.com/wiki/DSO_Quad:Upgrading_Firmware</LINK_TEXT>)
From hardware 2.72 and up, the devices have 8MB drives, and SYS files PRIOR to V1.60 will
NOT support them. The Alterbios plugin is for versions PRIOR to V2.72, and MUST be used
with these to properly support the 2MB drives. It should NOT be used on versions 2.72
and later. It can be removed by reinstalling the correct SYS version, which will overwrite it.
Secondly, for 8MB versions (V2.72 and later) the program version used must be of a version
that supports the 8MB drives. Early factory APP versions, as well as early versions of the
community app and Wildcat versions PRIOR to V3.2 did NOT support 8MB drives. The later versions
support BOTH 2MB (with the Alterbios plugin) and 8MB drives and can be used on any
hardware versions, with any SYS versions appropriate to the hardware.
Third, the drives must be properly formatted, the 2MB versions with 512 bytes per sector, and the
8MB versions with 4096 bytes per sector. The file system used is a Microsoft format, and is
best to format the drives on a Windows machine. There is info on the WIKI of using Linux that
may be helpful.
If all 3 of these conditions are not met, you will get file functions that work sometimes, not
others, corrupted BMP’s that show half the screen, or work with the device but not on a PC
connected via USB, or corrupted config files that cause the program to malfunction, etc…
Thank you for the clarification on this. It was my suspicion that the sys file was the issue however looking over pmos69’s github page I see where I made my mistake. It states on his page that the community sys file “v1.5 1.6” is required for the app to function properly which as far as I can tell is accurate. I thought I saw back a few pages where the file had been updated and modified to work with 2.72 8M devices. While you can load the “v1.5 1.6” in a 2.72 8M device and it does function and you are correct that it does not allow you to address the 8M flash memory.
In following your instructions I reloaded the manufacture sys (v1.60) and loaded Wildcat v4.1 community app successfully. I am currently looking over everything and I must say I do like the whole interface. I have been able to successfully save the config file properly and am looking over a lot of the other functions via the provided help file; very well documented. I will start working my way though the calibration section and other functions, hopefully, later today.
I also tested the app on pmos69s github with the manufacture provided sys file and can confirm that it does not work with that sys file. You are unable to select/adjust the volts/div setting and the time/div. I though this might have been caused by an incompatible file being loaded so I formatted the 8M drive and rebooted with the same results. At that point I stopped testing and reloaded Wildcat v4.1.
As far as using linux to format the drive you should be able to do that. While I am no linux expert, doing some searching around it appears that you can use the mkfs.msdos or mkfs.vfat program with the -S option to set the bytes per sector size as per its man page. If someone were to want to attempt this I would suggest lots of research, probable advice on linux forums and, of course, caution. The syntax of the command looks fairly straight forward as well. Other programs such as parted/gparted (GUI based version of parted) should be able to do this as well but I do not see where you can set the bytes per sector option.
Was looking at the customizable meters features. Not sure if there is a bug in the Wildcat 4.1 programming or user guide needs clarification. The default meters do not seem to be customizable. Undocumented access to customizable meters requires LONG-PRESS of the LEFT-Toggle switch first.
User guide says to LONG-PRESS RIGHT-TOGGLE to change focus from menus to meters. Doing this does not provide access to changing SOURCE with BUTTON-4, or changing meter items with LEFT-TOGGLE. To access customizable meters, you must first LONG-PRESS LEFT-TOGGLE.
PRESS and HOLD RIGHT-TOGGLE, locks ON user feedback beep sound. Requires reboot to stop continuous beep noise.
Revision(W4.1) by Wildcat
AlterBIOS 0.4 OK
Hardware Ver V2.70
SYS Ver 1.52
GCCv1.7W4.1 APP(2.51+SmTech1.8+PMOS69 fixes)
Loaded configuration file
The user guide probably could elaborate a bit more on this:
The left toggle LONG PRESS (release after beep) CHANGES the meters, cycling through 5 presets.
One of these presets, which shows, in small meter mode, 4 meters in cyan (ch A color) and
4 meters in yellow (ch B) CANNOT be changed. This non changeable preset in LARGE meter mode shows
2 large meters along with 4 smaller ones. Also if digital meters are on, with small meters this preset will
display 2 meters each from all 4 sources.
Further long pressing left toggle will then cycle through 4 more presets, each in one of the channel’s color
(cyan for chA, yellow for chB, etc) which ARE customizable. Presets for ch C and D in small meter mode
contain a mix of the 2 channels as there are not enough items to fill each page. Once on one of these
4 customizable pages, long pressing (release after beep) RIGHT toggle will shift the blinking item to the meters.
Change selected meter with right toggle (right/left), and meter item and source with left toggle (right/left) and
Note that any changes to any of these meters will revert to the default items and sources after selecting
another preset, so custom meter settings can only be made to one preset (or “page” as described in the guide).
To save this preset simply save to one of the configs while the “custom” preset is showing and it will be
restored on recall.
From what I can recall, this was pretty much the way the program worked originally, I didn’t make any changes
relating to the way meters are selected, other than add the large meters. Seemed OK, didn’t see a need
to change it.
In short, if one of the customizable meter pages (or preset) is displayed, LONG press (release after beep)
right toggle should cause one of the meters to start blinking, after which it can then be changed with button 4 and
left toggle (<left/right>).
Center pressing and HOLDING right toggle should toggle MIN/MAX HOLD on and off, with a notification showing
to that effect and any MIN or MAX meters changing to white. It should not lock the beeper on. Is it possible
that a config file from a previous version is being loaded on bootup? This could be the case if no config
has yet been saved with the new version. If so, try saving and restarting. If it still does this, let me know
with which menu settings it does this, as I have not been able to reproduce the problem.
Yes, RIGHT-TOGGLE LONG-Press does toggle MIN/MAX HOLD function on my DSO, but is also initiates a continuous beep noise. I just tried toggling the hold function ON/OFF and found out that turning it OFF does stop the continuous beep noise.
I deleted my WPT file and the beep problem went away. Apparently it was corrupted in some way. Unfortunately, I will need to recalibrate the analog channels again in order to create a new WPT file.
Thanks for the replies.
Wow, that’s too bad, because now I see what what causing the problem. Hopefully you have saved the WPT file because
it was not caused by that…
When engaging the hold function, it also engages the alarms, this is explained in the guide in -MIN/MAX METER HOLD MODE, ALARMS. This allows setting of V1 or V2 so that if the voltage exceeds V1 or falls below V2 the buzzer will sound…
Either V1 or V2 were within or below/above the trace area, turning on the alarm. When you deleted the file it likely moved
the cursors away from the trace and shut off the alarm.
From your original post, I thought you meant the beeper was running on and couldn’t be stopped…
I also want to mention that if you did not keep a copy of the WPT file, but you still have ANY of the CFG files, even
from prior versions, all the calibration info is saved in those as well (at whatever time that particular file was saved).
You can just take one of those, and rename it to XXXX.WPT to restore the data.
Wildcat thank you so much for your firmware. I’m a newbie on the DSO so i have to experiment more to find any issues but i’m running hw v2.81 and it works without any problem! Just a question are you aware of CHIPP’s firmware? It is a russian one and i’m not sure if it is still in development/support 8mb hardware…
You can have a look here: http://kazus.ru/forums/showthread.php?t=100175
and here for the documentation: <LINK_TEXT text=“http://kazus.ru/forums/attachment.php?a … 1371996922”>http://kazus.ru/forums/attachment.php?attachmentid=48395&d=1371996922</LINK_TEXT>
Maybe you can see other features that you want to implement, like the video mode which i believe you don’t have (sorry in advance if i am mistaken)
Also any words on doing and optimised V4.1 that takes more than 4 slots? On my hardware the only other useful program that works and it is installed in slot 4 is quad pawn…Maybe you can utilized the hidden rom of the new devices? Or there are more to it?
That’s good to hear. Yes, I did backup my files before deleting them on the DSO’s flash drive.
I hadn’t seen that about the alarms. I had only thought V1 and V2 were used for waveform measurements with delta-V. Moving them both to top and bottom per the guide does stop the alarm.
In moving V1 and V2 up and down while MIN/MAX HOLD is ON, they seem to only alarm for CH(A) waveform. I see you need to Short-press button 4 when menu selecting V1 or V2 to change V-source and MIN/MAX alarm from CH(A) to CH(B).