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?