My recent work with Dave testing Fluke Connect inspired me to take apart the Fluke 3000FC DMM. I wanted to see the Bluetooth Low Energy (BLE) parts and see how much power BLE consumes in Fluke Connect. In this post I try to reveal the good and the bad I find under the hood.

The enclosure is held together with just a handful of phillips screws. There is nothing tricky at all about taking it apart.

Bluetooth and Antenna

The Bluetooth Low Energy (BLE) antenna is a chip antenna in the top right corner of the board. The ground plane is recessed away from the antenna by 3.5mm. The antenna is connected to the BLE chip through just a filter and capacitor. There’s no pi or T network for matching. Usually a chip antenna’s impedance is highly dependent on the metal around it, and you need a pi network to hit 50 ohms. Although I did not measure it, I suspect it’s not well matched. The benefit of matching is questionable, though, when it’s just going to detune as soon as the user hangs it by the attached magnet to a metal rack.

Sitting on the bench, I get RSSIs in the -50dBm range on an iPod Touch a few paces away. There’s more than enough link margin to make it reliable in a room.

The BLE chip is a TI CC2564. This is a popular BLE controller with good output power (+12dBm) and sensitivity (-95dBm). Its antenna connection is single-ended 50-ohms.

When I opened the t3000 FC (see picture below) I found it uses a custom bluetooth module instead of a chip on the board. Most likely only the DMM has the Bluetooth controller built onto the main board because the DMM can act as a slave sending data to a phone or a master receiving data from other Fluke Connect devices. The other Fluke Connect devices support only Slave mode to send data to the app.

The module uses CC2541, a very common Bluetooth system on a chip containing an 8051 to run the stack and a Bluetooth controller. Unlike the CC2564 used in the DMM, this chip does not require another processor to run the stack. CC2541 is similar to the CC2540, which I see more often, but the CC2541 supports enhanced data rate (EDR) and has slightly lower power consumption during transmit. I wonder if there are any Fluke Connect products that need a high data rate?

Above is a picture of the BLE module with its shielding "can" removed.

The module has the same chip antenna as the DMM. There’s just an integrated balun/filter chip, no additional matching network. Ground plane is pulled back a few mm, but there are copper "etch" lettering right under the antenna. There is no way that antenna is well matched. At first I thought there was no mechanical retention on the back, but it turns out there's a feature on the back of the enclosure holding the card in its socket.

Chips and Circuitry

The main board is four-layers. There are two MSP430’s on the board. There’s a ‘5437 near the BLE chip, which I suspect runs the stack. There’s a ‘5435, which is just like the ‘5437 but with slightly less Flash. I suspect it runs the meter's firmware.

There is another chip closer to the input terminals that has a metal shield covering it. Lifting the shield reveals it to be LTFLK2 387248, possibly a customer chip used in measurement.

There is a buck regulator with a controller I can’t identify.

There is a 28-pin 0.5mm-pitch flat-flexible cable connecting the LCD display to the main board.

Power Consumption

When measuring its power consumption, it’s clear the meter spends most of its time in sleep mode, like any modern embedded system.. It wakes up every 250ms and pulls around 6mA for 20ms. Occasionally it pulls 50mA when it’s awake. I suspect these spikes are due to the measurement circuit.

When I turn on BLE advertising, I didn’t notice the spikes from its transmitting on the advertising channels. Once I connect to it with the Fluke Connect app, however, you can see a connection event every 30ms. Each connection event lasts about 1ms. The current draw peaks around 60mA during a connection event and averages around 40mA.





The BLE spec allows devices to skip a certain number of connection events (specified by the “slave latency” value) if there’s no new data to share. I set the meter to measure resistance and stayed clear of the terminals, so there should not have been even minor changes in data. The pulses kept coming every 30ms (called the “connection interval” in BLE), regardless of mode or whether the data changed.

Current draw when not using BLE:

4 wakeups per sec * 20 ms/wakeup * 6 mA + 1 high-current-event/sec * 20ms * 50 mA = 0.48 mA + 1 mA = 1.48 mA

Connecting to the meter by BLE pulls additional current:

33 connections per sec * 40 mA * 1 ms = 1.32 mA.

A typical AA alkaline cell provides 2 Ah of charge. 2Ah / 1.48 mA = 1350 hours

With BLE connected: 2A / (1.48 mA + 1.32mA) = 714 hours.





So BLE is a significant part of this meters power budget, but not so much so that users need to keep in mind whether they’re going to use it and turn it off. It’s enough, though, not to keep it connected all the time.





The Fluke 3000 FC technical datasheet specifies a minimum battery life of 250 hours. This testing suggests typical battery life is much longer, especially if the Fluke Connect function is not used all the time.

Conclusion

The two devices I opened remind me of any embedded system designed for rugged applications. The board on the DMM is just MSP430s and TI BLE chips, very ordinary in this regard. I suspect the chip under the shield is a custom part for switching in the voltage dividers that give it its dynamic range and robustness against exposure to different loads.





The lack of a matching network and the antenna being located so close to copper features (especially on the module) looks bad, but I had good results in practical testing walking down the hall.





I liked that the current draw appeared to be low enough to provide more than the specified battery life. It would be nice for Fluke to create a BLE Profile for meters. Such a Profile could allow skipped connection events when the data doesn't change.





Earlier Posts on Fluke Connect



Part 1: Introduction and Exploration

Part 2: Investigation on the Single-User Case

Part 3: Collaborating with live data and video conferencing