Hacking the DSO2X1X

[morgan_flint]

Hello all, I've come to a dead end trying a "mini hack" (my Linux knowledge is very poor), so I'd like to ask for help from the Linux experts out there 

From the naming scheme of the screen capture files (dso_01_01_xx_yy_zz.bmp, where xx, yy and zz change with time) is easy to deduct that it's somehow based on an internal system real-time clock.

With this in mind, and using David's Script launcher, I wrote a simple script to read and alter the internal clock settings. After several iterations (some forms of the standard syntax of the date command didn't seem to work) I came to the following simple script, also based on one of David's example scripts:

Code: [Select]

# Delete existing time folder
rm -rf /mnt/udisk/Time
# Create new time folder
mkdir /mnt/udisk/Time
# System time before
date >/mnt/udisk/Time/date_old.txt
# Set time and date MMDDhhmmYYYY (month-day-hour-minute-year)
date 032918452022
# System time after
date >/mnt/udisk/Time/date_new.txt
#reboot was added to avoid power cycling
# If not included, the scope stops anyway and asks for resetting after "upgrade"
reboot
The output files date_old.txt and date_new.txt show that the script worked OK:
before

Code: [Select]

Thu Jan  1 00:10:51 UTC 1970(this shows the system starts on 00:00:00 01/01/1970, start point of Linux epoch)
after:

Code: [Select]

Tue Mar 29 18:45:00 UTC 2022
The problem comes at the end as, if I don't include the reboot, the scope stops there and asks for a system restart anyway, so the setting is lost and reset to 00:00:00 01/01/1970 

So the question is: Is there a way to exit the "upgrade" process without rebooting, or calling the reboot process at a point where the clock is not restarted?

You may ask: Why am I interested in this? Well, apart from the sake of it, I think it would be interesting to have the captures properly labeled, maybe not always, but maybe it's handy if you are going to document a testing process with a good number of them. Also, as you can see in the attached images, the file and folder properties (date) created or modified before the date and time setting appear as empty, while those created afterward have this information. This information also helps when searching the captures that, otherwise, would appear always at the end of date-sorted listings

Thank you very much!

P.S: Maybe with the PC "remote control" software is possible to set scope's internal time/date, but I haven't yet installed it

[DavidAlfa]

You can try this:

Code: [Select]

# Kill scope processes
pidof phoenix dbus-daemon | xargs kill -9

# Your commands here
date 032918452022

# Restart scope process
/dso/etc/boot.sh &
exit

That should restart the scope software (But not the system), avoiding the post-update lock.
Don't run the reboot command at the end of the script!

As far as I know there's little to do about it. The RTC is not implemented, so the system always starts at epoch time.

[morgan_flint]

Thank you, David.

It works a little better, as the scope continues to work after running the script, but the keyboard does not respond (curiously, it beeps when keys are pressed, but does nothing else, neither when knobs are turned).

Maybe another process (or processes) needs to be restarted?

[DavidAlfa]

Ah, I forgot.
Yes, the software locks the keyboard when updating.
I was never able to overcome this...
Better to use a boot script running in the background that reads the date from the USB.
Will this update later.

[DavidAlfa]

Edit: Final version?
- Final version
- Created UPK packages, Date daemon
- Store system and date file timestamps
- Force date update only when date file timestamp changed
- Update non-volatile system date every 1 minute to prevent excessive flash wear
- Restores last system date on boot

Date file:
Linux (Remember to run "chmod +x date.sh" to allow execution):

Code: (date.sh) [Select]

touch date
Windows:

Code: (date.bat) [Select]

type NUL > date

Or just create a file called "date" in any other way.

[morgan_flint]

Perfect!

Tested the "volatile" one. As you can see in the attached picture, the file "date" and the .bmp have the same date, and the name of the .bmp correspond to it (the capture was done seconds after the pen drive was mounted).

Just in case somebody falls in the same mistake as I did, I had to think for a minute about how to include the information in the "date" file, until I realized that it can be empty, as the daemon takes the info just from its attributes... you only have to create it, for example with David's scripts, but notepad is also useful (just open it, save it and the time and date attributes get refreshed).

Thank you very much, David!! I think this can help when documenting tests with several captures, but it's also interesting, for example, for having logs with their correct time and date attributes, so you don't have to remember when they were extracted. Not something you need to run every time you use the scope, but convenient under certain circumstances.

EDIT: the one I tested was the "volatile" one of the first version

[DavidAlfa]

