Products > Test Equipment
SainSmart DDS120 & DDS140 USB Oscilloscope
<< < (18/84) > >>
psynapse:
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 confirms


So 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 four

Put both together and you have, for the front end gain

x2
x1
x0.5
x0.4
x0.2
x0.1

Transfer rates

Now 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 it http://www.triplespark.net/elec/analysis/USB-LiveOsci/
psynapse:
Doctormord

Sorry, 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 do

As 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?
doctormord:

--- Quote from: psynapse on October 23, 2014, 10:45:41 pm ---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)

--- End quote ---

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)


--- Quote ---Transfer rates

Now 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  ..

--- End quote ---

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)


--- Quote ---Doctormord

Sorry, 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 do

As you rightly point out, even at 2.4Mhz the CPU is too slow to pick out 1 sample in 10 (or maybe even 20)
--- End quote ---

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.
psynapse:
'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!

doctormord:
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.  :-X :)

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.  :-/O

RDY0/*SLRD is connected to *FLAGD/SLCS#/PA7


--- Quote ---In synchronous mode (IFCONFIG.3 = 0), the FIFO pointer is
incremented on each rising edge of IFCLK while SLRD is
asserted. In asynchronous mode (IFCONFIG.3 = 1), the
FIFO pointer is incremented on each asserted-to-deasserted
transition of SLRD.
--- End quote ---


--- Quote ---By default, SLOE and SLRD are active-low; their polarities
can be changed via the FIFOPINPOLAR register.
--- End quote ---

Source: 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 Reads

From 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 is
asserted. -> 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.jpg

Preview attached.

Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod