SainSmart DDS120 & DDS140 USB Oscilloscope - Page 1
Forum section: electronics / testgear

author: ganzuul
author_rank: Contributor
timestamp: May 20, 2014, 04:29:20 pm
content: ED:We have FOSS code!!/EDThis 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.99in total. I ordered it from here:http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=300992154516So 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.pdfC10 - CY7C68013A:http://www.cypress.com/?docID=45142R13 - 24LC64:http://www.mouser.com/ds/2/268/21189h-21840.pdfI'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.JPGhttp://nya.dy.fi/static/images/PICT3348.JPGhttp://nya.dy.fi/static/images/PICT3347.JPGThese photographs are just under 6MB each.ED2:Updates..

author: ganzuul
author_rank: Contributor
timestamp: May 20, 2014, 11:31:00 pm
content: Well my ISP shut me down for a few when I tried to zone transfer some Chinese DNS records.I was thinkingwww.buudai.commight 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.htmlLooks 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(Fromhttp://www.dx.com/p/bm102-bm102-50mhz-2-ch-usb-analog-oscilloscope-silver-grey-271544#.U3vp5a4Rots)

author: mikewardlow
author_rank: Newbie
timestamp: August 23, 2014, 12:50:37 pm
content: I purchased the DDS120  in August. It sort of works , the display software needs much improving,I was trying to detect a pulse train  100us pulse, 100us delay, 100us pulse, 8 second delay, this sequence repeatsTrying 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

author: mikewardlow
author_rank: Newbie
timestamp: August 26, 2014, 03:27:48 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: August 31, 2014, 11:54:12 pm
content: Thanks for your efforts. Let us know on any news. :-)CheersdocEdit:Q2/Q3/Q?/Q? = AD8065ART-R2Datasheet:http://www.analog.com/static/imported-files/data_sheets/AD8065_8066.pdf

author: doctormord
author_rank: Regular Contributor
timestamp: September 15, 2014, 06:34:59 pm
content: If someone please could dump the I2C eeprom? Somehow i fried mine.

author: biot
author_rank: Regular Contributor
timestamp: September 15, 2014, 10:57:26 pm
content: Quote from: doctormord on September 15, 2014, 06:34:59 pmUsually 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.

author: dannyf
author_rank: Super Contributor
timestamp: September 15, 2014, 11:07:35 pm
content: QuoteYou 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.

author: doctormord
author_rank: Regular Contributor
timestamp: September 16, 2014, 01:36:16 am
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: September 26, 2014, 10:02:13 am
content: Anyone tried yet?Cheers, doc

author: ganzuul
author_rank: Contributor
timestamp: October 04, 2014, 04:58:20 am
content: Oh hey! Didn't notice people were posting here! =DI'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?Quote from: dannyf on September 15, 2014, 11:07:35 pmAh, that was supposed to be a joke. I removed it now.

author: frenky
author_rank: Unknown
timestamp: October 04, 2014, 07:42:39 am
content: 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=33947http://www.cypress.com/?id=4&rID=26141http://cosmiac.ece.unm.edu/images/7/71/CyConsole.pdf

author: ganzuul
author_rank: Contributor
timestamp: October 05, 2014, 02:06:34 am
content: 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:>cd C:\Cypress\Cypress Suite USB 3.4.7\Driver\bin\wlh\x64>pnputil -i -a cyusb.infMeanwhile, Vend_Ax.hex is located in C:\Cypress\USB\CY3684_EZ-USB_FX2LP_DVK\1.0\Firmware\Vend_ax if you usehttp://dlm.cypress.com.edgesuite.net/akdlm/downloadmanager/software/CY3684Setup.exeIn 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.

author: ganzuul
author_rank: Contributor
timestamp: October 06, 2014, 12:54:56 am
content: 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=sharingI'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! =)

author: doctormord
author_rank: Regular Contributor
timestamp: October 06, 2014, 11:05:49 am
content: 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 installationO0Flashing is done via a simple parallel-port-programmer called "Easy I²C Bus interface":http://www.lancos.com/prog.html#easyi2cBottom 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

author: ganzuul
author_rank: Contributor
timestamp: October 08, 2014, 09:21:59 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 09, 2014, 12:07:43 am
content: A little off topic. I have the DDS140 (BM104) which usesad9288cy7C68013altera 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 acquisitionHowever 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 finePostscript: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

author: donut6
author_rank: Contributor
timestamp: October 09, 2014, 06:18:43 pm
content: 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!

author: gambit58
author_rank: Newbie
timestamp: October 10, 2014, 04:11:03 am
content: HelloI 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

author: ganzuul
author_rank: Contributor
timestamp: October 10, 2014, 09:06:23 am
content: Quote from: psynapse on October 09, 2014, 12:07:43 amThat'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?Quote from: donut6 on October 09, 2014, 06:18:43 pmAre the probes identical too?I'll gladly collaborate with you on the scope app. =DAttached 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.htmI 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 ifhttp://en.wikipedia.org/wiki/Karplus%E2%80%93Strong_string_synthesiscan't be used for a kind of triggering... Wave form stabilization, to be exact. The theory is just extremely interesting.

author: ganzuul
author_rank: Contributor
timestamp: October 10, 2014, 09:07:29 am
content: Quote from: gambit58 on October 10, 2014, 04:11:03 amDoes it show up in Device Manager? Did you try installing it on another PC?

author: psynapse
author_rank: Regular Contributor
timestamp: October 10, 2014, 09:46:33 am
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 10, 2014, 10:08:24 am
content: 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 outStill 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 posthttp://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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 10, 2014, 12:35:14 pm
content: 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 (seehttps://github.com/olerem/openhantek/commit/9a0d2747edc9306b1b56c04a4a9d491269023c76)

author: ganzuul
author_rank: Contributor
timestamp: October 10, 2014, 05:38:51 pm
content: 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! =DDo 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. =)

author: psynapse
author_rank: Regular Contributor
timestamp: October 10, 2014, 09:52:48 pm
content: 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.

author: ganzuul
author_rank: Contributor
timestamp: October 11, 2014, 12:20:58 am
content: 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.

author: donut6
author_rank: Contributor
timestamp: October 11, 2014, 12:44:00 am
content: 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)

author: ganzuul
author_rank: Contributor
timestamp: October 11, 2014, 04:19:14 am
content: 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.7zI have not yet analyzed the capture. It's 18MB uncompressed.

author: psynapse
author_rank: Regular Contributor
timestamp: October 11, 2014, 11:34:59 am
content: 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 examplehttp://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.

author: donut6
author_rank: Contributor
timestamp: October 11, 2014, 01:09:27 pm
content: 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

author: psynapse
author_rank: Regular Contributor
timestamp: October 11, 2014, 10:21:35 pm
content: 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- DoneHere is the result:Not a huge amount of code. Will get to it at the end of the weekend

author: ganzuul
author_rank: Contributor
timestamp: October 12, 2014, 02:56:02 am
content: 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:xxd -r eeprom\ dump.txt dds140.binI 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.

author: donut6
author_rank: Contributor
timestamp: October 12, 2014, 11:52:38 am
content: QuoteHaven'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 .

author: doctormord
author_rank: Regular Contributor
timestamp: October 12, 2014, 01:57:07 pm
content: Quote from: psynapse on October 10, 2014, 12:35:14 pmTheir 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:AiReadBulkData0x100010800x000010801 (0x1)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionAutoMeasurement0x10001ff00x00001ff02 (0x2)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionBufferInit0x100012c00x000012c03 (0x3)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionDataPreDisposal0x100012d00x000012d04 (0x4)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionDeviceClose0x100034600x000034605 (0x5)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionDeviceOpen0x100034100x000034106 (0x6)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionDllMain0x100010000x0000100024 (0x18)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionEventCheck0x100031a00x000031a07 (0x7)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionGetBuffer4Read0x100012200x000012208 (0x8)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionGetBuffer4Wr0x100012b00x000012b09 (0x9)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionGetData0x10001c900x00001c9010 (0xa)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionGetHWbufferSize0x100011600x0000116011 (0xb)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionGetInfoByte0x100011900x0000119012 (0xc)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionGetInfodouble0x100011c00x000011c013 (0xd)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionGetRawData4Read0x100012000x0000120014 (0xe)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionResetPipe0x100032e00x000032e015 (0xf)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionSetData0x10001e200x00001e2016 (0x10)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionSetInfo0x100011200x0000112017 (0x11)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionSetReadEnableOrNot0x100011000x0000110018 (0x12)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionSetStableEnableOrNot0x100011100x0000111019 (0x13)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionSetTrigInfo0x100011700x0000117020 (0x14)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionTrigDataPrepare0x10002c700x00002c7021 (0x15)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionUSBCtrlTrans0x100030e00x000030e022 (0x16)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionUSBCtrlTransSimple0x100030800x0000308023 (0x17)USBInterFace.dllE:\DDS120\USBInterFace.dllExported FunctionCode:DllMain0x100010000x000010003 (0x3)publicDLL.dllE:\DDS120\publicDLL.dllExported FunctionGetData0x100010300x000010301 (0x1)publicDLL.dllE:\DDS120\publicDLL.dllExported FunctionSetData0x100010e00x000010e02 (0x2)publicDLL.dllE:\DDS120\publicDLL.dllExported FunctionDDS140:Code:AiReadBulkData0x100010800x000010801 (0x1)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionAutoMeasurement0x100023400x000023402 (0x2)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionBufferInit0x100012c00x000012c03 (0x3)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionDataPreDisposal0x100012d00x000012d04 (0x4)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionDeviceClose0x100037c00x000037c05 (0x5)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionDeviceOpen0x100037700x000037706 (0x6)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionDllMain0x100010000x0000100024 (0x18)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionEventCheck0x100034f00x000034f07 (0x7)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionGetBuffer4Read0x100012200x000012208 (0x8)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionGetBuffer4Wr0x100012b00x000012b09 (0x9)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionGetData0x10001fe00x00001fe010 (0xa)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionGetHWbufferSize0x100011600x0000116011 (0xb)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionGetInfoByte0x100011900x0000119012 (0xc)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionGetInfodouble0x100011c00x000011c013 (0xd)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionGetRawData4Read0x100012000x0000120014 (0xe)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionResetPipe0x100036300x0000363015 (0xf)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionSetData0x100021700x0000217016 (0x10)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionSetInfo0x100011200x0000112017 (0x11)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionSetReadEnableOrNot0x100011000x0000110018 (0x12)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionSetStableEnableOrNot0x100011100x0000111019 (0x13)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionSetTrigInfo0x100011700x0000117020 (0x14)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionTrigDataPrepare0x10002fc00x00002fc021 (0x15)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionUSBCtrlTrans0x100034300x0000343022 (0x16)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionUSBCtrlTransSimple0x100033d00x000033d023 (0x17)USBInterFace.dllE:\DDS140\USBInterFace.dllExported FunctionCode:DllMain0x100010000x000010003 (0x3)publicDLL.dllE:\DDS140\publicDLL.dllExported FunctionGetData0x100010300x000010301 (0x1)publicDLL.dllE:\DDS140\publicDLL.dllExported FunctionSetData0x100010e00x000010e02 (0x2)publicDLL.dllE:\DDS140\publicDLL.dllExported FunctionComparing 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.pdfMainly, 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

author: ganzuul
author_rank: Contributor
timestamp: October 13, 2014, 05:58:35 am
content: Behold!http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQFX2If 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-CodeAnd underhttp://files.ettus.com/binaries/maint_images/uhd-images_003.007.003-release.tar.gzWe find /uhd-images_003.007.003-release/share/uhd/images/usrp1_fw.ihxIn 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

author: psynapse
author_rank: Regular Contributor
timestamp: October 13, 2014, 02:22:48 pm
content: 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!

author: psynapse
author_rank: Regular Contributor
timestamp: October 13, 2014, 02:41:36 pm
content: All,Sorry, I need to read the board more carefully.Donut6I 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 knowGanzuul,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 FIFODoctormord,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 wrongOn 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 13, 2014, 05:15:49 pm
content: 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

author: psynapse
author_rank: Regular Contributor
timestamp: October 13, 2014, 06:31:51 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 13, 2014, 07:12:23 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: October 13, 2014, 07:18:17 pm
content: Quote from: psynapse on October 13, 2014, 02:41:36 pmTo 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 13, 2014, 11:43:55 pm
content: Doctormord,I agree with you, and that is exactly the problem ... there is no hardware trigger (confirmed by sainsmart), the software just guessesOn 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 thesecondbyte 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 manner76 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

author: doctormord
author_rank: Regular Contributor
timestamp: October 14, 2014, 12:37:44 am
content: As far as I remember, the DDS140 should have an external trigger input. (seen in the software trigger menu, CH1/CH2/EXT)

author: psynapse
author_rank: Regular Contributor
timestamp: October 14, 2014, 09:47:27 am
content: 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?

author: doctormord
author_rank: Regular Contributor
timestamp: October 14, 2014, 10:42:58 am
content: I would guess, it's available at the expansion header.

author: ganzuul
author_rank: Contributor
timestamp: October 14, 2014, 03:21:28 pm
content: 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 gotfosphorworking, by telling my shell toCode: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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 14, 2014, 11:33:08 pm
content: I'm wrong again. There are some more command codes

author: doctormord
author_rank: Regular Contributor
timestamp: October 15, 2014, 11:00:57 am
content: Someone asked for demo-code or "SDK"?Its in here:http://m5.img.dxcdn.com/CDDriver/CD/sku.271544.rarThe included publicDLL.dll only supports "GetFre; GetVolt; Setpara".., the programmcode refers to "getData"..QuoteTranslated from?.txtEdit: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.htmlEdit2: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

author: ganzuul
author_rank: Contributor
timestamp: October 15, 2014, 02:50:29 pm
content: Quote from: doctormord on October 15, 2014, 11:00:57 amSo that's why I couldn't get it to work.It just seems to incredibly useless. What could have been the point of this?

author: doctormord
author_rank: Regular Contributor
timestamp: October 15, 2014, 04:16:57 pm
content: "Because we can."

author: psynapse
author_rank: Regular Contributor
timestamp: October 15, 2014, 08:45:41 pm
content: 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 notAll: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 scope2)finding out what all the twiddly hardware setup codes are (optional, if I am prepared to live with the supplied ##### software)

author: donut6
author_rank: Contributor
timestamp: October 15, 2014, 09:33:37 pm
content: psynapse,I can start to comment my code now!Code: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 codeCode: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:r = libusb_bulk_transfer(scope_handle, 0x2 | LIBUSB_ENDPOINT_IN, scope_data, sizeof(scope_data), &transferred, 1000);scope_request(0x24, 0x18) enables ch1 & ch2 inputscope_request(0x24, 0x19) enables ch1 inputscope_request(0x94, 0x10) sets the ADC to "100Mhz"scope_request(0x94, 0x1c) 10MhzI 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!

author: doctormord
author_rank: Regular Contributor
timestamp: October 15, 2014, 09:45:34 pm
content: Good job guys!

author: psynapse
author_rank: Regular Contributor
timestamp: October 16, 2014, 12:24:37 am
content: Donut6Keep going! Great.I am getting slightly different time base codes (with bit4=0) ie94,00=100megs94,0C =10 megs94,08=625kHz94,0B = 39khz (ie 100M/256)less sure24,0A C2 to AC24,1A C2 to DC94,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 DDS140I 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 16, 2014, 06:14:33 am
content: Quote from: psynapse on October 15, 2014, 08:45:41 pmHi 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:No. Time Source Destination Protocol Length Info6076 647.832144000 1.2 host USB 65563 URB_INTERRUPT inFrame 6076: 65563 bytes on wire (524504 bits), 65535 bytes captured (524280 bits) on interface 0USB URBUSBPcap pseudoheader length: 27IRP ID: 0xffffffff86746be8IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)IRP information: 0x01, Direction: PDO -> FDO0000 000. = Reserved: 0x00.... ...1 = Direction: PDO -> FDO (0x01)URB bus id: 7Device address: 1Endpoint: 0x82, Direction: INURB 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:TimebaseSampleratedppsSize50ns-1us50MHz1010244us2.4MHz10204820us2.4MHz104096200ns2.4MHz565536500ns2.4MHz5655361ms-5ms240kHz56553610ms240kHz3,7*13107220ms240kHz1,85*262144100ms240kHz0,91*524288200ms240kHz0,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):DDS120Control Settings24,00 CH1 to AC24,08 CH1 to DC25,00 CH2 to AC25,01 CH2 to DC94,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 rate33,00 request dataCH1 Voltage setting:22,08 50mV22,04 100mV22,00 200mV22,06 500mV22,02 1V22,02 2V22,02 5VCH2 Voltage setting:23,20 50mV23,10 100mV23,00 200mV23,12 500mV23,02 1V23,02 2V23,02 5VSo 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 output60,00 sine wave output61,00 triangle outputSome misc codes:34,01 enable logic analyzer mode34,00 enable scope modeI 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 DELAY24,08 CH1 to DC25,01 CH2 to DC94,1022,02 CH1 1-5V23,02 CH2 1-5V90,01; 90,02; 90,05; 90,03; 90,06; 90,0490,07; 90,08; 90,09; 90,0A; 90,0B; 90,0C; 90,0D; 90,0E; 90,0F; 90,10; 90,11; 90,12; 90,1394,1022,02 CH1 1-5V23,02 CH2 1-5VFirst time running (using START button) with default settings (SainSmart Version):90,01; 90,02; 90,05; 90,03; 90,06; 90,0490,07; 90,08; 90,09; 90,0A; 90,0B; 90,0C; 90,0D; 90,0E; 90,0F; 90,10; 90,11; 90,12; 90,1394,0122,02 CH1 1-5V23,02 CH2 1-5V24,08 CH1 to DC25,01 CH2 to DCFor the DDS140 i got some more requests at:34, 50, 63, 75, 76, 77, 78, 79, 7A, 7B, 7C, 7D, E7, 90, 94Edit:Due to some magic, i opened up some kind of calibration menu in the rocktech software.Code:#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 137To access, start BM102.exeselect "Oscilloscope + Signal Generator" from the menuchange to Signal-Generator windowpress play button once (beside the number-buttons)change back to "Osillagraph" windowRight 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" buttonClick "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 #definesDunno 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 16, 2014, 11:21:36 am
content: DoctormordFirst, 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 beenSo 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 16, 2014, 11:33:24 am
content: 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/

author: doctormord
author_rank: Regular Contributor
timestamp: October 16, 2014, 12:02:42 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 16, 2014, 12:54:30 pm
content: 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) etcBTW 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

author: doctormord
author_rank: Regular Contributor
timestamp: October 16, 2014, 08:28:32 pm
content: Quote from: psynapse on October 16, 2014, 12:54:30 pmThe 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.Quote from: psynapse on October 16, 2014, 12:54:30 pmWhat anomalies do you see here?Regards,docEdit:I wonder, how the framesize is set for the different timebases?

author: psynapse
author_rank: Regular Contributor
timestamp: October 17, 2014, 12:20:20 am
content: DocAnomolies, 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 handsAnd 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

author: doctormord
author_rank: Regular Contributor
timestamp: October 17, 2014, 12:29:46 am
content: Thanks for the reply, double checked to 22,23 commands, they're valid as shown previously.Regards,doc

author: psynapse
author_rank: Regular Contributor
timestamp: October 18, 2014, 10:53:51 am
content: database problems with the forum yesterday, my full reply lostAll 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 codescall 1 send 85call 2 send 87 backcall 3 send 6 backcall 4 return B2call 5 return 7Ecall 6 return B0call 7 return B8call 8 return 7Acall 9 return 7Acall 0A return 8Bcall 0B return 7fcall 0C return 7bcall 0Dreturn 8Ecall 0E return 84call 00Fh return 88call 10h return 80call 11 and 13h return 89call 12h return 85and the command 34 codes seem very plausible for the DDS140, they play with the right hardware bitscommands 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

author: ganzuul
author_rank: Contributor
timestamp: October 18, 2014, 01:03:15 pm
content: 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.ENCBon 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

author: psynapse
author_rank: Regular Contributor
timestamp: October 18, 2014, 02:02:44 pm
content: 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 (seehttp://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.

author: ganzuul
author_rank: Contributor
timestamp: October 18, 2014, 02:28:39 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 18, 2014, 02:41:09 pm
content: AllJust 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 scopeI used it to transfer data at 20 MBytes/s (2 x 10 MS/s) formany 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 righttype of software (e.g. fx2pipe) to handle the async IO."I see those as really helpful and positive words.

author: ganzuul
author_rank: Contributor
timestamp: October 19, 2014, 07:48:13 am
content: 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.pdfPrinceton has decided some ECC schemes may be used for compression:https://www.princeton.edu/~verdu/reprints/Lossless%20Data%20Compression%20Via%20Error%20Correction.pdfThe 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!

author: doctormord
author_rank: Regular Contributor
timestamp: October 20, 2014, 01:59:49 pm
content: 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=sourceandhttp://sigrok.org/wiki/Fx2lafwThe open source sigrok driver which implements logic analyzer functions with the help of:https://github.com/djmuhlestein/fx2lib

author: ganzuul
author_rank: Contributor
timestamp: October 21, 2014, 09:42:04 am
content: 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. =)

author: psynapse
author_rank: Regular Contributor
timestamp: October 21, 2014, 11:58:32 am
content: 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 observationsWhat 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 dataAt 625ksps the DDS140 captures 52 % of dataAt 10Msps just 6.2 %At "100" Msps around 0.65 % of dataSo 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

author: ganzuul
author_rank: Contributor
timestamp: October 21, 2014, 08:49:45 pm
content: 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:usb.transfer_type == 0x1I 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 21, 2014, 09:52:56 pm
content: QuoteIndeed, it always sends data from both channels, as i'd shown some posts before.

author: ganzuul
author_rank: Contributor
timestamp: October 21, 2014, 10:15:33 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 22, 2014, 12:05:02 am
content: "if this is simply the state the software was in when time ran out for the dev. "100% agreeGuys: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 EDITExcept 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 22, 2014, 01:50:13 pm
content: 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.jpgRegards,doc

author: donut6
author_rank: Contributor
timestamp: October 22, 2014, 03:24:40 pm
content: psynapse - hopefully this should line up with your DDS140 firmware analysisCode:// 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)

author: doctormord
author_rank: Regular Contributor
timestamp: October 22, 2014, 04:02:57 pm
content: Updated Version:https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpgPE3 and PE0 controls 2 PhotoMOS Relays directly at the Input to switch between AC/DC coupling. (NAIS 210EH)

author: doctormord
author_rank: Regular Contributor
timestamp: October 22, 2014, 05:28:21 pm
content: Quote from: ganzuul on October 21, 2014, 10:15:33 pmThis 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:1ms-5ms240kHz56553610ms240kHz3,7*13107220ms240kHz1,85*262144100ms240kHz0,91*524288200ms240kHz0,459*1048576With 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.Quote from: psynapse on October 21, 2014, 11:58:32 amHere we go:https://dl.dropboxusercontent.com/u/5641160/DDS120_CH1_AC_ON_CH2_AC_ON_200mV_5ms_240kHz.rarSettings 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 23, 2014, 12:04:31 am
content: 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.6Command 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 CPLDYou saw my earlier post that the 90 commands just return a static parameter ... have you seen a pattern?

author: psynapse
author_rank: Regular Contributor
timestamp: October 23, 2014, 12:50:27 am
content: 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 ADCThere 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 23, 2014, 06:55:06 am
content: 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.-->QuoteIf some coder could explain? Where is the magic?Found this:http://msdn.microsoft.com/en-us/library/windows/hardware/ff540352%28v=vs.85%29.aspxBut 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.aspxHardware-wise i updated the tracefile to:https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpgClocking and ADC-setup is traced back.DFS=0 -> Offset binary outputS1=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 attenuationJ3X1 is giving -20dB attenuationThere are 3 possible gain-settings, which is set by multiplexer J9:620R -> 0.61K5 -> 1.463k6 -> 3.5Code:0x220x080000 1000150mV/div-6dB Input+10dB Gain (x3.5)0x220x040000 01001100mV/div-6dB Input+3.3dB Gain (x1.46)0x220x000000 00001200mV/div-6dB Input-4.4dB Gain (x0.6)0x220x060000 01101500mV/div-20dB Input+3.3dB Gain (x1.46)0x220x020000 001011-5V/div-20dB Input-4.4dB Gain (x0.6)0x230x200010 0000250mV/div-6dB Input+10dB Gain (x3.5)0x230x100000 10102100mV/div-6dB Input+3.3dB Gain (x1.46)0x230x000000 00002200mV/div-6dB Input-4.4dB Gain (x0.6)0x230x120000 11002500mV/div-20dB Input+3.3dB Gain (x1.46)0x230x020000 001021-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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 23, 2014, 04:26:38 pm
content: Curious, how does the ADC gets clocked?Regarding the EZ-USB Technical Reference Manual:http://www.cypress.com/?docID=48811page 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 Channel2.4Mhz == 2.4MHz x 2 Channels = 2.4Msps per Channel240kHz == 240kHz x 2 Channels = 240ksps per ChannelThe 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)

author: psynapse
author_rank: Regular Contributor
timestamp: October 23, 2014, 09:43:11 pm
content: (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 scrutinyBut in the meantimeWell done ( I know how aweful SMD circuit tracing is)

author: psynapse
author_rank: Regular Contributor
timestamp: October 23, 2014, 10:45:41 pm
content: 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 confirmsSo 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 fourPut both together and you have, for the front end gainx2x1x0.5x0.4x0.2x0.1Transfer ratesNow 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 ithttp://www.triplespark.net/elec/analysis/USB-LiveOsci/

author: psynapse
author_rank: Regular Contributor
timestamp: October 23, 2014, 11:43:18 pm
content: DoctormordSorry, 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 doAs 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?

author: doctormord
author_rank: Regular Contributor
timestamp: October 24, 2014, 05:36:21 am
content: Quote from: psynapse on October 23, 2014, 10:45:41 pmWell, 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)QuoteFor 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)QuoteX 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 24, 2014, 08:59:07 am
content: '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!

author: doctormord
author_rank: Regular Contributor
timestamp: October 24, 2014, 12:45:03 pm
content: 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#/PA7QuoteQuoteSource: 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 ReadsFrom 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 isasserted. -> 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.jpgPreview attached.

author: psynapse
author_rank: Regular Contributor
timestamp: October 24, 2014, 03:12:47 pm
content: 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!

author: doctormord
author_rank: Regular Contributor
timestamp: October 24, 2014, 08:54:29 pm
content: Resoldered the IC and tried sigrok:http://sigrok.org/wiki/Main_PageThere 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/Fx2lafwSourcecode 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.

author: ganzuul
author_rank: Contributor
timestamp: October 24, 2014, 09:18:32 pm
content: 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.

author: donut6
author_rank: Contributor
timestamp: October 24, 2014, 09:22:56 pm
content: 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:CXX := g++CXXFLAGS := -O2 -g -DGL_GLEXT_PROTOTYPES -I./scope.o: scope.cpp$(CXX) $(CXXFLAGS) `wx-config --cxxflags` -c scope.cpp -o scope.oscope: scope.o$(CXX) scope.o -o scope -lusb-1.0 -lGL -lGLU -lX11 `wx-config --libs --gl-libs`

author: psynapse
author_rank: Regular Contributor
timestamp: October 24, 2014, 10:53:00 pm
content: Donut6,Many thanks for the code, I will look at it very shortly.Doctormord1) 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 attachmentI 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 approachSecondly 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 timeAnd 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

author: psynapse
author_rank: Regular Contributor
timestamp: October 24, 2014, 11:41:51 pm
content: Donut6Wow lots of dependencies! What did I expect? You work on your machine and this is work in progress.Struggling with the dependencies wx/wx.hI have installed as per the screen snap, any quick ideas please?

author: donut6
author_rank: Contributor
timestamp: October 24, 2014, 11:49:15 pm
content: psynapse,Try libwxgtk3.0-devAnd libusb-1.0.0-devmake scope./scopeYou'll need an udev rule set up for 8312 8312

author: doctormord
author_rank: Regular Contributor
timestamp: October 24, 2014, 11:51:00 pm
content: 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)

author: psynapse
author_rank: Regular Contributor
timestamp: October 25, 2014, 12:01:19 am
content: Donut6Both already installed ..... the dreaded path problem then. I will look in the morning, but thanks anywayDoctormordThank 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 softwareAllSorry, away from keyboard this weekend , it is our village fête this weekend

author: donut6
author_rank: Contributor
timestamp: October 25, 2014, 12:27:41 am
content: psynapse,Does this command work?Code:wx-config --cxxflagsIf so, perhaps the Ubuntu wxwidgets package doesn't set up the include path correctly.alsoCode:wx-config --list

author: doctormord
author_rank: Regular Contributor
timestamp: October 25, 2014, 09:59:46 am
content: Doctormord1) 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 attachmentI 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 approachSecondly 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/4You may check if IFCLK is connected to CLKOUT somehow.Quote from: doctormord on October 23, 2014, 04:26:38 pmAt DDS120, it is not. So the ADC is running either running at 30 or 48Mhz.

author: psynapse
author_rank: Regular Contributor
timestamp: October 25, 2014, 12:01:21 pm
content: Hi Donut6,Thanks again, it looks as though from the replies the install is correctQuote-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__ -pthreadQuoteDefault config is gtk2-unicode-3.0Default config will be used for outputAlternate matches:base-unicode-3.0But please leave it, I will sort it after the weekend..... Your time better spent on advancing the code.DoctormordI 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 25, 2014, 12:24:49 pm
content: 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.Fromhttp://www.nxp.com/documents/data_sheet/74HC_HCT4052.pdfthey perform much better.

author: ganzuul
author_rank: Contributor
timestamp: October 25, 2014, 07:30:25 pm
content: Quote from: doctormord on October 24, 2014, 12:45:03 pmO0USB 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...

author: psynapse
author_rank: Regular Contributor
timestamp: October 25, 2014, 11:45:15 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: October 26, 2014, 10:56:26 am
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 26, 2014, 12:16:19 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: October 26, 2014, 01:18:32 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 26, 2014, 11:37:23 pm
content: Quote from: doctormord on October 26, 2014, 01:18:32 pmMaybe 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 80MhzMy 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 29, 2014, 07:00:43 pm
content: 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:Analog Ch State Scale Position Coupling BW Limit InvertCH1 On 1.00V/ 40.0mV DC Off OffCH2 On 1.00V/ -2.04V DC Off OffAnalog Ch Impedance ProbeCH1 1M Ohm 10XCH2 1M Ohm 10XTime Time Ref Main Scale DelayMain Center 5.000ns/ -409.3000nsTrigger Source Slope Mode Coupling Level HoldoffEdge CH2 Rising Auto DC 1.12V 500nsAcquisition Sampling Memory Depth Sample RateNormal Realtime Normal 500.0MSa

author: ganzuul
author_rank: Contributor
timestamp: October 29, 2014, 07:16:36 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 31, 2014, 12:29:31 am
content: 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.

author: mmark
author_rank: Contributor
timestamp: October 31, 2014, 01:49:07 am
content: Quote from: psynapse on October 25, 2014, 12:01:19 amI 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

author: ganzuul
author_rank: Contributor
timestamp: October 31, 2014, 12:26:55 pm
content: Quote from: psynapse on October 31, 2014, 12:29:31 amThe 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. =)Quote from: mmark on October 31, 2014, 01:49:07 amStarting 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.

author: psynapse
author_rank: Regular Contributor
timestamp: October 31, 2014, 01:35:18 pm
content: 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 compileAre 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 currentAnd this is on a machine as real as you can get

author: ganzuul
author_rank: Contributor
timestamp: October 31, 2014, 04:50:46 pm
content: 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...

author: psynapse
author_rank: Regular Contributor
timestamp: October 31, 2014, 06:43:23 pm
content: 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 itwxASSERT_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 17warningsBTW, I do not know libusb, but note that the eeprom (for both the DDS120 and DDS140) store the following data in their first 8 bytes0 0xC21 Vendor ID (VID) L=47h2 Vendor ID (VID) H=05h3 Product ID (PID) L=31h4 Product ID (PID) H=21h5 Device ID (DID) L6 Device ID (DID) H7 Configuration byteTo 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?

author: donut6
author_rank: Contributor
timestamp: October 31, 2014, 07:26:13 pm
content: 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: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:this->Layout();glPane->SetCurrent(*m_context);edit: and add Show() and Raise() while we are at it:Code:this->Layout();this->Show();this->Raise();glPane->SetCurrent(*m_context);good luck!

author: psynapse
author_rank: Regular Contributor
timestamp: October 31, 2014, 10:48:55 pm
content: 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 8312A 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 donut6EDIT: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 lineif (w == 0x21) // fifo fullthe 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.

author: mmark
author_rank: Contributor
timestamp: November 01, 2014, 02:00:15 pm
content: 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

author: donut6
author_rank: Contributor
timestamp: November 01, 2014, 02:36:14 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: November 01, 2014, 02:43:29 pm
content: Hmm, maybe channel interleaving or differential input, there are actually 2 multiplexers free to use.)Good work guys!

author: psynapse
author_rank: Regular Contributor
timestamp: November 01, 2014, 05:21:33 pm
content: 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 case22DW case23DW case24DW case33DW case34DW case35DW case50DW case60DW case61DW case62DW case63DW case70DW case71DW case72DW case73DW case74DW case75DW case76DW case77DW case78DW case79DW case7ADW case7BDW case7CDW case7DDW case90DW case94DW caseD0DW caseD1Which 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)

author: ganzuul
author_rank: Contributor
timestamp: November 01, 2014, 09:23:39 pm
content: 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 ofhttp://www.altera.com/literature/an/an489.pdfone 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.

author: psynapse
author_rank: Regular Contributor
timestamp: November 01, 2014, 11:45:29 pm
content: 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 line0A40 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 NECESSARYThe same 6363 pattern exists in the DDS1200A20 3F 01 63 63 B8 01 01 01 07 02 00 00 01 00 00 002) 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 tableI 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

author: psynapse
author_rank: Regular Contributor
timestamp: November 02, 2014, 01:27:53 am
content: Donut6I 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?EDITI 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

author: donut6
author_rank: Contributor
timestamp: November 02, 2014, 08:12:10 pm
content: psynapse,QuoteThe 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, etcI 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.

author: psynapse
author_rank: Regular Contributor
timestamp: November 02, 2014, 10:41:36 pm
content: Donut6Thanks, 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 :-)

author: doctormord
author_rank: Regular Contributor
timestamp: November 03, 2014, 04:11:12 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: November 04, 2014, 11:06:30 am
content: 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!

author: mmark
author_rank: Contributor
timestamp: November 05, 2014, 01:15:09 am
content: 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

author: psynapse
author_rank: Regular Contributor
timestamp: November 05, 2014, 01:38:13 am
content: MMarkWell 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 bewareI 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.

author: mmark
author_rank: Contributor
timestamp: November 05, 2014, 02:13:32 am
content: 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...

author: doctormord
author_rank: Regular Contributor
timestamp: November 05, 2014, 09:13:57 am
content: Great work guys!^-^

