Your experience/opinion: Adding Bluetooth to handheld meters

[shakalnokturn]

I have a stack of handheld meters, LCR, DMM, current clamps, most of which support a serial link, some already have the I.R. hardware, on others it is optional or needs breaking out of the I.C.
If I must go to the bother of modding the hardware as in some cases the I.R. addon module is unobtainium, it seems to make more sense to use Bluetooth than I.R. these days.

I have no experience whatsoever with the cheap BT modules available. In fact I don't have much experience with BT at all...
Would they require joining a small dedicated microcontroller for initial setup in the DMM or can that be done once before embedding and stored non-volatile in the BT module? What are the constraints linked to pairing?

On the PC logging side is there any open-source software that would handle most meters or is it a case of using the specific data logging software each time?

Who has done it before? I've seen a couple of Flukes around here with added BT not sure of all that was involved though.

[DDunfield]

I've fooled around with the cheap HC-05 (master or slave) and HC-06 (slave only) modules you can get from Ebay a bit.

You will need to communicate with it initially (AT commands) to set it up (baudrate and other options) and pair it.
On some of the modules you need to pull a pin either high or low to get it into AT mode.

Once set up, it should "just work". I am able to connect to them from windows (BT COM port) and also from a "Bluetooth terminal" application on Android. You can also use an HC-05 module to connect to another HC-05 or HC-06 module.

Be careful powering it, there's a number of slightly different versions of the modules, some run on 5V, some on 3V, and some can run down to 1.8V.

There's a bunch of Arduino oriented tutorials available which might help you get started.

Dave

[shakalnokturn]

@DDunfield: Thanks for the advice.

I've given this a first try on a Metrix MX53 (BK Precision 5360).
For now using Windows 7 and SX-DMM V2.9 with a USB BT dongle (IS1601N-G / IS1002N-307G chips), I'd like to upgrade to windows XP but stuck for now due to this problem: https://www.eevblog.com/forum/testgear/sx-dmm-seeking-old-versions-of-the-bk-precision-metrix-software/

On the DMM side before messing with the DMM's PCB itself I've followed the IR route for now: A phototransistor and IR LED are fed to a JDY-31 Bluetooth module.
The module has previously been renamed and set to 2400bps via USB to UART.

No problem getting the DMM to throw the data out to Realterm over BT using the DMM's "Print" key. BT connection stays active, module's status LED is constantly ON.

Now, problems start when trying to use the dedicated SX-DMM software, no way to get a connection.
The software normally makes 3 attempts to request DMM status by sending 35+CR, the same attempts over BT seem to fail because the BT link goes back to standby (status LED blinks) the SX-DMM does not keep the BT serial port active as Realterm does. Each time status request is transmitted the BT attempts to go active again but is too slow for the DMM to respond in time.

Attached screen captures of normal and failing status requests.

Any way I could trick this connection to remain active, I've been through windows but haven't stumbled on it yet. Maybe a registry entry for the BT serial port?

[DDunfield]

Where are the "+CONNECTED" and "+DISCONNECTED" strings coming from?  Is this from the meter?  or the module? or the windows bluetooth stack?
You show the messages in a TTY program (which shouldn't be fooling with the control signals, but it might manipulate CTS if it thinks it's talking to modem). Software designed to talk to the meter might be using control signals to enable/control a proprietary interface.

What exactly are you doing to cause the connect/disconnect messages?

When I played with the modules they remained connected until I disconnected them. You mentioned an IR link between module and meter, I assume you only have RX/TX to the meter?
Perhaps the software is fiddling with the RS-232 control signals and causing a disconnect from the windows side?

It is also possible that control signal changes from windows are being copied through the bluetooth connection and seen by the module as a request to disconnect (especially if they are looped back on the module end as it common with three wire connections). If this is the case, and you can NOT loop them back that would probably fix it. Otherwise, check out the available options on the module, there are quite a few settings, you may be able to disable it.

I would probably try an HC05 module configured as host on the windows side connected to an actual serial port  (USB<>Serial 3V) .. this would let you trim it down to just a three wire interface on both sides, which should NOT disconnect. While you are at it you could look and see what the RS-232 control signals from the PC are doing. If the connection works and you see control signals changing from the PC, then likely the windows bluetooth stack is interpreting this as a request to disconnect.

