- #SAINSMART DDS140 SOFTWARE DOWNLOAD 6.0V 64 BIT#
- #SAINSMART DDS140 SOFTWARE DOWNLOAD 6.0V FULL#
- #SAINSMART DDS140 SOFTWARE DOWNLOAD 6.0V SOFTWARE#
- #SAINSMART DDS140 SOFTWARE DOWNLOAD 6.0V CODE#
#SAINSMART DDS140 SOFTWARE DOWNLOAD 6.0V CODE#
As I have said before, this code is really the basis for testing firmware extensions to the DDS140, but the bit that I do like is the display rendition (largely not of my making). 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)?Īll (esp mmark), QT has certainly been a learning curve! I see that mmark has been busy too! I have added my current code, so that we can both/all get the best of both/all worlds! I have not tried porting the code to a second machine and have only coded/tried it on a DDS140 (the key dependencies I can remember are QWT and libusb). Let's see what the other guys think about this. 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. Those changes will most probably break the code for the Hantek scope(s). 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. But the code does not really support two different scope families. 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. I guess we need to look into the 8051 code to really know what's going on. 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). If I read 32678 bytes, than the first 2048 are continuous in time and the last 30630 as well. Hmm, the "glitch" only appears at sample position 1024 (2048 bytes).
#SAINSMART DDS140 SOFTWARE DOWNLOAD 6.0V SOFTWARE#
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.
#SAINSMART DDS140 SOFTWARE DOWNLOAD 6.0V FULL#
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. Display is like within the original software.
Regarding the large buffer issue - see the second attached image. (Replugging did not helped) Edit3: Recompile fixed the issue, but i guess, the problem is not related to this. Then i hit the stop button and now it does not work anymore. Regards, doc Edit: Will try to run on Xubuntu 14.04 in VMWare Player 6.0.4 on Windows 7 host system. I suspect the Tantal-caps to influence this as they got alot of heat at the de-/resoldering process. 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 would guess, that the transfer makes the scope blind at this time, so data is missing there. This behaviour can be also seen within the original software with timebases 5ms+. When hovering over a line like #include QtCreator's tooltip pop-up should tell you if it sees the file. I changed some directory names around while trying to figure out the strange errors I saw earlier.
You can get the precompiled fftw3 package from here: I was testing with a 'libusbx' version, which actually appears to be deprecated in favor of This package already contains the needed.
#SAINSMART DDS140 SOFTWARE DOWNLOAD 6.0V 64 BIT#
Just noticed I have the 64 bit version when I ought to be targeting 32 bit. 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. Going to take a break now, so I'm documenting here. Ran into what appears to be a bug which will have me compile QtCreator itself from source.
0 kommentar(er)
