Uni-t ut-d07a Bluetooth..

[spikey1973]

Hey guys.. I'm been reading on and off on this forum for quite a while now, always very informative.. but now I have a question..

At the moment I own a uni-t ut61e.. and although I fully realise that some of you feel that the only proper use for this is to fill up the garbage bin I have been rather happy with it.. none the less I'm seperating from it.. why well I saw a change for a ut71c.. and took it, helping a friend of mine that was looking into the 61e because I sold it to him for an oke price.

Although I haven't received mine yet.. I have been looking around for some mods on this dmm like there are many for the 61e. But I didn't find any. Reason for that is that most of the mods for the 61e are already there in the 71 series. (Back light, usb cable).

But even though there is a USB cable supplied I was wondering if anyone has tried to mod / diy a ut07a Bluetooth module. These are rather rare and expensive (compared to the dmm) and to me it seems like there shouldn't need to much difficulty in building one yourself with Arduino parts..

Unfortunately the reason for the question is the same as why I need to ask.. I don't have one to take apart and have a look at the schematics..

So I was wondering if someone here was willing to have a look at it and post some pics from the inside.

Could be informative for all of use..

Anyway, many thanks in advance..
No matter what the result, just thought to ask.

Kind regards

Matt


Sent from my Redmi Pro using Tapatalk

[picitup]

Hi I've just taken receipt of one of these and I'm pretty disappointed in it.  The first hurdle was to pair it with my Windows 7 laptop.  As it turns out, it's a BLE (bluetooth low energy) device and the BLE stack is not supported in Windows 7.  Deep joy.

After diddling around with a million drivers, I eventually got it paired with and external cheapy dongle which presented itself as a CSR 8510 A10 and after installing the CSR drivers it paired.

I was hoping it would then install a serial port but not so lucky.  It installs itself as a GATT service.  As far as I have read, this provides all kinds of services like battery level, alerts, time, blood pressure and all sorts of goodies.

I'm guessing that you need some software to talk to the device which wasn't supplied.  On the UNI-T page here:

http://www.uni-trend.com/productsdetail_1689_1087_1087.html

Yes, that's it - the page with the missing graphic 

They were advertising it as working with Windows but now it seems they are only supporting Android.  I bought mine from Aliexpress which advertised it as working with Windows.  I've emailed them asking for the Windows software so I'll wait and see what they say.

According to the manual here:

https://drive.google.com/open?id=0B4Jyby-tjH5oMWdSQWhEVmhKbWc

It supports IOS, Android and Windows 8.  Funny there's no Windows software to download.  It also says it switches off automatically after 5 minutes of being unpaired and also when no data is transferred after 5 mins.

I can't think for the life of me why they would use a BLE device meaning they have to provide software (which is not their strongest suit).  What's wrong with a basic serial port?  It works with everything!

Oh well, I'll wait and see what the supplier says, but I think I have a few HC-05 Bluetooth modules somewhere so I might rip out most of the electronics and stick one of those in.

Bummer.

[picitup]

If anyone is thinking of making their own bluetooth / USB->Serial for the UTXX series, there's a nice teardown and mod for the serial cable (UT-D02) here:

http://blog.avrnoob.com/2014/03/uni-t-ut61e-rs232-serial-interface.html

The cables are available from aliexpress for around USD 10.

Cheers

Steve

[picitup]

Well I got a reply from the seller:

Hello Friend
Most customer use this bluetooth adapter in Android or Ios phones .
Please download iDMM in the Uni-t website with your phone firstly (http://www.uni-trend.com/productsdetail_1689_1087_1087.html)
Then you can connect it with ut181a
Waiting for your news
Jerry

Looks like the bluetooth adaptor doesn't work with Windows as there's no software.  I'll wait to resolve the issue with the seller and then crack it open and post up some pics.

Cheers

Steve

[picitup]

Just a quick update on this.  The seller has confirmed that there is no Windows software so I've asked for  50% refund so wait and see what he says.

No reply at all from UNI-T so I guess they don't give a damn about releasing the hardware with no software support.

Cheers

Steve

[picitup]

See if this gets their attention....
---------------------------------------------------------------------
Complaint: UT-D07a bluetooth adaptor  ** PLEASE REPLY **

Dear Sir

It's been 10 days since my last email and 12 days since my first email.
I'd be grateful for a reply.

Kind Regards

Steve

----- Original message -----
From: Steve Mayall <XXXXXXXXXXXXXX>
To: rex@uni-trend.com.cn
Subject: Complaint: UT-D07a bluetooth adaptor
Date: Fri, 20 Oct 2017 11:42:56 +0100

Dear Sir

I am unhappy as I've just bought a UT-D07a bluetooth adaptor from an
approved aliexpress distributor.  The device was advertised as working
with Windows, but I can't find any Windows software on your site,  just
Android software.

If you google UT-D07a, you can find hundreds of suppliers selling the
device as working with windows.

Are you really selling a Bluetooth multimeter adaptor that doesn't work
with Windows?

I feel I have wasted my money on a product that doesn't meet its
specifications.

Can you help?

Kind Regards

Steve

----- Original message -----
From: Steve Mayall <xxxxxxxxxxxxxxxxx>
To: neo@uni-trend.com.cn
Subject: UT-D07a bluetooth adaptor
Date: Wed, 18 Oct 2017 15:15:26 +0100

Dear Sir

I have just purchased one of these, but there was no software supplied.
Could you let me have a link to the Windows software please?

Kind Regards

Steve

[picitup]

OK here's the latest.  After opening a dispute, the seller gave me a USD 15.00 refund so it just cost me 15.00.  Uni-t never replied to nay of my emails so I guess they've lost interest in the product.  If you search for UT-D07a and Windows there are tons of sellers advertising it as working with Windows.  I guess UNI-T have dumped them for a low price.

Anyway, now I have my refund I decided to take it apart.  The case is glued together, but a carpet knife run along both long edges was enough to crack it open you can see the main components are a PIC18LF25K22 and a BL79BLETRMC2 which are here:

http://www.microchip.com/wwwproducts/en/PIC18F25K22

http://www.issc.com.tw/products/data/contentd8c4.html?


I traced the pads out and found it to be an ICD header (see pic).

I wonder if it would be better to rip it all out apart from the LED drivers and stick in one of the HC Bluetooth devices.  I don't want to spend a long time on this but will have another poke around later and see what's the best approach.

Cheers

Steve

[picitup]

I spent a little time tracing the circuit this morning and here it it.  No great surprises, I just need to cut the TX/RX lines to the PIC and connect these to a HC series Bluetooth serial port.  I have some HC-05's in stock, but these don't go down to 2400.

The HC-06 works from 3.1 to 4.2v and will go down to 2400 so I'll order one of those and see how it goes.

As far as the circuit goes, the only thing I'm not sure about is the power supply for the optical circuit which seems to come from the BT module pins 23 and 24.  I'm guessing that this is two PIO outputs in parallel, providing power saving during pairing and goes high when paired, but I'll do a bit of poking and report back.

Cheers

Steve

[joeqsmith]

 

I too was taken in by UNI-T's slick marketing group.   Still no Windows software     

I started to have a look at the andoid code and saw where someone put together a BLE library for Labview.  Has anyone here tried to get one of these working on the Windows platform after the original posts?

[joeqsmith]

I spent a little time looking at this adapter.  It's easy enough to readout the basic information but I was unable to find any details that would get me further.

[joeqsmith]

There is a LOT to sort out but I've made some progress.     

[joeqsmith]

Logging some data from the UNI-T UT1181A with UT-D07A and Windows 10.   Signal is a 2Vp-p sinewave at 20mHz.  So the first signs of life.

The combo is fairly fast, basically sending a packet at 10Hz, or five times faster than the 121GW!  At 55 Bytes, the packet sizes are much larger as well.   

After enabling the communications and connecting to the UT181A, the meter will not start sending data like the 121GW.  There are commands that appear must be sent to the meter to get it setup.    I used an IR receiver and sniffed the interface cable that was supplied with the meter and have some idea now how to program it.   The problem is getting the UT-D07A to send data to the meter.  So far I have been unable to get any data out of it. 

Once that is sorted it, I need to decode the packet.  Lack of documentation and software support for an OS they claim to support is really bad.  Aside from that, I'm impressed with the combo.   If UNI-T ever makes a better version of this meter, I will buy it.

[joeqsmith]

Setup Wireshark and attempted to sniff the BLE.     

Shown is the the time between packets.   In the software I have what I call a frame rate as well.  This is the actually the BLE message rate.  It runs faster as multiple messages are required for a single packet.   

[joeqsmith]

A quick demo showing the transfer rates.   It's fast. 

https://youtu.be/0iYZQIAwnbc

[joeqsmith]

The two adapters taped back to back was enough to sniff the codes from the UNI-T program.   A few more tests and I was able to get the BLE radio to transmit.  Things are getting pretty close now. 

[joeqsmith]

Anton,

Both the read and write are now working with the BLE interface.   Because I am using BLE and not the USB adapter, some things may be different.  So if you do not understand my questions, this may very well be part of the problem.

Let me start with there appear to be two sets of data sent in each packet.  What I am calling a packet is one complete message.   These two data sets appear to represent the data being displayed on the 181A.   They are both made up of a 32-bit floating point number and followed with a text string.   The strings appear to be null (0x00) terminated.  The strings are the mode that the meter is in.  So for example "mVDC".    I had assumed one data set represented the primary and the other the secondary display but this does not appear to be the case.   

For example, it appears that when the meter is set to DCV the first setset is the raw display value but the second data set appears to be a filtered version of the same data.   There appears to be a slight offset.     When resistance is selected, the second data set seems to be 2X the value of the first data set.   It almost looks like they are trying to provide more resolution.   

Have you dug into this and if so, you you explain how to interpret the second data set?

Again, thanks for any help you can provide. 

[antage]

Second value for DCV or resistance mode is fast measured value from bar meter on the screen.
Measurement packet contains from 1 to 4 values: main value, aux1 value, aux2 value and fast value.
For example, VAC/dBm mode: main value in dBm, aux1 is VAC, aux2 is resistance and fast value (VAC).

[joeqsmith]

It sounds like the packet size is not fixed then.   That's a BIG help already!   I have not tried all the modes to see anything besides the two data sets and fixed packet size. 

So far, I have not tried to change the rate that the 181A sends the data.   I just looked at the default code that their Windows application sends to the 181A and used that for now.  The meter sends the packets at 10Hz.  I assume this is faster than the meter normally samples which is why I see the discrete steps.   The bargraph would be faster, so this make sense rather than a filter.   Looking at the DCV mode,  does the bar graph data set have the same resolution?   Accuracy?   

When I switched to the resistance mode, the 181A sends a decimal 126 for the Omega symbol.  I ended up translating that to use the upper case W from the Windows symbol font to display the ohms sign.   Are you aware if they have other special graphics characters?

[antage]

So far, I have not tried to change the rate that the 181A sends the data.   I just looked at the default code that their Windows application sends to the 181A and used that for now.  The meter sends the packets at 10Hz.  I assume this is faster than the meter normally samples which is why I see the discrete steps.   The bargraph would be faster, so this make sense rather than a filter.   Looking at the DCV mode,  does the bar graph data set have the same resolution?   Accuracy?

As far as I know the rate can't be changed.
Data from the bargraph is more noisy and less accurate.

When I switched to the resistance mode, the 181A sends a decimal 126 for the Omega symbol.  I ended up translating that to use the upper case W from the Windows symbol font to display the ohms sign.   Are you aware if they have other special graphics characters?

There are two special symbols only:
0x7E - omega symbol,
0xFFFD - degree symbol (temperature modes, before C/F).

[joeqsmith]

Very good information so far.  You are saving me a lot of time.

I see now what you mean about the different packet sizes.  Temperature seems to have a slightly different format as well adding a single byte.   AC+DC is a much longer packet which makes sense.    So there is a bit of work to do in this area. 

When I first decoded the packets from their Windows software, I saw them send out an AB,CD,4,0,5,1,A,0.   The meter then beeps and starts transmitting the data.   I sent this same code out even after the meter powered off and sure enough it would start to send.    Sending an AB,CD,4,0,5,0,9,0 and the meter would stop.    This worked fine up to the point where I had to recharge the batteries in both the meter and the BLE adapter.   After this, the meter will not send data.  If I use the USB cable, set the meter to connect and then plug in the BLE adapter, it works fine again.  I can connect to the BLE just fine.  The handle tables are all correct.   

I assume there is more to getting the meter setup than just sending this one packet.   Can you give me some idea on the proper procedure? 

[antage]

When I first decoded the packets from their Windows software, I saw them send out an AB,CD,4,0,5,1,A,0.   The meter then beeps and starts transmitting the data.   I sent this same code out even after the meter powered off and sure enough it would start to send.    Sending an AB,CD,4,0,5,0,9,0 and the meter would stop.    This worked fine up to the point where I had to recharge the batteries in both the meter and the BLE adapter.   After this, the meter will not send data.  If I use the USB cable, set the meter to connect and then plug in the BLE adapter, it works fine again.  I can connect to the BLE just fine.  The handle tables are all correct.   

I assume there is more to getting the meter setup than just sending this one packet.   Can you give me some idea on the proper procedure?

It seems you don't turn on remote mode on the DMM or the BLE-adapter needs some initialization.

DMM must beeps after each command. Short beep sound is meaning an error.

Some notes about the packet format. All (sent and received) packets have the same format:
2 bytes: magic bytes, always == 0xCDAB
2 bytes: payload size + 2
xx, ..., xx: some payload
2 bytes: checksum

Payload 0x05, 0x01 - monitor mode on
Payload 0x05, 0x00 - monitor mode off

[Brannigan]

Hello All:

I don't have any BT or BLE experience with the 181A but I was very disappointed to find that I had no easy way of getting useful data off the meter, that had been saved in the data logging mode. This was really frustrating, because the supplied utility is .XLS aware, but only provides that if the data is collected in real time.

Soooo, this led me down a reverse engineering path that turned into a real time vampire. The upside is that I have a moderate understanding of how the meter communicates.

I used the supplied utility and Wireshark with the USB plug-in to watch the data stream. It's cumbersome and I ended up exporting it as text and wrote a post processor to remove the USB overhead and extract the actual data. I think the Microsoft Message Analyzer would be better but I couldn't get it to work reliably on USB, so rather than fight to find out why, Wireshark it is.

The data packet is fairly complete, letting you know just about everything going on in the meter, but unfortunately, it is highly variable depending on the mode and function selected.

The "05" mentioned above is a command ID, in this case, read real-time data (What you see on the meter) The byte following that is the read mode:

 Assuming the meter has just booted, it is in normal mode and if you send 0x05 0x00 it will return a single reading. If you send a 0x05 0x01, it will then send readings continuously at ~ 10/sec. If you send a 0x05 0x00 while in automatic mode, it will return to normal mode.

There is no other sample rate available.

One interesting thing I noticed is that if you continuously request data in the normal mode, the main data updates as it does on the display, and the secondary data for the bargraph changes rapidly. However, the main data does a proper update when in automatic.

As previously noted, the bar graph data has lower resolution but is MUCH faster, and if you look at the chipset datasheet, there are actually 2 separate A/D's.

By that, I mean that the conversion, and sample and hold appear to accurately support the higher data rate, it's not fudged or interpolated.

The USB communication is an HID class but does not enumerate to anything specific, so you need to interpret the data in raw mode. The chip is a CP2110 by Silicon Labs. Thankfully, their documentation is excellent and they provide 2 DLL's for communication and doing stuff like identifying the device and setting up baud rate. The same libraries are used by the Uni-T Utility, but are more recent on the SL website. 

Hope this helps.

Bob

[malagas_on_fire]

Hi i have a silly question... is this compatible with the portable scope uni-t 81b ?

I'm using a python program which can run on various Operating Systems using libusb.

http://www.lowlevel.cz/log/cats/hardware/Python%20software%20for%20scopemeter%20UT81B.html

It kind of works....

if not maybe it may become a new project....

[Edit]

PS. The only graphical languages used was C# for windows mobile / phone or Android Labview only in school and i don't remember most things.

[malagas_on_fire]

Now i have a new question... who wants the source code of the Android App  ?

[joeqsmith]

When I first decoded the packets from their Windows software, I saw them send out an AB,CD,4,0,5,1,A,0.   The meter then beeps and starts transmitting the data.   I sent this same code out even after the meter powered off and sure enough it would start to send.    Sending an AB,CD,4,0,5,0,9,0 and the meter would stop.    This worked fine up to the point where I had to recharge the batteries in both the meter and the BLE adapter.   After this, the meter will not send data.  If I use the USB cable, set the meter to connect and then plug in the BLE adapter, it works fine again.  I can connect to the BLE just fine.  The handle tables are all correct.   

I assume there is more to getting the meter setup than just sending this one packet.   Can you give me some idea on the proper procedure?

It seems you don't turn on remote mode on the DMM or the BLE-adapter needs some initialization.

DMM must beeps after each command. Short beep sound is meaning an error.

Some notes about the packet format. All (sent and received) packets have the same format:
2 bytes: magic bytes, always == 0xCDAB
2 bytes: payload size + 2
xx, ..., xx: some payload
2 bytes: checksum

Payload 0x05, 0x01 - monitor mode on
Payload 0x05, 0x00 - monitor mode off

Perhaps there is a minimum time between packets when sending data to the D07A.  I added a 500ms delay and a retry and it has been solid since.    I'm also rewriting my code to support the variable packet lengths.     


I have another question if you don't mind.  When I look at the float numbers, they appear to be followed by a string for the description.   The floats always appear to be 32-bit.   However, the string that follows does not always use the next byte following the float.   That byte may contain the actual ASCII character, a 0x20(space), 0x30 (0) and a few others.   It appears that for the first float, I could actually just skip the first byte but that's not the case for other strings.   Could you please explain what is going on?

[antage]

I have another question if you don't mind.  When I look at the float numbers, they appear to be followed by a string for the description.   The floats always appear to be 32-bit.   However, the string that follows does not always use the next byte following the float.   That byte may contain the actual ASCII character, a 0x20(space), 0x30 (0) and a few others.   It appears that for the first float, I could actually just skip the first byte but that's not the case for other strings.   Could you please explain what is going on?

main, aux1, aux2 values have additional byte after 32-bit float:

0 bit: positive overload (0L),
1 bit: negative overload (-0L),
4..7 bits: a number of digits after decimal point.

Unit is 0-terminated string but it has fixed length (8 bytes).

[joeqsmith]

With temperature selected, the byte following the second floating point number will be a 0x11 which is the same for the byte following the first float after the start.  However, when I select resistance mode,  the byte following the first float is 0x20 followed by the 0x7e ( the Omega).   The part I don't understand is the second float will be followed with a 0x7e and then a 0x00. 

So in some cases I seem to have to treat that first byte differently.   Does your meter behave differently?

[Brannigan]

The extra formatting byte is only used on values that will be displayed in one of the 3 aux bars below the main display.

The float without the extra byte is for the bar graph, which of course, doesn't have formatting, but does have a separate unit string, terminated with 0x00.

The "regular" modes (basic measurements) all have the same length (31 bytes including function ID) except for temperature which has 32, because temperature has no bar graph but has an AUX value for T1 or T2 and needs formatting.

Also, the overload nybble has an additional condition. If the value is >2, then it signifies "data not available", as in the case of autoranging, when the meter shows ---.-

 

[antage]

I've added partial protocol description: https://github.com/antage/ut181a/blob/master/Protocol.md
It covers measurement packet format only.

[joeqsmith]

First, again thanks to everyone.   I appreciate the dialog. 

Looking at the byte that may or may not follow a float, 

If the value is >2, then it signifies "data not available"

.   Antage's document shows the low two bits being defined.   Is a 0x3 an error (both over ranges set) or does it really mean the data is not available?

[antage]

Looking at the byte that may or may not follow a float, 

If the value is >2, then it signifies "data not available"

.   Antage's document shows the low two bits being defined.   Is a 0x3 an error (both over ranges set) or does it really mean the data is not available?

When you get 0x03 what the display shows?

[antage]

I wrote about 'data not ready' bits without checking.
Now I have checked and correct description: https://github.com/antage/ut181a/commit/2d5571e2ac8f3391b332469aafaee8759837a52b
Any of overload bits should be interpreted as 'data not ready'.

[joeqsmith]

Reading your document, the bargraph always follows the AUX channels.  If the AUX channels are not used, the bargraph would follow the Main channel.   The Main channel is always the first but the other three can change their position.    It appears this how the meter works.  I assume they do this rather than hard code their locations to try and minimize the amount of data they send.   

You start with 0 offset which I assume is after the AB, CD, length, length.  It seems one byte is not accounted for.  I attached what I am seeing for the first few bytes in a packet.

[Brannigan]

The byte 0x02, labeled is the packet ID, which tells what the response is, to differentiate it from other data responses, like recorded trend data, or saved measurements.

The auto and misc byte are a group of status bits, most of which correspond to annunciators on the LCD, like hold, record, HV, lead error and the rest are the AUX bits and modes (peak, maxmin etc), as previously discussed.

[antage]

Reading your document, the bargraph always follows the AUX channels.  If the AUX channels are not used, the bargraph would follow the Main channel.   The Main channel is always the first but the other three can change their position.    It appears this how the meter works.  I assume they do this rather than hard code their locations to try and minimize the amount of data they send.

You're right. If the packet has main and aux1 values the bargraph value follows right after aux1. If the packet has main value only the bargraph value follows after main.

You start with 0 offset which I assume is after the AB, CD, length, length.  It seems one byte is not accounted for.  I attached what I am seeing for the first few bytes in a packet.

I'll try to clarify frame format in the documentation.

[antage]

The auto and misc byte are a group of status bits, most of which correspond to annunciators on the LCD, like hold, record, HV, lead error and the rest are the AUX bits and modes (peak, maxmin etc), as previously discussed.

Thanks for pointing to additional bits (HV, lead error, etc). I've described it in the documentation.

[Brannigan]

You're welcome. The two upper bits, 14 and 15 do not appear to change, and there is one bit, bit 10, that I have very occasionally seen go to 1, but I have no idea why.

The measurement word (uint_16) consists of four nybbles for:

Rotary switch position,
SELECT button,
screen menu selections (left to right, top to bottom)

and the last one is a bit odd, it represents whether the F1 or F2 key has been pressed, but when you change the rotary switch, of course it defaults to F1 implicitly.

All values are one based as is the range info.

The Range byte is of limited use, because it just shows which range is in use in any given measurement, but tells nothing about the magnitude of the range. So, range 1 is the lowest range always. I used a look-up table driven by the measurement mode and the range value to get the actual numeric range and polarity e.g. +/- 60 or 0 to 60.

Edit: Added clarification, corrected typos

[joeqsmith]

Again, thanks everyone for taking the time to post some of these nuggets. 

Is bit 0 of the miscellaneous byte unused?

I was looking at some of the source code and noticed a test mode.   Can someone explain a little more about it. 


With the the 181A set to diode check mode and nothing attached to the meter.  The meter itself will display "OL", however the none of the bits 0-3 of the MISC1 byte are set.

[Brannigan]

I think you need to verify your test routine. On my meter, bit 3 (BAR) is set, in the diode mode.

Bit 0 applies to the first AUX bar, and it is rarely used, as it's position overlaps the bar graph.

Where you will see it set is in the MAXMIN mode.

[antage]

With the the 181A set to diode check mode and nothing attached to the meter.  The meter itself will display "OL", however the none of the bits 0-3 of the MISC1 byte are set.

When I set diode check mode I see:
misc1 byte = 0x08 (it has bargraph value)
misc2 byte = 0x01 (auto range is on)
precision byte of main value = 0x41 (positive overload and 4 digits after decimal point)

[Brannigan]

I forgot to mention:

MAXMIN is the one case where all 4 of the display status bits are set (Bits 0-3), but there is no bargraph preset.

I don't know if it's a bug, or if bit 3 has a different significance in MAXMIN mode.

Also, there are situations, like HOLD, where the MAIN display is shown in a small window in the centre at the top of the screen.

I can find no way, apart from HOLD, to indicate this display is to be used. It is also used in when viewing saves or records, but there seem to be no way to know remotely when it is in that mode.

[joeqsmith]

Yep, it was a bug in my decoding.  Thanks.  It's been great having people to bounce these questions off.   

The Hold mode seems to be a bit odd in that the meter appears to store up the readings for the bargraph. Once Hold is released, there is a burst of bargraph readings then it settles back down.   Could one of you please confirm if this is normal.  If it's normal, how do you handle it?  Flush all the data, display it? 


I started to look at the other modes (peak, min/max and rel).  That's the next thing to tackle. 

[joeqsmith]

I finished up the decoding logic.  The document was really helpful.  It would have taken me some time to sort out the the min/max function. 

Everything seems to work correctly except that somewhat odd behavior when selecting Hold.

I want to see how their software is slowing down the sample rate.  Maybe they just skip data points.   I also want to look into that diagnostic mode I mentioned.

[Brannigan]

I don't have any answers regarding the sampling rates, just some observations:

I did an extensive test with a low frequency, low distortion sine wave and the ~10 Hz sample rate is real. The values obtained are accurate to the expected values for that signal, to the resolution and accuracy of the meter.

So, all well and good, it's a nice feature when you are connected to a computer.

And then there is the update rate of the meter itself; 2 per second. Some people have a problem with that, but I'm OK with it, particularly with the fast bar graph. Fast changing numerical values and be difficult to interpret. A bit faster, or selectable would have been cool.

I did some reading about the A/D and multimeter subsystem chip and found that the conversion rate is 2/ second, so how they are getting 10/second I really don't know. It's been a while, but I wonder if the meter chip does averaging internally and it can be enabled/disabled.

Alternately, it wouldn't be the first time for a manufacturer to push a chip above spec, but 5x is a big jump.

One thing I noticed, and mentioned before, is that if the continuous transmission is selected (10 Hz), the MAIN data tracks the input signal at that rate and the BAR data is as fast, or likely faster than the 9600 baud transmission allows.

However, if you select the single reading mode, and run it in a tight loop, the BAR value changes very quickly, but the MAIN value update rate tracks the big display on the meter (2/sec)

I would be interested to see what you find out about the test mode. I know nothing about the Android app, but I am guessing/assuming that it is Java. Have you decompiled it with something like baksmali?

[joeqsmith]

I suspect the 181A's timing is better than what my software reports. 

When I started out on this project, I downloaded the Android app and ran it through some on-line disassembler.   I have no knowledge of Java and no desire to learn it.   So it was a short lived effort and I was on to sniffing the packets. 

I've never looked into the 181A's hardware outside of what I did for the videos I made.   Did you post somewhere about what you found?  Chipset used, tests ran, etc?

It's by far the best UNI-T meter I have looked at.  It's got a lot going for it but it's also IMO in need of some improvements.  I keep hoping they will come out with an improved version of the meter. 

[joeqsmith]

A few things that may be of interest.  Before I sorted out how to send data from the D07A, I would use UNI-T's software to setup the meter using the cable.  I then would unplug the cable from the meter and install the D07A and use my software.   

I use the UNI-T supplied software to set the data rate to 5 seconds and then install the D07A using my old software, it appears the data is still being sent at some very fast rate.   I suspect they just skip packets in their software.    Easy enough. 

Going back to my latest software, I connected a signal generator to the meter and press the Hold.  I wait for a few seconds, unplug the signal generator and release the Hold.  The meter does not appear to store of the data as I suspected.  Once Hold is released, you are back the the current data.  That answers that.   

I then slowed the signal generator to 10mHz.  Note the valid packet rate is 10Hz.   The primary display appears to be updating at one fifth of that or 2 times per second.   Obviously the bargraph is much faster, which is why I thought it was some sort of filtered value.   

So it appears there is no magic with their sampling.   Is this not what you are seeing?   

[Brannigan]

I got the information about the meter subsystem chip from another EEVblog Forum post.

https://www.eevblog.com/forum/testgear/uni-t-ut181a-pictures/

The chip in question is a Cyrustek ES51997

http://www.cyrustek.com.tw/spec/ES51997.pdf

I'm not sure what you mean by magic.  As I said before, the datasheet clearly states that the high res A/D has a conversion rate of 2/sec and yet the meter is outputting high res data at ~ 10/second. IIRC, the information at that rate was real and full resolution, but I will check it again when I have some free bench time.

AFAIK, there are only two sample rates via serial, for the full resolution; 2Hz and 10 Hz. The fast A/D for the bargraph is 600 count resolution and updates at 20 Hz, which might be doable over the serial port, if you have a tight loop, and there isn't much turnaround overhead in the meter.

I agree that any other data rate for the main display is a function of dropping samples and or averaging them.

Also, to repeat, if you request a measurement, rather that letting it stream at 10 Hz, the main display value changes at 2 Hz and the BAR value changes rapidly.

[joeqsmith]

What I mean by magic is that the meter is not by some unexplainable means, outputting a new data at 10Hz.   It sends a copy of the same data five times. 

So yes, they send out data at ten times per second but it only updates at 2 times per seconds. Is this not what you are seeing?

[Brannigan]

OK, now I'm confused.

I just did a test with my meter and the data is exactly as you say. With the 10 Hz automatic mode enabled, every 5 consecutive readings are identical, which is quite obvious.

I had previously (quite a while ago) done a test and convinced myself that the 10 samples per second were unique and tracked a sine wave correctly. This is why I could not understand the chip manufacturer's spec of 2 updates/sec.

I can not explain what I did back then, as a quick observation would tell me that the test was not even necessary. For now, I can only chalk it up to a major brain fart. I will investigate more as time allows.

So, the high speed update is of limited value unless one wants to access the faster, low resolution data. I suppose that the meter is also more consistent in timing, than doing a timed data request, but I seem to recall that it's not exactly 10 Hz or 2 Hz, but don't quote me on that.

[joeqsmith]

Ah, this make a little more sense now.  If I had to guess, you may have played around with the software they supply with the meter which doesn't show this level of detail.   

Yes, the advantage would be if you wanted to use the low resolution data.  I could also see with the amount of data they send, you could possibly handle cases where a packet was dropped. 

[joeqsmith]

I was working on my software for the UT181A and noticed a strange behavior with the meter.   I was feeding it with a 800uV pk sine and noticed that the meter seem to have a disturbance at 300uV with the slow hi-res ADC.   It seems repeatable but what is really strange is if I plot the fast low-res ADC, I see a very strange wave shape and it just happens to line up with the fast ADCs disturbance.  I suspect its a problem with that chipset they use.   

[Brannigan]

So, I replicated your test conditions and got pretty much the same thing, only worse.

I was using a ~ .07 Hz sine and found "The jump" occurred at around + 300 uV on the leading edge and + 100 uV on the trailing edge.

About 50 % of the time I would get a big jump (~100 uv and then it would fall back , in other words, go in the wrong direction.
I used the Uni-T utility just to make sure I wasn't seeing any bugs in my ongoing software development.
 
It strongly looks like some sort of hysteresis, but it's tough to tell if it's software or hardware. The anomaly doesn't occur at zero, nor is it symmetrical about zero, so if I had to guess, it's something to do with the digital calibration removing the DC offset, fighting with some hysteresis in the in the front end, but that's just a SWAG. Because it doesn't happen all the time, it seems to be timing interaction between when the input crosses zero and the meter takes a sample/reading, likely a settling time issue. It doesn't seem to get "stuck". which would be a real problem.

When measuring a similar DC voltage, it is tough to tell how fast it responds to slight changes. At 800 uV, you're kinda in the weeds and I don't have a fully shielded set-up for this quick test. That said, it does appear to stabilize fairly quickly. When I have time, I will test for monotonicity or missing codes. For now I'm a little disappointed, but I think it's just something to be aware of.   

[joeqsmith]

Thanks for checking.  At least I know it's not unique to this meter.

[spiff72]

Based on the work you guys have done with this adapter - do you see any reason that it wouldn't work with a Triplett 9065 meter?  This appears to be a rebadge of the UT181A. 

(In other words, would you expect that slightly different firmware would have any effect on it?  My intent is to use it with the Android app.)

[mjab]

Hello, was it possible to develop a ready-made program for Windows? Today I bought a UT-D07A module and I have the same problem as everyone else.

[ladnene]

Can you please share your labview software for UNI-T UT181A ? i need a quick datalogging multimeter to detect transient/fast signals ( between 10-100ms), in the datasheet it is written that the UT181A had a 10hz refresh rate which i hoped would be enought and it was the reason i bought this multimeter, but later when i plugged it with the PC i discovered it did send 10 mesures/s but it sends a new value only for each 2 values, so it had only 5hz in reality like i discovered in your videos ... hopefully the analog bargraph is fast enought to detect the signal but i can't find anyway else then your program to log it's data. Your software will help me read the bargraph values and spare some money which i really need lately. i have been looking for a link for your software for days now and no luck ... can you please help ?

[ladnene]

Anyway, i am starting my own custom software for UT181A multimeter, this is beta version : https://github.com/ladnene/UT181A_TOOL. i learned to code with python in the last 2 days and implemented these features so don't judge if you get any error  , will be implementing new features more and more like data reception over bluetooth and real time graphing. just sharing this with you in case someone needs it.

[pami3r]

Hi anybody can resolve the ut-d07 conection to windows? thanks

[pami3r]

Hi can you share your ut181a program?