Products > Test Equipment
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: --- // 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)
--- End code ---
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:
--- Quote from: ganzuul on October 21, 2014, 10:15:33 pm ---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.
--- End quote ---
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: ---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
--- End code ---
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.
--- Quote from: psynapse on October 21, 2014, 11:58:32 am ---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.
--- End quote ---
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. :D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version