Hacking the Siglent SDM3055 Bench DMM

[alexvg]

Hi,
I'm just copy-paste last news from my blog :

I've received stuffs to build the compute server needed to analyse all captured data from Siglent SDM3055 A/D converter (AD7190).
I'm also working on network/hosting/servers/emails due to massive increasing of internet attacks.
All these tasks take me long time.

About the new software for the Siglent SDM3055, the resampling implementation (power line sync) is not fully operationnal. But the first tests were very good (around 2 bits improvement over noise free bits).

[killingtime]

It's nice to see this project back on track.

As you have root access to the OS and are re-writing the GUI, a really useful feature would be a custom maths option, and the ability to display results in user definable units.

Use case: measuring the mV from a current shunt. Rarely do you see 1mV per A unless you carefully select the shunt design (just read the mV range in A otherwise). For a shunt that outputs 2.25mv/A (say) you could program the meter to divide the mV range by 2.25 and output to the display in A. Saves having to do the mental arithmetic.

We already have this ability for any meter with SCPI and a computer, but there's no reason it couldn't be done on the meter itself. Rigol have this facility on the 2000 series Oscopes, and R&S on their 1000 series Oscopes (and up), but it's hit and miss as to whether it's implemented or not. I guess manufacturers don't want us programming our own options that could be sold.

[maskedviperus]

I ordered a 3055 yesterday........are there any hw revisions over the years that could cause incompatibility?

Initially reading through this page I was skeptical when I saw the poll asking if people would pay for a firmware.  Even responded "no" to the poll  . But after seeing the youtube videos of what this thing looks like - Yea. Absolutely. On two conditions though....if you release the appropriate linux sources (keep your app layer closed), and if you provide a tool to backup/restore the original calibrations......not sure what the limitations are here, i know you couldnt provide the file but maybe even a tool that accepts an original firmware file to "go back".....Because if im paying for something - I'd be willing to pay a little bit more for it to be the complete package with the things I listed.....

Otherwise open a github and let us join in

[alexvg]

Hi.
I had a few weeks of break shared between my family and my job.
I've wanted to take this break to provide a better work now.

I've read all your private messages or commentaries.
I'll hope to provide you some answer in a near future.


Bye.

Alexia from France.

[bobxxlua]

Dear comrade, how are you? Are you alive? hope the coronavirus is defeated?
Any news? can you need help?

[alexvg]

Hi.
I'm working on the measurement processing.

Here you could find my latest results
" alt="" class="bbc_img" />

[Kleinstein]

The noise is a bit higher than for the 34470, but this is not such a surprise: the 34470 is a 7 digit meter and the SDM3055 is 5.5 digits only. In the 1000 V range the resolution is 10 mV for the display. So the noise level is well below the display resolution.

I think the higher noise is from a different (e.g. 1:1000 or maybe 1:500) divider. The divider can be the dominant noise source for the 1000 V and 100 /200 V range.

[alexvg]

I'm working hard "try-hard" to enhance my "1 PLC" measurement.

My best result is actually
std.dev = 364.9uV
span = 13547.5uV

Measurement settings :
- DMM at 1000V DC
- 2,5V with PDVS2mini
- 50HZ power-line

The Keysight 34470A at 1PLC (auto-zero during 43 mins) provides :
std.dev = 133.6uV
span = 1149uV

[Kleinstein]

The 1000 V range has a very hard stand to get low noise. Chances are the divider is 1:1000 (maybe 1:500) and the divider alone would have quite some noise. So a factor of Sqrt(10) higher noise compared to the meters that can use a divider 1:100 and 10 V range to follow is kind of normal.
There is a bit possible advantage compared to many other meters in that the AZ mode may still be able to do contineous sampling.
The fair comparison may be at a fixed reading rate of lets say some 25 readings per second. With the KS34470 (and many other meters in AZ mode) this would be 1 PLC. With the SD Chip based (and thus ADC with differential input) meters this may be already 2 PLC.

