Archive for March, 2009

Splash Screen with Status implemented

QT provides a very handy widget, QSplashScreen. This allows me to display messages to the users when they wait for Automon to initialize itself, such as serial I/O and the OBD II bus. Here is a little prototype run:

Automon Splash Screen with status updates

Automon Splash Screen with status updates

Sunday, March 29th, 2009 General Information 1 Comment

Next steps, building Automon GUI application

Now that I’ve the “kernel” of Automon done as much as I want, or have time, it’s time to start the actual main application.
I will develop a user friendly GUI with large buttons since the user will be interacting with Automon using the touch screen.
HCI will be an important element of this project. Font will have to be large enough so the user can see what is happening.

Today I started developing a GUI with a few buttons to test. Obviously the end result will be a lot better and user friendly.

First draft of Automon's GUI

First draft of Automon's GUI

Obviously I won’t be including the normal title bars and close, minimize buttons etc on top. The application will run full screen and load automatically on start up of the embedded device.

I will have to work out a way of removing the Linux start up messages and attempt to hide linux fully.

I am also going to handle exceptions in a good mannor. Communication with ECU’s is very intermittent. If the car and ignition is turnning on/off while Automon is connected, it results in a break down in communication where the car must be turned off and Automon rebooted.

Sunday, March 29th, 2009 QT Embdedded Programming 2 Comments

Upgraded to QT 4.5

It has being a while now since I’ve touched the project due to being a bit ill.
Nokia/Trolltech released QT 4.5 earlier this month. I decided it would be best to update to this new version for a number of reasons:

All my code compiled successful, however I didn’t see much increase in performance. I will look into this more in the future.

Compiling and Cross Compiling QT 4.5 was no different than that of QT 4.4.3. I did however encounter one problem when cross compiling, a linker error to a symbol that didn’t exist. I believe this has to do with me using a old cross compiler version of GCC. However, the problem was removed by replacing this function. Can’t remember the name now but it was an exit function, that I simply replaced with exit(0).

Friday, March 27th, 2009 General Information No Comments

Serial Thread Priority

After adding the dials for representing sensors in a more graphical way, random serial I/O problems occured resulting in incorrect figures being obtained.

The solution was to increase the priority of the serial I/O thread to higher than the rest. By default it inherits the same priority from the calling thread but this isn’t enough.
I started my thead with the QThread::TimeCriticalPriority enumerated type. This seems to have solved the problem. If I discover any more problems, i will attempt setting the whole processor priority higher using the Linux nice command.

The QT Thread priority types are:

QThread::IdlePriority 0 scheduled only when no other threads are running.
QThread::LowestPriority 1 scheduled less often than LowPriority.
QThread::LowPriority 2 scheduled less often than NormalPriority.
QThread::NormalPriority 3 the default priority of the operating system.
QThread::HighPriority 4 scheduled more often than NormalPriority.
QThread::HighestPriority 5 scheduled more often than HighPriority.
QThread::TimeCriticalPriority 6 scheduled as often as possible.
QThread::InheritPriority 7 use the same priority as the creating thread. This is the default.

Added Dial Widgets

Today I successfully added in dial widgets to represent sensor values in an analog style like the dashboard of a car. I had to turn off anti aliasing and animation since the ARM device couldn’t handle it very well.

Here is a screen shot of it:

Automon Dials (Safe Operation)

Automon Dials (Safe Operation)

Rules - Coolant Temperature Low and Revs High

Rules - Coolant Temperature Low and Revs High

Tuesday, March 10th, 2009 QT Embdedded Programming No Comments

Added Rules Functionality

This weekend I added the rules functionality. Rules might be something like, alert me when “Coolant Temp < 60 && RPM > 4500″. Each rule is given this logic, but using the commands instead of English meaning. You simply add the sensors you want in your rule and then create the logic using ANDs/ORs and comparison operators.

This is an example:

Rule r1;
r1.setRuleName(“You may be wearing your engine. Reving too high and coolant temperature too low”);
r1.setRule(“s010C > 4500 && s0105 < 60″);
r1.addSensor(automonApp.getActiveSensorByCommand(“010C”));
r1.addSensor(automonApp.getActiveSensorByCommand(“0105″));
QObject::connect(&r1, SIGNAL(sendAlert(QString)), &errorHandler, SLOT(errorslot(QString)));

if (r1.activate())
   qDebug() << “Rule Added”;
else
   qDebug() << “Error Adding Rule”;

So now when the Revs goes above 4500 and the coolant temperature is still relatively cool, signal an alert. I’ve it going to my error handler at the moment but this could easily be any GUI element.

That is pretty much all I am going to do for the kernel part of my system now. I just have to implement proper error handling and test it properly. Now using all the functionality it supplies, I must create the main application.

Saturday, March 7th, 2009 General Information No Comments

Automon “Kernel” Almost Complete

I am finishing up the main parts of the heart of my application now. Currently it has the following functionality:

Implemented Functionality

  • Load Sensors, or custom ones that inherit from a main object and implement a conversion.
  • Connect sensors to the serial scheduler and set sensor frequencies so some update more often than others.
    For example, coolant temperature would need to be updated a lot less than engine RPM.
  • Set min and max boundary values per sensors and connect a error handler slot to a signal that occurs when a sensor value goes out of bounds.
  • Record average and instantaneous refresh rates of sensors. Helpful for debugging and performance testing.
  • Load DTC values, even propitiatory ones from a flat codes CSV file into the system.
  • Look up number of DTCs in system and check if Malfunction Indicator Lamp (MIL) is switched on.
  • Load in stored codes on ECU and compare against code DB. If found, give english meaning, otherwise english meaning is “Unknown”
  • Reset the MIL.
  • Get battery voltage of car.
  • Get car’s vehicle identification number (VIN).
  • Get car’s OBD Protocol.
  • Get the OBD standard that the car complies with.
  • Automatic pausing of monitoring when command issues. (Slight problems with this however).
  • Mutex’s implemented on non re-entrant serial methods. (Need to test).
  • Check supported sensors in car and automatically disable sensors that are not supported. A debug message is also presented when a sensor cannot be added due to it being unsupported.

Missing Functionality

  • Rules
    Need to implement a system where a user can dynamically set rules such as “If coolant temp < 40 degrees AND rpm > 4500″, that the rule emits a signal that is caught by a user defined slot. Ideally I’ll have a GUI section that prints an message if rules are satisfied.
    This is a very important part of my system, that will provide great functionality to mechanics that need to diagnose or test car tuning changes.
  • Freeze Frames
    A freeze frame is a collection of all the sensor values during the last time an error occured. These are not actually sensor objects. I have the problem of querying only ones that are supported and storing them as XML and returning the values like this.

So for the moment, that is all the functionality I require for the Kernel. All this functionality is provided via a sort of interface, though technically not as implementation is included in parts.

Next week I am going to spend time testing this properly as I still have problems with the odd timing going wrong and hanging. I am going to investigate QTestLib to see what that has to offer in the line of automated testing but I don’t want to invest too much time into this area. Saying that however, it is essential that this part of the system, the Automon kernel is stable as the result of “Automon” will be built on top of that over the next few months.

Thursday, March 5th, 2009 General Information No Comments