Where’s my (Bluetooth) drill?

Industrial job sites are full of expensive tools, some of which wander off. We looked at this situation when we had a guest post about static asset tracking using Bluetooth. That was mostly looking at the RSSI of devices talking to a gateway and didn’t have any insight into the tool use. Today we’re going to introduce a more integrated version that talks to devices and also leans heavily into Golioth’s new Bluetooth-to-Cloud connectivity: we’ll have a device record on the cloud that shows power draw and the physical location of the device, based on which gateway it’s connected to. Let’s dive in.

Drill setup

First off, we should note that this is a prototype approximating many products already on the market. Toolmakers have a range of similar systems that are vertically integrated into their ecosystems:

• Dewalt Tool Connect
• Milwaukee OneKey

Ultimately there are tons of teams that are out there building similar capabilities over and over…but it takes a lot of people to implement. For a smaller team, it would require spinning up hardware, firmware, and cloud infrastructure to make it happen, before any of the manufacturing takes place. Sounds like a good candidate for Golioth’s IoT infrastructure.

The hardware is…very much a prototype!

I purchased an off-the-shelf battery compartment (made for DIY battery replacements, YMMV) and put my electronics in there. Then I found a 3D printed mount for the battery so it can plug into the bottom, using my custom hardware as a pass-through to tap into B+/B-. Finally, I hard wired a 10K resistor from the Thermistor blade to B+ in order to simulate temperature monitoring. Without temperature monitoring, only simple tools like LED flashlights would work, not more active devices like drills and impact drivers.

The end result is a stacked solution that can be added on to ‘any’ tool in this family of tools. I started imagining a 3rd party fleet management solution for job sites that could have similar capabilities across different vendors, since there’s no way to know if you’d only have one brand of tool (though the vendors would surely prefer that).

We are actively measuring voltage, current, and (calculating) power, which also can approximate usage and battery lifetime. Finding a suitable fuel gauge chip would be much better in this application, despite the mismatch in power envelope for most commercial chips.

Using Golioth’s Bluetooth-to-Cloud

The above setup was part of a previous hack day project that Mike wrote about last year. We implemented different Bluetooth devices without the Bluetooth-to-Cloud capabilities. We overloaded standard GATT messages intended for other purposes (heartrate monitoring, I think?) and instead pushed through whatever data we wanted…in this case the current draw of a drill. Hearts use electricity, so close enough for a hack day project, right?

This suffered from the same problem that most Bluetooth gateway projects do: once you have more than one device connecting through a gateway, it’s up to Cloud side processing to unwind the various UUIDs/MAC addresses that are sending data. You can send through all messages on a single stream, but then you need a parser to figure out which device is sending which data. What’s more, it requires increasingly complex gateway software to push control data in the other direction (down to devices). Using other Golioth features like Pipelines becomes increasingly complex. But no more!

I migrated the code for this drill over to our new Bluetooth-to-Cloud codebase that allows me to send data through our standard gateway firmware that I installed on the Thingy 91:X.

Sending through a gateway

Golioth’s new Bluetooth SDK makes it really easy to send data to the cloud. It matches the API that I use every day with the Golioth Firmware SDK,  which I put on a variety of Wi-Fi, cellular, Ethernet, and Thread devices. The key component is to format your text, pick a path where that data will be sent, and the system takes care of the rest. The difference now is that the data transits through a gateway.

For this device the sensor interaction was already written and so I pulled in the sensor code that pulls current, voltage, and (calculated) power from the INA219. I set my reading interval to every 10 seconds, so it’s not a high resolution capture of how often I’m hitting the trigger on the drill, but that’s something I could do in the future.

I also implemented RTT logging since my only output on this device is the 10 pin SWD cable coming out the side of the drill. After I program it, I keep the cable connected to my JLink and fire up RTT to see the logging data and interact with the device over the shell. Very useful.

Then as the data transits the gateway and the Golioth pipeline I set up,  I see it arrive in my device record for the drill

Append location onto Bluetooth device records

While our Bluetooth-to-Cloud capabilities have already unlocked a ton for simpler design of advanced Bluetooth devices, I wanted to take things a step further. Golioth enables the cloud on these super tiny Bluetooth devices, so let’s show it in action!

I had previously shown a program called n8n to create a geofence using an external location service to receive data from Golioth Pipelines and do interesting things with that data. That was before the Golioth Location Service was available and has enough steps to show just how much simpler things are now:

(This is all collapsed down to a single block now! Golioth Location Service makes it so much easier)

I decided to take a similar tact using Pipelines and n8n. When a device checks in on a stream path called ‘heartbeat’, it does two things:

• Grabs the time the pipeline was triggered and inserts that into the LightDB State record (our newest pipeline destination) to have a fixed record of ‘last check in’. This is metadata available on the console and REST API, but not directly to the device.
• Kicks off a webhook to n8n.

Once the data hits n8n…well actually, no, there actually isn’t any data! The heartbeat path was triggered with the smallest amount of data possible (a single character that gets thrown away). Here’s the sequence of events next:

• Receive trigger from Golioth Pipeline (empty data field).
• Do a GET call to the REST API for the Network, which returns which device ID the data transited through (the gateway’s information).
• Do a GET call to the REST API for the LightDB State information on the gateway, which has the following data on its ‘location’ path:
  • Latitude
  • Longitude
  • Accuracy
  • Timestamp of the location reading (seconds, nanos)
• Do a POST call to the REST API for the Bluetooth device’s LightDB State, basically copying this data over to the Bluetooth device.

Future work

So what’s next?

Well, that location data is very fake right now. It approximates the idea of gateways that are fixed, as is often the case, but doesn’t take advantage of all of the fun capabilities that the nRF9151/60 and the Golioth Location Service enable. So I am working on merging the Location + GNSS into this demo so we have a full end-to-end asset tracking system with precision location data.

I’d also like to make the devices be not-so-chonky. For the drill, I can’t imagine spending the time making a more integrated interposer device, but maybe someone who was building a fleet of device monitors would (that would more closely approximate what the tool makers build). I’ll be pushing this location capability into the AirTag Clone, which definitely benefits from location being attached to a device (you know…like an AirTag). If you’re interested in following along with that series, you can sign up to be notified about the next livestream here.  For other Bluetooth and hardware discussions, head over to our forums .