SainSmart DDS120 & DDS140 USB Oscilloscope

[psynapse]

"if this is simply the state the software was in when time ran out for the dev. "
100% agree


Guys:

You have posted loads, which I will read more thoroughly in the morning, I need some sleep.

It is clear that the scope firmware is pretty random:- I see the same stuff as you some of the time and not others, and I do not think it is us!

A couple more little snippets, both DDS140 of course.  What I said about data capture on that device remains true, nearly!  As I wind the timebase down, the sampling rate goes down from 100M, 10M, 625k and finally 39k ..... except when I switch the timebase right down to 500mS or 1 Second.  At these slowest of rates, the data capture rate rises to 240ksps and the hardware buffer full flag (C.6) never registers full. At that rate there appears to be no data loss (TBC)  However the display software is useless!  So continuous data logging at 240ksps looks as though it may be possible after all on the DDS140.  Not much but better than nothing. 

Second thing.  When I stop/start the trace, all the software in the PC does is stop sending 50 (status) commands.  On the DDS140 the device itself does not notice that it has a buffer full until the 50 command prods it into checking, when the data comes flooding out again.  I think that the DDS120 and 140 are very different beasts,  excepting that they both seem capable of continuous running at 240ksps (Thanks to both of you on that one)



Ganzuul.  I agree that the TRM is confusing.  My reading of it and USB standards are as follows (but I need to check for fundamental differences between the DDS120 and 140).  Initial negotiation between host and FX2 permits the FX2 to send interrupt packets. Against the USB 2 standard, it can send up to 3 interrupt packets  (each up to 1024 bytes) in each of the 8 available microframes that make up a millisecond.  These are re-assembled by the host into a complete message.  Maximum theoretical throughput is then 3x1024x8x1000 or a bit less than 24Mbps.  This gives each (DDS140) block of 2¹? bytes a transit time in of around 6mS.  Where XP and the app spend the next 94mS,  I do not know!

And in agreement with  Ganzuuls comment note interrupt, not iso!  This I have checked with the start up parameters in the firmware.

And as per Doctormords comment "Indeed, it always sends data from both channels, as i'd shown some posts before", interrupt mode puts no obligation on the host to actually read the data. EDITAnd Doctormord:- finally looked at your wireshark trace for the DDS120, these really are very different machines.  As you have been saying, data just comes out of the thing when it wants to. I really need to review your mega post more carefully and document more clearly the DDS140 codes.  I now know for example that the 94 command is perhaps the most dangerous of all the DDS140 commands:- it reloads the GPIF state machine and transfers its input parameter to Port A for some reason yet to be determined. And note that it changes state machines dependant on that input parameter.END EDIT

Except for the 200M single channel  :-//mode, which I have not checked, I think the 140 always sends both channels, even with only one selected. I will double check.

As to learning the FX2 , I agree . It seems about the only game in town for simply moving large amounts of data of USB.  There are plenty of code examples out there too.  As to the hardware we are discussing, again I would not recommend the DDS140, the CPLD is still a complete black box to me, and if I can it will stay that way.  No keep with the 120 guys,  I wish I had brought it instead.

That is not to say that the 120 is going to be easy.  I expect it uses the GPIF state machine, and are really going to need some level of circuit schematic.  First thing I would do is to see how much the hardware differs from other designs (links somewhere in this thread).  Not sure there is much point going in there with a soldering iron .... yet!  I have tacked two wires to the pcb,  I sweated a bit on that .  They connect the write signal to the RAM and the buffer full signal into an arduino.  From that I can generate my sync feed.  But again, would not need to do that on a 120.

Happy hunting.  More as I find it out.

[doctormord]

I put some more efforts hardware-wise into the DDS120. To have a better understanding, whats going on in there, there's a big template now.

Full-Size-Download (updated at 2014/10/23 01:46p):

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

Regards,

doc

[donut6]

psynapse - hopefully this should line up with your DDS140 firmware analysis

Code: [Select]

    //  Command  Bit Field ..... Description
    //    0x22   0000 0aa0   
    //                 00  ..... Gain Ch1   (0x0)
    //                 01  ..... Gain Ch1   (0x2)
    //                 10  ..... Gain Ch1   (0x4)
    //    0x23   0b00 0000
    //            0        ..... Gain Ch2   (0x00)
    //            1        ..... Gain Ch2   (0x40)
    //    0x24   000c abbr
    //                   0 ..... Relay
    //                   1 ..... Relay - Ch1 to both ADCs 
    //                 00  ..... Gain Ch2   (| 0x0)
    //                 01  ..... Gain Ch2   (| 0x2)
    //                 10  ..... Gain Ch2   (| 0x4)
    //                 11  ..... Gain Ch2   (| 0x6)
    //                0    ..... Gain Ch1   (| 0x0)
    //                1    ..... Gain Ch1   (| 0x8)
    //              0      ..... Ch2 AC     (| 0x00)
    //              1      ..... Ch2 DC     (| 0x10)
    //    0x94   000d ssss
    //              0      ..... Ch1 AC
    //              1      ..... Ch1 DC
    //                0000 ..... 100Mhz  (0x0)
    //                1100 .....  10Mhz  (0xc)  80/0x8
    //                1000 ..... 625Khz  (0x8)  80/0x80
    //                1011 .....  39Khz  (0xb)  80/0x800
    //                1010 .....   ?     (0xa)

