SainSmart DDS120 & DDS140 USB Oscilloscope

[doctormord]

"Because we can." 

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

    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();

The rest is just libusb code

Code: [Select]

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;
}

And to read the scope FIFO buffer:

Code: [Select]

        r = libusb_bulk_transfer(scope_handle, 0x2 | LIBUSB_ENDPOINT_IN, scope_data, sizeof(scope_data), &transferred, 1000);

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.

[doctormord]

Doctormord:
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!

Hi psynapse,

at first i'm looking for a working/better software solution. At second, it would be nice to maybe implement the functionallity i had coded once for my Rigol DS1000 series scope. (Datalogger)



@Donut6:

Is there any way i can test/explore something on my DDS120 yet? (Codes, Commands, Responses)

Edit:

I set up Wireshark + USBCap to see some magic and i really wonder about the fact that an amplitude of "zero" -> 0V is encoded as 0x82 in the stream. So when using the scope in DC-coupled mode, the effective resolution is only 7 bit.

Both channels open, no signal:

Code: [Select]

No.     Time           Source                Destination           Protocol Length Info
   6076 647.832144000  1.2                   host                  USB      65563  URB_INTERRUPT in

Frame 6076: 65563 bytes on wire (524504 bits), 65535 bytes captured (524280 bits) on interface 0
USB URB
    USBPcap pseudoheader length: 27
    IRP ID: 0xffffffff86746be8
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)
    IRP information: 0x01, Direction: PDO -> FDO
        0000 000. = Reserved: 0x00
        .... ...1 = Direction: PDO -> FDO (0x01)
    URB bus id: 7
    Device address: 1
    Endpoint: 0x82, Direction: IN
    URB transfer type: URB_INTERRUPT (0x01)
    Packet Data Length: 65536
    [bInterfaceClass: Unknown (0xffff)]
Leftover Capture Data: 828283828382828283838282828283838382828282828282...
Data is formated as CH1,CH2,CH1...
where 0x82 is "min_amplitude" and 0xFF is "max_amplitude" at DC-coupling. AC-coupling would (as expected) be 0x00-0xFF.

Data input compared to timebase (tested with Rocktech software version):

Code: [Select]

Timebase Samplerate dpps Size
50ns-1us 50MHz 10 1024
4us 2.4MHz 10 2048
20us 2.4MHz 10 4096
200ns 2.4MHz 5 65536
500ns 2.4MHz 5 65536
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
*Data-request-polling is set to 200ms (5rps), response (dpps - data packets per second) from scope lags behind.

The SainSmart software version has changed polling-rate/packet-size. I.e. with 10ms timebase polling rate is now 100ms with response times 70/200ms and 32k datapacketsize (compared to 64k at the Rocktech software), so this is running totally async. (out of control)

Shown here: (SainSmart 10ms timebase):




DDS120

Control Settings
24,00 CH1 to AC
24,08 CH1 to DC

25,00 CH2 to AC
25,01 CH2 to DC


94,11 240kHz (1ms to 2s)
94,01 2.4Mhz (4us to 2ms)
94,10 50Mhz (50ns to 1us) <-- would guess, it's 48Mhz real sampling rate

33,00 request data

CH1 Voltage setting:
22,08 50mV
22,04 100mV
22,00 200mV
22,06 500mV
22,02 1V
22,02 2V
22,02 5V

CH2 Voltage setting:
23,20 50mV
23,10 100mV
23,00 200mV
23,12 500mV
23,02 1V
23,02 2V
23,02 5V

So no PGA scaling, same resolution for 1V/2V/5V which corresponds to 6/7/8Bit, or 20mV/Step in AC-mode.

No more codes avail, so no CH1/CH2 on/off, no trigger settings.

Some signal generator codes:
62,00 square wave output
60,00 sine wave output
61,00 triangle output

Some misc codes:
34,01 enable logic analyzer mode
34,00 enable scope mode

I somehow captured data in logic analyzer mode (with the SainSmart software provided). There were a bitpattern shown when switched back to scope-mode, but somehow the software got f*cked up then. 

Using the old Rocktech release, Logic analyser is working, readout is done on CH2. (So hardware.addon with some weak-pulldowns might be possible to implement)

Maybe "94,10" (Rocktech) vs. "94,01" (SainSmart) at initialisation is doing some magic here. (See below)

First time running (using START button) with default settings (Rocktech Version):
31,00 SET ISOCH DELAY
24,08 CH1 to DC
25,01 CH2 to DC
94,10
22,02 CH1 1-5V
23,02 CH2 1-5V
90,01; 90,02; 90,05; 90,03; 90,06; 90,04
90,07; 90,08; 90,09; 90,0A; 90,0B; 90,0C; 90,0D; 90,0E; 90,0F; 90,10; 90,11; 90,12; 90,13
94,10
22,02 CH1 1-5V
23,02 CH2 1-5V

First time running (using START button) with default settings (SainSmart Version):
90,01; 90,02; 90,05; 90,03; 90,06; 90,04
90,07; 90,08; 90,09; 90,0A; 90,0B; 90,0C; 90,0D; 90,0E; 90,0F; 90,10; 90,11; 90,12; 90,13
94,01
22,02 CH1 1-5V
23,02 CH2 1-5V
24,08 CH1 to DC
25,01 CH2 to DC

For the DDS140 i got some more requests at:

34, 50, 63, 75, 76, 77, 78, 79, 7A, 7B, 7C, 7D, E7,  90, 94

Edit:

Due to some magic, i opened up some kind of calibration menu in the rocktech software.

Code: [Select]

#define  CHAN0_ZERO 132
 #define CHAN1_ZERO 128
 #define CHAN0_ZERO500mv 132
 #define CHAN1_ZERO500mv 128
 #define CHAN0_ZERO50mv 133
 #define CHAN1_ZERO50mv 129
 #define CHAN0_ZERO100mv 132
 #define CHAN1_ZERO100mv 128
 #define CHAN0_1V 205
 #define CHAN1_1V 0
 #define CHAN0_500MV 12
 #define CHAN1_500MV 154
 #define CHAN0_200MV 159
 #define CHAN1_200MV 165
 #define CHAN0_100MV 144
 #define CHAN1_100MV 151
 #define CHAN0_50MV 132
 #define CHAN1_50MV 137
 



To access, start BM102.exe
select "Oscilloscope + Signal Generator" from the menu
change to Signal-Generator window
press play button once (beside the number-buttons)
change back to "Osillagraph" window

Right then, all values are at 128 with no "zero adjustment", info box is empty.

Click "adjust" to set the defines.

