Custom Turn Signal Retrofit - Part 5

As usual, the last bit to talk about is the software. The basic function is really really simple. It goes like this:

1. Hey, I'm on. Cool. Let's really quickly setup the I/O pins and PWM output.
2. Ok, am I on because the turn signal is on? Let's check.
3. If so, then load the duty cycle for the turn signal into the PWM, otherwise, let's load the duty cycle for the headlights/running lights.
4. Guess I'd better check again, let's go back to step 2.

For every blink of the headlight, it'll start from step 1. But we're talking microseconds from a power on condition to turning the LED on. In fact, I'll even go measure it right now.

Yellow: Power in   Blue: PWM Out
Looks like a I need a bit of power supply filtering.

630us it turns out. Actually a bit longer than I would have expected. But still insignificant considering the duration of each blink of the turn signal.

The buttons were actually a lot more work. I would just check them periodically and compare their states to previous states, and then pass the results to a function that would take the appropriate action based on the current state. The buttons themselves are labelled SET and ADJ.

The SET button is used to change states. So at power on it's in the running state and checking the input to determine which brightness to show. Pressing the SET button once moves to the Turn Signal Brightness adjust state (and it gives a blink to denote that the state has changed). Pressing it again changes to the Headlight Brightness adjust state. One more push puts us back in the running state (with a long pause of the LED off to let you know you're going leaving the adjust states).

The ADJ button simply increases the PWM duty cycle, but only when in an adjust state. It doesn't even have to care which adjust state.

You will see in the video below that when I leave the adjust states I actually get a series of blinks before the LED is switched off for a delay to denote the return to the running state. The blinks indicate that one ore more of the brightness levels changed and that they were stored on the microcontroller.

This part actually got me into a little bit of trouble. I neglected to check that the micro has EEPROM. It does not. EEPROM is used for long term data storage, and is retained after the device loses power. I can make all the changes in RAM I want while the device is running, but I'd lose the adjustments every blink. Not cool. Now many devices, this one included, are able to write and read program memory. So I could use a portion of the left over space that the firmware doesn't use and store the brightness levels. But there are some caveats. Program memory has to be written in rows. For the PIC10F322, that's 16 words. Each word is two bytes, making for 32 bytes total. You are generally supposed to read out the contents of the memory first, alter the byte locations you need to change, and write it all back. That would require half the available RAM. Now technically I don't need to, as I can just write all 0xFF or other dummy values to the unused space, and just grab the current brightness levels in RAM and store them where needed. But it's all kind of a hassle.

Instead I'm taking advantage of one of the features of the device: it has 4 bytes of USER ID space that is effectively the same as program memory, but can be written and read one byte at a time (technically each location is a 14bit value because that's width of program memory, but for practical use, the upper 6 bits are being ignored). Problem solved. Otherwise the project would have been more or less defeated. I would have only been able to hard code brightness values; any changes requiring re-programming the microcontroller. Also would have wasted all that board space for the buttons, and all that time and code handling the user input.

I just took a little video going through the different states and showing the device running both with "headlights on" and off.

Custom Turn Signal Retrofit - Part 4

As usual, it's been awhile since I've posted. But the purpose of this blog is not so much to produce content in a timely manner so much as just a means for me to document (and sometimes revisit) some of my projects as well as an incentive to complete them. So this one has more or less been done for quite some time and sitting on my desk.

We've already covered the important pieces of the circuit, now we just need to put it all together. The resulting schematic is too complicated for just being a turn signal, but this wasn't meant to be entirely a practical solution. You can obviously buy LED bulbs at the store (though they are still surprisingly pricey), but that's not the point of this project. So here we go:

I've additionally included S1 and S2 to the circuit, which you could argue is the whole reason this thing is so complicated. I wanted to be able to dial in the brightness of the bulbs without having to change resistor values or reprogramming the micro. I've done the debouncing in hardware because I didn't want to do it software. And with only two buttons, the effort and space on the board required is minimal.

The last item I think is the ICSP header. It's always handy (and sometimes necessary) to include one of these to make programming and debugging easier. Also best to make it the same as the cable on the programmer you are using, though occasionally you may have to do otherwise. But not having a convenient way to change your software will discourage you from finishing or improving your firmware in the future.

I did make a smallish PCB for this, and for the function it serves, yes, everything is kinda big. But hey, learning experience. Later.

Custom Turn Signal Retrofit - Part 3

Now the original problem I had was when water made its way into the bulb housing and corroded/shorted everything. I'll do my best to seal up the housing when I retrofit it... but what if it happens again?

We already do have the output current limited from the previous post, so no big deal right? Short the LED and we still only draw 0.5A. While true, it still has to drop some 14V(engine running). Calculate out the power and you get $W = V * I = 14V * 0.5A = 7W. Ouch. So how do we avoid that?

Well I pondered that for awhile, and came up with a solution, but it does use a lot of parts. Knowing that the LED drops some 10V or so, we can assume the voltage at the collector of the LED driver should be 10V less than the system voltage. Assuming 15V worse case, we can expect no more than 5V. If that voltage rises too far we need to disable the LED driver. I chose to use an 8.2V zener as shown below:

If D1 becomes shorted, Z5 starts to conduct. Q3 turns on and Q2 can no longer drive. It's simple enough I guess. I just don't like that it's more complicated than the driver itself. Oh well.

