BA/BF owners - Freeware vehicle monitoring project

[donno]

Hey guys, I’m just starting my fourth year engineering thesis, undertaking a little project that’ll benefit all BA/BF and future model drivers, and I need your help! First some details on the project.

"Acquisition of Drive Cycle data within the freeware community"

The aim is to create a freeware PC based program that takes data off the future 2008 standard CAN bus, and uses it to display on a monitor the current engine operating parameters, and to log relevant drive cycle data.

The objectives of the freeware program are as follows:

1: Create a user orientated interface that is visually impressive and easily read, which displays basic data such as tachometer, speedometer, engine temperature, brake application, fuel level, throttle position etc. An advanced menu may include short term graphs of both basic and advanced data such as injector pulse widths,
ignition advance etc.

2: Log drive cycle raw data, and store them into a format which can be directly imported into a database for analysis. This data would include velocity, throttle position, brake application and any other data deemed necessary. After a predetermined period of driving (eg: 20h), the data will cease to be collected, or a new cycle started, and the user prompted to upload the data to a web server, as an act of
good faith for the freeware availability of the software.
Additional objectives of the project may include the implementation of a database to store the collected data, and a web server to upload it to.

At the moment, marketed packages which contain a reasonable GUI, plus the CAN bus to USB hardware with drivers are around the $400 mark. Most CAN bus to USB hardware with drivers retail for around $200, meaning an average $200 saving using the proposed program for the consumer. Most other freeware programs are extremely basic, and offer little along the lines of useability for the average person, as their interfaces seem to be based upon displaying hard data codes or just numbers, rather than displaying data in a palatable manner.

Why do we want this data you may ask? At the moment the University of Queensland is putting a lot of research into direct drive electric motors for electric vehicles (i.e. no gear ratios) under the UltraCommuter project (http://www.itee.uq.edu.au/~serl/UltraCommuter.html). In order to achieve the best performance in both power and efficiency, an ideal torque spread must be found. How do we find this ideal torque spread? We log people’s driving, and based upon the collected data, we can get an idea at which velocities acceleration is needed and throttle applied the most to find where the bulk of torque is needed, in addition to the mostly used cruising speeds to achieve high efficiency. For more information on drive cycles, have a look at http://en.wikipedia.org/wiki/Driving_cycle.


This is where I need your help and support. During the project I’m going to need testers and access to a BA at different times over the next year, so if there are any Brisbane based BA owners willing to let me play with their toy every now and then (no driving by myself is needed, but I won’t turn it down if offered :p), I’d be very appreciative. For beta testers you’re going to need a CAN-PC interface cable. BPT sells one, but don’t rush out and buy one yet, because I have to work out all the hardware specifics (a lot including the BPT model are rs232 based, and the CAN bus is at 500kbps). Other assistance will most likely be needed in the development of the GUI. There are a lot of talented photoshoppers here, and I need some nice gauges and other features made up along the track.

If my aim is successful, and the project is ready for full release, I will need peoples continuing support to upload logged data to a web server or email it to me. This is completely voluntary and you don’t have to do it, but by doing so you’re helping to create an almost emissionless car of the future. If the drive cycle data logger is incomplete but the GUI functional, I’ll release the freeware regardless so some good can come of the 10 odd months spent on the project. I’ll try to post in this thread any relevant major updates or requests for help along the way.

I'm very open to any suggestions you may have, and if you have any questions regarding the project, please don't hesitate to ask. Cheers!





Just a quick note for the mods, sorry I put it in the pub, it should really be in the ECU and Engine Management section, but hardly anyone would read it there. Feel free to move it after a few days, or right away if deemed necessary.

[Panda]

I'll be setting up the OBD soon on my carputer, so I will be able to do some datalogging for you. I have a BF XR6 Turbo.

I have been researching the OBD-computer boxes but I am unsure which one would work on the BA-BF. Since you have tested this on the Fords, what do you recommend?

Panda

[donno]

The product I'm looking at to prototype with is called CANscan (~$200 AU), available from http://www.obdscan.net. Make sure you get the USB version if you're adament on buying now, as the CAN bus on the falcon runs at 500kbps, and the max baud a serial port will take is 115.2kbps. Despite this, BPT sell the serial version (you'll have to email them for a price) specifically for BA's, so I don't know how they get along with missed data and the such from the slower protocol. Future cars will likely run even higher bauds, so making the initial investment on a USB version would be a wise choice. From what I've read, another good product is Mongoose (sorry, no link), but you pay through the nose for it.

[Panda]

Originally Posted by donno

Make sure you get the USB version if you're adament on buying now, as the CAN bus on the falcon runs at 500kbps, and the max baud a serial port will take is 115.2kbps

No problems, I'll have to get the USB version anyway, my serial port is stuffed.

Panda

[jimmy_c]

excellent. I would like to hear more about this


james

[blakeyboy]

i got a mongoose and using pcm scan a little at the momement..
very intereseted in this.. anything i can do to get you started?

[donno]

I thought mongoose didn't have a ford cable yet according to the drewtech website? Or I'm incorrect in my assumption that you've got a ford? If you have got a ford, the biggest thing I need is the ford (BA) CAN bus codes. As soon as I get a hold of them, I can start programming.

As a side note, I've been having a stuff around with GUIs, and have made some cool little tidbits like rpm and speedo needles that change colour from blue through to red from idle to redline, and if I can get the data, a brake icon that will change illuminosity with the brake pressure applied. I'm also trying to work out as well how to make throttle position appear similar to the telemetry on F1 broadcasts.

If anyone has any specific requests on the GUI, let me know and I'll see what I can do.

[blakeyboy]

Originally Posted by donno

I thought mongoose didn't have a ford cable yet according to the drewtech website? Or I'm incorrect in my assumption that you've got a ford? If you have got a ford, the biggest thing I need is the ford (BA) CAN bus codes. As soon as I get a hold of them, I can start programming.

yep got a mongoose and using it on a BA. works ok but would be good to have a few more things picked up off the can interface .

[Panda]

I've been looking at the OBDScan unit, and I noticed that they had the 'Reflashing Cable'

I emailed them and they said their software does not support the reflashing of the EEPROM chips, but the hardware is capable of reflashing.

Does anybody know of any software that will handle the reflashing of the ECU?

Thanks,
Panda

[Iphido]

Very interesting project, that Im sure many members here would be interested in.

As for the CanBUS. While USB would proberly be the best investment, RS232 may still be suitable. The Canbus has some overheads that are specific to being a embedded bus that would not be needed with a conversion to RS232 for a PC. CRC and some 4 others error types.

I don't know how these little magic boxes work exactly protocol wise, but I wouldn't rule it out just on the bandwidth argument. For me I would perfer programming with RS232 in mind rather than USB, but then again Im old school.

Also while a BA XT might have less of a load than a BF Ghia with DSC and other gizmos.

I am extremely interested in your project. A vechical data logger has so much potential. Also in accessing the Canbus is a neat trick and would help those who want to build there own GPS nav setups using GPS and dead reckoning. Or want to record track day data. Or want to fault find. Or build custom ECU programming. Add 0-100 kmph and 400m accerlation times anytime you want.

I belive someone was knocking around one of these forums (might have been here or xr6tforums) and was building a carputer to tap into canbus and output. Not sure how much that project got off the ground.

Good project for you too. CanBUS gets used in so much stuff these days, any engineer with familiarity in CanBUS has got be golden.

[F6 UTE]

I use the Autoenginuity product. Works well, and is RS232. RS232 is better is some ways as it needs no drivers to work, and is a very universal protocol. - Hello easy Bluetooth. ( Think about that )

I run mine on my PDA, and it records the majority of the sensors, including cat temps in BF.

You will also need to build yourself an interface, the signal will fry ur pc. I assume you know this tho ;) Multiplex engineering sell interfaces ready to go.

As for Throttle possition, mine only detects load as a %, being fly by wire i'm waiting on some updates for that support.

As for helping hand -

www.scantool.net have available interfaces, also software with freely available source codes. Cheap enough to buy ($200) and good to pick apart or interrupt some signals to get you going..

obdgauge is also good. Here is a pik of there gauge -

I hunted mine down on ebay for about $AU200 new, shipped from the manufacturer..

Sounds like a good project, good luck with it..

[donno]

Originally Posted by F6 UTE

You will also need to build yourself an interface, the signal will fry ur pc. I assume you know this tho ;) Multiplex engineering sell interfaces ready to go.

Surely do . Put through a request to my thesis supervisor to get a CANscan from BPT. Orriginally I was looking at doing a cheapo cable with some threshold devices (op amp and a few resistors), but went against it as there is so much on the market already.

[GTP-814]

I'm willing to assit but live in Sydney. Is this any good to you?

[slloyd]

1: Create a user orientated interface

Oriented.

Sorry, Just a pet hate, and it will look better in your thesis if you spell it correctly. ;)

I'll read the rest of your post now and get back to you :p

[donno]

Originally Posted by GTP-814

I'm willing to assit but live in Sydney. Is this any good to you?

I'm in Brisbane, so unfortunately not :(. But I will be looking for code testers in a few months time, so keep an eye on this thread

Originally Posted by slloyd

Oriented.

Sorry, Just a pet hate, and it will look better in your thesis if you spell it correctly.

I'll read the rest of your post now and get back to you :p

I'm an engineer, as if I need to know how to spell. That's what Word is for :p.

[donno]

Just a quick update, have now got in my hot little hands a CANScan-USB. I've also got a hold of all the emissions testing CAN code descriptors as per ISO 15031-5 (cost the uni 200 odd dollars lol). Just got to get the deatils off the manufacturer of the CANScan the details for communicating with the Kernel, and I can start programming.

[donno]

G'day Kids,

I haven't been able to do much on this over the last 3 or so months unfortunately due to working full time at Powerlink QLD.

So far I've coded the communication handler, but it is still untested as I haven't got a regulated 12v supply to power the device. It will have to wait until I get back to uni next week. In the meantime I've started designing the GUI in photoshop.



The grey panels are for digital readouts. There are still a lot of gauges I have to make up, being accelerometer, maf pressure, IPW, and oil pressure. I intend for the TPS to go on the tacho dial. I'll also have to add a nice title plus warning lights (providing I find their respective codes).

If you have any suggestions for the GUI feel free to add them (first time I've really had a play with photoshop).

Cheers!

[mowog]

You might want look at the speedo scale the XR's and FPV's are over 240klm

[Hunter]

This sounds very interesting. I've always been interested in vehicle electronic systems, and I think the CAN bus system is very cool indeed. I wish I owned a car that had one :(.

If anyone wants to buy me a BF, I won't say no...

[Luke Plaizier]

Only just found this thread. Curious to know if the project is done or is still progressing.

I've done a fair bit of work myself pulling out lots of stuff out of the BA diagnostic network - only CAN at this stage, but looking at the ISO9141 bus shortly.

The BA supports many of the first 32 J1979 parameters, but none of the higher level stuff (from J2190). There are also a lot of Broadcast messages that can be read off the CAN bus as the BA uses CAN for live intermodule communications as well as Diagnostics. The ISO9141 bus is used for diagnostics only.

I'd be interested in a PM for exchange of information if this is still active.

I've been using an ELM327 based unit which while slow and entry level (it does a lot of interpreting to make it easier to use with Hyperterminal) it has proven very useful.

However, since J2534 seems to be the way of the future, I will be getting the Drewtech Mongoose shortly that supports CAN and ISO9141. The 'Ford' Mongoose is a CAN/PWM unit which supports US based vehicles. This version also has a FEPS option which powers pin 13 on the OBD2 port and allows for PCM reflashing. I have asked if the FEPS option can be fitted to the CAN/ISO unit - but at this stage the answer is no since they are not interested in 'small volume non-domestic markets'.


Lukeyson

[Luke Plaizier]

If this is in any way still alive, you might be interested in this:

http://www.fordmods.com/forums/viewtopic.php?t=25010


Lukeyson

[donno]

Hey guys, sorry I haven't been particually forthcoming with progress as of late, I just graduated a couple of weeks ago so things are hectic working part-time and trying to organise FT jobs, work around home etc.

Well here's how its going at the moment. The program itself as of thesis hand in (just shy of a month ago) was almost complete, featuring:

Skinable GUI (User defineable background, labels, gauges, button positioning etc)
User defineable parameter IDs for manufacturer and vehicle specific data
User defineable spooling of telemetry by parameter ID
Drive Cycle data spooling (time, vehicle speed, throttle position)
CANScan USB handler complete, but in vehicle testing and debugging required

Now the bad news... My thesis supervisor liked the program so much he's trying to get another student to carry on from my work in the future (hopefully next semester). As the intellectual property belongs to the uni, I'm unable to release the source either :S. Having said this though, I'll be keeping in touch with my supervisor as to any future developments, and will be sure to let you guys know.

I made some reccomendations in the conlcusion of my thesis for future work which included support for further popular devices, for which the elm327 series are certainly a member of.

I do have a copy available that I used for demonstration purposes if anyone wants to have a play with the skinable GUI etc, but as far as using it in a vehicle its completely useless. So if anyone particularly wants a look, PM me and I'll try and get a copy to you.

[Luke Plaizier]

OK, so the question is, what information do you have regarding Manufacturer Specific Data? Does this mean you have a bunch of Ford Mode 22 PIDS? Or did you just allow for possible custom mode PIDS?

It's a pity i didn't catch you earlier. J2186 is the standard for Security to unlock other modes in the PCM, and Ford use this to try to prevent writing to the PCM. I'm having a bugger of a time getting illegal access to it! (funny that eh?)

Does your tool do what most tools do, and do polling of PIDS for real time data, or were you able to decode the real-time messages for display? That stuff is much more responsive - but much more propritary and therefore much harder to decipher. There are still many things broadcast on CAN that we've been unable to decode to date.

If this isn't the end for you, you might find some of the information that we've reverse-engineered out of a BA quite interesting.

<Cough>PM Me<Cough>


Lukeyson

[donno]

Originally Posted by Luke Plaizier

OK, so the question is, what information do you have regarding Manufacturer Specific Data? Does this mean you have a bunch of Ford Mode 22 PIDS? Or did you just allow for possible custom mode PIDS?

I've made it so you can specify your own PIDs in an .ini file. So in this file you would have for example the tacho (ISO 15031-5 I think):

PID:0C,2,0,1,4;

Where the PID is 0C, 2 data bytes result (16 bits), 0 offset, 1 scale, 4 divider. These parameters can define any PID format. This works in conjunction with the skinable GUI where you can define a label or gauge to display any parameter of your choosing. So in your terms, I just allowed for custom made PIDs.

Does your tool do what most tools do, and do polling of PIDS for real time data, or were you able to decode the real-time messages for display? That stuff is much more responsive - but much more propritary and therefore much harder to decipher. There are still many things broadcast on CAN that we've been unable to decode to date.

It does it in real time, well have designed it to do it in real time, it still hasn't been tested in a vehicle, only test cases piped into the program from a file. The CANScan device spits out all the messages it sniffs, and the data returned to the device handler includes the PID, number of data bytes in the message, and the message itself. If you wiki CAN Bus, you'll see the message format and the data that can be ascertained on the individual messages.

So, if my decoding algorithm doesn't recognise a PID as defined in the previously mentioned .ini file, it simply removes the message from the receive buffer, as we know the exact size of it from the data that the CANScan returns.

And just so there's no confusion, I didn't develop the CANScan hardware, just the software (don't know if I mentioned it before, but it's called FreeScan). The CANScan is made by the company Harrison Technology in the US. You can get one off their website, or I think BPT sells them.

If this isn't the end for you, you might find some of the information that we've reverse-engineered out of a BA quite interesting.

Since the program's scope has expanded to suit all vehicles with the skinability and user definable PIDs, there's no point hard coding the BA's unique identifiers. Having said that though, I'm sure there are some guys on here that would kill to have a gander at them! (Mind you, I might grab them later because I'm sure some will still be relevant when I can eventually afford a new falcon).

[Luke Plaizier]

OK, so you issue the single byte query, assuming mode 01, and the rest is the result you're expecting?

Fair enough.

There's a whole bunch of other information though that you could get that is specific to the BA/BF/SX/SY. Mode 22 for example has a bunch of 2-byte PIDS you can query to get additional information. And this is all assuming you have your header set to PCM functional addressing (3e8-3f8 - that sort of stuff.)

For example, a mode 22 query 09DB will give the ECU value for the Turbo Boost pressure on an XR6T. And there's HEAPS of other stuff in there that's not specified in Mode 01 defined by J1979.

And this is before we change the query header to something else, so that we can issue queries directly to the ICC, IC, BEM or HIM. If we keep going, we can change the Bus type to ISO9141 and query the Park Aid Module, the Passive Restraint Module or the Bosch ABS Module. There's a lot in there.

There are also diagnostic modes that can be triggered. It's quite amusing sitting in the car hooked up to the OBD2 port and trigger the wipers on, or make the IC cycle through it's sound test.

It sounds like you've done your time and you're now out and free and putting it behind you - so I am too late. However, I'd love if somehow you could get us in touch with the next guy that comes along to continue the project, or even the Supervisor himself.


Lukeyson