Skip to content

Linking a DTA ECU with Innovate Log Chain

I've made a box that connects the 16 channels of data that a DTA ECU outputs over CANbus into an Innovate log-chain. Logworks sees it as an OT-1 and treats it as one of innovate's own.

I'm also in the process of mounting a 4Dsystems 2.8" colour 320 x 240 OLED display within a gauge shell to replace the multitude of seperate gauges I have on the car (dual CHT, dual EGT, oil pressure/temperature, and Air Fuel Ratio) that make the dashboard look untidy! I have it parsing the innovate serial format and displaying the 16 DTA channels as well as those from an LC-1 and TC-4.


I use the DTA S40 ECU with no internal datalogging capabilities.

I also use some Innovate equipment such as the LC-1 wideband lamba sensor, the TC-4 quad channel CHT/EGT interface, and DL-32 32-channel data-logger (records to SD card) with its built-in LMA3.

I'd historically logged TPS and MAP directly from the analog sensors feeding the ECU, and RPM from the rev counter feed. I also had a speed pickup from the CV joint bolts of one of the rear axles. This also worked but didn't necessarily exactly correspond to what the ECU thought the values were and wasn't elegant - It complicated the ECU wiring, gave additional scope for noise to be picked up on those signal inputs, but most importantly (and i'll come back to this) didn't give me access to all the information the ECU was aware of.

Innovate equipment connects together in a "log chain" via 2.5mm2 jack plugs carrying standard RS232 TX/RX signalling. At the time of my project (2009), Innovate's serial protocol was poorly documented, though recent documentation is somewhat improved. Its D32 file format for the DL-32 was totally undocumented.

The DTA ECUs output channel data over their CANbus interface which was used for DTA's dashboard and TBW controller. The format is documented in their manual albeit sparsely.

DTA do sell a OT-1 CANbus interface that will add up to 16-channels of CANbus information into their log chain, but that deals with standard ISO message exchanges on the CANbus and not the proprietary (non-formatted) messages that DTA send.

So then, for this to work, I need to create an electronic box (DTAtoISP) that pretends to be an OT-1 to Innovate's system but understands DTA's data format. This would allow me to include the 16 channels of data that ECU produces in the Innovate datalog.

This is alot of work just to datalog but my second justification was instrumentation. I have four seperate 2" gauges today (dual CHT, dual EGT, Oil Pressure + Oil Temperature, and Air Fuel Ratio) making my lower dashboard look like a piece of swiss cheese and would prefer a single intelligent display. The electronic box I require for datalogging would also provide a single source of data for such a display.

So, there were really two seperate projects here, but both required a full understanding of Innovate's serial protocol (ISP). So that seemed the best place to start.

Innovate Serial Protocol

The data side to the protocol is quite straightforward. The head of the chain sends its data every 833mS and each device downstream adds its data as it passes it on.

On the control side, each device has to pass on and ultmately respond to nametype and devicetype requests that are send by the LogWorks software (and the DL-32) when connected to the chain so that the number and order of the channels can be understood.

To let me understand the minimum amount of information LogWorks needed to accept a datastream as Innovate's own I created a simple software program to playout D32 files over the serial port as though they were coming from an Innovate log chain itself.

With that understood, and reasonable, it was worth putting effort into writing a parser for the serial format. This would be used both in the intelligent display and the DTAtoISP box.

DTA CANbus Protocol

The CANbus output can be enabled by simply ticking a tickbox in DTA's software.

Once done, quite simply it sends four extended address 8 byte messages over the CANbus, each carrying four channels of information, every 100mS.

Later ECU firmware makes this interval programmable.

DTA to Innovate

I needed a microcontroller on which run the software needed to write that would add the data channels coming from the CANbus to the serial frames coming from a serial port. I quickly selected a PIC microcontroller, especially as the range included a device (PIC24HJ256) that included a CANbus controller, two serial ports, embedded flash and memory. Microchip's tools are priced within the range of a hobbyist so I bought a basic ICE system and ordered some samples of their PIC micro and the CAN PHY interface. I also bought a simple CANbus adaptor for my laptop to help debug on the CANbus implementation side.

The actual hardware design was pretty straight forward and after bread boarding it to develop the software I then built myself a unit for my car using veroboard. It wasn't worth getting printed circuit boards designed for a single unit.

And its been running quite happily for the last 2 and half years.

I've written the software so the unit will act as the head of an innovate log chain if nothing is plugged upstream of it. I always expect to use an LC-1 and probably a TC-4 ahead of one (I plan to also fuel inject my camper-van) but someone else may not - Yes I am willing to build a unit for someone if it is of interest.

Intelligent Display

I wanted a display that would work well in sunlight so looked at OLED-based ones. I originally planned to use another PIC to drive a slave display but then stumbled across 4D Systems intelligent displays which contain a programmable processor that would run all of the necessary software, thus simplifiing things dramatically. They also did touch-screen versions of said displays and I bought a 2.8" 320 x 240 touch-screen version for my project.

Early versions of the tools were somewhat buggy but I was able to get my Innovate Serial Protocol (ISP) parser up-and-running without too much trouble and soon had it dumping all 32 channels of the ISP frame as text on the display along with screens containing basic gauges.

The 4DGL language that is used for the displays sits somewhere between C and PASCAL and built-in routines handle the serial ports, fonts, drawing primitives, and filesystem access (It accepts a micro SD card for storing bit mapped images).

Fast forward a couple of years to late 2011 and the 4D systems tools have improved further and now make it easy to render high quality gauges onto the display.

They no longer sell OLED displays of 2.8" but do offer both 3.2" (320 x 240) and 4.3" (480 x 272) LCD touch-screen displays, but I did manage to pick up a 2nd OLED screen earlier in the year to use in my camper-van.

Again, i've written my software very generically so it will support other configurations of equipment than those used in my Chesil and planned for my camper-van.

I'll add some pictures and even some video of the gauges operating from an Innovate log stream shortly.

The only electronics additional to the display required is a 12volt to 5volt power supply and a RS232 level shifter....

I'd be prepared to give source of the parser to fellow enthusiasts to allow them to make similar gauges based on 4D Systems displays so long as my code wasn't put to commercial use.