Set both channels to "AC" and "ON"
Click "Start" button
Click "zero" button on the overlay menu
-> now the right column will filled up with values to be the ranges new "zero"
( #define  CHANx_ZEROyyMV)
Click "adjust" to set the #defines

Dunno what the scale button is doing so far, beside, it "scales" the signal on screen with the values from the left column. To get back, hit "adjust".

Everything setup in this menu is only valid for the current session. Nothing is saved in a file nor the scope.

[psynapse]

Doctormord

First, many thanks for the codes from the 120, I will do a compare and contrast.

Second some pure speculation, which might give you hope. Remember I do not have a DDS120 on which to check!

DC input.  The analogue front end is certainly buffered (protection and for the attenuator etc).  Most of the front ends I have seen will have a limited gain op amp acting as circuit protection.  The only sensible design decision will be that the output of the opamp rests around half of supply volts, obviously for AC, but also I suspect for DC. This would mean that your scope would measure +ve and -ve DC voltages, and hence rest half way up the digitising scale ...7F,80,81.

Datalogging. Even more speculation depending on the actual implementation in hardware/firmware of the DDS120.  As far as I can see at the moment, long period datalogging on the DDS140 (sic) will not be possible. It uses a standard RAM chip as buffer, controlled by a small CPLD. So it is either being written to by the A/D or being read from (indirectly) the host PC.  It cannot be doing both at the same instant. At low recording speeds, sure the CPLD could interleave reads and writes, but at 100Mhz no, and what hopes do you or I have about how clever the designers have been    So I would keep the faith with the DDS120. As far as I can see, at lower speeds (perhaps even 10Msps), the firmware may be clever enough to interleave FIFO reads and writes.  But that is unexplored at this time.  As a DDS140 owner, I have ordered a 10€ EZ-USB breakout board of the sort used for logic analysers.  My hope is to build an AD front end for that (sometime in the future)  ......EDIT, but having just looked at your wireshark traces, I agree the DDS120 seems a catastrophy, getting data when the host software feels like it.

Software.  Me and you both!  In fact everybody in this forum wants exactly that.  Donut6 seems to be storming forward on that front. And who knows, with an open interface, other groups might take up the challenge too, and we will be spoilt for software choice.  Me, I shall keep the faith with Donut6, I know the amount of work he is putting in.  So your contributions on command codes for the DDS120 make a real difference.

[doctormord]

Having the codes, the DDS120 might gets integrated (supported) into "OpenHantek":

http://www.openhantek.org/

Or "Open6022BE" from RichardK:

https://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/630/

ftp://ftp.pididu.com/OpenHantek/

[doctormord]

Well,  the polling might get better with a triggered signal. Haven't tried, was set up to freerunning all the time (No trigger).

This really needs to be adjusted.

[psynapse]

Doctormord,

Yes I agree, looking at your trace, you seem to have lost a data packet (which is quite acceptable under USB rules I believe)

I have looked at some of your codes on the DDS140, as well as photos of the DDS120.

DDS120:- I note that Port C is largely wired to the analogue front end. PC.0 to the AD encode pin, PC.1 not traced by me, PC.2 and PC.3 to one of the 4 to 1 multiplexors used as attenuators, PC.4 and PC.5 to the other attenuator.  This largely agrees with your findings, but there are a couple of anomolies.  For the DDS140 it is a mess.  Command 22 is sweet, it sets 2 bits on port B similar to the DDS120, but Command 23 tweaks just one bit in port E, and port B is connected to the CPLD .....  So the long and short of that is that I think those command codes correspond, broadly, but parameters will be different.

Commands 24 and 25 (with values 0 or 1) flip single bits in E (E.2 and E.6) according to the parameter.  E.6 at least goes to the analogue front end, so good reason to expect the same function there, but again different input parameters.

Command 34 seems to be a stop/go command.  34(1) executes the same code as 33.  34(0) inverts the two bits tweaked by 33.

Commands 76 through 7D (on the DDS140) store, bytewise, 16 bit reload values (and an alternative set) for timers 0 and 1.  I have yet to determine what the timers do, except for flipping bits E.0 and E.1 each time they overflow.

On the DDS140 , I am getting the idea that Port E, largely present on the expansion port, carries some control signals. Very tentatively E.0 and E.1 programmable clock signals, E.2 sampling in progress (active low) etc

BTW because E.2 is presented on the expansion connector of the DDS140, I may be able to use this as a sampling active indicator, and from there a sync to enable better triggering

[doctormord]

Doctormord,

Yes I agree, looking at your trace, you seem to have lost a data packet (which is quite acceptable under USB rules I believe)

The responses accumulate with time. The bunch of responses in the end is due to stopping the scope, like having 20 requests in 4s with 5 answered "in time", there will be 15 coming after when stopped.

I have looked at some of your codes on the DDS140, as well as photos of the DDS120.

DDS120:- I note that Port C is largely wired to the analogue front end. PC.0 to the AD encode pin, PC.1 not traced by me, PC.2 and PC.3 to one of the 4 to 1 multiplexors used as attenuators, PC.4 and PC.5 to the other attenuator.  This largely agrees with your findings, but there are a couple of anomolies.

What anomalies do you see here?

Regards,

doc

Edit:

I wonder, how the framesize is set for the different timebases? 

[psynapse]

Doc

Anomolies, perhaps none. And no slight intended!  As I said my speculation.  I see  (on a photo) PC.2 and PC.3 go to one of the 4 to 1 multiplexors used as attenuators, PC.4 and PC.5 to the other attenuator.  Any bit remapping is possible in the firmware, but if I was writing quick and dirty code My 22 codes for Attenuator CH 1 would be 0,4,8,C and my 23 codes for the other attenuator would be 0,10,18,20.  But as I say I have neither hardware nor software for the DDS120. You have ground truth in your hands

And to show how wrong I can be:- For reasons that completely elude me the E.2 bit shows perfectly the data acquisition window for the logic analyser (active low), but rests stubbornly high when getting analogue data!  And data acquisition in logic analyser mode is a nightmare, with the PC transfer and analysis time coming to 600mS per block .

As far as frame size in concerned, it seems completely fixed at the SRAM fill size.  But there maybe tweeks in the CPLD control that I have not seen yet

[doctormord]

Thanks for the reply, double checked to 22,23 commands, they're valid as shown previously.   

Regards,

doc

[psynapse]

database problems with the forum yesterday, my full reply lost 

All the 90 commands return a static parameter .... their meaning is lost, but I presume that they are product ID and device capabilities, so your assumption is very probably correct.

herewith the c90 return codes
call 1 send 85
call 2 send 87 back
call 3 send 6 back
call 4 return B2
call 5 return 7E
call 6 return B0
call 7 return B8
call 8 return 7A
call 9 return 7A
call 0A return 8B
call 0B return 7f
call 0C return 7b
call 0Dreturn 8E
call 0E return 84
call 00Fh return 88
call 10h   return 80
call 11 and 13h return 89
call 12h return 85

and the command 34 codes seem very plausible for the DDS140,  they play with the right hardware bits

commands 70 to 73 set up 16 bit variables in page zero.  At this stage the function of these variables is unclear.

command 94 uses the bottom 5 bits of the input parameter and resets the gpif state machine (responsible for bulk data transfers),  So yes to timebase setting, but perhaps something more?  I wonder whether one of the GPIF modes is capable of sustained data transfer (something you and I are both looking for)

Apart from the mystery E7 command what does that leave us with?  It will be interesting to see if Donut6 has enough to build a first shot linux based method of getting data from the scope.  When we know where the holes are, further charting will be possible

[ganzuul]

Great to see you guys making progress. I have just been running in circles. 

The GPIF could be promising for getting a sustained transfer...  I'm unsure of what can been be squeezed out from between the GPIF state machine/delay and the 8051, but having now discovered the link between matrix math, graph theory and state machines I remain optimistic. I vaguely remember some very simple coding schemes which result in various levels of compression...

Another idea: Put a resistor-divider between channel A and channel B to obtain more depth on a single signal.

ENC_B on both the DDS120 and the DDS140 are left floating. This makes me uncertain about the DDS140 getting 200Msps. I wonder if it might however be possible to make a hardware mod.

ED:
http://en.wikipedia.org/wiki/Template:Compression_methods

[psynapse]

Ganzuul

"ENCb is left floating" Is that by measurement or by looking at the photos? 

I had made the assumption that ENCb was directly connected to ENCa by straight extension of the PCB track under the device itself:- the ENCa and ENCb pins are directly opposite one another on the chip.  Next time I get the chance I will measire resistance between the two pins.  I would expect this for the 120, its lower sampling rates mean the both A/D can run synchronous.  I will be disappointed with the 140 if this is true, because it will mean that the two A/D are not run "phased" and the device will give nowhere near the claimed 200Msps.

The GPIF should be capable of sustained rates up to 10Msps, but I have asked somebody who has built a 10msps scope around the fx2 chip.  I await his reply.  Conceptually, his design is very close to the 120 (see http://www.triplespark.net/elec/analysis/USB-LiveOsci/ ) I also have an fx2 prototyping board ordered that will allow me to establish what the real situation is.

I await with interest your thoughts on graph theory and state machines, it may prove very useful.

Yes, if greater precision is needed,  the resistor chain would work well.

[ganzuul]

ACK! You're right. The trace is connected underneath. Today is not one of my more lucid days.

I'll take a little time and be more thorough with the state diagram thing. Markov chains appear to be good way to get a conceptual foot through the door on that subject though. https://charlesleifer.com/blog/building-markov-chain-irc-bot-python-and-redis/ really drives it home for those who need an intuitive, hands-on approach.

I'll say more, soon.

[psynapse]

All

Just had a quick and helpful reply from the guy who built the FX2 based scope that resembles the DDS120, to quote him

"Regarding data transfer: Back then when I did this USB scope
I used it to transfer data at 20 MBytes/s (2 x 10 MS/s) for
many seconds or even minutes with only occasional data loss.
Say, >90% that a some second long transfer had no loss. IIRC.

Computers were slower at that time (Athlon XP, single core)
and the type of chipset did matter. Most crucial was the right
type of software (e.g. fx2pipe) to handle the async IO."

I see those as really helpful and positive words.

[ganzuul]

20 MB/s might still be plenty, even if we get those only by reducing the encode rate. Positive indication indeed. =)



It appears that the purpose of two of the 8-bit multiplexers is to attenuate the analog input, so one can simply connect the two channels and set the relevant bits correctly to get deeper resolution.



The FX2 implements the following ECC:
http://read.pudn.com/downloads107/doc/439463/ECC%20Algorithm_Toshiba_v2.1.pdf
Princeton has decided some ECC schemes may be used for compression:
https://www.princeton.edu/~verdu/reprints/Lossless%20Data%20Compression%20Via%20Error%20Correction.pdf

The GPIF does operate at one instruction per cycle, and it uses 128 bytes to store its 'waveform descriptors'. These bytes are modifiable at run-time, but not quite on-the-fly.

Some words about graph theory: Graph theory appears to provide a theoretical framework for reducing the complexity of e.g. a circuit of logic gates while retaining its truth table. However, this process of reduction is pretty much the heart of a Turing machine; NP-completeness, Gödel's Incompleteness theorems, and optimization. Fortunately, humans brains with their neural networks are really good at optimization problems.
So, incredibly, I remain hopeful about squeezing more information through the 40MB/s max I have heard about!

[doctormord]

Could we do a simple bulk sample software on the current firmware yet?

Beside this, maybe the osciprime source could help to understand fx2lp firmware developing?

http://www.osciprime.com/?p=source

and

http://sigrok.org/wiki/Fx2lafw

The open source sigrok driver which implements logic analyzer functions with the help of:

https://github.com/djmuhlestein/fx2lib

[ganzuul]

It would make sense to make such a feature available to people who don't want to void their warranty.
The RTL-SDR samples up to ~2.56Msps without dropping packets and the DDS120 has a sampling mode of "2.4MHz", so copying the RTL-SDR's technique could be a good starting point.

I'll see what I can do. =)

[psynapse]

I really like experiments to back up theories and supposition, so herewith my finding on data acquisition on the DDS140.

The experiment was a simple one, count the number of write pulses arriving at the RAM each second.  If this number is equal the sampling rate, then there is no data loss. (Both the RAM and data path from the A/D are 16 bits wide)

Here are the findings ;

at 39ksps (80Meg/2048 =39.0625)

In alternate seconds 39070 samples written, in the other alternate seconds on average 35088 samples (approximately, because the sample window is not synchronised with the DDS140).

At 625ksps (80M/128)

an average of 321992 samples written per second.

Higher sampling speeds will have to wait for the ICs to build a pre-scaler.

The observed results fit almost perfectly the model that the DDS140 does 64k of samples, stops sampling and transfers the samples to the host.  On my bench machine (XP+3500Athlon) the total transfer and processing time is variable but averages closely to 100mS.

Why does this fit ?

For 39ksps, there is one second of pure,uninterupted, sampling, followed by ~0.677 second of further sampling and then data transfer,before restarting sampling.  The exact numbers are 1.677s of sampling 0.103s of transferring . Sampling every second, I will see either pure sampling or sampling plus a single transfer.

For 625ksps 321992samples corresponds to 4.9132 blocks to transfer per second, and an active sampling time of 0.515seconds, leaving 0.485seconds of transfer time. Again very close to 100mS per block transfer.

These measurements correspond well with wireshark observations

What does all this mean ?


In short, you cannot use the DDS140 to log data.  Even at low speeds when it would in principal be possible for correctly configured hardware to capture continuously the DDS140 does not.  I do not have a DDS120,  but as previously noted, the right firmware should make continuous low data rate acquisition possible on that device.
At 39ksps the DDS140 captures 95 % of data
At 625ksps the DDS140 captures 52 % of data
At 10Msps just 6.2 %
At "100" Msps around 0.65 % of data

So the DDS140 is useless as a datalogger, and single shot mode (for capturing transients) at 10Msps or above is like winning the lottery.

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.


Footnote :
One of my other reasons for « tapping » the write line is that it enables me to have a sampling active indication and even count where an externally triggered event will fall into the buffer.  Note by externally triggered, I mean that the DDS140 will trigger the event to be monitored, not the other way round.

Postscript:

I have just found that sometimes a stop from the sainsoft software stops USB transfer, but not data acquisition.  In this case the data sampling rates are steady at 39070 and 625116 samples per second.
This also seems to be linked to the software failing

[ganzuul]

Scope is DDS120. Sampling rate is 240kHz, time division 1ms, packet size is 65563B. It seems to insist on always returning data from both channels. Will the DDS140 agree to turning off one channel? The packets arrive at an average 0.2 seconds delay, with little variance except for a few outliers. "Delta time displayed" can be added as a column in Wireshark and it is populated with meaningful data when this filter is used:

Code: [Select]

usb.transfer_type == 0x1
I can attempt to attach my uC to some wires, if you'd like. My soldering has improved dramatically since I learned to keep my elbows close to my sides!   



Having studied the librtlsdr a little bit, it appears that they too use bulk transfer instead of isochronous transfer. This isn't because bulk is better, but because iso is poorly documented on the device. Preference for iso has been voiced on the mailing list, but they seem to have given up on it, deprecating the relevant 'asynchronous' code section of librtlsdr.
They also appear to be writing their own firmware into an EEPROM, somewhere...



I'm a little confused about how to put together what I'm reading in the FX2 TRM. Everything except iso is supposed to max out at 64 bytes of actual data per frame with huge swaths of padding, while iso utilizes the full 1023 bytes available to the frame. My confusion might be one of ISO-layers (different 'ISO', not 'isochronous') where the FX2 TRM actually talks about a lower level of abstraction when referring to frames, and Wireshark talks about a higher level of abstraction when talking about packets. If anyone knows more, please speak up. =)



I think I'm going to continue by figuring out how to make a custom firmware. What I'm reading is finally starting to make sense to me, and this chip is actually very commonly found in various devices. Since USB 2.0 isn't going away any time soon, programming the FX2 might be a decent professional skill to learn.

[doctormord]

The packets arrive at an average 0.2 seconds delay, with little variance except for a few outliers. "Delta time displayed" can be added as a column in Wireshark and it is populated with meaningful data when this filter is used:

Indeed, it always sends data from both channels, as i'd shown some posts before.

[ganzuul]

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.