author: psynapse
author_rank: Regular Contributor
timestamp: November 05, 2014, 10:58:36 am
content: 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 samplingDoctormord;I have looked at your photos of the DDS120 board, and as far as I can seeINT4INT5 is not connected anywhere ..... Please could you confirm that I am right .... My intention is to useINT4INT5 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)

author: doctormord
author_rank: Regular Contributor
timestamp: November 06, 2014, 12:12:49 pm
content: Confirmed.Regards,doc

author: sandos
author_rank: Contributor
timestamp: November 06, 2014, 01:34:04 pm
content: 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 seenhttps://github.com/rpm2003rpm/HT6022_Driverwhich 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.

author: doctormord
author_rank: Regular Contributor
timestamp: November 06, 2014, 03:28:53 pm
content: The 6022 got no AC-coupling.

author: doctormord
author_rank: Regular Contributor
timestamp: November 07, 2014, 01:40:55 pm
content: Quote from: psynapse on November 01, 2014, 05:21:33 pmSure, we need to double the ADC-frequency at first, i.e.:http://www.maximintegrated.com/en/app-notes/index.mvp/id/3327and 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.

author: psynapse
author_rank: Regular Contributor
timestamp: November 08, 2014, 01:28:48 am
content: 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 outputdata by 1/2 of a clock cycle. In other words, if two clocks are fedto the AD9288 and are 180° out of phase, enabling the dataalign allows Channel B output data to be available at the risingedge of Clock A. If the same Encode clock is provided to bothchannels and the data align pin is enabled, then output datafrom Channel B is 180° out of phase with respect to Channel A.If the same Encode clock is provided to both channels and thedata align pin is disabled, both outputs are delivered on thesame rising edge of the clock.Table 4. User-Selectable OptionsS1 S2 Option0 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 isdelayed a 1/2 clock cycle).Badly expressed, but seems to suggest that programming the S1 S2 pins might get us what we want

author: mozart5474
author_rank: Newbie
timestamp: November 08, 2014, 07:36:22 am
content: 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?

author: psynapse
author_rank: Regular Contributor
timestamp: November 08, 2014, 11:09:02 am
content: Mozart5474,Sadly I am not a windows expert, far from it. The generic answers are likely to be1) 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.

author: mmark
author_rank: Contributor
timestamp: November 09, 2014, 05:52:56 am
content: 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=sharingand here a dmg for those with a mac:https://drive.google.com/file/d/0B4k4TyIzvHKATW1rb1VpOXVpbzQ/view?usp=sharingTo 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:#add SainSmart DDS120 and DDS140 to group plugdev#DDS120SUBSYSTEM=="usb", ATTR{idVendor}=="8102", ATTR{idProduct}=="8102", GROUP="plugdev"#DDS140SUBSYSTEM=="usb", ATTR{idVendor}=="8312", ATTR{idProduct}=="8312", GROUP="plugdev"and make sure that your user is member of the plugdev group.

author: jimon
author_rank: Regular Contributor
timestamp: November 09, 2014, 01:20:06 pm
content: 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 programhttp://pastebin.com/HH1sscZNand fuses are set to 7A FF

author: doctormord
author_rank: Regular Contributor
timestamp: November 09, 2014, 01:36:24 pm
content: 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)

author: Guizmo
author_rank: Newbie
timestamp: November 09, 2014, 11:48:57 pm
content: 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,cyaI

author: ganzuul
author_rank: Contributor
timestamp: November 10, 2014, 01:40:19 am
content: Quote from: mmark on November 09, 2014, 05:52:56 amYou 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.

author: doctormord
author_rank: Regular Contributor
timestamp: November 10, 2014, 05:35:13 am
content: Any chance to run this under windows?

author: ganzuul
author_rank: Contributor
timestamp: November 10, 2014, 08:48:13 am
content: I think so. QtCreator only complains about libusb1.0 and fftw3 being missing. I'll see if I can figure out this Win32 stuff.

author: doctormord
author_rank: Regular Contributor
timestamp: November 10, 2014, 01:06:10 pm
content: Thanks in advance.

author: ganzuul
author_rank: Contributor
timestamp: November 10, 2014, 06:55:27 pm
content: 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.htmlI was testing with a 'libusbx' version, which actually appears to be deprecated in favor ofhttp://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")# ConfigurationCONFIG += warn_on \qtQT += opengl printsupportLIBS += -LC:/Qt/lib/libusbx/MS32/static/libusb-1.0.lib -llibusbxINCLUDEPATH += C:/Qt/lib/libusbx/include/libusbxDEPENDPATH += C:/Qt/lib/libusbx/include/libusbxLIBS += -LC:/Qt/lib/fftw-3.3.4-dll64/libfftw3-3.lib -lfftw3INCLUDEPATH += C:\Qt\lib\fftw-3.3.4-dll64DEPENDPATH += C:\Qt\lib\fftw-3.3.4-dll64Adding 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

author: mmark
author_rank: Contributor
timestamp: November 11, 2014, 03:54:55 am
content: Quote from: ganzuul on November 10, 2014, 01:40:19 amThanks, 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

author: doctormord
author_rank: Regular Contributor
timestamp: November 11, 2014, 06:44:14 am
content: 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,docEdit: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.

author: mmark
author_rank: Contributor
timestamp: November 11, 2014, 07:57:10 am
content: Quote from: doctormord on November 11, 2014, 06:44:14 amHmm, 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)?

author: doctormord
author_rank: Regular Contributor
timestamp: November 11, 2014, 08:28:33 am
content: +-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)

author: jimon
author_rank: Regular Contributor
timestamp: November 11, 2014, 08:56:58 am
content: @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 athttp://www.amazon.com/SainSmart-Portable-Handheld-Oscilloscope-Bandwidth/dp/B00FYGEFYMYou can see there at a bottom :Quote

author: doctormord
author_rank: Regular Contributor
timestamp: November 11, 2014, 09:00:43 am
content: Thanks.Edit:Seems to be the same as "standard" SainSmart version.

author: psynapse
author_rank: Regular Contributor
timestamp: November 11, 2014, 03:08:52 pm
content: 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)

author: psynapse
author_rank: Regular Contributor
timestamp: November 11, 2014, 04:07:33 pm
content: mmarkmmark, 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 8051Have 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=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?

author: donut6
author_rank: Contributor
timestamp: November 11, 2014, 06:38:49 pm
content: psynapse,QuoteI 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.

author: psynapse
author_rank: Regular Contributor
timestamp: November 11, 2014, 11:14:03 pm
content: 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

author: psynapse
author_rank: Regular Contributor
timestamp: November 12, 2014, 12:29:55 am
content: 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 resultEDIT: Blast! I have also seen 3072, more and more like and endpoint buffer issue

author: doctormord
author_rank: Regular Contributor
timestamp: November 12, 2014, 08:22:32 am
content: 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, buggyThe software, buggyThe 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.ChristianEdit:@psynapseI can't extract your scope2.zip (Windows & Linux)

author: jimon
author_rank: Regular Contributor
timestamp: November 12, 2014, 08:59:03 am
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: November 12, 2014, 09:48:55 am
content: Let's go! O0

author: ganzuul
author_rank: Contributor
timestamp: November 12, 2014, 07:26:42 pm
content: \/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/downloadSee 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.zipuser: eevblogpass: eevblogCRC32: EE3DAF51MD5: 6D5F867C992EF571A0824202BC863221SHA-1: 09FF567F9936E4A820EB5C267B81064BECB31CFE

author: doctormord
author_rank: Regular Contributor
timestamp: November 12, 2014, 08:30:17 pm
content: 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.

author: ganzuul
author_rank: Contributor
timestamp: November 12, 2014, 09:02:40 pm
content: 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

author: psynapse
author_rank: Regular Contributor
timestamp: November 12, 2014, 10:08:22 pm
content: DoctormordThat 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!GanzuulGood work ... Is it possible to share the QT5 source, so that we can give it a go under linux.AllEven 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 simplecase65: ; this command (65) tampers with the continuous mode timebase. The sample time is (1+1+param+param)/48Mhzmov DPTR, #SETUPDAT2 ;get pointer to the single input parameter, which is the second byte of the USB messagemovx A, @DPTR ;get the input parameter itself. We should check its validity here, zero would be BADmov DPTR, #021ECh ; A pointer to within the (RAM copy) alternate waveform tablemovx @DPTR,A ; store the number of cycles for T1 in the GPIF waveforminc DPTRmovx @DPTR,A ; store the number of cycles for T2 in the GPIF waveformlcall reload ; reload the wave tablesljmp send_ack

author: doctormord
author_rank: Regular Contributor
timestamp: November 13, 2014, 01:46:01 am
content: Quote from: psynapse on November 12, 2014, 10:08:22 pmWell, 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@ganzuulThanks!

author: mmark
author_rank: Contributor
timestamp: November 13, 2014, 01:58:37 am
content: Quote from: doctormord on November 13, 2014, 01:46:01 amFWIW: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: November 13, 2014, 02:15:36 am
content: @ganzuul,i actually get this, when starting the app.Possible solution:http://qt-project.org/forums/viewthread/22908Edit:I'm on Win7 32bit.

author: ganzuul
author_rank: Contributor
timestamp: November 13, 2014, 02:40:27 am
content: 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.zipuser: eevblogpass: eevblogCRC32: EE3DAF51MD5: 6D5F867C992EF571A0824202BC863221SHA-1: 09FF567F9936E4A820EB5C267B81064BECB31CFEServer 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

author: doctormord
author_rank: Regular Contributor
timestamp: November 13, 2014, 03:24:30 am
content: 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..

author: psynapse
author_rank: Regular Contributor
timestamp: November 13, 2014, 12:55:18 pm
content: DoctormordI 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?

author: doctormord
author_rank: Regular Contributor
timestamp: November 13, 2014, 07:06:19 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: November 14, 2014, 01:02:08 am
content: 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 datasheetFor 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

author: doctormord
author_rank: Regular Contributor
timestamp: November 14, 2014, 08:42:05 am
content: Now i see, was a bit confused because of the alignment.

author: mmark
author_rank: Contributor
timestamp: November 14, 2014, 06:58:14 pm
content: Psynapse,it might be silly, but from looking at the image Jimon postedearlier, 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

author: doctormord
author_rank: Regular Contributor
timestamp: November 14, 2014, 07:03:34 pm
content: Can't be, because both Channels get the same clock and data align is disabled by hardware.

author: ganzuul
author_rank: Contributor
timestamp: November 14, 2014, 09:09:13 pm
content: Quote from: psynapse on November 13, 2014, 12:55:18 pmThat 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.

author: jimon
author_rank: Regular Contributor
timestamp: November 14, 2014, 09:27:54 pm
content: @ganzuulI don't have any generators here that I can use for calibration, so probably will skip screwing around inside of scope

author: ganzuul
author_rank: Contributor
timestamp: November 14, 2014, 10:28:54 pm
content: 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!

author: doctormord
author_rank: Regular Contributor
timestamp: November 15, 2014, 05:59:38 pm
content: My approach of a classic generator is shown here:http://www.diyaudio.com/forums/showthread.php?t=261604

author: psynapse
author_rank: Regular Contributor
timestamp: November 16, 2014, 12:27:02 am
content: 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 endhereandhere. 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.EDITIn 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.

author: doctormord
author_rank: Regular Contributor
timestamp: November 18, 2014, 09:24:26 pm
content: 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 = badMultiplexer -> Resistor = goodIt 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:FODM8071SFH6701/11You 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.

