SainSmart DDS120 & DDS140 USB Oscilloscope

[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") [Select]

# 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
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]

You are a rock star! 

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! 

I'll try to keep up with you... and contribute something useful. lol.

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!

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]

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.

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)

[jimon]

@doctormord sure,

I was unable to read default cd that came with a DSO (I simply don't have a cd reader anymore), so I searched for a software online, and found it at http://www.amazon.com/SainSmart-Portable-Handheld-Oscilloscope-Bandwidth/dp/B00FYGEFYM

You can see there at a bottom :

Note: Please download updated software and manual here:
https://s3-ap-northeast-1.amazonaws.com/sain-amzn/20/20-010-730/DDS120_2014_1_13.zip
https://s3-ap-northeast-1.amazonaws.com/sain-amzn/20/20-010-730/CD/DDS120.rar

[doctormord]

Thanks.

Edit:

Seems to be the same as "standard" SainSmart version.

[psynapse]

All (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).

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).  I get over 20 frames per second (single threaded for a dataset of 131kbytes ) and I love the fact that the display has pan in X and Y (mouse drag over the display) and zoom in X and Y (ctrl or shift+ rotate mousewheel over the display)

As with mmark, you need to take ownership of the USB port.

The code is certainly "alpha", and as I said at the outset, it is shared so that we can cherry pick the best bits.  I will be improving the code, and will post a less buggy version shortly.  If you do try it, note continuous mode is not implemented , and X scale and offset are now just done through the mouse.


EDIT:

WHOOPS! Push the single shot for one trace, or dial up a succession of flashes and then press single shot (I did not want to lose control in my code just yet with a continuous mode,  but 99 single shots gives a clear idea of frame rate)

[psynapse]

mmark

mmark, do not underestimate your own contribution to this project either.  And for me Donut6's WX based code still provides the USB underlying layer for my QT5 implementation.

Just reading through the last couple of days of postings.  I am pretty sure that the 8051 firmware itself will not make an intervention once data has started to flow , the fifos are programmed to run autonomously.  However the endpoint FIFOs are 1024 bytes in size, and there are four of them.  So I suppose that at setup time for the transfer, the ring of four might be initialised poorly. Did you say that the system continues just fine after that ? If so I would suspect bad FIFO set-up.  A wild assertion. I am guessing that the ADC is running continuously into the FIFOs and that the firmware decides whether to transmit these to USB.  Badly written code (firmware) could initialise USB transfer and then continue to a FIFO reset .... I guess the FX2 wopuld have already commited to the send.  That is the trouble with the FX2, asynchronous USB engine, asynchronous GPIB engine and  8051

Have you tried running the software with just one go code at the start ? (Or do you do that already)  On the DDS140 and 240ksps (which I think is the same as the DDS120 normal mode), the data keeps flooding in, as Doctormord knows only too well! However I would expect that data to be uncorrpted.

To my mind the easiest thing to do would be to jettison the first 1024 bytes ..... unless we get a good trigger working, in which case they will be critical! (On the DDS140, the first 27 bytes recovered from the buffer are rubbish .... When I get the chance to look at the wireshark traces, I think they are just header information)

And I guess it is the same with your software, when you view the traces of an  identical signal through the two channels, it becomes only too clear the Doctormord is right to be concerned about sampling errors! (see the screenshot) I use a look up table because it is fast (eg)

indx=loop-initial_offset;
buffery[indx]=LUT1[scope_data[2*loop]];

But I have not yet loaded the LUT with all of attenuator, ADC null offset, non-linearity correction , software driven offset and software driven gain!

I also agree with you about OpenHantek and other projects (although I really hate us re-inventing the wheel again).  The more I coded, the more it was clear that that the architectural differences in the hardware (esp the DDS140) make common code very much more difficult.  However I agree completely with Doctormord that we should go "open" when we have something sufficiently stable to give to the community.

Doctormord,  sorry about the Tant, I feel partly responsible for the desolder.  It was a noble sacrifice for the community, thank you.  I guess you have tried tacking an external cap on the board?

[donut6]

psynapse,

Badly written code (firmware)

I may be able to help. I've created a proof of concept sdcc/fx2lib DDS140 firmware implementation if you are interested?

It's badly written, and currently doesn't quite work (probably just an issue with waveform selection). But it does capture data.

[psynapse]

Wow donut6, you're a dark horse!

If yours is a ground up re-write, yes I would be very interested in seeing it.  It would be great to avoid any accusation of plagerism by this group (well by me actually ;-)).  I do not feel comfortable posting my annotated disassembly in open forum (at least until I understand the legal situation), and equally I could well understand if you want to keep your code "pure"  .... I could flag where anomomies lie if that would help.  Does anybody understand the legal position with regard to dissassembled code?

Edit:

Just did a little search

"Now, publishing results of disassembly on blog, that's another thing ...... under European law you can do reverse-engineering, but you may not publish the results. Publishing your source code, that you've created thanks to what you found out, should be completely OK."   Not written by a lawyer of course!  But a useful indication nevertheless.

And also (in the US)

".... Accolade’s “intermediate” copying (i.e., copying solely in order to discover functional interface specifications that were then independently implemented) was a fair use, emphasizing that disassembly was the only way to gain access to the ideas and functional elements .... "

So I guess keeping your code pure is a good idea for all of us.  Would still love to see what you have done though.  My plans were to add two key functions into the firmware.

1) Add an additional command to set a "go code" pending flag.  Then add an ISR for interrupt 5, which would (if the flag permits) issue a go code.  This would provide an external trigger (int5 pin wired to the external socket, preferably through a buffer).  The only trouble would be that data acqusition would start 2 -5 microseconds after the trigger .
2) Add an additional command to write 2 bytes into the RAM copy of the "alternate" wave table used just for mode 0A.  Writing these two bytes will change the sampling rate generated by the GPIB.  I have already verified that this works by patching the two bytes manually.

What method are you using to upload your firmware?  Writing the EEPROM is OK, but leaving the link open and using cycfx2prog to do a direct ram load is much easier ..... but I am guessing you know that!

Great work.  If we could get away from the provided firmware altogether, that would be fantastic.  As Ganzuul noted some time ago , it would be nice to know what that CPLD does,  still something on my to do list. Given that, I am pretty certain we can do a better job than SainSmart

[psynapse]

mmark,

I have just added command 94 0A to my scope software (for the DDS140), that is the 240khz mode that perhaps copies the DDS120 mode of working  ....... and when I start a fresh scan I get 4096 bytes of "old" data at the beginning ...... indicative of poor fifo flushing.  I have tried using codes D0,D1 (which I think are fifo reset and set) and this blows up the scope nicely ... hard reset needed.  So I am guessing that the DDS140 has a similar problem to that you are finding on the 120 . I will look again at the fifo reset firmware.

In the meantime perhaps just ditch the first 2^n bytes, because I at least always get that result

EDIT:  Blast!  I have also seen 3072, more and more like and endpoint buffer issue

[doctormord]

Great discussion.  Here in Germany disassembling someones code is prohibited by law (this also belongs to reverse engineering) AFAIK.

But i would first think about the complexity of the problem and what's the initial intention is to hack something.

I mean, the DDS120 is mainly an FX2LP dev board with some analog circuit.. Nothing special in general.

The firmware, buggy
The software, buggy
The hardware, buggy
...
Linux? Nope!

Claimed to be open source and maker community friendly? Yes..

So, to my understanding, what we are doing here, is, to make things work like intended. )

There can't be much magic in the actual official firmware that isn't covered by the technical references. (I guess)

So, would say, keep it coming.

To be free, an open source firmware, compatible with the official one would be nice. (Advanced and with new magic)

Regards.

Christian

Edit:

@psynapse

I can't extract your scope2.zip (Windows & Linux)

[jimon]

Btw, I've ordered FX2LP dev board recently (should arrive in 1-2 weeks), should I try just to hijack ADC-FX2 traces ? probably it should be simple enough mod.

PS. Will order FX3 board if FX2 board will be successful, but I have a little knowledge what to do with GPIF II

[doctormord]

Let's go! O0

[ganzuul]

\ /

Got it to compile on Windows using QtCreator!

You want this version of Qt and MinGW:
http://sourceforge.net/projects/qtx64/files/qt-x86/5.3.2/mingw-4.9/dwarf/qt-5.3.2-x86-mingw491r1-dw2-opengl.exe/download

See the screenshots for hints. Ask question if it's unclear. This took a LOT of fiddling to get right so I'm probably overlooking something.

Get this version of FFTW:
ftp://ftp.fftw.org/pub/fftw/fftw-3.3.4-dll32.zip

(Note that you must create .lib files using MS Visual Studio. I believe the Express C++ version has the lib.exe program which does this. Issue 'vcvars32.bat' in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin to set up the path. Then, lib /def:libfftw3-3.def etc. in the fftw-3.3.4-dll32 folder to create the lib file.)

Get this version of LibUSB:
http://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.18/

And the attached, zipped .pro file.

See the #Configuration section of the .pro file for where I put LibUSB and FFTW.

I'll see about getting the precompiled binary uploaded. Getting the compiler set up right was such a hassle that I don't expect a lot of users to be able to do it. There are however security considerations to observe for Win32 stuff which I should to go through before uploading.


ED:
Stopping and starting both work in Windows, as does Digital phosphor.

ED2:

ED3:
This should be reasonable security.

https://nya.dy.fi/secure/Ledioskope.zip
user: eevblog
pass: eevblog

CRC32: EE3DAF51
MD5: 6D5F867C992EF571A0824202BC863221
SHA-1: 09FF567F9936E4A820EB5C267B81064BECB31CFE

[doctormord]

That's some great news! Thanks for the efforts, really appreciate.

I wonder if we could have precompiled .libs for this, so building would be easier. Isn't this just because reference calls to lib functions in the build process?

QT'n'stuff is not my business.

[ganzuul]

I think that's all it does... This post has the needed .lib file. I presume it works with other instances of Windows!

Note I edited my post and added a link to my server. Ledioskope.zip contains the binary and the .dlls it needs. My server's SSL cert has the  following SHA-256 fingerprint:

8F:42:26:3D:09:F2:2D:5B:1E:CB:CE:04:5E:9F:B4:50:70:E7:B8:40:82:83:BB:B2:FF:24:49:70:85:D9:4D:F4

[psynapse]

Doctormord

That is very strange, I can decompress both my original local copy of scope2.zip and a copy I just downloaded from this board;

ON everything else you say , I 100% agree with you.

Jimon,

I have one of those cute little FX2LP board, very pretty very cheap.  I had the same idea as you ..... but my board has the 56 pin device with port A, B and D.  Our scopes, be they 120 or 140 have the 100 pin device with ports C and E as well,  which are used by the default firmware.  So be careful about hacking the board!

Ganzuul

Good work ... Is it possible to share the QT5 source, so that we can give it a go under linux.


All

Even ignoring the Sainsmart software (and that is a really good idea) we have, I think, 4 versions of PC based code now (Donut6 WX, Mmark QT5, Psynapse QT5 and Ganzuul QT5)  and I think I have missed a fifth, my apologies, I have just looked at the current page.  I am quite happy to carry on with my own thread, but do we, as a community, want to start putting our weight behind one version? Or maybe two?  I am guessing that the only two key criteria are that the version we choose needs to run under linux and windows and on both the DDS120 and the 140.  I would want to have the ability to add my "odd" extensions, but with shared source this will not be a problem.  All that said, I would not want to explode the goodwill in this forum in order to force this idea, it is far too good a place to bounce ideas around in!

For information:- I have now proved (on the 140) that the wave table loaded to the GPIF with the 94 0A command can be rewritten "dynamically" , that is to say my app can now adjust the sampling rate between 10 and 200 FX2 clock periods.  This is in addition to the standard clock rates of 200,100,10 Mhz, 625k and 39k which are independently derived from a 80MHZ crystal on the CPLD. I have yet to try less than 10 (I know I cannot go below 4) or above 200, But it looks as though we can get additional ranges at (approximately) 5,2,1,0.5,0.25 Msps.  For mmark, my code is very short and simple

case65:                               ; this command (65) tampers with the continuous mode timebase.  The sample time is (1+1+param+param)/48Mhz   
   mov     DPTR,   #SETUPDAT2   ;get pointer to the single input parameter, which is the second byte of the USB message
   movx   A, @DPTR               ;get the input parameter itself. We should check its validity here, zero would be BAD
   mov           DPTR, #021ECh      ; A pointer to within the (RAM copy) alternate waveform table
   movx   @DPTR,A         ; store the number of cycles for T1 in the GPIF waveform
   inc      DPTR
   movx   @DPTR,A         ; store the number of cycles for T2 in the GPIF waveform
   lcall     reload                  ; reload the wave tables
   ljmp    send_ack

[doctormord]

Doctormord

That is very strange, I can decompress both my original local copy of scope2.zip and a copy I just downloaded from this board;

Well, downloaded again and get the same errors on the same files on linux and windows. (Even on C:\ .. )

Beside this, i would like to see the power of your coding skills in 1 (or 2) version. Would make things easier alot. As my coding skills are limited to mikrocontrollers and C#, i would help on the interface (GFX).

The last serious stuff i did (beside my amplifiers), was an uC controlled motordriver with PC-interface. (The GUI is only POC)





The idea behind is to use the motordriver (from CD-ROM) as an actor-controller -> XY galvanometer being fully modular. (Baseboard, Controller, Actor-Driver)

I put together a small presentation for our lectures:

https://dl.dropboxusercontent.com/u/5641160/Galva-O-Magic.pdf

@ganzuul

Thanks! 

[mmark]

Doctormord

That is very strange, I can decompress both my original local copy of scope2.zip and a copy I just downloaded from this board;

Well, downloaded again and get the same errors on the same files on linux and windows. (Even on C:\ .. )

FWIW: I could download and unzip scope2.zip without any issues on my mac... And after changing the .pro file a bit I was able to compile and run it as well, but had no time to add support for the DDS120 yet, but will hopefully in the next few days.