The RMS noise looks good, but the span is quite a bit larger. Is this in an non AZ mode ?

[alexvg]

Hi,
I cannot implement an « AZ mode » with the DMM Siglent SDM3055. Why ? Because I need to permanently and continuously resample source ADC data to 50 or 60Hz (the DMM doesn’t have power-line sync).
I’ve already tried to implement this AZ mode without a very good result, the integrated electronic could not provides enough feature. But I’ve tried… However the resampling always provides the better result !

Internal ADC have a clock rate variation of +/-4%, it's not very precise.
Ideally an PLL connected to the power-line could provide the perfect clock rate... But it's a dream.

I’m using the 1000V DC range because it is very hard to get good results. I try-hard, I work hard !

About the measurement of my processing. I really provide a 1PLC with 50 (or 60) measures per second. All PLC measurements provided with my processing have a settling time of 3ms.
Original Siglent software provides 800ms settling time in slow rate (5 values/sec),  80ms in middle rate (50 values/sec) and 26.7ms in fast rate (150 values/sec).

[Kleinstein]

Not having an extra AZ mode can happen with the SD ADC chips. The ADC chips internally often do some kind of chopping and have very little drift. If combined with a chopper stabilized input amplifier, there may very well be no real need for an AZ mode.
Given a 50 samples per second reading rate the RMS noise is not so bad.  The question is more the large span. So the noise seems to be not just white noise, but somewhat different, e.g. with some outliers. I may be worth looking at the noise in the time domain or look at the Allan varaiance. Resudual mains hum would cause a relatively small span compared to the RMS noise, so this is not the main ususpect.

With the usual higher order filters inside the SD ADC chips there is no real need for a PLL for the clock frequency. 4% tolerance for the clock would suggest an chip internal RC clock, which is not very good. With a higher order fitler this may still give a resonable mains hum suppression. Still a fixed crystal clock would be the best choice: good enough to get good mains hum suppression and low jitter compared to a PLL.
The higher order fitler at the ADC usually also comes with some settling time (e.g. like 60 ms). A very short settling suggest the simple averaging filter and thus not so good mains hum suppression - expecially with the only approximate frequency. It depends on the application which more is more suitable. So the 80 ms settling for the medium rate in the original SW may not be so bad.  Ideally I would like to have the choice of the filtering mode to use.

[2N3055]

Not having an extra AZ mode can happen with the SD ADC chips. The ADC chips internally often do some kind of chopping and have very little drift. If combined with a chopper stabilized input amplifier, there may very well be no real need for an AZ mode.
Given a 50 samples per second reading rate the RMS noise is not so bad.  The question is more the large span. So the noise seems to be not just white noise, but somewhat different, e.g. with some outliers. I may be worth looking at the noise in the time domain or look at the Allan varaiance. Resudual mains hum would cause a relatively small span compared to the RMS noise, so this is not the main ususpect.

With the usual higher order filters inside the SD ADC chips there is no real need for a PLL for the clock frequency. 4% tolerance for the clock would suggest an chip internal RC clock, which is not very good. With a higher order fitler this may still give a resonable mains hum suppression. Still a fixed crystal clock would be the best choice: good enough to get good mains hum suppression and low jitter compared to a PLL.
The higher order fitler at the ADC usually also comes with some settling time (e.g. like 60 ms). A very short settling suggest the simple averaging filter and thus not so good mains hum suppression - expecially with the only approximate frequency. It depends on the application which more is more suitable. So the 80 ms settling for the medium rate in the original SW may not be so bad.  Ideally I would like to have the choice of the filtering mode to use.

Maybe also an FFT of raw data to see if there are concrete frequencies present or histogram to see distribution.

[alexvg]

