OWON CM2100B, is Uni-t ut210e inspired?

[rauldm]

Hi, I see the new Owon C2100B is a current clamp with similar specs to ut210e, but with ensanched specs, but example, is 20000 counts model, it has bluetooth, and measure frequency. ut210e pro also measure frequency, but it has less counts. Does anyone know anything about this product?

[DaneLaw]

Prices' from an EU perspective (incl.25% VAT) seem to be around 40US for CM2100 & 58US for CM2100B (Harald Blåtand variant), so a tad more than UT210E, but also better specs.



Usermanual: https://files.owon.com.cn/probook/CM2100-Clamp-Ammeter%20User%20Manual.pdf

Source: https://www.owon.com.hk/products_cm2100_series_smart_ac%7Cdc__clamp_meter

Take the BT feature with a pinch of salt, OWONs app tends to be a mess and with no incentive to fix it, - their app-graphing feature on their multimeter-line 35series and 41series was bonafide broken, and would dance around wrongful segment values, and with no locked orientation on the graphing - at least that was the case in 2015/2016, - just checked the one on Google play, it's the same mess in 2023.
was this app  https://tinyurl.com/yc5ejf6v
Though the update rate, was not that bad for BT4.0 BLE in 2016 https://tinyurl.com/yjef97e9
Does not look like you can combine, the clamp meter with Owon DMMs, unless you have two different apps open, "Owons Multimeter BLE4.0 app" & "Owon IMeter app" that seems to be locked to only this clampmeter (CM2100B).. shame.

cirquit boards
https://youtu.be/pLUVRxyz74g?t=1845

[rauldm]

I can see in the video, the owon is not has input protections at least like ut210e, ok, I will go with ut210e.

[s_n]

I recently found the non-BT version on Amazon (US) for $30. There's not a lot of information on the web yet about this meter, so in case it helps anyone:

• I bought this primarily for low current DC work. With proper zeroing, I found that accuracy in the 2A range is about 0.5%±3 counts on my unit, testing all the way from 1mA to 2000mA.
• Low AC current accuracy seems similar to DC. Readings are within the specified ±3% up to 2kHz and the -3dB point is 3.2kHz.
  
• I don't care much about the other features, but I also tested DC voltage, and found it accurate to better than 0.1% between 1V and 20V.

There are a few usability quirks and annoyances:

• The meter beeps whenever you change range or push any button. I can't find a way to disable this.
• Voltage defaults to DC, but current defaults to AC
• The NCV alert takes about a second or two to trigger, so you have to make sure not to move the meter away too fast

[LeonR]

Here's a video comparing it to the UT210E:



Seems like OWON skimped on the protection side, which is a bummer. Even their high-end model (B41T+) have a very basic input protection.

[modoran]

Bought it myself with 40$ in EU ( without bluetooth ), cheaper than UT210E.

Multimeter chipset is sanded off, it is known what chipset it is ?

[linux-works]

I'm going to try this unit; and my wish is that it will work with linux.

I have some bleak (python) sample code that works with the aneng an9002, and I'm hoping there is a variant of that python (or c++) that will work with the clamp meter ble protocol.

has anyone tried or found what version of proto it speaks?

[linux-works]

I'm happy to say, I've created a linux BLE app that works with this meter!

took an example owon ble app and hacked it so that it 'knows' this model's use of BLE.

I'll post it to my github once I clean the code up a bit more and do some more testing.  so far, though, it seems to be 100% functional and all values and icons are decoded.  no funky xor stuff and its not an 'lcd segments' kind of decode.  its proper mode bits and integer numbers (along with decimal place location and 'scale' multiplier).

if anyone has linux and this meter and wants to give it a try, ping me.  soon, I'll have a link to a github location.

[linux-works]

while trying to rev-eng this protocol, I wrote a little python tool that will show you column differences (in binary) for any of the BLE gatt payload bytes.  you run a log tool and save to a file.  as long as its a rectangular file (each column is the same length and the same format) it will do a line by line diff and highlight any bits that changed.   it can also run in '--sticky' mode, so that each change stays latched and by the end of your short run, you can see all the fields that changed, and which ones you can ignore.  I'll include that hack script along with the DMM code.

[linux-works]

go get it!

https://github.com/sercona/owon-cm2100b-clamp-meter

git clone it and build on linux.

let me know if you have issues/etc.

[linux-works]

update: code is now generalized to run with three types of owon meters!  it turns out that the protocol is nearly the same, with only a few differences.  the new code is still beta but most things seem to work.  testing still needed.

[rauldm]

Looks nice these owon instruments, what is your main use for them? For automotive applications can be safe its use

[linux-works]

yet another update.

turns out, they all pretty much use the same protocol, with minor changes.  got hold of a 4th owon model type (ow18e) and this one also matches the others (is more like the cm2100b since it uses the same ble handle-id).

updated source for all four:

https://github.com/sercona/Owon-Multimeters

[linux-works]

btw, the way to find out how to talk to these is to run gatttool (three 'T's in that word, sigh...)

Code: [Select]

$ gatttool -b A6:C0:80:E5:84:0C -I
[A6:C0:80:E5:84:0C][LE]> connect
Attempting to connect to A6:C0:80:E5:84:0C
Connection successful
Notification handle = 0x001b value: 24 f0 04 00 00 00
Notification handle = 0x001b value: 24 f0 04 00 00 00
Notification handle = 0x001b value: 24 f0 04 00 00 00
Notification handle = 0x001b value: 24 f0 04 00 00 00
Notification handle = 0x001b value: 24 f0 04 00 00 00
Notification handle = 0x001b value: 24 f0 04 00 00 00
Notification handle = 0x001b value: 24 f0 04 00 00 00
Notification handle = 0x001b value: 24 f0 04 00 00 00
[A6:C0:80:E5:84:0C][LE]> quit
$

that 0x001b is the key.  it can be that value or 0x002e.

from what I've seen, just by sniffing the BLE output, is that meters that use 1b are the cm2100b and the ow18e.  the two B meters (b35 and b41) use the 2e handle.

the 6 bytes are 99% the same between the meters.  I still need to find all the diffs (I think on the clamp meter vs the others, what continuity_open means is what the others see as continuity_closed.  some things are not the same, for some reason).  but the basics are there and it should be usable for all four of these models.

linux BLE has a habit of getting stuck, for some reason.  I found a resetter that you might need to use, if your commands are not working.

Code: [Select]

$ sudo python3 ./hci-resetter.py --now
Resetting HCI hci0
HCI hci0 has been reset

you can tell if you need that by trying a ble scan:

Code: [Select]

$ sudo hcitool lescan
Set scan parameters failed: Input/output error

if you see that error, try the resetter.

Code: [Select]

$ sudo hcitool lescan
LE Scan ...
12:A7:CE:34:9E:47 (unknown)
64:07:F6:96:0A:03 (unknown)
B2:5C:DA:F7:BC:B5 (unknown)
67:15:BB:2D:90:56 (unknown)
C8:69:CD:51:7B:A1 (unknown)
E8:49:8E:26:D1:5C (unknown)
...


[linux-works]

not sure if I'll keep all the new Owon's I bought.  I will likely keep the clamp meter and the b35t+ (best backlight).

here is all that I've collected over the years.  some, I bought new back when I was in college (80's). 

the two IBM flukes are my favorites and I dont use them; they only come out for photos.



but lately, I only buy meters that have remote access of some kind (serial, ble, whatever).

my eventual goal is to provide an ESP8266 (or esp32) web front end to all of the ones I can, so that multiple clients could poll multiple devices, as long as everyone's on the same wifi net.

[ball]

Any way to make it default to DC?

Does it already default to continuity tester?

[Aldo22]

my eventual goal is to provide an ESP8266 (or esp32) web front end to all of the ones I can, so that multiple clients could poll multiple devices, as long as everyone's on the same wifi net.

I got an Owon CM2100B yesterday and the readout worked straight away with your code via ESP32.
  

[linux-works]

cool - I've recently started using the esp32-c3 'supermini' modules.

for some reason, though, staying up on wifi long-term on the esp32 has always been a problem.  they can fall off the network in hours or days, it seems random.  otoh, the 8266 chip NEVER drops out.  I've had them stay online for months and more than a year (before a power failure or upgrade was needed).  for short term wifi use, esp32 is still ok but I have yet to find out what it is about the api or bottom code on the 32 that has that bad behavior.  I've seen posts about it where people ask but there's no solution, really.  I've tried the latest board manager version and still has the issue.

the 32 does have BLE, though.  I dont know how stable ble is on the 32 but I bet its quite stable, at least compared to the wifi stack.

[kripton2035]

I have an esp32-c3 supermini online using wifi for a month now with no problem.

it is one that does NOT have the antenna design problem.
https://www.reddit.com/r/esp32/comments/1g3n3un/esp32_c3_dev_board_with_bad_antenna_design/

[linux-works]

I've tried the esp32 classic that comes on a lot of relay boards.  also on the 'cyb' (cheap yellow board, which has the 2.8" tft display).

I think there are at least 2 very different api's.  the one where the chips 'stay up' are probably the newer one (or there is a keepalive reset in there somewhere).  the older compatible ones that also work with the 8266 are the buggy ones.  stable as hell on 8266 but v2 or v3 of the board manager on the 32 lets me compile and run but I can see the node falling off the network around midnight, often.  I had one stay up for weeks.  could not figure out why that one did stay up but the rest all drop out.  its enough that I dont even try to use esp32 for longer-term wifi use.  I need to find out WHY this is, but its been a bug for years, it seems.  and espressif is not interesting in fixing it and I wonder if its in the closed source area, so we cant fix it ourselves.

I may have to move to the new api for networking but it means my old code has to be changed and I have quite a lot of old code that just plain works on 8266.

[Aldo22]

I didn't really think about the version.
I just took the first ESP32 that was in the drawer and.... it worked straight away. 

[linux-works]

I'm going to get the 'CYD' working with this.  this board or one like it: https://www.amazon.com/dp/B0D92C9MMH

so, if you want to see your data graphed, grab one of these boards.  I cant guarantee I'll have it working but I'm pretty sure I'll be able to find out pretty soon.  stay tuned..

(the image is of this display running an ELRS rf display monitor for RC air/ground control)

[linux-works]

confirmed that the CYD esp32 will work with this.  I tried on both my clamp meter and also my new B35T+ which was on sale and I bought on a whim.

I'm going to add graphs, now that I have a TFT esp32 that is easy to buy and very common.  and cheap.  that's the C in cyd.

update: running into space or co-existing issues.  I tried adding my wifi front-end and that, along with BLE stuff was too much and it would not fit.  took my wifi/web out and just went with graphics and BLE and even that would not startup.  I'm back to using the esp32 chip JUST for ble, and I'll try using a 2nd cpu (sigh) for the graphics.  not sure why this is happening, but I dont see ble working when I link in 'too many things'.  perhaps ble is using a lot of resources and adding the spi tft display threw it over the edge.

[Venturi962]

You can try changing the partition scheme on ESP32 to 'huge app' this will allow both the WiFi and BT libraries to fit.

[linux-works]

will it also support OTA updates?   (looks like you give up OTA if you want 'big app'.  I hate losing updates over-the-air, though.  but maybe it just has to be, for this size of flash and chip)

trying to see if changing partition sizes helps.

I guess I never tried ble and 'other things' on the esp32 until now.