Open Kabron287 opened 3 years ago
Interesting idea! I'll look into what exactly this would require on my end. I am unfamiliar with the protocol for the UT61 series, but I will look into that as well. From a bit of quick research, it seems like the UT61E uses a very different communication protocol, but I'll do some more digging.
It would be really interesting to make the B41T compatible with existing multimeter software.
Look datasheets (ES51922.pdf for UT61+ and ES51932.pdf for b41t+) and as spoken find 10 differences. But the intrigue is more deeper. Here is the story. Owon stated that PC SW works only with coresponding BLE dongle: https://www.amazon.com/Multimeter-bluetooth-dongle-connecting-software/dp/B07JBK6M4T. I made a search on aliexpress and found similar look like: https://aliexpress.ru/item/4000015140705.html? build with CC2540 TI chip. Then I rummaged in my mess and found the following: https://aliexpress.ru/item/4000028865267.html? It was flashed with TI CDC example FW. I try it and it worked fine with Owon PC SW! Next day the SW started to glitch. It finds no COM ports. I began a chat with owon support. Their main questions were: do I have an apropriate dongle and where did I bought it? When I said them about amazon, uploaded screen-shots of the worked SW and suggest to return to the SW bug subject, they suddenly end chat and I could not begin it again. They suspected something. Because if everybody will use another cheap dongle they loose the money. So, your Software is just a bomb. But lets go futher. The Windows BLE capabilities are in rudimental state. E.g. I use CSR BLE dongle. It does find almost all BLE devices, but could do nothing with most of them. Thus my next idea is to make SW which could connect to any BLE dongle with CDC class support, also forming transparent Virtual COM port. It'll open possibilities to conect to wide range of devices: USB testers, multimeters, power supplies, etc. Please, consider also this variant. ES51932.pdf ES51922.pdf
Hi there, I'm trying to play with your code adding serial output. But, it is rather difficult for me to understand your style. Would you be kind to address me to the code where RAW data from b41t are available?
The raw data comes in through the ValueChanged event handler callback, which I register in B41T::registerNotifications(). The meter sends GATT notifications containing the raw data on handle 0xfff4 whenever the display updates and during offline data downloading.
Are you trying to get the raw data output to go directly to stdout or something? I could make a command line argument like "--raw" to make that happen if you'd like, that would probably only take a couple of minutes.
Also, I have some free time today, so I'll be taking a look at all those links you sent in the former comment.
Also, sorry if my code is not the easiest to follow. Microsoft's BLE examples are even more convoluted, which leads me to believe there is no clean way to write code for handling BLE connections. I'm looking into ways to clean things up by having the notification handler pass data to a queue which would be processed by another thread, but that might just add more unnecessary layers of complexity.
Right now, my code is not perfectly thread-safe. It relies on the fact that packets are spaced far enough apart that the event handler finishes before the next packet arrives. But on a heavily-loaded computer this might not always be true.
Hello, Here is what Multimeter send to Owon PC software via CC2540 dongle while measuring temperature. So, I expect to find similar data while debug your SW. But I saw only 6 byte payload, corresponding with sniffered data but not complete. Researching inet I realized that realization virtual port in custom SW is not a lite task. But ordinary COM port exchange is not a problem. So, the solution is to send serial data to already created virtual com port, say with eltima SW, or any, e.g. I like VSPE from WWW.ETERLOGIC.COM.
04 ff 0e 1b 05 00 00 00 08 2e 00 21 f2 00 00 cc 05 ...........!.....
04 ff 0e 1b 05 00 00 00 08 2e 00 21 f2 00 00 cc 05 ...........!.....
Interesting. Does 04 ff 0e 1b 05 00 00 00 08 2e 00
ever change during readings? I recognize 21 f2 00 00 cc 05
as being a measurement of 148.4 Celsius, but I have no clue what the rest of that data you're seeing would be for.
I plan on doing a full writeup of this, but I'll give a quick overview of how this data is structured: The GATT notifications from the meter contain 6 bytes of data, broken into three 16 bit words (little endian). The first word encodes which function the meter is in, the scale of the reading (kilo, mega, percent... etc.) and the magnitude of the reading (the location of the decimal point). The second word encodes the modes of the meter (hold, min/max, autorange... etc.). The third word is the actual reading in an integer signed magnitude representation, which must be combined with the magnitude value to get the real reading.
I see all of that data in the last 6 bytes of the data you provided. Is that the raw BLE data you sniffed from the communication, or is that what the dongle sends to a COM port?
Data was collected from serial port. First 11 bytes are always the same. So, the payload, really, is last 6 bytes.
I added serial output to your SW, but the problem I realized too late, is that BLE chip in the Multimeter flashed with FW that converts original protocol ES51932 to what we see. So, universality is not so near. RTFM unambiguously.
Thanks for the software, the basic version works fine, however I'm more interested in getting it to work with TestController and a virtual serial port would enable that.
Did you, or Kabron287, get the virtual com port working?
I have done a User Interface, see my pull request.
Sorry about the delay, the notification got lost somewhere.
Your pull request is for your repo, not mine. I'll add a note in mine that you've done this work.
No worries, you have done the hard part.
I have done some work on your part of the code C++. Not sure if I have sent a pull request for the latest I have done. I recently upgraded to a Windows 11 machine. Not good with C++, but I managed to pull some hair out and your code now works with Windows 11. It was a need to do it, basis haha.
Also sending pull request and using Git in general is new to me, sometimes I end up sending lots. (apology if I send lots) I use Visual Studio 2023, Git is now part of the IDE so I am starting to use it. Shall I send a pull request for the latest? Make sure you have the Windows 11 update?
BTW: I solved the dongle issue with a simple ESP32 program. https://github.com/palmerr23/Owon_B41T
It's much appreciated.
Hello, again. Before developing GUI, I have the following idea. Could you modify the current SW to create a virtual passthru COM port which will passed RAW data in both directions. It'll allow to use numerous softwares for UT61 devices which has the same protocol as B41T. It'll be a great cherry on the cake, I guess.