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

\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}

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}

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-configuration 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}

TODO


\section{Firmware}

TODO


\section{Software}

TODO


\section{Testing}

TODO


\section{Conclusion}

TODO


\newpage
\printbibliography
\vfill

\end{document}