jtcash / OwonB41T

A Windows Bluetooth(BLE) client for the Owon B41T+ multimeter. Any BLE adaptor is compatible, so no dongle needed!
The Unlicense
15 stars 4 forks source link

Idea #1

Open Kabron287 opened 3 years ago

Kabron287 commented 3 years ago

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.

jtcash commented 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.

Kabron287 commented 3 years ago

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

Kabron287 commented 3 years ago

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?

jtcash commented 3 years ago

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.

jtcash commented 3 years ago

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.

Kabron287 commented 3 years ago

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  ...........!.....
jtcash commented 3 years ago

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?

Kabron287 commented 3 years ago

Data was collected from serial port. First 11 bytes are always the same. So, the payload, really, is last 6 bytes.

Kabron287 commented 3 years ago

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.

palmerr23 commented 2 years ago

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?

Palingenesis commented 1 year ago

I have done a User Interface, see my pull request.

palmerr23 commented 11 months ago

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.

Palingenesis commented 11 months ago

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?

palmerr23 commented 8 months ago

BTW: I solved the dongle issue with a simple ESP32 program. https://github.com/palmerr23/Owon_B41T

Palingenesis commented 8 months ago

It's much appreciated.