DSO Quad engineering sample bug and firmware upgration

I actually enjoyed reading your post and there is no reason to apologize for anything, but I still thought it appropriate to point out that these are your speculations and in no way does it reflect my intentions. No hard feelings!

Keep in mind also that this scheme can work in several ways. As it is now a developer may not be able to even run his own creation unless he has prior approval (license) from Seeed subject to whatever terms they see fit. This is in contrast to the Nano where a developer might create his own licensing scheme (including key generator) and assume full control without any interaction with Seeed whatsoever.

As you pointed out, licensing may not be such a bad thing if used in a sensible way. In this respect I have no reason to believe it will be used in any other way. Quite the contrary, I would say Seeed has been more than willing to listen to and encourage customer input such as with hosting and supporting this forum. With this and their hardware design skills I’m impressed, but less so with their ability to develop quality software.

I got my Quad today; Thank You SeeedStudio! It does have the power switch slider, the silkscreen is still wrong and the firmware is Sys v102 = 1229_sys.hex and App v201 = 0106_app.hex.

Attached is a listing of my virgin Quad USB files. I renamed the 1229_sys.hex file to 1229_sys.xeh and rebooted the Quad and it came up properly. I just wanted to make sure that file was not used as a license; it appears not to be necessary. I even tried to boot the reloader and it simply reported that no update files were found.

Nice find on that pressing the arrowed slider for USB only!

Turning on my virgin Quad with no buttons pressed reports “enhanced hardware version” same as the power up with “s”, “m”, and 'F" buttons pressed. Of course the button power on’s are dead with no app present.

Since we are all guessing, my educated guess is that the 0118_app.hex update forgot to provide or forgot to match the associated license for that app version of install. Another guess would be that for some reason your 0118 update got into one of the button memory slots instead of the default memory slot.

You might roll back and try the 1229_sys.hex and the 0106_app.hex to see if that fixes it. You could then try 0115_app.hex and let us know what happens. This of course assumes that the 0118_FPGA.bin upgrade has no impact upon the original factory firmware.

Does anyone know where to find the original xxxx_FPGA.bin file?

As for the attachment below, my system does display hidden files and system files so I suspect that there are no hidden files; but there is always the possibility of a table entry in the volume partition that would not show here.

I just loaded 0115_app.hex without incident. Then I loaded 0118_app.hex by itself and all appears normal. I went back and forth reloading these two versions without incident. I have not attempted to load 0118_sys.hex yet. One trick that I use is to rename the file extension .hex > .xeh so I can keep the file on the USB drive and go back to it later if needed. Only rename to .hex for the upgrade that you want to load. The reason that I reverse the file extension characters is so I don’t have to remember what it used to be. Just reverse again to get back.

The file save is fixed for BMP and the “m” key now saves the current configuration (screen reports “save current settings” unless you have “savefile” displayed). Even with “savefile” displayed, it still saves the config but doesn’t report it. The screen brightness, sound vol, and increased capture buffer scroll speed works in both updates. There must be something else changed in 0118 that I haven’t noticed yet, or it needs 0118_sys.hex to show those displayed changes, or they are non-visible fixes.

I created a dummy .dat file and saved a .dat file. Does anyone know what format this is? What program can view it? It is the same size as the .BMP files so it must be some variation of screen capture.

After using this for a few hours I have another suggestion … another suggestion … another suggestion … sorry, the flashing got to me! Those flashing cursor positions get to be quite irritating. Why not just use the black background for the selected item (without the flash). This way the color is still present on the text for that channel and the absence of background draws your eyes to the correct cursor position without the flashing. I understand that the color background makes the text easier to read, but that incessant flashing may lead to a seizure … a seizure … a seizure.

Now if we can just get BenF’s capture buffer fixes and the ability to save the capture buffer, then the Quad would be usable although not as user friendly as the BenF firmware has become.

