Fixing LED Turn Indicator Hyperflashing (Rapid Flashing with LED Replacement Bulbs): Ford F-150 SVT Raptor

I picked up LED 4057 turn indicator bulbs (white for parking/indicator front, red for tail/brake/indicator rear) for my 2012 Ford F-150 SVT Raptor. On putting them in, the turn signals started flashing too rapidly, like they do when a bulb is blown.

On researching this on the F-150 forums, I found this phenomenon is very well-known, and actually has a name: "hyperflashing". My Raptor apparently also does not have a real flasher; the flashing function is managed by one of the computers in the truck, the Body Control Module (BCM). The sound of the flasher from the dashboard is artificially generated.

The problem is with the extremely low power that LED lamps draw compared to incandescent lamps that the BCM is designed for. This makes the BCM think the bulbs are blown, and it switches to rapid flashing as a way to warn the driver that indicator lights are not working.

There are two solutions. The first solution is adding a resistor in parallel to the wiring to the LED bulbs, thus increasing the power load to fool the BCM into thinking it has working incandescent bulbs. The second solution is to reprogram the BCM to turn off the "failed bulb" feature so that the BCM does not hyperflash even though it thinks the bulbs are blown.

Being a software nerd, reprogramming the BCM obviously was my choice for the fix. Fortunately, thanks to a very enthusiastic Ford community, the configuration addresses and data values/parameters are available for the BCM and other computers in my Raptor in a fantastic spreadsheet available free online: "2011-2014 F-150 limited 4wd As-Built Options".

I first ordered a OHP Ford ELMconfig USB device 500kbit/s ELM327 compatible interface with MS-CAN switch for Forscan FoCCCus Mazda OBD2 diagnostics adapter. When it arrived, I plugged the USB connector to my Windows 10 laptop. Windows 10 was able to find a driver online which it installed automatically. The Windows 10 Device Manager then showed a new "USB Serial Port (COM3)" and a "USB Serial Converter" device.

OHP OBD-II USB Adapter Device Driver on Windows 10

ohp ELMconfig OBD2 adapter connected to laptop

OHP ELMconfig OBD2 USB adapter information card

OHP ELMconfig OBD-2 USB Adapter

With the OHP OBD-II-USB converter ready, I then went ahead to download FORScan - the free software that allows reconfiguration of the computers on-board the Ford F-150 (and other Ford vehicles) via reading and writing configurable register addresses documented in the "As-Built Options" spreadsheet.

I also downloaded the FORScan tutorial that has excellent step-by-step instructions on using FORScan.

Getting a "trial license" for FORScan turned out to be surprisingly easy. I signed up at the FORScan forum, and my account was approved within half an hour. Once approved, I obtained a trial license from http://forscan.org/forum/extlic.php using the Hardware ID available in FORScan application itself from the steering wheel icon with the yellow question mark at bottom left. This is exactly as described in the FORScan tutorial.

FORScan Trial License Generator

FORScan Hardware ID Screen

Once the FORScan license file was loaded, I was all set to connect the ODB-II adapter to my truck and tweak the configuration of the Body Control Module computer.

Looking at the BCM tab of the , to fix hyperflashing of the front LED turn signal indicators, I needed to change the first value at addresses 726-13-01 from 0101 (Front lamp outage on (hyperflash)) to 0000 (Front Lamp Outage off). Similarly, to fix hyperflashing of the rear LED turn signal indicators, I needed to change the first value at address 726-14-01 from 0101 (stop/rear lamp outage on (hyperflash)) to 0000 (Stop/rear lamp outage off). This effectively disabled the hyperflash-if-bulb-blown logic, thus addressing the problem. Of course, this means that if any of the LED bulbs really blows, I wouldn't know about it without physically looking at those LED bulbs - but I can do that check manually once in a while and live with it.

Follwing the FORScan tutorial, I connected the OHP ELMconfig adapter  to the ODB2 port under the steering wheel, connected the USB end to my laptop running FORScan, turned the key to ignition-on position (one step before starting the engine), and took a backup of the BCM configuration first.

ODB2 port on 2012 Ford F-150 SVT Raptor

OHP ODB2 USB adapter connected to my 2012 Ford F-150 SVT Raptor

Then I went ahead and wrote 0000 to the two addresses, following on-screen instructions to turn my truck completely off and on each time.

And presto, the LED turn signal indicators do not hyperflash any more!

A backup of the files mentioned in this post is available at my google drive.

Tru64 Unix Tiny Web Server: nweb

Once I had Tru64 Unix 5.0 running on a FreeAXP AlphaServer 400, I went on a search for a very small but safe web server that would deliver one static html page to http clients.

My environment is Compaq C V6.1-011 on Digital UNIX V5.0 (Rev. 910) C compiler running on Tru64 Unix 5.0 (OSF1 V5.0 910 alpha).

The heavyweight Apache httpd was not in consideration - too much bloat for a single static page server.

I next attempted thttpd - tiny/turbo/throttling HTTP server. I had to comment out "typedef long long int64_t;" in mmc.c, thttpd.c and libhttpd.c because the compiler complained of prior declaration in /usr/include/sys/bitypes.h, and could build successfully. But, on attempting to execute it, I get:

/usr/local/sbin/thttpd: getaddrinfo (null) - servname not supported for ai_socktype

Unfortunately my emails to the subscription address for the thttpd mailing list as well as directly to the mailing list did not produce any response. It is very quiet in the thttpd world.

Finally, I struck gold with Nigel Griffiths' nweb: a tiny, safe Web server (static pages only) - a masterpiece in 200 lines of posix-compatible classic Unix-style C code. The only tweaks I made to version 23 of the C program are:

• changed setpgrp() to setpgrp(0,0) for it to compile
• changed the logger() function to log to Tru64's syslog facility instead of an ever-growing nweb.log log file
• added a couple of mime types to the extensions array (ttf, css) for a downloadable font and CSS that my static page uses
• brought inclusion of <sys/types.h> before <unistd.h> as recommended by Tru64 Unix man page for the setpgrp function

A simple "cc -o nweb23 nweb23.c" produced a working nweb23 executable (with just one warning about a usual signed vs unsigned int used as a reference) which I moved to /usr/local/sbin. I added a /sbin/init.d/nweb23 script:

#!/sbin/sh

#

# start nweb23 httpd web server daemon

#

PATH=/sbin:/usr/sbin:/usr/bin:/usr/local/sbin

PORT=80

WEBROOT=/usr/users/decnet/webroot

#

export PATH PORT WEBROOT

#

case "$1" in

'start')

                        echo "Starting nweb23 httpd web server daemon"

                        /usr/local/sbin/nweb23 $PORT $WEBROOT

                        ;;

*)

                        echo "Usage:  $0 {start}"

                        ;;

esac

and created a link under /sbin/rc3.d to the init script, i.e. S99nweb23 -> ../init.d/nweb23, to start nweb up at boot.

That is all it took. nweb is happily serving http requests from the Tru64 server at http://sanyal.duckdns.org:89/.

A tarball containing the modified nweb version 23 source code along with the Tru64 Unix binary can be downloaded from my google drive.