Products > Test Equipment
SainSmart DDS120 & DDS140 USB Oscilloscope
doctormord:
--- Quote from: psynapse on October 16, 2014, 12:54:30 pm ---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)
--- End quote ---
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.
--- Quote from: psynapse on October 16, 2014, 12:54:30 pm ---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.
--- End quote ---
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. :-+ :phew:
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. :scared:
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.
ENCB 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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version