| Products > Test Equipment |
| SainSmart DDS120 & DDS140 USB Oscilloscope |
| << < (31/84) > >> |
| ganzuul:
I have made some progress. MinGW is needed in QtCreator on Windows. Ran into what appears to be a bug which will have me compile QtCreator itself from source. Going to take a break now, so I'm documenting here. fftw3 needs to have its .lib file created as per its README-WINDOWS, which involves telling the console 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin>vcvars32.bat' before running the commands. Just noticed I have the 64 bit version when I ought to be targeting 32 bit. You can get the precompiled fftw3 package from here: http://www.fftw.org/install/windows.html I was testing with a 'libusbx' version, which actually appears to be deprecated in favor of http://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.18/ This package already contains the needed .lib file. I changed some directory names around while trying to figure out the strange errors I saw earlier. When hovering over a line like #include <libusb-1.0/libusb.h> QtCreator's tooltip pop-up should tell you if it sees the file. --- Code: (".pro") ---# Configuration CONFIG += warn_on \ qt QT += opengl printsupport LIBS += -LC:/Qt/lib/libusbx/MS32/static/libusb-1.0.lib -llibusbx INCLUDEPATH += C:/Qt/lib/libusbx/include/libusbx DEPENDPATH += C:/Qt/lib/libusbx/include/libusbx LIBS += -LC:/Qt/lib/fftw-3.3.4-dll64/libfftw3-3.lib -lfftw3 INCLUDEPATH += C:\Qt\lib\fftw-3.3.4-dll64 DEPENDPATH += C:\Qt\lib\fftw-3.3.4-dll64 --- End code --- Adding the MinGW build option to QtCreator's Projects profile (left sidebar) isn't straight-forward. There is dark grey rectangular box with a toggle switch in the upper part of the view, which shows a little white triangle in a grey circle when you hover over it. This is the menu item which becomes active once you have cajoled the Manage Kits button to its left into letting you use MinGW. QtCreator comes with a version of MinGW included, but they seem to be recommending a different version: http://qt-project.org/wiki/MinGW |
| mmark:
--- Quote from: ganzuul on November 10, 2014, 01:40:19 am ---You are a rock star! :clap: Compiles with QtCreator at the click of a button, once the build path is defined. This is on Ubuntu 14.04 LTS. Amazing update rate... This is so cool! ;D I'll try to keep up with you... and contribute something useful. lol. --- End quote --- Thanks, but I just put the stuff doctormord and psynapse discovered and documented into the code written by oliverhaag, so they deserve most of the credit! :clap: Did you also see the issue of the non continuous time which the large buffer size? To see it, please set the buffer size to large and the time base to 1ms, connect the probes to the 1khz source and look at the right side (around 8.4ms) of the DSO display (see attached image between marker 1 and 2). Also, how should we name this, OpenHantek is not really appropriate anymore? OpenSainSmart ist long, so how about OpenDSO? Any other suggestions? mmark |
| doctormord:
This behaviour can be also seen within the original software with timebases 5ms+. I would guess, that the transfer makes the scope blind at this time, so data is missing there. What about contributing the code back to OpenHantek? There's an OpenDSO project already, what about OpenBuudai, as this is the initial source (Chinese student i guess)? From the screenshot, you got alot more noise on channel 2, i have the same result on channel A after resoldering the CYPRESS back to the PCB. I suspect the Tantal-caps to influence this as they got alot of heat at the de-/resoldering process. Regards, doc Edit: Will try to run on Xubuntu 14.04 in VMWare Player 6.0.4 on Windows 7 host system. Edit2: Worked - once. Then i hit the stop button and now it does not work anymore. :-// (Replugging did not helped) Edit3: Recompile fixed the issue, but i guess, the problem is not related to this. Regarding the large buffer issue - see the second attached image. Display is like within the original software. My guess, there's not enough data coming from the scope to construct a full frame, so an additional frame-buffer needs to be created to construct a full frame. My intentional idea was not to belong on the scopes timebase setting but rather sample at fullspeed and do the "downsizing" in software to overcome this problem and having alot data to antialiase. |
| mmark:
--- Quote from: doctormord on November 11, 2014, 06:44:14 am ---This behaviour can be also seen within the original software with timebases 5ms+. I would guess, that the transfer makes the scope blind at this time, so data is missing there. What about contributing the code back to OpenHantek? There's an OpenDSO project already, what about OpenBuudai, as this is the initial source (Chinese student i guess)? From the screenshot, you got alot more noise on channel 2, i have the same result on channel A after resoldering the CYPRESS back to the PCB. I suspect the Tantal-caps to influence this as they got alot of heat at the de-/resoldering process. to run on Xubuntu 14.04 in VMWare Player 6.0.4 on Windows 7 host system. --- End quote --- Hmm, the "glitch" only appears at sample position 1024 (2048 bytes). If I read 32678 bytes, than the first 2048 are continuous in time and the last 30630 as well. If it would be some kind of blind phase during transfer I would expect a repeating pattern? For me it more looks like that the scope starts reading at position 1024 and the first 1024 samples are 'old' (or vice versa). I guess we need to look into the 8051 code to really know what's going on... And I could not see this in the Rocktech software? Did you see this with the Rocktech or with the SainSmart software? I though about merging my changes back into OpenHantek. But the code does not really support two different scope families. The author tried to create some hardware abstraction by moving the hardware access code into separate classes, but there are a quite a few places where I had to make changes to code outside of those hardware classes to make it work with the DDS120. Those changes will most probably break the code for the Hantek scope(s). And since the last commit to OpenHantek was from early 2011, I don't expect to much interest or help from the original author to clean this up. Let's see what the other guys think about this... Regarding noise: I think there seems to be a bit more noise on channel 1 in the picture, but not a lot on both channels (more or less only +/-1 bit, which is to be expected)? |
| doctormord:
+-1bit.. Please note, that the scope is already putting out 7bits only when DC-coupled. Lets see in Rocktech/SainSmart - screen buffer fills up after a short period of time. @jimon, could you provide your software-release to the public, as your version seems to be different to the all known 1.2 rocktech/sainsmart version. Edit: Start/Stop at openhantek f*cks up the device somehow. (data timeout) |
| Navigation |
| Message Index |
| Next page |
| Previous page |