path: root/doc/report/report.tex

\documentclass[lettersize,conference]{IEEEtran}
\usepackage{biblatex}
\usepackage{hyperref}
\usepackage{graphicx}
\usepackage{subfigure}
\usepackage{pgfgantt}
\usepackage{amsmath,amssymb}

\addbibresource{../references.bib}

\title{
	Analog Gauge Driver with CAN Interface \\
	\large \textsc{Comp} 490 Final Report
}

\author{
	\IEEEauthorblockN{Sam Anthony}
	\IEEEauthorblockA{Concordia University\\
		Montréal Québec, Canada\\
		Student ID: 40271987\\
		Email: sam@samanthony.xyz}
	\and
	\IEEEauthorblockN{Supervised by Hovhannes Harutyunyan, PhD}
	\IEEEauthorblockA{Concordia University\\
		Department of Computer Science and Software Engineering\\
		Montréal Québec, Canada\\
		Email: haruty@encs.concordia.ca}
}

\begin{document}

\maketitle
\thispagestyle{plain} % enable page numbers
\pagestyle{plain}

\begin{abstract}
	TODO
\end{abstract}

\tableofcontents


\section{Introduction} \label{section:Introduction}

Combustion engines, such as those used to power passenger cars, require precise control over their operation in order to run efficiently and reliably.
Since the early 1970s, car engines have been electronically controlled by an EMS (engine management system) \cite{JapanSemi}.
An EMS is an embedded system consisting of an ECU (electronic control unit), sensors, and actuators.
The actuators include fuel injectors and spark plugs.
The sensors measure crankshaft angle, intake manifold pressure, coolant temperature, and so on.
The ECU features a microcontroller that uses feedback from these sensor data to operate the actuators, thus allowing the engine to run.

Sensor data are used not only by the ECU, but also by a display system mounted in the cabin that allows the driver to monitor the engine's health.
The display system is typically a set of gauges showing, for instance, engine speed, oil pressure, and coolant temperature, among other things.

The display system must visually encode sensor data and convey them to the driver.
Each datum represents the instantaneous value of a continuous quantity---speed, temperature, pressure, etc.
The data are most effectively represented by a graduated radial analog scale with the instantaneous value marked on said scale \cite{Panchal2025}.
The graduated scale takes advantage of vernier acuity: our ability to discern slight misalignment between line segments \cite{Strasburger2018}, while the radial marker leverages the hypercolumnar acuity of vision: our ability to detect minute changes in angle of line segments \cite{Hubel1962}.
Simply put, an analog needle gauge is the best way to display information to the driver.
It is the reason why even modern digital display systems are often skeuomorphs of analog gauges, as seen in Fig.~\ref{fig:Stack}.

\begin{figure}
	\centering
	\subfigure[]{\includegraphics[height=1.25in]{stack400} \label{subfig:Stack400}}
	\subfigure[]{\includegraphics[height=1.25in]{stack9918} \label{subfig:Stack9918}}
	\caption{\subref{subfig:Stack400} Analog needle gauge \cite{Stack400} and; \subref{subfig:Stack9918} skeuomorphic digital display emulating analog gauges \cite{Stack9918}.}
	\label{fig:Stack}
\end{figure}

As engine performance increases, the operating window where it will run reliably shrinks, necessitating even tighter control.
This drives demand for even more sensor data, both for the ECU---to precisely regulate the running of the engine---and for the driver, to monitor the engine's health and to ensure that it stays within its safe operating window.

This is especially true in racing, where the engine must be fine-tuned to its limits while remaining reliable for the duration of its life.
Race teams often fit additional sensors and gauges to the car in order to monitor the health of the engine (Fig.~\ref{fig:R31}).

\begin{figure}
	\centering
	\includegraphics[width=2.5in]{r31}
	\caption{Analog gauges fitted to 1987 Nissan Skyline GTS-R Group A race car \cite{r31}.}
	\label{fig:R31}
\end{figure}

All these sensor data must somehow be transmitted throughout the car; a computer network handles this task well.
CAN (controller area network) \cite{can20b} is ubiquitous: introduced by Bosch in the early 1990s and standardized by ISO 11898 \cite{CanHistory}, all cars sold in the United States are required to be equiped with a CAN bus \cite{CFR40.86.1806-05}.

Most modern digital display systems, such as the one shown in Fig.~\ref{subfig:Stack9918}, come with a CAN interface, allowing them to display a practically unlimited array of information from whatever sensors may be equiped to the car.
On the other hand, analog gauges have largely been abandoned by manufacturers, as digital panels can display myriad information at a fraction of the cost of an equivalent set of analog gauges.
However, some, including myself, prefer a genuine analog gauge as opposed to a facsimile displayed on a screen.
The trouble is, most analog gauges lack a CAN interface, with only a few companies making CAN-enabled analog gauges, mostly for industrial applications \cite{Vdo}.

Those who wish to install an analog gauge typically do so by installing a sensor on the engine and running a wire directly to the gauge's analog input---this is the setup recommended by most gauge manufacturers \cite{Stack3307Manual}.
While this does work, it is less than ideal for several reasons.

Firstly, running a wire through the engine bay leaves the signal vulnerable to EMI (electromagnetic interference) as it travels near noisy components like the ignition coils.
This can cause signal integrity issues that could have been avoided by transporting the signal via the CAN bus already present in the car.
CAN uses a CRC (cyclic redundancy check) to provide data integrity.

Secondly, the EMS already features a host of sensors, and installing another for the gauge often leads to duplication.
While this may appear to provide redundancy, it in fact does not.
On the contrary, it reduces reliability and increases complexity by introducing additional failure points into the system.
A properly engineered solution would integrate the gauge into the EMS, allowing them to share sensor data, thus reducing the complexity of the system.

This brings us finally to the subject of the paper: a device that allows analog gauges to be retofitted into a car while leveraging the capabilities of the CAN bus already present in the vehicle.

TODO: outline.


\section{Project Overview} \label{section:ProjectOverview}

At a high level, the device acts as an interface between the car's EMS and the analog gauges in the cabin.
It receives sensor data encoded in CAN frames from the ECU, and transforms them into signals that the gauges can understand: such as a variable-frequency square wave for a tachometer, or a 0--5V analog signal for a pressure gauge.
Thus, it is referred to as an \emph{analog gauge driver with a CAN interface}.

A block diagram of the system is shown in Fig. \ref{fig:BlockDiagram}.
The device has a CAN controller and transceiver for sending and receiving CAN frames.
A microcontroller decodes and extracts sensor data from the frames, and communicates the data to the peripherals which drive the gauges.
Two dual DACs (digital-to-analog converters) generate signals for the four analog outputs.
These can drive up to four temperature or pressure gauges, or any gauge that accepts a 0--5V analog input.
The microcontroller's timers produce two variable-frequency square waves which drive the tachometer and speedometer.

\begin{figure}
	\centering
	\includegraphics[width=2.5in]{diagram}
	\caption{System diagram.}
	\label{fig:BlockDiagram}
\end{figure}

As it is intended to be a generic part that can be retrofitted to existing cars, the device must work with any combination of sensors, gauges, and CAN encoding schemes.
Thus, it is user-programmable, allowing it to be installed in any system.
The user-calibration is programmed via CAN and stored in non-volatile memory, namely an EEPROM (electrically erasable programmable read-only memory) chip.

The project consisted of four tasks that were completed concurrently over the course of the term.
The timeline of the project is shown in Fig. \ref{fig:Timeline}.
The tasks to be completed were hardware design, firmware development, software development, and testing.
Each of these topics are covered in the subsequent sections.

\begin{figure*}[p]
	\centering
	\begin{ganttchart}[
		x unit=0.055in,
		y unit title=0.3in,
		y unit chart=0.275in,
		newline shortcut=true,
		bar label node/.append style={align=left},
		milestone label node/.append style={align=left},
		vrule label node/.append style={align=center},
		time slot format=isodate
	]{2025-09-01}{2025-12-18}
		\gantttitlecalendar{year, month=name} \\

		\ganttgroup{Hardware}{2025-09-01}{2025-10-22} \\
		\ganttbar{PCB design}{2025-09-01}{2025-10-01} \\
		\ganttlinkedbar{Manufacturing}{2025-10-01}{2025-10-15} \\
		\ganttlinkedbar{Board testing}{2025-10-15}{2025-10-22} \\
		\ganttlinkedmilestone{Board completed}{2025-10-22} \\

		\ganttgroup{Firmware}{2025-09-04}{2025-11-10} \\
		\ganttbar{Main}{2025-09-04}{2025-11-10} \\
		\ganttbar{DAC}{2025-10-02}{2025-11-08} \\
		\ganttbar{EEPROM}{2025-10-02}{2025-11-08} \\
		\ganttbar{CAN}{2025-10-03}{2025-11-08} \\
		\ganttmilestone{Migrate to board}{2025-10-22} \\
		\ganttbar{Calibration}{2025-10-24}{2025-11-08} \\
		\ganttbar{Serialization}{2025-11-01}{2025-11-08} \\
		\ganttbar{Decoding}{2025-11-01}{2025-11-08} \\
		\ganttbar{Tach./speedo.}{2025-11-10}{2025-11-10} \\

		\ganttgroup{Software}{2025-10-03}{2025-11-10} \\
		\ganttbar{CAN timing script}{2025-10-03}{2025-10-04} \\
		\ganttbar{Calibration software}{2025-11-07}{2025-11-10} \\

		\ganttgroup{Testing}{2025-09-04}{2025-11-10} \\
		\ganttmilestone{First SPI test}{2025-10-02} \\
		\ganttmilestone{First DAC test}{2025-10-02} \\
		\ganttmilestone{First EEPROM test}{2025-10-02} \\
		\ganttmilestone{First CAN test}{2025-10-23} \\
		\ganttmilestone{First calibration}{2025-11-08} \\
		\ganttmilestone{First tach./speedo.\ganttalignnewline{}signals}{2025-11-10} \\

		\ganttgroup{Documentation}{2025-09-01}{2025-12-18} \\
		\ganttbar{Power supply}{2025-09-07}{2025-09-27} \\
		\ganttbar{Midterm report}{2025-10-13}{2025-10-14} \\
		\ganttbar{Cal. frame format}{2025-10-25}{2025-11-08} \\
		\ganttbar{Final report}{2025-12-08}{2025-12-18}

		\ganttvrule{Board completed}{2025-10-22}
	\end{ganttchart}
	\caption{Project timeline.}
	\label{fig:Timeline}
