Products > Test Equipment
SainSmart DDS120 & DDS140 USB Oscilloscope
doctormord:
"Because we can." |O
psynapse:
Doctormord:
Argh! seems like I brought my DDS140 two weeks too early ... the BS204 is exactly what I need in terms of functionality.
I am still making progress on the code, but ask myself whether there is anybody wanting it. Are there elements that you are searching for? I guess you are not planning on rewriting the DLL!
But thanks for the BS204 heads up anyway.
Ganzuul:
The point? perhaps just to be able to say it is an "open" interface. Which of course it is not
All:
After days of negative feelings as to progress, I finally got round to Wiresharking the USB stream. And low, I see the command set I've already seen in the firmware , the only code I was missing is E7.
In fact, once the scope is setup (permit USB interrupt data transfer gain,ACDC etc) the sequence of events is incredibly simple. The host(pc) issues a "go code" of 33h, periodically checks the status of the FIFO with command 50h, which returns 2Ch for fifo not full. When the EZUSB does detect fifo full, it returns a code of 21h, halts the fifo (and hence data acquisition) and then blasts 2^17 bytes to the PC under a USB "interrupt". On my machine this takes around 15mS (not sure why so slow). The whole process is then repeated, issue go code, check status, stop fifo when full and transfer data under USB "interrupt".
All this means that there are periods of black out, which get more dominant with timebase speed. At 100Mhz 2 channels running, data acquisition takes around 650uS and transfer 15mS, so blind 95+% of time.
However the good news is that if the go-code can be timed properly by the PC, or gated in hardware, single shot triggering is possible, but only in the sense that the scope acquires data post-trigger.
Which for my needs leaves two tasks:-
1)gating the go-code before it leaves the PC or through hardware/firmware in the scope
2)finding out what all the twiddly hardware setup codes are (optional, if I am prepared to live with the supplied ##### software)
donut6:
psynapse,
I can start to comment my code now!
--- Code: --- int w = 0;
int resync = 0;
scope_request(0x33, 0x00); // "go" code
// check FIFO status:
while (w != 0x2c)
{
w = scope_request(0x50, 0);
resync++;
if (resync>10) break;
}
while (w != 0x21)
{
w = scope_request(0x50, 0);
resync++;
if (resync>25) break;
}
if (w == 0x21) // fifo full
{
int r = acquire_scope_data();
if (r < 0) return;
}
render();
--- End code ---
The rest is just libusb code
--- Code: ---int scope_request(int req, int val)
{
unsigned char data;
if (scope_handle)
int r = libusb_control_transfer(scope_handle, 0 | LIBUSB_ENDPOINT_IN, req, val, 0, &data, 1, 0);
return data;
}
--- End code ---
And to read the scope FIFO buffer:
--- Code: --- r = libusb_bulk_transfer(scope_handle, 0x2 | LIBUSB_ENDPOINT_IN, scope_data, sizeof(scope_data), &transferred, 1000);
--- End code ---
scope_request(0x24, 0x18) enables ch1 & ch2 input
scope_request(0x24, 0x19) enables ch1 input
scope_request(0x94, 0x10) sets the ADC to "100Mhz"
scope_request(0x94, 0x1c) 10Mhz
I think. Not tested this yet.
So in terms of software, it seems trivial to me! I'm working on a basic wxWidgets front end, but don't have much spare time this week!
doctormord:
Good job guys!
psynapse:
Donut6
Keep going! Great.
I am getting slightly different time base codes (with bit4=0) ie
94,00=100megs
94,0C =10 megs
94,08=625kHz
94,0B = 39khz (ie 100M/256)
less sure
24,0A C2 to AC
24,1A C2 to DC
94,08 C1 to AC (noting that this conflicts with my timebase setting)
94,18 C1 to DC (noting that this conflicts with your timebase setting)
Both 24 and 94 codes load the bottom 5 parameter bits into Port A, connected to the CPLD on the DDS140
I do not see a logical bitwise use, so I guess it is decoded .... with 32 combinations of commands? Also the heavy use of 94 commands at startup suggests setting one function at a time. So more exploring to do (unless somebody works out what the cpld is doing)
The difference between 24 and 94 codes is that 94 codes reload the EZUSB state machine controlling the GPIF. I have little evidence to prove it as of yet, but I wonder whether such radical tinkering with the hardware on the fly is the source of the bugginess in their software.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version