[doctormord]

Updated Version:

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

PE3 and PE0 controls 2 PhotoMOS Relays directly at the Input to switch between AC/DC coupling. (NAIS 210EH)

[doctormord]

Oops, I missed that.

But I did notice the bug psy mentioned, where the scope keeps sending data after the scope app has been stopped. I makes me wonder if there actually is any logical coupling between each request and reply, and if this is simply the state the software was in when time ran out for the dev.

This problem comes from the fact, that the software is requesting more packets than the scope can deliver. This also happens with the DDS120 at bigger/longer timebase-settings and can be seen by Wireshark.

I posted a table in #55 (page 4)

Code: [Select]

1ms-5ms 240kHz 5 65536
10ms 240kHz 3,7* 131072
20ms 240kHz 1,85* 262144
100ms 240kHz 0,91* 524288
200ms 240kHz 0,459* 1048576
With 5 requests per second, the scope begin to lag with 10ms (timebase-setting) upwards. At 200ms timebase-setting and i.e. 10 seconds sampling-time, there will be 50 requests but only ~20 replys, so the scope is sending data for 15 more seconds after STOP.

Suggestion:

A DDS120 owner should repeat a very similar experiment to determine whether that device is capable of continuous acquisition.  The only tricky part is tacking a wire onto the board.  After that the wire goes to a frequency counter or the "counter in" on an arduino.  My fear is that the same programming style will have gone into the DDDS120, ie get a block of data, stop, transfer it, restart acquisition.  If I remember correctly, other folks wireshark traces certainly show a "start" command after each block transfer, but are those traces on the DDS120 or the DDS140?  It may even be possible (by using low data rates) to judge this from the less accurate wireshark data.  If somebody will post a raw USBPCAP file for the DDS120 running at its lowest rate, I will have a look.  The trace will need to be for say 20 bulk transfers.

Here we go:

https://dl.dropboxusercontent.com/u/5641160/DDS120_CH1_AC_ON_CH2_AC_ON_200mV_5ms_240kHz.rar

Settings like filename. At start i toggled CH1/CH2 coupling AC/DC/AC and then ran for about 25 seconds. (Start is at ~9seconds)

With tdiff = 9s, the last request came at 35.6s with the last package received at 48.8s.

Edit:

I wrote up some informations on my site:

http://www.360customs.de/2014/10/usb-oszilloskop-sainsmart-dds120-2-kanal-20mhz-50msps-buudairocktech-bm102/

Sorry for the translation, its automatic.

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

-->

last request came at 35.6s with the last package received at 48.8s.

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. 

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: [Select]

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

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)

 

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) 

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)

[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]

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)

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)

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

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)

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)

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. 

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. 

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

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.

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

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.

[psynapse]

Again, filled with admiration.   I have neither the courage nor the ability to do that.  That Rdy0 line makes all the difference.  And I see a couple of plated through holes that could be important. (but then I checked a photo of the back of the PCB, just one heavy track, so no you have found everything.  Good news)

Sorry thought you were using LTSPICE rather than multisim.  Yes, I guess. increasing the value of all the external resistors will reduce the variability due to the internal resistance of the 4052. But as you say, it will hit the gain bandwidth problem....... But perhaps not...... we do not need to change the gain of the amplifier ..... the only problem might be the change in input/output impedence that will be needed.

And to misquote you, me "I am firmware, not software". Happy to tinker around at that level, but I am old and never got to master OOPS!  So I am hoping that with you at hardware (and clearly some software), me at firmware (with a bit of hardware and software), perhaps we could look to donut6 for the soft side .... But he has already said he is busy .... We all have lives!

[doctormord]

Resoldered the IC and tried sigrok:

http://sigrok.org/wiki/Main_Page

There also is an open source firmware available - FX2LP mode. With the eeprom-jumper removed, the scope is running in devkit mode (Cypress standard) and just reads raw from the 2 ports via FIFO. Also simple control codes are implemented. (I think async fullspeed, so no IRQ)

As you're the "firmware", here is my idea:

- Sampling at max samplerate all the time
- "timebase" just in software
- implementing the controlcodes for the gainstage
- done.

I see some data coming in in Pulseview, the actual problem is, the ADC is getting no clock from the CYPRESS. (needs to be configured)