author: psynapse
author_rank: Regular Contributor
timestamp: November 19, 2014, 11:06:48 pm
content: 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 + 5vC2 PE 1 (clk)C3 PE 0? with RCC4 PE 3C5 PE 5C6 CLKOUT via 300 ohms 48MhzC7 -gndC8 - +3v3C9 -DataB 7C10 -DataB 6C11 -dataB 5C12 -dataB 4C13 -dataB 3C14 -dataB 2C15 -dataB 1C16 -dataB 0Bn no pinsA1 -GndA2 -GndA3 -A4 -A5 PE 2A6 -gndA7 -A8 -gndA9 -A10 -A11 -A12 PE 4A13 -A14 -A15 - gndA16 - gndPE3,PE4 and PE5 seem to function as an I2C interface for controlling the waveform generator.

author: doctormord
author_rank: Regular Contributor
timestamp: November 22, 2014, 05:58:19 pm
content: Regarding:http://www.cypress.com/?docID=48811Page 221IFCLK 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

author: psynapse
author_rank: Regular Contributor
timestamp: November 22, 2014, 06:58:53 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: November 22, 2014, 08:14:18 pm
content: Nice!Isn't pretrigger "just" a thing of implementing software "prebuffer"?(Like on cameras)

author: psynapse
author_rank: Regular Contributor
timestamp: November 23, 2014, 01:46:05 am
content: 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 firmwareBut 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?

author: CatWhisker
author_rank: Contributor
timestamp: November 24, 2014, 12:07:49 am
content: Psynapse,Stumbled on this yesterday, I'll definitely be interested.What 'scope software are you targetting? Or going a-fresh?

author: doctormord
author_rank: Regular Contributor
timestamp: November 24, 2014, 02:51:34 pm
content: 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.

author: psynapse
author_rank: Regular Contributor
timestamp: November 24, 2014, 08:42:23 pm
content: DoctormordYes, 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.CatWhiskerWhat 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.

author: doctormord
author_rank: Regular Contributor
timestamp: November 25, 2014, 09:20:27 am
content: 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

author: psynapse
author_rank: Regular Contributor
timestamp: November 27, 2014, 01:29:39 am
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: November 30, 2014, 02:20:30 pm
content: 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.

author: bobi_dunkel
author_rank: Newbie
timestamp: December 04, 2014, 12:04:56 pm
content: Hi everybody.I have stumbled on this thread in May, only a few posts. 5 days ago went through my favoritesand 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.

author: psynapse
author_rank: Regular Contributor
timestamp: December 04, 2014, 01:20:56 pm
content: It's a whole week since I said something .... not like meAs 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 limitations1) 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 time2) you get no trace whilst recording3) 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 itbobi_dunkelTwo 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

author: doctormord
author_rank: Regular Contributor
timestamp: December 04, 2014, 06:30:53 pm
content: Ledioskope is within this thread.

author: psynapse
author_rank: Regular Contributor
timestamp: December 05, 2014, 01:41:59 am
content: 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.

author: bobi_dunkel
author_rank: Newbie
timestamp: December 05, 2014, 08:43:59 am
content: Quote from: psynapse on December 05, 2014, 01:41:59 amNo 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.

author: mmark
author_rank: Contributor
timestamp: December 08, 2014, 04:39:15 am
content: Quote from: bobi_dunkel on December 04, 2014, 12:04:56 pmBobi,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

author: bobi_dunkel
author_rank: Newbie
timestamp: December 09, 2014, 01:10:13 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: December 12, 2014, 03:18:07 pm
content: @psynapse,RichardK released the sources of his open6022BE project:https://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/msg566881/#msg566881https://jumpshare.com/v/bviO41a4x8CiAaSSbamaYou may have a look at it.A binary to play with is available here, it features a demo mode.https://jumpshare.com/v/q1Spmyw0dk7BmnRd77tkRegards,Christian

author: psynapse
author_rank: Regular Contributor
timestamp: December 14, 2014, 11:14:09 am
content: 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

author: MengPeng
author_rank: Contributor
timestamp: December 19, 2014, 12:58:39 am
content: 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!

author: bobi_dunkel
author_rank: Newbie
timestamp: December 19, 2014, 07:38:25 pm
content: 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.

author: MengPeng
author_rank: Contributor
timestamp: December 19, 2014, 10:08:48 pm
content: 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

author: MengPeng
author_rank: Contributor
timestamp: December 20, 2014, 04:53:08 am
content: 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...

author: bobi_dunkel
author_rank: Newbie
timestamp: December 20, 2014, 08:04:00 pm
content: 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 Usbdeviewhttp://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.

author: MengPeng
author_rank: Contributor
timestamp: December 21, 2014, 09:44:13 pm
content: 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

author: MengPeng
author_rank: Contributor
timestamp: December 21, 2014, 09:47:08 pm
content: I forgot to mention that USBDeviewer says my DDS120's device name is "USB102" in case that's important.

author: doctormord
author_rank: Regular Contributor
timestamp: December 21, 2014, 10:15:18 pm
content: USB102 is right.

author: MengPeng
author_rank: Contributor
timestamp: December 21, 2014, 11:09:51 pm
content: 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!

author: doctormord
author_rank: Regular Contributor
timestamp: December 22, 2014, 12:07:06 am
content: 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

author: MengPeng
author_rank: Contributor
timestamp: December 22, 2014, 03:17:04 am
content: 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!

author: doctormord
author_rank: Regular Contributor
timestamp: December 22, 2014, 04:53:48 am
content: "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

author: MengPeng
author_rank: Contributor
timestamp: December 22, 2014, 06:03:26 am
content: 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.

author: MengPeng
author_rank: Contributor
timestamp: December 22, 2014, 06:10:23 am
content: PS Doctormord - tried to go to your websitewww.360custom.de, got a "not available" message from my chrome browser... I'd like to support the people that help me.

author: bobi_dunkel
author_rank: Newbie
timestamp: December 22, 2014, 07:52:05 am
content: Hi Cam,Great , glad you sorted it outBest regards,bobi

author: doctormord
author_rank: Regular Contributor
timestamp: December 22, 2014, 12:14:37 pm
content: Quote from: MengPeng on December 22, 2014, 06:10:23 amGlad that it works now. 360customs is up and running.Edit:seems like my signature is "fuck*d" up..www.360customs.de<--

author: MengPeng
author_rank: Contributor
timestamp: December 22, 2014, 04:25:21 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: December 22, 2014, 10:29:31 pm
content: 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.

author: MengPeng
author_rank: Contributor
timestamp: December 23, 2014, 12:19:45 am
content: Ok, thanks for the reply! Obviously I've got some learning to do!

author: nitetrip
author_rank: Newbie
timestamp: December 27, 2014, 01:25:47 am
content: 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.

author: MengPeng
author_rank: Contributor
timestamp: December 27, 2014, 06:16:03 am
content: 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.

author: crystal
author_rank: Contributor
timestamp: December 28, 2014, 12:47:05 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: December 28, 2014, 04:19:13 pm
content: They're supposed to be the same.

author: torr032
author_rank: Regular Contributor
timestamp: December 28, 2014, 11:32:26 pm
content: Quote from: doctormord on December 28, 2014, 04:19:13 pmSo which one is the newer version?

author: doctormord
author_rank: Regular Contributor
timestamp: December 29, 2014, 12:48:26 am
content: The same is the same, so no "newer version".

author: crystal
author_rank: Contributor
timestamp: December 29, 2014, 08:45:00 pm
content: If they are the same then why do they have two different stickers on the cover?

author: doctormord
author_rank: Regular Contributor
timestamp: December 30, 2014, 05:50:32 pm
content: Why does car companies sell cars in different colors? (Same specs, different colors)

author: nitetrip
author_rank: Newbie
timestamp: December 31, 2014, 08:33:16 pm
content: 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.

author: i4004
author_rank: Regular Contributor
timestamp: January 07, 2015, 11:46:02 pm
content: 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 videoie 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 rigolhttps://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.

author: CAlan
author_rank: Newbie
timestamp: January 25, 2015, 09:14:13 pm
content: 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?

author: doctormord
author_rank: Regular Contributor
timestamp: January 26, 2015, 03:22:17 am
content: Do you have GFX-acceleration enabled on Parallels? You're right, all the readings are done software. The scope only sends raw ADC data.

author: CAlan
author_rank: Newbie
timestamp: January 26, 2015, 08:01:22 pm
content: Quote from: doctormord on January 26, 2015, 03:22:17 amive tried it with both directx enabled and disabled. It makes no difference.

author: doctormord
author_rank: Regular Contributor
timestamp: January 27, 2015, 12:32:17 am
content: I will try to reproduce this in my setup. (OSX + Parallels Win7)

author: CAlan
author_rank: Newbie
timestamp: January 27, 2015, 02:56:10 am
content: 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.

author: PapaLukas
author_rank: Newbie
timestamp: January 27, 2015, 10:00:01 pm
content: Hi guys! And among those specificallydoctormord,psynapse,ganzuulanddonut6!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 herehttps://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 usefulUsage 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 successRegards!

author: rvendrame
author_rank: Newbie
timestamp: January 30, 2015, 07:01:49 pm
content: 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

author: mmark
author_rank: Contributor
timestamp: January 31, 2015, 11:08:15 pm
content: R61 seems to be 0 Ohm:https://dl.dropboxusercontent.com/u/5641160/DDS120_Top_20141023_0146p.jpg(posted somewhere before)

author: rvendrame
author_rank: Newbie
timestamp: February 01, 2015, 11:49:53 pm
content: Quote from: mmark on January 31, 2015, 11:08:15 pm@mmark, thanks, will give it a try...

author: DAIRVINE
author_rank: Contributor
timestamp: February 04, 2015, 09:16:08 am
content: 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.

author: DAIRVINE
author_rank: Contributor
timestamp: February 04, 2015, 09:20:45 am
content: 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.

author: rvendrame
author_rank: Newbie
timestamp: February 18, 2015, 04:27:03 pm
content: Quote from: mmark on January 31, 2015, 11:08:15 pmStill 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...

author: doctormord
author_rank: Regular Contributor
timestamp: February 18, 2015, 06:10:29 pm
content: May you check the current drawn from USB?

author: bobi_dunkel
author_rank: Newbie
timestamp: February 19, 2015, 12:39:34 am
content: Quote from: DAIRVINE on February 04, 2015, 09:16:08 amIs Picoscope also variant of Cypress FX2 board ?

author: bobi_dunkel
author_rank: Newbie
timestamp: February 23, 2015, 02:55:57 pm
content: Quote from: bobi_dunkel on February 19, 2015, 12:39:34 amYes some models are:http://sigrok.org/wiki/Oscilloscope_comparison

author: doctormord
author_rank: Regular Contributor
timestamp: February 23, 2015, 04:24:36 pm
content: Quote from: PapaLukas on January 27, 2015, 10:00:01 pmGreat work,would you mind to implement support for the DDS120?Quote from: bobi_dunkel on February 23, 2015, 02:55:57 pmWell, they aren't as they just use the FX2LP interface but rely on custom FPGA implementations.

author: venoft
author_rank: Newbie
timestamp: March 21, 2015, 04:06:38 pm
content: 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

author: jbar
author_rank: Newbie
timestamp: March 23, 2015, 05:21:38 am
content: 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.

author: freefall322
author_rank: Newbie
timestamp: September 05, 2015, 11:29:06 pm
content: 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.htmlpeople 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 projectsthat have appeared in this thread?

author: consequential
author_rank: Newbie
timestamp: September 14, 2015, 08:28:25 pm
content: 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 installThanks

author: elecblues
author_rank: Newbie
timestamp: October 08, 2015, 06:11:25 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: October 31, 2015, 10:30:58 pm
content: Cool story mate. Will look into this.

author: doctormord
author_rank: Regular Contributor
timestamp: November 02, 2015, 05:25:25 am
content: 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 stuffWorks good for me.1.2.0Link1.2.1Linkdds120

author: jdev99
author_rank: Regular Contributor
timestamp: November 30, 2015, 09:05:02 pm
content: 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 ?

