SainSmart DDS120 & DDS140 USB Oscilloscope

[merbanan]

F
The buffersize is now set correctly automatically, nice! But the 1k buffer glitch / restart / discontinuity still seems to be there, see attached screen shot. I believe that we need an updated firmware on the DDS120/140 to fix this issue correctly, so I'll try to get merbanan's firmware running with openhantek or pulseview.

M.

We can not get rid of these discontinuity glitches totally at higher sample rates as the usb bus is not fast enough to transfer all the data we need (we might get drops at <=24MHz also depending on the available IO on the used usb bus). What we can do is to lower the sample rate to match the signal frequency. That way we can have 1024 samples (or 2048 if we only use one channel) to describe the pulse shape. If we sample a periodic signal we need 5 cycles of the signal to always find a good triggering spot. Start in the middle of the buffer, find the triggering position forward and backwards. Translate the signal so it matches the previous triggering position. The result should be an always pleasantly looking waveform.

[mmark]

When starting pulseview, libsigrok will scan for usb devices registered to a driver. The hantek6xxx driver will try to load the firmware and after that it is go time. So if you are compiling everything yourself you need to get my 1 patch to libsigrok and build and install my firmware package.

FX2load should be able to manually load the firmware also. I did not test it myself but it should work in theory. Upon loading the firmware the device should renumerate as a new usb device.

OK, got your modified hantek6xxx firmware and libsigrok compiled on my Macbook. When I start Pulseview, the firmware seems to get uploaded to the DDS120, since the PID:VID changes from 0x8102:0x8102 to 0x6022:0x04b5 and the DDS120 device is now listed as a 'HantekDSO6022BE'

Pulseview shows that it found a Sainsmart DDS 120, but sadly I get an USB error 'sr: hantek-6xxx: Failed to submit transfer: LIBUSB_ERROR_PIPE' when I try to acquire data. Any idea why this could happen?

When I try to use the the unmodified OpenHantek with the DDS120 AFTER the new firmware was uploaded, it finds the device but I also get an error when OpenHantek tries to acquire data: "Couldn't get channel level data from oscilloscope".

@merbanan: What OS are you using?

[merbanan]

OK, got your modified hantek6xxx firmware and libsigrok compiled on my Macbook. When I start Pulseview, the firmware seems to get uploaded to the DDS120, since the PID:VID changes from 0x8102:0x8102 to 0x6022:0x04b5 and the DDS120 device is now listed as a 'HantekDSO6022BE'

Pulseview shows that it found a Sainsmart DDS 120, but sadly I get an USB error 'sr: hantek-6xxx: Failed to submit transfer: LIBUSB_ERROR_PIPE' when I try to acquire data. Any idea why this could happen?

When I try to use the the unmodified OpenHantek with the DDS120 AFTER the new firmware was uploaded, it finds the device but I also get an error when OpenHantek tries to acquire data: "Couldn't get channel level data from oscilloscope".

@merbanan: What OS are you using?

I am using Linux (Ubuntu 15.04). And from your output the firmware is loading fine. OpenHantek is probably trying to use the hantek vendor protocol which fails for whatever reason. I have no idea why pulseview wont work but I recall that I saw some bugs in the driver that might cause issues. Can you try with sigrok-cli ?

sigrok-cli -d hantek-6xxx --samples 2000

[merbanan]

Pulseview shows that it found a Sainsmart DDS 120, but sadly I get an USB error 'sr: hantek-6xxx: Failed to submit transfer: LIBUSB_ERROR_PIPE' when I try to acquire data. Any idea why this could happen?

I committed a fix for some issues I found. There is a very low chance your issue got fixed by my changes. But try it out and see if it changes anything.

[merbanan]

Coupling support in firmware and sigrok driver is implemented now.

[doctormord]

Nice!

Seems like someone messed up the DDS120 page at Sigrok (Hardware Section).

[merbanan]

I think I figured out how to get something like an external trigger working. Pin PE2 is connected to the 1kHz calibration pulse output. If we change the direction to an input we can use that as a trigger signal. The trigger signal then needs to set PA7 when you get a trigger condition. For some reason PA7 is connected to the RDY0 pin and the RDY0 signal enables the configured GPIF program 0. So if it would be possible to only run the GPIF program 0 once and then fetch the samples then we could realize this feature.

[doctormord]

Interesting find.

I somehow managed to implement a "PLL-loop" into the trigger, works quite good. (Actually not at full 48M speed)

I had a look into the original Software again, they got the same triggering problems from the scope data.

https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V2-SOURCE.zip
https://dl.dropboxusercontent.com/u/5641160/DDS120_OpenHantek_Trigger_V2.zip

CHANGES:
- Markerslidersteps 0.2 -> 0.1 of DIV - DONE
- Move Waveform by Triggerpositionslider - DONE
- Select triggervoltage in < 0.05V steps - DONE
- Make trigger more solid - DONE

[mmark]

Coupling support in firmware and sigrok driver is implemented now.

Nice!

I got it finally working on OSX (my Macbook is at 10.10.5) after banging my head against the table for quite a while. The problem seems to be that the USB bulk transfer size must be a power of two. So I had to change the define of FLUSH_PACKET_SIZE in src/hardware/hantek-6xxx/protocol.h from 2600 to 2048 and replace the line:

Code: [Select]


data_left += MIN_PACKET_SIZE; /* Driver does not handle small buffers. */
with:

Code: [Select]

uint32_t i;
for (i = 512; i < data_left; i *= 2)
;
data_left = i;
in src/hardware/hantek-6xxx/api.c in static uint32_t data_amount(const struct sr_dev_inst *sdi) around line 550.

After those changes, I can read valid data with sigrok-cli and pulseview. Changing the coupling seems to work as designed!

I'll try DrMords changes later tonight or tomorrow...

M.

[merbanan]

I got it finally working on OSX (my Macbook is at 10.10.5) after banging my head against the table for quite a while. The problem seems to be that the USB bulk transfer size must be a power of two. So I had to change the define of FLUSH_PACKET_SIZE in src/hardware/hantek-6xxx/protocol.h from 2600 to 2048 and replace the line:

Code: [Select]


data_left += MIN_PACKET_SIZE; /* Driver does not handle small buffers. */
with:

Code: [Select]

uint32_t i;
for (i = 512; i < data_left; i *= 2)
;
data_left = i;
in src/hardware/hantek-6xxx/api.c in static uint32_t data_amount(const struct sr_dev_inst *sdi) around line 550.

After those changes, I can read valid data with sigrok-cli and pulseview. Changing the coupling seems to work as designed!

M.

Can you send your changes as a github pull request so you get the proper attribution for this fix ?

[merbanan]

I've started adding more sample rates and some sample rates are possible to both have with a 48MHz clock or 30MHz clock. Am I correct in believing that a slower ADC clock might give slightly more stable samples?

[doctormord]

