Dewalt Hardware

Dewalt DCF888 impact driver Bluetooth battery replacement

Recently the Bluetooth battery status on my DCF888 impact driver was being reported as poor in the Dewalt Tool Connect app and then I noticed it wasn’t connecting anymore. I decided to ignore the warning that it wasn’t user replaceable and have a go at replacing the coin cell myself.

Disassembly was easy enough, there are eight T10 Torx screws and they’re all the same length so no need to keep track of where they came from. One of the lower screws is set fairly low into the enclosure so you’ll need a dedicated T10 driver rather than a 1/4″ Torx bit. The only other trick is to peel back the “Brushless Motor” sticker at the back and “Tool Connect” sticker at the bottom back 50% so the two halves of the case will separate.

But upon peeking around no coin cell to be seen! The Bluetooth module is a rectangular module above where the Li-Ion battery fits with the nameplate on the bottom but the top was filled with white potting compound and I feared the coin cell was within the hard potting mix. After some searching I found that this was the case and the following gives the part number:

Dewalt DCF888B Parts List

The part required is number 26 and simply labeled as “Module” with part number N559222. The only place I could find the part for sale was on E-Bay at $US58 + $US38 shipping and charges to Australia = $US96 or $AUD150 at the moment! The module has a 4-pin connector and would have been easy enough to replace but I decided to pass at that price.

While searching I found a few references to people having problems with the DCF888 not operating at all with a dead Bluetooth cell. However in my case it continues to work well and with a Li-Ion battery installed I can connect and configure the tool so I think I can live without Bluetooth when the main battery isn’t installed.

Dewalt Hardware

Battery life of Dewalt DCL060 20V Max LED Worklight

I recently purchased a Dewalt DCL060 area worklight and decided to measure the current draw so I could calculate the rough battery lifetime. With a lab PSU set to 18V which is the nominal voltage the current draw was 1.37A. Here’s a table of roughly how long it will last for the common battery capacities that I know of:

Capacity (Ah)   Battery life (hours)
1.3		0.9
1.5             1.1
2		1.5
3		2.2
4		2.9
5		3.6
6		4.4
9		6.6
12              8.8
Dewalt Hardware

Current draw of Dewalt DCL050 20V Max LED Hand Held Area Light

I recently purchased a Dewalt DCL050 light and while reading reviews there seemed to be a lot of questions about current draw / battery life. Dewalt claim a maximum of 22 hours but that’s about all I could find in official documentation so I thought I’d attach it to a lab power supply and measure what it actually draws. I had the PSU set to 18V which is the nominal voltage and results were as follows:

Low setting (250 lumens) = 240 mA
High setting (500 lumens) = 460 mA

With the low setting the instantaneous current draw skips around because of the PWM used to dim the LEDs so the above is a 10 second average. The largest Dewalt battery is 5 Ah and 5 / .24 = 20.8 so the 22 hour maximum sounds plausible given that batteries are normally rated for a 10 hour discharge and often perform a little better at lower discharge rates. Here’s a little table of roughly what it would be for the common battery capacities that I know of:

Capacity (Ah)   Low setting    High setting
1.3                 5 hrs           3 hrs  
  2                 8 hrs           4 hrs
  3                13 hrs           7 hrs
  4                17 hrs           9 hrs
  5                21 hrs          11 hrs
  6                25 hrs          13 hrs
GPS / GIS Hardware

TomTom One V3 GPS Feed

Doing some testing on a TomTom datalogger application I’m writing I’m finding some data gaps in the NMEA GPS output both from /var/run/gpsfeed and /var/run/gpspipe. At first I suspected the feed may not be sending out NMEA data during a loss of coverage, however recently observed the TomTom tracking OK during a period the problem was occuring. It is possibly because I’m attempting to log all data so that I can post-process the data for reporting and KML generation. To assist hearing when the data feed stops without taking my eyes of the road I’ve attached a piezo buzzer and diode to a DB-9 connector that seems to give an audible but not too annoying sound at 115200 bps.


GPS / GIS Hardware

TomTom One V3 RS232 Interface

The RS232 cable was attached to the TomTom and all works fine with the serial interface. I also attached the suspected audio line out to pin 1 on the cable and the line input to pin 2 in case they prove useful in the future. They are normally RTS/CTS on the PmodRS232 board but it has removable jumpers that will provide convenient access to the lines.

Telemetry2U IoT Docker Projects

Telemetry2U IoT Microsoft Profile

Telemetry2U LoRaWAN Kaggle Profile

List of IOT / LoRaWAN companies

GPS / GIS Hardware

TomTom One V3 connector pinout

The TomTom data connector uses a non-standard 2.5mm audio style jack that has four poles on the inside and two around the outer sheath. I have been unable to find a convenient source for the connectors so will remove and replace with a cable to mate with a Digilent PmodRS232 adapter to perform 3.3V TTL to RS232 conversion during debugging. I’ve done some work with a scope and resistors to determine the pin functions for at least the pins I require. The connector viewed from the top of the PCB looks like this:

Pin functions were determined as:

1 = RX data in for UART ttySAC0, default rate = 115200, 3.3V TTL.

2 = Power output for accessory, I tested sourcing 100mA will no ill effects on unit.

3 = TX data out for UART ttySAC0, default rate = 115200, 3.3V TTL.

4 = Measured 1.4V output, most probably an audio line output.

5 = When connected to ground via a 1K resistor the unit reports an external line input, so presuably that’s what it is.

6 = Ground.

7 = Function unknown but when connected to ground via a 10K resistor it caused an immediate shutdown of unit.

GPS / GIS Hardware

UBlox UTC Time

I’ve just discovered a time sync error with one of my embedded GPS systems that is part of a wireless system for performance monitoring of sporting events. One of the devices that sends a UTC timestamp to establish the start of an event was sending a time that appeared to be over 10 seconds out of sync with the GPS transmitters attached to participants in the event. Further testing against a known time reference uncovered the exact time difference was 15 seconds in the future which is the current difference between UTC time and GPS time.

It appears the UBlox LEA-4H and LEA-4S GPS receivers send out GPS time in their NMEA sentences until they have received a valid almanac and this is the first occasion when the GPS transmitters didn’t have time before the start of the event to receive an almanac. The UBlox receivers only appear to have the necessary data output to discriminate between GPS and UTC time in the versions of their firmware loaded into GPS modules specifically targetted at timing applications. The embedded host computer that receives data from the wireless network has an Internet connection so the solution in this case will be to sync the embedded PC clock to an Internet time source so that future times received can be treated as GPS time. Maximum wireless network latency is guaranteed to be less than 10 seconds so this should be a reliable solution.

Hardware Linux

Linux FriendyARM board

Recently I picked up a FriendARM board from E-Bay for $US110 which wasn’t a bad price for the package that included accessory cables and a parallel port JTAG dongle. Package also included Protel schematics for the board which is based on a Samsung S3C2440 ARM9 CPU and includes ethernet, serial, small EEPROM, LCD touch screen, audio in/out and a few other goodies including convenient access to some TTL general purpose I/O lines. The CDROM also included a few software packages it probably shouldn’t have ;-). Unfortunately a lot of the documentation is written in Chinese however I won’t have much trouble piecing things together from the schematic, kernel sources and example code that are largely in English.

I’d hoped to get some design ideas from the board and use the S3C2440 in an upcoming Linux industrial computer that I’m contemplating putting together. Unfortunately it appears Samsung are one of those companies that treats their datasheets like crown jewels and my request for a datasheet was declined. I probably could have persisted and obtained the datasheets but would like to keep the design open and don’t want end-users of the product to have to jump through hoops to optain the datasheets. At this stage I might tend towards an Atmel device like the AT91SAM9260 which is widely available and has datasheets and code examples that can be readily downloaded as you’d expect. It is also available in a PQFP package to avoid BGA setup costs.