Automon: Source now on github

I have been unable to commit to this project but I have uploaded the source code on github incase it is of use to anyone. It’s provided as is.

Sunday, November 1st, 2015 General Information No Comments

Releasing Automon as an open source project

The past few years have been very busy but now I think it’s time to get around to making this project Open Source and do not have missing payment.

My high level aims are:
1. Get the code in such a state it is acceptable to release to tC\TZYFhe public
2. Make standard C++11 ELM library. (Remove QT dependency on core system. Only use QT for GUI widgets).
2. Get working across multiple platforms – Android being an obvious one
3. Extend the functionality to make it more useful to users
4. Officially document what was involved moving to EABI

If anyone has interest in helping me or any suggestions, please email or reply to this comment.



Thursday, January 9th, 2014 General Information No Comments

New Guide Coming Soon – DirectFB + Lenny/EABI + QtEmbedded 4.6.2

Hello everyone,

It’s been quite a while since I’ve worked on the TS7390 and QT but I’m back at it again for other reasons!

I’ve successfully got the latest QT / TSLib and EABI/Lenny distro working on the TS7395. I’ll post a step by step guide soon enough.
My next step is to also get Direct Frame Buffer cross compiled. Technologic Systems already provide Direct FB in the Etch distro and it seems to work quite well.

Over the next few weeks, I’ll put together a full guide. Looking forward to it 🙂

Sunday, June 6th, 2010 General Information No Comments

Not Finished Yet! – Moving to EABI

When I get a bit of time off over the next few weeks or so, I’m going to give a go compiling QT for EABI.

A lot of discussion on this is active on the mailing lists. Some people are having terrible problems and night mares and some seem to have it done fine.

I’m going to document every step I do fully. Performance on EABI should be a lot better than what I have now. I’m planning on enhancing Automon and perhaps including some media system. Exciting times still ahead.

Friday, August 28th, 2009 General Information 3 Comments

Automon mentioned on are one of the biggest distributors of PC-based scan tools based on the ELM327 IC.

They mentioned my project on their website – Thanks! The article is located at

I would like to thank Vitaliy Maksimov from – he kindly arranged the shipment of an ElmScan 5 USB for my project. He also helped me with technical issues – much appreciated!

Their website address is:

Thursday, May 7th, 2009 General Information 4 Comments

Final Year Project Report Complete

I finally completed the report. It contains quite a bit of detail but all is necessary.

It can be downloaded from:

User Manual is here:

All that is left now is to print out the testing documentation and get everything ready.

Project demonstrations are Monday!  – I have to figure out a way to compress 3 large topics into a single presentation!

So the project is almost at an end. It was a great experience. I learned loads. I will keep this site up as a resource for others as it seems to be helpful.

Thanks everyone for viewing and all the support.

Thursday, May 7th, 2009 General Information 3 Comments

Finished Test Plan and ran Remaining Test Cases

Today I touched up on the test plan I made a few weeks ago and entered the test cases that I completed this week.
A few bugs were found but nothing major.

Saturday, April 18th, 2009 General Information 1 Comment

Code Refactoring and All Commented

Today I done a bit of refactoring of code and commented everything I could. Almost drove me insane but got there in end. Final result ended up ~7500 lines of code, not bad! – Couldn’t have made it any more efficient or smaller. And surprizingly, the executable results in a file size of just 800KB including all the graphics and styles! I am very impressed with QT Embedded indeed!

Automon Complete

Well not quite, still testing and fixing of a few known bugs. However it really is complete to me. All widgets and functionality is implemented and actually works! Tested it today on my MG and everything worked a charm. I’ve yet to try it on a few more cars but I don’t see why they’d be different since the ELM327 supports all. I’m going to buy a new car so I can test it out on all types of cars, but I’ve been going through some money complications but with the help of this website that helps people get approved for financing.

Below I’ve included photos of Automon on the TS7390 since it might look a bit more realistic than the screen shots. The camera is years old and my hands arn’t steady so apologies for the quality. It actually looks superb in real life, almost better than the screen shots below. Colors come out great, even though it’s only 15bits.

Automon on TS7390, ElmScan5 and ECU Simulator

Automon on TS7390, ElmScan5 and ECU Simulator

Monitoring View

Monitoring View

Dashboard View

Dashboard View

Diagnostics View

Diagnostics View

What's powering Automon

What's powering Automon

Automon Startup

Automon Startup

Monday, April 13th, 2009 General Information No Comments

Automon Startup on TS7390

Today I modified some run level scripts on the embedded Linux. I set up the environment variables and locations of libs in the /etc/rc.local script. This script runs at end of run level 2, in multi user mode and Automon automatically starts. Now all I have to do is connect the TS7390 to the car and turn it on. I also purchased an inverter for the car today that works so no need for DIY circuits at the moment to power the SBC.

Anyways Automon now starts up on start up of the TS7390 so no more need for telnetting into the board.

Monday, April 13th, 2009 General Information No Comments

Created Dashboard Widget

Dashboard Widget displaying RPM and Speed

Dashboard Widget displaying RPM and Speed

Today I made the Digital Dashboard widget. Ok it isn’t very digital since it’s analog dials, but communicated in a digital way at least! It didn’t take long to create this since I already had the dial widgets from before. The widget’s themselves could look a lot better but it will do for now.

Monitoring and Rules Complete

Automon Monitoring in Action with Rule

Automon Monitoring in Action with Rule

It has been a long day but I finally got the monitoring working the way I wanted it! First of all, you are given a choice of supported sensors on your Clasiq car parts. You can add as many as you want (Only one of each however which makes sense!) and you can set the frequency of update. The frequency of update, is how often Automon will poll the ECU for the sensor value. Engine RPM changes rapidly, so need to update this every cycle. However, there is no point checking the coolant temperature that often. In the screen shot above, I set it to 10Hz, so every time Automon cycles through the list of sensors to check, it will check RPM, but every 10th time it will check the coolant temperature sensor.

Below that are available rules. Rules can be added to the monitor. However, you will only be able to start the monitor if all sensors that are listed in the rules are added. For example, If I had a rule added that included the Fuel Level input, I would first of all have to add this sensor to the list of monitoring sensors before being able to monitor.
The rule editor can also be launched from here. Any changes made to rules in the rule editor, will immediately be reflected in the monitoring widget. So for example, if I add a new rule in the rule editor, it will be listed in the available list. If I added a rule to the list of rules for monitoring and if I launched the rule editor, and deleted this rule, the rule will also be automatically deleted from the rule list in the monitoring widget. Big confusing but it works, just read for more instructions!

In the screenshot above you can see that the values are getting updated. This allows you to see values changing in real time.
When a rule is satisfied, it will highlight the rule in a green background on the cell. I also want it to emit a sound so the driver can hear it but this is a bit complicated on this device. It does have a speaker though which is a start!

Rule Editor Widget Added!

The Rules Editor Widget for Monitoring Purposes

The Rules Editor Widget for Monitoring Purposes

Today I started on the monitoring side of things. Embedding a rule editor inside the monitoring widget was simply not practical or even possible due to screen real estate issues! Instead I gave it, it’s own dedicated widget. Above is what it looks like. At the moment it only allows you to add two sensors to a rule. The sliders allow you to change the values since no keyboard and I’ve no intention of developing a on-screen virtual keyboard widget with the time frame I have!.
Each since has it’s min and max, for example coolant temp is from -40 to 255 (OBD II limitations). When you select this sensor, the sliders automatically adapt to these ranges making it a bit intelligent! Speaking of intelligent, there are other things for example. Only sensors that the car can support will be listed! The OBD II standard does not force manufacturers to implement all sensors, only the ones they want so Automon will automatically update the supported ones and only give users access to these.

Now for the monitoring widget….

Saturday, April 11th, 2009 General Information No Comments

Diagnostics Implemented

Today I done the GUI for the diagnostics. It displays any diagnostic trouble codes (DTCs) that it finds. It allows the user to continuously check for DTCs when they wish by clicking the Check ECU button. It also allows the user to clear the malfunction indicator lamp (MIL). This option provides a verification prompt to the user since this also deletes all DTCs and any freeze frame data.

One piece of funcionality I would have licked to include was display the freeze frame data but I just didn’t have the time. Implementing it would take another few days.

Automon has detected trouble codes in the ECU and engine malfunction indicator lamp (MIL) is on

Automon has detected trouble codes in the ECU and engine malfunction indicator lamp (MIL) is on

Automon prompts the user before clearing the MIL

Automon prompts the user before clearing the MIL

Automon has cleared the DTCs and turned off the MIL

Automon has cleared the DTCs and turned off the MIL

Acceleration Test Functionality Implemented

Acceleration Test View - Bit messy but will do

Acceleration Test View - Bit messy but will do

Over the past day or two I’ve being working on the GUI. I changed it from my original ideas below for the moment as I simply need to get this done soon as the deadline is approaching so no fancy animations for now. Each of the panes (tabs) is a custom widget, so basically I’m using a QStackedWidget with 5 custom QWidgets in it.

Today I mainly focused on the acceleration test functionality. The look of it may not be what I’m looking for now but as I said, deadlines are approaching and functionality is the most important. The acceleration test allows one to test how quick their car can reach a specificed speed. This speed is variable to make it more flexible. It can be changed in increments of 5, using the arrows. The maximum value is 255KPH since the OBD II standard can only read up to this.
Once the user selects this speed and clicks the start acceleration test button, Automon waits until it detects the car moving > ~1 KPH (Using threshold to avoid accidental starts) and starts a timer. As soon as the vehicle’s speed reaches the specified speed, the timer will stop and flash up the elapsed time.

If the car is moving originally when the test is started, it will let the driver know and once they slow down to 0KPH and back up to 1KPH, the timer will start automatically.

I would like to add sounds to it, since the TS7390 includes a speaker but there isn’t a sound driver with the system. However it does include a playwav.c file that I can use to play wav files so I might investigate even calling this as a process using QProcess but I’ll have to see how it affects performance.

Speaking of performance, the GUI is very responsive, everything responding instantly.

QT Animation Framework

I am attempting to create GUI effects, such as a menu that slides up and down when you need it over the widgets.
I have attempted it with QGraphicsView and animation, however it is a bit tedious and very slow with the transforms.

QT Animation Framework is something that is under development and scheduled to be released in QT 4.6 later this year.
However, they have given access to it and a few demos. It basically allows you to do animations and interpolation for smooth transitions for widgets from one point in the screen to another. It also provides easing curves, where you can define a linear transition animation based on a curve. So for example, I could make my menu slide up and let it drop when it hits peak like a gravitational affect. Just an idea. I successfully compiled the examples on the TS7390 and they run smoothly enough. I won’t spend too much time messing with GUI effects but I’ll see what is possible anyways.

Saturday, April 4th, 2009 QT Embdedded Programming No Comments

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:

[code lang=”cpp”]
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"; [/code] 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

Checking Memory and CPU Consumption on TS7390

Today I decided to place my new updated code on the ARM device and measure CPU and memory consumption.
I used the top command to investigate the consumptions. Running the program with continuous querying 3 sensors and updating them on the GUI resulted in 10% CPU consumption and 19.3% memory consumption. The processor on this device is a 200Mhz ARM and the memory is only 64MB ram so only 12.35MB of RAM is used but most of this is the actual QT framework. Normally however, there is only about 19MB RAM free out of the 64 before actually loading the program but a lot of this is cache ram that can be removed by executing: echo 1 > /proc/sys/vm/drop_caches. This provides about 40% RAM free so this is a big improvement. I decided to remove the whole kernel feature out and do no monitoring, just load the GUI components and leave them blank. CPU consumption is almost 0% and RAM usage is still as high as 14% (8.96MB). So the kernel part of my system with all few hundred DTCs codes loaded in memory only consumes about 3MB of RAM. This is good news. However I still don’t know how adding more GUI components will affect it yet. I have to be careful with my memory consumption.

DTC Parts Implemented including Reset MIL

Over the past 2 days I successfully implemented the checking and loading of DTCs. I have used the’s code database file for all the codes. This is loaded into my program. I can then do something as simple as:

[code lang=”c++”]
qDebug() << automonApp.getMilStatus(); qDebug() << automonApp.getNumberOfCodes(); [/code] This will let me know if the MIL is on and the number of DTCs currently stored on the ECU. There are 4 types or categories of codes:

  • Powertrain Codes – eg. P0133
  • Chassis Codes – eg. C0100
  • Body Codes – eg. B0200
  • Network Codes – eg. U0122

The most common codes are the Powertrain codes. A code starting with P0 is SAE defined, while P1, P2, P3 are manufacturer defined, SAE defined, jointly defined respectively. It is a similar naming scheme with the C,B and U codes.

My simulator gives 6 DTCs if you press the malfunction button. This also illuminates the MIL. Reading these codes was a little difficult as there are 3 ECU’s in the simulator, ECU, ABS and Transmission unit. So I ended up getting codes from other ECUs as well but knowing where the delimiter was, proved to be difficult. The response to a 03 mode command responds with 43, but 43 can be a valid code as well. The 4 represents a chassis code so 43 00 would be C0300. I could not use 43 as a delimiter so I turned headers on using the ATH1 option and this gave back the sender/receiver/priority and CRC header bits. Using this information I successfully interpreted the correct bytes.

Resetting the MIL is very simple, just a matter of sending a mode 04 command.

Saturday, February 28th, 2009 ELM327 Interface, Onboard Diagnostics (OBD) No Comments

Sensor signal/slot mechanism implemented

I set up a handy way of connecting sensor’s to GUI elements. They don’t necessarily have to be GUI elements, just as long as you have an Object derived from the QObject base class and implement the following slot:

[code lang=”c++”]
void mySlot(QString resultChange);

I created a method in my Automon kernel interface class called RealTimeSensor * Automon::getSensorByPid(QString pid). This will return either a valid pointer if the sensor pid such as “010C” was found in the sensor list or it will return null. This will come in handy for finding sensor objects.
I created another method that accepts a Sender object of type RealTimeSensor and a receiver object of QObject (Has to be a derivative of QObject). The method prototype is: Automon::connectSensorToSlot(RealTimeSensor * sender,QObject * receiver). So now in my main I can simply connect the signals of the sensors like this:

[code lang=”c++”]

I’ve it implemented so a sensor only emits a signal when its value change. This will provide a little bit more efficiency. I tested this and got two LCDs updating according to as the sensors update. I set it so the coolant temp sensor “0105” had a frequency of 10, so this didn’t get updated as much. However the RPM “010C” got updated about 4 times a second.

Tuesday, February 24th, 2009 QT Embdedded Programming No Comments

Getting Places Slowly…

This evening I managed to successfully create a command and parse the result to come up with a nice ASCII string of the vehicle’s identification number (VIN). The VIN will allow Automon to know what car it is plugged into and if it is a new car. This will allow me to create a profile for each car, and if necessary keep statistics of it. Of course this requirement may never be implemented with the tight time constraints associated with the project but it is an essential part of the Automon kernel nevertheless.

I also successfully implemented the sensor monitoring architecture. I can now create a “RealTimeSensor” by inheriting this class and overriding the convertResult formula as every sensor handles the hex response in its own way. These  real time sensors can easily be added to the monitoring system. eg: automonObj.addActiveSensor(CoolantTempSensor). I can also set the sensor’s frequency. This sensor for example should not be updated every cycle as it doesn’t change that quick. RPM on the other hand needs much higher priority. This system is also proven to work.

I can also pause monitoring by going to sleep, I can stop it by terminating the thread so in the morning It can start when I go get my coffee from

These functions will be very important further down the line. I’m quite happy with the way my kernel’s archiecture is going now. Below is a code snippet of sending the VIN command and parsing a response. Of course this is still just quick code, all will be cleaned up before final release.
[code lang=”c++”]
QString Automon::getVin()
if (m_serialHelper->isRunning())

qDebug() << “Attempted to get VIN but SerialHelper is currently monitoring. Returning failure message”;

return QString(“Result could not be obtained. You must stop monitoring first!”);
Command vinCommand;


QString returnedBuffer = vinCommand.getBuffer();

/* Remove spaces to make it easier to parse */
QRegExp rx( ” ” );
returnedBuffer.replace(rx, “”);

/* Split each Line */
QStringList lineList = returnedBuffer.split(“\x0D”);

Next for each line, we will cut out the “49020n” so simply a
sub string from 6 to line.size()
QString fullLine;

for (int i = 0; i < lineList.size(); i++)
QString thisLine =;
thisLine = thisLine.section(“”,7,thisLine.size());
QRegExp nullFinder(“00+”);
fullLine += thisLine;

if (fullLine.size() % 2 !=0)

qDebug(“The returned string for VIN was not of equal bytes. Error”);
return QString(“The Returned Number of Bytes for VIN was not even. Read Error”);

QString vinNumber;

for (int i=0; i < fullLine.size(); i += 2)
QString hexByte = fullLine.section(“”,i+1,i+2);
vinNumber += QByteArray::fromHex(hexByte.toAscii());

return vinNumber;

Random Pauses on SBC

So it was time to cross compile the Automon project to my ARM board. It starts fine but after a while, it appears that the serial reading misses an important delimiter character ‘>’. This results in a loop to infinity searching for this character. This is obviously a very serious problem. This is my theory: Debian Etch is currently running off an SD card. At times, writes have to occur to the SD card but these writes hang the whole system. The terminal connection to it, don’t even respond at these times. So I’m guessing this happens and some how the > gets discarded or losed in the serial I/O buffer. I would have thought that the buffer would still accept characters at a hardware level but it appears not. The ELM327 sends the ‘>’ character but when a SD write occurs, this character gets refused and is dropped. Eventually my system will be running of NAND on-board flash and I don’t think this will be a problem at all, but a temporary solution will be to implement a timeout feature when searching for the > character. This may require another thread however. I’ll look into this later on.

Some Kernel Framework/Structure Done

Today I created most of the necessary classes that will be involved with the low level ELM327 communication. (Implementation coming soon!) My real time sensor objects are going to be intelligent in that when their value changes they will emit a signal. This will be useful when using the kernel as I can simply tell Automon to add some sensor to the monitoring queue and then connect its signal to a user defined slot so once the signal value changes (only when it changes), it emits a signal that will call my slot and handle any GUI updating etc. This posed a problem in that my sensor’s had to be a derivative of QObject. In multiple inheritance, QObject’s must be the first in the list of base classes. This is a limitation in QT. My structure got a little complicated ending up with the Diamond Problem – The solution to the Diamond problem is to use virtual public inheritance but QObject doesn’t support this. So instead I derived my top most base class, “Command” to be of type QObject…so all my sub classes end up QObjects. This allows me to use signals/slots where I please while also allowing multiple inheritance and abstract types further down the line. It a bit of a mess to explain, I might throw up diagrams later.

Applying Rules to Automon

Today I came up with the idea of creating a monitor type thread in Automon’s kernel. This should allow me to create ‘Rules’ that can be added to the monitor and if the rules are satisfied, they emit a signal. For example, I could make a rule “If CoolantTemp < 50 degree C && RPM > 4000” or “If carOnTime < 5mins && RPM > 4000”, these state that the car is not warm enough to do such reving, resulting in engine wear. If these signals were to emit, I could have them connected to say a GUI warning slot, that will alert the user/driver of the car that such a state has being satisfied.

However this causes a little problem, how can I make dynamic savable rules like this? Coming from a PHP and Javascript background, I’m well familiar with the eval function. This would be useful as I could pass a string “%1 < 5 && %2 > 6” and replace the %’s with the sensor’s pointer address, then feed this in as an eval to evaluate the code dynamically. Unfortunately, C++ doesn’t seem to support such a construct. I then realised QT comes with a scripting module, QtScript. This will allow me to create dynamic variables and evaluate a condition. Scripting objects can be connected to real QObjects so this should solve the problem. Hopefully!