I would say it just gives less "noise" due to less samples. (But it's not getting better, just looks like that)

Oversampling, averaging and/or decimation is another/better approach.

[mmark]

Can you send your changes as a github pull request so you get the proper attribution for this fix ?

Done! I also changed the VID:PID of the Sainsmart DDS-120 FW from the Hantek VID:PID (0x04b5:0x6022) to something unique (0x8102:0xd120).

BTW: pulseview crashes on both Linux (without my changes) and Mac OSX (with my changes) when I try to record 10M samples or more. 5M works fine...

[MysticPixel]

So I read through the thread but there's been a lot of programs going back and forth, I'm not sure what I should be looking for software-wise if I'm considering picking one of these up.

Basically I just want something to check timings on uC projects. I have a Usbee (AX? older... it's like the DX but only 8 channels) but it just doesn't play nice with some ICD devices etc. Looking for something cheap but most importantly the software has to not be total rubbish. Honestly, vertical accuracy isn't too important for this app, I just need something that can reasonable capture signals, and my trusty Tek 2445 is starting to fritz... (also need something digital)

I'd be willing to spend the ~$90 US or so for a dds-140 but I'm kind of at a loss for what software is the best / most developed.

Anyone care to sum it up for newcomers to the thread? C'mon, pimp your badass programs and tell me which one I should be using! :-P

ninja edit: it looks like SanSmart has a Logic Analyzer add-on that's only another few $. Anyone tried it?

[lavajumper]

I'm with MysticPixel on this count. I got a DDS140, siggen and logic unit as a christmas present. The software crashes more than a drunken stock car, and I'm getting different readings off the signal generator between versions  v1.4 vs. v6 . (Seriously, 5 major version bumps in 4 months???)

I'm impressed with the work I've been reading about here, but having a hard time figuring out what needs done, what's been done, what the current files are.
I'm more than willing to help with the porting/dev of the QT part.

Is there a github?
What do we need to do to get this hardware running?

I'm not bitching, I'm trying to roll up my sleeves.

[merbanan]

Just a heads up. The sigrok stuff is now committed upstream.

http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=commit;h=ce1d0a869e4761d30b698b6bb1ea015a0470f09e

There are some more things I would like to add to the firmware but most of the focus will be on the driver side. Currently there is no calibration but that will eventually be fixed as I now have the proper hardware and tools to do it.

[doctormord]

With much thanks to Joe Vee,

there's some progress with the "OpenHantek DDS120".

* Version 0.3.1
* Support for SainSmart/Buudai DDS120 (mmark)
* Better support for SainSmart/Buudai DDS120 (CW)
* Trigger Support for DDS120 (CW)
* Markerslidersteps 0.2 -> 0.1 of DIV (CW)
* Select triggervoltage in < 0.05V steps (CW)
* Improve trigger stability by excluding false positive cases (JV)
* Added falling edge trigger support (controlled by GUI button) (JV)
* The other channel now use the same trigger position as the trigger source channel, ensuring that the timing relationship between the channels is maintained. Only the trigger source channel determine the trigger position. This is an important requirement for signals that are generally different (in shape and phase) across the channels. (JV)
* Eliminate the "rolling buffer" problem and fix the segmentation fault issue. (JV)
* Improvement in the robustness of rising/falling edge detection prior to locating the trigger position offset, especially, for slow signals (e.g 100ms, 200ms timebases). (JV)
* Keep the start of displayed waveform (trigger source channel) in level with the trigger position on the slider control. (JV)
* The trigger position sliders now work separately and only the trigger source channel controls the trigger position. (JV)
* The glitches (discontinuities) in the capture data recurring at around 2KB (combined byte count for both channels) boundaries seems to be a HW/FW limitation of the DDS120 that would be difficult to workaround. (JV)

I set up the sources on GitHub:

https://github.com/doctormord/OpenBuudai

Any commits are welcome.

[Ripman]

Version 1.3.1:

Changes:
- Based on Version 1.3 (found on DX)
- FFT optimization (update rate)
- Timing optimization
- Fixed some GUI glitches
- Longer timebases added again
- Antialiasing
- Translations
- Ability to change signal width (1-10px)

Bugs:
 

DDS120_V1.3.1.rar
http://www99.zippyshare.com/v/p14YpYdf/file.html

pw? dds120

Hello, I am new around here and I have a DDS140. Do you know if this modified version works for DDS140? I cannot seem to make it work, also if there is any more stable version of software. I have troubles getting Triggers (Normal/Single) to work sometimes. I am currently using this version from SainSmart 1.4 https://s3.amazonaws.com/Barsoom/Z0/Z00I0C0Z/Z00I0C0Z.zip

https://www.amazon.de/SainSmart-DDS140-Oscilloscope-Signal-Generator/dp/B00HD6F8HY/ref=sr_1_1?ie=UTF8&qid=1465221711&sr=8-1&keywords=DDS140

Many thanks!

[mjwx4p]

Hello,
i have an SainSmart DDS-120. My development environment is debian linux jessie.
i'm trying to use OpenBuudai as oscilloscope software, but whatever i try, i got the message that OpenHantek (OpenBuudai) don't find any Buudai oscilloscope. I'm not sure which information i have to give you, but as i said, i had complete compile OpenBuudai and the app is working. I had installed libusb-1.0.20 too. I have no idea what i have to do now. My next idea is to tell OpenBuudai which port it have to use, but don't know how. Have someone any experience with linux and OpenBuudai? Thanks for your help 

Marko 

[doctormord]

Did you set up the udev rules right?

[bianchifan]

Do you know if this modified version works for DDS140?

Yes, it doesn't work.

I have troubles getting Triggers (Normal/Single) to work sometimes.

That seems to be normal, triggers are not really working at all.

I set up the sources on GitHub:

https://github.com/doctormord/OpenBuudai

Any commits are welcome.

[mjwx4p]

here is my udev-rule (file 10-local.rules)

ACTION=="add",  SUBSYSTEM=="usb",  ATTR{idVendor}=="1111",  ATTR{idProduct}=="2222",  MODE="0666",  GROUP="plugdev"

If i list my usb devices, there is a weird entry for my oscilloscope:

Bus 003 Device 006: ID 1111:2222 Pandora International Ltd.

I have the same ID on the Windows 10 OS. But with the original driver (but only with the old version of it) the oscilloscope works, but only with the bad original software DDS-120 from sainsmart themself.
This is my oscilloscope definitely, cause i had tested it. If i unplug my oscilloscope the entry doesn't appear.
Do i need to patch the firmware? If yes, how?
Thanks for your help.
Regards
Marko

[doctormord]

Strange, the older ones always have 8102:8102 (pid/vid) do your firmware is different.

Check the code in openbuudai if the app is fixed to the older pid/vid combination.

[mjwx4p]

Hi,

Strange, the older ones always have 8102:8102 (pid/vid) do your firmware is different.

Check the code in openbuudai if the app is fixed to the older pid/vid combination.

that was it. Thanks. I think these strange VID:PID combination is a mistake and not normal. Pandora Industries Ltd. isn't a vendor who produced oscilloscopes. In the OpenBuudai code i changed the pid/vid to my requirements and OpenBuudai works now.
Damn, i have many jammings in my scope ( i want to trigger the code of a remote control), but this is normal, we are living here very close to radio mast of cellphone-provider, this is the reason of these jammings.

[doctormord]

It would be interesting if the firmware differs much to the one I have. Are you able to dump the firmware?