Products > Test Equipment

SainSmart DDS120 & DDS140 USB Oscilloscope

<< < (8/84) > >>

ganzuul:
Behold!   :D

http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQFX2

If I'm reading this right, with GPIF the FX2 does achieve 96MB/s. That ought to mean 16MB/s headroom if we get 2 x 40MS/s x 8bits.

The links are broken, but this appears to be the same:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_build#Get-the-Source-Code

And under http://files.ettus.com/binaries/maint_images/uhd-images_003.007.003-release.tar.gz
We find /uhd-images_003.007.003-release/share/uhd/images/usrp1_fw.ihx

In the source tree at uhd/firmware/fx2/usrp1 there appears to be files which created the firmware. Going this route might be much easier than trying to reverse engineer the original binaries. This is looking very promising. =D

psynapse:
A lot can happen in a weekend when you are not watching!  There seems to be really major progress.  I've started looking at the DDS140 firmware,  which is pretty small (taking out the data blocks and interrupt vector tables, less than 3k)  .  Very few interrupts have service routines:-  reset, the two timers (which are basically just register reloads) and wakeup (One line of code).  Apart from that the USB and GPIO vectored interrupts are pretty largely null.  Nothing on the GPIO/FIFO.  For the USB Vectors only SOF, SUTOK, SUSPEND, USBRESET,HISPEED have ISRs .

Hope this helps steer the folk looking at the USB protocol, such as it is.

Like everybody else , I am looking to the USB side of things for most of the solution. I am exploring the internals simply to try and find a way to get a real one shot trigger built into hardware. (eg stop the fifo a certain number of clock cycles after an external event)

Interesting notes on the AD interleave.  Yeah I've seen this approach elsewhere too; RIGOL use a 10 way interleave with 5 ADs to get 1GHz!  Has anybody scoped the two clock pins on the AD to see if they are complimentary phases?  A quick no go verification is to see if the two clock pins are shorted together!

psynapse:
All,

Sorry, I need to read the board more carefully.

Donut6

I had not spotted the 200Mhz, one probe mode!  Thanks.  That will be the clock interleave .... although how they do it with a 80Mhz Crystal I don't know ;)


Ganzuul,

Apologies, you too spotted the RIGOL. And yes the GPIO functioning as the port to FIFO will run up to 96Meg .... So for the DDS120 good news.  For the DDS140 I think the max is 80x2Meg and hence the onboard RAM ..... but I suspect that is where my problem lies  ... I think that the RAM functions as a poor mans FIFO,  it is filled under the control of the CPLD and then dumped into the regular FIFO, leading to regular periods when the scope is blind.  I (well we DDS140 owners) can hope that the CPLD runs in two modes, either (at lower speeds) passing AD data straight to the true FIFO as per the DDS120 and just for higher speeds it directs the AD to the SRAM and then dumps the SRAM to the FIFO

Doctormord,

No I would not recommend trying the cross firmware load any more. It was a quick and dirty test (I am fond of those).  Perfectly feasible to reprogramme the EEPROM back and forward (using the Cypress utilities), but with the CPLD in circuit ....  And yes my guess was that the DDS120 resembled those logic analysers that are entirely boot loaded ... I was wrong

On the DLL front: Sainsmart make great play of the interface being open .... Just not as open as we would like?  Wish I could help more.

doctormord:
Sainsmart is not a great help in any way. They just rebranded hard-/software. The so called "SDK" is kinda useless. Beside this, they weren't able to supply a firmware dump to me.

DLL documentation would greatly help.

I would like to ask, how did you separated the firmware (interrupts, vectors, etc.)?

For the cross flash, I tried DDS140 fw on DDS120 hw, so no CPLD/FPGA harmed. :))

Regards doc

psynapse:
Doctormord,

Seperate out the vectors?  The old fashioned way, by eye!  Converted the hex dump from the eeprom to a Intel hex file (via a spreadsheet!), converted the Intel hex to a bin, diassemble the bin, eyeball the bin, knowing the default page zero map, trace the jumps by hand.  Find the "odd code regions" by eye, check that there are no dependencies in and out of those regions (except by reference as data) . Then use a text editor to substitute symbolic references for known hardware addresses and registers in particular.  Mind bogglingly slow, simple and boring.  The bigger challenge (now) is to interpret and comment what is there.  I am hoping to find the "case" statement associated with input gathered from the USB.  That way I hope that I can give you guys some idea what the box is expecting to see out of the back end of your DLLs.

The thing I do not understand well is the legality of it all.  To do so for my own benefit I believe to be completely legal .... to share it perhaps less so  ... to exploit it, certainly not.  So I hope that I will be able to give you help at the USB interface.  Which should marry up with what you, G & D are doing. 

But no promises, the brain is not as sharp as it was.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod