Products > Test Equipment
SainSmart DDS120 & DDS140 USB Oscilloscope
doctormord:
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.
We don't have higher voltages available here. (Still unknown, how the negative voltage is generated)
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!
I would rather change the multiplexers to 74HCxxxx.
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.
Actually the firmware is loaded to the Cypress RAM when starting the software (Pulseview). The Scope enumerates with the standard PID/VID when eeprom jumper is open. So firmware-changes could be done at runtime.
(The original firmware is still in the attached eeprom)
Zigrok/Pulseview includes a tool (Zadig) to change the driver for the Cypress on the fly. (WINUSB, libusb, libusbk.. )
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
You may check if IFCLK is connected to CLKOUT somehow.
--- Quote from: doctormord on October 23, 2014, 04:26:38 pm ---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)
--- End quote ---
At DDS120, it is not. So the ADC is running either running at 30 or 48Mhz.
psynapse:
Hi Donut6,
Thanks again, it looks as though from the replies the install is correct
--- Quote ---Does this command work?
--- Code: ---wx-config --cxxflags
--- End code ---
--- End quote ---
-I/usr/lib/i386-linux-gnu/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread
--- Quote ---If so, perhaps the Ubuntu wxwidgets package doesn't set up the include path correctly.
also
--- Code: ---wx-config --list
--- End code ---
--- End quote ---
Default config is gtk2-unicode-3.0
Default config will be used for output
Alternate matches:
base-unicode-3.0
But please leave it, I will sort it after the weekend..... Your time better spent on advancing the code.
Doctormord
I will get back to you on your observations, too little time today. My apologies. Only thing to note immediately, the 74HC4052 seems slightly worse in terms of resistance/linearity. From my standpoint, I would rather correct in software in the PC through a LUT. But a redesign from scratch, I agree with you, always better to get the hardware right to start with. Weird about the negative rail generator.
doctormord:
I actually connected CLKOUT to the CLKIN of the ADC (bypassed IFCLK) - works. Not sure if 12 or 24Mhz, but i dont see any change in samplingrate. (So even 240kHz in software shows valid data)
:)
Only thing to note immediately, the 74HC4052 seems slightly worse in terms of resistance/linearity.
From http://www.nxp.com/documents/data_sheet/74HC_HCT4052.pdf
they perform much better.
ganzuul:
--- Quote from: doctormord on October 24, 2014, 12:45:03 pm ---
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. :-//
--- End quote ---
O0
USB spec says all transfers are initiated from the host, which could result in huge variances to when the host polls the device. Isochronous mode decreases this variance a lot, and for our purposes iso means we require less from the 4K buffer.
EP2 can be configured to be 4x 1K, and it doesn't look like to me that there are any special considerations to this. It's just a single 4K buffer. Meanwhile in the examples I've looked at, EP6 is used for iso and they recommend 512 for iso. I'm not sure if one can use EP2 and get full bandwidth for iso, but I also don't think it's unreasonable to demand we get an entire USB 2.0 host controller all to ourselves so we don't need to share resources.
To logically couple the device to the host, I think each host -> device poll should tell the device to keep alive. Since this is an RX-only application we don't have to care about latency, so we can let big buffers take care of perceptual continuity. We won't know exactly when a signal arrived unless we code that information into one of the analog channels. I can't think of an application where we'd need to know the device time accurately though...
psynapse:
Just briefly.
I have been digging aroung in the firmware, trying to find out more about the DDS140 94(0A) command which gives continuously sampled 240Khz data. I have tracked down the special wavetable that is invoked only for this timebase rate (which strangely is only available when you select 1second timebase)
Coming to grips with the wavetable editor, the FIFO read mode has 4 states, lasting 1,99,99,1 clock intervals. And 48Mhz/200=240khz. There maybe hardware reasons for the speed limit, and at higher rates there will certainly be USB transfer rate limits, but I shall be playing with these values to see what other timebase rates could be available (as the only truly continuous data mode for the DDS140)
In agreement with what doctormord says, this wavetable mode would see the ADC running at full speed and the fifo taking 1 sample in every 200 48Mhz clock periods. I have no way of knowing, but it seems distinctly possible that this is the standard mode for the DDS120. Change the state periods, change the overall sampling rate. I need to find the wavetables in the DDS120 in order to know more.
For DDS140 owners, the pattern 63h 63h only seems to appear once in the eeprom image, and these are the two 99d clock period waits in the fifo load.
The downside is that the scope software is simply not capable of handing the inrush of data. Custom display software needed. More on Monday
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version