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:
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.
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.
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.
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.
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.