Decoding the MEET MS-BDTP1A Multimeter Bluetooth

 Meet the MEET MS-BDTP1A multimeter!

The MEET MS-BDTP1A multimeter is a cute battery-powered, very portable, pen-style multimeter. The maker has a handy web page  with the full specs. This is my second successful multimeter; the previous one was the ANENG 9002 which has the BDM protocol described up on GitHub.

The DMM itself is pretty nice. It handles all the things a portable DMM should, like resistance, volts, and current, plus the typical add-ons like a diode reading and continuity.

Investigating the services and characteristics

Using my new Bluetooth app showed that the device uses service FFF0 like the BDM type multimeters, but using characteristic FFF1 and not FFF4 like the BDM. Setting up the notification for FFF1 shows a stream of data coming in, all 15 chars long, looking like this: "18 27 3D 4E 5B 66 72 86 92 A2 B1 CA DD EE FF"

Copilot and Github both report failure in decoding it. Copilot says it looks like an LCD type interface, so it's similar to the BDM protocol, but it's a different length. Also, looking at the hex dump, the top 4 bits are just the numbers 1 to 9 and A to F, in order, so clearly they are some kind of check for bad transmissions.

LCD type interface

A bunch of these multimeters used an LCD screen interface for their Bluetooth. There's companies that will make a nice one-chip DMM solution, but without a Bluetooth interface. Instead, the company making the DMM has to jury-rig something in. Since the only data they have access to is the data bus leading to the LCD screen on the DMM, they just dump the raw LCD data straight to Bluetooth.

This means that each segment of the 7-segment display gets it's own separate bit in the output, and they aren't going to be neatly bundled together. 

BTW, if you aren't familiar with 7-segment nomenclature, each segment is given a letter A to G, starting at the top segment A and going clockwise and ending the  middle segment called G. I've added a picture from the Fortune spec sheet. To the left of each digit is a decimal point (or, for the leftmost digit, a negative sign).

The Bluetooth interface is over Bluetooth, of course. But since some these devices used to provide data over a RS-232 serial port interface, they are often documented as an RS-232 interface. 

Reverse-engineering the LCD interface

After some thrashing around, the successful steps for reverse engineering were:

Start by exploring some data sheet. Asking Copilot for DMM chip spec sheets. This brought up the Fortune FS9731 device where the RS-232 interface matched the style of the data I was seeing. Notably, the top four bits are doing the "counting up" thing. 

Here's the Fortune RS9731 spec sheet RS-232 data. You can see the 1X 2X 3X etc which matches the kind of data the Notify is providing.

When I compared my notify data against the LCD data, it absolutely didn't match at all. 

Find a spec sheet that's a better match. I found a spec from the same Fortune company where the spec sheet matches the specs of the MEET device. The MEET device says it's a "2000 count" aka "3½ digit" display, which matched the Fortune FS 9952_LP2 spec. That spec sheet didn't include any RS-232 interface but it did include a LCD screen map. And their LCD screen picture kind of looked like the screen in the MEET device.

Here's the Fortune FS 9952 LCD display spec.

To convert this into code, I just had to decode the bottom table. The first four columns aren't useful; it's the next that have the real data. The data as transmitted is the SEG1 in the bottom bits of the first byte, the SEG2 in the bottom bits of the second byte, and so on.

Note how the data is scattered seemingly at random. There's some hints of a pattern, but not enough to really write code for.

And it all worked!

 After a bit of fiddling, I could update my BDM Multimeter display to also support the MEET MS-BDTP1A multimeter. Here it is in action:

Total time: Exploring the protocol and comparing to BDM protocol was < 8 hours. Finding the right spec sheet was about 2 hours of work. And the actual code modifications was 4 hours.