More info to add for those that are interested. These results were found using 0118_app.hex update only with the original 1229_sys.hex from the factory. Because of justblair’s negative experience in previous post, I am holding off on the 0118_sys.hex and 0118_FPGA.bin updates.

Channels A & B can simultaneously display 3.546Mhz square waves (which is 10% of the Max sample rate of 36MS/s) with reasonable shape. This indicates that the 36MS/s is not divided while using channels A & B simultaneously. Hiding channel B appears to have no effect on the displayed sample rate resolution of channel A.

It appears that the Quad has 3-each range scales for each channel A & B. This was determined by noting that the frequency compensation for .2 & 2 were different than .5 & 5 and different from 1 & 10 V/Div scales. There are also six adjustable trimmer caps under the battery that could be frequency compensation for each range. These range compensation differences were observed while looking at a 3.546Mhz square wave signal. At the risk of being wrong, it appears to be reasonable to conclude that the same range scales will be used for the 20mv, 50mv, and 100mv respectively when the opto coupler is installed. Further conjecture would be that the opto will merely bypass or add a gain adjustment resistor for each of those ranges.

Signal generator square wave output is firmware unlimited but only reasonable up to 200Khz. The sine, saw & triangle waves are firmware limited to 20Khz or less and reasonable with 1.4us steps observed. The output square wave frequency up to 8Mhz appears to be accurate in frequency using the Tektronix scope as reference, but the square wave appearance is long gone.

Chanel D is where the math functions [+/-] for A & B can be displayed. It can also display logic functions [and/or] using channels C & D. It also appears to have File_1 thru File_4 display capabilities but I have found nothing published on this topic. I have tested the A & B math functions and they appear to be normal. Have not tested the TTL logic math nor the C & D channels at this time.

The XPos has a peculiar slow down rate only as you approach the default position.

The time cursors measure 282ns (3.546Mhz) while my Tektronix measures 301ns (3.318Mhz).

One thing still missing is the ability to display measured frequency (must calculate using T1 & T2).

0118 hex and fpga worked absolutely fine for me. There is a later update that didn’t go so well. I did not post the files here but I linked to the forum post on the miniDSO I think…

Firmware Update — FPGA_2 .22-SYS. V1.2-APP.V2.1, this one went pear shaped for me!

You say opto? I have only seen this listed as “opt”. It’s most likely short for optional.

I got this working… If you save the waveform as a DAT file and then load it back selecting File_1 superimposes the Channel A waveform from the saved file… File_2 Channel B and so on… I uploaded file templates on page 2, about halfway down which need to be loaded onto your quad…

Just to clear the air, the above quote from ESP is opto-coupler. These come in two basic package formats. One is called a CMOS analog switch, and the other style just has an input diode and output transistor for each stage. In both cases optical coupling is used to isolate the controlling signals from the switched signal. I suspect they are having a supplier/vendor problem with this part.

Thanks for this information. It sounds as if the file is superimposed upon the channel and that is why I didn’t see any change. I will try again and change the T/Div after the save and before the reload.

One more suggestion concerns the menu sequencing. As the menu falls down the right side of the screen, it would be less confusing if the “delta-V” and “delta-T” items were at the bottom of this right panel list. Then you should have the T1-T-2 choices scrolled next, and then have the “Save File” sequence next for the arrows jog switch. Then scroll back up to Channel-A. This would eliminate all that unnecessary jumping around of the display as the menus are scrolled through.

One other possible fix is to color “delta-T”. “T1”, and “T2” orange (not white) to reflect timebase association.

Due to cost and difficulty, we are not doing Android compatible version in the near future. How about a Bluetooth DSO for Android devices?

Missed the discussion during Chinese New Year~

About the license: I would consider myself among open source fans, and Seeed Studio is built for facilitating open hardware. The license idea is not to pullback open source but trying to invite more interesting apps. The designer could surely choose to open source freely as before, while dual-licensing could stimulate the process, as an option.