Infos about firmware:

http://sigrok.org/wiki/Fx2lafw

Sourcecode of firmware:

http://sigrok.org/download/source/sigrok-firmware-fx2lafw/

I further simulated some things of the gainstage with the right opamp models. Gain varies with frequency at frequencies >~8MHz. Changing the values at Q1 to 100R would help abit for this stage. GBW is varies with gainsetting as well. There definitely is some compensation needed. 

To minimize temp-/amplitude drift within the analog switches, the CD4052 may be changed to some 74HCxxxx. (With 1/10 of Ron)

V(n004) is the output of Q1.
LTSpice stuff is attached as well.

[ganzuul]

In a desperate effort to keep up with you guys ( )  I soldered a wire to the resistor on the clock line and tried to read the clock ticks with my Propeller uC. The verbatim reading I get is a few 100 kHz under 13MHz, and by making a few other measurements I presume that the ADC is always actually running at XTAL/2. - If of course I have not made some grave oversight regarding the performance of my uC, which remains possible. I made a thread on the Parallax forums but suddenly the forum decided that a moderator needs to review my posts. Perhaps the reading I get is a result of aliasing.

[donut6]

Here's some code for the DDS140 that may be useful for experiments.

Good luck compiling. It may also destroy your device.

This needs wxwidgets, libusb , ...

Makefile ->

Code: [Select]

CXX := g++
CXXFLAGS := -O2 -g -DGL_GLEXT_PROTOTYPES -I./

scope.o: scope.cpp
$(CXX) $(CXXFLAGS) `wx-config --cxxflags` -c scope.cpp -o scope.o

scope: scope.o
$(CXX)  scope.o -o scope -lusb-1.0  -lGL -lGLU -lX11  `wx-config --libs --gl-libs`

[psynapse]

Donut6,
Many thanks for the code, I will look at it very shortly.

Doctormord
1) Improving performance of the input stage. Putting temperature variability to one side for a minute, I think that this is the key curve for a CD4052 is shown at attachment
I note two things.  Running the device at a higher voltage reduces both resistance and non linearity.  In principle, the higher supply voltage should not cause a problem in terms of analogue inputs/outputs,  but the multiplexer select lines would need buffering.  So that is the quality approach
Secondly at 5V supply, and 0-1V operating range, linearity is not too terrible and resistance comes in at 400 ohms.  This is the "do nothing" approach!

On the firmware front, happy to give it a go .... but I guess I must buy a DDS120, which will need to be from next months pocket money!  Implementing gain and timebase should not be the difficult part.  The key part is of course reliable data transfer at maximum rate.

I am guessing you are using Cyconsole to load up the FX2 with the other firmware and then re-enumerating? If we can get that path working it is going to save a lot of development time

And a word of warning to all. As a proof of principal, I wanted to change exactly 1 bit in the default firmware of theDDS140 (The IFCONFIG bit that switches out of GPIF debug mode).  Made the edit in cyconsole and re-enumerated. "Bad device".  It took a long time comparing hex dumps to find out that cyconsole was systematically changing the contents of 20-3F in the eeprom when I rewrote my two bytes in a completely different part of the memory map D30,D31.  I copied back by hand the damaged fields and all is working.  My priority at the moment is to get the default firmware into an iic file (and find out how to generate an iic) before trying any further firmware mods, no matter how small.

Ganzuul,  if I am right that resistor is connected to IFCLK, which when driven by the FX2 can only take on values of 30 and 48Mhz.  So I think your aliasing explanation is right, you have 48/4

[psynapse]

Donut6

Wow lots of dependencies!  What did I expect?   You work on your machine and this is work in progress.

Struggling with the dependencies  wx/wx.h

I have installed as per the screen snap, any quick ideas please?

[donut6]

psynapse,

Try libwxgtk3.0-dev

And libusb-1.0.0-dev

make scope
./scope

You'll need an udev rule set up for 8312 8312

[doctormord]

No need to have .iic, you can flash straight .bin with CyConsole. (Just select .* all files in the dialog).

I had done this before with success (and verified via I2C dump). (I wrote something on page 2/3 about this here)

[psynapse]

Donut6

Both already installed ..... the dreaded path problem then. I will look in the morning, but thanks anyway

Doctormord

Thank You. Yes, I remember somebody had a problem, but had not remembered the .bin solution.  I followed your post in order to get the hex out of the DDS140 to start with.  Very glad I did!  And now you mention it I remember a hex to bin converter somewhere in the cypress software

All
Sorry, away from keyboard this weekend , it is our village fête this weekend

[donut6]

psynapse,

Does this command work?

Code: [Select]

wx-config --cxxflags
If so, perhaps the Ubuntu wxwidgets package doesn't set up the include path correctly.

also

Code: [Select]

wx-config --list