SainSmart DDS120 & DDS140 USB Oscilloscope

[psynapse]

To your last point,  yes I am trying to get cy console up in order to upload the code from the 140.  I am a little confused about unsoldering the eeprom.  As far as I can see, you pull the jumper and the device enumerates as a classic Cy ..... mind you I have not tried putting the jumper back on yet, but I am not expecting problems.

Will let you know when I make progress .... I am winding up an old version of Vista that has not been used for a couple of years and I have 130 automatic updates .  Normally a unix man.

[ganzuul]

You don't need to unsolder the EEPROM. But you do need the attached configuration file. I used it with Win7 x64 and it goes in C:\Cypress\Cypress Suite USB 3.4.7\Driver\bin\wlh\x64, as per the instructions franky linked.
On Vista you need to press F8 on boot and tell it to accept uncertified drivers to get it to accept the Cypress Suite driver.

Speaking of Unix, I got the OpenHantek software to compile and run on Debian Jessie after adding a bunch of qt4 packages beyond the ones in the instructions. The I couldn't get the firmware extractor to compile though, as the ./configure file is missing and the one I got generated with autoreconf --install; autoconf gives a strange missing file error about a '--silent' switch.
The Qt/OpenGL software seemed to work though, aside from throwing some errors that might, hopefully, be trivial. It could prove a terrific starting point for our plans!


I'm next going to use franky's instructions to try to get the DDS 120 to enumerate as the Hameg, and hopefully sniff the firmware off the line.

ED ED ED!!!:
I forgot!! You don't need the config file! I removed it from attachments. You can just plug the device in with the EEPROM jumper removed and it will identify as the generic Cypress device. Replace the jumper and you can use CyConsole to program the EEPROM!

Don't forget to use EZ-USB Download the vend_ax file to the FX2LP's RAM though. I attached a version I found on github, which seems to work fine.

[donut6]

Just written a quick and dirty libusb based program on linux. Not really got a clue what I'm doing ( ), but think I'm repeatedly capturing a waveform (131072 bytes from endpoint 0x82), lots of 0x85 0x86 values then eventually loses sync...

Will investigate more tomorrow! (or try out OpenHantek)

[ganzuul]

donut6, good work!  The 0x85 0x86 appears to be the quiescent value from what I've seen so far. It appears to be a raw 8-bit, bottom-to-top bitmap.



I tried setting " C0 B5 04 90 20 84 23 00 " with a Vend Req to Req 0xA9, Value 0x0000, Index 0x0000, length 8. The idea was to spoof a Hantek vendor ID and product ID. Windows does associate the Hantek driver with the USB device, but whenever their software runs with the hardware plugged in, the software freezes until the hardware is unplugged. It never gets to the point of sending its secrets over USB.
I don't know what 84 23 00 should actully be. The first two nibbles of these three are referred to as both Device ID and Revision, but this 'Device ID' is different from the 'Product ID' byte which actually follows the 'Vendor ID' byte.
 It might be this didn't work because I don't have those last three nibbles right. I'll need to find them and try again. - FWIW, C0 means use only vend/product id, while C2 means read-the-whole-EEPROM.


With the use of the open source Wireshark + USBcap combo like psynapse suggested, I made a complete capture of all of the functions that I know of or suspect that the DDS 120 program sends back to the hardware. It is 7-zipped and stored on my server, here:
http://nya.dy.fi/static/allcaptured.7z

I have not yet analyzed the capture. It's 18MB uncompressed.

[psynapse]

Slow down guys!

No seriously, brilliant work.  While I have been sleeping you have done a huge amount.

Ganzuul, I shall start ploughing through that huge capture of yours . And thanks for the tips on the EEPROM (both programming and the C0 vs C2 code),  I have got the EZ-USB console up and running, but cannot find a way of reading all the EEPROM contents .... but that was at 0200 this morning, ie after the 5 hours of windoze updates had finished ... so perhaps there is a way .... And with a driver that comes up with "NO EEPROM" in its device description.  As soon as I can I will get the firmware out of the DDS140.

