Products > Test Equipment

SainSmart DDS120 & DDS140 USB Oscilloscope

<< < (25/84) > >>

donut6:
mmark,

Nice one!

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

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

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

Good work guys! :o

psynapse:
Looks like this community is cooking!

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

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

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

Doctormord,

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

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

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


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

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


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


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

psynapse:
Ganzuul,

The big question is which two bytes!

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

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

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

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

The same 6363 pattern exists in the DDS120

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

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

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod