Products > Test Equipment

SainSmart DDS120 & DDS140 USB Oscilloscope

<< < (17/84) > >>

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

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

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

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

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

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

psynapse:
Doctormord,

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

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

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

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

doctormord:
psynapse,

thanks for the reply.

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

-->
--- Quote ---last request came at 35.6s with the last package received at 48.8s.
--- End quote ---

If some coder could explain? Where is the magic?

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

But im not an USB coder.

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

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


Hardware-wise i updated the tracefile to:

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

Clocking and ADC-setup is traced back.

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


(Preview is attached)

To my eyes, the gainstage is a bit strange.

Gainstage schematic:



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

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

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

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




--- Code: ---0x22 0x08 0000 1000 1 50mV/div
-6dB Input
+10dB Gain (x3.5)
0x22 0x04 0000 0100 1 100mV/div
-6dB Input
+3.3dB Gain (x1.46)
0x22 0x00 0000 0000 1 200mV/div
-6dB Input
-4.4dB Gain (x0.6)
0x22 0x06 0000 0110 1 500mV/div
-20dB Input
+3.3dB Gain (x1.46)
0x22 0x02 0000 0010 1 1-5V/div
-20dB Input
-4.4dB Gain (x0.6)
0x23 0x20 0010 0000 2 50mV/div
-6dB Input
+10dB Gain (x3.5)
0x23 0x10 0000 1010 2 100mV/div
-6dB Input
+3.3dB Gain (x1.46)
0x23 0x00 0000 0000 2 200mV/div
-6dB Input
-4.4dB Gain (x0.6)
0x23 0x12 0000 1100 2 500mV/div
-20dB Input
+3.3dB Gain (x1.46)
0x23 0x02 0000 0010 2 1-5V/div
-20dB Input
-4.4dB Gain (x0.6)
--- End code ---

I haven't taken "Ron" (D-S resistance inside CD4052) into calculation, which will result in slightly higher gain at the low end.



doctormord:
Curious, how does the ADC gets clocked?

Regarding the EZ-USB Technical Reference Manual:

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

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

Maybe its like:

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

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

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

Conclusion:

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

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

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

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)

 |O

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)  :wtf:

Attached are some dumps from USBTrace.

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

psynapse:
(Not posted earlier)

Doctormord,

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

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

But in the meantime

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

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