SainSmart DDS120 & DDS140 USB Oscilloscope

[ganzuul]

ED:
We have FOSS code!!
/ED



This scope is advertised as 50Ms/s while the ADC runs at 40MHz. The supplied software switches down to a sampling rate of 2.4 "MHz" when over a certain time division, and then over the time division it switches up to 50MHz. The resulting graph is not as pretty as I'd like... The lowered sampling rate appears to be a way to avoid writing sub-pixel graphing accuracy, but it could also be a self-imposed CPU load ceiling.

The two probes are of the model TP6100, which when sold separately reportedly cost $9 on eBay. They are probably not true 100MHz probes, but one review of them that I saw referred to them as "good stuff".

There's a rather exposed I2C interface, which I have heard lends itself to hackability. There is also an API to the driver with a sample project for the Microsoft platform SDK.

I placed my order on May 8th, so it took 12 days to deliver it from China to Finland. I paid $67.99 in total. I ordered it from here: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=300992154516

So far I'm happy with the hardware I actually got for the money but will have to look into making the scope work with some existing open source package.

R4 - AD9288BSTZ-40:
http://www.analog.com/static/imported-files/data_sheets/AD9288.pdf

C10 - CY7C68013A:
http://www.cypress.com/?docID=45142

R13 - 24LC64:
http://www.mouser.com/ds/2/268/21189h-21840.pdf

I'll bump this when I know more about this thing!

ED:

Added some high-res pics to my private web server:
http://nya.dy.fi/static/images/PICT3351.JPG
http://nya.dy.fi/static/images/PICT3348.JPG
http://nya.dy.fi/static/images/PICT3347.JPG

These photographs are just under 6MB each.

ED2:
Updates..

[ganzuul]

Well my ISP shut me down for a few when I tried to zone transfer some Chinese DNS records. I was thinking www.buudai.com might have a new IP which hasn't propagated yet, so in want of that I cyber-stalked the developer instead! 

https://web.archive.org/web/20140520231246/http://bbs.21ic.com/icview-350047-1-1.html

Looks like a university student who couldn't afford a scope of his own, so instead he built one for himself.


ED:

Forgot this. The software package that gets distributed with the Rocktech version of the scope has one additional functional button in the UI, but the version number is the same.
http://m5.img.dxcdn.com/CDDriver/CD/sku.271544.rar
(From http://www.dx.com/p/bm102-bm102-50mhz-2-ch-usb-analog-oscilloscope-silver-grey-271544#.U3vp5a4Rots )

[mikewardlow]

I purchased the DDS120 [BM102] in August.  It sort of works , the display software needs much improving,
I was trying to detect a pulse train [ie]  100us pulse, 100us delay, 100us pulse, 8 second delay,  this sequence repeats
Trying to use single trigger , it would sometimes take 2 minutes to capture a trace  ,  it seems like the larger the delay 8, the longer it takes to catch the trigger ... Normal trigger was not much better.  All the trace captures displays started at center screen, I have been unable to change that, who needs a 50% pretrigger area ? When I would capture a signal, starting at center screen, then change the time base, it would rescale proper on some timebase, bad on some, missing on some.

It is a useable product if you don't need to observe 1 time events,  again the display software needs much improving

[mikewardlow]

Have been in contact with Sainsmart, they are working on a SW upgrade that will hopefully be released [ next 7 days]
I'm not going to hold my breath 

[doctormord]

Thanks for your efforts. Let us know on any news. :-)

Cheers

doc

Edit:

Q2/Q3/Q?/Q? = AD8065ART-R2
Datasheet: http://www.analog.com/static/imported-files/data_sheets/AD8065_8066.pdf

[doctormord]

If someone please could dump the I2C eeprom? Somehow i fried mine. 

[biot]

If someone please could dump the I2C eeprom? Somehow i fried mine. 

Usually these EEPROMs connected to Cypress FX2s contain only a USB VID/PID, not much more. But this is an 8KiB EEPROM, much larger than it needs to be for this. It wouldn't surprise me if this one also contained some calibration data specific to your unit. So if you get a dump and things seem off afterwards... don't be too surprised.

I don't know this particular USB scope, but I've seen this in other cheap USB scopes.

[dannyf]

Glad to know I won't be fattening unwashed kapitalist pigs

You probably don't want to know this but it is precisely those kapitalist pigs who made it possible for you to purcahse this product from China.

A little bit ungraceful to slam the hands that just helped you.

[doctormord]

I changed the PID/VID/DID back to the original ones, but this wont work. It seems that the whole firmware is stored in the EEPROM.

I initially dumped the EEPROM several times, but ponyprog came up with nonvalid dumps.

If someone is able to dump:

Ponyprog: I2C Bus 16bit eeprom, 2464/2465

[doctormord]

Anyone tried yet?

Cheers, doc

[ganzuul]

Oh hey! Didn't notice people were posting here!  =D

I'm working on getting a dump from the EEPROM done, but I have been avoiding soldering since I remain horrible at the art. I should be able to attach to the 222 resistors fairly safely though... shouldn't I?

Doc tells me my approach of listening in on the Cypress uC talking to the EEPROM isn't going to work. But, should I not be able to analyze the data after capture just as well? Or is it necessary to chat up the 24LC64 to get it to tell me its secrets?

You probably don't want to know this...

Ah, that was supposed to be a joke. I removed it now.

[frenky]

I was able to read contents of eeprom connected to the CY7C68013A by folowing this instructions:

http://www.jwandrews.co.uk/2011/12/saleae-logic-analyser-clone-teardown-and-reprogramming/
http://www.cypress.com/?id=4&rID=33947
http://www.cypress.com/?id=4&rID=26141
http://cosmiac.ece.unm.edu/images/7/71/CyConsole.pdf

[ganzuul]

Thanks frenky! I thought I had bricked the EEPROM for a moment there while I was playing around with CyConsole, but it seems to work fine still, capturing traces and so on. 

It strangely stopped responding to 0xA9 requests after I had mashed the buttons for a bit. It now occurs to me that it might have forgotten the Vend_Ax.hex firmware.
Meanwhile, I'm unsure of how to automate dumping the EEPROM. I would rather not manually iterate through the whole address range, but learning to code this thing has been on my to-do list so I might try that approach.

If others wish to try this route, I can add to step 6 at jwandrews.co.uk's instructions the following:
Open cmd with admin privs, enter;

Code: [Select]

>cd C:\Cypress\Cypress Suite USB 3.4.7\Driver\bin\wlh\x64
>pnputil -i -a cyusb.inf
Meanwhile, Vend_Ax.hex is located in C:\Cypress\USB\CY3684_EZ-USB_FX2LP_DVK\1.0\Firmware\Vend_ax if you use
http://dlm.cypress.com.edgesuite.net/akdlm/downloadmanager/software/CY3684Setup.exe


In addition to the GUI improvements we have discussed, another potential use for this device might be software defined radio. A shortwave radio with two receiving antennas could be very interesting in case the data streams are 'coherent', since you could theoretically then put a ~10db attenuation on local sources of interference.

[ganzuul]

Aah! That was easier than I thought. CyConsole does requests of 4096 bytes length, so I just made two of those.

https://docs.google.com/document/d/1gz8bpZO8d04XP_qIzXkw-ArYnnmb7o2oF7ut7Qiz32w/edit?usp=sharing

I'll clean it up and make a proper file out of it, like .hex or .iic...

Note line 0FF0 after the first 4096 bytes is equal to line 0000 of the second 4K. Then there is a little padding, and then the rest of the ROM is NULL. - The Keil compiler that the Cypress SDK comes with is restricted to binaries of 4K, so we can probably assume that Buudai used the free version!

Now IDA Pro does IIRC disassemble 8051 bytecode... More on this later.

ED:
The attached file should be the binary. I presume doc will tell us if it works! =)

[doctormord]

BIG thanks to ganzuul and franky, we are back in business! 

Reflash the EEPROM in short:

