I have just get MY new DSO QUAD and I find out that there is no XY function or I can’t find it jet?
This function is very important for me…
I did as what is instructed, the first time I powered up after formatting the flash prompted me with reload parameter error, then I did the usual enabling and disabling of channels. After that I pressed the “o” and then turned it off.
When I turned it on it is OK now, I think this has fixed my problem. Thanks
To put this another way, look at the following YouTube video I created for the Nano, look at minutes 8:00 - 9:03 and you will see how the Nano saves multiple configuration files to the SD card for recall later. This allows multiple unique settings to be recalled by filename. In this analogy, Flash is the current Quad configuration save, and we are asking for additional file saves of configuration data.
youtube.com/watch?v=tS3mmZO0MrQ time 08:00 thru 09:03
Hope this helps to clarify.
Now to take this to the next logical level, let us rename the numerical file names (saved by the Quad) to 8 character file names with the same extension while the Quad SD card is seen as a drive to a PC. For an example view the following video at time 03:16 thru 04:00 to see how the Nano does this. The PC can change the numerical file names saved by the Nano to alphanumeric file names, renamed using a PC and the USB link.
youtube.com/watch?v=Y6M4lG14O4U time 03:16 thru 04:00.
The Nano uses the same family microprocessor as the Quad, so it should be done on the Quad too.
Very nice, Lygra. I have see your vids before. Where did the code come from that added this multiple saves of configurations, or was it an original code that didn’t make it into the Quad. Just for ref, I know nothing about coding or…
Lygra … Am i missing a trick here … is there an SD card on the quad, what size and where does it go.
One of the reasons that BenF gave for not being able to save large export files was due to the limited size of the internal memory AKA flash drive. If this can be made larger or better still an exposed SD card slot we could actually have several sets of configs made portable on the SD cards. I can see me with a library of saved waveforms and settings on different SD cards.
CHeers Pete.
The title of the video includes the BenF version updates. BenF added this to the Nano after the factory failed to do same. I believe the file renaming using a PC was made in v3.21, but I am not sure because I only got involved after v3.40. The current Nano BenF version is v3.62.
Unfortunately the Quad development was hardware orientated and no attempt has been made to adopt the Nano firmware development concepts in the Quad as of this date. That is a shame because the Quad is that diamond in the rough without the features that have been added to the Nano.
My poor choice of terminology. For want of a better term I refer to the internal serial memory chip as a virtual SD memory card, and that serial memory chip is only 16Mbits = 2Mbytes. The Quad firmware emulates an SD memory card reader (2Mbyte) to any PC connection while the Quad is in normal mode of operation.
The Nano has an internal Flash memory plus a plug in SD memory card slot for cards up to 2-Gbytes.
Unfortunately the Quad design chose small over functional and had not enough room for the SD card. I am sure they were also trying to keep the cost down. This has resulted in serious memory shortage for typical DSO o’scope uses such as saving multiple capture buffers and multiple configuration sets, not to mention BMP screen saves.
If you can live with the Nano narrow bandwidth, it is a much better product than the Quad when the Nano is using the latest BenF firmware updates. Hopefully Bure and associates will take heed and update the Quad to include a new software trigger system that works properly and to also incorporate the BenF features that already exist in the Nano. I have said all this before, but maybe persistence will prevail. It just doesn’t make sense to totally ignore 6-months of firmware user interface development on the Nano while creating the factory Quad firmware which uses the same processor family. 
It might make sense if the “factory” is just one guy. If you look at the chinese web site where this product was developed, seems it is just one designer with the hope that the open h/w would attract users to contribute to the open software.
BenF did a great job with the Nano. Maybe he is working on the QUAD version…
Users who want to develop the firmware features are right here. The only obstacle: the product, as of right now, is closed source. (To be fair, HugeMan says he might be able to get the source released at some future date.)
And yeah, I’m following http://www.minidso.com/forum too.
I meant this: ourdev.cn/bbs/bbs_content.jsp?bb … bs_id=3053
I also thought the earlier versions of the source were released…
You thought correctly. I’ve been working with the old code.
I can’t say all the available developers think like me, but I’ll not be releasing any features, fixes, or ideas as long as:
-
The only code available is outdated, known-buggy code.
-
The latest source code is missing.
Why?
-
I don’t want to release sample builds that have new features, but still have existing bugs simply because I’m some sort of lower class citizen in this community. And, if I fix the bugs, my fixes will be different, and probably wrong. I don’t want to end up in competition with the official devs trying to fix bugs. Finally, when I have questions about the code, it will be more difficult to coordinate with the official devs, since they aren’t really working with the same code.
-
I don’t want to work in a closed-source community. And this, to me, is closed source.
Caveat: the code is still being worked on, so maybe there are some delays. That indicates alpha code and a still-developing community. It effectively limits the rate of growth, maybe that’s intentional. When the code is available, then look for faster bug fixes and better features.
Appreciate your desire to help.
tgo,
Just a thought, the current source code (APP_235, SYS_134) is not particularly complex, or well written for that matter (chuckle). It would be not so difficult to simply write these again in a similar way that BenF has done with the Nano. BenF’s APP_313 appears well coded and well structured, as professional software development should be.
Now it would be great not to have to re-invent the wheel for the Quad DSO since BenF has already progressed so far with the Nano. Looking through the APP_313 source, there are many, many coding structures that could simply be ported directly to the Quad DSO, and then built upon in order to suit the Quad DSO. The other nice thing with this is that there would be consistent features and usability between the Nano and the Quad DSO.
So I would ask, how about it BenF? Are you prepared to share the source code for v3.62 under the basis that it is to be ported to the Quad DSO and then developed to work with that hardware, by those people that would like to take it on?
The comment that the Quad DSO is a “diamond in the rough” I feel is correct about the Quad DSO, and after looking at the hardware design and currently available resources, it has a lot of potential but is not there yet 
.
I’ve never tried to get in touch with BenF, but I’m willing to try using his APP_313.
I didn’t realize he hadn’t released APP_362 yet (or is it called v3.62?). That’s too bad…I’d really like to think he’s more open than that.
If we make good progress from APP_313, when (if?) APP_362 is released the delta won’t be too hard to incorporate. Well, that’s assuming there aren’t huge changes from APP_313 to APP_362.
I agree that the DSO Quad is a diamond in the rough. I’m currently spending my time working with the FPGA source code, since it is the latest version. I may have something interesting there in a few weeks – spectrum analyzer anyone?
Agreed, APP_313 could be the basis of a good structure for the Quad DSO. I would just like to see if we can do this in colloboration with BenF, if he is willing, as I see the changelog progressing to APP_362 has a lot of useful developments and resolved issues. The most ideal of course is for APP_362 to be the starting base, but let’s see what BenF’s comments are.
Now a spectrum analyser app for Quad DSO would be very interesting and exciting . I would like to see us develop that as well!
I look forward to your FPGA developments . Let’s see if we can’t turn the Quad DSO into a very handy all-in-one field instrument (a bit like Doctor Who’s sonic-screwdriver LOL!).
As you may have noticed, I have been an avid proponent of the BenF software incorporation into the Quad. I am not a C-programmer, just assembly language programming experience. I could negative-test and evaluate new releases and if needed I could rewrite the User Guide for this V3.xx implementation on the Quad ( I have technical writing experience and training). If you haven’t already, you should read the first few pages of BenF’s User Guide where he points out numerous major flaws of the original Nano factory code, and those same flaws appear to be in the Quad factory code.
I can not speak for BenF, but assurance that he will not be involved with the details of the adaptation may be helpful. He has made it crystal clear that he no time nor inclination for teaching programming to novices. It sounds as if you and Tgo are also experienced and professional C-programmers. It seems reasonable that BenF doesn’t want his work adapted with poor and non-professional structure. For examples of this non-professional approach, just look at the factory code for the Quad.
It would be my expectation that if you and Tgo were to contact BenF directly (private message), describe your coding experience, and agree to take the responsibility for this Quad adaptation; then BenF may at least consider it.
If BenF will not agree to a limited release of v3.62 source to you folks only, then the 3.13 adaptation may be necessary to put your code where your mouth is (so to speak). BenF may respond to that V3.13 adaptation in a positive way.
Which ever code is adapted, it is important to keep an active thread comment trail for all changes just as BenF has done for the Nano.
As I said earlier, I certainly can not speak for BenF. I am just trying to throw out some solutions to this problem of adapting the Quad to the BenF firmware. As I said earlier, I too will contribute in any meaningful way to make this happen. My Nano videos and Forum posts demonstrate that I will perform and not just talk about it. Count me in on this project.
lygra, you’re welcome to do anything you feel inclined to do. For example, I’ll probably focus mostly on the lowest-level stuff (FPGA and SYS) because that’s where my interest is right now. Not that I won’t be able to help port BenF’s app, just that’s how I’ll approach it: try to work out the low-level issues first.
Right now, I’ve made some steps toward re-writing the manual here: http://garden.seeedstudio.com/index.php?title=DSO_Quad_Manual_%28by_the_community%29
DaveLyons made some minor edits, so I’m hopeful people will like where I’m going with that.
Can you give me some feedback? The document peters out toward the end, but how is the beginning? I’m targetting a “print media” format, which is why I’ve resisted including video tutorials.
I haven’t finished it because I got busy with the FPGA, and because the next part I wanted to write (calibration) was being modified as I wrote. Someone also mentioned http://hifiduino.wordpress.com/2011/04/30/dso-quad-quick-start-guide/ which has some great ideas for how to do calibration. So, that’s kind of where I got.
I figured the manual should explain common tasks, like measuring a digital signal, an analog signal, and using Ch(A) as a trigger for Ch(B). I haven’t written that yet.
lygra,
All very good suggestions. I am also pressed for time, but evenings work for me for some development work . As tgo is keen with the low level FPGA etc, I will focus on the APP side, and some on the SYS to support it as well. Your testing, comments, and manual will also be great to get it all moving as swiftly as possible. We seem to be taking our natural positions for the work at hand.
Just to be clear, I was thinking of BenF’s work as a suitable starting point only for the DSOQuad development, as this will save a lot of time in the beginning with suitable coding etc. I was not assuming that BenF will be available, or want to commit any time to the proposed project, unless of course he wants to. Otherwise I can see the DSOQuad development taking on its own particular set of features, interface etc, rather than becoming a faster Nano clone.
I will contact BenF privately to see if he is willing to assist us with a limited release of v362, otherwise we can start from v313, and re-write the current DSOQuad firmware as it should be 
The very best starting point would be, (for maximum startup speed):
- APP_245B and SYS_141 source codes for DSOQuad
- APP_362 and LIB_352 source codes for Nano
All of the original developer wishes to be respected of course, and kept within the project development team
Can you assist with item 1?
I looked over both manual links that you provided. My plan would be to build a Word document and convert that into a PDF file with index and chapter links. This conversion, once automated makes easy updates in PDF format. I have done this before and it makes the PDF document very navigable. With this method, updates can be provided in the popular Word format, yet the final document remains in PDF format.
What you have already done should be adequate until the code change-over takes place. At that time I would be willing to incorporate that info into the PDF format as described above. In the interim, I can write up the measuring examples you have stated and also include hints and tips. Once I publish the first PDF manual, it will have it’s own Forum thread to track suggestions and corrections.
I will create a new video showing how to use the Quad menu system and make it available as soon as I have enough time. Once it is available, you can link this video to your manual pages.
Unfortunately I also do not have the current Quad factory source code. Hopefully HugeMan can come through with this when it is released.
I just wanted to be clear to BenF that you didn’t expect his help unless he desired to provide same.
Do you have some general direction for adapting the menu system? Do you have a Nano v1 or v2 so that you can see how the Nano menu system actually works?