Donut6, for somebody who says " Not really got a clue what I'm doing ( )," you are doing great .... not sure I could do as well.

While waiting for Windoze , I trawled about the interweb thingy.  It seems we are doing pretty well here without further info , but if things get difficult I have found how others have tackled this exact problem.  There are several hardware examples the are very close parallels to both the DDS120 and DDS140. The (DDS140 with its CPLD) has comparatively complex firmware, but I found one DDS120 "like" device where the main firmware code is a null loop:- it functions entirely by setting up the USB endpoints and fifos correctly and then just bulk ships out the data with zero intervention from the software.  Also several others, for example http://www.triplespark.net/elec/periph/USB-FX2/  . For me it helps enormously to see how others have tackled the problem.

I have my kids home from university this weekend, so I shall be going dark for 48 hours.

Between Donut6 and Ganzuul, the bar is set high. Ganzuul has the DDS120 covered while Donut6 is closing the DDS140 knowledge gap fast.  I guess it is time to try the compare and contrast the different command sets sent from the PC .

Donut6: - I almost forgot. I have not had time to investigate this thread, but the link to triplespark above leads to something called fx2pipe which is a linux command to (optionally) load hex into and pull data out of the cy.  You might find it a useful addon to the libusb work you are doing.  Which brings me to another question. If you are sucking large amounts of data out of the DDS120 under linux, does it mean that you have done no initialisation of the device?  And if you have what?!  Whichever, good luck.

[donut6]

For the DDS140 I had to send around 40 control transfer requests (currently magic numbers!) before getting bulk transfer data.
The bulk transfer also depends on repeated requests and waiting for the correct response (Request type 0x33 & 0x50 and waiting for response 0x2c followed by 0x21).

Seems a bit more complex than the DDS120 trace, but may also depends on the state of the scope.

BTW ganzuul , the probes are P6060. Similar/identical to -> http://www.aliexpress.com/item/Freeshipping-P6060-X1-X10-60-MHZ-oscilloscope-probe/1751563389.html

[psynapse]

In great haste, copying the eeprom contents from a DDS140 (largely following the example of others here)

- disconnect (open) jumper J1 from pcb
- connect scope to PC
- wait for USB recognition (CYPRESS default VID/PID)
- connect (close) jumper J1 on pcb
- start Cypress USB Console
- start EZ-USB Interface (Options -> EZ-USB)
- "Cypress EZ-USB ..." should be shown next do Device
- download vend_ax.zip to the scope controller, with download button
-issue Vendor request A9 , Value= start address, length (limited to 4096), direction "1 in"
- (so to get all the DDS140 eeprom need two commands , one with value 0x0000, next with 0x1000, both length 4096
- Done

Here is the result:


Not a huge amount of code.  Will get to it at the end of the weekend

[ganzuul]

The attached binary appears to be correct for the DDS 140.

It has some large differences from the DDS120's! The JTAG header has obviously been put to use. I turned psynapse's hex dump into binary with the following command on Linux:

Code: [Select]

xxd -r eeprom\ dump.txt dds140.bin
I wonder if the CPLD on the DDS140 could not be used to interleave the ADC, so that time-resolution is doubled. - That is the method by which the Rigol gets to 1GS/s.


Meanwhile, the FX2 has built-in UART. The pins are RXD1, TXD1, RXD0 and TXD0. They don't appear to be shorted to ground and from visual inspection they are not even soldered on the DDS140. =)

I'll need to fabricate some really small probes, and see if the pins are talking.

[donut6]

I wonder if the CPLD on the DDS140 could not be used to interleave the ADC, so that time-resolution is doubled. - That is the method by which the Rigol gets to 1GS/s.

Haven't had much free time this weekend. Think you're right! The 2 ADC channels are byte interleaved. There's also a "200Mhz" mode that shuts off probe 2 and only sends probe 1 data presumably from both ADCs .

[doctormord]

Has anybody had the courage to cross load firmware? (Since these devices are largely boot loaded from the host PC ??). 

Their actualy aren't in case of those DDS120/140 where the eeprom holds the firmware. I know those little logic-analyzers where only the PID/VID is stored in a (very smaller) eeprom. For sure, the DDS120 could boot up from host-side firmware injection in the CY RAM. Problem could be, that the acutally firmware does not enumerate after rebooting the 8051 core, so the software will likely fail.

To get around this, the .inf files could be altered to accept the CY standard PID/VID as a valid scope but i guess the software will check for correct (original) PID/VID.

(Edit: This seems to be all known for good, i guess)

Beside this, i had a deeper view in the provided DLL files to access the scope. Extracting the methods is on ease, but the the method-calls are not documented. As i don't have an IDA enviroment, i can't dig any deeper into this.

DDS120:

Code: [Select]

AiReadBulkData 0x10001080 0x00001080 1 (0x1) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
AutoMeasurement 0x10001ff0 0x00001ff0 2 (0x2) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
BufferInit 0x100012c0 0x000012c0 3 (0x3) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
DataPreDisposal 0x100012d0 0x000012d0 4 (0x4) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
DeviceClose 0x10003460 0x00003460 5 (0x5) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
DeviceOpen 0x10003410 0x00003410 6 (0x6) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
DllMain 0x10001000 0x00001000 24 (0x18) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
EventCheck 0x100031a0 0x000031a0 7 (0x7) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
GetBuffer4Read 0x10001220 0x00001220 8 (0x8) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
GetBuffer4Wr 0x100012b0 0x000012b0 9 (0x9) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
GetData 0x10001c90 0x00001c90 10 (0xa) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
GetHWbufferSize 0x10001160 0x00001160 11 (0xb) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
GetInfoByte 0x10001190 0x00001190 12 (0xc) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
GetInfodouble 0x100011c0 0x000011c0 13 (0xd) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
GetRawData4Read 0x10001200 0x00001200 14 (0xe) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
ResetPipe 0x100032e0 0x000032e0 15 (0xf) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
SetData 0x10001e20 0x00001e20 16 (0x10) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
SetInfo 0x10001120 0x00001120 17 (0x11) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
SetReadEnableOrNot 0x10001100 0x00001100 18 (0x12) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
SetStableEnableOrNot 0x10001110 0x00001110 19 (0x13) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
SetTrigInfo 0x10001170 0x00001170 20 (0x14) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
TrigDataPrepare 0x10002c70 0x00002c70 21 (0x15) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
USBCtrlTrans 0x100030e0 0x000030e0 22 (0x16) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function
USBCtrlTransSimple 0x10003080 0x00003080 23 (0x17) USBInterFace.dll E:\DDS120\USBInterFace.dll Exported Function


Code: [Select]

DllMain 0x10001000 0x00001000 3 (0x3) publicDLL.dll E:\DDS120\publicDLL.dll Exported Function
GetData 0x10001030 0x00001030 1 (0x1) publicDLL.dll E:\DDS120\publicDLL.dll Exported Function
SetData 0x100010e0 0x000010e0 2 (0x2) publicDLL.dll E:\DDS120\publicDLL.dll Exported Function

DDS140:

Code: [Select]

AiReadBulkData 0x10001080 0x00001080 1 (0x1) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
AutoMeasurement 0x10002340 0x00002340 2 (0x2) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
BufferInit 0x100012c0 0x000012c0 3 (0x3) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
DataPreDisposal 0x100012d0 0x000012d0 4 (0x4) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
DeviceClose 0x100037c0 0x000037c0 5 (0x5) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
DeviceOpen 0x10003770 0x00003770 6 (0x6) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
DllMain 0x10001000 0x00001000 24 (0x18) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
EventCheck 0x100034f0 0x000034f0 7 (0x7) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
GetBuffer4Read 0x10001220 0x00001220 8 (0x8) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
GetBuffer4Wr 0x100012b0 0x000012b0 9 (0x9) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
GetData 0x10001fe0 0x00001fe0 10 (0xa) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
GetHWbufferSize 0x10001160 0x00001160 11 (0xb) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
GetInfoByte 0x10001190 0x00001190 12 (0xc) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
GetInfodouble 0x100011c0 0x000011c0 13 (0xd) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
GetRawData4Read 0x10001200 0x00001200 14 (0xe) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
ResetPipe 0x10003630 0x00003630 15 (0xf) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
SetData 0x10002170 0x00002170 16 (0x10) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
SetInfo 0x10001120 0x00001120 17 (0x11) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
SetReadEnableOrNot 0x10001100 0x00001100 18 (0x12) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
SetStableEnableOrNot 0x10001110 0x00001110 19 (0x13) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
SetTrigInfo 0x10001170 0x00001170 20 (0x14) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
TrigDataPrepare 0x10002fc0 0x00002fc0 21 (0x15) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
USBCtrlTrans 0x10003430 0x00003430 22 (0x16) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function
USBCtrlTransSimple 0x100033d0 0x000033d0 23 (0x17) USBInterFace.dll E:\DDS140\USBInterFace.dll Exported Function


Code: [Select]

DllMain 0x10001000 0x00001000 3 (0x3) publicDLL.dll E:\DDS140\publicDLL.dll Exported Function
GetData 0x10001030 0x00001030 1 (0x1) publicDLL.dll E:\DDS140\publicDLL.dll Exported Function
SetData 0x100010e0 0x000010e0 2 (0x2) publicDLL.dll E:\DDS140\publicDLL.dll Exported Function

Comparing the DLLs from DDS120/140 shows that the basic method-names are the same.

For the FX2 i would guess, i just bulk dumps the ADC-data on one controll-point -> IN, adjusts some GPIO to switch the analog-frontend (CD4052 8ch. multiplexer) -> OUT. I would also guess, that the HRA (SOT23-5 AD8065 FET Opamp) are gain-switched regarding to the selected input-amplitude.

http://www.analog.com/static/imported-files/data_sheets/AD8065_8066.pdf

Mainly, nothing more is going on here. 

Edit:

Checking TXD0/1, nothin to be seen here on both pins (dead silent).

For the AD8065, one will be used as a SGA (switchable gain amplifier), the second seems to be the buffer stage.

Looking at the pictures DDS120/140, i'd say, the FPGA is only used for the expansion port. Will try a crossflash with DDS140 on my DDS120.

Edit: Crossflash works, drivers get installed, app is starting, BUT it seems that ho valid data is coming in. Despite this, the app is lagging alot. -> Wont work.

Cheers, doc

[ganzuul]

Behold!   

http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQFX2

If I'm reading this right, with GPIF the FX2 does achieve 96MB/s. That ought to mean 16MB/s headroom if we get 2 x 40MS/s x 8bits.

The links are broken, but this appears to be the same:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_build#Get-the-Source-Code

And under http://files.ettus.com/binaries/maint_images/uhd-images_003.007.003-release.tar.gz
We find /uhd-images_003.007.003-release/share/uhd/images/usrp1_fw.ihx

In the source tree at uhd/firmware/fx2/usrp1 there appears to be files which created the firmware. Going this route might be much easier than trying to reverse engineer the original binaries. This is looking very promising. =D

[psynapse]

A lot can happen in a weekend when you are not watching!  There seems to be really major progress.  I've started looking at the DDS140 firmware,  which is pretty small (taking out the data blocks and interrupt vector tables, less than 3k)  .  Very few interrupts have service routines:-  reset, the two timers (which are basically just register reloads) and wakeup (One line of code).  Apart from that the USB and GPIO vectored interrupts are pretty largely null.  Nothing on the GPIO/FIFO.  For the USB Vectors only SOF, SUTOK, SUSPEND, USBRESET,HISPEED have ISRs .

Hope this helps steer the folk looking at the USB protocol, such as it is.

Like everybody else , I am looking to the USB side of things for most of the solution. I am exploring the internals simply to try and find a way to get a real one shot trigger built into hardware. (eg stop the fifo a certain number of clock cycles after an external event)

Interesting notes on the AD interleave.  Yeah I've seen this approach elsewhere too; RIGOL use a 10 way interleave with 5 ADs to get 1GHz!  Has anybody scoped the two clock pins on the AD to see if they are complimentary phases?  A quick no go verification is to see if the two clock pins are shorted together!

[psynapse]

All,

Sorry, I need to read the board more carefully.

Donut6

I had not spotted the 200Mhz, one probe mode!  Thanks.  That will be the clock interleave .... although how they do it with a 80Mhz Crystal I don't know


Ganzuul,

Apologies, you too spotted the RIGOL. And yes the GPIO functioning as the port to FIFO will run up to 96Meg .... So for the DDS120 good news.  For the DDS140 I think the max is 80x2Meg and hence the onboard RAM ..... but I suspect that is where my problem lies  ... I think that the RAM functions as a poor mans FIFO,  it is filled under the control of the CPLD and then dumped into the regular FIFO, leading to regular periods when the scope is blind.  I (well we DDS140 owners) can hope that the CPLD runs in two modes, either (at lower speeds) passing AD data straight to the true FIFO as per the DDS120 and just for higher speeds it directs the AD to the SRAM and then dumps the SRAM to the FIFO

Doctormord,

No I would not recommend trying the cross firmware load any more. It was a quick and dirty test (I am fond of those).  Perfectly feasible to reprogramme the EEPROM back and forward (using the Cypress utilities), but with the CPLD in circuit ....  And yes my guess was that the DDS120 resembled those logic analysers that are entirely boot loaded ... I was wrong

On the DLL front: Sainsmart make great play of the interface being open .... Just not as open as we would like?  Wish I could help more.

[doctormord]

Sainsmart is not a great help in any way. They just rebranded hard-/software. The so called "SDK" is kinda useless. Beside this, they weren't able to supply a firmware dump to me.

DLL documentation would greatly help.

I would like to ask, how did you separated the firmware (interrupts, vectors, etc.)?

For the cross flash, I tried DDS140 fw on DDS120 hw, so no CPLD/FPGA harmed. )