- disconnect (open) jumper R32 from pcb
- connect scope to PC
- wait for USB recognition (CYPRESS default VID/PID)
- connect (close) jumper R32 on pcb
- start Ponyprog2000
- set EEPROM type to 2464/2465 - I2C bus 16bit eeprom
- do a calibration (Setup -> Calibration
- read device to backup state (button)

- File -> Open Device File -> i.e. "DDS120_24LC64.bin"
- write device (button), verifies when finished

- reconnect scope, wait for scope driver to finish installation

 O0

Flashing is done via a simple parallel-port-programmer called "Easy I²C Bus interface":

http://www.lancos.com/prog.html#easyi2c

Bottom of page.

(Should also be possible via a CH341A eeprom programmer, but haven't any success)

Reprogramming can also be done via the CYPRESS USB Control Center (see attachment). When doing so, it is important to select the "64k eeprom":

- disconnect (open) jumper R32 from pcb
- connect scope to PC
- wait for USB recognition (CYPRESS default VID/PID)
- connect (close) jumper R32 on pcb
- start Cypress USB Console
- start EZ-USB Interface (Options -> EZ-USB)
- "Cypress EZ-USB ..." should be shown next do Device
- press Lg EEPROM "DnLoad to 64k EEPROM"
- select "All files *.*"
- select "DDS120_24LC64.bin"
- wait for finish then reconnect scope
- wait for scope driver to finish installation
- Done

[ganzuul]

Glad I could help! I learned a lot in the process, and I don't think I'm done. =)

By the way, I just noticed that the DDS 120's File > Record an Review function actually does work! It's much more usable than the Single trigger. It will record up to 450 frames to disk.

[psynapse]

A little off topic. I have the DDS140 (BM104) which uses

ad9288
cy7C68013
altera max II.

The altera gives a lot of extra I/O pins for logic analyser / sig.gen.  I have not traced the circuit to see whether it plays any major part in analogue acquisition

However I note that the (awful) software is the same for both scopes, so I am guessing the protocol to the cy 7C68013 is the same.

Somebody mentioned an API to the device, where can I find that please.

Like one of the other folk here, I brought this thing to record single shot events, but triggering is almost non existent. And the faster the sample rate, the less likely the trigger is to happen.  A quick calculation on USB2 transfer rates suggests that the device goes blind whilst it transfers the next 40k bytes of samples.  Another person noted that the record function works  ...... and it does ..... but seems to have the same problem ...... ie grab 40k bytes, transfer it to the PC, store it on hdd, get the next 40k ..... which would mean that the data is actually full of holes.  All that said, if I could get true triggering, 20kx2 samples would be fine

Postscript:

Just opened mine up to take a photograph ...... to my horror I find the AD is a 40Msps certified part and the crystal to the logic array is 80Mhz   ....... This would be fine, except that this device is meant to be 100M samples per second per channel  .... So I shall try and send it back

[donut6]

I also have the DDS140, advertised on amazon.co.uk as a 40MHz 200M/S Oscilloscope.

But, the analogue front end is identical to the DDS120?

Too lazy to return it. Might try my hand at writing an OpenGL scope app!

[gambit58]

Hello
I just received the SainSmart DDS-120. The device drivers installed properly for Windows 7/64 Ult. When I run the scope software that is included I receive an error message (See attached). Suggestions for a fix?
Thank you

[ganzuul]

Just opened mine up to take a photograph ...... to my horror I find the AD is a 40Msps certified part and the crystal to the logic array is 80Mhz   ....... This would be fine, except that this device is meant to be 100M samples per second per channel  .... So I shall try and send it back

That's an amazing thing to hear! 

I wonder if the AD is actually a genuine part? I can imagine an off-brand higher spec device would cost less than a brand-name one.

Perhaps it can be overclocked in the DDS 120, like doc suggested?

I also have the DDS140, advertised on amazon.co.uk as a 40MHz 200M/S Oscilloscope.

But, the analogue front end is identical to the DDS120?

Too lazy to return it. Might try my hand at writing an OpenGL scope app!

Are the probes identical too?

I'll gladly collaborate with you on the scope app. =D

Attached is a capture I made with a trial version of a program called USBlyzer. I was not able to capture any of the control signals which are obviously sent back to the uC, or any of the traffic in that direction, to my frustration. However, the data it sends should be trivial to plot. I'll next try USB Hound, which I found through links on this site: http://janaxelson.com/development_tools.htm

I wonder if the easiest way to make a pretty graph would not be to use "poor man's anti-aliasing" and simply downscale a large bitmap. A further degree of averaging/smoothing could be to use a fading effect. Ideally, this would make the visual equivalent of; sort 5 or so samples, drop the highest and lowest, take average value, and display it. - This very simple signal conditioning procedure has high noise immunity. There is no need to decimate the signal rate; one can just shift in the next sample in the sequence.

A much more advanced, experimental idea could be to see if http://en.wikipedia.org/wiki/Karplus%E2%80%93Strong_string_synthesis can't be used for a kind of triggering... Wave form stabilization, to be exact. The theory is just extremely interesting.

[ganzuul]

Hello
I just received the SainSmart DDS-120. The device drivers installed properly for Windows 7/64 Ult. When I run the scope software that is included I receive an error message (See attached). Suggestions for a fix?
Thank you

Does it show up in Device Manager? Did you try installing it on another PC?

[psynapse]

Identical front end to the DDS120:- no, probably similar but a visual inspection between photos of the DDS120 and the DDS140 shows at least different component layout .... but in my DDS140 the A/D converter is identical to that in the DDS120 .... and hence incapable of 100Msps. The silk screening on the top is for an Analog Devices AD9288 BSTZ-40 , perhaps with a date code of 0732 (?!) and since it is not clear that AD use the BSTZ-40 designation, it might be a copy (photo)

Here is a photo of the insides of my DDS140, apologies for the added colours, I am trying to trace through to get an idea of how it works ..... Although I am so disgusted at being sold something that doesn't do what it says, that I have stopped for now .... send it back or not?  And if I keep it, happy to collaborate .... to my mind the quickest way to get something working might be as part of sigrok, a cross platform community.

[psynapse]

To all (but Ganzuul in particular)

Nice USB dumping utility:- if I read it correctly, its reading 64k bytes in 80mS? I need to look into that.  But as you say, it will be important to read traffic in both directions.

Yes the A/D might be being overclocked, but I prefer your explanation of a copy which might be capable of that speed . IF I have read the date code correctly (ie 7 years old) then that seems more likely.  The 80Mhz clock to the gate array I had presumed was divided by 2 (or another prescaler) before going to the AD, but it might be fed direct .... I really need a scope to find out 

Still would mean that the maximum sample rate is 80msps, but did I read somewhere that "they" use a slight of hand to call that 100msps. ie interpolation.

Your ideas on subsampling are very interesting and I will look into them as soon as I can advance a little in the hardware. I guess you are not keen on the sigrok approach  .... could I ask why?

Postscript:

No meaningful dialogue with the supplier, simply a "contact Amazon for a return"

On the AD9288:- Overclocking (or use of forgery) of this part has been common for some time, see this post

http://www.eevblog.com/2009/04/05/full-review-of-the-rigol-ds1052e/

And the guys here in the " Rigol DS1052E " community are completely used to AD9288-40's being used at 100Mhz.  Arguments still abound whether the chips are copies, selected samples or whether all 9288's work at 100Mhz with decreasing accuracy.  Reading (the AD9288 datasheet) a little further myself, the top 5 bits are determined by a switched capacitor technique and the bottom three bits by a small (3 bit) flash convertor.  This would mean that a 40Mhz part might well work well on the top 5 bits , but with increasing errors in the bottom three bits as sample rates increase. Quoted performance for the DDS140 is S/N 100:1 so errors in the bottom 1.5 bits is in specification.

So the long and short, I guess what I have is the "norm" and not a freak DDS140.  I would love to know what others have inside their DDS140, assuming the courage of violating the meaningless "void if removed" sticker.

And when I get the time, I shall follow ganzuuls example and use Wireshark + USBPcap to get hold of the USB traffic.  It will interesting to see what the differences are between DDS120 and 140 protocols.

[psynapse]

Less of me!  I have neither a DDS120 nor a Hantek6022be, but a visual of photos of the PCBs suggests that both are wired identically with respect to AtoD and the cypress chips, ie both have AD9288s wired to the same ports in the same way.... which leads to the questions,
has anybody more information on this similarity?
Has anybody had the courage to cross load firmware? (Since these devices are largely boot loaded from the host PC ??). 

The reason for this question is that the Hantek is being worked upon  by the Open community  ... and for Ganzuul there is some progress on the protocol exchange (see https://github.com/olerem/openhantek/commit/9a0d2747edc9306b1b56c04a4a9d491269023c76)

[ganzuul]

That's brilliant!

The JTAG interface to the FPGA could prove very interesting. - I have spent the past few days learning about JTAG on an unrelated and now mostly finished project. I used a Parallax Propeller with a piece of software called the Jtagulator, by Joe Grand. It enumerates pin configurations, for UART too, and also does a boundary scan. You have to get the voltage level right but 3.3V is fortunately very common.

I'm quite unfamiliar with sigrok aside from recently encountering it in passing and adding it to me reading list.

The RF frontend is an unexplored mystery to me right now, but overclocking the DDS 120 definitely has to be tried.
1.5 bits of resolution translates to 9db. 39db left. Can be used for certain applications.

I'll definitely try cross-loading the firmware from the Hantek if I can obtain it! And also try my hand at analyzing the bytecode side-by-side since we have our binary from the DDS 120. Doc tried removing the pin which powers the EEPROM, and so did I after I knew he got his DDS 120 working again with the firmware. When the pin is removed the scope enumerates as a different USB device, and you can still load firmware directly into RAM with CyConsole.

This is gotting very interesting! =D

Do you think you could use CyConsole to get a copy of the firmware from the DDS 140? I'd very much like to try to spot differences, and do more cross-loading. =)

[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?

[doctormord]

"Because we can." 

[psynapse]

Doctormord:

Argh! seems like I brought my DDS140 two weeks too early ... the BS204 is exactly what I need in terms of functionality.

I am still making progress on the code, but ask myself whether there is anybody wanting it.  Are there elements that you are searching for? I guess you are not planning on rewriting the DLL!

But thanks for the BS204 heads up anyway.

Ganzuul:

The point? perhaps just to be able to say it is an "open" interface.  Which of course it is not

All: 

After days of negative feelings as to progress, I finally got round to Wiresharking the USB stream.  And low, I see the command set I've already seen in the firmware , the only code I was missing is E7. 

In fact, once the scope is setup (permit USB interrupt data transfer gain,ACDC etc)  the sequence of events is incredibly simple.  The host(pc) issues a "go code" of 33h, periodically checks the status of the FIFO with command 50h, which returns 2Ch for fifo not full.  When the EZUSB does detect fifo full, it returns a code of 21h, halts the fifo (and hence data acquisition) and then blasts 2^17 bytes to the PC under a USB "interrupt".  On my machine this takes around 15mS (not sure why so slow).  The whole process is then repeated, issue go code, check status, stop fifo when full and transfer data under USB "interrupt".

All this means that there are periods of black out, which get more dominant with timebase speed. At 100Mhz 2 channels running, data acquisition takes around 650uS and transfer 15mS, so blind 95+% of time.

However the good news is that if the go-code can be timed properly by the PC, or gated in hardware, single shot triggering is possible, but only in the sense that the scope acquires data post-trigger.

Which for my needs leaves two tasks:-
1)gating the go-code before it leaves the PC or through hardware/firmware in the scope
2)finding out what all the twiddly hardware setup codes are (optional, if I am prepared to live with the supplied ##### software)

[donut6]

psynapse,

I can start to comment my code now!

Code: [Select]

    int w = 0;
    int resync = 0;
    scope_request(0x33, 0x00);   // "go" code
    // check FIFO status:
    while (w != 0x2c) 
    {
        w = scope_request(0x50, 0); 
        resync++;
        if (resync>10) break;
    }
    while (w != 0x21)
    {
        w = scope_request(0x50, 0);
        resync++;
        if (resync>25) break;
    }
    if (w == 0x21) // fifo full
    {
        int r = acquire_scope_data();
        if (r < 0) return;
    }
    render();

The rest is just libusb code

Code: [Select]

int scope_request(int req, int val)
{
    unsigned char data;
    if (scope_handle)
       int r = libusb_control_transfer(scope_handle, 0 | LIBUSB_ENDPOINT_IN, req, val, 0, &data, 1, 0); 
    return data;
}

And to read the scope FIFO buffer:

Code: [Select]

        r = libusb_bulk_transfer(scope_handle, 0x2 | LIBUSB_ENDPOINT_IN, scope_data, sizeof(scope_data), &transferred, 1000);

scope_request(0x24, 0x18) enables ch1 & ch2 input
scope_request(0x24, 0x19) enables ch1 input

scope_request(0x94, 0x10) sets the ADC to "100Mhz"
scope_request(0x94, 0x1c) 10Mhz

I think. Not tested this yet.

So in terms of software, it seems trivial to me! I'm working on a basic wxWidgets front end, but don't have much spare time this week!

[doctormord]

Good job guys!

[psynapse]

Donut6

Keep going! Great.

I am getting slightly different time base codes (with bit4=0) ie
94,00=100megs
94,0C =10 megs 
94,08=625kHz
94,0B = 39khz (ie 100M/256)

less sure
24,0A C2 to AC
24,1A C2 to DC
94,08 C1 to AC (noting that this conflicts with my timebase setting)
94,18 C1 to DC (noting that this conflicts with your timebase setting)

Both 24 and 94 codes load the bottom 5 parameter bits into Port A, connected to the CPLD on the DDS140
I do not see a logical bitwise use, so I guess it is decoded ....  with 32 combinations of commands? Also the heavy use of 94 commands at startup suggests setting one function at a time.  So more exploring to do (unless somebody works out what the cpld is doing)

The difference between 24 and 94 codes is that 94 codes reload the EZUSB state machine controlling the GPIF.  I have little evidence to prove it as of yet, but I wonder whether such radical tinkering with the hardware on the fly is the source of the bugginess in their software.

[doctormord]

Doctormord:
I am still making progress on the code, but ask myself whether there is anybody wanting it.  Are there elements that you are searching for? I guess you are not planning on rewriting the DLL!

Hi psynapse,

at first i'm looking for a working/better software solution. At second, it would be nice to maybe implement the functionallity i had coded once for my Rigol DS1000 series scope. (Datalogger)



@Donut6:

Is there any way i can test/explore something on my DDS120 yet? (Codes, Commands, Responses)

Edit:

I set up Wireshark + USBCap to see some magic and i really wonder about the fact that an amplitude of "zero" -> 0V is encoded as 0x82 in the stream. So when using the scope in DC-coupled mode, the effective resolution is only 7 bit.

Both channels open, no signal:

Code: [Select]

No.     Time           Source                Destination           Protocol Length Info
   6076 647.832144000  1.2                   host                  USB      65563  URB_INTERRUPT in

Frame 6076: 65563 bytes on wire (524504 bits), 65535 bytes captured (524280 bits) on interface 0
USB URB
    USBPcap pseudoheader length: 27
    IRP ID: 0xffffffff86746be8
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)
    IRP information: 0x01, Direction: PDO -> FDO
        0000 000. = Reserved: 0x00
        .... ...1 = Direction: PDO -> FDO (0x01)
    URB bus id: 7
    Device address: 1
    Endpoint: 0x82, Direction: IN
    URB transfer type: URB_INTERRUPT (0x01)
    Packet Data Length: 65536
    [bInterfaceClass: Unknown (0xffff)]
Leftover Capture Data: 828283828382828283838282828283838382828282828282...
Data is formated as CH1,CH2,CH1...
where 0x82 is "min_amplitude" and 0xFF is "max_amplitude" at DC-coupling. AC-coupling would (as expected) be 0x00-0xFF.

Data input compared to timebase (tested with Rocktech software version):

Code: [Select]

Timebase Samplerate dpps Size
50ns-1us 50MHz 10 1024
4us 2.4MHz 10 2048
20us 2.4MHz 10 4096
200ns 2.4MHz 5 65536
500ns 2.4MHz 5 65536
1ms-5ms 240kHz 5 65536
10ms 240kHz 3,7* 131072
20ms 240kHz 1,85* 262144
100ms 240kHz 0,91* 524288
200ms 240kHz 0,459* 1048576
*Data-request-polling is set to 200ms (5rps), response (dpps - data packets per second) from scope lags behind.

The SainSmart software version has changed polling-rate/packet-size. I.e. with 10ms timebase polling rate is now 100ms with response times 70/200ms and 32k datapacketsize (compared to 64k at the Rocktech software), so this is running totally async. (out of control)

Shown here: (SainSmart 10ms timebase):




DDS120

Control Settings
24,00 CH1 to AC
24,08 CH1 to DC

25,00 CH2 to AC
25,01 CH2 to DC


94,11 240kHz (1ms to 2s)
94,01 2.4Mhz (4us to 2ms)
94,10 50Mhz (50ns to 1us) <-- would guess, it's 48Mhz real sampling rate

33,00 request data

CH1 Voltage setting:
22,08 50mV
22,04 100mV
22,00 200mV
22,06 500mV
22,02 1V
22,02 2V
22,02 5V

CH2 Voltage setting:
23,20 50mV
23,10 100mV
23,00 200mV
23,12 500mV
23,02 1V
23,02 2V
23,02 5V

So no PGA scaling, same resolution for 1V/2V/5V which corresponds to 6/7/8Bit, or 20mV/Step in AC-mode.

No more codes avail, so no CH1/CH2 on/off, no trigger settings.

Some signal generator codes:
62,00 square wave output
60,00 sine wave output
61,00 triangle output

Some misc codes:
34,01 enable logic analyzer mode
34,00 enable scope mode

I somehow captured data in logic analyzer mode (with the SainSmart software provided). There were a bitpattern shown when switched back to scope-mode, but somehow the software got f*cked up then. 

Using the old Rocktech release, Logic analyser is working, readout is done on CH2. (So hardware.addon with some weak-pulldowns might be possible to implement)

Maybe "94,10" (Rocktech) vs. "94,01" (SainSmart) at initialisation is doing some magic here. (See below)

First time running (using START button) with default settings (Rocktech Version):
31,00 SET ISOCH DELAY
24,08 CH1 to DC
25,01 CH2 to DC
94,10
22,02 CH1 1-5V
23,02 CH2 1-5V
90,01; 90,02; 90,05; 90,03; 90,06; 90,04
90,07; 90,08; 90,09; 90,0A; 90,0B; 90,0C; 90,0D; 90,0E; 90,0F; 90,10; 90,11; 90,12; 90,13
94,10
22,02 CH1 1-5V
23,02 CH2 1-5V

First time running (using START button) with default settings (SainSmart Version):
90,01; 90,02; 90,05; 90,03; 90,06; 90,04
90,07; 90,08; 90,09; 90,0A; 90,0B; 90,0C; 90,0D; 90,0E; 90,0F; 90,10; 90,11; 90,12; 90,13
94,01
22,02 CH1 1-5V
23,02 CH2 1-5V
24,08 CH1 to DC
25,01 CH2 to DC

For the DDS140 i got some more requests at:

34, 50, 63, 75, 76, 77, 78, 79, 7A, 7B, 7C, 7D, E7,  90, 94

Edit:

Due to some magic, i opened up some kind of calibration menu in the rocktech software.

Code: [Select]

#define  CHAN0_ZERO 132
 #define CHAN1_ZERO 128
 #define CHAN0_ZERO500mv 132
 #define CHAN1_ZERO500mv 128
 #define CHAN0_ZERO50mv 133
 #define CHAN1_ZERO50mv 129
 #define CHAN0_ZERO100mv 132
 #define CHAN1_ZERO100mv 128
 #define CHAN0_1V 205
 #define CHAN1_1V 0
 #define CHAN0_500MV 12
 #define CHAN1_500MV 154
 #define CHAN0_200MV 159
 #define CHAN1_200MV 165
 #define CHAN0_100MV 144
 #define CHAN1_100MV 151
 #define CHAN0_50MV 132
 #define CHAN1_50MV 137
 



To access, start BM102.exe
select "Oscilloscope + Signal Generator" from the menu
change to Signal-Generator window
press play button once (beside the number-buttons)
change back to "Osillagraph" window

Right then, all values are at 128 with no "zero adjustment", info box is empty.

Click "adjust" to set the defines.

Set both channels to "AC" and "ON"
Click "Start" button
Click "zero" button on the overlay menu
-> now the right column will filled up with values to be the ranges new "zero"
( #define  CHANx_ZEROyyMV)
Click "adjust" to set the #defines

Dunno what the scale button is doing so far, beside, it "scales" the signal on screen with the values from the left column. To get back, hit "adjust".

Everything setup in this menu is only valid for the current session. Nothing is saved in a file nor the scope.

[psynapse]

Doctormord

First, many thanks for the codes from the 120, I will do a compare and contrast.

Second some pure speculation, which might give you hope. Remember I do not have a DDS120 on which to check!

DC input.  The analogue front end is certainly buffered (protection and for the attenuator etc).  Most of the front ends I have seen will have a limited gain op amp acting as circuit protection.  The only sensible design decision will be that the output of the opamp rests around half of supply volts, obviously for AC, but also I suspect for DC. This would mean that your scope would measure +ve and -ve DC voltages, and hence rest half way up the digitising scale ...7F,80,81.

Datalogging. Even more speculation depending on the actual implementation in hardware/firmware of the DDS120.  As far as I can see at the moment, long period datalogging on the DDS140 (sic) will not be possible. It uses a standard RAM chip as buffer, controlled by a small CPLD. So it is either being written to by the A/D or being read from (indirectly) the host PC.  It cannot be doing both at the same instant. At low recording speeds, sure the CPLD could interleave reads and writes, but at 100Mhz no, and what hopes do you or I have about how clever the designers have been    So I would keep the faith with the DDS120. As far as I can see, at lower speeds (perhaps even 10Msps), the firmware may be clever enough to interleave FIFO reads and writes.  But that is unexplored at this time.  As a DDS140 owner, I have ordered a 10€ EZ-USB breakout board of the sort used for logic analysers.  My hope is to build an AD front end for that (sometime in the future)  ......EDIT, but having just looked at your wireshark traces, I agree the DDS120 seems a catastrophy, getting data when the host software feels like it.

Software.  Me and you both!  In fact everybody in this forum wants exactly that.  Donut6 seems to be storming forward on that front. And who knows, with an open interface, other groups might take up the challenge too, and we will be spoilt for software choice.  Me, I shall keep the faith with Donut6, I know the amount of work he is putting in.  So your contributions on command codes for the DDS120 make a real difference.

[doctormord]

Having the codes, the DDS120 might gets integrated (supported) into "OpenHantek":

http://www.openhantek.org/

Or "Open6022BE" from RichardK:

https://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/630/

ftp://ftp.pididu.com/OpenHantek/

[doctormord]

Well,  the polling might get better with a triggered signal. Haven't tried, was set up to freerunning all the time (No trigger).

This really needs to be adjusted.

[psynapse]

Doctormord,

Yes I agree, looking at your trace, you seem to have lost a data packet (which is quite acceptable under USB rules I believe)

I have looked at some of your codes on the DDS140, as well as photos of the DDS120.

DDS120:- I note that Port C is largely wired to the analogue front end. PC.0 to the AD encode pin, PC.1 not traced by me, PC.2 and PC.3 to one of the 4 to 1 multiplexors used as attenuators, PC.4 and PC.5 to the other attenuator.  This largely agrees with your findings, but there are a couple of anomolies.  For the DDS140 it is a mess.  Command 22 is sweet, it sets 2 bits on port B similar to the DDS120, but Command 23 tweaks just one bit in port E, and port B is connected to the CPLD .....  So the long and short of that is that I think those command codes correspond, broadly, but parameters will be different.

Commands 24 and 25 (with values 0 or 1) flip single bits in E (E.2 and E.6) according to the parameter.  E.6 at least goes to the analogue front end, so good reason to expect the same function there, but again different input parameters.

Command 34 seems to be a stop/go command.  34(1) executes the same code as 33.  34(0) inverts the two bits tweaked by 33.

Commands 76 through 7D (on the DDS140) store, bytewise, 16 bit reload values (and an alternative set) for timers 0 and 1.  I have yet to determine what the timers do, except for flipping bits E.0 and E.1 each time they overflow.

On the DDS140 , I am getting the idea that Port E, largely present on the expansion port, carries some control signals. Very tentatively E.0 and E.1 programmable clock signals, E.2 sampling in progress (active low) etc

BTW because E.2 is presented on the expansion connector of the DDS140, I may be able to use this as a sampling active indicator, and from there a sync to enable better triggering

[doctormord]

Doctormord,

Yes I agree, looking at your trace, you seem to have lost a data packet (which is quite acceptable under USB rules I believe)

The responses accumulate with time. The bunch of responses in the end is due to stopping the scope, like having 20 requests in 4s with 5 answered "in time", there will be 15 coming after when stopped.

I have looked at some of your codes on the DDS140, as well as photos of the DDS120.

DDS120:- I note that Port C is largely wired to the analogue front end. PC.0 to the AD encode pin, PC.1 not traced by me, PC.2 and PC.3 to one of the 4 to 1 multiplexors used as attenuators, PC.4 and PC.5 to the other attenuator.  This largely agrees with your findings, but there are a couple of anomolies.

What anomalies do you see here?

Regards,

doc

Edit:

I wonder, how the framesize is set for the different timebases? 

[psynapse]

Doc

Anomolies, perhaps none. And no slight intended!  As I said my speculation.  I see  (on a photo) PC.2 and PC.3 go to one of the 4 to 1 multiplexors used as attenuators, PC.4 and PC.5 to the other attenuator.  Any bit remapping is possible in the firmware, but if I was writing quick and dirty code My 22 codes for Attenuator CH 1 would be 0,4,8,C and my 23 codes for the other attenuator would be 0,10,18,20.  But as I say I have neither hardware nor software for the DDS120. You have ground truth in your hands

And to show how wrong I can be:- For reasons that completely elude me the E.2 bit shows perfectly the data acquisition window for the logic analyser (active low), but rests stubbornly high when getting analogue data!  And data acquisition in logic analyser mode is a nightmare, with the PC transfer and analysis time coming to 600mS per block .

As far as frame size in concerned, it seems completely fixed at the SRAM fill size.  But there maybe tweeks in the CPLD control that I have not seen yet

[doctormord]

Thanks for the reply, double checked to 22,23 commands, they're valid as shown previously.   

Regards,

doc

[psynapse]

database problems with the forum yesterday, my full reply lost 

All the 90 commands return a static parameter .... their meaning is lost, but I presume that they are product ID and device capabilities, so your assumption is very probably correct.

herewith the c90 return codes
call 1 send 85
call 2 send 87 back
call 3 send 6 back
call 4 return B2
call 5 return 7E
call 6 return B0
call 7 return B8
call 8 return 7A
call 9 return 7A
call 0A return 8B
call 0B return 7f
call 0C return 7b
call 0Dreturn 8E
call 0E return 84
call 00Fh return 88
call 10h   return 80
call 11 and 13h return 89
call 12h return 85

and the command 34 codes seem very plausible for the DDS140,  they play with the right hardware bits

commands 70 to 73 set up 16 bit variables in page zero.  At this stage the function of these variables is unclear.

command 94 uses the bottom 5 bits of the input parameter and resets the gpif state machine (responsible for bulk data transfers),  So yes to timebase setting, but perhaps something more?  I wonder whether one of the GPIF modes is capable of sustained data transfer (something you and I are both looking for)

Apart from the mystery E7 command what does that leave us with?  It will be interesting to see if Donut6 has enough to build a first shot linux based method of getting data from the scope.  When we know where the holes are, further charting will be possible

[ganzuul]

Great to see you guys making progress. I have just been running in circles. 

The GPIF could be promising for getting a sustained transfer...  I'm unsure of what can been be squeezed out from between the GPIF state machine/delay and the 8051, but having now discovered the link between matrix math, graph theory and state machines I remain optimistic. I vaguely remember some very simple coding schemes which result in various levels of compression...

Another idea: Put a resistor-divider between channel A and channel B to obtain more depth on a single signal.

ENC_B on both the DDS120 and the DDS140 are left floating. This makes me uncertain about the DDS140 getting 200Msps. I wonder if it might however be possible to make a hardware mod.

ED:
http://en.wikipedia.org/wiki/Template:Compression_methods

[psynapse]

Ganzuul

"ENCb is left floating" Is that by measurement or by looking at the photos? 

I had made the assumption that ENCb was directly connected to ENCa by straight extension of the PCB track under the device itself:- the ENCa and ENCb pins are directly opposite one another on the chip.  Next time I get the chance I will measire resistance between the two pins.  I would expect this for the 120, its lower sampling rates mean the both A/D can run synchronous.  I will be disappointed with the 140 if this is true, because it will mean that the two A/D are not run "phased" and the device will give nowhere near the claimed 200Msps.

The GPIF should be capable of sustained rates up to 10Msps, but I have asked somebody who has built a 10msps scope around the fx2 chip.  I await his reply.  Conceptually, his design is very close to the 120 (see http://www.triplespark.net/elec/analysis/USB-LiveOsci/ ) I also have an fx2 prototyping board ordered that will allow me to establish what the real situation is.

I await with interest your thoughts on graph theory and state machines, it may prove very useful.

Yes, if greater precision is needed,  the resistor chain would work well.

[ganzuul]

ACK! You're right. The trace is connected underneath. Today is not one of my more lucid days.

I'll take a little time and be more thorough with the state diagram thing. Markov chains appear to be good way to get a conceptual foot through the door on that subject though. https://charlesleifer.com/blog/building-markov-chain-irc-bot-python-and-redis/ really drives it home for those who need an intuitive, hands-on approach.

I'll say more, soon.

[psynapse]

All

Just had a quick and helpful reply from the guy who built the FX2 based scope that resembles the DDS120, to quote him

"Regarding data transfer: Back then when I did this USB scope
I used it to transfer data at 20 MBytes/s (2 x 10 MS/s) for
many seconds or even minutes with only occasional data loss.
Say, >90% that a some second long transfer had no loss. IIRC.

Computers were slower at that time (Athlon XP, single core)
and the type of chipset did matter. Most crucial was the right
type of software (e.g. fx2pipe) to handle the async IO."

I see those as really helpful and positive words.

[ganzuul]

20 MB/s might still be plenty, even if we get those only by reducing the encode rate. Positive indication indeed. =)



It appears that the purpose of two of the 8-bit multiplexers is to attenuate the analog input, so one can simply connect the two channels and set the relevant bits correctly to get deeper resolution.



The FX2 implements the following ECC:
http://read.pudn.com/downloads107/doc/439463/ECC%20Algorithm_Toshiba_v2.1.pdf
Princeton has decided some ECC schemes may be used for compression:
https://www.princeton.edu/~verdu/reprints/Lossless%20Data%20Compression%20Via%20Error%20Correction.pdf

The GPIF does operate at one instruction per cycle, and it uses 128 bytes to store its 'waveform descriptors'. These bytes are modifiable at run-time, but not quite on-the-fly.

Some words about graph theory: Graph theory appears to provide a theoretical framework for reducing the complexity of e.g. a circuit of logic gates while retaining its truth table. However, this process of reduction is pretty much the heart of a Turing machine; NP-completeness, Gödel's Incompleteness theorems, and optimization. Fortunately, humans brains with their neural networks are really good at optimization problems.
So, incredibly, I remain hopeful about squeezing more information through the 40MB/s max I have heard about!

[doctormord]

Could we do a simple bulk sample software on the current firmware yet?

Beside this, maybe the osciprime source could help to understand fx2lp firmware developing?

http://www.osciprime.com/?p=source

and

http://sigrok.org/wiki/Fx2lafw

The open source sigrok driver which implements logic analyzer functions with the help of:

https://github.com/djmuhlestein/fx2lib

[ganzuul]

It would make sense to make such a feature available to people who don't want to void their warranty.
The RTL-SDR samples up to ~2.56Msps without dropping packets and the DDS120 has a sampling mode of "2.4MHz", so copying the RTL-SDR's technique could be a good starting point.

I'll see what I can do. =)

[psynapse]

I really like experiments to back up theories and supposition, so herewith my finding on data acquisition on the DDS140.

The experiment was a simple one, count the number of write pulses arriving at the RAM each second.  If this number is equal the sampling rate, then there is no data loss. (Both the RAM and data path from the A/D are 16 bits wide)

Here are the findings ;

at 39ksps (80Meg/2048 =39.0625)

In alternate seconds 39070 samples written, in the other alternate seconds on average 35088 samples (approximately, because the sample window is not synchronised with the DDS140).

At 625ksps (80M/128)

an average of 321992 samples written per second.

Higher sampling speeds will have to wait for the ICs to build a pre-scaler.

The observed results fit almost perfectly the model that the DDS140 does 64k of samples, stops sampling and transfers the samples to the host.  On my bench machine (XP+3500Athlon) the total transfer and processing time is variable but averages closely to 100mS.

Why does this fit ?

For 39ksps, there is one second of pure,uninterupted, sampling, followed by ~0.677 second of further sampling and then data transfer,before restarting sampling.  The exact numbers are 1.677s of sampling 0.103s of transferring . Sampling every second, I will see either pure sampling or sampling plus a single transfer.

For 625ksps 321992samples corresponds to 4.9132 blocks to transfer per second, and an active sampling time of 0.515seconds, leaving 0.485seconds of transfer time. Again very close to 100mS per block transfer.

These measurements correspond well with wireshark observations

What does all this mean ?


In short, you cannot use the DDS140 to log data.  Even at low speeds when it would in principal be possible for correctly configured hardware to capture continuously the DDS140 does not.  I do not have a DDS120,  but as previously noted, the right firmware should make continuous low data rate acquisition possible on that device.
At 39ksps the DDS140 captures 95 % of data
At 625ksps the DDS140 captures 52 % of data
At 10Msps just 6.2 %
At "100" Msps around 0.65 % of data

So the DDS140 is useless as a datalogger, and single shot mode (for capturing transients) at 10Msps or above is like winning the lottery.

Suggestion:

A DDS120 owner should repeat a very similar experiment to determine whether that device is capable of continuous acquisition.  The only tricky part is tacking a wire onto the board.  After that the wire goes to a frequency counter or the "counter in" on an arduino.  My fear is that the same programming style will have gone into the DDDS120, ie get a block of data, stop, transfer it, restart acquisition.  If I remember correctly, other folks wireshark traces certainly show a "start" command after each block transfer, but are those traces on the DDS120 or the DDS140?  It may even be possible (by using low data rates) to judge this from the less accurate wireshark data.  If somebody will post a raw USBPCAP file for the DDS120 running at its lowest rate, I will have a look.  The trace will need to be for say 20 bulk transfers.


Footnote :
One of my other reasons for « tapping » the write line is that it enables me to have a sampling active indication and even count where an externally triggered event will fall into the buffer.  Note by externally triggered, I mean that the DDS140 will trigger the event to be monitored, not the other way round.

Postscript:

I have just found that sometimes a stop from the sainsoft software stops USB transfer, but not data acquisition.  In this case the data sampling rates are steady at 39070 and 625116 samples per second.
This also seems to be linked to the software failing

[ganzuul]

Scope is DDS120. Sampling rate is 240kHz, time division 1ms, packet size is 65563B. It seems to insist on always returning data from both channels. Will the DDS140 agree to turning off one channel? The packets arrive at an average 0.2 seconds delay, with little variance except for a few outliers. "Delta time displayed" can be added as a column in Wireshark and it is populated with meaningful data when this filter is used:

Code: [Select]

usb.transfer_type == 0x1
I can attempt to attach my uC to some wires, if you'd like. My soldering has improved dramatically since I learned to keep my elbows close to my sides!   



Having studied the librtlsdr a little bit, it appears that they too use bulk transfer instead of isochronous transfer. This isn't because bulk is better, but because iso is poorly documented on the device. Preference for iso has been voiced on the mailing list, but they seem to have given up on it, deprecating the relevant 'asynchronous' code section of librtlsdr.
They also appear to be writing their own firmware into an EEPROM, somewhere...



I'm a little confused about how to put together what I'm reading in the FX2 TRM. Everything except iso is supposed to max out at 64 bytes of actual data per frame with huge swaths of padding, while iso utilizes the full 1023 bytes available to the frame. My confusion might be one of ISO-layers (different 'ISO', not 'isochronous') where the FX2 TRM actually talks about a lower level of abstraction when referring to frames, and Wireshark talks about a higher level of abstraction when talking about packets. If anyone knows more, please speak up. =)



I think I'm going to continue by figuring out how to make a custom firmware. What I'm reading is finally starting to make sense to me, and this chip is actually very commonly found in various devices. Since USB 2.0 isn't going away any time soon, programming the FX2 might be a decent professional skill to learn.

[doctormord]

The packets arrive at an average 0.2 seconds delay, with little variance except for a few outliers. "Delta time displayed" can be added as a column in Wireshark and it is populated with meaningful data when this filter is used:

Indeed, it always sends data from both channels, as i'd shown some posts before.

[ganzuul]

Oops, I missed that.

But I did notice the bug psy mentioned, where the scope keeps sending data after the scope app has been stopped. I makes me wonder if there actually is any logical coupling between each request and reply, and if this is simply the state the software was in when time ran out for the dev.

[psynapse]

"if this is simply the state the software was in when time ran out for the dev. "
100% agree


Guys:

You have posted loads, which I will read more thoroughly in the morning, I need some sleep.

It is clear that the scope firmware is pretty random:- I see the same stuff as you some of the time and not others, and I do not think it is us!

A couple more little snippets, both DDS140 of course.  What I said about data capture on that device remains true, nearly!  As I wind the timebase down, the sampling rate goes down from 100M, 10M, 625k and finally 39k ..... except when I switch the timebase right down to 500mS or 1 Second.  At these slowest of rates, the data capture rate rises to 240ksps and the hardware buffer full flag (C.6) never registers full. At that rate there appears to be no data loss (TBC)  However the display software is useless!  So continuous data logging at 240ksps looks as though it may be possible after all on the DDS140.  Not much but better than nothing. 

Second thing.  When I stop/start the trace, all the software in the PC does is stop sending 50 (status) commands.  On the DDS140 the device itself does not notice that it has a buffer full until the 50 command prods it into checking, when the data comes flooding out again.  I think that the DDS120 and 140 are very different beasts,  excepting that they both seem capable of continuous running at 240ksps (Thanks to both of you on that one)



Ganzuul.  I agree that the TRM is confusing.  My reading of it and USB standards are as follows (but I need to check for fundamental differences between the DDS120 and 140).  Initial negotiation between host and FX2 permits the FX2 to send interrupt packets. Against the USB 2 standard, it can send up to 3 interrupt packets  (each up to 1024 bytes) in each of the 8 available microframes that make up a millisecond.  These are re-assembled by the host into a complete message.  Maximum theoretical throughput is then 3x1024x8x1000 or a bit less than 24Mbps.  This gives each (DDS140) block of 2¹? bytes a transit time in of around 6mS.  Where XP and the app spend the next 94mS,  I do not know!

And in agreement with  Ganzuuls comment note interrupt, not iso!  This I have checked with the start up parameters in the firmware.

And as per Doctormords comment "Indeed, it always sends data from both channels, as i'd shown some posts before", interrupt mode puts no obligation on the host to actually read the data. EDITAnd Doctormord:- finally looked at your wireshark trace for the DDS120, these really are very different machines.  As you have been saying, data just comes out of the thing when it wants to. I really need to review your mega post more carefully and document more clearly the DDS140 codes.  I now know for example that the 94 command is perhaps the most dangerous of all the DDS140 commands:- it reloads the GPIF state machine and transfers its input parameter to Port A for some reason yet to be determined. And note that it changes state machines dependant on that input parameter.END EDIT

Except for the 200M single channel  :-//mode, which I have not checked, I think the 140 always sends both channels, even with only one selected. I will double check.

As to learning the FX2 , I agree . It seems about the only game in town for simply moving large amounts of data of USB.  There are plenty of code examples out there too.  As to the hardware we are discussing, again I would not recommend the DDS140, the CPLD is still a complete black box to me, and if I can it will stay that way.  No keep with the 120 guys,  I wish I had brought it instead.

That is not to say that the 120 is going to be easy.  I expect it uses the GPIF state machine, and are really going to need some level of circuit schematic.  First thing I would do is to see how much the hardware differs from other designs (links somewhere in this thread).  Not sure there is much point going in there with a soldering iron .... yet!  I have tacked two wires to the pcb,  I sweated a bit on that .  They connect the write signal to the RAM and the buffer full signal into an arduino.  From that I can generate my sync feed.  But again, would not need to do that on a 120.

Happy hunting.  More as I find it out.

[doctormord]

I put some more efforts hardware-wise into the DDS120. To have a better understanding, whats going on in there, there's a big template now.

Full-Size-Download (updated at 2014/10/23 01:46p):

https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpg

Regards,

doc

[donut6]

psynapse - hopefully this should line up with your DDS140 firmware analysis

Code: [Select]

    //  Command  Bit Field ..... Description
    //    0x22   0000 0aa0   
    //                 00  ..... Gain Ch1   (0x0)
    //                 01  ..... Gain Ch1   (0x2)
    //                 10  ..... Gain Ch1   (0x4)
    //    0x23   0b00 0000
    //            0        ..... Gain Ch2   (0x00)
    //            1        ..... Gain Ch2   (0x40)
    //    0x24   000c abbr
    //                   0 ..... Relay
    //                   1 ..... Relay - Ch1 to both ADCs 
    //                 00  ..... Gain Ch2   (| 0x0)
    //                 01  ..... Gain Ch2   (| 0x2)
    //                 10  ..... Gain Ch2   (| 0x4)
    //                 11  ..... Gain Ch2   (| 0x6)
    //                0    ..... Gain Ch1   (| 0x0)
    //                1    ..... Gain Ch1   (| 0x8)
    //              0      ..... Ch2 AC     (| 0x00)
    //              1      ..... Ch2 DC     (| 0x10)
    //    0x94   000d ssss
    //              0      ..... Ch1 AC
    //              1      ..... Ch1 DC
    //                0000 ..... 100Mhz  (0x0)
    //                1100 .....  10Mhz  (0xc)  80/0x8
    //                1000 ..... 625Khz  (0x8)  80/0x80
    //                1011 .....  39Khz  (0xb)  80/0x800
    //                1010 .....   ?     (0xa)

[doctormord]

Updated Version:

https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpg

PE3 and PE0 controls 2 PhotoMOS Relays directly at the Input to switch between AC/DC coupling. (NAIS 210EH)

[doctormord]

Oops, I missed that.

But I did notice the bug psy mentioned, where the scope keeps sending data after the scope app has been stopped. I makes me wonder if there actually is any logical coupling between each request and reply, and if this is simply the state the software was in when time ran out for the dev.

This problem comes from the fact, that the software is requesting more packets than the scope can deliver. This also happens with the DDS120 at bigger/longer timebase-settings and can be seen by Wireshark.

I posted a table in #55 (page 4)

Code: [Select]

1ms-5ms 240kHz 5 65536
10ms 240kHz 3,7* 131072
20ms 240kHz 1,85* 262144
100ms 240kHz 0,91* 524288
200ms 240kHz 0,459* 1048576
With 5 requests per second, the scope begin to lag with 10ms (timebase-setting) upwards. At 200ms timebase-setting and i.e. 10 seconds sampling-time, there will be 50 requests but only ~20 replys, so the scope is sending data for 15 more seconds after STOP.

Suggestion:

A DDS120 owner should repeat a very similar experiment to determine whether that device is capable of continuous acquisition.  The only tricky part is tacking a wire onto the board.  After that the wire goes to a frequency counter or the "counter in" on an arduino.  My fear is that the same programming style will have gone into the DDDS120, ie get a block of data, stop, transfer it, restart acquisition.  If I remember correctly, other folks wireshark traces certainly show a "start" command after each block transfer, but are those traces on the DDS120 or the DDS140?  It may even be possible (by using low data rates) to judge this from the less accurate wireshark data.  If somebody will post a raw USBPCAP file for the DDS120 running at its lowest rate, I will have a look.  The trace will need to be for say 20 bulk transfers.

Here we go:

https://dl.dropboxusercontent.com/u/5641160/DDS120_CH1_AC_ON_CH2_AC_ON_200mV_5ms_240kHz.rar

Settings like filename. At start i toggled CH1/CH2 coupling AC/DC/AC and then ran for about 25 seconds. (Start is at ~9seconds)

With tdiff = 9s, the last request came at 35.6s with the last package received at 48.8s.

Edit:

I wrote up some informations on my site:

http://www.360customs.de/2014/10/usb-oszilloskop-sainsmart-dds120-2-kanal-20mhz-50msps-buudairocktech-bm102/

Sorry for the translation, its automatic.

[psynapse]

A quick reply to donut6:  Yes those codes match up nicely, thank you.  To close off one question mark (and perhaps open another ) That 94(0A) code you see is the mystery mode.  It does not show up on the sainsmart software, but it seems to invoke a 240kHz sampling mode when you select the slowest timebase settings.  As noted previously , it seems to be capable of running indefinitely without dropout, but have yet to do the experiment to confirm.  It also invokes a completely different GPIF setup  for the fifo.  "Normal" mode is shown in the first two attachments.  The 240kHz mode is shown in the second two. Obviously more experimentation needed on my part.

(checking your codes against the firmware, and my earlier experiments)

And those gain settings agree with my findings , but for Channel B are very strange.  Yep command 22 goes out to port C.1 and C.2 whilst 23 goes out to port E.6

Command 24. SUPERB! Did not have all of those combinations but yes, the bottom five bits are latched out to the CPLD via port A. Thank you, in particular for sorting out where the other channel 2 gain bits went.

Yep to the 94 commands, and note that as above 0A gives a special mode. again it is bottom 5 bits mapped to the CPLD via port A. This is latched in by C.4 (the 24 command is latched by C.7)   Which leaves the question, what are the other 11 timebase modes?  I cannot tell from the FX2 firmware of course , because the parameter is latched into the CPLD

You saw my earlier post that the 90 commands just return a static parameter ... have you seen a pattern?

[psynapse]

Doctormord,

I think I am going to tell you what you already know! I have downloaded and looked at your pcap and  according to me you have zero data drop at 240kHz on the DDS120.  Good news! And sorry to give you extra work to do.  As you have already seen , all based around USB interrupts.

But this idea of the scope software requesting more packets than the hardware can deliver is strange.

And great work on the hardware tracing.  Keep it up.  Particulary nice job on labelling the components. Absolutely necessary in order to understand the firmware.  And it looks as though you have most of the necessary data already.  The only bit of tracing left to do (if you have not already done it ) are the traces back from the 4052 multiplexers .... pins 9 and 10 (IIRC) are the two selection pins that control which part of the input attenuator chain to select. Oh and the clock and enable pins to the ADC

There is something I really do not understand with the hardware of the DDS120.  Obviously you are getting 64k interrupt packets from the device, but the internal fifo of the fx2 is 4k.  I see your traces for the data paths, obviously correct (no hidden external fifos), So I can only guess that the DDS120 sets up an interrupt transfer of 64k bytes before it actually receives it and transfers data in 1024 byte interrupt packets when it has actually got the data from the ADC.  And what we see with wire shark is the re-assembly of 64 of those packets .  If it is true it is a clever use of interrupts, because that does not tie you to transferring the data at a particular time.

[doctormord]

psynapse,

thanks for the reply.

I wonder, "who" is constructing the packets. I.e. at 200ms timebase, the packets get 1048576 bytes in size. One 0x33 request results in one "combined" packet returned by the interrupt. As with this packetsize, the stream is running more and more async which results in stalled software-state. (Crash) So even with 1ms timebase, the software will stall on a long run, as seen from the dump.

-->

last request came at 35.6s with the last package received at 48.8s.

If some coder could explain? Where is the magic?

Found this: http://msdn.microsoft.com/en-us/library/windows/hardware/ff540352%28v=vs.85%29.aspx

But im not an USB coder.

From the driver-side, the device just uses winusb, thats why no driver is needed at Win8+:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff540283%28v=vs.85%29.aspx


Hardware-wise i updated the tracefile to:

https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpg

Clocking and ADC-setup is traced back.

DFS=0 -> Offset binary output
S1=1/S2=0 -> Normal Operation (Data Align Disabled)


(Preview is attached)

To my eyes, the gainstage is a bit strange.

Gainstage schematic:



Multiplexer J3 is doing what? Beside possibly bypassiing the clamping-diodes. 

J3X0 is giving -6dB attenuation
J3X1 is giving -20dB attenuation

There are 3 possible gain-settings, which is set by multiplexer J9:

620R -> 0.6
1K5 -> 1.46
3k6 -> 3.5

Code: [Select]

0x22 0x08 0000 1000 1 50mV/div
-6dB Input
+10dB Gain (x3.5)
0x22 0x04 0000 0100 1 100mV/div
-6dB Input
+3.3dB Gain (x1.46)
0x22 0x00 0000 0000 1 200mV/div
-6dB Input
-4.4dB Gain (x0.6)
0x22 0x06 0000 0110 1 500mV/div
-20dB Input
+3.3dB Gain (x1.46)
0x22 0x02 0000 0010 1 1-5V/div
-20dB Input
-4.4dB Gain (x0.6)
0x23 0x20 0010 0000 2 50mV/div
-6dB Input
+10dB Gain (x3.5)
0x23 0x10 0000 1010 2 100mV/div
-6dB Input
+3.3dB Gain (x1.46)
0x23 0x00 0000 0000 2 200mV/div
-6dB Input
-4.4dB Gain (x0.6)
0x23 0x12 0000 1100 2 500mV/div
-20dB Input
+3.3dB Gain (x1.46)
0x23 0x02 0000 0010 2 1-5V/div
-20dB Input
-4.4dB Gain (x0.6)
I haven't taken "Ron" (D-S resistance inside CD4052) into calculation, which will result in slightly higher gain at the low end.

[doctormord]

Curious, how does the ADC gets clocked?

Regarding the EZ-USB Technical Reference Manual:

http://www.cypress.com/?docID=48811

page 125, the IFCLK can only output 30/48MHz from its internal source. (I must review the trace at IFCLK and CLKOUT.)

Maybe its like:

24Mhz crystal -> PLL (48Mhz) -> /2 divider -> 8051 Core + CLKOUT [pin out] (24Mhz) -> IFCLK [pin in] + ADC_CLK (24Mhz)

Then the 8051-Core, FIFO, and ADC are running at 24Mhz at all time. Sampling is then done by 1/1 (24MHz), 1/10 (2.4MHz), 1/100 (240kHz).

From the specs, this scope should do 50Msps, but only when using both channels - single channel is 25Msps. This can't be true with a 24Mhz clock-source in no way, so we'll end up at 24/48Msps like Hantek. Even the software is lying to us when showing "50MHz" (should be "48MHz" -> 24MHz x 2 Channels)

Conclusion:

50Mhz -> 48MHz == 24MHz x 2 Channels = 24Msps per Channel
2.4Mhz == 2.4MHz x 2 Channels = 2.4Msps per Channel
240kHz == 240kHz x 2 Channels = 240ksps per Channel

The lower samplerates just skip sampling by 1/10, 1/100. 

Would be suprised to see the scope running at 48MHz. 

Beside all this crude stuff, the CD4052Bs propagation delay impacts as well at frequencies over 5-6MHz. 
(And because the Ron(DS) inside the switches varies with temperature and amplitude, things are getting worse even more)

 

Edit:

I made another testrun with the SainSmart DDS120 software version at a timebase of "2s". Captured data for 26 seconds (then hit STOP) results in 156 secons of data transfer (BULK INPUT) 

Attached are some dumps from USBTrace.

With timebases >= 1ms, data is not getting in in realtime. (lag)

[psynapse]

(Not posted earlier)

Doctormord,

Nice to see that you use the same tools as me (eg LTspice). You have traced and modelled  the circuit, respect.  You are a little worried about the circuit, not sure why. Q1 is a unity gain buffer (if memory serves me ) And Q2 a variable gain amp of a particularly horrid design.  As of this moment you do not seem to have included R26 though.

I most go cook for my kids, a house husbands work is never done.  But I will give both of your posts a much closer look. All that work on your part deserves a more careful scrutiny

But in the meantime

Well done ( I know how aweful SMD circuit tracing is)

[psynapse]

OK I have looked a bit more at the circuit and the internal resistance of the 4052 is critical.  Allowing internal resistances of 380,500 or 400 ohms for the three states,  Q2 is programmable to have a gain of 2,3 or 5 (1+(620+380)/1000), (1+ (1500+500)/1000), (1+(3600+400)/1000)

Odd gain figures, except we are driving the ADC differential, the other side being 1, the output of the unity gain buffer.  So what the ADC sees is 2-1, 3-1 or 5-1  .... aka 1,2,4  .... It is kind of sweet in a chear cost cutting sort of way.

A quick LTspice confirms


So in summary, J3 is giving divide by two or divide by 10 (and if the divide by 2 is diode clamped, de facto divide by 10 is too)
Whilst J9 gives multiply by one, two or four

Put both together and you have, for the front end gain

x2
x1
x0.5
x0.4
x0.2
x0.1

Transfer rates

Now I am not saying that the DDS120 does do this,  but the FX2 is capable of FIFO bursts up to 96Mbps,  but only using a 16 bit wide bus (which you do have),  so it should be capable of 48Msps per channel  ..... but for really brief periods of time, just till the 4k FIFO fills (because the output rate to USB will be far below that,  so the trick that works at lower speeds will not work here).  It is capable of this because the 8051 core plays no part in the transfer,  the GPIF is preprogrammed to move the data from the ADC direct to the FIFO buffer, completely invisibly to the CPU.  The actual maximum speed will be determined by the GPIF wavetable,  which is buried somewhere in the firmware.  When I have more time I will decompile the 120 dump that was put into play some time ago.

Your comments on the 4052, absolutely agree, this device is running right at its limits.  And inter-device variability.  And temperature variability all mean waveform distortion and variable gain characteristics.

On "who" is building the packets, it has to be somewhere in the PC, but where?  I join your call for somebody with knowledge in this area to explain what is going on!

Just looked at your circuit trace.  I pride myself on my work,  but yours is far better.  Apart from praise where it is due,  it seems to me that you have all the external information necessary to progress to a firmware re-write.  Is your plan to code the FX2 without looking at the existing firmware, or to look at how it should not be done ;-)  From my stand point most everything in the main 8051 code is pretty straightforward.  The two difficult areas are in setting up the USB and programming the GPIF in order to make fast transfers possible.  I mentioned earlier in this thread that somebody has already put code into the public domain. I have not looked too closely at the schematics or the firmware,  but the system from hardware and a firware sense seem very well constructed.  If you have no looked at it http://www.triplespark.net/elec/analysis/USB-LiveOsci/

[psynapse]

Doctormord

Sorry, I need to read your posts at least 3 times!

I have looked at your trace photo again, and if I understand "X" correctly, none of the CTRL or RDY pins are connected.  I am not sure that the GPIF can function with no such signals. I need to check.  But if it cannot (and you are certainly right about IFCLK) then I think that the only way this scope can work is by oversampling and throwing data away,  but at the PC end.   This would of course show in the the wireshark traces, we would see the same amount of data transferred regardless of timebase setting.  Is it possible there are some pcb traces on te underside of the device?  Have I misunderstood what "X" means? Perhaps it is just a marker for stuff still to do

As you rightly point out, even at 2.4Mhz the CPU is too slow to pick out 1 sample in 10 (or maybe even 20)

In short, what on earth is going on?

[doctormord]

OK I have looked a bit more at the circuit and the internal resistance of the 4052 is critical.  Allowing internal resistances of 380,500 or 400 ohms for the three states,  Q2 is programmable to have a gain of 2,3 or 5 (1+(620+380)/1000), (1+ (1500+500)/1000), (1+(3600+400)/1000)

Well, you cant have different Ron values (inside the 4052) for different external resistor-settings. (They are fixed for a given VDD-VEE, temperature and amplitude)

Transfer rates

Now I am not saying that the DDS120 does do this,  but the FX2 is capable of FIFO bursts up to 96Mbps,  but only using a 16 bit wide bus (which you do have),  so it should be capable of 48Msps per channel  ..

For sure it could, but when they would do, the scope where/is advertised as 100Msps device (50Msps x 2 Channels). (As they actually do with 50Msps -> 25Msps x2 Channels. Just have a look at the SainSmart website)

Doctormord

Sorry, I need to read your posts at least 3 times!

I have looked at your trace photo again, and if I understand "X" correctly, none of the CTRL or RDY pins are connected.  I am not sure that the GPIF can function with no such signals. I need to check.  But if it cannot (and you are certainly right about IFCLK) then I think that the only way this scope can work is by oversampling and throwing data away,  but at the PC end.   This would of course show in the the wireshark traces, we would see the same amount of data transferred regardless of timebase setting.  Is it possible there are some pcb traces on te underside of the device?  Have I misunderstood what "X" means? Perhaps it is just a marker for stuff still to do

As you rightly point out, even at 2.4Mhz the CPU is too slow to pick out 1 sample in 10 (or maybe even 20)

X is for "no connection" - right. There are no corresponding traces at the bottom side of the pcb, for having a further look, i need to desolder the fx2.

[psynapse]

'Well, you cant have different Ron values (inside the 4052) for different external resistor-settings. (They are fixed for a given VDD-VEE, temperature and amplitude)"

No, I know. To make clear what the designers were doing, i substituted different values into the theoretical calculations.  Using LTspice and adopting the datasheet typical value of 470 ohms as the internal resistance for all the 3 cases of gain, I confirmed that the gain for the q2 stage in the actual design is (very nearly)  2,3 or 5. This gives q1 and q2 a differential gain of 1,2 or 4, approximately.  The designers have used fixed value components and no trim pots. Same with the input attenuator. Nearly, but not exactly divide by 2 or divide by ten.


For sure it could, but when they would do, the scope where/is advertised as 100Msps device (50Msps x 2 Channels). (As they actually do with 50Msps -> 25Msps x2 Channels. Just have a look at the SainSmart website)

I agree. You will see from my earlier posts that they have done the same thing with the dds140, claiming 200Msps'
, when at best it can do 160Msps, and in the process overclock the ADC by 100%. My comment was more about what new firmware might be capable of.

X is for "no connection" - right. There are no corresponding traces at the bottom side of the pcb, for having a further look, i need to desolder the fx2.
Thanks for the clarification. I did not know whether there were any plated through holes hidden under the device. So as I said in my last post, that makes the configuration of the fx2 in the dds120 strange.  And no, of course unsoldering the fx2 would seem to be a foolish act. Certainly I would neither recommend it nor try it!

[doctormord]

I wonder if the influences could be minimized with changing the feedback-loops-resistor values. Needs verification not to affect GBW (gain-bandwith-product).

(I also want to simulate the influence of propagation delay, dunno if Multisim is taking this into account)

Apart from praise where it is due,  it seems to me that you have all the external information necessary to progress to a firmware re-write.  Is your plan to code the FX2 without looking at the existing firmware, or to look at how it should not be done ;-)

I'm hardware, not software. 

For the packet-creation, i looked a bit into USB-specification. I think, some understanding could be calculated by the 125us USB-timing. The point ist, that the Rocktech and SainSmart software-version do different packetsizes at same timebase settings with no altered control-codes.

And no, of course unsoldering the fx2 would seem to be a foolish act. Certainly I would neither recommend it nor try it!


Firstly, i'll try to trace those missing connections by electrical testing. If that don't work, i'll heat up my resoldering airgun.

Edit:

There we go. 

