Products > Test Equipment
SainSmart DDS120 & DDS140 USB Oscilloscope
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: ---usb.transfer_type == 0x1
--- End code ---
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! :-/O
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:
--- Quote ---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:
--- End quote ---
Indeed, it always sends data from both channels, as i'd shown some posts before. :D
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version