author: Gyro
author_rank: Super Contributor
timestamp: November 30, 2015, 09:23:37 pm
content: IFyou'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.m1684Here's the teardown thread:https://www.eevblog.com/forum/testgear/owon-vds1022i-quick-teardown-%28versus-the-hantek-6022be%29/

author: jdev99
author_rank: Regular Contributor
timestamp: December 01, 2015, 10:25:59 am
content: 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.

author: Gyro
author_rank: Super Contributor
timestamp: December 01, 2015, 12:44:44 pm
content: If you hurry. Santa may smile on you!

author: doctormord
author_rank: Regular Contributor
timestamp: December 01, 2015, 04:40:58 pm
content: Is the software any better?

author: Gyro
author_rank: Super Contributor
timestamp: December 01, 2015, 05:46:33 pm
content: 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.

author: bianchifan
author_rank: Regular Contributor
timestamp: December 03, 2015, 05:05:22 pm
content: Quote from: doctormord on November 02, 2015, 05:25:25 amLink is dead

author: doctormord
author_rank: Regular Contributor
timestamp: December 04, 2015, 11:49:04 pm
content: 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.rarhttp://www99.zippyshare.com/v/p14YpYdf/file.htmlpw? dds120

author: lmorgan3d
author_rank: Newbie
timestamp: December 08, 2015, 08:04:09 pm
content: 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..

author: doctormord
author_rank: Regular Contributor
timestamp: December 09, 2015, 08:01:44 pm
content: 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

author: zp1956
author_rank: Newbie
timestamp: December 09, 2015, 08:34:11 pm
content: doctormordyour 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!

author: lmorgan3d
author_rank: Newbie
timestamp: December 12, 2015, 01:45:13 pm
content: 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..

author: aviador
author_rank: Newbie
timestamp: December 14, 2015, 06:59:09 pm
content: I can not have working version 1.3.1 in Windows 7, byt no problem with version 1.2.0Can you please put a link to version 1.3.0Thanks

author: bianchifan
author_rank: Regular Contributor
timestamp: December 15, 2015, 07:00:57 am
content: Quote from: doctormord on December 04, 2015, 11:49:04 pmMuchas graciasQuote from: doctormord on December 04, 2015, 11:49:04 pmUnfortunately it doesn't workSplash appears on startup, 2secs later it crashes, Win7x64

author: doctormord
author_rank: Regular Contributor
timestamp: December 16, 2015, 08:09:11 pm
content: Version 1.3.0 is here:http://m5.img.dxcdn.com/CDDriver/CD/sku.271544.rarDid tested the 1.3.1 only on Win7 32bit, no 64bit avail here to test.Quote from: zp1956 on December 09, 2015, 08:34:11 pmTry .net Reflector 8.5, this seemed to give better code quality - but there's still code to fix afterwards.

author: zp1956
author_rank: Newbie
timestamp: December 17, 2015, 01:59:23 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: December 17, 2015, 04:29:04 pm
content: Maybe the recompiled version on a 64bit machine will do. Let me know about your progress.

author: doctormord
author_rank: Regular Contributor
timestamp: January 02, 2016, 02:33:23 pm
content: Any progress?

author: zp1956
author_rank: Newbie
timestamp: January 05, 2016, 08:53:15 am
content: Unfortunately, not yetI 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.

author: doctormord
author_rank: Regular Contributor
timestamp: January 07, 2016, 03:39:55 pm
content: Someone may try:http://www14.zippyshare.com/v/g5cFy1de/file.htmlStraight x86 compilation.pw: dds120

author: bianchifan
author_rank: Regular Contributor
timestamp: January 07, 2016, 05:32:51 pm
content: 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..

author: antrrax
author_rank: Newbie
timestamp: January 07, 2016, 06:07:12 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: January 08, 2016, 03:37:34 pm
content: Quote from: bianchifan on January 07, 2016, 05:32:51 pmOkay.Quote from: antrrax on January 07, 2016, 06:07:12 pmThe 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.

author: antrrax
author_rank: Newbie
timestamp: January 08, 2016, 06:27:28 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: January 09, 2016, 02:24:27 pm
content: This hw-trigger is for the DDS140, which is != DDS120.

author: bianchifan
author_rank: Regular Contributor
timestamp: February 05, 2016, 12:33:38 pm
content: Quote from: bianchifan on January 07, 2016, 05:32:51 pmAfter 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.Quote from: mmark on November 09, 2014, 05:52:56 amAll 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?

author: doctormord
author_rank: Regular Contributor
timestamp: February 05, 2016, 01:01:13 pm
content: 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

author: bianchifan
author_rank: Regular Contributor
timestamp: February 09, 2016, 04:15:46 pm
content: At the moment I'm a little disappointed..Ok, 16MHZ can be displayed, but the device/AD is quite noisy, no stable curves, triggringTest 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

author: doctormord
author_rank: Regular Contributor
timestamp: February 09, 2016, 07:23:33 pm
content: Are you complaining about the Channel 2 reading? I would suggest to switch this channel on first - it's actually off at both screenshots.

author: bianchifan
author_rank: Regular Contributor
timestamp: February 10, 2016, 11:59:20 am
content: Quote from: doctormord on February 09, 2016, 07:23:33 pm?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 circuitEDIT:Forgotten..CH1 triggers when time base is less/equal 0.1 msCH2 triggers never, no wayWhen stopped (triger ext.) it displays a much better waveform, only slightly rounded.

author: doctormord
author_rank: Regular Contributor
timestamp: February 10, 2016, 09:31:02 pm
content: 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.

author: bianchifan
author_rank: Regular Contributor
timestamp: February 14, 2016, 04:35:47 pm
content: Quote from: doctormord on February 10, 2016, 09:31:02 pmQuote from: bianchifan on February 09, 2016, 04:15:46 pmQuote from: doctormord on February 10, 2016, 09:31:02 pmSurely, 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 areaChanging 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 screenWith these curves I wouldn't complain

author: doctormord
author_rank: Regular Contributor
timestamp: February 14, 2016, 06:56:10 pm
content: I would return it, this device is pretty much out of spec.Thanks for the upload.

author: zp1956
author_rank: Newbie
timestamp: February 17, 2016, 10:14:14 am
content: Finally! I have my own source code working!@doctormordUsing 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).

author: doctormord
author_rank: Regular Contributor
timestamp: February 17, 2016, 11:29:21 am
content: Nice, haven't thought it will work with SharpDevelope.

author: bianchifan
author_rank: Regular Contributor
timestamp: February 17, 2016, 11:35:33 am
content: Quote from: doctormord on February 14, 2016, 06:56:10 pmMaybe, but at least I couldn't resist and opened it and took some pics.Front PCBBacksideBad soldering, looks manually

author: doctormord
author_rank: Regular Contributor
timestamp: February 17, 2016, 11:44:46 am
content: Hmm, no AD adc anymore, but a chinese "pin compatible" MXT2088.

author: bianchifan
author_rank: Regular Contributor
timestamp: February 17, 2016, 12:08:59 pm
content: Quote from: doctormord on February 17, 2016, 11:44:46 amThe 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.

author: doctormord
author_rank: Regular Contributor
timestamp: February 17, 2016, 12:26:04 pm
content: 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.

author: bianchifan
author_rank: Regular Contributor
timestamp: February 17, 2016, 04:03:54 pm
content: Quote from: doctormord on February 17, 2016, 12:26:04 pmI 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 asThe Newest Version1. 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 shifts4. 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.

author: doctormord
author_rank: Regular Contributor
timestamp: February 17, 2016, 04:37:29 pm
content: 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.

author: coromonadalix
author_rank: Super Contributor
timestamp: February 18, 2016, 03:22:41 am
content: @bianchifanDid you check for probe calibration compensation, a small adjustable capacitor in the base bnc connector of the probeI had this problem before, badly calibrated probes were messing measurements, and had poor results in voltages.

author: bianchifan
author_rank: Regular Contributor
timestamp: March 11, 2016, 06:32:21 pm
content: Quote from: doctormord on February 14, 2016, 06:56:10 pmOK, at least I did so.NO answer from Amazon, nothing...but wait.. since 2 days they are offering a warehouse DDS140Meanwhile I checked my new DDS140 and this device seems ok.Quote from: ganzuul on May 20, 2014, 04:29:20 pmIMHO 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.

author: doctormord
author_rank: Regular Contributor
timestamp: March 12, 2016, 02:48:46 pm
content: Quote from: bianchifan on February 14, 2016, 04:35:47 pmNot working anymore.

author: bianchifan
author_rank: Regular Contributor
timestamp: March 14, 2016, 08:48:04 am
content: Quote from: doctormord on March 12, 2016, 02:48:46 pmIt 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 nonsenseFeeded with Voltageges about 6V or more will cause the scope to strike.A red line will be displayed combined with loud beeping.

author: merbanan
author_rank: Contributor
timestamp: March 15, 2016, 01:26:14 pm
content: @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.

author: doctormord
author_rank: Regular Contributor
timestamp: March 15, 2016, 02:10:26 pm
content: @merbanan,You have my permission.Just link back to "360customs.de".Regards.

author: merbanan
author_rank: Contributor
timestamp: March 15, 2016, 09:13:41 pm
content: Ok, I have now added:http://sigrok.org/wiki/SainSmart_DDS120For the record here is the Hantek 6022BL sigrok driver:http://sigrok.org/gitweb/?p=libsigrok.git;a=tree;f=src/hardware/hantek-6xxx;hb=f2a66a8ee669df5afa1b7bdade6e25ac0857fe4bAnd then the more interesting part the firmware:http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=commitdiff;h=189db3d41e4c3d8a4aec5ec605c03df75577d531So 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 ?

author: doctormord
author_rank: Regular Contributor
timestamp: March 15, 2016, 10:10:41 pm
content: If i remember correctly and from the pictures:PE3 = Channel A AC/DC via Photomos; enabled Photomos bridges AC input capPE0 = Channel B AC/DC via Photomos; enabled Photomos bridges AC input capPC1= enables Channel A compensation NetworkPE1= enables Channel B compensation NetworkI'm not sure if it is always enabled when doing AC coupling.PC2 + PC3 = selects Channel B gainPC4 + PC5 = selects Channel B gainPB7-PB0 = Channel A 8bit input D7(MSB)-D0:PD7-PD0 = Channel B 8bit input D7(MSB)-D0:

author: merbanan
author_rank: Contributor
timestamp: March 15, 2016, 10:22:34 pm
content: Quote from: doctormord on March 15, 2016, 10:10:41 pmWhat 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 ?

author: doctormord
author_rank: Regular Contributor
timestamp: March 15, 2016, 10:32:28 pm
content: 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/#msg535341It'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 = -20dBPE1: 0 = -6dB; 1 = -20dBQuoteSorry, typo, it is:PC2 + PC3 = selects Channel A gainPC4 + PC5 = selects Channel B gain

author: doctormord
author_rank: Regular Contributor
timestamp: March 15, 2016, 10:59:08 pm
content: 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/#msg535995with the internal switch resistance, its going like this by combination of bits.QuoteSo to sum this up:#Channel A:PC1=1; PC2=0; PC3= 0 -> Gain x0.1 = -20dBPC1=1; PC2=0; PC3= 1 -> Gain x0.2 = -14dBPC1=1; PC2=1; PC3= 0 -> Gain x0.4 = -8dBPC1=0; PC2=0; PC3= 0 -> Gain x0.5 = -6dBPC1=0; PC2=0; PC3= 1 -> Gain x1 = 0dBPC1=0; PC2=1; PC3= 0 -> Gain x2 = +6dB#Channel B:PE1=1; PC4=0; PC5= 0 -> Gain x0.1 = -20dBPE1=1; PC4=0; PC5= 1 -> Gain x0.2 = -14dBPE1=1; PC4=1; PC5= 0 -> Gain x0.4 = -8dBPE1=0; PC4=0; PC5= 0 -> Gain x0.5 = -6dBPE1=0; PC4=0; PC5= 1 -> Gain x1 = 0dBPE1=0; PC4=1; PC5= 0 -> Gain x2 = +6dB

