Full support for Sainsmart DDS120

[alimoche]

There is an offset between the vertical position of the trace and the channel marking CH1 in DDS120, please see screenshot, this might be related or be the same as bug #39 but it is already closed.
I would expect that the channel marking would be at the base of the trace as in the images shown in the readme.

[Ho-Ro]

There are two possibilities to get offset and gain calibration values:

1. Read the *.conf file
2. If this file is not available or contains no valid data the factory (or user) calibration values of HANTEK6022 are read from EEPROM.

I suspect that the DDS120 firmware does not support the reading of EEPROM content, so reading of calibration values failed and uninitialised memory content was used.

[alimoche]

I tested the fix with v3.0.3 and it seems to be working very well, thanks a lot. In the terminal window, however, it still says "Couldn't get calibration data from oscilloscope", it might be a different problem but I could help by testing any new firmware or patch.

[alimoche]

I suspect that the DDS120 firmware does not support the reading of EEPROM content, so reading of calibration values failed and uninitialised memory content was used.

If it is using the sigrok opensource firmware then this is what they implemented
https://sigrok.org/wiki/SainSmart_DDS120/Info#Vendor_firmware

[alimoche]

there is also some additional information but about the vendor firmware that you might already know, but just in case it might be useful here
http://www.360customs.de/en/2014/10/usb-oszilloskop-sainsmart-dds120-2-kanal-20mhz-50msps-buudairocktech-bm102/

[Ho-Ro]