Regards doc

[psynapse]

Doctormord,

Seperate out the vectors?  The old fashioned way, by eye!  Converted the hex dump from the eeprom to a Intel hex file (via a spreadsheet!), converted the Intel hex to a bin, diassemble the bin, eyeball the bin, knowing the default page zero map, trace the jumps by hand.  Find the "odd code regions" by eye, check that there are no dependencies in and out of those regions (except by reference as data) . Then use a text editor to substitute symbolic references for known hardware addresses and registers in particular.  Mind bogglingly slow, simple and boring.  The bigger challenge (now) is to interpret and comment what is there.  I am hoping to find the "case" statement associated with input gathered from the USB.  That way I hope that I can give you guys some idea what the box is expecting to see out of the back end of your DLLs.

The thing I do not understand well is the legality of it all.  To do so for my own benefit I believe to be completely legal .... to share it perhaps less so  ... to exploit it, certainly not.  So I hope that I will be able to give you help at the USB interface.  Which should marry up with what you, G & D are doing. 

But no promises, the brain is not as sharp as it was.

[doctormord]

I once had a friend like you, who teached me "model tiny" ASM this way. )

So my first "program" was reboot.com " 0xCD 0x19"

Regards, doc

[doctormord]

Ganz. I think that the RAM functions as a poor mans FIFO,  it is filled under the control of the CPLD and then dumped into the regular FIFO, leading to regular periods when the scope is blind.  I (well we DDS140 owners) can hope that the CPLD runs in two modes, either (at lower speeds) passing AD data straight to the true FIFO as per the DDS120 and just for higher speeds it directs the AD to the SRAM and then dumps the SRAM to the FIFO

