SainSmart DDS120 & DDS140 USB Oscilloscope

[doctormord]

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

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

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

Data reconstruction can then be done in software.

[psynapse]

Doctormord, 

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

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

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

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

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

[doctormord]

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

[mmark]

Psynapse,

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

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

mmark

[doctormord]

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

[ganzuul]

I do have a functioning trigger in software (though only in my adaptation of Donut6 WX based code).  It is based on generating the first differential of the input data (more simply the difference between current and previous input value) .  By keeping track of the maximum of this value and where it occurs in the dataset you have a plot startpoint.  To speed the process and to avoid late syncs which leave too little data to plot, I scan just the first 25% of the input in this way.

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


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

[jimon]

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

[ganzuul]

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

[doctormord]

My approach of a classic generator is shown here:

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

[psynapse]

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

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

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

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

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

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

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

[doctormord]

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

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

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

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

Means:

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

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

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

Should work:

FODM8071
SFH6701/11

You might also consider TIs high speed digital isolators.

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

Hardware-trigger should also be possible in DDS120.

[psynapse]

Doctormord,

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

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

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

Bn   no pins

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

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

[doctormord]

Regarding:

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

Page 221

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

This might get helpful:

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

[psynapse]

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

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

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

[doctormord]

Nice!

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

(Like on cameras)

[psynapse]

Doctormord,

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

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

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

What is left to do??

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

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

Which is it folks?

[CatWhisker]

Psynapse,

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

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

[doctormord]

Psynapse,

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

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

[psynapse]

Doctormord

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

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

CatWhisker

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

[doctormord]

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

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

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

Regards,

Doc

[psynapse]

doctormord;

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

All,

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

[doctormord]

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

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

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

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

[bobi_dunkel]

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

[psynapse]

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

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

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

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

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

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

[doctormord]

Ledioskope is within this thread.