Yes, just create the file in any way you want, the contents don't matter!
Made some modifications, as I realised you couldn't set an older date if for any reason you wanted so.
Now it also tracks the timestamp of the date file, updating the system date when it changes.
Made UPK packages and update FAQ.

[morgan_flint]

I've been using the first volatile version and it is working perfectly but, after installing the remote control program (2022 version at Keysight's web), I thought there might be a way to set time and date with SPCI commands.

After some googling, I found that the command SYSTem:TIME?, which doesn't appear in the SCPI manual for DSO2000 series, worked in my DSO2D10. But the proposed syntax for setting time with this comad, like SYSTem:TIME hh,mm,ss that I found in those searches didn't work. After a more specific Google search, I found the SCPI Remote communication control manual for DSO4000BC, where SYSTem:TIME? was explained on page 78, along with the SYSTem:SET:TIME command. So I tried SYSTem:SET:TIME yy;MM;dd;hh;mm,ss; (the latest semicolon is mandatory) and it worked also for my DSO (see attached capture).

Later I saw these commands were included in the list posted by David in this thread, so if there are more commands in that list that are not documented for DSO2000 series, the DSO4000 manual might be of help.
 

[DavidAlfa]

The "little" issue is that you need a computer to fix the time everytime you boot the dso...

[morgan_flint]

Totally true... although you also need a computer to create the "date" file, but at least you don't need to launch the IO libraries and connect the rear USB.

Really, the best solution would be to add one of those el-cheapo I2C real-time clocks connected to the I2C bus (maybe the best point to attach it would be to pins 5 and 6 of U9, as the MCU and FPGA pins are too small), read it on startup and set the clock accordingly.