author: merbanan
author_rank: Contributor
timestamp: March 15, 2016, 11:15:12 pm
content: This is the function I need to re-implement for the SainSmarthttp://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=blob;f=hantek_6022be.c;h=8a73cc07b4ac74828f5303e1f1b7861dd1149cca;hb=189db3d41e4c3d8a4aec5ec605c03df75577d531#l190With 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.

author: doctormord
author_rank: Regular Contributor
timestamp: March 15, 2016, 11:25:15 pm
content: I wonder if clock setting is working, as the DDS120 is using the IFCLK output:Quote

author: doctormord
author_rank: Regular Contributor
timestamp: March 15, 2016, 11:29:59 pm
content: Quote from: bianchifan on March 14, 2016, 08:48:04 amNeeds the mega decryption key.

author: merbanan
author_rank: Contributor
timestamp: March 16, 2016, 10:00:54 am
content: Quote from: doctormord on March 15, 2016, 11:25:15 pmI just assumed it used the same as the Hantek.Tracing the pin onhttp://sigrok.org/wimg/d/d8/Hantek_6022be_pcb_top.jpgandhttp://sigrok.org/wimg/0/05/Hantek_6022be_pcb_bottom.jpgit 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).

author: bianchifan
author_rank: Regular Contributor
timestamp: March 16, 2016, 01:39:20 pm
content: Quote from: doctormord on March 15, 2016, 11:29:59 pm2nd 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 jobQuote from: merbanan on March 15, 2016, 09:13:41 pmPlease don't forget DDS140Until 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.

author: merbanan
author_rank: Contributor
timestamp: March 16, 2016, 03:25:48 pm
content: Quote from: bianchifan on March 16, 2016, 01:39:20 pmWell 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.

author: merbanan
author_rank: Contributor
timestamp: March 19, 2016, 01:58:29 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: March 19, 2016, 04:14:54 pm
content: 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?

author: bianchifan
author_rank: Regular Contributor
timestamp: March 19, 2016, 04:27:33 pm
content: Another try, anonymous on filehorst.de(germen), checked twice from different requestersDDS140.7z

author: merbanan
author_rank: Contributor
timestamp: March 22, 2016, 03:20:42 pm
content: Quote from: doctormord on March 19, 2016, 04:14:54 pmYeah 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.

author: doctormord
author_rank: Regular Contributor
timestamp: March 24, 2016, 07:17:42 pm
content: Alright, the commands/functions can be seen from their .dll.AiReadBulkDataAutoMeasurementBufferInitDataPreDisposalDeviceCloseDeviceOpenEventCheckGetBuffer4ReadGetBuffer4WrGetDataGetHWbufferSizeGetInfoByteGetInfodoubleGetRawData4ReadSetDataSetInfoSetReadEnableOrNotSetStableEnableOrNotSetTrigInfoTrigDataPrepareUSBCtrlTransUSBCtrlTransSimple

author: merbanan
author_rank: Contributor
timestamp: March 26, 2016, 03:02:46 am
content: 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 ?

author: doctormord
author_rank: Regular Contributor
timestamp: March 26, 2016, 11:41:07 am
content: 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)

author: merbanan
author_rank: Contributor
timestamp: March 26, 2016, 04:44:35 pm
content: Quote from: doctormord on March 26, 2016, 11:41:07 amhttp://sigrok.org/wiki/SainSmart_DDS120has 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.

author: doctormord
author_rank: Regular Contributor
timestamp: March 26, 2016, 05:00:34 pm
content: Nice, keep it up.

author: merbanan
author_rank: Contributor
timestamp: March 26, 2016, 05:09:22 pm
content: I took a picture of a 1kHz triangle wave. And it is easy to see here that I am missing every other buffer.

author: doctormord
author_rank: Regular Contributor
timestamp: March 26, 2016, 05:50:24 pm
content: 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.

author: merbanan
author_rank: Contributor
timestamp: March 27, 2016, 09:25:04 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: March 28, 2016, 12:06:59 am
content: 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.

author: merbanan
author_rank: Contributor
timestamp: March 28, 2016, 12:52:46 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: March 28, 2016, 01:03:24 pm
content: Nice, please check your private messages.

author: andrej
author_rank: Newbie
timestamp: March 28, 2016, 07:56:58 pm
content: 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 ebayhttp://www.ebay.com/itm/SainSmart-Hardware-Trigger-Module-for-DDS-140-Oscilloscope-/301789209154?hash=item464409e242:g:ILgAAOSwd0BVp1ygDoes 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

author: bianchifan
author_rank: Regular Contributor
timestamp: March 29, 2016, 12:20:19 pm
content: Quote from: andrej on March 28, 2016, 07:56:58 pmA couple of months ago I thought exactly the same directionSome 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.

author: merbanan
author_rank: Contributor
timestamp: April 01, 2016, 10:10:40 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: April 01, 2016, 11:58:15 pm
content: Great news mate! How can the coupling problem be fixed, so what's needed?

author: merbanan
author_rank: Contributor
timestamp: April 02, 2016, 11:38:29 am
content: Quote from: doctormord on April 01, 2016, 11:58:15 pmJust 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 ?

author: doctormord
author_rank: Regular Contributor
timestamp: April 02, 2016, 11:53:36 am
content: 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?

author: merbanan
author_rank: Contributor
timestamp: April 02, 2016, 12:18:13 pm
content: Quote from: doctormord on April 02, 2016, 11:53:36 amHere it is:https://github.com/merbanan/sigrok-firmware-fx2lafw/tree/sainsmart-dds120and here is the needed change to libsigrok:https://github.com/merbanan/libsigrok/tree/sainsmart-dds120

author: doctormord
author_rank: Regular Contributor
timestamp: April 02, 2016, 12:44:32 pm
content: Thanks,a working blob would be nice, as i actually wont setup the build environment.Please check your mails.

author: merbanan
author_rank: Contributor
timestamp: April 02, 2016, 06:59:33 pm
content: Quote from: doctormord on April 02, 2016, 12:44:32 pmHere it is. This firmware might be compatible with the Hantek 6022BE software.

author: doctormord
author_rank: Regular Contributor
timestamp: April 03, 2016, 05:08:31 am
content: 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: ObsoleteDownload:https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_GlitchFix.zipSee:https://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg911658/#msg911658for actual code.

author: mmark
author_rank: Contributor
timestamp: April 03, 2016, 01:26:41 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: April 03, 2016, 01:48:57 pm
content: 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.

author: mmark
author_rank: Contributor
timestamp: April 03, 2016, 02:49:15 pm
content: Follow-up:I had to installhttp://download.qt.io/archive/qt/5.3/5.3.2/qt-opensource-windows-x86-mingw482_opengl-5.3.2.exeAND 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.

author: mmark
author_rank: Contributor
timestamp: April 03, 2016, 02:56:21 pm
content: Quote from: merbanan on April 02, 2016, 06:59:33 pmMerbanan,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.

author: doctormord
author_rank: Regular Contributor
timestamp: April 03, 2016, 03:41:53 pm
content: Here's the possible trigger approach:EDIT: ObsoleteCompiled:https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V1.zipSource:https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V1-SOURCE.zipSee:https://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg911658/#msg911658for actual codeIt is implemented in buudai_control.cppWorks for rising signals.CHANGES:- setup highest voltage-divider on start (5V)- implemented trigger-hackBUGS/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

author: doctormord
author_rank: Regular Contributor
timestamp: April 03, 2016, 04:18:57 pm
content: Quote from: mmark on April 03, 2016, 02:49:15 pmThere 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-168538575The 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.

author: doctormord
author_rank: Regular Contributor
timestamp: April 03, 2016, 05:29:28 pm
content: 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

author: merbanan
author_rank: Contributor
timestamp: April 04, 2016, 01:55:35 pm
content: Quote from: mmark on April 03, 2016, 02:56:21 pmWhen 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.

author: merbanan
author_rank: Contributor
timestamp: April 04, 2016, 02:20:23 pm
content: Quote from: mmark on April 03, 2016, 02:49:15 pmWe 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.

author: mmark
author_rank: Contributor
timestamp: April 04, 2016, 03:31:21 pm
content: Quote from: merbanan on April 04, 2016, 01:55:35 pmOK, 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?

author: merbanan
author_rank: Contributor
timestamp: April 04, 2016, 05:41:37 pm
content: Quote from: mmark on April 04, 2016, 03:31:21 pmI 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

author: merbanan
author_rank: Contributor
timestamp: April 04, 2016, 06:06:32 pm
content: Quote from: mmark on April 04, 2016, 03:31:21 pmI 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.

author: merbanan
author_rank: Contributor
timestamp: April 04, 2016, 08:05:59 pm
content: Coupling support in firmware and sigrok driver is implemented now.

author: doctormord
author_rank: Regular Contributor
timestamp: April 04, 2016, 08:58:06 pm
content: Nice!Seems like someone messed up the DDS120 page at Sigrok (Hardware Section).

author: merbanan
author_rank: Contributor
timestamp: April 04, 2016, 09:24:19 pm
content: 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.

author: doctormord
author_rank: Regular Contributor
timestamp: April 04, 2016, 11:52:34 pm
content: 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.ziphttps://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V2.zipCHANGES:- 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

author: mmark
author_rank: Contributor
timestamp: April 05, 2016, 02:17:07 am
content: Quote from: merbanan on April 04, 2016, 08:05:59 pmNice!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:data_left += MIN_PACKET_SIZE; /* Driver does not handle small buffers. */with:Code: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.

author: merbanan
author_rank: Contributor
timestamp: April 05, 2016, 08:44:49 am
content: Quote from: mmark on April 05, 2016, 02:17:07 amCan you send your changes as a github pull request so you get the proper attribution for this fix ?

author: merbanan
author_rank: Contributor
timestamp: April 05, 2016, 11:30:54 am
content: 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?

author: doctormord
author_rank: Regular Contributor
timestamp: April 05, 2016, 12:48:33 pm
content: 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.

author: mmark
author_rank: Contributor
timestamp: April 07, 2016, 12:10:18 pm
content: Quote from: merbanan on April 05, 2016, 08:44:49 amDone! 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...

author: MysticPixel
author_rank: Newbie
timestamp: April 29, 2016, 04:53:55 am
content: 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! :-Pninja edit: it looks like SanSmart has a Logic Analyzer add-on that's only another few $. Anyone tried it?

author: lavajumper
author_rank: Newbie
timestamp: May 06, 2016, 06:49:24 pm
content: 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.

author: merbanan
author_rank: Contributor
timestamp: May 18, 2016, 09:10:17 pm
content: Just a heads up. The sigrok stuff is now committed upstream.http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=commit;h=ce1d0a869e4761d30b698b6bb1ea015a0470f09eThere 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.

author: doctormord
author_rank: Regular Contributor
timestamp: May 25, 2016, 03:51:38 pm
content: With much thanks to Joe Vee,there's some progress with the "OpenHantek DDS120".QuoteI set up the sources on GitHub:https://github.com/doctormord/OpenBuudaiAny commits are welcome.

author: Ripman
author_rank: Newbie
timestamp: June 06, 2016, 01:57:10 pm
content: Quote from: doctormord on December 04, 2015, 11:49:04 pmHello, 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.4https://s3.amazonaws.com/Barsoom/Z0/Z00I0C0Z/Z00I0C0Z.ziphttps://www.amazon.de/SainSmart-DDS140-Oscilloscope-Signal-Generator/dp/B00HD6F8HY/ref=sr_1_1?ie=UTF8&qid=1465221711&sr=8-1&keywords=DDS140Many thanks!

author: mjwx4p
author_rank: Newbie
timestamp: June 10, 2016, 07:12:59 pm
content: 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 helpMarko

author: doctormord
author_rank: Regular Contributor
timestamp: June 11, 2016, 06:00:41 pm
content: Did you set up the udev rules right?

