OWON XDM1041 the unknown multimeter...

[BugCatcher]

theHWcave


Received my XDM1041 a few days ago (running V3.0.1 SW). During waiting for delivery was enough time to screen all available information.
Found interesting discussions regarding different types of temperature sensors.
Regarding PT100 sensors I found following arguments:
- calculations for temperatures < 0°C are more challenging
- unwanted cable resistance is adding huge errors at low temperatures (around °0C)

Regarding temperatures < °0C:
Calculation requires 3rd-order polynom (pos. temperatures only 2nd-order)
What happens when we simply ignore the 3rd-order coefficient "c"?
    at -100°C   an additional error of 0.2°C
    at  -50°C   an additional error of 0.02°C
    -> see first diagram ...  (including tolerance band for class A sensors)

=>  extreme unlikely that "home lab" applications will ever face temperatures below -50°C
=>  second order correction is sufficient! No need to block calculation for <0°C!


Regarding impact of cable resistance:
I calculated the impact of an given resistor (0.262Ohm). Precise calculation based on the 3rd order polynom.
- impact nearly flat, no singularity around 0°C
- simply subtract 0.7°C for a "good enough" correction  (rule of thumb: subtract 2.6°C per Ohm, perfect at 50°C)
   -> see second diagram
   -> there is no problem for bench applications without extreme cable length

During ordering PT100 sensors I found that there are also PT1000 devices!
Price for class A PT100/1000 unpacked sensors is below 2€ (e.g. Reichelt in Germany)
-> PT1000 reduces the impact of the unwanted resistance by one magnitude (green line)!
Problem:
XDM1041 is not supporting PT1000!   ...   Why? It's a huge benefit with nearly no effort (measured resistance divided by 10)!
The only solution is an external PC-SW with a very simple modification of the PT100 algorithm.
e.g.   XDM1041 utility from theHWcave ... btw: this is an impressive piece of work!!!
       Another idea: SW-feature to enter the cable resistance manually (no need for a 3-wire cable!)
                     ... only need for a one time resistance measurement at known temperature (e.g. 0°C ice-water)!

I tried to install the utility on a Windows10 system running Python 3.10 ... I failed!
What must be preinstalled? Did it ever work on Windows10?

Regarding comparison of Thermocouple/PTxx ... I found an interesting link:
https://tmseurope.co.uk/applications/thermocouple-rtd-colour-codes-tolerances
-> Below 400°C PTxx class A shows always the best precision!

My own preference is PT100/1000:
- low price
- good performance
- heading for PT1000 with external SW
- full precision after cold start ... no trouble with reference junction block
- only negative point:  TCs can handle higher temperatures

[theHWcave]

For anyone interested, I have put the OWON Windows tool to upgrade the firmware of the XDM1041 as well as the firmware version OWON sent me (apparently V2.1.2 however it shows as 20210525) on my github page. The tool should be able to upload other firmware versions as well.

You can download it (in binary chunks) here: https://github.com/TheHWcave/OWON-XDM1041 with instructions in the readme file to reassemble the .ZIP file
(the reason for breaking it into chunks is the file size limit on Github)

To be clear, this is OWON's software but they gave me permission to post it. Don't complain to me about the quality of either the upgrade tool or the firmware please 

From the same place, you can download my own software (happy to accept suggestions on that) to log data from the XDM1041 on a PC (Linux or Windows), including a mode to properly use a PT100 sensor to measure temperature.

[BugCatcher]

XDM1041 Continuity Test

I had the impression that the response time is related to the XDM1041 "beep-threshold".
All existing evaluations regarding "speed of continuity beep response" are based on "hectic moves" combined with gut feeling!

I would like to propose an objective test method
- a function generator (square wave, 1Hz, variable duty cycle)
- a "contact" controlled by the function generator
      there are two options
       - a FET, I used a 2N7000 (2.1Ohm on resistance)
       - a reed relais (typ. 0.15Ohm on resistance, switching time about 1ms)
- I also increased the "on" contact resistance by adding different serial resistors (10, 30, 100Ohm)

Measurement procedure
Increase the "on" time by changing the duty cycle of the square wave
- first you hear single beeps (not every second)
- increase "on" time until you hear every second a beep
    -> this is the minimum time for the reliable detection of "contact"

The diagram shows my results for the XDM1041
- response time is heavily impacted by the "threshold resistance"
- high threshold gives you very fast response
- the setting of the threshold value depends on your application!

I tested also an UNI-T 804
- fixed threshold (40Ohm)
-  2.1Ohm 180ms
   10Ohm  170ms
   30Ohm  170ms

What about other multimeters?   Now we can compare!


Conclusion:     no longer need for "hectic moves"
   

[HKJ]

All existing evaluations regarding "speed of continuity beep response" are based on "hectic moves" combined with gut feeling!

Not really, I have reviewed a lot of multimeters where I used something similar:

More about it: https://lygte-info.dk/info/DMMTesterACSwitch%20UK.html

My Reviews: https://lygte-info.dk/info/DMMReviews.html

[BugCatcher]

Good News:   XDM1041 Recording Function

XDM1041 running V3.0.1
DMMEasyControl, Version 1.7.0 running on Win10

Local recording and upload of data
- local XDM1041 recording is working
- DMMEasyControl supports upload from XDM1041 to host (slow speed, takes time)
- import of uploaded data into spreadsheet (OpenOffice)
  special characters for °C, °F and Ohm are a challenge
  my solution: open data-file with text editor, copy "strange characters",
               past the "strange characters" as "separation characters" into the import menu of the spreadsheet,
               not elegant ... but working!

Data retention
- power off, 1h later, power on: recorded data still there
- disconnected power cable, disconnected usb-cable, reconnected power (30min later):    RECORDED DATA IS STILL THERE!
  didn't invest more effort to evaluate max. storage time

Big question:
Will OWON also support PT1000 Hope they are reading this thread  ;-)

[UniSoft]

Good News:   XDM1041 Recording Function
XDM1041 running V3.0.1

The big question is where to get that firmware?

Data retention
- power off, 1h later, power on: recorded data still there

It is saved inside MCU's flash...
Number of guaranteed program/erase cycles before failure (Endurance): 100 kcycles (according to the datasheet)
And by the way, data and settings can be lost due power failure within erase/write sector.

[BugCatcher]

There must be a battery on board. Clock is running without external power supply! The question is the size of the internal SRAM ...

[theHWcave]

Maybe a dumb question but are you sure that the data "saved" by DMMeasycontrol" is actually your locally recorded data? I am asking because DMMeasycontrol had that save-the-recording-as-spreadsheed function before and what it actually did was record new data coming in from the meter online into the spreadsheet. It did not even look at the previously recorded local data.

[UniSoft]

There must be a battery on board. Clock is running without external power supply!

Yes, there is a battery, for clock...
I draw the schematic of the control part, attached...

The question is the size of the internal SRAM ...

If you mean SRAM of MCU, then it is totally 48KB
If you mean storage, then how I said it is stored in FLASH, maximum 1000 points

I am working on reversing firmware...
Funny part, that the firmware is written for STM32F103 MCU (using SPL libraries), but they run it as is on GD32F303

[BugCatcher]

Proof of Recording Function

I tried to make the check waterproof!
- step 1   I disconnected USB from XDM
- step 2   XDM power on
- step 3   Temp -> PT100 -> °C
- step 4   Record -> Manual -> Clear buffer -> Back
- step 5   Auto -> set 20 Points -> Interval 1s
- step 6   soft key Start
                 touched PT100 during measurement (increase/decrease of temperature)
- step 7   checked samples on XDM (increase/decrease of temperature) -> was ok
- step 8   XDM power off, removed PT100 cable
- step 9   reconnected USB
- step 10  XDM power on (running VDC, no PT100 connected!)
- step 11  started DMMEasyControl on PC
- step 12  DMME command Control -> Connect
- step 13  DMME command Record -> Device data export -> entered path/file-name
- step 14  after a few seconds: "Device data export completed!"
- step 15  checked file on PC ... identical with manual observation on XDM -> BINGO!

Stored file:

NO   MODE   VALUE   
1   Period   29.1¡æ
2   Period   29.0¡æ
3   Period   29.3¡æ
4   Period   29.4¡æ
5   Period   29.5¡æ
6   Period   29.6¡æ
7   Period   29.7¡æ
8   Period   29.8¡æ
9   Period   29.8¡æ
10   Period   29.9¡æ
11   Period   29.6¡æ
12   Period   29.0¡æ
13   Period   28.6¡æ
14   Period   28.3¡æ
15   Period   27.8¡æ
16   Period   27.4¡æ
17   Period   27.0¡æ
18   Period   26.8¡æ
19   Period   26.5¡æ
20   Period   26.5¡æ

Other observation:
direct capture with DMME
- you get higher resolution
- you get date/time on top
only problem: formatting of msec is not correct
correct example for time:   19:22:47.779
incorrect example:          19:22:50. 45
-> leading zeros for msec below 100 or below 10 are replaced by "space"
-> trouble with spreadsheet processing

[BugCatcher]

UniSoft

You are right! Data must be in Flash. Leakage of SRAM (deep sleep) is above 100uA.

BTW: Could it be that D1 (in front of battery) is in wrong direction?

[UniSoft]

You are right! Data must be in Flash.

I saw it in the firmware code.

BTW: Could it be that D1 (in front of battery) is in wrong direction?

Yes, for sure... I made a mistake.

By the way, Does anyone know what the TFT display is used there.
I did not find anything with such a pinout.
PB2 - D/C (0: Command; 1: Data)
PB10 - CLK
PB1 - Probably RESET

[BugCatcher]

Next Story:   Sampling Rate

The data sheet promises up to 65Hz sampling rate (15.4ms)

First step:

timing only
  I started with the DMMEasyControl tool
  - simple measurement due to time stamps in download,
    1000 samples per run (DCV, 5V fixed, fast mode)

       set sampling rate (ms)     measured sampling rate (ms)
             
         16                        51.1
         18                        51.1
         20                        48.0
         25                        50.6
         30                        51.2
         40                        52.2
         50                        77.9
         100                      110.1
         1000                    1007.8

       -> Dramatic overhead for sampling rates below 1s!
       -> Time stamps are heavily impacted by jitter (a few 10ms)

   Next test is XDM with internal recording

     Due to missing time stamps only total time for 1000 samples (hand stopped)

         15ms   -> 15s
         30ms   -> 30s
        100ms   -> 100s
     
       -> Internal recording of XDM looks ok!


Next step:

What about the quality of the stored measurements?
Used a function generator with a slow triangle wave (below 100mHz)

  downloaded an internal recording of the XDM
  (see "XDM_internal_recording)

       -> looks ok! No Jitter!


Next test is DMME recording with 50ms samples. Big surprise ...
  - samples are repeated!
  - new sample value only after a few 100ms, heavily impacted by jitter!
  (see "DMME_repetition_of_samples")

What happens for 1s sampling?
  - no longer repeated samples
  - impact of jitter still visible
  (see "DMME_jitter_at_1s_sampling)

Potential explanation:
  - rate for new sample values is similar to rate on PC-display (in the range of 2Hz)
  - DMME SW is doing nasty things: delivering correct number of requested samples, update
    of sample value only in sync with display of PC-screen


My conclusion:

     -> for sample rates below 1s you have to use the internal recording!

[Ringmodulator]

Check out the Voltcraft VC-655 BT

Looks like the same unit in a different dress....



https://asset.conrad.com/media10/add/160267/c1/-/en/002357060DS00/datenblatt-2357060-voltcraft-vc-655-bt-tisch-multimeter-digital-cat-i-1000-v-cat-ii-600-v-anzeige-counts-55000.pdf

Chris

[Johnny B Good]

 It appears to be the same breed of "Duck", you know, if it walks like a duck, quacks like a duck... 

 At nearly 200 Euros (and possibly VAT on top - there didn't seem any point checking at that pricing level) for the Voltcraft version, I decided to spend my money on the Banggood offering, namely the OWON XDM1041 USB model for just £96.46 plus  a little extra on shipping and tariff insurance (still just under the 99 quid mark with an estimated delivery by the 29th - a realistic estimate going by recent past experience).

[Ringmodulator]

It appears to be the same breed of "Duck", you know, if it walks like a duck, quacks like a duck... 

 At nearly 200 Euros (and possibly VAT on top - there didn't seem any point checking at that pricing level) for the Voltcraft version, I decided to spend my money on the Banggood offering, namely the OWON XDM1041 USB model for just £96.46 plus  a little extra on shipping and tariff insurance (still just under the 99 quid mark with an estimated delivery by the 29th - a realistic estimate going by recent past experience).

It is currently 139,99€ with VAT and shipping included. Add VAT and conversion to € for your Banggood offering, you are about level.
https://www.conrad.de/de/p/voltcraft-vc-655-bt-tisch-multimeter-digital-cat-i-1000-v-cat-ii-600-v-anzeige-counts-55000-2357060.html

[Johnny B Good]

 I just checked the currency exchange rates and I reckon I saved close to £20.00 on the deal (Banggood only show VAT inclusive prices, at least to us Brits). What I'd paid, was the equivalent of 119€ in total with no further charges added on. 

[Johnny B Good]

 The XDM1041 I'd ordered from Banggood arrived this morning - three days sooner than Banggood's estimated delivery date.

 I haven't tested everything but it seems to be within its specs on DC volts and K-type temperature readings. The standby energy consumption is a gratifyingly low 250mW, peaking to a maximum of 1.5W at a backlight level of 100% dropping to just below 1W at 0% and just a fraction over 1W at the 25% setting.

 I'm monitoring the EFC voltage difference against my GPSDO's internal +2.0000 voltage reference offset which is hovering around the 366.00mV mark (2.36600v) closely matching the mV readings of a Mestek DM91A 9999 counts true RMS dmm I'd been using to see these variations down to a resolution of 0.1mV.

 I could use it to monitor the full EFC voltage (2.3660 volts) direct but I'd end up seeing only the same effective 100uV resolution I was getting with the Mestek DMM and a +2 volt offset.

 The only thing that had initially put me off buying this 4.5 digit bench meter was the lack of any tempco specification, hence my pushing the boat out on an SDM3065X which has impressively low tempco figures.

 In this regard, I don't expect the Owon bench meter will do any better than the Mesteks which, until I had cause to test their temperature stability a few months ago, had seemed remarkably stable in the face of typical changes in room temperature.

 At least the Owon bench meter isn't going to incur regular changes of a pair of AAA cells every 400 hours of run time (I usually disable the auto shut off time out feature built into the Mesteks to avoid losing sight of whatever I'm monitoring for hours long periods).

 I'll give the Owon a more thorough work out later and report the results here in a follow up post.

[Johnny B Good]

 I completed my tests and, with the obvious exception of capacitance measurements being extremely slow to obtain results, everything else checks out with remarkably good accuracy against the SDM3065X.

 The only real complaint I have is in regard to the slowness (glacial) in producing capacitance readings. The accuracy of capacitance measurements is on a par with those obtained with other test meters so no complaint there - it's just the very long time required to get the reading that's so intolerable.

 Luckily, I have much better alternative ways to test capacitors, so this is very much far from being a "deal breaker" (as I suspect will (should!) be the case for most other purchasers).

[BugCatcher]

Hi John,

happy to hear that you like your new "investment"!
I'm eager to get the following information:
Which FW-version is running in your box?

BugCatcher

[Johnny B Good]

@BugCatcher

V3.1.0

[ass20]

for
UniSoft

I check photo(digital board) of xdm2041 and xd1041 and found more identifical parts
see
https://github.com/PetteriAimonen/owon-xdm2041-info
https://github.com/aziemer/Project-Phoenix
and
http://essentialscrap.com/owon_fix/

[raphaelCoelho]

Has anyone tried replacing the SMPS with a linear power supply, as commented on in post #51?

[kwass]

Has anyone tried replacing the SMPS with a linear power supply, as commented on in post #51?

Yes, see post #113 in this thread.  My xdm1041 has been running continuously on a lipo cell with wireless charging for the past 8 months or so.  I never turn it off and just pick it up off the changing base when I need to use it off the workbench.  No problems at all, other than the bugs reported above for version 2.xxxxx firmware.

[raphaelCoelho]

I had already seen your modification, it was very good!
My idea is to put a small transformer and make a regulated power source. In this way try to escape some noise from the original switched power source.