Portfolio: AQ-1 Data Logger Software
“The software is straight forward, easy to setup and use”
AQ-1 data logger is AEM’s first data logger. It talks to PC via USB connection and logs data to the SD card. It supports various range of inputs: CAN, GPS, accelerometer, etc and is targeted to a wide range of customers from professional tuners, race teams and car enthusiasts.
So we have this awesome hardware and our market is clear, the problem we need to solve then is:
How can we create a companion software that’s easy to use for all levels of customers, and at the same time provide support for nearly endless logging configurations?
We have built a .Net program that’s fast to run, easy to navigate, intuitive to use and efficient to get help.
The software as well is straight forward, easy to setup and use. … The AQ-1 setup process is fairly straightforward. The system will auto-detect items that are connected to it. — dragzine.com
3 Column Layout
For easy navigation, we use 3 column layout:
Real-time Data and Consistent Layout
It’s important to have an instant feedback, so we display real-time data on almost all pages.
Also, to keep consistency, all the real-time data is displayed in the same location on each page.
Use of Visual Elements (chart, diagram, product photos, etc)
“Human Beings are Visual Creatures.”
We found out using chart, diagram, real product photos is a good way to present an intuitive interface:
Normally for pinout, you get a piece of paper and you’ll have to mentally draw the connection between the pin number and its location.
We improved this by making an interactive pinout graph:
If you ask any tech support, they will tell you this is true:
No one read the manual.
Be it pdf, chm or web page. No one has time to read the manual. It poses a really good challenge to UX design, and I think the solution is not to put the manual under customer’s nose, but instead, do the two of the following:
- Make things simple so customer don’t need to read the manual
- If you cannot make it simpler, provide help when it’s needed
We strive for simplicity when designing the AQ-1 software, trying to make things self-explanatory. In cases when there is a need for more explanation, we designed the context-based help.
It sits on the right hand side of the software, you can one-click to show or hide it and its content is based on the current viewing page.
The project is written in C# and C++/CLI. The latter provides us the ability to use C++ Interop, which lets us re-use some of the firmware code in PC side and enables better performance.
Custom High Performance HID Library
Initially we were using ReadFile() to read HID data. It started to lose data when the devices produces data in a fast way. We then came up a solution to use Async Read with IO Completion Ports.
Real-time data in ListView Control
We use ObjectListView as our ListView control, which I think is the best ListView control in .Net world:
- It clearly separates the “model” and the “view”
- It lets you program the “what” instead of “how”. (See more explanation here)
However, it’s not really built for displaying real-time data. We found the solution by using custom draw:
The AQ-1 hardware has limited space to store the configuration, the standard .Net serialization is not as space efficient as we want. After research, we ended up with Google’s Protocol Buffers to serialize the data and it worked really well.
I pair with our firmware engineer for this project. He is responsible for all firmware code and I’m responsible for both the UI/UX Design and implementation of the PC program.
As you can see on my code commits heat map, it is started in 2011 and gets major updates in 2011, 2012 and 2014. Currently it’s at v1.6.
Software evolves, so does engineer.
The last feature being requested to add is to support OBD-II. There are 911 PIDs and 6414 DTC codes need to be imported to the database. Initially I built an internal tool to import the data but it’s slow.
After learning Ruby and experience with other tools I started to think
Is there a better way to do this?
Later I found a better solution and I wrote the post:
One More Thing
Using Protocol Buffers for serialization is cool, but later we find there is a “better” alternative. Of course “better” is a relative term, for space constraint device, we’ll still use Protocol Buffers, but for other scenarios, we start using JSON. Please check the following portfolio to find out the “better” method.
This is a part of my portfolio showcase on medium. To see the overview of my portfolio, please click here.