To my understanding, running the scope this way on "high speed" would only work for triggered signals (so just getting enough samples to refresh the screen) not in free running mode, or will, until the buffer gets full.

[psynapse]

Doctormord,

I agree with you, and that is exactly the problem ... there is no hardware trigger (confirmed by sainsmart), the software just guesses 

On a brighter note, the code inspection is progressing.  I believe that the "magic bullets" of donut6 are:

db(022h)
db(023h)
db(024h)
db(033h)
db(034h)
db(035h)
db(050h)
db(060h)
db(061h)
db(062h)
db(063h)
db(070h)
db(071h)
db(072h)
db(073h)
db(074h)
db(075h)
db(076h)
db(077h)
db(078h)
db(079h)
db(07Ah)
db(07Bh)
db(07Ch)
db(07Dh)
db(090h)
db(094h)
db(0D0h)
db(0D1h)

I think these are all the command codes (first byte) to the DDS140 scope.  The commands appear in the second byte of the 8 byte setup data (please see attached diagram of USB packet structure)

Tomorrow, I will start exploring what parameters they import, but I have noted that many of them do bit set/clr to the I/O ports. Also, what is the first byte?

Some examples 33 and 34 manipulate port C.3 and E.2 in complementary manner
76 through 7d have similar behaviours to each other and take one byte parameter (which sets key parameters in the direct RAM space below 80h) etc