I've used those modules in the Arduino environment, but I don't know if the onboard Linux would have the resources to read it, or if a small program would have to be written specifically for that... I have some of those on hand, so I could try and report if somebody else can provide the software part (I don't have the knowledge to do it myself ).

[DavidAlfa]

Perfectly possible, the i2c bus can be accesed from the shell.

Edit:
I ordered a DS1307 for testing.
Hardware-wise, all it should require is soldering VCC/GND/SDA/SCL.
The module EEPROM might need removal or modding if matching the in-board EEPROM address.

[morgan_flint]

Hello!

I already have that module, and also this one and this one, these two based on a different chip (DS3231, supposedly more precise), but for this application, I imagine all of them are equally valid.

As you said, the first one also has a 24C32N EEPROM. Pins 1-3 are attached to GND, so EEPROM's address is 0x50, the same as the DSO's EEPROM, so definitively it'll be necessary to remove it or modify the module connecting some of them to Vcc to change the address. The second one listed before also has EEPROM, but A0-A2 are pulled up (0x57) and provides solder bridges in the PCB to change the address easily Anyway, if had to buy specifically for this application, I'd probably go for the third one, with the smallest footprint, without EEPROM, and with a rechargeable battery. DS3231 also provides an internal temperature sensor readable from I2C (maybe we could also monitor MCU temperature for overclocking?).

Yesterday I opened the scope (again...) and took the opportunity to solder the wires for the I2C bus (attached photo). I had already soldered R49 and R52 for the serial port as you can see.

I ran your i2cdetect with the RTC connected and it was properly detected:

Code: [Select]

# cd ..
# cd mnt/udisk/Binaries
# ./i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

I see the existent Busybox has the hwclock command that maybe we can use to read the RTC after proper configuration. Crude test of the command shows where it's expecting missing configuration data:

Code: [Select]

# hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory
# hwclock --help
BusyBox v1.26.2 (2020-06-08 11:06:44 CST) multi-call binary.

Usage: hwclock [-r|--show] [-s|--hctosys] [-w|--systohc] [-t|--systz] [-l|--localtime] [-u|--utc] [-f|--rtc FILE]

Query and set hardware clock (RTC)

        -r      Show hardware clock time
        -s      Set system time from hardware clock
        -w      Set hardware clock from system time
        -t      Set in-kernel timezone, correct system time
                if hardware clock is in local time
        -u      Assume hardware clock is kept in UTC
        -l      Assume hardware clock is kept in local time
        -f FILE Use specified device (e.g. /dev/rtc2)
# ./busybox hwclock --help
BusyBox v1.33.1 (2021-06-06 18:01:19 CEST) multi-call binary.

Usage: hwclock [-swul] [--systz] [-f DEV]

Show or set hardware clock (RTC)

        -s      Set system time from RTC
        -w      Set RTC from system time
        --systz Set in-kernel timezone, correct system time
                if RTC is kept in local time
        -f DEV  Use specified device (e.g. /dev/rtc2)
        -u      Assume RTC is kept in UTC
        -l      Assume RTC is kept in local time
                (if neither is given, read from /etc/adjtime)

(as you can see, "native" hwclock and the one in your statically compiled busybox have different options)

I found this Adafruit's tutorial to install an RTC in the raspberry py where they use hwclock, but I'm afraid it'll not be easy to me to apply it to this case. As I said before, I'm not very skilled with linux... If you can help me with the configuration now that I have the hardware installed, in the meantime your module arrives, I'm willing to do any tests!

[DavidAlfa]

The command is there, but the kernel module isn't.
Would require a least a custom kernel device tree.
Suddenly I had some Vietnam flashbacks...

Hopefully there'll be an application capable of doing so over the raw i2c bus, by no way I'll be messing with the kernel, first because there's no source code and everything around Allwinner stinks.

Hantek should release the GPL sources, but of course they won't.

[morgan_flint]

I don't know if this is orthodox, but I tried i2cget and got the following:

Code: [Select]

# ./i2cget -y  0 0x68 0x00
0x00
# ./i2cget -y  0 0x68 0x00
0x05
# ./i2cget -y  0 0x68 0x01
0x06
# ./i2cget -y  0 0x68 0x02
0x01
# ./i2cget -y  0 0x68 0x03
0x01
# ./i2cget -y  0 0x68 0x04
0x11
# ./i2cget -y  0 0x68 0x05
0x04
# ./i2cget -y  0 0x68 0x06
0x22
#

According to the datasheet, address 0x00 is seconds, 0x01 minutes, 0x02 hours, 0x03 day of the week, 0x04 day of the month, 0x05 month and 0x06 year, The former dialog was today, Monday, April 11th at 01:06, so everything seems to correspond...

The RTC had been previously set on time with an Arduino.

Maybe a script to be called at boot could convert these data into the appropriate format to set the internal clock with "date". Not very elegant, but it might work 

[Nominal Animal]

I don't know if this is orthodox, but I tried i2cget and got the following:

You have already provided enough information for someone to take the existing i2cget and i2cset sources to get and set the system clock from such an I2C module.  You'll be limited to GPL2+ licensing, though, but I assume it is not a problem here?

(If I had hardware to test, I'd have posted an implementation here; it's such a simple thing.  I'd recommend setting the I2C address, and individual register numbers, as compile-time options, overridable at run time, for best results.  Compile it statically, so it can be run very early in the boot process.  Use clock_settime(CLOCK_REALTIME, &struct_timespec) to set the system clock.)

Do remember to set the RTC to UTC, and not local time.  Until we get rid of the Daylight Savings Time mess, that will make a huge difference.  Oh, assuming the installation does include the Timezone database.  If the device is ever connected to internet, you can use the NTP protocol and NTP pool servers (say, countrycode.pool.ntp.org) to obtain a very good approximate time (to within a small fraction of a second).

In Bash/Dash/Busybox sh,

Code: [Select]

#!/bin/sh
I2CGET="/bin/i2cget -y 0 0x68"
DATE="/bin/date"

Year=$[2000 + $($I2CGET 0x06)]
Month=$[0 + $($I2CGET 0x05)]
Day=$[0 + $($I2CGET 0x04)]
Hour=$[0 + $($I2CGET 0x02)]
Minute=$[0 + $($I2CGET 0x01)]
Second=$[0 + $($I2CGET 0x00)]

$DATE -u --set "$(printf '%02d%02d%02d%02d%04d.%02d' $Month $Day $Hour $Minute $Year $Second)"
although you might need to adjust the paths on the first three lines.

[morgan_flint]

Thank you very much, Nominal Animal!

Sorry for taking so much time to answer, but I've been struggling with it... Seems like the syntax in the DSO's linux is a bit different from what you proposed, it must be a simplified and/or non standard one. Here is what its finally working:

Code: [Select]

#!/bin/sh
 I2CGET="/bin/i2cget -y 0 0x68"
 DATE="/bin/date"
 Decade="0x20"
 Year=$($I2CGET 0x06)
 Month=$($I2CGET 0x05)
 Day=$($I2CGET 0x04)
 Hour=$($I2CGET 0x02)
 Minute=$($I2CGET 0x01)
 Second=$($I2CGET 0x00)
 $DATE -u --set "$(printf '%02x%02x%02x%02x%02x%02x.%02x' $Decade $Year $Month $Day $Hour $Minute $Second)"
#

You were proposing MMDDHHmmYYYY.ss for the "date" argument, and according to the help in the command it should work:

Code: [Select]

# date -?
date: invalid option -- '?'
BusyBox v1.26.2 (2020-06-08 11:06:44 CST) multi-call binary.

Usage: date [OPTIONS] [+FMT] [TIME]

Display time (using +FMT), or set time

        [-s,--set] TIME Set time to TIME
        -u,--utc        Work in UTC (don't convert to local time)
        -R,--rfc-2822   Output RFC-2822 compliant date string
        -I[SPEC]        Output ISO-8601 compliant date string
                        SPEC='date' (default) for date only,
                        'hours', 'minutes', or 'seconds' for date and
                        time to the indicated precision
        -r,--reference FILE     Display last modification time of FILE
        -d,--date TIME  Display TIME, not 'now'
        -D FMT          Use FMT for -d TIME conversion

Recognized TIME formats:
        hh:mm[:ss]
        [YYYY.]MM.DD-hh:mm[:ss]
        YYYY-MM-DD hh:mm[:ss]
        [[[[[YY]YY]MM]DD]hh]mm[.ss]
        'date TIME' form accepts MMDDhhmm[[YY]YY][.ss] instead

But, although if you issue the command manually it's OK, when doing it from the script it only seems to accept YYYYMMDDhhmm.ss 

Also, I had to find a workaround for another problem I found when using your script:

Code: [Select]

# Year=$[2000 + $($I2CGET 0x06)]
/bin/sh: +: not found
#

Apparently, it doesn't like the "+" sign in the definition... I don't know if all these issues are my fault for not understanding well the environment or if they were due to particularities of this specific linux implementation, or a mix of both 

Finally, I had to use %02x in the format instead of %02d; this is because, although the registers are i2cget like hexadecimal, in fact, according to the datasheet, "The contents of the time and calendar registers are in the binary-coded decimal (BCD) format", so when i2cget returns 0x22 for minutes it doesn't mean the actual minutes are 34, but 22.

After I got a working script, now I had to get it running at boot time. The tutorials I found on internet (update-rc.d scriptname defaults after copying the script in /etc/init.d) didn't work, as update-rc is not a valid command here... Finally, studying David's example and the existing scripts in /etc/init.d, I could make it work creating a script named "RTC_Script" with the code at the beginning of this post in /usr/bin, and another script in /etc/init.d calling it with the following content:

Code: [Select]

#!/bin/sh
 /usr/bin/RTC_script &
And now finally the scope gets the correct time and date from the RTC module after booting!!

Thanks a lot to all of you for your help!

Now I'll try to do the opposite: setting the RTC module from the USB pen drive in case it lost time, probably with a similar approach as David's in the aforementioned post (disconnecting it from the scope and setting it with an Arduino doesn't seem an easy method...)

[DavidAlfa]

Try

Code: [Select]

Year=$(( 2000 + $($I2CGET 0x06) ))

[KF6BL]

I wanted to drop in just to say THANKS for everyone who has worked on this hack. I just received my 2C10 today which I purchased from Amazon. My intent was to at least upgrade to  2C15 if the AWG parts were not installed. But much to my excitement, we have a fully populated board. So the upgrade to 2D15 was accomplished.

The board's data was like the others I have seen:

DSO2D15_V1.7  2021.1.14

Utility screen showed:

Model: 2C10 (now 2D15)
Serial: CN213...
Software:  1.0.1.1.0(20210726.00)
Hardware: 003.002.001.000.000.000.000.000
Firmware: 3202

As per upgrade instructions I did a backup first before doing anything else. After the backup was done, I ran the script to upgrade the unit to 2D15 without upgrading the software (best not to tempt fate).

I am not a power user for O'scopes. As a Ham Radio Operator, my area of concern centers around using Spectrum Analyzer (TinySA) and Vector Network Analyzer (NanoVNA). Both have the ability to act as a signal generator up to 950MHz (TinySA) and 350MHz (NanoVNA), sine wave only. Other than that, the majority of the content in this thread is way above my pay grade.

I doubt that I will be adding any value to the discussion. However, I do have a few questions.

1. Since doing the upgrade, do I need to do another backup?
2. Should I upgrade to a higher level of software from the 2021.7.26? And if so, what would be the recommended version.
3. I read of a "dot test". How is that performed?

Again, thanks, kudos, bravo-zulu.

Brian D
KF6BL

[morgan_flint]

Try

Code: [Select]

Year=$(( 2000 + $($I2CGET 0x06) ))

Thank you, David. Although the script works well with the $Decade trick, I tried your suggestion so I could learn the correct syntax in this case.  It doesn't give an error as before, but gives a weird result instead:

Code: [Select]

# Year=$(( 2000 + $($I2CGET 0x06) ))
#printf $Year
2034
#printf '%04d' $Year
2034
# printf '%04x' $Year
07f2
#Year=$(( 1986 + $($I2CGET 0x06) ))
# printf $Year
2020
printf '%04x' $Year
07e4

Probably it has to do with the mixing of decimal and HEX in the sum. I'm not sure if the workaround of using 1986 instead of 2000 would work after 2029 (the return of i2cget would change from 29 to 30 instead of 2A), so as I don't think the scope is going to survive past 2099, my trick with $Decade will be enough (and, even if it survives, it won't be the case for myself ).

Thank you for the correct syntax, in any case, I hope it'll avoid me stumbling over the same stone again .

[DavidAlfa]

I got lost. What's exactly the issue there? None?

BTW, Bash also can work with hex by adding "0x" to the number, ex.

Code: [Select]

Year=0x16
Year=$(( $Year + 2000 ))

echo $Year
> 2022


[morgan_flint]

...
And now finally the scope gets the correct time and date from the RTC module after booting!!
...

No issues, David, the script at the beginning of that post is working OK, the comments were just to explain the things I had to change from Nominal Animal's code. I also managed to get it running at boot time, as I explained at the end of that (maybe too long) post, thanks to the example of your daemon.

I don't know if anybody else, apart from you and me, is willing to install an RTC in the scope, but I'll document it and add the info to the writable directory of your disk, so you can add it to the collection if you like. It's not anything you can't live without, but given the low cost of the module, might be attractive for somebody else.

Again, thank you and Nominal Animal for the help.

[.rpv]

...
And now finally the scope gets the correct time and date from the RTC module after booting!!
...

No issues, David, the script at the beginning of that post is working OK, the comments were just to explain the things I had to change from Nominal Animal's code. I also managed to get it running at boot time, as I explained at the end of that (maybe too long) post, thanks to the example of your daemon.

I don't know if anybody else, apart from you and me, is willing to install an RTC in the scope, but I'll document it and add the info to the writable directory of your disk, so you can add it to the collection if you like. It's not anything you can't live without, but given the low cost of the module, might be attractive for somebody else.

Again, thank you and Nominal Animal for the help.

Hi, I'm interested on install the mod.

[morgan_flint]

I've just uploaded the scripts and document for RTC installation to David's disk. They are here now, but I imagine David will move them to the appropriate directory later.

[DavidAlfa]

Thanks, it's great to not be the only one around this, it's really boring!
Will check the files for nudes before moving them!
And I'll change the credits: "Made by David Alfa from EEVblog" 

[morgan_flint]

I've uploaded a new version of the document, as I had forgotten to say that David's statically compiled i2ctools had to be copied in the scope. I have also updated the "do_other_update" script to do it. I'm copying them to /bin, maybe it would have been better to copy them to /usr/bin, the same place as the scripts... David, if you think it should be done like that, please tell me or modify them yourself.

Also, I've tried the following script to set the RTC from the system time and date:

Code: [Select]

#!/bin/sh
 I2CSET="/bin/i2cset -y 0 0x68"
 DATE="/bin/date"
 echo
 echo "Setting RTC time and date from system clock"
 $DATE
 $I2CSET 0x06 "$(printf '%s%02d' "0x" $($DATE +%y))"
 $I2CSET 0x05 "$(printf '%s%02d' "0x" $($DATE +%m))"
 $I2CSET 0x04 "$(printf '%s%02d' "0x" $($DATE +%d))"
 $I2CSET 0x02 "$(printf '%s%02d' "0x" $($DATE +%H))"
 $I2CSET 0x01 "$(printf '%s%02d' "0x" $($DATE +%M))"
 $I2CSET 0x00 "$(printf '%s%02d' "0x" $($DATE +%S))"
 
 echo

It seems to work OK, but I'm not still sure about the best way to call it. Probably, including it into David's date daemon would be the best option, but in this case the daemon would also have to be modified to remove the writing to EEPROM, as having the RTC it's not needed (I still keep David's first "volatile" version).