author: bianchifan
author_rank: Regular Contributor
timestamp: June 12, 2016, 05:58:04 am
content: Quote from: Ripman on June 06, 2016, 01:57:10 pmYes, it doesn't work.Quote from: Ripman on June 06, 2016, 01:57:10 pmThat seems to be normal, triggers are not really working at all.Quote from: doctormord on May 25, 2016, 03:51:38 pm

author: mjwx4p
author_rank: Newbie
timestamp: June 13, 2016, 08:36:05 am
content: 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.RegardsMarko

author: doctormord
author_rank: Regular Contributor
timestamp: June 13, 2016, 09:27:50 am
content: 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.

author: mjwx4p
author_rank: Newbie
timestamp: June 13, 2016, 03:44:46 pm
content: Hi,Quote from: doctormord on June 13, 2016, 09:27:50 amthat 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.

author: doctormord
author_rank: Regular Contributor
timestamp: June 13, 2016, 04:14:27 pm
content: It would be interesting if the firmware differs much to the one I have. Are you able to dump the firmware?

author: bianchifan
author_rank: Regular Contributor
timestamp: June 14, 2016, 10:58:19 am
content: Quote from: doctormord on June 13, 2016, 09:27:50 amLuckily the DDS140 type is fixed to "8312" in buudai_types.h, same as offered from mineFor 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-3collect2: error: ld returned 1 exit statusMakefile.Release:193: recipe for target 'bin/openhantek' failedto 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 -lpthreadI 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

author: mjwx4p
author_rank: Newbie
timestamp: June 14, 2016, 12:21:46 pm
content: i will try to dumb the firmware and will post it here. Again thanks for your help.

author: doctormord
author_rank: Regular Contributor
timestamp: June 14, 2016, 05:12:56 pm
content: 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.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.

author: mjwx4p
author_rank: Newbie
timestamp: June 18, 2016, 07:06:28 am
content: 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

author: mjwx4p
author_rank: Newbie
timestamp: June 19, 2016, 02:10:09 pm
content: 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?

author: naut
author_rank: Contributor
timestamp: October 30, 2016, 06:15:59 pm
content: hey guys,does anyone have pictures of what's inside the logic analyzer module for the DDS140 model?thanks

author: heisenberg281
author_rank: Newbie
timestamp: December 22, 2016, 09:27:14 am
content: Dropbox link to version 1.5 of their software for the DDS120. Enjoy!https://www.dropbox.com/sh/rzxfia0bvhxpgwk/AADpJyxka11HUzifM4XeGtXda?dl=0

author: clizza
author_rank: Newbie
timestamp: January 11, 2017, 03:27:17 pm
content: 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

author: clizza
author_rank: Newbie
timestamp: January 11, 2017, 03:33:37 pm
content: Has anyone ever solved this issue? I am running Win10 under Parallels and get exactly the same behavior.Thanks, Carl

author: bianchifan
author_rank: Regular Contributor
timestamp: January 11, 2017, 04:28:49 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: January 11, 2017, 05:10:44 pm
content: Wasn't it using the standard WinUSB driver?

author: clizza
author_rank: Newbie
timestamp: January 11, 2017, 06:17:28 pm
content: 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

author: doctormord
author_rank: Regular Contributor
timestamp: January 11, 2017, 06:42:04 pm
content: Well, tried Open_Budich from the thread here?

author: clizza
author_rank: Newbie
timestamp: January 11, 2017, 07:10:56 pm
content: I have not tried Open_Budich and cannot find a link? See atch for what I am working with...

author: doctormord
author_rank: Regular Contributor
timestamp: January 11, 2017, 07:21:07 pm
content: This i meant:https://github.com/doctormord/OpenBuudaiWell, you could try using a VM and Win7 or send the scope back.

author: lclark
author_rank: Newbie
timestamp: January 18, 2017, 03:08:08 pm
content: 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.rulesCode:SUBSYSTEM=="usb", ATTR{idVendor}=="8102", ATTR{idProduct}=="8102", GROUP="users"https://github.com/doctormord/OpenBuudaiMuch happier vs. the SainSmart tools in Windows.Thanks!

author: savvej
author_rank: Newbie
timestamp: April 30, 2017, 07:55:31 am
content: 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.rarhttp://www.sainsmart.com/zen/documents/20-010-731/DDS140_V6.rarRegards,sav

author: swedgin
author_rank: Newbie
timestamp: June 15, 2017, 03:28:00 pm
content: 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 softwarei 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

author: doctormord
author_rank: Regular Contributor
timestamp: June 15, 2017, 10:05:54 pm
content: Trigger level should follow the small arrow to the right.Gesendet von meinem SM-A510F mit Tapatalk

author: bplaa.yai
author_rank: Newbie
timestamp: June 18, 2017, 06:08:16 pm
content: 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 pageCheers

author: doctormord
author_rank: Regular Contributor
timestamp: June 19, 2017, 03:43:46 pm
content: OpenBuudai was never tested with the DDS140, so it needs complete implementation of the different command set. (As the DDS140 uses an FPGA)

author: bplaa.yai
author_rank: Newbie
timestamp: June 19, 2017, 05:23:17 pm
content: Quote from: bplaa.yai on June 18, 2017, 06:08:16 pmQuote from: doctormord on June 19, 2017, 03:43:46 pmWell, that's exactly the kind of "silly" I was expectingRegarding the command set, and based on PapaLukas' Logic140, it looks almost identical between the 120 and the 140 (OpenBuudai typesvs.Logic140 init code).Anyway, time to do my homeworkRegards,

author: SquidCap
author_rank: Newbie
timestamp: July 09, 2017, 03:36:37 pm
content: Quote from: heisenberg281 on December 22, 2016, 09:27:14 amThanks 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)

author: DOCa Cola
author_rank: Contributor
timestamp: August 30, 2017, 12:45:28 pm
content: I've made the effort to compileOpenBuudaifor both Windows and Mac since all links in this thread for it are deadWorks 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=21051875976332290019I've included all required libraries for the Windows version. Just extract and run.Mac:http://s000.tinyupload.com/index.php?file_id=09276964695742077948The 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.Alsono libraries are included with this binary. You need to install these with brew.Code:brew install fftw libusb qt

author: bb512
author_rank: Newbie
timestamp: November 05, 2017, 03:27:09 am
content: 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

author: luminary6
author_rank: Newbie
timestamp: November 05, 2017, 11:37:46 pm
content: Thank You for binary! Windows 7 x64, DDS120 from SainSmart worked.

author: swedgin
author_rank: Newbie
timestamp: December 14, 2017, 04:04:45 pm
content: 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.Quote

author: swedgin
author_rank: Newbie
timestamp: May 24, 2018, 03:15:28 pm
content: 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.QuoteCan someone host a valid .sys file or help me get around this?Greatly appreciated

author: savvej
author_rank: Newbie
timestamp: June 09, 2018, 09:31:27 am
content: Quote from: bplaa.yai on June 19, 2017, 05:23:17 pmHi,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

author: savvej
author_rank: Newbie
timestamp: June 09, 2018, 11:03:56 am
content: 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

author: UnSeen
author_rank: Newbie
timestamp: March 30, 2019, 11:02:10 pm
content: Hello guysThe 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 supposedQuote from: savvej on June 09, 2018, 11:03:56 amIf would be cool if you could share your modified code. Thanks

author: keropi
author_rank: Newbie
timestamp: May 20, 2019, 08:45:22 pm
content: 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 DDS140https://www.mediafire.com/file/4bkw7vsc7fy9755/SainSmart-DDS120-DDS140.rar/file

author: mmark
author_rank: Contributor
timestamp: October 19, 2019, 02:13:59 pm
content: 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/OpenHantek6022for 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.

author: kimbergirl
author_rank: Newbie
timestamp: October 25, 2019, 02:04:14 am
content: 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....

author: mmark
author_rank: Contributor
timestamp: October 25, 2019, 02:30:28 am
content: Tryhttps://github.com/OpenHantek/OpenHantek6022/releases/download/v2.17-rc5/OpenHantek-Win-x64-Release-b169.zip(64 bit) orhttps://github.com/OpenHantek/OpenHantek6022/releases/download/v2.17-rc5/OpenHantek-Win-x86-Release-b169.zip(32 bit).DDS120 support has been integrated into OpenHantek6022...

author: kimbergirl
author_rank: Newbie
timestamp: October 25, 2019, 04:46:28 am
content: thanks for the quick replyi still dont regret the nastygram that is in the Sainsmart inboxback to work on the electric car......

author: Rio
author_rank: Newbie
timestamp: October 25, 2019, 08:09:33 am
content: @mmark: Thanks for your effort. I used the DDS120 easily with the last version of OpenHantek6022 in Win7...

author: kimbergirl
author_rank: Newbie
timestamp: October 25, 2019, 12:27:15 pm
content: thankssomeday 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

author: luminary6
author_rank: Newbie
timestamp: December 01, 2019, 04:20:19 pm
content: 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 fileC:\Users\USER\.config\OpenHantek\modelDDS120.confwith content (for my DDS120):Code:; 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 gainch0\20mV=1.250ch0\50mV=1.244ch0\100mV=1.241ch0\200mV=1.298ch0\500mV=1.164ch0\1000mV=1.199ch0\2000mV=1.205ch0\5000mV=1.203ch1\20mV=1.231ch1\50mV=1.235ch1\100mV=1.252ch1\200mV=1.322ch1\500mV=1.193ch1\1000mV=1.219ch1\2000mV=1.221ch1\5000mV=1.224; add offset valuesch0\20mV=6ch0\50mV=6ch0\100mV=6ch0\200mV=5ch0\500mV=6ch0\1000mV=5ch0\2000mV=5ch0\5000mV=5ch1\20mV=5ch1\50mV=5ch1\100mV=5ch1\200mV=5ch1\500mV=5ch1\1000mV=5ch1\2000mV=5ch1\5000mV=5I write this message for any who want use OpenHantek6022 software with SainSmart DDS120 and will face the same problem.

author: horo
author_rank: Regular Contributor
timestamp: December 02, 2019, 10:12:44 am
content: Hello luminary6,Thx for providing your conf file. OpenHantek6022 already does provide atemplatefor this file, but with gain = 1.0. I had a quick look into the input gain selectionthereandtherein this thread and will update themodel fileaccordingly, so that even without a conf file the gain error will not become too big, a rough estimation would be:Code:specification.voltageLimit = { 32 , 80 , 160 , 155 , 170 , 165 , 330 , 820 };specification.voltageLimit = { 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 fromappveyors artifacts. There are also theolder buildsavailable.MartinEDIT:I've created a newissue #39on github.EDIT2: Closed issue, luminary6 please check if the scope behaves better when usedwithoutconf file.

author: horo
author_rank: Regular Contributor
timestamp: December 05, 2019, 12:38:06 pm
content: Hello luminary6,I updated the DDS120 handling again,please check the latest build:https://ci.appveyor.com/project/Ho-Ro/openhantek6022/build/artifactsIf you want to test older Win builds, there's also a history:https://ci.appveyor.com/project/Ho-Ro/openhantek6022/historyMartin

author: luminary6
author_rank: Newbie
timestamp: December 15, 2019, 04:09:12 pm
content: 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 VoltCH2 = -0.41 Volt5) Reconnect DDS-120 to USB.6) Run new version (b205, x64) and get zero at:CH1 = 5.96 VoltCH2 = 6.01 VoltChanges 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.0But 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?

author: luminary6
author_rank: Newbie
timestamp: December 15, 2019, 04:39:43 pm
content: I read your message at github and understand that you correctonly "gain", but "offset" value you remove from source.QuoteI was remove gain section in my config file, and run new version (b205) with only offset in my config file.QuoteVoltage 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.

author: konkdekilo
author_rank: Newbie
timestamp: September 23, 2022, 08:33:47 pm
content: 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