OpenHantek6022 tries to read calibration data from the EEPROM and as the sigrok firmware for DDS120 does not support EEPROM reading it fails and informs you about this, but this is an info/warning message and not an error. Also as the DDS120 has own firmware in EEPROM (in this case a so called big EEPROM (capacity > 256 Byte with different 16 bit addressing mode compared to the small Hantek EEPROMs capacity <= 256 Byte, 8 bit addressing). Therefore it is not possible to store calibration values in EEPROM in a consistent way and without destroying the original firmware.

Some more details:
The Hantek6022 has factory offset calibration values stored in the small EEPROM (capacity <= 256 Byte) read more. Further calibration values (gain calibration as well as sub-sample offset correction) can be written with my calibrate.py tool.
Getting the correct calibration takes tree steps:

1. On detecting a scope the according ~/.config/OpenHantek/*.conf file is read and applied to specification->voltageScale and specification.voltageOffset.
2. On opening the device the EEPROM calibration values are read into controlsettings.calibrationValues, if this fails the message is shown.
3. On sampling data the calibration values are used to correct offset and gain. If the values from step 1 (specification->voltage...) are valid they take priority over the values from step 2 (controlsettings.calibrationValues).

Root cause of #69 was that there was no valid *.conf available so the values from step 2 should be used. As the reading from EEPROM failed the (unpopulated) calibration structure controlsettings.calibrationValues was used. My correction was to invalidate this structure in case of read errors.

    memset(controlsettings.calibrationValues, 0xFF, sizeof( CalibrationValues ) );

I checked the sigrok firmware that your scope uses and this FW doesn't support the EEPROM. So you must use the config file to compensate offset and gain error and live with this (not critical) info message.

[alimoche]

The Hantek6022 has factory offset calibration values stored in the small EEPROM (capacity <= 256 Byte) read more. Further calibration values (gain calibration as well as sub-sample offset correction) can be written with my calibrate.py tool.

I installed Hantek6022API-2.06 and made small modifications to be able to run calibrate_6022.py (attached file), as the reading of EEPROM is not supported, first I run openhantek to load the open source firmware and then patched and run the python tool. The offsets look fine, however, the gains computed with the tool don't work well in my case (maybe because it is not for DDS120), e.g.

ch0\500mV=1.2159
ch1\500mV=1.1885

whereas if I compute the corrections manually (taking the DC average from the gui) I get better results, e.g.

ch0\500mV=1.0414
ch1\500mV=1.0067

Without the corrections, the error is relatively small for high voltages (<5%) but it could be as large as 15% for lower voltage ranges (20-50mV), in any case, it works quite well, thanks a lot!

calibrate_dds120.txt

[Ho-Ro]

Hi, thx for providing this info. The observed discrepancy between the automatic gain and your manual gain is caused by the different analog front end hardware of the 120 compared to the 6022.
This difference can be seen in modelDSO6022.cpp:

// Define the scaling between ADC sample values and real input voltage
// Everything is scaled on the full screen height (8 divs)
// The voltage/div setting:      20m   50m  100m  200m  500m    1V    2V    5V
// Equivalent input voltage:   0.16V  0.4V  0.8V  1.6V    4V    8V   16V   40V
// Theoretical gain setting:     x10   x10   x10   x5    x2     x1    x1    x1
// mV / digit:                     4     4     4     8    20    40    40    40
// The real input front end introduces a gain error
// Input divider: 100/1009 = 1% too low display
// Amplifier gain: x1 (ok), x2 (ok), x5.1 (2% too high), x10.1 (1% too high)
// Overall resulting gain: x1 1% too low, x2 1% to low, x5 1% to high, x10 ok
// The sample value for full screen (8 divs) with theoretical gain setting
specification.voltageScale[0] = { 40 , 100 , 200 , 202 , 198 , 198 , 396 , 990 };

... and modelDDS120.cpp:

// This data was based on testing and depends on divider.
// The sample value at the top of the screen with gain error correction
specification.voltageScale[0] = { 64 , 160 , 160 , 155 , 170 , 165 , 330 , 820 };

calibration_6022.py uses the same (theoretical) gain error for the four different gain steps (10/10/10/5/2/1/1/1) of 6022:

# theoretical gain error of 6022 front end due to nominal resistor values (e.g. 5.1 kOhm instead 5.0)
# these values are considered also in OpenHantek6022
error = ( 1.00, 1.01, 0.99, 0.99 ) # gainSteps 10x, 5x, 2x, 1x

while the 120 uses five different gain steps (20/20/10/5/2/1/1/1)
models/modelDDS120.cpp:

specification.gain = {  // ID, HW gain, full scale voltage
    { 20,  0.16},        // 0     20         160mV =  20mV/div
    { 20,  0.40},        // 1     20         400mV =  50mV/div
    { 10,  0.80},        // 2     10         800mV = 100mV/div
    {  5,  1.60},        // 3      5          1.6V = 200mV/div
    {  2,  4.00},        // 4      2          4.0V = 500mV/div
    {  1,  8.00},        // 5      1          8.0V =    1V/div
    {  1, 16.00},        // 6      1         16.0V =    2V/div
    {  1, 40.00}         // 7      1         40.0V =    5V/div
};

These lines should be fixed:

# corresponding amplifier gain settings
gains = ( 10, 10,  10,   5,   2,    1,    1,    1 )
# available amplifier gains
gainSteps = ( 10, 5, 2, 1 )

The firmware flashing can also be incorporated in your modified calibrate_dds120.py similar to upload_firmware_to_DSO2020.py:

scope = Oscilloscope(0x8102,0x8102)
scope.setup()
scope.open_handle()
scope.flash_firmware_from_hex( "dds120-firmware.hex" )
scope.close()

scope = Oscilloscope(0x1d50, 0x608e)
scope.setup()
scope.open_handle()
...

[alimoche]

Hi, I replaced lines L122-125 with

# corresponding amplifier gain settings
gains = ( 20, 20,  10,   5,   2,    1,    1,    1 )
# available amplifier gains
gainSteps = ( 20, 10, 5, 2, 1 )

and L215 with

error = ( 1.00, 1.00, 1.01, 0.99, 0.99 ) # gainSteps 20x, 10x, 5x, 2x, 1x

but still I'm getting similar results, maybe there are some more parameters specific of DDS120 that are in OpenHantek but not in the Hantek6022API-2.06 that are needed for reading or correctly setting the parameters of DDS120 with the python tool, in any case, the manual config works very well

[Ho-Ro]

You must adapt the values in line 215 to your settings according specification.voltageScale from above for your scope, e.g. 1st gain = 64/40 (or 40/64, :) just try which way round) and so on.
The 6022 needs 40 digits difference from bottom to top of screen i n the 20mV/div range, the 120 needs 64 digits in the same range.

[alimoche]

I changed line 215 with

error = ( 1.60, 0.80, 0.77, 0.86, 0.83 ) # gainSteps 20x, 10x, 5x, 2x, 1x

and now it gives similar values to the manual calibration, e.g.

ch0\500mV=1.0521
ch1\500mV=1.0283

except for 20mV and 50mV where sometimes it gives no value or the values are too large. Comparing with the value obtained manually, 1.60 should be around 0.77. The file calibrate_dds120.txt contains the modifications of calibrate.py script except the part of the firmware loading.

[alimoche]

Alternatively, this is how I obtained the correction values "manually":

1. Create a new file ~/.config/OpenHantek/modelDDS120.conf or use the file created by the calibrate script as template :

[offset]
ch0\20mV=0
ch1\20mV=0
...
[gain]
ch0\20mV=1.0
ch1\20mV=1.0
...

2. Read the offset from the scope screen for both channels and all voltage ranges and change the sign, -1 worked for me, or use the values obtained with the calibrate script (only one or two entries turns out to be -2)

3. Save the file and restart the scope

4. Calculate the gain correction for both channels and all voltage ranges: set your voltage supply (e.g. a voltage divider with a potentiometer) to a value that is on the middle of the scale and measure it with a multimeter, Vin, and then take the DC average given by the scope on the bottom of the screen, Vout, the correction factor would be Vin/Vout

5. Save the file, restart the scope and compare the values with the multimeter to check that they are correct. If you need to change some entry, you need to revert the value to 1.0 and restart the scope.

[Ho-Ro]

The 1.60 value must be of course half as big (0.77 looks good), because 6022 has gain=10 and 120 has gain=20 in the two lowest ranges:
error = ( 0.77, 0.80, 0.77, 0.86, 0.83 ) # gainSteps 20x, 10x, 5x, 2x, 1x
Otherwise you'll fall out of the valid range, this is why the calibration gives no result, check this code snippet:

    if raw1 > 250 or value1 < 80 or value1 > 120: # overdriven or out of range
        gain1[ gain ] = None # ignore setting, no correction
    else:
        gain1[ gain ] = target / value1 # corrective gain factor
    if raw2 > 250 or value2 < 80 or value2 > 120: # same as for 1st channel
        gain2[ gain ] = None
    else:
        gain2[ gain ] = target / value2

BTW: did you check the latest pre-release? I made some improvements for the calibration output especially for the 120 (now you can select 100Hz, 1kHz, 10kHz and 50kHz, this is all the sigrok FW delivers). Also the marker handling got two new features: double click (left mouse button) draws two nearby markers that will give zoom=100, while right double click moves the markers out of the way to left and right margin.

[alimoche]

The 1.60 value must be of course half as big (0.77 looks good), because 6022 has gain=10 and 120 has gain=20 in the two lowest ranges:

ok, very good, this explains why it didn't work and the value 0.77 ~ 0.80 = 64/40/2 = 160/100/2 (so maybe 0.80 should go in the script). This fixes the issue, the changes could be integrated in your script with an additional command line parameter, e.g. --model DDS120 (default: Hantek6022) or else with the modifications from here or else with the manual calibration :)

BTW: did you check the latest pre-release? I made some improvements for the calibration output especially for the 120 (now you can select 100Hz, 1kHz, 10kHz and 50kHz, this is all the sigrok FW delivers) ...

I have just compiled and noticed that the calibration out frequency is twice the value reported by the scope, this can be seen in any of the two screenshots above, i.e. calibration out 1kHz, scope 500 Hz, is this the expected behaviour? for all the calibration frequencies the value reported by the scope is half (and less than 2V pp)

[Ho-Ro]

The voltage ist hardwired and fixed, the frequency is a bug in the sigrok firmware. I know what to change and will file an issue report/pull request.