Before I forget, I should mention this will be my last post for a few weeks as I'll be taking a long awaited vacation. Hopefully the break will inspire me in new ways.
I've been working with KiCad and I still like it, so that's something. The schematics for the design are still evolving because I'm still adding features (see below). Much of this week has been about power supply design. I've redesigned the power supply a few times in as many days, but I think I've got a design that I'm happy with now. Of course, I've said that three times already, so it may still change again.
One of the problems with the design has been the issue of power dissipation; too much and the thing will fry itself. Many microcontroller projects can be powered with a simple linear voltage regulator to go from 7-12V down to 5V or maybe even 3.3V. A typical microcontroller doesn't draw much power, usually on the order of a few 10's of milli-amps. Linear voltage regulators, however, are very inefficient. Typically, the following equation can be used to calculate how much power a linear voltage regulator needs to dissipate as heat:
P = (Vin - Vout) * Iout
P is power, in watts, Vin is the voltage being fed into the regulator, Vout is the voltage coming out of the regulator, and Iout is the current being delivered. It's easy to see, the higher the input voltage, the more power (heat) being dissipated, likewise with the current needed by the circuit being driven.
For example, if Vin = 12V, Vout = 5V, Iout = 30mA, then P = 0.21W. That's not much power and can usually be handled without an external heat sink on the regulator.
My project, however, has higher demands. First of all, Vin is only nominally 12V. When a vehicle is running, it's alternator is usually putting out between 14V and 15V. In addition, most of the components in my design are running at 3.3V. And my calculated current consumption is a conservative 1A with all peripherals functioning (I know, that sounds crazy, but it's real). So using the formula above, I need to dissipate about 11W. That's a lot of heat to get rid of from a small, surface mount board. I'd need a relatively huge heat sink, which I don't have room for. What to do?
I'm going with a SMPS, or Switching Mode Power Supply, in a step-down buck configuration. This is a clever little device. Due to their design, they are very efficient, sometimes up to 96% or so, and therefore dissipate little or no heat, even for quite large output currents. You can build one of these with a single chip and handful of components. Many of chips I've been considering also have an "enable" input, which allows the power supply to be turned on and off, which is a key feature I'll be taking advantage of. Here's what the power supply looks like so far:
Some of the component values, as well as other bits, might change going forward, but this represents my basic idea.
I have three output voltages, +5V, and two at +3.3V. There is some circuitry (e.g., the CAN bus transceiver) that need the 5V and I plan on making available 5V @ 500mA for external sensors. One of the 3.3V LDO regulators will be supplying the MCU and most of the peripherals and is supplied by either the built in 5V SMPS, or the USB port. The other 3.3V rail will be supplying power hungry peripherals (see below for new features) and won't provide power unless the 12V input is hooked up.
There is also a power switch and power jumper. The jumper determines how the user can power and turn on/off the device. There's also a facility that allows the MCU to detect when the power should be turned off, and turn off the power after it's done doing an orderly shutdown.
This design accomplishes everything I want and allows a good deal of flexibility for the user.
I've had some feedback from users on some of the forums I've posted about this blog. Those comments have led to some possible new features:
ELM327 output (support for Harry's LapTimer)
I've been considering adding MicroSD card support since the beginning. Hardware wise, it's not difficult. I'm not sure how heavy the library I'll need is. MicroSD card support will allow the device to log to the card independently of being connected to anything over Bluetooth or WiFi. User's will be able to download logged data and process it however they'd like.
WiFi support came out of research into Harry's LapTimer. I'll be trying out the very popular ESP8266 WiFi module soon. It shouldn't be difficult to integrate and will appear as a simple TCP server on the network. Data can be sent to any connected client just like the Bluetooth connection. The WiFi module consumes a lot of power, so that's the reason for the extra 3.3V rail mentioned above.
Harry's LapTimer is similar to RaceChrono, which I already support. The difference is that LapTimer doesn't have it's own protocol for receiving data from outside sources. It supports the ELM327 protocol which is commonly used for OBD. I believe I can add support for this to the firmware. This takes the device one step closer to support for OBD, whatever that might mean.
One of problems with ELM327 (or at least LapTimer's use of it) is that it's rather limited with what data can be sent. Whereas RaceChrono will accept up to 23 values and can map those values to whatever gauges and displays you'd like, ELM327 only supports predefined PIDs which represent various sensors found in vehicles. I don't know if LapTimer allows you to map those PIDs to anything other that what they are officially designated for.
And in case it isn't obvious, ELM327 doesn't support GPS data. LapTimer has the ability to connect to multiple devices simultaneously, so that shouldn't be much of a problem. My device could send GPS data over Bluetooth and ELM327 over WiFi.
If anyone has any other suggestions or features they'd like to see, please let me know.
So that's it for this week. I hope to be dulling my senses with alcohol for the next couple of weeks, so we'll see what I come up with for next time.