[doctormord]

As far as I remember, the DDS140 should have an external trigger input. (seen in the software trigger menu, CH1/CH2/EXT)

[psynapse]

It has ext marked, but no external connection.  It make me ask:-does one exist "inside" the dds140, or is this in some way generic software?

[doctormord]

I would guess, it's available at the expansion header.

[ganzuul]

I found out that the sdcc compiler doesn't support dual data pointers. Dual DPTR gives a huge performance boost, so I'm unsure if I want to base a new firmware on it.

Other than that, I got fosphor  working, by telling my shell to

Code: [Select]

export LD_LIBRARY_PATH=/usr/lib/fglrxbefore compiling. Proprietary code was needed. My GPU should be able to cope with 220MS/s, according to some benchmarks made by fosphor people. From this evidence it appears that direct sampling of an oscilloscope signal is achievable. OpenCL/OpenGL interop opens up some really interesting use cases.

[psynapse]

I'm wrong again.  There are some more command codes 

[doctormord]

Someone asked for demo-code or "SDK"?

Its in here:

http://m5.img.dxcdn.com/CDDriver/CD/sku.271544.rar

The included publicDLL.dll only supports "GetFre; GetVolt; Setpara".., the programmcode refers to "getData".. 

The publicDLL.dll and demo.exe, placed in the same directory as the oscilloscope software,
Oscilloscope software at run time will be part of the measurement data is written DLL, while demo.exe simultaneously read and display these data.
Provides demo.exe VC source code, users can refer to write their own applications.

Translated from ?.txt

Edit:

Seems like the software is also for the BM204 (beside BM102/BM104). The BM204 got an external trigger input:

http://www.aliexpress.com/store/product/New-arrival-External-trigger-function-BM204-Oscilloscope-Signal-generator-logic-analyzer-USB-PC-virtual-oscilloscope/927391_2016085955.html

Edit2:

The provided demo.exe is working when copied to the DDS120-Software-Directory. (DDS120.exe and Channel 1 needs to be running)

Source-Code is avail here:
"Oscillograph\Demo\VCSource"

Seems like the demo.exe is only talking to the software, not to the scope directly.

My Driver-CD is done at 20140606 with manual from 20140522.

If someone needs, there a download-link from my amazon-seller. (Sent via mail)
https://docs.google.com/file/d/0B8P1gmkorIY5U0x2d1VlMG8wbms/edit?usp=drive_web

[ganzuul]

Seems like the demo.exe is only talking to the software, not to the scope directly.

So that's why I couldn't get it to work.

It just seems to incredibly useless. What could have been the point of this?