RDY0/*SLRD is connected to *FLAGD/SLCS#/PA7

In synchronous mode (IFCONFIG.3 = 0), the FIFO pointer is
incremented on each rising edge of IFCLK while SLRD is
asserted. In asynchronous mode (IFCONFIG.3 = 1), the
FIFO pointer is incremented on each asserted-to-deasserted
transition of SLRD.

By default, SLOE and SLRD are active-low; their polarities
can be changed via the FIFOPINPOLAR register.

Source: EZ-USB TRM page 103 9.2.5 Control Pins (SLOE, SLRD,SLWR, PKTEND, FIFOADR[1:0])

How to implement -> EZ-USB TRM -> 9.2.8 Implementing Synchronous Slave FIFO Reads

From 9.3.2., i would guess, they're using EP2 or EP6 with 1024byte size (As the smallest received packets are 1k) . FLAGD is then programmed to represent a FIFOFULL state (15.5.3 ff page 223).

By that, the FIFO size could be increased up to 4k when needed (slower sampling)

The question is, will FLAGD be held "high" only as long as the FIFO is full, or has it to be reseted when it once triggered by "FIFO Full"? If so, this would mean:

ADC is sending data to the FIFO -> FIFO gets full -> FLAGD is triggered (going "high) -> this raises SLRD, so IFCLK is incrementing the FIFO pointer on each rising edge of IFCLK while SLRD is
asserted. -> Data is being sent -> FIFO pointer reaches 0x000. FLAGD is then to be cleared. For the time of data transfer, the scope is "blind".

This could be avoided if switching from EP2 <-> EP6 respectively. So one FIFO gets filled by the ADC, while the other is being sent to the host.

A totally different approach would be (9.3.4 Auto-In / Auto-Out Modes page 111 ff), with direct streaming.

This has to be clarified by someone who knows. 

But in my opinion, the auto-in/out mode does not rely on SLRD <-> FLAGD.

EDIT:

Latest Version of traces:

https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141024_0540p.jpg

Preview attached.

[psynapse]

Again, filled with admiration.   I have neither the courage nor the ability to do that.  That Rdy0 line makes all the difference.  And I see a couple of plated through holes that could be important. (but then I checked a photo of the back of the PCB, just one heavy track, so no you have found everything.  Good news)

Sorry thought you were using LTSPICE rather than multisim.  Yes, I guess. increasing the value of all the external resistors will reduce the variability due to the internal resistance of the 4052. But as you say, it will hit the gain bandwidth problem....... But perhaps not...... we do not need to change the gain of the amplifier ..... the only problem might be the change in input/output impedence that will be needed.

And to misquote you, me "I am firmware, not software". Happy to tinker around at that level, but I am old and never got to master OOPS!  So I am hoping that with you at hardware (and clearly some software), me at firmware (with a bit of hardware and software), perhaps we could look to donut6 for the soft side .... But he has already said he is busy .... We all have lives!

[doctormord]

Resoldered the IC and tried sigrok:

http://sigrok.org/wiki/Main_Page

There also is an open source firmware available - FX2LP mode. With the eeprom-jumper removed, the scope is running in devkit mode (Cypress standard) and just reads raw from the 2 ports via FIFO. Also simple control codes are implemented. (I think async fullspeed, so no IRQ)

As you're the "firmware", here is my idea:

- Sampling at max samplerate all the time
- "timebase" just in software
- implementing the controlcodes for the gainstage
- done.

I see some data coming in in Pulseview, the actual problem is, the ADC is getting no clock from the CYPRESS. (needs to be configured)

Infos about firmware:

http://sigrok.org/wiki/Fx2lafw

Sourcecode of firmware:

http://sigrok.org/download/source/sigrok-firmware-fx2lafw/

I further simulated some things of the gainstage with the right opamp models. Gain varies with frequency at frequencies >~8MHz. Changing the values at Q1 to 100R would help abit for this stage. GBW is varies with gainsetting as well. There definitely is some compensation needed. 

To minimize temp-/amplitude drift within the analog switches, the CD4052 may be changed to some 74HCxxxx. (With 1/10 of Ron)

V(n004) is the output of Q1.
LTSpice stuff is attached as well.

[ganzuul]

In a desperate effort to keep up with you guys ( )  I soldered a wire to the resistor on the clock line and tried to read the clock ticks with my Propeller uC. The verbatim reading I get is a few 100 kHz under 13MHz, and by making a few other measurements I presume that the ADC is always actually running at XTAL/2. - If of course I have not made some grave oversight regarding the performance of my uC, which remains possible. I made a thread on the Parallax forums but suddenly the forum decided that a moderator needs to review my posts. Perhaps the reading I get is a result of aliasing.

[donut6]

Here's some code for the DDS140 that may be useful for experiments.

Good luck compiling. It may also destroy your device.

This needs wxwidgets, libusb , ...

Makefile ->

Code: [Select]

CXX := g++
CXXFLAGS := -O2 -g -DGL_GLEXT_PROTOTYPES -I./

scope.o: scope.cpp
$(CXX) $(CXXFLAGS) `wx-config --cxxflags` -c scope.cpp -o scope.o

scope: scope.o
$(CXX)  scope.o -o scope -lusb-1.0  -lGL -lGLU -lX11  `wx-config --libs --gl-libs`

[psynapse]

Donut6,
Many thanks for the code, I will look at it very shortly.

Doctormord
1) Improving performance of the input stage. Putting temperature variability to one side for a minute, I think that this is the key curve for a CD4052 is shown at attachment
I note two things.  Running the device at a higher voltage reduces both resistance and non linearity.  In principle, the higher supply voltage should not cause a problem in terms of analogue inputs/outputs,  but the multiplexer select lines would need buffering.  So that is the quality approach
Secondly at 5V supply, and 0-1V operating range, linearity is not too terrible and resistance comes in at 400 ohms.  This is the "do nothing" approach!

On the firmware front, happy to give it a go .... but I guess I must buy a DDS120, which will need to be from next months pocket money!  Implementing gain and timebase should not be the difficult part.  The key part is of course reliable data transfer at maximum rate.

I am guessing you are using Cyconsole to load up the FX2 with the other firmware and then re-enumerating? If we can get that path working it is going to save a lot of development time

And a word of warning to all. As a proof of principal, I wanted to change exactly 1 bit in the default firmware of theDDS140 (The IFCONFIG bit that switches out of GPIF debug mode).  Made the edit in cyconsole and re-enumerated. "Bad device".  It took a long time comparing hex dumps to find out that cyconsole was systematically changing the contents of 20-3F in the eeprom when I rewrote my two bytes in a completely different part of the memory map D30,D31.  I copied back by hand the damaged fields and all is working.  My priority at the moment is to get the default firmware into an iic file (and find out how to generate an iic) before trying any further firmware mods, no matter how small.

Ganzuul,  if I am right that resistor is connected to IFCLK, which when driven by the FX2 can only take on values of 30 and 48Mhz.  So I think your aliasing explanation is right, you have 48/4

[psynapse]

Donut6

Wow lots of dependencies!  What did I expect?   You work on your machine and this is work in progress.

Struggling with the dependencies  wx/wx.h

I have installed as per the screen snap, any quick ideas please?

[donut6]

psynapse,

Try libwxgtk3.0-dev

And libusb-1.0.0-dev

make scope
./scope

You'll need an udev rule set up for 8312 8312

[doctormord]

No need to have .iic, you can flash straight .bin with CyConsole. (Just select .* all files in the dialog).

I had done this before with success (and verified via I2C dump). (I wrote something on page 2/3 about this here)

[psynapse]

Donut6

Both already installed ..... the dreaded path problem then. I will look in the morning, but thanks anyway

Doctormord

Thank You. Yes, I remember somebody had a problem, but had not remembered the .bin solution.  I followed your post in order to get the hex out of the DDS140 to start with.  Very glad I did!  And now you mention it I remember a hex to bin converter somewhere in the cypress software

All
Sorry, away from keyboard this weekend , it is our village fête this weekend

[donut6]

psynapse,

Does this command work?

Code: [Select]

wx-config --cxxflags
If so, perhaps the Ubuntu wxwidgets package doesn't set up the include path correctly.

also

Code: [Select]

wx-config --list

[doctormord]

Doctormord
1) Improving performance of the input stage. Putting temperature variability to one side for a minute, I think that this is the key curve for a CD4052 is shown at attachment
I note two things.  Running the device at a higher voltage reduces both resistance and non linearity.

We don't have higher voltages available here. (Still unknown, how the negative voltage is generated)

In principle, the higher supply voltage should not cause a problem in terms of analogue inputs/outputs,  but the multiplexer select lines would need buffering.  So that is the quality approach
Secondly at 5V supply, and 0-1V operating range, linearity is not too terrible and resistance comes in at 400 ohms.  This is the "do nothing" approach!

I would rather change the multiplexers to 74HCxxxx.

I am guessing you are using Cyconsole to load up the FX2 with the other firmware and then re-enumerating? If we can get that path working it is going to save a lot of development time.

Actually the firmware is loaded to the Cypress RAM when starting the software (Pulseview). The Scope enumerates with the standard PID/VID when eeprom jumper is open. So firmware-changes could be done at runtime.

(The original firmware is still in the attached eeprom)

Zigrok/Pulseview includes a tool (Zadig) to change the driver for the Cypress on the fly. (WINUSB, libusb, libusbk.. )

Ganzuul,  if I am right that resistor is connected to IFCLK, which when driven by the FX2 can only take on values of 30 and 48Mhz.  So I think your aliasing explanation is right, you have 48/4

You may check if IFCLK is connected to CLKOUT somehow.

Curious, how does the ADC gets clocked?

Regarding the EZ-USB Technical Reference Manual:

http://www.cypress.com/?docID=48811

page 125, the IFCLK can only output 30/48MHz from its internal source. (I must review the trace at IFCLK and CLKOUT.)

Maybe its like:

24Mhz crystal -> PLL (48Mhz) -> /2 divider -> 8051 Core + CLKOUT [pin out] (24Mhz) -> IFCLK [pin in] + ADC_CLK (24Mhz)

At DDS120, it is not. So the ADC is running either running at 30 or 48Mhz.

[psynapse]

Hi Donut6,

Thanks again, it looks as though from the replies the install is correct

Does this command work?

Code: [Select]

wx-config --cxxflags

-I/usr/lib/i386-linux-gnu/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread

If so, perhaps the Ubuntu wxwidgets package doesn't set up the include path correctly.

also

Code: [Select]

wx-config --list

    Default config is gtk2-unicode-3.0

  Default config will be used for output

  Alternate matches:
    base-unicode-3.0


But please leave it,  I will sort it after the weekend..... Your time better spent on advancing the code. 


Doctormord

I will get back to you on your observations, too little time today.  My apologies.  Only thing to note immediately, the 74HC4052 seems slightly worse in terms of resistance/linearity. From my standpoint, I would rather correct in software in the PC through a LUT.  But a redesign from scratch, I agree with you, always better to get the hardware right to start with. Weird about the negative rail generator.

[doctormord]

I actually connected CLKOUT to the CLKIN of the ADC (bypassed IFCLK) - works. Not sure if 12 or 24Mhz, but i dont see any change in samplingrate. (So even 240kHz in software shows valid data)

 

Only thing to note immediately, the 74HC4052 seems slightly worse in terms of resistance/linearity.

From http://www.nxp.com/documents/data_sheet/74HC_HCT4052.pdf

they perform much better.

[ganzuul]

How to implement -> EZ-USB TRM -> 9.2.8 Implementing Synchronous Slave FIFO Reads

From 9.3.2., i would guess, they're using EP2 or EP6 with 1024byte size (As the smallest received packets are 1k) . FLAGD is then programmed to represent a FIFOFULL state (15.5.3 ff page 223).

By that, the FIFO size could be increased up to 4k when needed (slower sampling)

The question is, will FLAGD be held "high" only as long as the FIFO is full, or has it to be reseted when it once triggered by "FIFO Full"? If so, this would mean:

ADC is sending data to the FIFO -> FIFO gets full -> FLAGD is triggered (going "high) -> this raises SLRD, so IFCLK is incrementing the FIFO pointer on each rising edge of IFCLK while SLRD is
asserted. -> Data is being sent -> FIFO pointer reaches 0x000. FLAGD is then to be cleared. For the time of data transfer, the scope is "blind".

This could be avoided if switching from EP2 <-> EP6 respectively. So one FIFO gets filled by the ADC, while the other is being sent to the host.

A totally different approach would be (9.3.4 Auto-In / Auto-Out Modes page 111 ff), with direct streaming.

This has to be clarified by someone who knows. 

O0

USB spec says all transfers are initiated from the host, which could result in huge variances to when the host polls the device. Isochronous mode decreases this variance a lot, and for our purposes iso means we require less from the 4K buffer.

EP2 can be configured to be 4x 1K, and it doesn't look like to me that there are any special considerations to this. It's just a single 4K buffer. Meanwhile in the examples I've looked at, EP6 is used for iso and they recommend 512 for iso. I'm not sure if one can use EP2 and get full bandwidth for iso, but I also don't think it's unreasonable to demand we get an entire USB 2.0 host controller all to ourselves so we don't need to share resources.

To logically couple the device to the host, I think each host -> device poll should tell the device to keep alive. Since this is an RX-only application we don't have to care about latency, so we can let big buffers take care of perceptual continuity. We won't know exactly when a signal arrived unless we code that information into one of the analog channels. I can't think of an application where we'd need to know the device time accurately though...

[psynapse]

Just briefly.

I have been digging aroung in the firmware, trying to find out more about the DDS140 94(0A) command which gives continuously sampled 240Khz data.  I have tracked down the special wavetable that is invoked only for this timebase rate (which strangely is only available when you select 1second timebase)

Coming to grips with the wavetable editor,  the FIFO read mode has 4 states, lasting 1,99,99,1 clock intervals.  And 48Mhz/200=240khz.  There maybe hardware reasons for the speed limit, and at higher rates there will certainly be USB transfer rate limits, but I shall be playing with these values to see what other timebase rates could be available (as the only truly continuous data mode for the DDS140)

In agreement with what doctormord says, this wavetable mode would see the ADC running at full speed and the fifo taking 1 sample in every 200 48Mhz clock periods.  I have no way of knowing, but it seems distinctly possible that this is the standard mode for the DDS120. Change the state periods, change the overall sampling rate.  I need to find the wavetables in the DDS120 in order to know more.

For DDS140 owners, the pattern 63h 63h only seems to appear once in the eeprom image, and these are the two 99d clock period waits in the fifo load.

The downside is that the scope software is simply not capable of handing the inrush of data. Custom display software needed.  More on Monday

[doctormord]

 

My testings with sigrok are not consistent at the moment. I thought, it should be fine to connect CLKOUT to CLK_ADC to have em running, but the readings makes no sense to me.

Mostly i get some 00 00 00 FF FF 00 FF garbage. This might be due to aliasing from the hostsides sampling frequency, as this could altered from 100k to 24M. Also the second port does not geive any results at all. Might be, that because the input multiplexer is not set valid and the corresponding output pin (FX2LP) is in tri-state. Couldn't check any further. Having another FX2LP logic-analyzer connected gives nothing valuable, as it is limited to 24M, so heavy aliasing in the results.

[psynapse]

Doctormord,

When you talk of CLKOUT, I presume you mean pin 1 on the FX2.   IFCLK on pin 75, is the usual clock as you know.  I note that both CLKOUT and/or  IFCLK can be inverted under software control and that both can be prescaled.  So even if there is no difference in frequency, there will be differences in both skew and phase between the two.  And as you rightly say,  without a logic analyiser of 250Mhz or more, you will not be able to visualize the problem.

Have you measured the frequency on the two pins?  On the DDS140 these are fixed, ie once the firmware setup routine has run, these are static values.  If this is true for the DDS120 too, and both clocks run at 48Mhz, it suggests that your explanation that the FX2 subsamples the ADC (running at 48Mhz) at a 1/N rate, and in all probability this is achieved by reprogramming the GPIF wavetable.  If both these assertions are true, then the DDS120 is already delivering maximum performance, and the question becomes one of best firmware/software to support transfer.  If IFCLK is running at 30Mhz, flipping a bit in firmware should get you the performance you seek.  (The only way the DDS140 gets "more" performance is by buffering in the ADC values at 80Mhz into SRAM and then replaying them out to the FX2 FIFO at 48Mhz.  But that extra performance is at a high price)

So I have not given much help, except to say I think your analysis is correct.

Back to the Fête

[doctormord]

Yes, CLKOUT can be scaled (:1, :2, :4), while IFCLK is fixed to 30/48MHz when used as output. CLKOUT is always the same as Core-Clock, they share the same pin/divider. I need to measure CLKOUT to see what's going on. At 48MHz, the ADC would be slightly overclocked. But if this is true, they would advertise as 100Msps.

[psynapse]

At 48MHz, the ADC would be slightly overclocked. But if this is true, they would advertise as 100Msps.

Maybe even 200Msps 

"ADC slightly overclocked" In the DDS140, and several rigol oscilloscopes the 40 meg part is overclocked at 80 or even 100Mhz.  It seems to work, although I expect badly.  The ADC is 5 bits of capacitive stages and 3 bits of flash,  I am taking this to suggest thay you might get 6 bits at 80Mhz

My 74lvc74s have arrived:- the trouble is that the are ssop (I had thought they were soic).  When I have good enough eyes to solder them,   I will measure the clock rates on the DDS140.

Ganzuul:

I have not had the time to look this weekend, but I had understood that the four buffers could be set up as a ring of four, one filling, one emptying and (in steady state) one full buffer waiting to be sent and the fourth empty buffer waiting to be filled.  I will look into it more.

[doctormord]

I checked for the clocks at CLKOUT and IFCLK, they're the same at all times. Samplingfrequency does not affect anything, so the ADC and8051 are running at 48MHz all the time. Dunno if the phase-shift is important to note. (Blue is CLKOUT, Red is IFCLK)

(Only had a Rigol 1052E unaltered avail.)

Code: [Select]

Analog Ch  State   Scale    Position   Coupling  BW Limit  Invert
CH1        On      1.00V/   40.0mV     DC        Off       Off
CH2        On      1.00V/   -2.04V     DC        Off       Off

Analog Ch  Impedance   Probe
CH1        1M Ohm      10X
CH2        1M Ohm      10X

Time    Time Ref    Main Scale    Delay
Main    Center      5.000ns/      -409.3000ns

Trigger  Source      Slope    Mode      Coupling     Level    Holdoff
Edge     CH2         Rising   Auto      DC            1.12V   500ns

Acquisition    Sampling    Memory Depth    Sample Rate
Normal         Realtime    Normal          500.0MSa   



[ganzuul]

psynapse, I think the ring buffer you described is optimal.

As for squeezing more information through USB 2.0... The best scheme I have been able to come up with is to connect the two channels, interleaving them together and setting the gain so that information from the higher-quality side of the ADC pipeline is preferred. This just means that fewer bits are wasted as noise, rather than each bit representing more sampling information.

There doesn't seem to be enough gates running at 1 instruction per cycle, 16 bit wide, to allow for better processing gain.


Other than that, I'll probably start scraping together money for the new Rigol scope! Its price/performance really appeals to me.

[psynapse]

Sorry for not replying sooner, a friend with problems came to stay.

Doctormord:
Thank you for the information.  That seems completely consistent with the idea that the FX2 simply takes 1 in N of the samples always made at 48Mhz and transfers those.

Ganzuul:
Which Rigol are you thinking about buying?

All:

I have only found a few minutes to experiment.  However I can confirm that the two bytes I identified in my earlier post are indeed those responsible for determining the sample rate.  I have changed 63h to 31h, changing the default sampling period from 200 cycles to 100 cycles (1+49+49+1).  The measured clock rate is now 480khz and wireshark shows that all the samples are presented to the PC.

The PC software does display the acquired data (very slowly) ,  but as Doctormord has already noted with the DDS120,  the acquired data arrives independently of the go commands and there is a growing backlog of data as time passes.

All this means that a small firmware modification will allow the DDS140 to function in the same way as the DDS120 when necessary, and with many timebases possible.

So now the question is generating some PC software that actually works.

I shall start looking at the DDS120 firmware now to see what zaps are possible to the timebase.

[mmark]

Donut6

Both already installed ..... the dreaded path problem then. I will look in the morning, but thanks anyway

Doctormord

Thank You. Yes, I remember somebody had a problem, but had not remembered the .bin solution.  I followed your post in order to get the hex out of the DDS140 to start with.  Very glad I did!  And now you mention it I remember a hex to bin converter somewhere in the cypress software

All
Sorry, away from keyboard this weekend , it is our village fête this weekend

I was able to compile scope.cpp after installing libglu1-mesa-dev (in addition to libusb-1.0.0-dev and libwxgtk3.0-dev) on ubuntu 14.04...

Since I only have a DDS120, I am currently trying to get it to work with that. I added a test for 0x8102:0x8102 and it is found, but I am getting an assertion "../src/common/glcmn.cpp(59): assert "IsShownOnScreen()" failed in SetCurrent(): can't make hidden GL canvas current" when starting and no GUI elements are drawn. This is in a VM, I'll try on a real PC later tonight...

Mark

[ganzuul]

Ganzuul:
Which Rigol are you thinking about buying?

***

All this means that a small firmware modification will allow the DDS140 to function in the same way as the DDS120 when necessary, and with many timebases possible.

So now the question is generating some PC software that actually works.

The cheapest one, the DS1054Z! 

Really glad to hear the DDS140 can function the same way. Have you been able to determine if the JTAG fuse is blown on the CPLD? If not, that's quite interesting. =)

Since I only have a DDS120, I am currently trying to get it to work with that. I added a test for 0x8102:0x8102 and it is found, but I am getting an assertion "../src/common/glcmn.cpp(59): assert "IsShownOnScreen()" failed in SetCurrent(): can't make hidden GL canvas current" when starting and no GUI elements are drawn. This is in a VM, I'll try on a real PC later tonight...

Mark

Starting the scope with strace, such as '$ strace ./scope' gives a lot more information about what the program is doing. It sounds very likely to be an issue with OpenGL support in the VM though.

[psynapse]

Ganzuul,

Not a JTAG expert. how do I determine if the fuse is blown and how do I get useful information.  I have a "bus pirate" which will do jtag, but what questions do I ask the CPLD (if the fuse is not blown).  And I have no idea (yet) on how to interpret the results !  Is there a "disassembler" that will give me a pseudo schematic representation of the way the logic is "wired"

Mmark,

Welcome aboard.  Yes I already have libglu1-mesa-dev installed, but no compile    Are you 32 or 64 bit Ubuntu 14.04. I run both, Perhaps you would be so kind as to post the binary .... if nothing else it will highlight what other dependencies I am missing.
EDIT:  My mistake, I thought I had libusb installed, but had failed to install the dev.   Now, like you, I get

./src/common/glcmn.cpp(59): assert "IsShownOnScreen()" failed in SetCurrent(): can't make hidden GL canvas current

And this is on a machine as real as you can get

[ganzuul]

psynapse,

I'm not an expert. Far from it. What I know is that Altera must release a complete JTAG-related description file, on request if needed, for them to be allowed to claim IEEE 1149.1 compliance. This lets you perform a JTAG boundary scan, and enumerate what I presume to be a kind of API.

There are a myriad of companies who provide the service of "code extraction". CPLDs are non-volatile, so they don't store their information in an EEPROM. Still, the companies say they can extract the firmware and apparently there have even been complaints that the fuse-blowing mechanism of the MAXII can be circumvented. - I very much doubt that these companies employ Ion Beam Workstations etc. to do the code extraction, but rather they have simply read a lot of product manuals.

There are talks, by smooth speakers with pleasant English accents, who do a good job of explaining the RE bits:



I'll see if I can find out how to dump MAXII firmwares, and report my findings.


psynapse, Mmark,

I got scope.cpp to compile and run on Ubuntu 14.01 LTS, but not capture data. I use the proprietary AMD driver. The trick was to save the Makefile that donut6 quoted into a file named "Makefile" in the same directory as scope.cpp, and run 'make scope' from the CLI.

I have the DDS120 though, and libusb isn't happy with me simply changing ven/dev ID in scope.cpp. I will have to review the discoveries made about the control codes, and what libusb expects out of udev etc. etc. strace produces a huge amount of information. Perhaps a log analyzer exists for it already...

[psynapse]

Ganzuul,

Many thanks, there is a lot of useful information in your post. I'll dig out the bus pirate and see what I can do.

Mmark,

I think we are getting the error on execution because (as it says in the glcmn.cpp source)

bool wxGLCanvasBase::SetCurrent(const wxGLContext& context) const
{
// although on MSW it works even if the window is still hidden, it doesn't
// work in other ports (notably X11-based ones) and documentation mentions
// that SetCurrent() can only be called for a shown window, so check for it

wxASSERT_MSG( IsShown(), wxT("can't make hidden GL canvas current") );

My challenge is finding out which window!

I also get several

(scope:7780): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17

warnings

BTW,  I do not know libusb, but note that the eeprom (for both the DDS120 and DDS140) store the following data in their first 8 bytes
0 0xC2
1 Vendor ID (VID) L=47h
2 Vendor ID (VID) H=05h
3 Product ID (PID) L=31h
4 Product ID (PID) H=21h
5 Device ID (DID) L
6 Device ID (DID) H
7 Configuration byte

To my mind that means that the USB code should be 0547:2131.  I cannot square that with Donut6s code, and when I have fixed my problems I will check this out. Donut6,  your code is proving really useful, could you give an idea on the VID/PID issue?

[donut6]

psynapse,

Check out page 53 of the EZ USB TRM PDF - C2 load format. Apparently, the VID/PID/DID here isn't used by most applications.

On the assertion error. This line:

Code: [Select]

    glPane->SetCurrent(*m_context);

Must be called too early. (I'm using debian/kde)

So, delete that line, and move it later on... not sure where!

Try here after Layout() is called (later on in the same function):

Code: [Select]

    this->Layout();
    glPane->SetCurrent(*m_context);

edit: and add Show() and Raise() while we are at it:

Code: [Select]

    this->Layout();
    this->Show();
    this->Raise();
    glPane->SetCurrent(*m_context);

good luck!

[psynapse]

Donut6,

yep, those code mods worked a treat.

First time I have connected the scope to my linux system, and of course you are right, it enumerates at 8312 8312

A word to the folk like me. running scope as root does not work.  I had to change the permissions in dev/bus/usb/XXX/YYY to allow myself access and the application works.
Obviously more work to do, but the fundamentals (ie the difficult bit) are done.

 Well done donut6

EDIT:
Started playing with the code and note that the 39khz mode does not acquire.  Have added a menu option for the 940A command (which is 240khz), and at first that did not work either.  That is simply explained :- the FIFO never shows full (because it is never full!).  By the simple expedient of commenting out the line
 
    if (w == 0x21) // fifo full

the software is forced to get data from the buffer, which it does! And everything works This is clearly not the right coding solution however.  In addition, if this is the way the DDS120 normally works, the software as it stands will not handle that device.

None of this should be seen as criticism:- I am delighted to get my hands on some code that works, and works under linux . As I have already said, Donut6s work is a really sound foundation on which to build. Bravo.

[mmark]

Psynapse & Donut6,

got the original scope.cpp to work on my real linux box (again, ubuntu 14.04, nvidia X11 server...). Did not try the suggested changes to see if those make it run in the VM as well.

I tried for quite a while to get my DDS120 to work with scope.cpp, but I never got any scope data from USB. After installing USBPCap and wireshark I saw that the original software (well, I only tried the Rocktech BM102) does not do any FIFO checking at all with the DDS120. Instead, there is a 0x33:0x0 command from the host and then an interrupt transfer for every frame. So I went ahead and implemented the asynchronous interrupt transfer and got some data, YEAH!! (never die much of USB programming before, so my code my look strange...) Then I also tried just the synchronous transfer without the FIFO check and this works as well. I tried this on Linux and MacOS and it works on both!

Funnily enough you don't need any initialization with the DDS120, just polling for data works right away after plugging it into the USB port.

I removed all the graphics related code for my test since I mainly develop on MacOSX these days and didn't have wxWidgets installed. If anybody is interested, my code (as well as Donut6's) is attached below. The paths in the Makefile are expecting libusb-1.0 to be installed in /opt/local/lib and /opt/local/include (as it is if you use macports to install libusb-1.0 and didn't change the default path), you need to change those if your libusb-1.0 is installed somewhere else.

My plan is use Qt/Qwt to develop a simple scope program for MacOSX and Linux (I am quite familiar with Qt and Qwt, so I prefer that over wxWidgets, but that's just my personal preference).

BTW: it's kinda strange that zip attachments are allowed on eevblog, but not tar.gz...

Cheers,

mmark

[donut6]

mmark,

Nice one!

I believe OpenHantek is a Qt app. Perhaps a candidate for forking?

As for next steps. Speeding up the USB transfer? Custom firmware (maybe more important for the DDS140?) and a dedicated USB capture thread on the app side.

[doctormord]

Hmm, maybe channel interleaving or differential input, there are actually 2 multiplexers free to use. )

Good work guys!

[psynapse]

Looks like this community is cooking!

On the "PC" based app, I am torn between the work that Donut6 has already done and the QT approach .... I have quite a few ideas I was planning upon putting into the Donut6 code, mainly linked on the display side (zooming, scrolling, interpolating, soft trigger etc).

Mmark, I am tempted to use the same continuous data mode (from the DDS120) on the DDS140 as my default data collection mode (but keeping the other high speed flash sampling mode for sampling above 10/20 megs)  :- I am fairly confident that I can add a few lines of code to the firmware to get a range of timebases up to 8Msps  per channel, 12 is less clear and anyway represents the upper limit of sustained throughput for a device on USB. At the moment I have the 940A mode running at (2x)480Khz rock steady.

Donut6, do not want to tread on your toes, do you want to sort the DDS120 data acquisition mode in the software, or should I have a go.

Doctormord,

I would suggest that (for DDS120 users) channel interleaving might be really useful, doubling the maximum acquisition rate, but wouldn't that need a small hardware modification? There are several ways of tackling that problem,  which one are you thinking of?  Differential input, I am not so sure about .... I would probably forget to respect the common mode voltage and connect the two probes across two lines at 18v!

All:  If I revisit the firmware with a view to adding new continuous mode time bases, one of the easiest patches is to steal an existing command from the following table:
DW    case22
DW    case23   
DW    case24   
DW    case33   
   DW    case34
   DW    case35
   DW    case50
   DW    case60
   DW    case61
   DW    case62
   DW    case63
   DW    case70
   DW    case71
   DW    case72
   DW    case73
   DW    case74
   DW    case75
   DW    case76
DW    case77
DW    case78
DW    case79
DW    case7A
DW    case7B
DW    case7C
DW    case7D
DW    case90
DW    case94
DW    caseD0
DW    caseD1

Which code is the best candidate? (patching a new address into this table is a change of just two bytes to existing firmware, the wavetable modification firmware can be put up in unused eeprom)

[ganzuul]

I'm really impressed with this all too. The thread has exceeded all expectations.

OpenHantek is GLPv3, has lots of code comments, and has a qmake build system set up. I have a little experience with Nokia Qt from before, so I might be able to make useful contributions once I re-orient myself to Qt on Linux.


psynapse,
Regarding the CPLD; According to bullet point 4 from the bottom of the list on page 9 of http://www.altera.com/literature/an/an489.pdf one can verify that the bytes written are being read back verbatim. This of course means that the entire user flash memory can be read just like we did with the EEPROM. I'm unsure if the UFM actually contains the code we expect, but it would seem highly redundant if it didn't.


Could you describe which two bytes in the firmware to patch, and if there's a special trick to it, how to do it? It could be beneficial if we try them all and come up with a short list for further consideration.

[psynapse]

Ganzuul,

The big question is which two bytes!

1)  At the moment I patch manually (using cytools) the two bytes in the ram copy of the wavetable, these are two contiguous bytes of 63x 63x. If you dump the eeprom in cyconsole you will get the following line

0A40  00 00 3F 01 63 63 B8 01 01 01 07 02 00 00 01 00 .

Those two 63 are the wait periods for the second and third period of the state machine.  In total the wait period is 1+63x+63x+1 =200d and 48Mhz/200=240khz.  To invoke this mode you need a 940A call, which you can get by selecting the 1s timebase (from the drop down list). For example, my DDS140 is running with the two 63x changed to 31x, and its data rate is now 480khz (for each of the two channels).  With the warning that you could ruin your DDS140, you could change these values to anything between 1 and 63x, it may well be that the two byte can have different values too.

ALL WARNING!THIS APPLIES ONLY TO THE DDS140, AND YOU SHOULD VERIFY THE EEPROM CONTENTS ARE AS SHOWN ABOVE.  NOTE TOO THAT CYCONSOLE HAS A STRANGE HABIT OF CHANGING SOME LOW MEMORY AS WELL. SO DUMP THE BOTTOM 80x BYTES, PATCH THE TWO BYTES SHOWN ABOVE AND THEN CHECK THE LOW 80X BYTES FOR UNPLANNED MODIFICATION.  FOR SAFETY HAVE A COMPLETE COPY OF THE FIRMWARE FOR RELOAD IF NECESSARY

The same 6363 pattern exists in the DDS120

0A20 3F 01 63 63 B8 01 01 01 07 02 00 00 01 00 00 00

2) Note however that the two bytes I am proposing to patch (in my last post) is a  two byte address in the case jump table, so that I can redirect an existing command to some new code that will do this patch under software control. All that will then be necessary will be to issue a 940A command to update the wave table

I have not forgotten the JTAG on the CPLD,  I just have not got round to it!  I've downloaded the information you've flagged up and shall read it right away

[psynapse]

Donut6

I have a small problem with the code.  The data buffer is constantly overwritten.  This means that you cannot search the data for start points and you must expect to see one or more splice points of new data .

A couple of approaches are possible:- Tell the scope to stop sending data (but we all know that it does not like that, and if we are to support continuous modes on the DDS120/140 this is a problem .
Lock the input buffer whilst data is copied out from it.
Support multiple buffering in order to give enough time to read a buffer.

I do not know enough about libusb to know which are possible, do you have any sage words please?

EDIT
I do have a trigger of sorts working now.  (It is important to remember that the first 27 bytes of "data" are not in fact scope data!)
I also seem to have sufficient control (by using the 34 command) to avoid buffer overwrite, but that is a provisional finding! 5If I have not noted it before 34 00 and 34 FF are start and stop

[donut6]

psynapse,

Support multiple buffering in order to give enough time to read a buffer

The function scope_usb::scope_get_buffer writes into the buffer. I imagined this running in a thread, populating a large ring of buffers instead of the single "scope_data" array.
The "app" thread can then take it's time doing any sort of analysis, rendering, etc
I expect there is open source scope that already does this, so perhaps no point reinventing the wheel here.

Feel free to progress things any way you see fit as I haven't had time to spend on this project.
Although I may have a quick attempt at writing a proof of concept sdcc/fx2lib firmware.

[psynapse]

Donut6

Thanks, yes, seems a good way forward.  I can write the code to fill a ring of buffers, but what I am less clear about is how I spawn an autonomous thread to fill those buffers.  I know you are short on time, so can you point to some example code which can bring me up to date (I note that your code already has "THREAD" in it, how far advanced is that please?). I will also look at the triplespark guys code, maybe he has a ring of buffers (although as I recall he has a "layer" between the App and libusb to do the buffering).

And "no reply" is also entirely acceptable :-)

[doctormord]

Why not having an array in an array to create a ringbuffer.

I.e. 1024byte array in a 32 field array built as a ringbuffer. I use something similar in a microcontroller to have float averaging.

[psynapse]

Doctormord,

Yes, that would be my solution of choice too.  The trouble is working out exactly how to pass a pointer to the OS (copying the data from the OS buffer to the application buffer represents too much of an overhead)

Mmark,

I have looked at both wxwidgets and qt and prefer qt I think! So my current plan is to port elements of the donut6 code into qt and then add to it. But to avoid us both doing the same thing, what are your plans/progress please?

and I need to patch the firmware and look at the jtag!

[mmark]

Some progress:

Got OpenHantek to compile on my Mac with Qt5.3 & clang and added some initial code to talk to my DDS120:

Neither range setting, voltage scaling, sample rate setting or triggering works yet, but I was quite excited to see some real oscilloscope data on my screen today for the first time... It's a start!

Don't know how to share this in the best way. Do you guys want a github project or should I just zip up the src and post it somewhere? Just in case someone wants to play with the code (it in rough shape..., you will need to change the OpenHantek.pro for sure to get it to compile), but I'll attach a zip just in case.

mmark

[psynapse]

MMark

Well done, have just downloaded your code to play with.  Your problems on scaling etc ... it is late, and I have not checked but Donut6 and I have been working on DDS140 codes and I am not sure that we have 100% verified that they are the same, similar yes, but ... so beware


I have been working on getting a platform for firmware modification.  Getting the tools together etc.  For those that are interested "cycfx2prog" (at least in the Ubuntu repository, and source available) will download an Intel hex file into the RAM of the FX2 (if it is started with its eeprom jumper off) and from there will allow the code to execute.  This is much faster than loading the eeprom each time, and more importantly gives you a fall back to a working device at the flick of a jumper.  To verify this I have turned the original eeprom dump into an intel hex format file, which can be reloaded to the DDS140 and works.(attached)  More importantly (for me), I have also generated annotated assembly code which is bit perfect with the original .... meaning of course that firmware additions can now be added very easily.

[mmark]

Psynapse,

I don't have any problems with the codes (I am using the codes for the DDS120 as identified by doctormord, which seem to work in my test120.cpp application as expected). It's just that the code inside openhantek is --- aehh ---- somewhat complicated to say it politely .
So I need to figure out how I need to scale the data in the way openhantek wants it to be scaled and add functions to actually change the gain and the sample rate of the SainSmart scopes. So far I just removed all the code for the Hantek scopes and just implemented the getSamples methode. In the meanwhile I also implemented the setCoupling methode, which seems to work correctly, but I need to find a clean way to remove options (like GND coupling) which are not supported by the SainSmart scopes...

[doctormord]

Great work guys! ^-^

[psynapse]

mmark,

Well, that you have got good DDS120 codes is good news (so well done to Doctormord as well).  I know what you mean about the openhantek code. I looked as well and decided that it would be quicker to use Donut6's code to get the data (and control the scope) and then to write a whole new front end in QT ..... that way I have a working system I can improve (by adding buffers as previously discussed, as well as extra features).  That decision as to whether it is better to adapt existing code or write new code is always hugely difficult. 
For me (with a DDS140) the new code route seems better, because there is a second operating mode which does not exist in the basic Hantek and because some of the features I want to add exist neither in the hantek, dds120 or dds140.  In particular something resembling an external trigger, or at least a signal outputted to mark beginning / end of sampling

Doctormord;

I have looked at your photos of the DDS120 board, and as far as I can see INT4 INT5 is not connected anywhere .....  Please could you confirm that I am right .... My intention is to use INT4  INT5 as an external trigger (of sorts).  Also, what advice do you have on buffering the pin  .... which series of devices gives the best isolation, do I need clamp diodes etc (Not Int4 because there is a potential clash with FIFO interrupts, although these are not currently used in the DDDS140)

[doctormord]

Confirmed.

Regards,

doc

[sandos]

I was looking at DDS120 before buying the Hantek6022, but it seems the community around the sainsmart is even more lively than that around the Hantek!

I assume you people have already seen https://github.com/rpm2003rpm/HT6022_Driver which is a libusb based driver for the 6022. You guys seem to have an even better grasp of things, so this might not change anything. I am curious though what the exact differences are between the DDS120 and the 6022? I am planning on writing an android app to talk to the Hantek, by simply translating the libusb code to androids native usb host API. Was planning on doing it in java to start with, even though performance is likely to suffer. I was also planning on using the 1Khz square wave to try ascertain any "dead periods", but I will have to see how that works out.

[doctormord]

The 6022 got no AC-coupling.

[doctormord]

I would suggest that (for DDS120 users) channel interleaving might be really useful, doubling the maximum acquisition rate, but wouldn't that need a small hardware modification? There are several ways of tackling that problem,  which one are you thinking of?

Sure, we need to double the ADC-frequency at first, i.e.:

http://www.maximintegrated.com/en/app-notes/index.mvp/id/3327

and then attach a phase-splitter (0/180) to feed both channels seperately. The AFE might some compensation due to lower the (now) lowered input impedance.

Alternatively, the clock needs to be shifted by 1/2 clock-cycle to feed into ENCA/ENCB. (Without frequency doubling)
Should work with "data aligning enabled" - or the delay needs to be corrected in the host-app.

[psynapse]

All,

Sorry I have gone quiet a couple of days, I have been improving my Qt skills (which did not exist).  Except for the all important trace display, I now have Donut6 code running under Qt,  which is probably easy for all you young guys out there , but has proved very difficult for me. When I have graphics up and running, I shall go back to the firmware.

Doctormord,

Obviously phase inverting the clock to one ADC is the easiest solution conceptually, but I rather guess it demands taking the ADC off the board in order to cut the trace beneath the chip itself.  That is something you are capable of,  but it is way too difficult for me! Perhaps lift a leg (but a pretty poor engineering solution).

Also, not sure whether you have seen this information from the ADC datasheet

"The other option allows the user to skew the B channel output
data by 1/2 of a clock cycle. In other words, if two clocks are fed
to the AD9288 and are 180° out of phase, enabling the data
align allows Channel B output data to be available at the rising
edge of Clock A. If the same Encode clock is provided to both
channels and the data align pin is enabled, then output data
from Channel B is 180° out of phase with respect to Channel A.
If the same Encode clock is provided to both channels and the
data align pin is disabled, both outputs are delivered on the
same rising edge of the clock.
Table 4. User-Selectable Options
S1        S2     Option
0           0       Standby Both Channels A and B.
0           1       Standby Channel B Only.
1           0       Normal Operation (Data Align Disabled).
1          1        Data Align Enabled (data from both channels avail-
                       able on rising edge of Clock A. Channel B data is
                       delayed a 1/2 clock cycle).

Badly expressed, but seems to suggest that programming the S1 S2 pins might get us what we want

[mozart5474]

i have got the same problem as gambit 58 on my win7 64bit. device not be found error. any help how i might get it running? i have tryed it on a 32 bit machine and had no troubles but at this machine it is not going anywhere. tryed installing reinstalling over and underinstalling sideinstalling screaming and crying at it, begging snobbing and of course the good old delete it and make it anew from the root to the top but no luck. "Device not be found." anyone?

[psynapse]

Mozart5474,

Sadly I am not a windows expert, far from it.  The generic answers are likely to be
1) the device does not work (though not in this case)
2) that it is not plugged in (although it might appear so.  Note in particular the high current needs of the device, machines differ in their USB current delivering capacity)
3) that the driver is not installed (does it appear correctly in what I continue to call "control panel")
4) access permissions, the device might function, be connected, have a driver installed but not be accessible to you as a user.

[mmark]

Update:

timebase setting, y-scaling and switching between AC and DC coupling works for me now at least somewhat for my DDS120. I didn't do any real calibration yet (traveling right now and only have the DDS120 with me). And still no triggering, but at least it starts to get somewhat useful...

There seems to be a problem with sample sized > 2048 bytes. If I try to read more then 2048 bytes, then there is always a jump in time at sample 1024 (e.g. at 2048 bytes). You can see that if you set the sample size to large (which is 32768 for now...) and select a time base of 1ms or longer. I tried sending 0x33 cmd before reading the data with various delays, but the discontinuity stays there no matter what. The data after this point seems to be continuous again... I am wondering if the OEM software discards the first 2048 bytes for buffer sizes > 2048...

Also, my 5 year old mac book is somewhat struggling keeping up with redrawing the screen if the small buffer (2048) is selected. I added a 10 ms delay to the end of getSamples() to relief this a bit, but the GUI still get sluggish after a few seconds. Either switch to the large buffer or start/stop the sampling only for short times. And there is a display error in the lower right part of the DSO widget, but this goes away after toggling the zoom mode once (I have only seens that on my mac and not on linux) .

Anyhow, the updated code is attached.

here is a complied binary for ubuntu 14.04 (in fact it is compiled under xubuntu 14.04)
https://drive.google.com/file/d/0B4k4TyIzvHKANXdlSTQ4bDZaaHc/view?usp=sharing

and here a dmg for those with a mac:
https://drive.google.com/file/d/0B4k4TyIzvHKATW1rb1VpOXVpbzQ/view?usp=sharing

To compile und linux/ubuntu, you need to have libqt4-dev (or libqt5-dev) and fftw3-dev installed. To access the device as a user, add this to /etc/udev/rules.d/50-sainsmart.rules:

Code: [Select]

#add SainSmart DDS120 and DDS140 to group plugdev
#DDS120
SUBSYSTEM=="usb", ATTR{idVendor}=="8102", ATTR{idProduct}=="8102", GROUP="plugdev"
#DDS140
SUBSYSTEM=="usb", ATTR{idVendor}=="8312", ATTR{idProduct}=="8312", GROUP="plugdev"

and make sure that your user is member of the plugdev group.

[jimon]

Hi guys,

When playing around with it, I connected signal, that is suppose to be square with freq around 4.8 mhz, to both channels.
Probe connection is made to exact same points (both signal and ground connections).

And I got what on screenshot.

First I thought that it's a probe compensation difference, but then I switched probes on oscilloscope side (so just swaped bnc's).
And guess what, I got same result - more sin-ish on second channel, and more square-ish on first channel.

What it could be ?

PS. siqnal source is an attiny13a that I playing with now, it runs this simple program http://pastebin.com/HH1sscZN and fuses are set to 7A FF

[doctormord]

Well, at 50Msps, you'll get 10 datapoints per periods (at 5MHz signal). - that's what you see. Additional errors are from the non compensated AFE (analog frontend).

The shifting, timewhise, might be a result of the increased propagation delay on one channel due to the bigger pcb-loop.

To interpret correctly, the signal waveform, generated by the attiny, should be checked with a proper scope. (rise-/fall-times)

[Guizmo]

Hello, I have the same problem of gambit 58 and Mozart5474 and have a W7 64 laptop. But I found a little solution.
Not "The" solution I wanted but ...

It is as simple as it is anoying... I have 4 USB and only one is working with the DDS.
I tries to uninstalled, install by another port but this is always the same USB which is working.
So.. you shoud try all your USB port!

Viewing how simple is my "solution" I am not sure at all it will work for you.
This must be a little parameter causing all this trouble but I am unable to find it !

Hoping this will help you,
cya


I

[ganzuul]

Update:

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.

[doctormord]

Any chance to run this under windows?

[ganzuul]

I think so. QtCreator only complains about libusb1.0 and fftw3 being missing. I'll see if I can figure out this Win32 stuff.

[doctormord]

Thanks in advance.

[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?

[doctormord]

Still thinking about interleaving the two channels. A non trivial task, as the half clock shift at the ADC only delays data out, not data in.

An half-clock-cycle-delay (HCCD) is needed while maintaining the original clock frequency.

For sure, we simply can inject some propagation delay by gatter-logic, but this won't be frequency stable, I guess.

Data reconstruction can then be done in software.

[psynapse]

Doctormord, 

I am not sure I agree about the half clock shift not skewing sampling.  Here is the timing diagram for mode (S1/S2 1,1) from the datasheet

For me it shows that supplying antiphase clocks to the two encode pins results in data sampled at double the clock rate (if the two inputs are tied together)

Compare it with the normal mode operation(S1/S2 1,0) (shown in the second attachment), which shows both channels being sampled once a clock period.

So the task would then involve spliting the two encode pins (lifting one leg) , feeding antiphase clocks to the two, swithching one of the mode pins between 1 and 0, and of course joining the two inputs together.

While it looks as though S1 is tied high on the DDS140 board , S2 is connected to a plated through hole.  The same is true of the DDS120.  I am not in front of the hardware tonight, have you traced S2?  Of course the two encode pins are strapped together and will need splitting apart

[doctormord]

Now i see, was a bit confused because of the alignment.

[mmark]

Psynapse,

it might be silly, but from looking at the image Jimon posted earlier, one could assume that Ch1 and 2 are already shifted by half a sample period at the 48/50 MHz sample rate... It would be interesting to see what signals you get if you connect a signal close to 50 MHz to both inputs.

Again, this is just an observation without any support from schematic or data sheets. Nevertheless I thought it might be interesting?!

mmark

[doctormord]

Can't be, because both Channels get the same clock and data align is disabled by hardware.

[ganzuul]

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.

That is a very good way of doing it. You trigger on what equates to the highest instantaneous current that way.


In Jimon's screenshot it looks like there is a PIN diode on the clipped channel, as if a capacitance gets drained after the voltage overshoots. PIN diodes are more permissive of high frequencies though. It might be that the adjustable filters near the BNC connectors shunt higher frequencies to ground, and that they form an RCL network which also phase-shift the signal. If that is true then the channels can be matched by just looking at the oscillograph and adjusting the filters.

[jimon]

@ganzuul
I don't have any generators here that I can use for calibration, so probably will skip screwing around inside of scope 

[ganzuul]

No sweat. I'm looking into building a tunable oscillator from discrete components right now anyway. I specifically got this scope for the purpose of screwing around, so I'll report the results! 

[doctormord]

My approach of a classic generator is shown here:

http://www.diyaudio.com/forums/showthread.php?t=261604

[psynapse]

Well Doctormord is right about the ADC, the DDS120 and DDS140 (without modification) will do no phase shifting between their two inputs.  However Ganzuuls observation is an interesting one.  I have not looked at the analogue front end too much ..... Doctormord and Ganzuul are certainly more hardware capable than me.  The only thing I would note is that for the designers of these scopes, wouldnt it have been easier to use antiphase clocks to the ADC ..... Having a tuned circuit to adjust costs money!

BTW, Doctormord,  I have done some calibration of the analogue front end .... and found what you already knew.  Significant 0v offsets and appalling gain variability.  Now that I have (software) corrected these I need to look at gain nonlinearities    .... have you taken that subject further since you mentioned your concerns? And a quick question.  I am proposing to buffer INT5 with an opto, collector tied to +3v with a 10k resistor.  Do you see problems with that?

mmark, I agree that there is a phase shift, but I am not sure I see 180 degrees on Jimons post.  Doctormord did a good job of tracing the front end here and here.  His LTspice simulation shows that phase is all over the place up at the top end frequencies.  Perhaps even limited differences in gain between the two channels could cause the observed shift.

Ganzuul and mmark.  Yes, your observation on Jimons clipped channel.  I have observed the same behaviour on one channel, but one only. Have not investigated further.

So all in all, good luck .... I am leaving this one to you guys (as the experts). 

Once I have considered carefully how to implement a hardware trigger, that is next on my list.  After that polish the interface ... oh and of course continuous data capture .... are we convinced that after the initial bad data, the scopes give data streams without dropouts (obviously excluding the DDS140 when it is in flash, ie normal, mode).  I think both Doctormord and I are keen on decent data logging capabilities.

EDIT In starting to work out how to generate and receive an external trigger, I have looked closely at the DDS140 firmware.  I note that the 50 command not only checks the status of the CPLD fifo, but also stops data acquisition by the CPLD (if the device has marked its FIFO as full).  The only trouble is that the firmware resets the FX2 FIFO before it stop and resets the CPLD (and its FIFO) .... it is hence quite possible that the FX2 FIFO will be reloaded with additional data before a true stop.  Note too that the "stop" to data acquisition is effectively up to the PC (through its polling with command 50), and all of the latency that involves.  All of this says that there is very little surprise that there is floating data left for the next data acquisition cycle. 

[doctormord]

Well Doctormord is right about the ADC, the DDS120 and DDS140 (without modification) will do no phase shifting between their two inputs.  However Ganzuuls observation is an interesting one.  I have not looked at the analogue front end too much ..... Doctormord and Ganzuul are certainly more hardware capable than me.  The only thing I would note is that for the designers of these scopes, wouldnt it have been easier to use antiphase clocks to the ADC ..... Having a tuned circuit to adjust costs money!

Well, this will work when we could antiphase IFCLK. Then we split the clocks and enable data-align on the ADC. Would be just a minor patch. We might also use one of the free multiplexer to parallel the inputs then. Switching needs to be done via an additional command (GPIO) within the custom firmware.

BTW, Doctormord,  I have done some calibration of the analogue front end .... and found what you already knew.  Significant 0v offsets and appalling gain variability.  Now that I have (software) corrected these I need to look at gain nonlinearities    .... have you taken that subject further since you mentioned your concerns?

Haven't looked into this yet, but would consider changing the multiplexers to types i mentioned earlier. I asked an application engineer within the company i work (as student). The problems concerning gain variance wouldnt be that important if the multiplexer resistor construction got implemented the other way around.

Means:

Resistor -> Multiplexer = bad
Multiplexer -> Resistor = good

It can easiliy be unterstood if you see the setup as an voltage-divider.

And a quick question.  I am proposing to buffer INT5 with an opto, collector tied to +3v with a 10k resistor.  Do you see problems with that?

Should work:

FODM8071
SFH6701/11

You might also consider TIs high speed digital isolators.

Once I have considered carefully how to implement a hardware trigger, that is next on my list.

Hardware-trigger should also be possible in DDS120.

[psynapse]

Doctormord,

Have been building my hardware add-ons, so I have been quiet (as has everybody!)

In the process I took my DDS140 apart, again, and took the opportunity to trace through a bit more circuit. The ADC in the DDS140 has the clock pins and the S2 pin controlled by the CPLD, so it seems very probable that the DDS140 properly interleaves the two ADC in order to get its top sampling rate.  This doesnt help DDS120 owners of course,  but it means your mods can be DDS120 specific, which might make the job easier.

Tracing through the circuit, The external connector is as follows.
C1 + 5v
C2  PE 1 (clk)
C3 PE 0? with RC
C4 PE 3
C5 PE 5
C6 CLKOUT via 300 ohms 48Mhz
C7 -gnd
C8 - +3v3
C9 -DataB  7
C10 -DataB 6
C11 -dataB 5
C12 -dataB 4
C13 -dataB 3
C14 -dataB 2
C15 -dataB 1
C16 -dataB 0

Bn   no pins

A1 -Gnd
A2 -Gnd
A3 -
A4 -
A5  PE 2
A6 -gnd
A7 -
A8 -gnd
A9 -
A10 -
A11 -
A12 PE 4
A13 -
A14 -
A15 - gnd
A16 - gnd

PE3,PE4 and PE5 seem to function as an I2C interface for controlling the waveform generator.

[doctormord]

Regarding:

http://www.cypress.com/?docID=48811

Page 221

IFCLK can be inverted to internal CLK, so driving the ADC in "double-speed" is def. possible with a new firmware or a byte-patch in the existing one.

This might get helpful:

http://www.cypress.com/?docID=50815

[psynapse]

Just a brief update for the DDS140. Bit PC.6 (fifo full) acts as a exact indicator of when data sampling is taking place (ie active low), except as noted below.  PA.7 (go) shows when the host PC has demanded data acquisition , but is less exact .... in particular the back porch (ie after the fifo is full) is only cleared after the host PC has issued a code 50 (fifo status command).  See the attached traces for a bit more detail. Data acquisition is shown for two capture rates 10M and 625k.  Note that in both cases the Sainsmart PC software takes slightly over 100mS to re-issue the go code.

In mode 94 0A (240khz) on the DDS140, the fifo (more exactly the CPLD fifo) never shows full.  Another reason to believe that the 94 0A mode on the DDS140 functions exactly as the DDS120 normal mode, ie ADC data direct into the FX2 fifos, and not via the cpld pseudo fifo.

So now I have my "trigger out", which shows when the data sampling window is open.  Quite simply fifo not full on PC.6.  I will now write a very short ISR for INT5 which will assert PA.7 and the allow normal software to detect when the fifo full flag changes (existing command 50).  This will give me trigger in, though sadly not a pre-trigger in.

[doctormord]

Nice!

Isn't pretrigger "just" a thing of implementing software "prebuffer"?

(Like on cameras)

[psynapse]

Doctormord,

Thanks!  I am not sure I know what you mean by pre-buffer though .... could you explain please .... could be a neat idea.

What I would have liked was a constantly running cyclic buffer, which you stop shortly after the transient of interest.  That is possible (through PC software) on the both the DDS120 and the DDS140 94(0A) mode, but not for the flash capture mode that runs at 10 and '100' Mhz on the 140.  Ganzuul, I really must get round to listening to the CPLD JTAG to see if it can be reprogrammed to do that.   I note that the CPLD continues to strobe the !WE pin on the memory after the buffer is full (right until the host issues command 50), but I have not yet checked to see if it has enabled !CE or cycles address pins ... I think not.

For me, I can arrange that external events that I wish to monitor can be triggered by a ready signal from the scope.  And I know / think that continuous data logging will be possible to 12Mhz (perhaps 24Mhz) , which meets my needs (and perhaps Doctormords).  And with a hardware input trigger that will fire data acquisition within 1-2uS it is as far as I need to go for my needs.  Doctormord has a fix to up the data-rate on the ADC side of the DDDS120.  So......

What is left to do??

.......The PC software needs tidying up and it would be really nice to have open firmware

But nearly everybody has gone quiet.  That could be a loss of interest or that everybody is busy elsewhere, or that folk are hard at work on recrafting code.

Which is it folks?

[CatWhisker]

Psynapse,

Stumbled on this yesterday, I'll definitely be interested.

What 'scope software are you targetting? Or going a-fresh?

[doctormord]

Psynapse,

i meant preroll with hw-trigger, didn't knowed that you meaned flash-capture.

Up to 50msps it should work with realtime pass through into the PC. The other way I could think of is live data at reduced speed with additional (triggered ) flash capture into the clpd fifo - so having a big set if reduced resolution data with additional highres (magnification) added from flash capture.

[psynapse]

Doctormord

Yes, pre  -roll will work well, although it might be nice to have an external signal "mark" the start of the region of interest.

And yes on the CPLD too   ... I need to come to grips with that.  However I have learned so much from this exercise, and our valuable conversations, that my inclination is to build a new scope from scratch, especially since this thread seems to be going cold (a real shame).  I now have a MAX1446 ADC and an FX2 development board,  the challenge for me now is making a PCB for it all to happen on!  I was thinking of a true FIFO chip to get transient data rates up and allow continuous data acquisition up to 48M.  If I find the time and energy, I will certainly be implementing the front end revisions you have identified, for which many thanks.

CatWhisker

What we are trying to achieve here is both open software and firmware (along with some significant hardware improvements).  We are a long way forward on open software for both the Windows and Linux environments (there is still a lot of tidying up to do, but proof of principal we definitely have).  We are less far forward on open firmware for the scope itself.  I have "contaminated" myself by looking at a disassembly of part of the provided code, which makes it very difficult for me to claim that I have invented my firmware from scratch.  However I do know how to patch the standard code to give us extra features.  If we do not get open firmware, I will look carefully at the legality of releasing details of how to zap the firmware in order to give extra functions. 

[doctormord]

Preroll with external mark, yes, that's what I thought off.

Would you implement the stuff for the DDS120 into your software as well? Thanks.

If I find some spare-time, I'll redraw the AFE (started already) and think about the wiring for interleaving the channels.

Regards,

Doc

[psynapse]

doctormord;

When you say "software", do you mean the firmware modifications to give external trigger and variable timebase?  Yes, I can do, but will need to identify some addresses in the DDS120 firmware.  On the DDS140, the process was pretty straightforward:- patch the page zero interrupt table to give access to an ISR for INT 5. Revector two commands (I used 41h and 42h) to my own code, which is only 30 lines of assembler.  On the PC based software, I can certainly try, but I have no way of verifying if I have got it right.  I have still to implement recording data to file and replaying from file as well, so it will be in a couple of weeks I guess (I am really not that good on C++).

All,

At this moment I have tested the variable (and continuous) time base to just 4msps (per channel), beyond this something strange seems to happen, though I am not sure that this is not just a problem of using the scope for the test signal as well.  External trigger works too, simply a 74LVC14 tied to the INT5 pin and a 7 line interrupt service routine (3 lines of which are nop for port timing!)  ... but progress on the QT based code is slow. It really isnt my strong area. I would like to thread the code, especially the data acquisition/writing to file and would also like to get an effective way to check the status of the FIFO .... at the moment it is a spin loop and it should be based around a real time initiated event.  Oh and find out how to make the code properly portable (I know, build static instances of the libraries etc etc, but this is all new to me). Help most welcome.

[doctormord]

When you say "software", do you mean the firmware modifications to give external trigger and variable timebase?  Yes, I can do, but will need to identify some addresses in the DDS120 firmware. 

Yes, basic implementation of the standard stuff would be enough to start with.

I stumbled about 2 things lastly. First, the original software has a scale bug (at least) in stop-mode. So resizing the window back and forth would result in wrong voltage marks.

Secondly, i wondered, what would happen if you measure some signals, AC coupled up to the limit and pull/reattach the scope. (I.E. 40V DC with 4V AC) While AC-coupled, theres no problem, but the control lines for the two optoswitches are initialised at startup/power connect.

[bobi_dunkel]

Hi everybody.
I have stumbled on this thread in May, only a few posts. 5 days ago went through my favorites
and happy to see 14 pages of posts  . Reading it since… 
What to say, great job, really great job.
I have DD120 and if you need some help please let me know.
I can be some beta tester because my knowledge of eeprom and programing is really limited. Personally bought this scope for automotive sensor testing.
And it is doing a great job. The only thing lacking in original software is longer time base. (60sec or even longer 5 min)
So I have downloaded Ledioskope (a.k.a OpenHantek for DD120). It is working really well.
The problem is when I select longer time base. It shifts the display to the left. If i select 5min the wave becomes one red dot in left corner.
What am I doing wrong?
Please see the attached pics.

[psynapse]

It's a whole week since I said something .... not like me

As forewarned,  I have been struggling with Qt (and still am).  However at the alpha level of development I have now got the things I want, in particular continuous sampling.  Using my "patch the wavetable"  technique on the DDS140 I can get up to 8Msps per channel and record these indefinitely without data loss.  The only problem is that I cannot get libusb to multiple buffer convincingly, once it has filled the capture buffer, there is data loss.  So, when recording traces, I use malloc to dynamically grab the necessary chunk of memory, pass this to libusb and wait for the return.  This has three limitations
1)  the amount of memory grabbed is finite and variable, but (eg) grabbing "just" 100 megabytes for a 1Msps trace does give you a long sample time
2) you get no trace whilst recording
3) at slower sample speeds, threading and asynchronous use of libusb with small buffers might open the possibility for infinitely long recordings and visualisation ..... but at this stage this would be another learning "event" for me ... and maybe there are others who are more skilled.
As it is I record the grabbed waveforms and store them as raw WAV files, which lots of programmes can read and manipulate. As it happens, this is pretty easy because with the right header you can just append the data to a file straight from the USB read.

Doctormord:
At one stage I was using a triangle waveform to test for data loss (it is really easy to see onscreen).  What I also noted was the serious non linearity on the ramp, so perhaps a good way of calibrating against those nasty 4063's.

Failsafe on the AC/DC switches, good question.  Even if the firmware initialises correctly, is the hardware design such that the startup state of the FX2 "outputs" correct to select AC mode.  And of course if you unplug the scope, the whole thing is floating with respect to the PC.... until you replug it 

bobi_dunkel
Two problems, I cannot find ledioskope ... zero hits on google is pretty rare these days.  Could you provide a link if possible please.

I have the dds140, and this is not a simple hardware "upgrade" of the dds120.  But I will have a look
 

[doctormord]

Ledioskope is within this thread.

[psynapse]

I agree, that's pretty stupid of me. An old man with a poor memory. Sorry.

The executable version is windows ..... so I will have to recompile from source under linux and QT ... expect this to take time... I am not clear whether the mmark version of the source is the most current , but will give it a go.

[bobi_dunkel]

I agree, that's pretty stupid of me. An old man with a poor memory. Sorry.
The executable version is windows ..... so I will have to recompile from source under linux and QT ... expect this to take time... I am not clear whether the mmark version of the source is the most current , but will give it a go.

No problem i have problem with memory also  . It seems that Mr "ganzuul" is the compiler of "Lediosope" for windows.
I was hoping he will find the answer for longer time base left shift.
But again maybe it is the problem of OpenHantek and I need to contact the author.

[mmark]

Hi everybody.
I have stumbled on this thread in May, only a few posts. 5 days ago went through my favorites
and happy to see 14 pages of posts  . Reading it since… 
What to say, great job, really great job.
I have DD120 and if you need some help please let me know.
I can be some beta tester because my knowledge of eeprom and programing is really limited. Personally bought this scope for automotive sensor testing.
And it is doing a great job. The only thing lacking in original software is longer time base. (60sec or even longer 5 min)
So I have downloaded Ledioskope (a.k.a OpenHantek for DD120). It is working really well.
The problem is when I select longer time base. It shifts the display to the left. If i select 5min the wave becomes one red dot in left corner.
What am I doing wrong?
Please see the attached pics.

Bobi,

did you try to switch to 'Large Buffer Size'? (Menu Oscilloscope => Buffer Size => Large)? This will give you 32768 samples (the default is Small=2048), therefore the displayed trace will be longer.

I did not implement a rolling update or a continuous sampling yet, so even with the larger buffer you eventually will run out of samples. The reason for that is that the DDS120 has a minimum hardware sample rate of 240kHz. With the large buffer (32768 samples), the maximum total time is 32768 / 240 kHz = 136.5ms. So if you select a time basis larger 10 ms/div (= 100ms total), there wont be enough data to display...

Mark

[bobi_dunkel]

Mark,
You are right. Wen I select bigger buffer I can go to 500ms , but at 1 s  , have left shift of wave data.
So it is buffer issue. Waiting for your continuous sampling 

[doctormord]

@psynapse,

RichardK released the sources of his open6022BE project:

https://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/msg566881/#msg566881

https://jumpshare.com/v/bviO41a4x8CiAaSSbama

You may have a look at it.

A binary to play with is available here, it features a demo mode.

https://jumpshare.com/v/q1Spmyw0dk7BmnRd77tk

Regards,

Christian

[psynapse]

Doctormord,

Thanks for the heads up.  I will download the files when France Telecom repair the lines to our village ... At the moment I have only got 2.5G GSM mobile and a limited download package.

Regards

[MengPeng]

I've just plugged my new DDS120 into my Win XP Acer Travelmate 8204WLMi laptop (ca 2006) and can't even get the supplied software to open - it gives me the splash page saying it's v.1.2 and then I get a Windows message saying it had to close the program V6.1.0...  So I looked around for some other software that might run it and came across this blog, which seems to be quite a bit over my head, and I'm hoping someone here can guide me to getting the DDS120 running. 

I read most of the posts, and I saw Bobi's message about Ledioskope, so I downloaded and extracted the Ledioskope zip file and opened the OpenHantek program but that's as far as I got.  There's an error message on the bottom of the screen saying "Couldn't open device 005:003: Operation not supported or unimplemented on this platform".  Can anybody help me out here?  It's my first oscilloscope and I'd really like to get it to work!

[bobi_dunkel]

Hi, and welcome to the forum.
Did you installed drivers for dd120? Any errors?. For sainsmatrt program to run correctly you have to install net.framework2. It is on cd.
Also plug dds120 on some win8 machine. Drivers are already installed. Then start ledioscope it will work. Then we can help you install it on acer.

[MengPeng]

Hi Bobi, and thanks for your reply.  It inspired me to tackle the DDS120 again, and I’ve tried a bunch of things but the DDS120 programs (both v1.2 and v1.3) still crash on opening so I’m puzzled about that, and also OpenHantek still gives me "Couldn't open device 005:003: Operation not supported or unimplemented on this platform" .  I'm puzzled! 

To answer your questions, yes I did install the drivers and didn’t get an error message.  When I connected the DDS120, I got the “Found New Hardware” wizard and pointed it to the drivers in the package I downloaded from the site mentioned in the Amazon product description.  (I thought those would be the latest version, but that’s where I got v1.2 of the DDS120 software package, and the installation cd that came with the unit has v1.3 so I guess that’s later.) 

The DDS120 shows up in Device Manager as "WinUsb Device (NULL)" under "Universal Serial Bus devices".  I don't know what (NULL) means.  There’s no yellow “!” or “?” showing, so I think the driver installed successfully.  Does your unit show up as "WinUsb Device (NULL)"?

I did install .NET 2.0 using the dotnetfx20 installer on the installation cd.  To get that to work I first had to uninstall the .NET frameworks 3.5, 3.0, and 2.0.  The DDS120 programs (both v1.2 and v1.3) still crash on startup and OpenHantek (Ledioskope) can't open the device.

All of this happened while DDS120 was plugged into a powered USB hub, but the same thing happens when I plug directly into the laptop’s USB port.  I am using the cable supplied with the DDS120.

Sorry about the long post, but I wanted to make sure I covered all possible sources of error!  I don’t have a Windows 8 machine to play with but am thinking of getting one.  Anyway, it’s nice to know others have got this thing to work properly, so I’ll persevere but would appreciate any ideas you might have!

Regards,
Cam

[MengPeng]

Just a quick update - I have an HP Stream 7 running Win 8.1 and the DDS120 software runs fine on it, even without the DDS120 hardware connected, so I think my aging Acer might be the problem of the crashing but I don't know why.  Anyway, a possible work around is an OTG cable to a Powered USB  hub, plug the DDS120 into that, see if that works.  Ordered an OTG cable, will update you all when I know more...

[bobi_dunkel]

Hi Cam,
Great , your dd120 is working you have problem with driver on xp. When you connect it to xp and go to computer management it will show as Buudai - Oscillagraph. Please don't use usb hub. Plug it directly to usb. Download this software Usbdeview http://www.portablefreeware.com/?id=1004.  Use it to remove any bad usb driver. Then reboot and you can install drivers again. You have to get device Buudai. Then it will work with ledioscope. After that we can solve the stock program issue.

[MengPeng]

Hi Bobi!  Thanks so much for your reply, and I think you’re correct that my problem with Leidoskope not being able to open my DDS120 is that I don't have the correct driver installed.  I right-clicked on the DDS120 shown as "WinUsb Device (NULL)" in the Device Manager, checked its properties and saw that there were no drivers installed for this device! 
I downloaded USBDeview (cool program - thanks for showing me that!) and see the WinUsb (NULL) device in the list, but it shows that it’s not connected so nothing happened when I clicked on the red X to disconnect it.  So I tried disabling it, and rebooted.  My expectation was that this would delete the device's driver and that when I next connected the DDS120 I would be prompted by the New Hardware Wizard to point at a proper driver.  I was amazed to see that did not happen: when I connected the DDS120 I got no New Hardware message, and when I looked in the Device Manager, there was that "WinUsb Device (NULL)" again.  (I'm positive that's my DDS120, because when I unplug it, the "WinUsb Device (NULL)" disappears.)
So I gave up using USBDeview and tried updating the drivers by right-clicking on the device in Device Manager and selecting “Update Drivers”.  Then I browsed to the driver location (trying the driver from both from the install cd and the one in the package I downloaded from the Amazon page where they say to get the latest drivers), but the Hardware Update Wizard tells me the update was unsuccessful because it couldn't find a better match for the hardware than the currently installed driver.  Pretty puzzling since the Device Manager Properties says there’s no driver installed or required.  So right now I’m stymied?  Any ideas? 
One possibility is that maybe I’m not using USBDeview correctly:  I not sure what you mean “use it to remove any bad usb driver” – I could see that I could select my device and disable it, or disconnect it if it was connected, but couldn’t figure out how to remove a driver - maybe I’m missing something…  When I look at the properties using USBDeview, it says that there is a driver installed, WinUsb Device (NULL), v1.0.0.0, but I couldn’t delete it or anything..
Regards,
Cam

[MengPeng]

I forgot to mention that USBDeviewer says my DDS120's device name is "USB102" in case that's important. 

[doctormord]

USB102 is right.

[MengPeng]

Thanks, Doctormord!  So as per USBDeview, Device Name is "USB102", Device Type is "WinUsb Device (NULL)" and that is all correct?  What about the Buudai Oscilloscope that Bobi mentioned?  I thought he meant that would be the name that Device Manager showed, but it appears I misunderstood.  Maybe that's the name his DDS120 shows in USBDeview?
Also, I thought it made sense what Bobi said about there being a driver error, because in Device Manager, it tells me there are no drivers installed for "WinUsb Device (NULL)"..  But I think I'll leave the driver issue alone for awhile, it's hurting my head.
If the drivers ARE ok, though, perhaps the problem is related to the fact that my DDS120 known as "USB102" is shown as not connected, even though it is!  Maybe that's why OpenHantek can't open it?  Anyway, I am learning a lot, mostly about how much I don't know! 
I really appreciate the help!

[doctormord]

Normally, the devices will get recognized by their VID/PID. Could you check for this?

Please try this drivers:

https://dl.dropboxusercontent.com/u/5641160/DDS120_Driver_XP_Win7.zip

[MengPeng]

Hi Doctormord - thanks for your reply!  Here's what I get from USBDeview's properties record "Instance ID", the only place I could find VID/PID: "USB\Vid_8102&Pid_8102\5&bbb2cc8&0&3"  Does that make sense?  Don't know what it means..
Also, I tried to update the driver for the WinUsb (NULL) device and pointed it to the new drivers you made available to me (thanks!), but the wizard again saying it couldn't find a better match for the software than what I already had installed..  Starting to seem like it's not a driver problem, but I'm in over my head for sure, dunno what's going on.
I ran "driverquery" from the command line, got a verbose list of all the drivers, saved it to a csv file, opened it in Excel and sorted on the Date column, but there was no driver created/modified when I installed the drivers for the DDS120, so again, I'm confused!  Still learning a lot and not tearing my hair out yet, approaching this in a calm, measured manner, prior to the scorched earth, nuke'n'pave approach I intend to take later.  Sure appreciate your efforts to help me! 

[doctormord]

"No better match" sounds like you used the "driver wizard" rather than selecting manual install by "have disk".

http://www.intel.com/support/graphics/sb/CS-030331.htm

[MengPeng]

omg!  It worked!  Thanks, Doctormord - I had to click "Have Disk" to select the location to force it to install the driver from!  So now Ledioskope (OpenHantek) recognizes the DDS120, I could measure the 1kHz clock signal, and I'm about to start exploring the marvel of pc-based oscilloscopes.  Thanks so much for your help, Bobi and Doctormord.  Bobi, the DDS120 shows up in Device Manager as Buudai>Osillagraph just like you said it should.  So happy.

[MengPeng]

PS Doctormord - tried to go to your website  www.360custom.de, got a "not available" message from my chrome browser...  I'd like to support the people that help me.

[bobi_dunkel]

Hi Cam,

Great , glad you sorted it out 

Best regards,
bobi

[doctormord]

PS Doctormord - tried to go to your website  www.360custom.de, got a "not available" message from my chrome browser...  I'd like to support the people that help me.

Glad that it works now. 360customs is up and running.

Edit:

seems like my signature is "fuck*d" up..

www.360customs.de <--

[MengPeng]

Now I'm playing with the OpenHantek software measuring the 1kHz test signal from the DDS120, and it zips across the screen until I press the space bar.  Then I can see a nice square wave signal, but shouldn't the signal display as a stationary square wave instead of moving (fast!).  I tried adjusting the trigger mode and played around with a few other settings, but maybe I'm missing something?

Also, is OpenHantek the same as Ledioskope or...?  (Since I got the DDS120 to work and am now puzzling through software, maybe I should move this topic to another thread, just let me know!)

Regards,
Cam

[doctormord]

Ledioskope is an OpenHantek-hack to work with the DDS120. It lacks of a software-trigger, as the DDS120/140 does not have one in hardware. To have trigger-capabilities, you'd need to stay with the original software atm.

[MengPeng]

Ok, thanks for the reply! Obviously I've got some learning to do!

[nitetrip]

I feel like I am late to this party.

I just ordered a DDS140 from Amazon, it should arrive on Wednesday.

I'm hoping it will fill my needs, I am just a tinkerer, with the Arduino and Raspberry Pi. I am also a software engineer so I will see if I can provide any assistance with the software.

[MengPeng]

Welcome nitetrip!  I think the software is the missing link between this seemingly adequate hardware and an actually useful usb oscope!  I've been researching and have sorta concluded that these things are toys, probably better off buying a 'real' oscilloscope, but I feel there is potential to create something good.  Seems like the hardware is there but not the software.  Thinking I should have bought a desktop oscilloscope but it is nice to be involved with the community of folks trying to make this hardware useful.

[crystal]

So can DDS120 in any way be upgraded or not?

And is DDS120 better buy or this one: http://www.ebay.com/itm/New-USB-PC-Virtual-Oscilloscope-20MHz-50MS-s-1CH-/261544520822?pt=BI_Oscilloscopes&hash=item3ce544ac76

[doctormord]

They're supposed to be the same.

[torr032]

They're supposed to be the same.

So which one is the newer version?

[doctormord]

The same is the same, so no "newer version". 

[crystal]

If they are the same then why do they have two different stickers on the cover?

[doctormord]

Why does car companies sell cars in different colors? (Same specs, different colors)

[nitetrip]

My DS-140 came in today. Included was the Logic Analyzer and Signal generator.

I plugged it in, hit start and... Device not found.

I mucked around with it for a bit, changed USB port and still nothing. Then, I changed USB ports again and it started working! So anyone who might find this thread while googling ds-140 not working, try different USB ports, all the ones you have on your computer. I'm not entirely sure why it only works on 2 of my 4 USB ports, possibly they are the only USB 3.0 ports I have, but I'm not sure.

This is my first oscilloscope ever and I think it's amazing. It's so neat to be able to see the signal generated by the various electronics we use. I have been hooking up everything I can find to it and watching it. So very cool.

So after I get bored of playing with this thing, my next step is to take a look into the software that came with it, and the open-source software out there that is available and see if I can improve it any.

[i4004]

such usb scope threads usually lack the details abotu the original bundled softtware(problems) in the first post (then if somebody mentiones anything it will be burried in the thread). one particular thing is of interest to me, the thing described in this video


ie zooming and moving the trigger horizontally beyond the screen.

what i'm asking is does it work in a simillar fashion like on benchtop dso's, for example on this rigol
https://www.youtube.com/watch?feature=player_detailpage&v=kcOdzFaIYNE#t=93
(where such trigger movement exposed interesting bug)

so can you move the trigger on sainsmart usb scopes (with bundled scope software), and how much can you move it?
this question is also interesting in the context of other usb scopes for example picoscope 2204 or hantek 6022be, but i didn't really find any mention of that in the yt videos of those scopes.
ie i don't see a provision for it in their user interfaces.

[CAlan]

Seeming that the folks on this board are the unofficial experts on the Sain Smart DDS120,  I hope you guys might be able to help me with a problem.

I primarily use it for looking at logic board functions while experimenting with early Solid State pinball machines, and my Arduino Uno.  I have a Windows 7 computer that the DDS120 works great, but from time to time I would like to be able to hook it up to my Mac Pro.

Now I am under the impression that there is no OSX compatible software that works with the DDS120, and I am ok with this as I have both Windows 7 and Windows XP I can run in OSX using Parallels desktop.

OSX does seem to recognize the DDS120, as it shows up in my Hardware profile after I plug it in.  Parallels desktop does acknowledge the connection (listing the device as USB102), and I can start up the DDS120 software and start the probes without an issue.

This is where things get strange:  I can't see any trace lines in the DDS120 program.  If I hook up the probes to the build in signal generator, and set the software to auto, it appears to be reading a 1000 hz signal, but all the voltage related reading (v Max, v Min, etc..) all say 0.  It is making me wonder if not all the USB information is being handed off from OSX through Parallels to Windows 7.

Is anyone using the DDS120 with Parallels Desktop and could possibly give me some pointers as to how to get it working properly?

[doctormord]

Do you have GFX-acceleration enabled on Parallels? You're right, all the readings are done software. The scope only sends raw ADC data.

[CAlan]

Do you have GFX-acceleration enabled on Parallels? You're right, all the readings are done software. The scope only sends raw ADC data.

ive tried it with both directx enabled and disabled.  It makes no difference.

[doctormord]

I will try to reproduce this in my setup. (OSX + Parallels Win7)

[CAlan]

So have you gotten it to work with parallels?  I also have tried it with both windows 7 and XP with Parallels.  I get the same results.  I'm using a 2010 Mac Pro with OSX 10.9.5 and a PCI usb card.

[PapaLukas]

Hi guys! And among those specifically doctormord, psynapse, ganzuul and donut6!
Great thanks for what you've done and even more have shared here. Inspired by this thread I've created by own version of desktop client for DDS140 Logic Analyzer module. Which I've bought to diagnoze the problems I'm having connecting SD card reader to Raspberry Pi (but that's a different story). After I received DDS140 device I was very much depressed by the fact that despite of claimed functionality and theoretic support I cannot use it for my purpose! Indeed, it turned out that a lot I can do even without any hacking of the firmware by mere writing a stable enough client. I've published the work in progress version here https://sourceforge.net/projects/logic140/ It lacks some of planned capabilities but seem to be stable enough (especially compared to stock software) and more user-friendly. Will be happy if anybody find it useful 
Usage note: it's developed in java and now only supports 64-bit windows platform (java is enough cross-platform, yes, but AFAIK it does not directly support usb devices, so I have a thin JNI library). In order to run it one needs installed 64-bit version of Java Runtime Environment (JRE) version 1.8. There is also all the source code published so you can build the one yourself, just need JDK 1.8, Netbeans and native toolchain (Visual Studio project for windows users is published)
At the same time I'm very curious what speeds have you manage to get gapless data at? Having these data losses IMO kills the whole idea of logic analyzer so it would be nice if other folks (like myself ) could repeat your success
Regards!

[rvendrame]

Any good soul who could tell the value of resistor R61?  I got it damaged (as well as the nearby AMS 1117) after a wrong ground connection...  I want to replace both parts, who knows it gets back to life...
Thanks

[mmark]

R61 seems to be 0 Ohm: https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpg (posted somewhere before)

[rvendrame]

R61 seems to be 0 Ohm: https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpg (posted somewhere before)

@mmark, thanks, will give it a try...

[DAIRVINE]

USBEE AX pro can capture analog for several seconds at least at 24MHz. This also uses FX2.
Saleae can capture 8 bits at 24MHz for several seconds. This also uses FX2.
USBEE AX clones are available, DDS120 is just a variant of this, they are all variants of the Cypress dev boards.

With continuous capture at 24MHz nice analog like instant displays with triggering and glitch capture should be feasible in software on the PC, for example like the Rigol 2072, except slower sampling.

At several seconds of 24MHz capture trigger is less important. You can capture long enough to cover the event then find the event with software.

The above comes across as critical, it is not meant to be, I am very grateful that people spend the time to improve the software and thank you for this. It is just a desire for what could be.

[DAIRVINE]

An example use is testing universal infra red. The maximum IR frequency is about 1.125MHz, the length can be several seconds. It should be within the capability of a DDS120 to capture a complete transmission, or even several transmissions.
Several transmissions are useful because of rolling code sequences up to a sequence of 16 codes (An obsolete telephone).

I actually used a picoscope for this, combined with an analog Tek scope.

[rvendrame]

R61 seems to be 0 Ohm: https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpg (posted somewhere before)

Still trying to bring it back to life... Replacing R61 by a jumper didn't fix it (anyway thx a lot @mmark!).  The voltage regulator next to it, AMS1117  3.3V is reading 2.1V at its v-out.  Can this be the problem?  Just want to check before replacing it...

[doctormord]

May you check the current drawn from USB?

[bobi_dunkel]

USBEE AX clones are available, DDS120 is just a variant of this, they are all variants of the Cypress dev boards.

Is Picoscope also variant of Cypress FX2 board ?

[bobi_dunkel]

USBEE AX clones are available, DDS120 is just a variant of this, they are all variants of the Cypress dev boards.

Is Picoscope also variant of Cypress FX2 board ?

Yes some models are: http://sigrok.org/wiki/Oscilloscope_comparison

[doctormord]

Hi guys! And among those specifically doctormord, psynapse, ganzuul and donut6!
Great thanks for what you've done and even more have shared here. Inspired by this thread I've created by own version of desktop client for DDS140 Logic Analyzer module.

Great work,

would you mind to implement support for the DDS120?

USBEE AX clones are available, DDS120 is just a variant of this, they are all variants of the Cypress dev boards.

Is Picoscope also variant of Cypress FX2 board ?

Yes some models are: http://sigrok.org/wiki/Oscilloscope_comparison

Well, they aren't as they just use the FX2LP interface but rely on custom FPGA implementations.

[venoft]

This thread doesn't seem to have been active for 2 months, which is a shame, but makes me extra hopeful there has been some progress. So does anyone have a good working software yet?

I tried Ledioskope, which looks good, but that doesn't seem to have a trigger. And the official software is pretty crappy of course, so I won't even mention that.

When I purchased it, it looked so good. But now I actually have it, I'm kinda dissapointed

[jbar]

I had the same issue with DDS120 Oscilloscope Windows 7 64 bit. "Device not found"
Delete any previously installed Oscilloscope driver from device manager.
Right Click "My Computer" -> "Manage" -> "Device Manager" -> "Action" -> "Install Legacy Software" -> "Have Disk"

First I installed the Win7 XP Driver which didn't function properly.
Next I updated the driver to the Win7 64 bit version.


Ran Application....and device connected properly.

[freefall322]

Hi all, SainSmart now sells a cheap Hardware Trigger Module for the DDS-140:

http://www.sainsmart.com/sainsmart-hardware-trigger-module-for-dds-140.html

people in this thread have been complaining about the lack of a hardware trigger for the DDS-140,
does this device make it more useful?

Any chance that we could get this hardware trigger to be supported by the various software projects
that have appeared in this thread?

[consequential]

Hi all,

I read this thread but am still confused on how to install and run this on a windows pc, can someone please help?

I downloaded OpenHantek 0.2.0 but none of the files have extensions, i.e. install.exe, just install

Thanks

[elecblues]

Hi all.

I am writing this to notice that DDS120 source code is available, by disassembling DDS120.exe or BM102.exe with ".NET Reflector". Other disassembler may also work.

This operation will produce c# sources out of DDS120.exe. Produced solution/project can be opened and edited on Visual Studio 2015,  older versions of VS may work also.
Of course program logic can be seen on  .cs sourcefiles with any text editor, so installing Visual Studio is not obligatory if just inspecting inner workings of device.

I don't know if this kind of disassemly for interoperatility/compatibility is legal in every country. Check legal things before using this method.
Hopefully at least someone can make use of this method, and produce finally a working scope software for DDS120. 

[doctormord]

Cool story mate. Will look into this.

[doctormord]

Seems like someone did some efforts in the DDS120 application, found somewhere on the net...

This that are fixed:

- Translation
- 50/48Mhz correction
- interface speedup and datatransfer optimization (much faster now)
- adjustements to buffer sizes to improve triggering
- faster buffer scroll
- removed "useless" timebase settings > 200ms to avoid overflowing data buffer (maybe readded in the future if the data acquisition is rewritten/adapted)
- antialiasing to graphs + "digital Phosphor§
- other stuff

Works good for me.

1.2.0
Link

1.2.1
Link

dds120

[jdev99]

I am new on this forum and the world of USB DSO's.
Still deciding between the SainSmart DDS120 and Hantek 6022BE. (Any suggestions, which one is the better?)

A new software version for the DDS120 is mentioned in the previous post as Link 1.2.1 , but the link is dead. Any chance to repost that file please?
Or, what is the difference between the 1.2.0 and 1.2.1  ?

[Gyro]

IF you're really looking for a low end USB scope, as opposed to the Rigol standalone one that everyone here recommends, then I'd suggest the Owon VDS1022 in preference to either of these, it's way ahead of them in performance. There are a bunch of these on ebay from China at the moment for not much more money:

http://www.ebay.co.uk/sch/i.html?_from=R40&_sacat=0&_nkw=vds1022&rt=nc&LH_PrefLoc=1&_trksid=p2045573.m1684

Here's the teardown thread:

https://www.eevblog.com/forum/testgear/owon-vds1022i-quick-teardown-%28versus-the-hantek-6022be%29/

[jdev99]

Thank you for that info and the teardown info you and Mark_O provided.
The Owon is for sure the winner here, nice Xmas present from myself to myself.   

[doctormord]

[Gyro]

If you hurry. Santa may smile on you! 

[doctormord]

Is the software any better?

[Gyro]

What? The Owon vs the other two?

Yes, by miles. Mark_O commented on that (at least against the Hantek) in the teardown thread. I showed screenshots and shortcuts in the same thread.

[bianchifan]

Seems like someone did some efforts in the DDS120 application, found somewhere on the net...

This that are fixed:

- Translation
....
1.2.1
Link

Link is dead

[doctormord]

Version 1.3.1:

Changes:
- Based on Version 1.3 (found on DX)
- FFT optimization (update rate)
- Timing optimization
- Fixed some GUI glitches
- Longer timebases added again
- Antialiasing
- Translations
- Ability to change signal width (1-10px)

Bugs:
 

DDS120_V1.3.1.rar
http://www99.zippyshare.com/v/p14YpYdf/file.html

pw? dds120

[lmorgan3d]

Has anyone found a driver for the DDS120 that will work with Windows 10?  Win7 driver with Win10 unsigned driver install does not work.  Standard Win10 driver install does not work.
      ..Rock..

[doctormord]

From Win8+ there isn't any driver needed - that's what they claim.

http://www.amazon.co.uk/forum/-/Tx1XXKCCR82ITFN/ref=ask_dp_dpmw_al_hza?asin=B00FXGYAXE

[zp1956]

doctormord

your version 1.3.1 doesn't work for me. Currently I am using Windows 10 and version 1.3.0 works fine.
meantime, I have created C# code from DDS120.EXE using ILSpy (from icsharpcode), but compiling back doesn't work (so many warnings). any advice is welcome!

[lmorgan3d]

Thanks for the reply doctormord, followed the Amazon link, looks like two got it to work, and one didn't.   No details on the install. 

I would imagine it should install like Win8...  but I tried with and without the unsigned driver procedure for Win10, it doesn't not install.  In reviewing the sources that sell the DDS120, none of the sites state Win10 compatible.   I have not been able to locate the original DDS120/140 vendor of the product to inquire about a driver. 

Mine was purchased from Sainsmart...  at first they did send me the older software which did not work.  After that, they have not responded to my last three emails.  Wish I could get this scope working on my small laptop....  Loved it when it worked.....

              ..Lynn..

 

[aviador]

I can not have working version 1.3.1 in Windows 7, byt no problem with version 1.2.0
Can you please put a link to version 1.3.0

Thanks

[bianchifan]

Version 1.3.1:

Muchas gracias

Bugs:
 

Unfortunately it doesn't work 
Splash appears on startup, 2secs later it crashes, Win7x64

[doctormord]

Version 1.3.0 is here:

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

Did tested the 1.3.1 only on Win7 32bit, no 64bit avail here to test.

doctormord

your version 1.3.1 doesn't work for me. Currently I am using Windows 10 and version 1.3.0 works fine.
meantime, I have created C# code from DDS120.EXE using ILSpy (from icsharpcode), but compiling back doesn't work (so many warnings). any advice is welcome!

Try .net Reflector 8.5, this seemed to give better code quality - but there's still code to fix afterwards.

[zp1956]

Unfortunately, I haven't tested version 1.3.1 on 32 bit platform. I did a test on 64 bit platforms only (Win7 and Win10), since I am working on such platforms.

Anyway, I will give a try to my own recompiled version.
ps. thank you for advice in your pm.

[doctormord]

Maybe the recompiled version on a 64bit machine will do. Let me know about your progress.

[doctormord]

Any progress?

[zp1956]

Unfortunately, not yet

I have tried to compile your code using fresh installation of Visual Studio 2015 Community Edition, but there is still code which should be modified.
In addition, I have tried with couple disassembler tools (Reflect, ILSpy, ..), and result is similar.
Now, my priority is to refresh one very old wah-fuzz stomp box, so I am going to use DDS120 software as it is. Modification of software is postponed.

[doctormord]

Someone may try:

http://www14.zippyshare.com/v/g5cFy1de/file.html

Straight x86 compilation.

pw: dds120

[bianchifan]

IT works on win7/64, thank you! 
Nevertheless a little note..the icon text from the scope window sidebar which appears on mouseOverIcon is still chinese..

[antrrax]

It would be possible to include the pulse trigger? For example in a square wave to trigger a greater or lesser "X" milliseconds of a negative or positive pulse.

[doctormord]

IT works on win7/64, thank you! 
Nevertheless a little note..the icon text from the scope window sidebar which appears on mouseOverIcon is still chinese..

Okay.

It would be possible to include the pulse trigger? For example in a square wave to trigger a greater or lesser "X" milliseconds of a negative or positive pulse.

The DDS120 got no hardware-trigger and the actual software-solution isn't capable of doing that. As the DDS120 just streams the ADC-content, this (to my knowledge) can't work. From the code i'd seen, implementing "pre-roll/delay" for trigger would result in a completely rewrite of the code. The code itself is coded with "DMA" and unsafe statements. So if someone knows how to do, i do not. 

[antrrax]

No problem man!!!
I just thought that with this new accessory would be possible to implement a new trigger in the program.

http://www.sainsmart.com/sainsmart-hardware-trigger-module-for-dds-140.html

-------

You could tell what function this accessory the link above?

Thanks

[doctormord]

This hw-trigger is for the DDS140, which is != DDS120. 

[bianchifan]

IT works on win7/64, thank you! 

After checking the software out I got such a divice at least, I choosed DDS140 fo rless than 80 bucks from Amazon.
Your SW doesn't recon DDS140, it seems, only "104/140"-specified version will run.
So I have to use shipped out one 1.4 from 2014.

Update:
.......
To compile und linux/ubuntu, you need to have libqt4-dev (or libqt5-dev) and fftw3-dev installed. To access the device as a user, add this to /etc/udev/rules.d/50-sainsmart.rules:

Code: [Select]

#add SainSmart DDS120 and DDS140 to group plugdev
#DDS120
SUBSYSTEM=="usb", ATTR{idVendor}=="8102", ATTR{idProduct}=="8102", GROUP="plugdev"
#DDS140
SUBSYSTEM=="usb", ATTR{idVendor}=="8312", ATTR{idProduct}=="8312", GROUP="plugdev"

and make sure that your user is member of the plugdev group.

All done, it compiles fine.
My DDS140 is recognized as Buudai104 , unfortunately the screen is empty, no waveform and no waveout on the device.
Do I need FW-extraction and loading scripts like on the Hanteks?

[doctormord]

Right, my software is actually only for the DDS120/Buudai102 as i stripped some code to cleanup and understand whats going on.

May you upload the 1.4 somewhere?

Regards,

Christian

[bianchifan]

At the moment I'm a little disappointed..
Ok, 16MHZ can be displayed, but the device/AD is quite noisy, no stable curves, triggring 
Test signal, what? 
Measure window is only a bad joke.
The scaling on Y even, for ex. 5V USB Voltage will show a line at 6.3 V, with 1/10 divider at 0.59 V.

DDS140 V1.4

[doctormord]

Are you complaining about the Channel 2 reading? I would suggest to switch this channel on first - it's actually off at both screenshots.

[bianchifan]

Are you complaining about the Channel 2 reading?

?
Of course CH2 is switched off when nothing to do.
But I can tell you, it's quite analog to CH1.
My pics are showing the test signal, should be square...
Even a slowfrequent triangle from an old XT2206 has noiserounded edges.

I attach some more pics:
- test signal how it should look like due to help screen
- USB voltage from breadboard supply, should be 5.03 V
- same through probe divider
- noise from shorted CH1 at 1V/div - 200MSamples
- same at 50mV/div
- clock signal at 16MHz crystal of an ATMEGA16 circuit

EDIT:
Forgotten..
CH1 triggers when time base is less/equal 0.1 ms
CH2 triggers never, no way 
When stopped (triger ext.) it displays a much better waveform, only slightly rounded.

[doctormord]

May you upload the 1.4 somewhere?

Have you tried to run a "calibration" with both channels on and shorted? That normally cancels out the offset for each voltage setting. If this doesn't help, i'd blame the multiplexer they use. There were some issues with this in the DDS120 as well.

[bianchifan]

May you upload the 1.4 somewhere?

DDS140 V1.4

Have you tried to run a "calibration" with both channels on and shorted?

Surely, of course I did so.

At least there are two probs, HW and SW!
For ex. within the loupe func you should be able to scroll left and right..unfortunately the arrows are greyed out always.
As long as I'm able to work bugs and glitches are a only a minor problem.
Displaying wrong values however sucks...

Two examples:
1st, absolute value, USB Voltage / AVR supply, roundabout 5V (4.8V - 5.13V may occur)
5Volts are "transformed" to 6.4V - 6-5V., three possible scenarios:
- resulting voltage < 6.4V  ->  curve will be displayed
- 6.4V < result < 6.5V  ->  Curve is displayed and a wrning message is blinking, sometimes paired with beeps- .
- result  > 6.5V  ->  blank screen, loud beeps and permanently flashing warning "Out of range!"

2nd, relative value, by 10 divided signal in 100mV/div area
Changing the screen divider to 50mV/div should double the value.
Depending on signal form and noise the value raises about 10-30%...
Changing to 200mV/div should halve the value.
Depending on signal and noise the value decreases mostly between 20% and 40%...

On youtube I found a video where the 1kHz test signal looks like it should, so maybe my device is faulty Monday crap.


Should I return it?
Or fuck the warrenty, open it and try for tuning up?

Yesterday I soldered q&d an AVR-DDS, it's quality isn't the very best but not as shitty as on my poor screen 

With these curves I wouldn't complain

[doctormord]

I would return it, this device is pretty much out of spec.

Thanks for the upload.

[zp1956]

Finally! I have my own source code working!

@doctormord
Using your executable file version 1.3.1 and decompiler/compiler pair ILSpy/SharpDevelop, I got my own customized DDS120.EXE file.
Now, as a first step I am going to change those ugly icons (since I am not native C# programmer, I have to work carefully  ).

[doctormord]

Nice, haven't thought it will work with SharpDevelope.

[bianchifan]

I would return it, this device is pretty much out of spec.

Maybe, but at least I couldn't resist and opened it and took some pics.

Front PCB


Backside


Bad soldering, looks manually

[doctormord]

Hmm, no AD adc anymore, but a chinese "pin compatible" MXT2088.

[bianchifan]

Hmm, no AD adc anymore, but a chinese "pin compatible" MXT2088.

The only datas I could find are telling 8bit ADcv 100MSPS, 90mW 1Vpp..I cannot read chinese and I'm too lazy translating those fuc...datasheets via google.
I do not think it causes the told probs.

[doctormord]

Well, they state +-500mV FS while the AD is +-512mV. Maybe a translation error as most of their data is same as AD, even in the order.

For the voltage error have a look at the gain stage resistors.

If the error is same in percentage for different ranges, I'd check the ref voltage/s at the ADC. Maybe the MXT2088 isn't that linear at the top end.

[bianchifan]

For the voltage error have a look at the gain stage resistors.

If the error is same in percentage for different ranges, I'd check the ref voltage/s at the ADC. Maybe the MXT2088 isn't that linear at the top end.

I did a few quick checks only, all seemed ok.
ON Sainsmart's HP I found an older version of DDS140.exe (v 1.2) inm Analyzer/Generator sections offered as The Newest Version
1. It displays 16 MHz same known shit but it displays.
2. Slew rate / steep curves same bullshit, even 100 Hz rectangles show rounded edges.
3. Loupe same crap, use with care, no side shifts
4. No more "Out of Range" with 5V, all signals were shown and sometimes they were triggered too.
With AC selected, Voltage is fine, 4.93 V differed between 4.89 and 4.97 V, triggerpoint is the middle vertical line.
Rising/falling seems fine, trigger level is a little mystery, only no trigger was working.
Zero adjustment has an offset of .5V, thumb ruled.

With DC selected I didn't notice any "out Of Range" too.
Depending on the selected V/div it was too high, i.e. 5.8V in 2V/div and 5.6V in 1V/div thumb ruled instead of 4.93V.
Rising/falling seems fine, trigger level is absolutely mystery, maybe for selecting the voltage area, a signal have to cover completely.
With the "T"-LIne you can mark an area froom Zero to "T", all curves staying between these lines are displayed, "normal" and "single" will do.

[doctormord]

So you'll check the resistor values at the range switch "CD40xx", maybe they aren't in the 1% or better range.

You may also check if the voltage levels are changing vs temperature.

As far as I remember the code, there's no 2 point calibration at all, just offset calibration for the zero line.

[coromonadalix]

@bianchifan

Did you check for probe calibration compensation  , a small adjustable capacitor in the base bnc connector of the probe

I had this problem before, badly calibrated probes were messing measurements, and had poor results in voltages.

[bianchifan]

I would return it, this device is pretty much out of spec.

OK, at least I did so.
NO answer from Amazon, nothing...but wait.. since 2 days they are offering a warehouse DDS140

Meanwhile I checked my new DDS140 and this device seems ok.

The two probes are of the model TP6100, which when sold separately reportedly cost $9 on eBay. They are probably not true 100MHz probes, but one review of them that I saw referred to them as "good stuff".

IMHO the probes are "bad" stuff, I wasn't able to calibrate the 1kHz rectangle correctly.
With my TP6100 probes all is fine in 1:10 position.
USB voltage is measured at around 4.9V, fine also.
At the moment I hope to work with.

[doctormord]

DDS140 V1.4

Not working anymore. 

[bianchifan]

DDS140 V1.4

Not working anymore. 

It works for me, just even tested.

Nevertheless an alternative:
https://mega.nz/#!pgdHHQIY
_________________

I wonder about the options 5V/div and 2V/div..IMHO they are nonsense
Feeded with Voltageges about 6V or more will cause the scope to strike.
A red line will be displayed combined with loud beeping.

[merbanan]

@doctormord can I get you permission to upload your image of the DDS120 pcb to the sigrok wiki website ? Earlier this week the Hantek 6022BE got supported with a driver and a firmware. I would like to extend that to support the DDS120. Right now I want to  document the hardware first.

[doctormord]

@merbanan,

You have my permission.

Just link back to "360customs.de".

Regards.

[merbanan]

Ok, I have now added:

http://sigrok.org/wiki/SainSmart_DDS120

For the record here is the Hantek 6022BL sigrok driver:

http://sigrok.org/gitweb/?p=libsigrok.git;a=tree;f=src/hardware/hantek-6xxx;hb=f2a66a8ee669df5afa1b7bdade6e25ac0857fe4b

And then the more interesting part the firmware:

http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=commitdiff;h=189db3d41e4c3d8a4aec5ec605c03df75577d531



So from reading the thread I have come to the conclusion that the Hantek and SainSmart are fairly similar but there are vital differences that will hinder the use of the Hantek firmware directly.

To start with how does the gain stage work ? What pins control that ?

[doctormord]

If i remember correctly and from the pictures:

PE3 = Channel A AC/DC via Photomos; enabled Photomos bridges AC input cap
PE0 = Channel B AC/DC via Photomos; enabled Photomos bridges AC input cap

PC1= enables Channel A compensation Network
PE1= enables Channel B compensation Network

I'm not sure if it is always enabled when doing AC coupling.

PC2 + PC3 = selects Channel B gain
PC4 + PC5 = selects Channel B gain

PB7-PB0 = Channel A 8bit input D7(MSB)-D0:
PD7-PD0 = Channel B 8bit input D7(MSB)-D0:

[merbanan]

PC1= enables Channel A compensation Network
PE1= enables Channel B compensation Network

I'm not sure if it is always enabled when doing AC coupling.

PC2 + PC3 = selects Channel B gain
PC4 + PC5 = selects Channel B gain

What is a compensation network (when would the firmware enable it) and can you clarify Channel B gain (it's there 2 times)?

What bits correlate to what gain ?

[doctormord]

The compensation network is right beside the white BNCs. I'll have to overthink it.

Edit: Compensation is always active, see schematic.

The gain stage were discussed here:

https://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-%28buudai-bm102%29/msg535341/#msg535341

It's a 2 stage approach. -6dB and -20dB on the first stage. The second stage is then doing the gain by 3 different resistor values switched into the feedback loop.

So there is:

First stage (Attentuator):
PC1: 0 = -6dB, 1 = -20dB
PE1: 0 = -6dB; 1 = -20dB

and can you clarify Channel B gain (it's there 2 times)?

Sorry, typo, it is:

PC2 + PC3 = selects Channel A gain
PC4 + PC5 = selects Channel B gain

[doctormord]

Wow, long time since i where in the circuit.

As "psynapse" pointed out here:

https://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg535995/#msg535995

with the internal switch resistance, its going like this by combination of bits.

OK I have looked a bit more at the circuit and the internal resistance of the 4052 is critical.  Allowing internal resistances of 380,500 or 400 ohms for the three states,  Q2 is programmable to have a gain of 2,3 or 5 (1+(620+380)/1000), (1+ (1500+500)/1000), (1+(3600+400)/1000)

Odd gain figures, except we are driving the ADC differential, the other side being 1, the output of the unity gain buffer.  So what the ADC sees is 2-1, 3-1 or 5-1  .... aka 1,2,4  .... It is kind of sweet in a chear cost cutting sort of way.

A quick LTspice confirms


So in summary, J3 is giving divide by two or divide by 10 (and if the divide by 2 is diode clamped, de facto divide by 10 is too)
Whilst J9 gives multiply by one, two or four

Put both together and you have, for the front end gain

x2
x1
x0.5
x0.4
x0.2
x0.1

So to sum this up:

#Channel A:
PC1=1; PC2=0; PC3= 0 -> Gain x0.1 = -20dB
PC1=1; PC2=0; PC3= 1 -> Gain x0.2 = -14dB
PC1=1; PC2=1; PC3= 0 -> Gain x0.4 = -8dB
PC1=0; PC2=0; PC3= 0 -> Gain x0.5 = -6dB
PC1=0; PC2=0; PC3= 1 -> Gain x1 = 0dB
PC1=0; PC2=1; PC3= 0 -> Gain x2 = +6dB

#Channel B:
PE1=1; PC4=0; PC5= 0 -> Gain x0.1 = -20dB
PE1=1; PC4=0; PC5= 1 -> Gain x0.2 = -14dB
PE1=1; PC4=1; PC5= 0 -> Gain x0.4 = -8dB
PE1=0; PC4=0; PC5= 0 -> Gain x0.5 = -6dB
PE1=0; PC4=0; PC5= 1 -> Gain x1 = 0dB
PE1=0; PC4=1; PC5= 0 -> Gain x2 = +6dB

[merbanan]

This is the function I need to re-implement for the SainSmart

http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=blob;f=hantek_6022be.c;h=8a73cc07b4ac74828f5303e1f1b7861dd1149cca;hb=189db3d41e4c3d8a4aec5ec605c03df75577d531#l190

With your latest info it will be straight forward. The only thing left is to figure out how to address the PEx pins and implement a new command for AC/DC coupling. And how to output the square wave pulse.

[doctormord]

I wonder if clock setting is working, as the DDS120 is using the IFCLK output:

Regarding the EZ-USB Technical Reference Manual:

http://www.cypress.com/?docID=48811

page 125, the IFCLK can only output 30/48MHz from its internal source. (I must review the trace at IFCLK and CLKOUT.)

Maybe its like:

24Mhz crystal -> PLL (48Mhz) -> /2 divider -> 8051 Core + CLKOUT [pin out] (24Mhz) -> IFCLK [pin in] + ADC_CLK (24Mhz)

Then the 8051-Core, FIFO, and ADC are running at 24Mhz at all time. Sampling is then done by 1/1 (24MHz), 1/10 (2.4MHz), 1/100 (240kHz).

From the specs, this scope should do 50Msps, but only when using both channels - single channel is 25Msps. This can't be true with a 24Mhz clock-source in no way, so we'll end up at 24/48Msps like Hantek. Even the software is lying to us when showing "50MHz" (should be "48MHz" -> 24MHz x 2 Channels)

Conclusion:

50Mhz -> 48MHz == 24MHz x 2 Channels = 24Msps per Channel
2.4Mhz == 2.4MHz x 2 Channels = 2.4Msps per Channel
240kHz == 240kHz x 2 Channels = 240ksps per Channel

The lower samplerates just skip sampling by 1/10, 1/100. 

[doctormord]

It works for me, just even tested.

Nevertheless an alternative:
https://mega.nz/#!pgdHHQIY

Needs the mega decryption key. 

[merbanan]

I wonder if clock setting is working, as the DDS120 is using the IFCLK output:

I just assumed it used the same as the Hantek.

Tracing the pin on
http://sigrok.org/wimg/d/d8/Hantek_6022be_pcb_top.jpg and http://sigrok.org/wimg/0/05/Hantek_6022be_pcb_bottom.jpg it looks to me it is connected the same as the SainSmart. (The signal goes through R35 and on both sides of the pcb and under the chips).

[bianchifan]

Needs the mega decryption key. 

2nd file is from a private account, don't know the problem..
Mega never stressed me , neither Ubuntu(64) nor win7(x64).
No idea, Zippyshare doesn't work for me since some monthsss#

BTW..PCB of the actual DDs140 shows much better soldering job

Ok, I have now added:

http://sigrok.org/wiki/SainSmart_DDS120

Please don't forget DDS140

Until now I thought Sigrok/Pulseview isn't a scope SW but Logic analyser, I used it a few times with my USBee clone from BG.

[merbanan]

Please don't forget DDS140

Until now I thought Sigrok/Pulseview isn't a scope SW but Logic analyser, I used it a few times with my USBee clone from BG.

Well Sigrok hasn't a scope yet. But it provides an api for it. So write one scope app and you can support all the hardware that sigrok has drivers for. And regarding DDS140 support, start by documenting it in the Sigrok wiki. There is lots of information spread around in this thread that could be used to create a wiki page.

[merbanan]

I created a firmware based on the Hantek 6022 one and tried to load it. The controller wouldn't re-enumerate because the fx2 had already loaded a firmware from the eeprom. I then removed a jumper on the board and then the fx2 was happy to load the image. Through the firmware seemed running the values from it was bogus.  I could just hack the eeprom so it wouldn't read the firmware from there I feel that it is much easier to write a driver for the Sainsmart and let it load its own firmware that should be working fine.

[doctormord]

You could program the sigrik firmware to eeprom as well, so it works out of the box, I guess. Flashing the EPROM is shown in this thread, also hex editing the IDs (vendor/class/usb).

For the bogus values, maybe the ADC is read out/running in a different way than on the Hantek?

[bianchifan]

Another try, anonymous on filehorst.de(germen), checked twice from different requesters

DDS140.7z

[merbanan]

You could program the sigrik firmware to eeprom as well, so it works out of the box, I guess. Flashing the EPROM is shown in this thread, also hex editing the IDs (vendor/class/usb).

For the bogus values, maybe the ADC is read out/running in a different way than on the Hantek?

Yeah I know I can modify it, but I want it to be usable without modifications. So unless anyone knows how to reload the FX2 firmware via a usb command I will just implement the SainSmart protocol for sigrok. The bogus values are definitely from differences in the hardware.

[doctormord]

Alright, the commands/functions can be seen from their .dll.

AiReadBulkData
AutoMeasurement
 BufferInit
DataPreDisposal
DeviceClose
DeviceOpen
EventCheck
GetBuffer4Read
GetBuffer4Wr
GetData
GetHWbufferSize
GetInfoByte
GetInfodouble
GetRawData4Read
SetData
SetInfo
SetReadEnableOrNot
SetStableEnableOrNot
SetTrigInfo
TrigDataPrepare
USBCtrlTrans
USBCtrlTransSimple

[merbanan]

I have been working on the sigrok driver and it is sort of working now. I also figured out how to upload custom firmware and get that running properly.

I also found out how to program the extra gain mode that is there but not used by the vendor software.

Now that all this is working I'm hitting the transfer limit of the "50MHz" mode. 240kHz and 2.4MHz seem fine with the exception of the square wave that seem to change the duty cycle depending on the sample rate. So right now I am using interrupt transfers for usb transfers. Is it possible to use something else ? Something faster or is this a limit of the firmware ?

[doctormord]

What's the extra gain mode?

Fastest mode would be fifo streaming. We discussed this in the tread somewhere one the first pages, you may want to look. Problem is, the scope is running blind when transferring data, because of the transfer they implemented.

(The original software is using polling for transfers)

[merbanan]

What's the extra gain mode?

Fastest mode would be fifo streaming. We discussed this in the tread somewhere one the first pages, you may want to look. Problem is, the scope is running blind when transferring data, because of the transfer they implemented.

(The original software is using polling for transfers)

http://sigrok.org/wiki/SainSmart_DDS120 has the details. But channel 0 has 0x0A as valid config and Channel 1 has 0x22. These modes are very close in gain to another gain step. Thus I reason that they omitted it in the software. On your blog you list 5 used modes but in your posts you listed 6. I just sorted out the details which bit to set and found out it was fairly useless.

I think you are wrong about it using polling. I think the 0x33 command is a FIFO clear command. I can at any time just request more packets without any problem. No need to issue a 0x33 command per packet. The vendor software might do it this way to be able to get a clean part of a continuous stream to analyse. They might always get zeros at the start and then a signal to do the analysis on. One of the lower time resolutions only send one 0x33 packet per 16 data packets. And there is a post in this thread where someone says he just started streaming without any start command.

As far as I understood there is a clock that clocks the adc. The adc data lines are read by the fx2 and placed in a buffer somewhere on the FX2 chip (lets say 1024 bytes). When the buffer is filled it will start filling another buffer. During that time you need to get the first buffer over to the host because when the second buffer is full the FX2 will start over with the first one. So if you didn't manage to get the first buffer in time there will be a time discontinuity.

Right now the vendor software is using usb interrupt transfers (my driver also). The openhantek dds-120 port is using bulk transfers. So it might be possible to use something else that is be better.

Anyway I need to do some more testing before I can say anything for sure. Right now I have only been testing with the built in 1kHz square wave and with a perfect timed packet drop things can appear very strange.

[doctormord]

Nice, keep it up.

[merbanan]

I took a picture of a 1kHz triangle wave. And it is easy to see here that I am missing every other buffer.

[doctormord]

Hmm, isn't it async as well?

Nice one anyway. I wonder if "readbulkdata" is caring for the buffers itself. And what will happen, if you sample both channels, available buffer would half for each channel I guess.

[merbanan]

I have now tested the sainsmarts bulk endpoint 0x86 and I could not get it working. I did get a sane transfer count when running the test120 application and using it in 2.4MHz and 2.4kHz mode. In both cases I got close to double Ms rate. But when choosing "50" MHz mode I max out at ca 7.5Ms/s.  Either the interrupt read is not working correctly with regards to some buffer handling or bulk reads are needed to be able to get more data. I am more and more convinced that a custom firmware is needed to get reliable data from the hardware.

[doctormord]

Maybe it's a setup issue. Have you checked the other .dll functions? I'm not sure if they share the dll code for both the DDS120/140.

Have you had a look into the source of "leidioskop", it should be available here in the thread.

[merbanan]

Ok, I got it all explained now. At 48MHz ("50Ms") sample rate the scope gets one frame of 1024 samples. That should be enough to capture most periodic signals. As you/others wrote before the scope is blind most of the time. The waveform update rate on this scope is low.

But the hardware can deliver more then it does with the vendor software/firmware. For example the fx2lafw firmware is able to sample at a rate of 24MHz with a logic analyzer with 8 pins. So it should be possible to get one channel with a continuous sample rate of 24MHz and 12MHz with two channels. So I just need a firmware implementing that. And yesterday I was able to get the custom Hantek 6022 firmware working. So now I need to get the gain stage working and get proper samples out of the scope.

[doctormord]

Nice, please check your private messages. 

[andrej]

Hi!

I  wanted to buy DDS140, and did a little research on the product. In that process I came across this thread. I haven't read it thoroghly, but I see that on many places, one of the major problems with DDS140 is triggering. I also came across this product on ebay http://www.ebay.com/itm/SainSmart-Hardware-Trigger-Module-for-DDS-140-Oscilloscope-/301789209154?hash=item464409e242:g:ILgAAOSwd0BVp1yg
Does this make things better? Has anyone tried it?

I am aware of the limitations of this kind of product, but I am going to buy either hantek 6022B or DDS140,or DDS 120. I am aware of tehnical specifications (by wich dds140 is the best from these 3 Products), but what do you think would be a better choice, when you consider downsides discovered in this thread, and when you consider available software?

P.s. Sorry for my bad english

[bianchifan]

I am aware of the limitations of this kind of product, but I am going to buy either hantek 6022B or DDS140,or DDS 120. I am aware of tehnical specifications (by wich dds140 is the best from these 3 Products)

A couple of months ago I thought exactly the same direction 
Some words to the trigger.
Sadly it's not very stable as I'm used in former times with my old analog Hameg.
Nevertheless it's usable for timebase > 1 us, on shorter base the signal is runnin' thru..
CH2 can only be triggered together with CH1, a lonely CH2 is running to Mars.
I do not think, the external trigger will change anything, it's just another base.
I guess that the module s only an enclosure for the two lines.
Have a look on my oics above, they are connected to pins 1 and 4 on the bottom row.
You can stick to with a Dupont jumper.

Sometimes CH2 is very noisy, until now I couldn't evaluate the reasons.

The greatest disadvantages IMHO are the input dividers..
The max. possible positive voltage is ~6V, the max neg. voltage (DC) sometimes 1.6 V, sometimes 3.6 V, max possible neg. voltage AC ~5V.

Result: At logic level you need an external 1/10 divider. 

My reason for buying were the 200MSa, 'cause I wanted a "real" 20 MHz scope.
If you can live with an absolutely shitty software you can work with.

[merbanan]

Ok, I have now sent a pull request for support in Sigrok. I added a new firmware based on the Hantek 6022BE firmware. Coupling support is missing in the firmware but other then that it should be feature complete. To maybe be added is the possibility to change the frequency of the 1kHz pulse and to add a few more sampling frequencies.

What more is missing is a good oscilloscope application that can use the driver. But pulseview should be quite capable for the time being.

And last but not least writing the firmware had not been possible without all the info in this thread. Especially the layout picture by doctormord.

[doctormord]

Great news mate! How can the coupling problem be fixed, so what's needed?

[merbanan]

How can the coupling problem be fixed, so what's needed?

Just the time to add the support to the firmware and the driver. The Hantek driver didn't support coupling, that is the main reason for current lack of support.


Now to an analogue signal question. I have enabled the 1kHz pulse, is there a possibility that this pulse causes noise in the signal sampling? Or is the pcb signal path properly shielded ?

[doctormord]

Nothing is shielded on the pcb, it's just 2 layers. From the board picture it can be seen that the top ground is opened over the 1kHz trace (which is on the bottom). The analog signals are "embedded" in the top analog ground section, so they did a bit of isolation.

If you can't see any 1kHz artefacts at highest gain, i wouldn't call this an issue.

Any chance to get the actual firmware?

[merbanan]

Any chance to get the actual firmware?

Here it is:

https://github.com/merbanan/sigrok-firmware-fx2lafw/tree/sainsmart-dds120

and here is the needed change to libsigrok:

https://github.com/merbanan/libsigrok/tree/sainsmart-dds120

[doctormord]

Thanks,

a working blob would be nice, as i actually wont setup the build environment.

Please check your mails. 

[merbanan]

a working blob would be nice, as i actually wont setup the build environment.

Here it is. This firmware might be compatible with the Hantek 6022BE software.

[doctormord]

Thanks,

i spend the last couple of hours to fix the "OpenHantek-Mod" aka "Ledioskope" from this thread. Codebase is from "mmark".

The bufferproblem is somehow fixed (glitch after 1k of data), timebase is working up to 200ms/DIV, "correct" buffersize is selected by timebase-value. Trigger is still not working but with the trigger-sliders, you can adjust possible glitch-position aka bufferposition.

 
EDIT: Obsolete
Download: https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_GlitchFix.zip

See: https://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg911658/#msg911658
for actual code.

[mmark]

Great progress!

@DrMord: could you share your src code changes? I have some time during the next two weeks and could try to get the triggering working.

Thanks,

M.

[doctormord]

Sure,

i actually try so get the trigger working. It actually does for buffersizes <= 2048 for both channels on rising edge at sine/triangle but still at bad hack. I know that the original DDS120 firmware have a "pretrigger-rolling" implemented, but i do not have the control code.

Will share the code then.

[mmark]

Follow-up:

I had to install http://download.qt.io/archive/qt/5.3/5.3.2/qt-opensource-windows-x86-mingw482_opengl-5.3.2.exe AND set the following environment variable  QT_QPA_PLATFORM_PLUGIN_PATH to c:\Qt\Qt5.3.2\5.3\mingw482_32\plugins\platforms\ to get DrMord's latest binary to run in my Windows XP VM...

The buffersize is now set correctly automatically, nice! But the 1k buffer glitch / restart / discontinuity still seems to be there, see attached screen shot. I believe that we need an updated firmware on the DDS120/140 to fix this issue correctly, so I'll try to get merbanan's firmware running with openhantek or pulseview.

M.

[mmark]

Here it is. This firmware might be compatible with the Hantek 6022BE software.

Merbanan,
how do you get the firmware into the DDS120? Does sigrok/pulseview download it automatically when you start or do you have to download it manually? If so, could you tell us how to do this? I am still trying to get pulseview compiled on my macbook...

Thanks a lot,

M.

[doctormord]

Here's the possible trigger approach:

EDIT: Obsolete
Compiled: https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V1.zip
Source: https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V1-SOURCE.zip

See: https://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg911658/#msg911658
for actual code

It is implemented in buudai_control.cpp

Works for rising signals.

CHANGES:
- setup highest voltage-divider on start (5V)
- implemented trigger-hack

BUGS/FIXES needed:

- Make trigger work with slope-function (QT button action)
- Make trigger work on start up (it is not working on the first start or when changing trigger source channel, you always have to click on the small trigger-level-arrow once to make it work)
- Disable/Hide Buffersize Menu (action is actually commented out), as Buffersize is set according to timebase
- Make trigger more solid to noise (dunno how)
- Make trigger work with fast risetimes/transients (triggering on square-wave is not really working well)

I added some comments to the parts i changed.

Regards,

doc

[doctormord]

But the 1k buffer glitch / restart / discontinuity still seems to be there, see attached screen shot. I believe that we need an updated firmware on the DDS120/140 to fix this issue correctly, so I'll try to get merbanan's firmware running with openhantek or pulseview.

M.

There isn't on mine. As far as i know, this problem is on the 6022 as well:

https://github.com/OpenHantek/openhantek/issues/7#issuecomment-168538575

The latest source/binary reintroduced some glitching, so this finally needs to be fixed. Skipping just 1024(*2) bytes from the data received did not fixed it in any way. I actually use the "readmulti" to get bigger blocks - so to have valid 1k data per channel you'll need to read 4k overall and drop the first 2k, would guess. 

Edit:

I don't know how to make a proper "release" build. I did a "release" to get the .exe and then copied all missing .dll files to that folder until it started. 

[doctormord]

Just ran some USBPcap to see what's going with the trigger in original Buudai software, the triggering is done in their USBInterface.dll in software. 

Edit:

Hooking up the scope on a dedicated USB-hub removed (nearly) all glitches, triggering on squarewave works then. 

Changes for next version:
- Markerslidersteps 0.2 -> 0.1 of DIV - DONE
- Move Waveform by Triggerpositionslider - DONE
- Select triggervoltage in 0.01V steps - DONE

[merbanan]

how do you get the firmware into the DDS120? Does sigrok/pulseview download it automatically when you start or do you have to download it manually? If so, could you tell us how to do this? I am still trying to get pulseview compiled on my macbook...

When starting pulseview, libsigrok will scan for usb devices registered to a driver. The hantek6xxx driver will try to load the firmware and after that it is go time. So if you are compiling everything yourself you need to get my 1 patch to libsigrok and build and install my firmware package.

FX2load should be able to manually load the firmware also. I did not test it myself but it should work in theory. Upon loading the firmware the device should renumerate as a new usb device.

[merbanan]

F
The buffersize is now set correctly automatically, nice! But the 1k buffer glitch / restart / discontinuity still seems to be there, see attached screen shot. I believe that we need an updated firmware on the DDS120/140 to fix this issue correctly, so I'll try to get merbanan's firmware running with openhantek or pulseview.

M.

We can not get rid of these discontinuity glitches totally at higher sample rates as the usb bus is not fast enough to transfer all the data we need (we might get drops at <=24MHz also depending on the available IO on the used usb bus). What we can do is to lower the sample rate to match the signal frequency. That way we can have 1024 samples (or 2048 if we only use one channel) to describe the pulse shape. If we sample a periodic signal we need 5 cycles of the signal to always find a good triggering spot. Start in the middle of the buffer, find the triggering position forward and backwards. Translate the signal so it matches the previous triggering position. The result should be an always pleasantly looking waveform.

[mmark]

When starting pulseview, libsigrok will scan for usb devices registered to a driver. The hantek6xxx driver will try to load the firmware and after that it is go time. So if you are compiling everything yourself you need to get my 1 patch to libsigrok and build and install my firmware package.

FX2load should be able to manually load the firmware also. I did not test it myself but it should work in theory. Upon loading the firmware the device should renumerate as a new usb device.

OK, got your modified hantek6xxx firmware and libsigrok compiled on my Macbook. When I start Pulseview, the firmware seems to get uploaded to the DDS120, since the PID:VID changes from 0x8102:0x8102 to 0x6022:0x04b5 and the DDS120 device is now listed as a 'HantekDSO6022BE'

Pulseview shows that it found a Sainsmart DDS 120, but sadly I get an USB error 'sr: hantek-6xxx: Failed to submit transfer: LIBUSB_ERROR_PIPE' when I try to acquire data. Any idea why this could happen?

When I try to use the the unmodified OpenHantek with the DDS120 AFTER the new firmware was uploaded, it finds the device but I also get an error when OpenHantek tries to acquire data: "Couldn't get channel level data from oscilloscope".

@merbanan: What OS are you using?

[merbanan]

OK, got your modified hantek6xxx firmware and libsigrok compiled on my Macbook. When I start Pulseview, the firmware seems to get uploaded to the DDS120, since the PID:VID changes from 0x8102:0x8102 to 0x6022:0x04b5 and the DDS120 device is now listed as a 'HantekDSO6022BE'

Pulseview shows that it found a Sainsmart DDS 120, but sadly I get an USB error 'sr: hantek-6xxx: Failed to submit transfer: LIBUSB_ERROR_PIPE' when I try to acquire data. Any idea why this could happen?

When I try to use the the unmodified OpenHantek with the DDS120 AFTER the new firmware was uploaded, it finds the device but I also get an error when OpenHantek tries to acquire data: "Couldn't get channel level data from oscilloscope".

@merbanan: What OS are you using?

I am using Linux (Ubuntu 15.04). And from your output the firmware is loading fine. OpenHantek is probably trying to use the hantek vendor protocol which fails for whatever reason. I have no idea why pulseview wont work but I recall that I saw some bugs in the driver that might cause issues. Can you try with sigrok-cli ?

sigrok-cli -d hantek-6xxx --samples 2000

[merbanan]

Pulseview shows that it found a Sainsmart DDS 120, but sadly I get an USB error 'sr: hantek-6xxx: Failed to submit transfer: LIBUSB_ERROR_PIPE' when I try to acquire data. Any idea why this could happen?

I committed a fix for some issues I found. There is a very low chance your issue got fixed by my changes. But try it out and see if it changes anything.

[merbanan]

Coupling support in firmware and sigrok driver is implemented now.

[doctormord]

Nice!

Seems like someone messed up the DDS120 page at Sigrok (Hardware Section).

[merbanan]

I think I figured out how to get something like an external trigger working. Pin PE2 is connected to the 1kHz calibration pulse output. If we change the direction to an input we can use that as a trigger signal. The trigger signal then needs to set PA7 when you get a trigger condition. For some reason PA7 is connected to the RDY0 pin and the RDY0 signal enables the configured GPIF program 0. So if it would be possible to only run the GPIF program 0 once and then fetch the samples then we could realize this feature.

[doctormord]

Interesting find.

I somehow managed to implement a "PLL-loop" into the trigger, works quite good. (Actually not at full 48M speed)

I had a look into the original Software again, they got the same triggering problems from the scope data.

https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V2-SOURCE.zip
https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V2.zip

CHANGES:
- Markerslidersteps 0.2 -> 0.1 of DIV - DONE
- Move Waveform by Triggerpositionslider - DONE
- Select triggervoltage in < 0.05V steps - DONE
- Make trigger more solid - DONE

[mmark]

Coupling support in firmware and sigrok driver is implemented now.

Nice!

I got it finally working on OSX (my Macbook is at 10.10.5) after banging my head against the table for quite a while. The problem seems to be that the USB bulk transfer size must be a power of two. So I had to change the define of FLUSH_PACKET_SIZE in src/hardware/hantek-6xxx/protocol.h from 2600 to 2048 and replace the line:

Code: [Select]


data_left += MIN_PACKET_SIZE; /* Driver does not handle small buffers. */
with:

