| Products > Test Equipment |
| SainSmart DDS120 & DDS140 USB Oscilloscope |
| << < (32/84) > >> |
| jimon:
@doctormord sure, I was unable to read default cd that came with a DSO (I simply don't have a cd reader anymore), so I searched for a software online, and found it at http://www.amazon.com/SainSmart-Portable-Handheld-Oscilloscope-Bandwidth/dp/B00FYGEFYM You can see there at a bottom : --- Quote ---Note: Please download updated software and manual here: https://s3-ap-northeast-1.amazonaws.com/sain-amzn/20/20-010-730/DDS120_2014_1_13.zip https://s3-ap-northeast-1.amazonaws.com/sain-amzn/20/20-010-730/CD/DDS120.rar --- End quote --- |
| doctormord:
Thanks. :) Edit: Seems to be the same as "standard" SainSmart version. |
| psynapse:
All (esp mmark), QT has certainly been a learning curve! I see that mmark has been busy too! I have added my current code, so that we can both/all get the best of both/all worlds! I have not tried porting the code to a second machine and have only coded/tried it on a DDS140 (the key dependencies I can remember are QWT and libusb). As I have said before, this code is really the basis for testing firmware extensions to the DDS140, but the bit that I do like is the display rendition (largely not of my making). I get over 20 frames per second (single threaded for a dataset of 131kbytes ) and I love the fact that the display has pan in X and Y (mouse drag over the display) and zoom in X and Y (ctrl or shift+ rotate mousewheel over the display) As with mmark, you need to take ownership of the USB port. The code is certainly "alpha", and as I said at the outset, it is shared so that we can cherry pick the best bits. I will be improving the code, and will post a less buggy version shortly. If you do try it, note continuous mode is not implemented , and X scale and offset are now just done through the mouse. EDIT: WHOOPS! Push the single shot for one trace, or dial up a succession of flashes and then press single shot (I did not want to lose control in my code just yet with a continuous mode, but 99 single shots gives a clear idea of frame rate) |
| psynapse:
mmark mmark, do not underestimate your own contribution to this project either. And for me Donut6's WX based code still provides the USB underlying layer for my QT5 implementation. Just reading through the last couple of days of postings. I am pretty sure that the 8051 firmware itself will not make an intervention once data has started to flow , the fifos are programmed to run autonomously. However the endpoint FIFOs are 1024 bytes in size, and there are four of them. So I suppose that at setup time for the transfer, the ring of four might be initialised poorly. Did you say that the system continues just fine after that ? If so I would suspect bad FIFO set-up. A wild assertion. I am guessing that the ADC is running continuously into the FIFOs and that the firmware decides whether to transmit these to USB. Badly written code (firmware) could initialise USB transfer and then continue to a FIFO reset .... I guess the FX2 wopuld have already commited to the send. That is the trouble with the FX2, asynchronous USB engine, asynchronous GPIB engine and 8051 Have you tried running the software with just one go code at the start ? (Or do you do that already) On the DDS140 and 240ksps (which I think is the same as the DDS120 normal mode), the data keeps flooding in, as Doctormord knows only too well! However I would expect that data to be uncorrpted. To my mind the easiest thing to do would be to jettison the first 1024 bytes ..... unless we get a good trigger working, in which case they will be critical! (On the DDS140, the first 27 bytes recovered from the buffer are rubbish .... When I get the chance to look at the wireshark traces, I think they are just header information) And I guess it is the same with your software, when you view the traces of an identical signal through the two channels, it becomes only too clear the Doctormord is right to be concerned about sampling errors! (see the screenshot) I use a look up table because it is fast (eg) indx=loop-initial_offset; buffery[indx]=LUT1[scope_data[2*loop]]; But I have not yet loaded the LUT with all of attenuator, ADC null offset, non-linearity correction , software driven offset and software driven gain! I also agree with you about OpenHantek and other projects (although I really hate us re-inventing the wheel again). The more I coded, the more it was clear that that the architectural differences in the hardware (esp the DDS140) make common code very much more difficult. However I agree completely with Doctormord that we should go "open" when we have something sufficiently stable to give to the community. Doctormord, sorry about the Tant, I feel partly responsible for the desolder. It was a noble sacrifice for the community, thank you. I guess you have tried tacking an external cap on the board? |
| donut6:
psynapse, --- Quote ---Badly written code (firmware) --- End quote --- I may be able to help. I've created a proof of concept sdcc/fx2lib DDS140 firmware implementation if you are interested? It's badly written, and currently doesn't quite work (probably just an issue with waveform selection). But it does capture data. |
| Navigation |
| Message Index |
| Next page |
| Previous page |