I have tried too many approaches without really relevant success.
The best result is the ADC running at 1200Hz or 4800Hz then I resample it at a frequency set by PLL locked to the power-line frequency.
The advantage of this method is to have a very large number of samples that can be processed in order to reject noise and get the best measurement value.
I've tried realtime multiple transforms (like FFT, MDCT / MDST, wavelet…) but the settling time is too high... CPU power needs is too high… and this reduce the final precision, a little… The processing of detecting and removing all unwanted harmonics is not very simple in realtime.
The processor in the DMM is not very powerful and I do not wish to apply a software overclock.

Also the AI processing is not possible, yet I thought about it and I would have liked to do it ...

In my latest advances I could provide 5.5 digits in 1000V DC range at 1PLC at 50Hz (or 60Hz) - You could look at my previous post with the measurement table.

" alt="" class="bbc_img" />
" alt="" class="bbc_img" />

[Kleinstein]

There are quite a lot of glitches / far off values in the curve. This may be some spike like background from mains. Another possible cause could be a transfer problem hat the relatively high data rate. The glitches look really bad and make the otherwise good looking curve hard to use.
Most of the glitches seem to be periodic with an slightly below 50 units cycle. What are the units ?

Using the high data rate and than adjust the sampling interval to the actual mains frequency is a nice idea. Getting averaging over a suitable length interval can get the lowest effective noise bandwidth, but the mains suppression depends on a good frequency match. The SINC³ filter of the ADC directly gives better hum suppression, but more sensitivity to white noise and longer settling.

I don't think one would need to do complicated math in the DMM. The main part is some kind of digital filtering, like the simple integration with an adjusted interval. Which fitler is best depends on the application and would ideally be more a user choice.

The more complicated analysis may help to find the source of the glitches and maybe decide on how to minize the effect.

[alexvg]

It's not possible to modify precisely the ADC sampling-rate  and the ADC frequency drift is very problematic.
The curve uses Hz (X) and dB (Y).

I use several complex methods (and maths) in order to approach a better measurement value vs simple average (+ internal ADC sinc3 or sinc4).

I've found the origin of the main glitchs (230Hz, 457Hz, 557Hz...) but I can't do anything... It's a PCB/schematic problem.


About original software :
slow-mode or 5 display/sec is equivalent to 40 PLC (at 50Hz)
middle-mode or 50 display/sec is equivalent to 4 PLC (at 50Hz)
fast-mode or 150 display/sec is equivalent to 1 PLC (at 50Hz)

The ADC does a continuous conversion. At 5Hz, with a settling time of 800ms, the overlap is 600ms. The 5Hz measures displayed each second are not independents.
Using my processing the overlap is always fixed to 3ms or less and a little pause could be set (if needed) to do a fully independent measures, no overlap at all !
I've checked this at 10PLC using a square wave generator at around 2.5Hz to see 2 totaly different measures (this is impossible in the original software).


My goal is to provide the best possible measurement with this limited DMM and a better software. I'm doing my best with the little time I have.

[Kleinstein]

I had not seen the units in the lower left corner. So the data are already after FFT and thus most of the peaks from mains hum.  So mains hum seems to be a least some issue.

230 Hz is a slightly odd frequency for the extra hum. It this something like a fan or display frequency ?



The original SW seems to use the sinc4 filter with chop disabled. The window for the filtering is 40/4/ 1.3 PLC wide,  but this is not simple integration over the whole time. The points at the start and end get a lower weight. Especially the very start and end have quite low weight.
It makes the comparison between data with different fitlers a bit tricky, as the readings are no all idependent, but there is still more information than skipping all the date before getting independent.
The sliding average over data with a higher rate are closer to the integration in the more classical integrating ADCs. This can have advantages, but it can also be worse in some cases. The sinc4 case is already a bit extreme. Sinc2 may some justification.

[oz2cpu]

when you are rewriting the FW for 3055,
is it also possible to fix the rather wrong way the statistics avarage works ??
right now the average readout only display the same number of digits, as the main screen,
remember it sends out two more digits via remote logging and via usb logging.
other units the Keysight 34465A is claimed to be the design master for the siglent DMM series,
their statistics, average show at least one extra digit,
bu the way I also on a SDM3055 and is longtime comparing it with 34465A
I find the 3055 do contain at least one more good digit, when average 10 times,
and 2 extra digits, when averaging 200 times. for many things, I just use external data management and filtering,
I also work on adding temperature controlled regulated heater (very cheap and simple mod)
to the parts affecting drift inside the 3055, just for fun really :-)
I also got access to much better equipment by 10x and by 100x factor, wich is newly calibrated.

[oz2cpu]

the SDM3055 is cheap, and nice in many ways, a perfect platform for modification / upgrade experiments

did anyone map all parts, that affect voltage read out by their temperature change to affected voltage read change ?
the most obvious is the Refferance, but also the ADC , and also other parts, like opamps ? range resistors ? input selector chips ?
do we have a have a schematic to work from ?

[alexvg]

Hi,

I continue the work I've started on the SDM3055.
I'm trying to find a solution to inject my software into the SDM3055 in the simplest way possible.

I'm trying multiple hardware solution
- Ethernet via a telnet access
- Using a USB-Key (but limited to 8GB usb-key capacity)
- Using a SD-card inside the SDM-3055

I'm working on multiple solution to use my software instead of the Siglent.
- Replace all flash memory with my own data (and remove all Siglent software)
- Inject my own software as a default boot software (with an exit button to access to the original Siglent software)

Note
Siglent uses TI and GPL code. After working hard, I could use some parts already inside the Siglent SDM3055 and re-use it in my own firmware (Linux, Linaro, gcc, telnet...).
All bash scripts (from Bookwore Peng) and softwares from Siglent will never be used.
Inside the SDM3055, I've could find surprise softwares : SVN, SDG800 bin, arb, cal, fpga and other data.
I don't know if the scripts from Bookwore Peng are licenced to Siglent or not, but I've already found his code inside some webpages about the AM335x evaluation boards.

I'm working hard.
Thanks for your support.

Alexia.

[tautech]

I continue the work I've started on the SDM3055.
I'm trying to find a solution to inject my software into the SDM3055 in the simplest way possible.

Alexia.

Great to see you back ! 

Details of Alexia's work is here:
https://www.eevblog.com/forum/testgear/hacking-the-siglent-sdm3055/

[alexvg]

Hi,

I've created 2 diagrams because it seems I misexplained my current work on the device.
I'm not working on a new GUI to replace the original Siglent software.
I'm working on another way to operate the device, to process the data and to provide better measurements.

Let's look at how the device works with the original Siglent Software.


Now let's look at my current work



I hope that with these diagrams, my work seems to be clearer to you.

Have a nice day.
Alexia.

[alexvg]

Experimentation on the AM3352 Sitara processor and Siglent digital board of the SDM3055





1. I've done a full backup of the NAND Flash memory (a global NAND file and 12 mtd files)
2. Rename and clean the 12 mtd files and generate 6 files (MLO, u-boot, kernel, rawlogo, rootfs, datafs)
3. I've reset the NAND Flash memory.
4. The SDM3055 is totally crashed/bricked !!!

Why did I lock my device ?
I need to have a step-by-step and verified procedure to allow me to quickly unlock the device if something goes wrong.


The hard way : Restoring the MLO and u-boot
I've written the MLO and u-boot files into a SD-Card under Linux
The SD-Card is /dev/sdc under Linux

Code: [Select]

sudo dd if=/dev/zero of=/dev/sdc bs=1M count=10
sudo dd if=./MLO.img of=/dev/sdc count=1 bs=128k
sudo dd if=./u-boot.img of=/dev/sdc seek=1 bs=384k
My MLO file is 128KiB long, now I can't shorten it.
My U-boot file is 1920KiB long, now I can't shorten it.

I unplug the SDM3055, insert the SD-Card, plug power supply to the SDM3055, short J16 (if J16 exists) and press "power".
I look at the JTAG under Putty and see the process... (need around 2 minutes)
I press "power" and unplug the power supply and remove the SD-Card.

Now the MLO and U-Boot is on the device... It's done !

The easy way : Restoring the device
Under Windows or Linux, create a partition into the SD-Card and format in FAT format.
(Personally I create a 3GB partition).

Copy the 6 files (MLO, u-boot, kernel, rawlogo, rootfs, datafs) into the SD-Card.
Create a uEnv.txt file to read and nand erase/write all 6 files into the SD-Card.

Here's my uEnv.txt (uEnv.txt file only support UNIX line feed)

Code: [Select]

I've removed my uEnv.txt because my SDM3055 suddently crash after working on the filesystem.
I thing my uEnv.txt is wrong.Note : You could create your own uEnv.txt using the U-boot documentation and the mtd4 raw backup. I've seen inside the mtd4 files, it could possible to restore the device from a USB-Key... I must try this.

I unplug the SDM3055, insert the SD-Card, plug power supply to the SDM3055, short J16 (if J16 exists) and press "power".
I look at the JTAG under Putty and see the process... (need around 5 minutes)
The device will boot 2 or 3 times and... application is launched !!!
Turn off the device, remove power supply, remove SD-Card and open J16 (if exists).
Turn on the device, it works !


I've done this for the v19 firmware.
I need to work more to provide all tools, to backup NAND Flash more better and to create a v19 and a v25 compatible backup process.


Other userfull information

Code: [Select]