Code: [Select]

uint32_t i;
for (i = 512; i < data_left; i *= 2)
;
data_left = i;
in src/hardware/hantek-6xxx/api.c in static uint32_t data_amount(const struct sr_dev_inst *sdi) around line 550.

After those changes, I can read valid data with sigrok-cli and pulseview. Changing the coupling seems to work as designed!

I'll try DrMords changes later tonight or tomorrow...

M.

[merbanan]

I got it finally working on OSX (my Macbook is at 10.10.5) after banging my head against the table for quite a while. The problem seems to be that the USB bulk transfer size must be a power of two. So I had to change the define of FLUSH_PACKET_SIZE in src/hardware/hantek-6xxx/protocol.h from 2600 to 2048 and replace the line:

Code: [Select]


data_left += MIN_PACKET_SIZE; /* Driver does not handle small buffers. */
with:

Code: [Select]

uint32_t i;
for (i = 512; i < data_left; i *= 2)
;
data_left = i;
in src/hardware/hantek-6xxx/api.c in static uint32_t data_amount(const struct sr_dev_inst *sdi) around line 550.

After those changes, I can read valid data with sigrok-cli and pulseview. Changing the coupling seems to work as designed!

M.

Can you send your changes as a github pull request so you get the proper attribution for this fix ?