Assuming that proves to be the problem, then how to fix it is another matter... I'm assuming you don't have the source to the program you are trying to use so you can't disable it from changing the control signals. I can think of a rather messy hack ... use "com0com" to set up a virtual null modem, and write a small program to copy data between one of them and the bluetooth COM port without copying changes to the control signals. Then you connect the vendors software to the other com0com port and it can do whatever it wants to the control signals, only the data passes through.

Dave

[shakalnokturn]

A little more detail on the previous results:
For now I basically have two IR interfaces one is my own design with the attached JDY-31 module, the other is an official Metrix interface designed for the MTX3281(/2/3) DMM's, that will work with the older models. It is CP2102 based, only Rx/Tx are used for communication, the other lines are there as power to the IR section. (Attached IR section photos.)
This adapter can be used with the SX-DMM software and chat with the DMM no problem.

The previous screenshots were taken with both IR interfaces face-to face while asking the SX-DMM software to query the DMM status (DMM not present).

In the first case the wired interface (COM9) outputs the three 35+CR requests that are captured by the IR+BT interface on the terminal (COM14).

In the second screen capture the IR+BT interface is on the SX-DMM software (COM14) while return is captured by the wired interface on the terminal (COM9).

I'm guessing that the "+CONNECTED" and "+DISCONNECTED" messages are issued by the JDY-31 as they start with the "+" character.
The 11:11:11:11:11:11 MAC is that of my BT USB dongle so I think it is really windows/SX-DMM software telling the BT link to sleep, if I send the 35+CR request with the terminal program trough IR+BT the DMM responds with the status string immediately.

Is there an alternative BT stack I could try that has more tweaks to it than the windows 7 has?

[Psi]

You can get automatic Bluetooth serial port modules for cheap from aliexpress.

No need to set baud with AT commands or anything. When you open the port in windows the driver sets up the link automatically at the baudrate you opened the connection at. And they include error checking/correction. From the device and app perspective it's just a normal serial port link

So you would simply attach the BT module to a UART and it would work.

The main issue you're going to run into is battery life, With BT active your meter batteries are going to run flat super fast.
Another issue is that they dont all support some weird uart formats like 7bit or 9bit or xor or weird start/stop bit combos. (or maybe they do but you need AT commands, i dunno)

[shakalnokturn]

@Psi:

Would you have a link or model number for such a BT module?

As for power consumption I'm not too worried, I intend that the BT module will only be powered when the DMM is in communication mode.
With the module I'm using now measured consumption is 32mW with connection active. If I go to the trouble of throwing in a switching converter for the 3.3V that will draw something in the 4mA range from the 9V battery, once the original IR interface in the DMM is disabled I'm not sure I'll be much worse off for battery life compared to the factory solution.

[Psi]

@Psi:

Would you have a link or model number for such a BT module?

As for power consumption I'm not too worried, I intend that the BT module will only be powered when the DMM is in communication mode.
With the module I'm using now measured consumption is 32mW with connection active. If I go to the trouble of throwing in a switching converter for the 3.3V that will draw something in the 4mA range from the 9V battery, once the original IR interface in the DMM is disabled I'm not sure I'll be much worse off for battery life compared to the factory solution.

My one is old and doesn't have a model number on it.
They are super cheap, like $3 inc shipping so get like 3 or 4 different types and see what works.

This one looks visually very similar to mine
https://www.aliexpress.com/item/HC-06-Bluetooth-Serial-Pass-through-Module-Wireless-Serial-Communication-HC06-Bluetooth-Module-for-arduino-Diy/32857133517.html

Note that all the BT modules ive seen are 3.3V date lines, so you will have to check your meter uart is 3.3V
If it's 5V you will need a voltage divider to stop the 5V damaging the BT module

Also looks like that one above only supports the normal  8 data bits, 1 stop bit, no parity

[DDunfield]

I'm guessing that the "+CONNECTED" and "+DISCONNECTED" messages are issued by the JDY-31 as they start with the "+" character.
The 11:11:11:11:11:11 MAC is that of my BT USB dongle so I think it is really windows/SX-DMM software telling the BT link to sleep, if I send the 35+CR request with the terminal program trough IR+BT the DMM responds with the status string immediately.

Is there an alternative BT stack I could try that has more tweaks to it than the windows 7 has?

Exactly which bluetooth module are you using?

It seems unlikely (but not impossible) that windows is injecting data into the serial stream, a little bit of looking, and it seems +CONNECTING, +CONNECTED and +DISCONNECTED are messages sent out from some bluetooth modules - which would also explain the mac address. It is entirely possible that the module is sending a connected message into the meter and possibly getting echoed back to the PC causing the meter and/or software to get confused and disconnect. Exactly how that disconnection is happening is yet to be determined, but likely involves serial control signals.

You may be able to turn these messages off, but you need to find the documentation for exactly the module you are using -- and be warned that there are different firmware installed in what otherwise appear to be the same modules which causes them behave differently.

I would still recommend setting up another module as host and eliminating windows entirely from the equation until you have determined exactly what the modules are doing. I would start with a just TTY program connected to each module (that's how I got them going initially).

I don't know what options are available for windows bluetooth stacks, but if you have an android device available, there are a few free "bluetooth terminal" apps available.

Dave

[DDunfield]

This one looks visually very similar to mine
https://www.aliexpress.com/item/HC-06-Bluetooth-Serial-Pass-through-Module-Wireless-Serial-Communication-HC06-Bluetooth-Module-for-arduino-Diy/32857133517.html

This is an HC06 module, which is the client only version (cannot be a host). It definitely has an AT command set, and as far as I know requires use of an AT command to change the serial speed.
It is entirely possible that there's some sort of automatic mode that I have not discovered, but googling "HC-06 change baudrate from windows" only turns up posts from people who say they've not found any way to do this.

Here's a site with some info on the AT commands, including command reference documents for the HC05 and HC06 modules:

   https://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/


If there is another cheap module type available which does automatically follow windows serial port configuration, I would love to know about it as that would be very useful. Setting them up via embedded AT commands is a PITA.   I assume they would still need some sort of configuration mode however as you would need to set the Bluetooth name, pairing code and enable/disable pairing mode.

Dave

[Psi]

i'm like 99% sure i have used my one on many baud rates and it just works.

But i cant say im 100% sure. I always thought it was automatic and told the BT module to begin at whatever speed the windows driver opened the port at.

Maybe ive only ever used it at 115200 and never realized.
Or it maybe different to the one i posted the link to. Or runs different firmware
I've definitely never sent a AT command to it.

[DDunfield]

i'm like 99% sure i have used my one on many baud rates and it just works.

But i cant say im 100% sure. I always thought it was automatic and told the BT module to begin at whatever speed the windows driver opened the port at.

Maybe ive only ever used it at 115200 and never realized.
Or it maybe different to the one i posted the link to. Or runs different firmware
I've definitely never sent a AT command to it.

If you can figure out what it is, I'd like to know. Are there any markings on it?
How about post a photo (both sides if there's marking on the bottom).
I'd like to find out what it is as I'd really like to have a module that works like that.

Q: How did you pair it?  Perhaps it's auto-pairing if not connected?

Dave

[babysitter]

PSA for the lazy ones, Hewagikeysight has the U1177A for their series of orange handheld meters.
I bought my handheld when there was a promotion where you got the Bluetooth "backpack" for free. Also (still?) for free you can get a logger software for mobile phone.

[Dundarave]

I think your connectivity issue may be a result of using incompatible BT modules:  the JDY-31 spec indicates that it supports BT 3.0, which I believe is BT Low Energy, as opposed to your USB module which appears to be the older 1st generation BT protocol.  You might want to check this, as they are not compatible at all.

As Dave would say, “a possible trap for young players”:  I’ve wasted more hours than I care to admit to troubleshooting a similar issue as I was getting acquainted with the BT protocol as a newbie.

[Psi]

i'm like 99% sure i have used my one on many baud rates and it just works.

But i cant say im 100% sure. I always thought it was automatic and told the BT module to begin at whatever speed the windows driver opened the port at.

Maybe ive only ever used it at 115200 and never realized.
Or it maybe different to the one i posted the link to. Or runs different firmware
I've definitely never sent a AT command to it.

If you can figure out what it is, I'd like to know. Are there any markings on it?
How about post a photo (both sides if there's marking on the bottom).
I'd like to find out what it is as I'd really like to have a module that works like that.

Q: How did you pair it?  Perhaps it's auto-pairing if not connected?

Dave

I had a closer look at it and pulled off the sticky tape & heatshrink off it.
It says HexTronik
3.3V level
Supply 3.6-6V
HB-02

EDIT:  I connected the output to the scope and paired my PC to it. Then sent it data at a few baud rates.
Looks like the others were right, it doesn't seem to auto switch.
I must have only ever used it at 115200, so never knew it was fixed to that.
Sorry to get your hopes up

[shakalnokturn]

Thanks for all the input.

What kind of IC does that HexTronik HB-02 module run?

Logger software for your smartphone, I like that idea although I don't own a Keysight DMM, for now I don't have a laptop that will run the logging software for my meter. Is there any Sigrok-like for Android?

I've just tested the Toshiba BT stack without changing anything else to the setup and it all runs like a charm.
Even the calibration software will run if BT serial is forced to COM1 or COM2.
Not sure why the Toshiba stack is a 30 day evaluation version, maybe due to not running on Toshiba hardware?
The other odd thing is that the Toshiba software never asks for the pairing code, even if I delete the connection. Could that have anything to do with not deleting the connection from the Windows 7 BT before installing the Thoshiba one?

[Psi]

What kind of IC does that HexTronik HB-02 module run?

BC417143

[shakalnokturn]

What kind of IC does that HexTronik HB-02 module run?

BC417143

I have a similar one with the same IC.

I ordered 3 cheap modules from Aliexpress with different IC's, the similar one is item 32633767613 sold as a HC-05 / JY-MCU, with BC417143BQN and MX29Lxxxx flash.

Then there's a DX-BT16 / ZS-040 item 32797495268 with AB1602Q16BL38 and 24C32

And the one I've been focussing on up to now the JDY-31 item 32657800452 with BK3221S, I've been using this one because I've had trouble throwing AT commands at the other two, but I'll get back to that later.

In the meantime I've had access to a recent laptop with integrated BT (certainly BT3.0 and above) running Windows 10 and Windows BT stack. I ran into the same connection problems using the Metrix software as with Win7 BT stack and my old USB BT dongle.

[DDunfield]

And the one I've been focussing on up to now the JDY-31 item 32657800452 with BK3221S, I've been using this one because I've had trouble throwing AT commands at the other two, but I'll get back to that later.

There's a lot of variations. Some modules go into "AT command" mode when not connected, some require to be powered up with a certain pin set (sometimes there's a switch on the board).

Also, some modules don't rely on a CR terminator, but time-out to determine when the command has been entered, which makes it hard to manually type commands into them.

And... there are different versions of firmware floating around so even modules which are supposedly the same type can behave differently.

Dave

[Psi]

Be interesting to make double BT link.
One link that does the COM port and a MCU at each end to monitor/measure baud/bit settings on TX/RX and send needed AT setting changes to reconfigure on the fly.

You could probably build a system like that with a single single BT based MCU at each end (like nRF52) since most of them have BT stacks that support multiple simultaneous BT connections.

Sounds like a cool open sounds project for someone.
A nRF52832 COM port link with automatically handling of the band/bit/stop.
Nordic probably have a COM port SDK example already, so most of the code is already available. Just need to glue it together.

[shakalnokturn]

I've been able to use the HC-05 module too, although the PDF document for this module (at least the one I have) states 4800 as the minimum baud, the module will accept to go down to 1200bps.

The DX-BT16 module's minimum is 9600bps, this one won't be much use on the old Metrix meters that require 2400 or even 1200bps for the MX240 clamp meter going by the scarce documentation available.
It may find a place in the Fluke, Brymen or Gossen though.

Next problem with the old Metrix's is that there is no output on the microcontroller that can be used to enable power to BT only when the DMM is in communication mode.

There are two different communication modes:

Print key: A interval is set on the meter and stored in EEPROM, the meter transmits data at this interval. "RS23" LCD segment is active during Tx time.

Slave mode: The DMM is controlled by the Windows software and only transmits when requested.
The "RS23" LCD segment is the only one active on power-up.
To further complicate the problem, on normal power-up (RS232 inactive) there is a LCD test with all segments active.
The LCD is 4 com 1/3 - 2/3 Vcc muxed so it looks like this project is going to require a PIC10F322 or ATtiny for BT power management.

[iMo]

The HC-05 modules (at least 6pcs here) go into "idle" mode after 5secs of inactivity at their serial tx (input to the module). When active the current consumption is around 20mA, when idling 2mA.
The modules wake up only when they receive a char from the PC (via air).
When in idle they ignore the data coming to their tx input. Thus you do not get data into your PC (and the data are lost).
Pretty annoying feature, no idea how to switch the idle mode off..
Most annoying when you send results off your MCU with say at 6secs period

[shakalnokturn]

I'm un-burying the topic almost a year later, many other things to do in the meantime... I finally got round to finishing the first attempt.

The first one wasn't a MX53 after all:
I came across a i-Mesure IM-9916, a cheap new Uni-T UT61B knock-off on evilBay a while ago and thought it would be an easy one to start on.

The DMM is a 4000 count model based on the Fortune Semiconductor FS9922.
Although the DMM uses a 9V battery this regulated down to 3V to power the FS9922, convenient for the Bluetooth module too.
The FS9922 has an open collector TXD output that drives an IR LED through a 1kohm resistor, I left this untouched.

The 14bit, 2400baud data output is enabled on the DMM by a long press on the "REL" key, in idle state TXD is held high by the IR diode and 1kohm resistor.

I opted for a PIC10F222 because of the SOT-23-6 footprint and availability at my usual supplier. An awful little microcontroller that seems well suited for this kind of task.
(Re)learning the PIC ASM took me a little extra time, I'd hardly done it before and many years ago.

The program monitors the TXD from FS9922, and switches the power to the BT module accordingly (a monostable with kinks). The initial plan was to use a P-MOS to switch the BT module's Vcc, that caused me unexpected problems as the inactive high TXD was apparently almost powering the BT module through the BK3231S's input protection diode.
Having spare pins (it has so many!) on the 10F222 a few extra lines in the main test loop pass the TXD through (adding unwanted delay and jitter but not enough for data errors) and hold it low when inactive rather than high. I also used the remaining output to drive a N-MOS and cut supply on GND as an alternative, simpler and works just as well.

The JDY-31 BT module was configured before hand with the right baud and giving it the DMM's name and serial number for easier identification.
PIC and N-MOS mounted "dead-bug in amber" style are in a blob of epoxy on the BT module itself.
BT module then glued on a wedge in what seemed to be the most sensible spot.

The current consumptions where measured for Vbat= 8.5V before and after modification.

Before:

Off:   810nA
DCV: 2.1mA
ACV: 3.1mA


After:

Off: 840nA
BT active:
DCV: 10.5mA
ACV: 11.5mA


The DMM is currently doing a test run on a 9V Ni-MH battery logging the temperature in my freezer to the official UT61B software.

[EEVblog]

With Bluetooth (not Bluetooth BLE) you can likely just feed in the existing serial output of the meter and make it appear as a virtual serial port on your PC via the Bluetooth.
In theory it would be as simple as just wiring in an existing module.
When we developed the 121GW we thought it was possible to do this with the Bluetooth BLE module, but after months of R&D we came to the conclusion that's BLE sucks in regards to serial part interfaces, it's just not designed for that.

[shakalnokturn]

Thanks for the (discouraging) input in BLE Dave, I was interested in BLE, figured it was much more interesting for the application considering the lower power consumption, a shame it's a PITA to use for RS-232...

The SPP (non-BLE) module glued-in here is used exactly as you suggest. All the PIC does here is switch the power as I didn't want the BT module constantly draining 8mA for a seldom-used function.
I'm pretty what I've done with the PIC could have been done directly in the BK3231S IC's ARM968 core if I'd had more information on the IC and more experience in microcontrollers.

[EEVblog]

Thanks for the (discouraging) input in BLE Dave, I was interested in BLE, figured it was much more interesting for the application considering the lower power consumption, a shame it's a PITA to use for RS-232...
The SPP (non-BLE) module glued-in here is used exactly as you suggest.

If you are keen to see what we had to go through to get the BLE working, the source code is on Github.
BLE simply doesn't natively support serial port mode like full Bluetooth does, so you have to kludge it into working