[doctormord]

@ganzuul,

i actually get this, when starting the app.

Possible solution:

http://qt-project.org/forums/viewthread/22908

Edit:

I'm on Win7 32bit.

[ganzuul]

Our cooperation so far has proven itself an obvious strength. We've been screaming along at supersonic speed and consequently it's difficult to tell at this point which way we are going.

The vagrancies of the Win32 version of OpenHantek can be hidden away within the .pro file, and right now the project is otherwise identical to mmark's. The actual code base compiled without alteration once the correct compiler/qmake combo was unlocked. That's why it's quite interesting that stop/start works on Windows but not on Linux.
We don't seem to have a functioning trigger. It ought to be possible to make one in software that behaves like a Schmitt trigger. With some scaling and adaptivity this in turn would easily lend itself to frequency counting. For that stuff we'll probably have to rely on an FFT library.

Miscellaneous thoughts:
I have had the FX2 dev board in my Aliexpress shopping cart for a while now too, and I have been learning a lot about electronics. I have ideas for data acquisition hardware modules which I hope to explore. An FX2 talking with an FPGA or CPLD is a great and versatile combo that the DDS120 avoids with the skin of its teeth.
Gnuradio has a scope built-in, along with its uncountable other features. Its GUI is based on WX. The developer community is quite helpful and there is lots of documentation. They are well-versed in DSP and bridge out to an academic, industrial and even military audience. The code-base is huge though, and far from portable.
For heavy-duty compute, GPUs seem to beat FPGAs. FPGAs excel in high-throughput with light compute situations and the latest generation of entry-level FPGAs from Xilinx and Altera have high-speed Ser/Des at low cost. For GPU documentation and education, nVidia's has more. For FOSS, one has to choose OpenCL. If a laptop just a few years old has trouble with FFTs, we might want to consider some rudimentary OpenGL/OpenCL interop to alleviate that. 


------

doctormord,
On it!

ED:

https://nya.dy.fi/secure/Ledioskope.zip
user: eevblog
pass: eevblog

CRC32: EE3DAF51
MD5: 6D5F867C992EF571A0824202BC863221
SHA-1: 09FF567F9936E4A820EB5C267B81064BECB31CFE

Server SSL SHA-256: 8F:42:26:3D:09:F2:2D:5B:1E:CB:CE:04:5E:9F:B4:50:70:E7:B8:40:82:83:BB:B2:FF:24:49:70:85:D9:4D:F4

[doctormord]

And.. it's working! 

Thanks alot, now i'll go to bed. 

Edit: From Start i got CPU-load of 90+%, but then, somehow, it droped to ~8%.

Can't reproduce for sure, but it seems like there's something with the trigger settings.


System is a C2D 6750 @3GHz 4GB, NVIDIA GFX..

[psynapse]

Doctormord

I will dig out a windows machine later today and see if I can replicate the problem on that.  All I did was use the Ubuntu archive manager to zip up the directory .......  And do not judge my coding skills on what is in the ZIP, it is a mess!  More objectively perhaps you should judge my coding skills by what is in the ZIP!  Seriously, it is just a vehicle for trying out ideas and not debugged bomb proof code.

Ganzuul,

I agree, and it is good to know that there is a close convergence between your code and that of mmark.  I have the feeling that the easiest thing I can do is to ride on the coat tails of you two, though I still have my doubts about the openhantek code.

I do have a functioning trigger in software (though only in my adaptation of Donut6 WX based code).  It is based on generating the first differential of the input data (more simply the difference between current and previous input value) .  By keeping track of the maximum of this value and where it occurs in the dataset you have a plot startpoint.  To speed the process and to avoid late syncs which leave too little data to plot, I scan just the first 25% of the input in this way.

Later today, I shall be wiring Int5 to the external socket of the DDS140 and writing a small ISR to allow Int5 to generate a "go code".  This will give an external trigger to the device, limited only by the fact that data acquisition will start a few microseconds after the trigger pulse.  The ISR could equally invoke a stop code, but I am no longer certain that stop really does stop the device!  I think we need to work on that to get a clean end state (ie one which does not pollute the start of the next capture, something we are all seeing at the moment.  BTW , what I thought were FIFO flush commands seem to trash the DDS140)

MMark,

Glad the code worked for you. I would not worry too much about developing it ... It was really a vehicle for showing some ideas (I have since added the variable timebase stuff and plan on doing the Int stuff as soon as family obligations permit).  I am very happy to "go with the flow" (you and Ganzuul) as long as I can expand the code to get hardware triggering in and the variable timebase stuff.  However, I did like the pan and zoom on the display,  which is basically my mash of other peoples code.  And if I really get really stuck, I will steal your good ideas and support for the DDS120 and put them in my code, with your permission of course.  How goes the firmware?