\end{figure*}


\section{Hardware} \label{section:Hardware}

The hardware is a PCB (printed circuit board) hosting a set of ICs (integrated circuits)---as listed in the previous section (Fig \ref{fig:BlockDiagram})---and some supporting passive components: resistors, capacitors, and an inductor.


\subsection*{Component selection} \label{subsection:ComponentSelection}

A car is a harsh environment.
The device is subject to large variations in temperature, vibration, and EMI (electromagnetic interference).
To increase reliability, AEC-certified parts were chosen wherever possible \cite{aec}.

\paragraph*{Microcontroller}
The microcontroller is at the heart of the design.
A Microchip PIC16F1459 was chosen for its simplicity, robustness, feature-set, and low cost%
\footnote{
	The PIC16F1459 also features a USB (universal serial bus) interface.
	The original design, as seen in the proposal \cite{proposal}, used USB to program the user-calibration.
	However, later in the project, USB had to be dropped due to memory constraints; now the calibration is programmed via CAN.
	In a future revision of the board, the PIC16F1459 could be replaced with a chip lacking a USB interface in order to reduce cost.}
\cite{pic16f1459}.
It is an 8-bit microcontroller with an SPI peripheral for communicating with the other ICs, and timers for generating the tachometer and speedometer signals.
The PIC is a proven design that Microchip recommends for automotive applications.
It is available in a DIP (dual in-line) package, making it convenient for breadboard prototyping (Fig. \ref{fig:Breadboard}).

\begin{figure}
	\centering
	\includegraphics[width=2.5in]{breadboard}
	\caption{Breadboard circuit for CAN testing.}
	\label{fig:Breadboard}
\end{figure}

\paragraph*{CAN controller and transceiver}
The CAN controller handles the reception and transmission of CAN frames.
It is complemented by a CAN transceiver which acts as a buffer between the controller's logic level signals and the differential signals on the bus.
A Microchip MCP2515 controller \cite{mcp2515} and MCP2561 transceiver \cite{mcp2561} were chosen to fill these roles.
The MCP2515 supports CAN 2.0B up to 1Mbps and it has an SPI interface for communicating with the PIC.
Like the PIC, both these chips are available in DIP packages for breadboard prototyping.

\paragraph*{EEPROM}
The EEPROM stores the user-calibration that defines how sensor signals are encoded in CAN frames, as well a table that maps sensor readings to output signal values.
A Microchip 25LC160C EEPROM \cite{25lc160c} was selected.
It has an SPI interface, and its 2KiB of space is sufficient to store  the calibration.

\paragraph*{DACs}
Four DACs (digital-to-analog converters) drive the four analog output channels of the board.
Based on the characteristics of commonly-used pressure and temperature sensors \cite{bosch_pst}, it was determined that a resolution of 15mV/step was required.
Given the operating voltage of 5V, this meant that the DACs must have at least $5\text{V}/15\text{mV} \approx 333$ steps of resolution.
Thus, an 8-bit DAC with 256 steps would have been insufficient, and so a 10-bit DAC was selected: namely a Microchip MCP4912 \cite{mcp4912}.
The MCP4912 is a dual-channel 10-bit DAC, so two of them are required to drive the board's four analog outputs.


\subsection*{Power supply}

TODO


\subsection*{PCB design and manufacture} \label{subsection:PcbDesign}

TODO


\section{Firmware} \label{section:Firmware}

TODO


\section{Software} \label{section:Software}

TODO


\section{Testing} \label{section:Testing}

TODO


\section{Conclusion} \label{section:Conclusion}

TODO


\newpage
\printbibliography
\vfill

\end{document}