On the other hand, since the open source works like BenF stimulates DSO Nano sales and providing a much better user experience, Seeed real need to prepare a channel to thank open contributors. It might be converting download counts or direct donation. Check out this post, How do you guys think?

p,s. Please don’t worry about the count down, PM me with your hardware SN, I will generate the activation code.

a bluetooth DSO quad would be the berries (the bandwidth hit would even probably be ok…). What would it take to get a project like that moving?

Hi

A bluetooth DSO with a android app would be so cool with high screen resolution and stuff. Don’t know if the “coolness” is worth the price? Is the bandwidth enough? I guess all data handling and trigging would have to be done in the DSO and android app would just be a display device? Do maybe it wouldn’t be so damn hard to convert a nano or quad to a bluetooth DSO if the screen data is available as a serial stream? Btw, then we would miss all the cool features and lose its point if it would just display exactly the same as a normal nano or quad

Btw, can you tell us how many nano you sold or is it a well kept secret? Would be interesting to know Especially with a discussion about open source contributor feedback in mind.

The front end is already out there…

one example:
android.serverbox.ch/?p=213

or another lower res example:
projectproto.blogspot.com/2010/0 … scope.html

all these being open source makes it fun to tie them together.

Granted I own a DSO nano 2 and am patiently awaiting a DSO Quad, but there is sometime interesting to a solid piece of hardware which could be made display agnostic. Besides who wouldn’t want to have their oscilloscope front end be on a 7" or 10" touch screen…

Cool! The android UI look so sweet, just think of the quality feeling it would give the nano or quad if the native UI looked like that, it would bring the DSO market to the next generation for sure

This is my first post here. I am eagerly awaiting my quad beta - ETA March.

On the subject of using an external display, I have to say this has some merit. But it’s probably smarter still to walk before running.

What we need is an “Interface Design spec” for two files.
Output file - where parameters which have been sampled go; and
Input file - parameters to control the Quad go.

Initially the files can both be accessed externally using the USB. The external host just needs to be able to access the USB file system, so it could be any garden variety Linux, Mac, or MS based PC. Latter on you could add on bluetooth access to the file system if you want, though this may be a bit more tricky.

both files could be a really simple format CSV, eg:
output:
time, a-value, b-value, c-value, d-value
input:
time-scale, a-scale ,b-scale, c-scale, d-scale, sample-rate, etc

These files are very simple because at least in principle the host is doing all the hard work to display the data, and the quad just needs to write the nearly raw output from the A/Ds. Obviously the file formats will need to be adjusted when doing signal generation.

The output is continually written to by the quad during normal operation and read continually by the host. Input is normally written by the host when the user selects a new scale or whatever. The quad could poll the input file or more efficiently - just read it when the saved date/time changes.

As file accesses is handled on the host by the host OS, the quad application (running on the host) is really just a gui for displaying the data and controlling how it is displayed. Potentially it could be written as a Java application which can run on anything.

The only issue is that this approach has already been done. Just google “digital oscilloscope computer”, but not at a price that competes with the quad. It least if the quad approach is kept open source.

I have the original LCD scope and have ordered the Quad beta.

Given the fantastic new speed of both the ADC and the CPU, it seems realistic to think about a spectrum analyzer as well as a scope. Codespace might require that only one or the other be loaded, but this could easily give you a 36 MHz spectrum analyzer using direct sampling and no other hardware.

Leigh/WA5ZNU

Hi

Any news about the development, latest FW etc. ?

A week ago, we had some news on the blog: http://www.seeedstudio.com/blog/2011/03/08/dso-quad-shipping-delay-notification/
But no update till now… and it’s a long time for people waiting.

Back Panel Arrived… Assembly still on going. Sorry for the delay!

Hey, just keep us in the loop, and we will be happy. I also want a good product, so take your time, and get it right

David

ok ! keep us informed ! how many orders do you have ? is it more that 300 ?