[merbanan]

I've started adding more sample rates and some sample rates are possible to both have with a 48MHz clock or 30MHz clock. Am I correct in believing that a slower ADC clock might give slightly more stable samples?

[doctormord]

I would say it just gives less "noise" due to less samples. (But it's not getting better, just looks like that)

Oversampling, averaging and/or decimation is another/better approach.

[mmark]

Can you send your changes as a github pull request so you get the proper attribution for this fix ?

Done! I also changed the VID:PID of the Sainsmart DDS-120 FW from the Hantek VID:PID (0x04b5:0x6022) to something unique (0x8102:0xd120).

BTW: pulseview crashes on both Linux (without my changes) and Mac OSX (with my changes) when I try to record 10M samples or more. 5M works fine...

[MysticPixel]

So I read through the thread but there's been a lot of programs going back and forth, I'm not sure what I should be looking for software-wise if I'm considering picking one of these up.

Basically I just want something to check timings on uC projects. I have a Usbee (AX? older... it's like the DX but only 8 channels) but it just doesn't play nice with some ICD devices etc. Looking for something cheap but most importantly the software has to not be total rubbish. Honestly, vertical accuracy isn't too important for this app, I just need something that can reasonable capture signals, and my trusty Tek 2445 is starting to fritz... (also need something digital)

I'd be willing to spend the ~$90 US or so for a dds-140 but I'm kind of at a loss for what software is the best / most developed.

Anyone care to sum it up for newcomers to the thread? C'mon, pimp your badass programs and tell me which one I should be using! :-P

ninja edit: it looks like SanSmart has a Logic Analyzer add-on that's only another few $. Anyone tried it?

[lavajumper]

I'm with MysticPixel on this count. I got a DDS140, siggen and logic unit as a christmas present. The software crashes more than a drunken stock car, and I'm getting different readings off the signal generator between versions  v1.4 vs. v6 . (Seriously, 5 major version bumps in 4 months???)

I'm impressed with the work I've been reading about here, but having a hard time figuring out what needs done, what's been done, what the current files are.
I'm more than willing to help with the porting/dev of the QT part.

Is there a github?
What do we need to do to get this hardware running?

I'm not bitching, I'm trying to roll up my sleeves.

[merbanan]

Just a heads up. The sigrok stuff is now committed upstream.

http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=commit;h=ce1d0a869e4761d30b698b6bb1ea015a0470f09e

There are some more things I would like to add to the firmware but most of the focus will be on the driver side. Currently there is no calibration but that will eventually be fixed as I now have the proper hardware and tools to do it.

[doctormord]

With much thanks to Joe Vee,

there's some progress with the "OpenHantek DDS120".

* Version 0.3.1
* Support for SainSmart/Buudai DDS120 (mmark)
* Better support for SainSmart/Buudai DDS120 (CW)
* Trigger Support for DDS120 (CW)
* Markerslidersteps 0.2 -> 0.1 of DIV (CW)
* Select triggervoltage in < 0.05V steps (CW)
* Improve trigger stability by excluding false positive cases (JV)
* Added falling edge trigger support (controlled by GUI button) (JV)
* The other channel now use the same trigger position as the trigger source channel, ensuring that the timing relationship between the channels is maintained. Only the trigger source channel determine the trigger position. This is an important requirement for signals that are generally different (in shape and phase) across the channels. (JV)
* Eliminate the "rolling buffer" problem and fix the segmentation fault issue. (JV)
* Improvement in the robustness of rising/falling edge detection prior to locating the trigger position offset, especially, for slow signals (e.g 100ms, 200ms timebases). (JV)
* Keep the start of displayed waveform (trigger source channel) in level with the trigger position on the slider control. (JV)
* The trigger position sliders now work separately and only the trigger source channel controls the trigger position. (JV)
* The glitches (discontinuities) in the capture data recurring at around 2KB (combined byte count for both channels) boundaries seems to be a HW/FW limitation of the DDS120 that would be difficult to workaround. (JV)

I set up the sources on GitHub:

https://github.com/doctormord/OpenBuudai

Any commits are welcome.

[Ripman]

Version 1.3.1:

Changes:
- Based on Version 1.3 (found on DX)
- FFT optimization (update rate)
- Timing optimization
- Fixed some GUI glitches
- Longer timebases added again
- Antialiasing
- Translations
- Ability to change signal width (1-10px)

Bugs:
 

DDS120_V1.3.1.rar
http://www99.zippyshare.com/v/p14YpYdf/file.html

pw? dds120

Hello, I am new around here and I have a DDS140. Do you know if this modified version works for DDS140? I cannot seem to make it work, also if there is any more stable version of software. I have troubles getting Triggers (Normal/Single) to work sometimes. I am currently using this version from SainSmart 1.4 https://s3.amazonaws.com/Barsoom/Z0/Z00I0C0Z/Z00I0C0Z.zip

https://www.amazon.de/SainSmart-DDS140-Oscilloscope-Signal-Generator/dp/B00HD6F8HY/ref=sr_1_1?ie=UTF8&qid=1465221711&sr=8-1&keywords=DDS140

Many thanks!

[mjwx4p]

Hello,
i have an SainSmart DDS-120. My development environment is debian linux jessie.
i'm trying to use OpenBuudai as oscilloscope software, but whatever i try, i got the message that OpenHantek (OpenBuudai) don't find any Buudai oscilloscope. I'm not sure which information i have to give you, but as i said, i had complete compile OpenBuudai and the app is working. I had installed libusb-1.0.20 too. I have no idea what i have to do now. My next idea is to tell OpenBuudai which port it have to use, but don't know how. Have someone any experience with linux and OpenBuudai? Thanks for your help 

Marko 

[doctormord]

Did you set up the udev rules right?

[bianchifan]

Do you know if this modified version works for DDS140?

Yes, it doesn't work.

I have troubles getting Triggers (Normal/Single) to work sometimes.

That seems to be normal, triggers are not really working at all.

I set up the sources on GitHub:

https://github.com/doctormord/OpenBuudai

Any commits are welcome.

[mjwx4p]

here is my udev-rule (file 10-local.rules)

ACTION=="add",  SUBSYSTEM=="usb",  ATTR{idVendor}=="1111",  ATTR{idProduct}=="2222",  MODE="0666",  GROUP="plugdev"

If i list my usb devices, there is a weird entry for my oscilloscope:

Bus 003 Device 006: ID 1111:2222 Pandora International Ltd.

I have the same ID on the Windows 10 OS. But with the original driver (but only with the old version of it) the oscilloscope works, but only with the bad original software DDS-120 from sainsmart themself.
This is my oscilloscope definitely, cause i had tested it. If i unplug my oscilloscope the entry doesn't appear.
Do i need to patch the firmware? If yes, how?
Thanks for your help.
Regards
Marko

[doctormord]

Strange, the older ones always have 8102:8102 (pid/vid) do your firmware is different.

Check the code in openbuudai if the app is fixed to the older pid/vid combination.

[mjwx4p]

Hi,

Strange, the older ones always have 8102:8102 (pid/vid) do your firmware is different.

Check the code in openbuudai if the app is fixed to the older pid/vid combination.

that was it. Thanks. I think these strange VID:PID combination is a mistake and not normal. Pandora Industries Ltd. isn't a vendor who produced oscilloscopes. In the OpenBuudai code i changed the pid/vid to my requirements and OpenBuudai works now.
Damn, i have many jammings in my scope ( i want to trigger the code of a remote control), but this is normal, we are living here very close to radio mast of cellphone-provider, this is the reason of these jammings.

[doctormord]

It would be interesting if the firmware differs much to the one I have. Are you able to dump the firmware?

[bianchifan]

Check the code in openbuudai if the app is fixed to the older pid/vid combination.

Luckily the DDS140 type is fixed to "8312" in buudai_types.h, same as offered from mine

For I have no plan how to compile on Win7 I just even tried on Ubuntu 15.10.
Unfortunately compilation failes at last step:
g++ -m64 -Wl,-O1 -o bin/openhantek build/obj/colorbox.o build/obj/configdialog.o build/obj/configpages.o build/obj/dataanalyzer.o build/obj/dockwindows.o build/obj/dsocontrol.o build/obj/dsowidget.o build/obj/exporter.o build/obj/glgenerator.o build/obj/glscope.o build/obj/helper.o build/obj/levelslider.o build/obj/main.o build/obj/openhantek.o build/obj/settings.o build/obj/hantek_control.o build/obj/hantek_device.o build/obj/hantek_types.o build/obj/buudai_control.o build/obj/buudai_device.o build/obj/buudai_types.o build/obj/dso.o build/obj/moc_colorbox.o build/obj/moc_configdialog.o build/obj/moc_configpages.o build/obj/moc_dataanalyzer.o build/obj/moc_dockwindows.o build/obj/moc_dsocontrol.o build/obj/moc_dsowidget.o build/obj/moc_exporter.o build/obj/moc_glscope.o build/obj/moc_glgenerator.o build/obj/moc_levelslider.o build/obj/moc_openhantek.o build/obj/moc_settings.o build/obj/moc_hantek_control.o build/obj/moc_hantek_device.o build/obj/moc_buudai_control.o build/obj/moc_buudai_device.o build/obj/qrc_application.o build/obj/qrc_configdialog.o    -L/usr/lib/x86_64-linux-gnu -L/usr/X11R6/lib64 -LC:/Qt/lib/libusb/MS32/dll/ -llibusb-1.0 -LC:/Qt/lib/fftw-3.3.4-dll32/ -lfftw3-3 -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread
/usr/bin/ld: cannot find -llibusb-1.0
/usr/bin/ld: cannot find -lfftw3-3
collect2: error: ld returned 1 exit status
Makefile.Release:193: recipe for target 'bin/openhantek' failed

to compare... same step at openhantek:
g++ -m64 -Wl,-O1 -o bin/openhantek build/obj/colorbox.o build/obj/configdialog.o build/obj/configpages.o build/obj/dataanalyzer.o build/obj/dockwindows.o build/obj/dso.o build/obj/dsocontrol.o build/obj/dsowidget.o build/obj/exporter.o build/obj/glgenerator.o build/obj/glscope.o build/obj/helper.o build/obj/levelslider.o build/obj/main.o build/obj/openhantek.o build/obj/settings.o build/obj/sispinbox.o build/obj/hardcontrol.o build/obj/control.o build/obj/device.o build/obj/types.o build/obj/moc_colorbox.o build/obj/moc_configdialog.o build/obj/moc_configpages.o build/obj/moc_dataanalyzer.o build/obj/moc_dockwindows.o build/obj/moc_dsocontrol.o build/obj/moc_dsowidget.o build/obj/moc_exporter.o build/obj/moc_glscope.o build/obj/moc_glgenerator.o build/obj/moc_levelslider.o build/obj/moc_openhantek.o build/obj/moc_settings.o build/obj/moc_sispinbox.o build/obj/moc_hardcontrol.o build/obj/moc_control.o build/obj/moc_device.o build/obj/qrc_application.o build/obj/qrc_configdialog.o    -L/usr/lib/x86_64-linux-gnu -L/usr/X11R6/lib64 -lfftw3 -lusb-1.0 -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread

I have no skills in c++/g++ but when I change "-llibusb-1.0" to "-lusb-1.0" and "-lfftw3-3" to "-lfftw3" it compiles fine.
When started DDS140 is recognized but nothing further happens

[mjwx4p]

i will try to dumb the firmware and will post it here. Again thanks for your help.

[doctormord]

[dummyquote]I have no skills in c++/g++ but when I change "-llibusb-1.0" to "-lusb-1.0" and "-lfftw3-3" to "-lfftw3" it compiles fine.[/dummyquote]

That's normal and just fine. I should note that on the manual page. A proper make file should handle that, but I'm not into it. For compiling on Windows, there's a hint in the thread here.

[mjwx4p]

Hi,
i had opened my device now, and here is a picture of it. If i compare the picture of doctormord and my picture, then there are several differences between our devices visible. It seems i have another hardware revision as doctormord.   

I have some troubles to connect my device with ponyprog2000 or similiar. Maybe someone can help me with that. What i have to do?

Thanks for your help

[mjwx4p]

Hi,
ok i can establish the connection now with Cypress Suite 3.4.7 if i install the cypress driver usb3 from cypress itself without jumper R32. But i can't establish the connection with ponyprog2000, even jumper R32 is plugged in or not. Which driver i have to use to work with ponyprog2000?

[naut]

hey guys,

does anyone have pictures of what's inside the logic analyzer module for the DDS140 model?

thanks

[heisenberg281]

Dropbox link to version 1.5 of their software for the DDS120. Enjoy!
https://www.dropbox.com/sh/rzxfia0bvhxpgwk/AADpJyxka11HUzifM4XeGtXda?dl=0

[clizza]

This is such a long and varied thread I'd like to try for a simple, summary answer? I am running Windows 10 Pro, 32-bit x64-based, and cannot get the unit to work and strongly suspect the driver. SainSmart has answered a couple emails telling me to manually install the Win7/XP driver manually which I have done successfully? I have only tried testing using the square wave tab but do not read any voltage/freq. Note that I get this same behavior if I use the default driver install which looks like a Windows Phone driver!

SainSmart pointed me to a dropbox of older software, v1.2 of the app, while I see references here to v1.5 and wonder if the driver has ever been updated -- the driver on the v1.5 dropbox appears to be the same. I installed it and tried with the app versions 1.2, 1.3 and 1.5 with exactly the same result.

SainSmart has not responded when I asked if they have ever tested Win10 installs so I hope there is help here?

Thanks, Carl

[clizza]

Has anyone ever solved this issue? I am running Win10 under Parallels and get exactly the same behavior.

Thanks, Carl

[bianchifan]

I do not know win 10 but it should run with version 1.3..
https://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg817650/#msg817650

[doctormord]

Wasn't it using the standard WinUSB driver?

[clizza]

Using the standard WinUSB driver I get the same results -- no voltages let alone no trace. I cannot blame graphics until I see valid data displayed. In summary, with Win10, neither the DDS120 driver nor the standard WinUSB driver registers any data other than period, width, etc.

Is Win10 to blame? I wish I had never upgraded but cannot go back that I know of...

-- Carl

[doctormord]

Well, tried Open_Budich from the thread here?

[clizza]

I have not tried Open_Budich and cannot find a link? See atch for what I am working with...

[doctormord]

This i meant:
https://github.com/doctormord/OpenBuudai

Well, you could try using a VM and Win7 or send the scope back.

[lclark]

Reporting happiness and success running OpenBuudai on Gentoo with a DDS120.

udev rules required an update (as previously stated in this thread).  Compilation required minor changes to the .pro file, as expected.

/etc/udev/rules.d/50-sainsmart.rules

Code: [Select]

SUBSYSTEM=="usb", ATTR{idVendor}=="8102", ATTR{idProduct}=="8102", GROUP="users"
https://github.com/doctormord/OpenBuudai

Much happier vs. the SainSmart tools in Windows.

Thanks!

[savvej]

Hi Guys,

I purchased DS-140 from amazon and it looks to be working fine with Windows 10 , 64bit for me.
No drivers separately installed. Just using the latest gui software from their website, DS140_v6.rar
http://www.sainsmart.com/zen/documents/20-010-731/DDS140_V6.rar

Regards,
sav

[swedgin]

I've been able to install openbuudai on ubuntu 16.04 for the DDS-120 and ran it using 'openhantek' in the terminal. Thanks for the software   

i was wondering though, how I could change the triggerlevel and if it was possible to view some standard measurements like frequency, min/max, amplitude,..
Thanks

[doctormord]

Trigger level should follow the small arrow to the right.

Gesendet von meinem SM-A510F mit Tapatalk

[bplaa.yai]

Hi guys,

Did anyone have any success with a DDS140 on Linux ? OpenBuudai compiled just fine here, udev rules added and the DDS140 is detected okay.
But all calls to libusb_bulk_transfer() in Device::bulkTransfer() are failing with LIBUSB_ERROR_TIMEOUT.
I'll be happy to dig more into this, but I'd like to make sure I've not made/forgotten anything silly first. For example, it's not clear to me if it's required to upload any firmware or not ? (by looking at some messages here it seems it's not)

Not sure if it's the right place to ask about this, but this thread seems a lot more active than the github page

Cheers

[doctormord]

OpenBuudai was never tested with the DDS140, so it needs complete implementation of the different command set. (As the DDS140 uses an FPGA)

[bplaa.yai]

I'd like to make sure I've not made/forgotten anything silly first.

OpenBuudai was never tested with the DDS140, so it needs complete implementation of the different command set. (As the DDS140 uses an FPGA)

Well, that's exactly the kind of "silly" I was expecting

Regarding the command set, and based on PapaLukas' Logic140, it looks almost identical between the 120 and the 140 (OpenBuudai types vs. Logic140 init code).

Anyway, time to do my homework

Regards,

[SquidCap]

Dropbox link to version 1.5 of their software for the DDS120. Enjoy!
https://www.dropbox.com/sh/rzxfia0bvhxpgwk/AADpJyxka11HUzifM4XeGtXda?dl=0

Thanks a ton mate! The one on their website is just rubbish. As a payback, i'll tell my quest to get this scope..

Ordered from the manufacturer webpage, nothing wrong there. They sent it, took a bit but all seemed to be in order, package was moving. But then, nothing. Weeks rolled by and the package didn't arrive. Finally strange message came that said that the package could not be delivered. No other explanation and i contacted Sainsmart. They were helpful but did suggest for sometime that it was my fault, that i had not been at home or something (i ordered so that i have to pick it up, just so i can pay possible costs if it had any extras and to inspect the parcel). But since this could not be the case, i pestered them to get to the bottom of the problem. They wanted to send a new or cancel the deal but i said that if they do that, they learn nothing what happened. It took 3 emails to finally get them to react and they did. They found out that the company they used was putting theirs and other clients packets to same pallets and in there was something that was stopped at EU border (nothing illegal, if i got it right, it was batteries or some other stuff like that) so the whole thing was sent back to china. They had had plenty of weird unexplained returns before so..  Glad that i persevered, maybe next guys in EU can get theirs without trouble.

Haven't tried with the proper software yet but it seems to work 100%, now that i fixed the loose BNC connector (a bit wimpy springs, i think i'll replace that with something that takes a good grip on the inner pin...., little bit of wiggling and good ole in&out and it makes good connection now, didn't do anything out of the box though which was concerning)

[DOCa Cola]

I've made the effort to compile OpenBuudai for both Windows and Mac since all links in this thread for it are dead

Works fine on my DDS120 as far as i can see. Except the single shot trigger which i couldn't get to do anything and the Mac version has a bug after you start the program (see workaround in my description below).



Windows: http://s000.tinyupload.com/index.php?file_id=21051875976332290019
I've included all required libraries for the Windows version. Just extract and run.

Mac: http://s000.tinyupload.com/index.php?file_id=09276964695742077948
The Mac build has a broken GUI after start each time. Atleast on my mac. The toolbars have to be reenabled each time and there is a graphical bug that goes away when you use the zoom function once.
Also no libraries are included with this binary. You need to install these with brew.

Code: [Select]

brew install fftw libusb qt

[bb512]

Trying the DDS-120 for the first time - but can't scope US house current - using the probe at 10X - 1.5 Windows software.

Am I just out of range?

- update - added the OpenHantek image too

[luminary6]

Thank You for binary! Windows 7 x64, DDS120 from SainSmart worked.

[swedgin]

So I got this working before on ubuntu. I did however a reinstall and tried to install openbuudai again. There isn't a specific guide for linux, only bits and peaces across several files. I tried to document while I was installing for future references but I couldn't complete it. I don't know where to find the drivers for DDS120 so I can extract them with extractfw.

This is what I did to install it. I can open the program but my oscilloscope can't be recognized.

sudo apt-get install libqt4-dev libfftw3-dev libbfd-dev

cd /directory/of/choice
git clone https://github.com/doctormord/OpenBuudai

cd Source

nano OpenHantek.pro
uncomment line 11 and 15, comment line 10 and 14

qmake
make
make install

Download dsoextractfw from https://sourceforge.net/projects/openhantek/files/

tar xvjf openhantek-extractfw-0.7.0.tar.bz2
cd dsoextractfw
./configure
make
make install
cp 90-hantek-dso.rules /etc/udev/rules.d/

[swedgin]

So I forgot the .sys file. But I have still problems. I've installed the driver on a windows 10 machine and copied the winusb.sys file to my ubuntu 16.04 laptop. When trying to extract the firmware I get the following error.

speklap:openhantek-extractfw$ ./openhantek-extractfw winusb.sys
BFD: winusb.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .text
BFD: winusb.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .rdata
BFD: winusb.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .data
BFD: winusb.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .pdata
BFD: winusb.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .idata
Section .data found (starting at 0xfc00, 512 bytes)
Symbol _firmware found (offset 0xffffffffffff0400, 0 bytes)
Symbol _loader found (offset 0xffffffffffff0400, 512 bytes)
Can't get firmware contents: Bad value

Can someone host a valid .sys file or help me get around this?

Greatly appreciated

[savvej]

I'd like to make sure I've not made/forgotten anything silly first.

OpenBuudai was never tested with the DDS140, so it needs complete implementation of the different command set. (As the DDS140 uses an FPGA)

Well, that's exactly the kind of "silly" I was expecting

Regarding the command set, and based on PapaLukas' Logic140, it looks almost identical between the 120 and the 140 (OpenBuudai types vs. Logic140 init code).

Anyway, time to do my homework

Regards,

Hi,

As far as the Logic140 code is concerned, I was able to compile it under Linux-Ubuntu using neatbeans and gcc compiler.The JNI library had to be ported to call corresponding functions from libusb available in Linux, compared to the winusb implementation provided.
The gui seems to work and connect to the DDS140 scope when invoked as a root. See snapshot attached, for the case when the test signal from the scope is probed in CH1.Though I think the GUI as well as the implementation is not great especially for the oscilloscope version, since there is lot of data loss happening (The red region which is seen in the gui) . Also zooming/panning function seem to be dsyfunctional.

Thus,I wanted to tryout OpenBuddai.I was able to compile it on linux and run it. The device was detected  but data capture is failing with similar error as you posted. Since the initialization works fine in Logic140, we should be able to port it in OpenBuddai and a quick glance of the code seems like the sequence is similar. Maybe some minor difference here and there. Let me know if you want to assist me in the bringup.

Regards,
Shabbar

[savvej]

Hi All,

Just an update.

I was able to edit the OpenBuddai code and edited initialization sequence and the getSamples sequence as per the Logic140 code.
The getSamples sequences polls until receiveing a 0x21 before reading the buffer, as in Logic140 code and this seems to resolve the timeout issue. And, surprisingly, I was able to get something on the scope when probing the scope's signal. See attached below.Though I am unable to capture the square wave test source train properly.

May be, many of the other settings related to voltage /sampling/timebase settings too will need to be updated.I think we are not too far from getting this working.

@doctormord and or @papalukas, if we can have a quick skype call, we can figure out what is missing or needs to be tweaked and get it functioning properly.

Regards,
Shabbar

[UnSeen]

Hello guys
The vendor's software drives me crazy. And I can't find any working link to versions newer than 1.2. Could someone post it please?
Have anybody managed to run OpenBuddai with DDS140 yet?
I've just built it and it prints "Getting sample data failed: Operation timed out" as supposed

I was able to edit the OpenBuddai code and edited initialization sequence and the getSamples sequence as per the Logic140 code.
The getSamples sequences polls until receiveing a 0x21 before reading the buffer, as in Logic140 code and this seems to resolve the timeout issue.

If would be cool if you could share your modified code. Thanks

[keropi]

anyone has a working link for windows software 1.50 ?
thanks!!!

edit:
I have uploaded the ISO that contains 1.50 + drivers + videos , suitable for both DDS120 and DDS140

https://www.mediafire.com/file/4bkw7vsc7fy9755/SainSmart-DDS120-DDS140.rar/file

[mmark]

Just a heads up: I spend the last couple of days adding support for the Sainsmart DDS120 to the new and improved OpenHantek6022. It uses the sigrok firmware for the DDS120.
Works already pretty good (tested on MacOS 10.14 and Ubuntu 18.04 with qt5!).

Source is here: https://github.com/msiegert/OpenHantek6022 for now and hopefully will get merged into Ha-Ro's original repository.

Since there also is a sigrok firmware for the DDS140, I expect that after adding the firmware (or running sigrok-cli first to upload the firmware to the scope) and adding the USB PID/VIDs for the DDS140, it should also work.

[kimbergirl]

does somebody want my dds-120 before i smash it to bits?
or is there a solution to get old old crappy version of .NET to install on win 10?

tried everything....

[mmark]

Try https://github.com/OpenHantek/OpenHantek6022/releases/download/v2.17-rc5/OpenHantek-Win-x64-Release-b169.zip (64 bit) or https://github.com/OpenHantek/OpenHantek6022/releases/download/v2.17-rc5/OpenHantek-Win-x86-Release-b169.zip (32 bit).

DDS120 support has been integrated into OpenHantek6022...

 

[kimbergirl]

thanks for the quick reply
i still dont regret the nastygram that is in the Sainsmart inbox
back to work on the electric car......

[Rio]

@mmark: Thanks for your effort. I used the DDS120 easily with the last version of OpenHantek6022 in Win7...

[kimbergirl]

thanks
someday i will get frustrated enough to get a stand alone O scope not tied to the strange fleeting whims of programmers and a separate compute box

[luminary6]

Have problem with DDS120 and OpenHantek6022 (b188)
I try use my DDS120 again, find new software OpenHantek6022 (b188) and try configure all again.
I see that OpenHantek6022 not read calibration data from DDS120 and zero is not in zero and gain wrong.
This is normal?
Anybody try use OpenHantek6022 with DDS120?
Your device is calibrated?

I make calibration file C:\Users\USER\.config\OpenHantek\modelDDS120.conf
with content (for my DDS120):

Code: [Select]

; OpenHantek calibration file
; individual calibration values for DDS120
; will be read by .../src/hantekdso/modelDDS120.cpp

; filename is modelDDS120.conf
; copy into ~/.config/OpenHantek (Linux)
; copy into %USERPROFILE%\.config\OpenHantek (Windows)

; multiply channel to get the correct gain
[gain]

ch0\20mV=1.250
ch0\50mV=1.244
ch0\100mV=1.241
ch0\200mV=1.298
ch0\500mV=1.164
ch0\1000mV=1.199
ch0\2000mV=1.205
ch0\5000mV=1.203

ch1\20mV=1.231
ch1\50mV=1.235
ch1\100mV=1.252
ch1\200mV=1.322
ch1\500mV=1.193
ch1\1000mV=1.219
ch1\2000mV=1.221
ch1\5000mV=1.224

; add offset values
[offset]

ch0\20mV=6
ch0\50mV=6
ch0\100mV=6
ch0\200mV=5
ch0\500mV=6
ch0\1000mV=5
ch0\2000mV=5
ch0\5000mV=5

ch1\20mV=5
ch1\50mV=5
ch1\100mV=5
ch1\200mV=5
ch1\500mV=5
ch1\1000mV=5
ch1\2000mV=5
ch1\5000mV=5


I write this message for any who want use OpenHantek6022 software with SainSmart DDS120 and will face the same problem.

[horo]

Hello luminary6,

Thx for providing your conf file. OpenHantek6022 already does provide a template for this file, but with gain = 1.0. I had a quick look into the input gain selection there and there in this thread and will update the model file accordingly, so that even without a conf file the gain error will not become too big, a rough estimation would be:

Code: [Select]

specification.voltageLimit[0] = { 32 , 80 , 160 , 155 , 170 , 165 , 330 , 820 };
specification.voltageLimit[1] = { 32 , 80 , 160 , 155 , 170 , 165 , 330 , 820 };
If you build your own binary, please check, otherwise I will put it into my source later today.
If you're on windows, you can get a binary of every commit from appveyors artifacts. There are also the older builds available.

Martin

EDIT:
I've created a new issue #39 on github.

EDIT2: Closed issue, luminary6 please check if the scope behaves better when used without conf file.

[horo]

Hello luminary6,

I updated the DDS120 handling again, please check the latest build:
https://ci.appveyor.com/project/Ho-Ro/openhantek6022/build/artifacts
If you want to test older Win builds, there's also a history:
https://ci.appveyor.com/project/Ho-Ro/openhantek6022/history

Martin

[luminary6]

1) I download b205 version.
2) I rename my calibration config file (disable).
3) Connect DDS-120 to USB (probes are disconnected).
4) Run old version (b188, x64) and get zero at:
CH1 = -0.62 Volt
CH2 = -0.41 Volt
5) Reconnect DDS-120 to USB.
6) Run new version (b205, x64) and get zero at:
CH1 = 5.96 Volt
CH2 = 6.01 Volt

Changes in software is wrong.
Also i think you can not set calibration data for all users (if different models of DDS-120 have different electronic parts etc ...)
May be good way is revert calibration data to 1.0
But official software is working normally and measure is precise, how it working i do-not know. May be official software read calibration data from device?

[luminary6]

I read your message at github and understand that you correct only "gain", but "offset" value you remove from source.

"Ok, no problem, I've just removed your 1.18 : 1.21 correction if there is no conf file and therefore adjusted the specification values accordingly, so it should give a +- 5% accuracy for 1st time users - only offset has to be adopted individually."

I was remove gain section in my config file, and run new version (b205) with only offset in my config file.

EDIT2: Closed issue, luminary6 please check if the scope behaves better when used without conf file.

Voltage gain is fine, measured values close to real.

But becouse voltageLimits is divided by calibration value (how i understand after see source code), my old calibration data is not valid for new version of program, and need recalculation.

[konkdekilo]

I wanted to inform you for those who still have a DDS140 that I am running it in the lotto OS802  software and that it works perfectly on w10 without the need for a driver.
I leave capture and link for those who may be interested greetings.



https://drive.google.com/drive/folders/1ST3awUa5HEMRMAV_RmmmOf8mwPNBn1TI