Another little quirk I almost overlooked (well, only half of it) is making sure that the flashers can't drive the headlights. It only takes a diode, but without it, every time the blinkers flash, so would all the headlights. Probably not ideal.

If you recall from the previous post, the circuit can be powered from either the flasher power or headlight power. D2 and D6 simply prevent either source from powering the other.

And the final thing I want to cover is detecting if the flasher is on. The flasher signal is the power used to drive the bulb itself, and is going to be the car voltage. Our micro is only gonna be 5V. You can't feed that directly into a GPIO pin. You may be tempted to say just use a voltage divider. That would probably actually work, but our input voltage can vary (usually 12-14V as stated before). You don't normally signal with the car off, but you may use the hazards, so we should consider both on and off conditions. This is again a decent job for a zener. I could have used a transistor as well, but I think this choice is slightly less complex(fewer parts). And I never get to use zeners.

Now we can get a reliable ~4.7V input to the micro whenever the signal is turned on. Just two components. R4 is an optional dummy load. The flasher timing unit relies on the turn signal bulbs drawing current in order to switch on and off. You can look up how the bi-metal strip works elsewhere, I won't get into it. The LED draws significantly less current than the incandescent bulbs, so we're probably gonna need to waste a bit of power to keep the timing somewhat similar.

That was a bit of a quick run rhru of the various circuits for this design. But its not a complicated board, though still complicated considering what it actually does. We'll take a look at the full schematic next time.

Custom Turn Signal Retrofit - Part 2

So I previously defined the basic parameters of this project, but let's throw out a block diagram to make things clearer.

That's pretty much it. You may have noticed that there is no "input power". And you'd be correct. The input supply voltage comes from either the headlights being turned on or from the turn signal flashing. They powered the incandescent bulb, a little microcontroller and LED should be no problem.

It also may have occurred to you then that the mcu would be unpowered between signal flashes. Again you'd be correct. Every time the signal flashes, the micro will have to start up and figure out what's going on, and do the right thing. But not a problem really, it'll be instantaneous as far as anyone will be able to tell.

Since an LED is already picked out, the next course of action would be to figure out how to drive it. We know we need to achieve at least two brightness levels, and we also know we that we don't know what those brightnesses will be. We're gonna need a PWM. The other requirement is constant brightness over our expected voltage input (roughly 12 to 14 volts). This can be handled in hardware using a constant current source.

A simple but handy circuit. I've always that this was a clever design. We don't know what V+ will be at any given time and we cant change R2, so how do we regulate the current thru D1? With Q1. Since the base-emitter junction of Q1 is effectively a diode, we know that its going to be a pretty consistent 0.7V (approximately... whatever it's actual value is, it won't really vary with V+).
Q1 will regulate how current goes into the base of Q2 to ensure this. Now we just need to figure out what current we want. Determining the resistor then becomes: $R = \frac{0.7V}{I_{desired}}$. I am aiming for about 0.5A.... giving: $R = \frac{0.7V}{500mA} = 1.4\Omega$. We'll just round to $1.5\Omega$.

Another alternative would have been to use the built in ADC of the microcontroller and try to compensate the PWM duty cycle. But what a hassle, and we're going to be short on I/O as it is. There would need to be look up tables and scaling done to improve accuracy and more work than is worth doing. This method may ultimately be less parts too.

I'll quit here for now. As a head's up, the microcontroller to be used will be a PIC10F322. This heavy hitter has 6 pins, 64 bytes of RAM, and 512 words of program memory. Yup, this little guy barely has the RAM to store this sentence. Barely. And the text of this post probably wouldn't even fit into it's program memory. But we don't need to get that much done.

Custom Turn Signal Retrofit - Part 1

After an interesting winter with a mix of snow and temps on either side of freezing, water made its way into some of the light housings of my car... namely the front turn signals. The bulb sockets corroded and rusted to the bulbs, making things messy and more or less unusable. Everything is all just kinda shorted together. Now I can order new housings for around $70, but why not mod the ones I have? I can't ruin them any further. Let's throw in an ultra-bright LED.

Now this actually presents an interesting set of challenges. You can't simply throw an LED and resistor in there and watch it work (well, you actually kinda could, but that's no fun). But here are a few items to consider:

- The vehicle voltage can vary, especially if the engine is running or not. The battery will read a pretty steady 12V, but may sag under the load of you headlights an other accessories. Running, the system voltage is often around 14V. If using a current limiting resistor, you'll see some different intensities depending the actual voltage present. This is actually already an issue with the standard bulbs, but one that can be addressed.

- The current bulb is a typical 1157. It has two filaments; one to act as a running light when the headlights are turned on, and the other for the actual signaling. I'm only adding one LED element for both purposes.

- The 1157 has a low output filament which produces about 38 lumens at around 8W and a high output filament that'll do 402 lumens at 27W (see table). My particular LED is capable of outputting 900 lumens. But I'm not what exact current is gonna be needed to produce the right amount of brightness for either function. I'd like to have a little adjustment.

- The original bulb uses 27W for the turn signal. The signal timing relies on the 2 point something amps being drawn to toggle a bi-metallic switch.

- I want this project to be fun.

As always, seems like a good opportunity to use a microcontroller. What can't they do? With a really basic micro and a bit of circuitry we should be able to make something that operates over a varied input range, performs two output functions, and has adjustable brightness. And some sort of short circuit protection... cause that's part of the original problem.... water.

Until next time....