mtd0 - the MLO (or named SPL)
mtd1 - a copy the MLO (or named SPL.backup1)
mtd2 - a copy the MLO (or named SPL.backup2)
mtd3 - a copy the MLO (or named SPL.backup3)
mtd4 - U-boot
mtd5 - U-boot env (it's empty)
mtd6 - Manufacturedata (it's the raw image, but a u-boot command could upload and convert a BMP file into this area)
mtd7 - rootfs (warning ! not all data needs to be backed up - I'm working and a tool to autocorrect the file)
mtd8 - kernel (it's the Linux kernel)
mtd9 - firmdata0 (your calibration data !!! very important to backup)
mtd10 - firmdata1 (i'll don't backup this)
mtd11 - datafs (warning ! not all data needs to be backed up - I'm working and a tool to autocorrect the file)mtd7 or rootfs is mounted into /
mtd9 or firmdata0 is mounted info /usr/bin/siglent/firmdata0 (this directory is very important, it contains the calibration data of the device)
mtd11 or datafs is mounted into /usr/bin/siglent/usr

The NAND Flash memory mapping

Code: [Select]

Offset                    Size (hex)  Size (KiB)  Description
0x0000000-0x0020000       0x0020000   128KiB      mtd0 - MLO (SPL)
0x0020000-0x0040000       0x0020000   128KiB      mtd1 - MLO (SPL.backup 1)
0x0040000-0x0060000       0x0020000   128KiB      mtd2 - MLO (SPL.backup 2)
0x0060000-0x0080000       0x0020000   128KiB      mtd3 - MLO (SPL.backup 3)
0x0080000-0x0260000       0x01E0000   1920KiB     mtd4 - U-Boot
0x0260000-0x0280000       0x0020000   128KiB      mtd5 - U-Boot Env
0x0280000-0x0580000       0x0300000   3072KiB     mtd6 - Raw logo
0x0580000-0x3080000       0x2b00000   44032KiB    mtd7 - rootfs
0x3080000-0x3680000       0x0600000   6144KiB     mtd8 - Linux Kernel
0x3680000-0x6880000       0x3200000   51200KiB    mtd9 - firmdata0
0x6880000-0x9A80000       0x3200000   51200KiB    mtd10- firmdata1
0x9a80000-0x10000000      0x6580000   103936KiB   mtd11- datafs
Total                     0x10000000  256MiB      NAND Flash
About how to backup data of mtd0 to mtd11
I've noticed a difference of data backed up between U-boot and Linux.

Code: [Select]

U-Boot code to backup MLO into a SD-Card
nand read 0x82000000 0x00000 0x20000
fatwrite mmc 0 0x82000000 backup-MLO.img 0x20000

Linux code to backup MLO into a USB-Key
nanddump -s 0 /dev/mtd0 -f /usr/bin/siglent/usr/mass_storage/U-disk0/MLO.imgThe MLO file saved using the U-Boot command is 128KiB long and cannot be shorten with my own tool to clear backup flash file.
The MLO file saved using Linux command is 132KiB long and can be shorten to 84KiB with my own tool to clear backup flash file.
Why ? I don't understand...

Updated on 2023-02-21 02:24 GMT
I've removed some incorrect or false information.
I've added the Flash NAND memory mapping.
I've added information about how to backup data.

To be continued...
Alexia.

[alexvg]

Hello everyone,

I finally found a solution to make a complete backup of the NAND Flash memory of the SDM3055 for all firmware versions.
The problem with the solution? It's too complex!

Anyway, I'll briefly explain my method.

My first functional solution (quick explanation)
You need to create 3 text files on an uSD-CARD formatted in FAT32. These 3 files contain U-Boot commands to dump the NAND Flash.
You need to boot the device on the uSD-CARD and wait for it to start up completely.
Under Linux, you need to mount and then reduce the images of the rootfs.img and datafs.img files with mkfs.ubifs.
Finally, you need to create a uSD-CARD with the image files in ubifs format as well as the few other dumped image files. All this with a uEnv.txt file.

My second functional solution (quick explanation)
You need to create 3 text files on an uSD-CARD formatted in FAT32. These 3 files contain U-Boot commands to dump the rootfs partition of the NAND Flash.
You need to boot the device on the uSD-CARD and wait for it to start up completely.
Under Linux, you need to mount and then reduce the image of the rootfs.img file with mkfs.ubifs.
From a Siglent update file in ADS format, you need to extract the files to be added to the uSD-CARD and add the ubifs file of rootfs. You need to accompany all this with a uEnv.txt file.

My third solution but not yet functional
You need to place a special version of mkfs.ubifs on a USB key.
With Telnet or Putty, you need to mount the USB key in another path, dump the non-ubi partitions, unmount some partitions, and convert the ubi partitions with mkfs.ubifs.
You will need to copy all the resulting files to a uSD-CARD with the uEnv.txt file.
(Currently, I can extract all ubi partitions except rootfs because my version of mkfs.ubifs is blocked due to a known bug).

The future
For now, I'm putting the NAND Flash memory extraction on hold. I may incorporate an option into my software to extract all data quickly and simply (if possible).
I noted that firmware version 1.01.01.25 changed things for the management of the rootfs partition. But I also noted a bug in version 25 that locks the device (perhaps due to my tinkering with the partitions?)
In the meantime, I'll start working on the software again and I'll post versions of my binaries when they're available.


I am seriously considering distributing my software for free while offering people who wish to financially support me through donations.
So... free of charge !


Thank you for supporting me.

Alexia.

[alexvg]

Hi,

Here is the status of the project :
- I have improved the capture to gain one bit of precision at the ADC level.
- I still have issues with range/function selection (sometimes the selection goes wrong and the measurements are completely off)
- I haven't yet implemented the very high precision capture processing functions.
- I have improved the processor load with a significant decrease: going from 60% to 35% load.
- To date, I have only had one crash during operation, but I haven't yet looked for the cause.
- The DCV, DCI, ACV, ACI, R2W, R4W, and "continuity" functions work. The "diode" function is buggy. The other functions are inactive.

Here is a small capture with a reference set to 1V (1000V / DCV / 1NPLC)

[alexvg]

Hi,
I've done some little improvements but not enough to provide a public beta.
So here is a little video at 60FPS.
https://youtu.be/HVU-4-q3Zkc

Alexia from France.