Digital Instrument Gauges based on PLX SM-AFR and MFD

Discussion in 'How To' started by mikedjames, Oct 1, 2016.

  1. In the beginning I bought a PLX Devices inc Air Fuel Ratio meter to help with tuning up my progressive carburettor. At the time I bought direct from the USA and $200 plus $53 postage became £200 here in the UK.
    It is very fast acting and I bought a version with the older Bosch 4.2 sensor as that was what they had at the time.

    At the time apart from lengthening the wiring with a multicore screened cable I did nothing special so I did not bother posting a howto.

    Then I found a resource on the PLX devices website which was a document describing the digital protocol used between the computer box in the engine bay and the multifunction dash display. And explaining how to daisy chain sensors and displays.

    So I made a rev counter addon but using a very old 1990's microcontroller board ( the Philips LPC2106 chip on it can be bought NOS for about £30 these days).
    Again I did not write it up because it was made with effectively unobtainable parts..

    This worked well despite being damaged once by ignition coil flashover having to rewrite code to move pins around on the chip to bypass the damage.

    Then I melted the engine bay wiring and shorted the 12 volt battery voltage to the power supply of the dash display DM-6..So that stopped working and I had to make another display. This is when the interesting stuff starts.
     
    Last edited: Oct 1, 2016
    nicktuft and davidoft like this.
  2. To start with : the basic PLX Devices setup consists of a box in the engine bay. It contains a computer which controls the Bosch lambda sensor on the end of a few metres of cable. It provides three outputs and one input.
    It also contains the voltage regulators for the dashboard display which is its Achilles heel In a normal installation the display is just the other side of the firewall so it makes sense to have a metre or so of wire carrying supply voltages and data to the dash display. Not in a T2. More later.
    On the dashboard is a display consisting of another computer, a 32x128 matrix OLED display, a ring of coloured LEDS and three touch sensors (does not work with gloves on on cold days :()

    Outputs from the computer in the engine bay:
    • A narrowband lambda sensor emulation so you can unbolt a narrowband lambda sensor from the bung in the exhaust in some vehicles, install the PLX kit and fake the narrowband lambda signal to the ECU. Not a lot of use.
    • A wideband analog AFR output which produces 2.35 volts DC for a 14.7 AFR or (AFR-10)/2 volts. This is useful for tweaking the carburettor as the signal is in the engine bay. I often hook up a digital volt meter to this wire for setting idle mixture.
    • A digital signal which is 'TTL' level and intended for driving the dash display on a shortish wire. It does work on longer wires but I had to use proper screened cable. This signal carries the data from the computer to the display. It contains 'packets' of data which are sent every 100mS. The protocol used is basically what was once known as 'token ring'. The first device in the chain has no data coming in so it spits out a packet every 100mS, which identifies what kind of sensor it is, whether it is the first, second, third , fourth .. instance of that sensor and also a reading from 0 to 4095.
    As the first sensor in the chain has no input it will always be the first sensor of that kind.

    The input to the sensor is a stream of packets from devices earlier in the daisy chain. If a sensor sees 'packets' on its input, it passes through the data for those packets, and the instant the end of message marker is seen, it deletes it instead of forwarding it , and inserts its own packet of data, and sticks an end of message marker on the tail of the data.
    In this way up to 32 devices can use a single wire.

    By tapping the touch sensors on the DM-6 display the display can select one of the channels of data and display it. It can also switch units for instance between kPa and PSI for manifold boost pressure for instance. The sensor keeps on chugging along putting out 0 to 4095 or 0 to 1023 and the display simply changes its interpretation and presentation of the data .
    The display can display min/max values, show a value in large digits, or a graph of the sensor output.

    This protocol seems to have been invented in 2006 and predates CANBUS (OBDII) being easily and cheaply available on microcontrollers. It is also very easy to implement on small computers.

    It provides 10 samples a second. This means that with the engine idling, problems like misfire will be seen as intermittent blips of lean burn.

    For a while the document was provided openly on the PLX Devices website in order to assist in integration of other sensors with the PLX MFD.
    Using the Wayback Machine I was able to locate it .

    http://web.archive.org/web/20100114045954/http://www.plxdevices.com/AppNotes/PLXApp018.pdf
     
    jivedubbin likes this.
  3. The first add-on sensor

    This was the rev counter.

    Rather than running a wire from the ignition coil to the dashboard, a microcontroller was programmed to measure the frequency of the pulses from the contact breaker or electronic ignition unit. The frequency is then encoded into PLX speak and sent to the front of the bus, as a daisychained measurement on the data wire.

    The unit that I built had 'stronger' drive capability than the PLX SM-AFR, so it was wired second in the daisy chain, inserting its measurement 'after' the AFR measurement.

    It used an old Philips Semiconductors LPC2106 microcontroller board which plugged into a 40 pin IC socket. It was programmed in C using GCC and the Eclipse IDE. When I was developing this code though it was more a "fire and forget" kind of debugging - write the code, compile it and download and try to guess what was wrong by its behaviour.
    The output of the microcontroller was buffered through a second chip to try and protect the LPC2106 from electrical damage. But it did not work in the end (see later)

    The real challenge with this was that the signal I was looking for was a simple on/off switching of the contact breaker, there is a massive ringing voltage on the negative coil terminal. This can cross zero several times in a single firing of the coil, as that 'fat' spark is actually several sparks in succession.

    So the rev counter input had to be protected electrically and filtered electronically to reduce the number of pulses seen per firing of the coil to maybe less than ten. The remainder of the filtering is done in the software, deciding that very short pulses are actually part of the next opening of the points so their time is added to the total.

    The first circuit I created suffered from a coil flashover and it blew the pin on the LPC2106 so I changed the code to use a different timer, improved the protection circuit, to one I have kept in the latest version.

    But once built and coded, this worked happily until the short of +12 volts to the power supplies going to the dashboard display popped the dashboard display and also managed to damage the LPC2106 in a fatal way. It is all very well using 'clamping' diodes to restrict voltages on interface pins, but when the current feeding the pin is from a car battery they dont help for long.
     
  4. Sounds like you are having fun! And thanks for calibrating my rev counter.
     
  5. The PLX devices dash display retails for $99 and I was left with a known working AFR computer in the engine bay - the analog AFR pin output from the little red box was still working and I could see data pulses coming out using my oscilloscope.

    So I decided to make my own dashboard display. I used a pair of 1.3 inch white OLED 128x64 graphics modules as sold for Arduino experimentation. And an STMicro STM32F103 "Nucleo" board which is in the style of Arduino boards but which also has a pair of 38 way connectors on it with every pin from the microcontroller available on it. I bought a couple of 20 step rotary encoders at £2.90 for 10 in a packet. I use these to select functions, by twiddling knobs.

    And what makes a great difference with the Nucleo board : on one side is a USB connector and a complete programming interface allowing code download and debugging (can stop code at breakpoints or other conditions) . And also a serial port connected from the debugger to one of the UARTS on the STM32F103 chip. So the extra cost on top of the about £12 for the debugger/programmer interface is £0.

    Also, STMicro provide a tool called STMCubeMX which allows you to graphically assign pins and functions on the chip and then it writes about 80% of the setup code for the peripherals attached to the pins. The code is pretty horrible and sometimes like for UARTS it is about 99% totally useless, but generally it provides a major leg-up in getting going with a new ST Micro controller.
     
  6. This is fun, but it is quite hard to find time in between stripping down steering boxes , picking off filler to find loads of damp rust under the cab floor, and using the bus to go shopping..(I am on leave this week.. )
     
    nicktuft and Skater 8 like this.
  7. Post some photos of the kit you showed me!
    Personally I want an mpg readout at different speeds, actually no, I want a £/km readout at different speeds
     
  8. (Only because my speedo is in km)
     
  9. I will try and get some photos of the work in progress :
    at the moment I have sorted out cylinder head temperature using a cheap MAX6875 module which was a few pounds for a 0-1000 deg C thermometer that currently has a sensor put into the cylinder head temp sensor hole, but I see the spark plug ring thermocouples are about a fiver. So about a tenner per temperature sensor.

    So far the setup has
    AFR - the PLX Devices computer
    RPM - Work in progress - have the code from the old rev counter but I am doing something stupid.
    CHT - Reads temperature - can wave probe in front of laptop air vent for 49 deg C reading
    Battery 1 - Work in progress
    Battery 2- Work in progress
    MAP - Work in progress Bought an analog sensor for a tenner on eBay because seller couldnt work out which car it was for.... Citroen..
    Oil Pressure - Work in progress - analog 0-100PSI sensor off eBay . Turns out 0 on sensor is vacuum so could have used same type for MAP.

    The last four sensors are pretty straightforward but I have another small mistake in the code.

    Then I need to set up calibration for the analog sensors. Rather than using precision resistors, I have decided to store scale factors in non volatile memory in the engine bay computer.


    I also need to upgrade the display as I notice one of the two twiddle knobs does not work right.
     
    Valveandy and nicktuft like this.
  10. Just read this thread, I love it. Do you have your code posted any where ?I've been messing with arduino nano and some thermocouples and an LCD 2x16 display and this is encouraging to pull my finger out
    Cheers
    Andy
     
  11. Continuing the story, as it has been a little while .

    Things have moved on . I got the dashboard display running, there was a problem with a little bit of wiring shorting out a switch so that stopped the second control knob from working.

    There were problems with decimal points in the wrong place and also it forgot the switch settings when I powered it off, until I downloaded an application note and some example code for storing the settings in the program memory of the STM32F103 processor, which did not work until I totally re-wrote it. I should probably send it back to STMicroelectronics and tell them to update their broken example.

    The CHT sensor developed a fault as the tinware crushed it until the wires shorted to the cylinder head. The temperature read 0 degrees C all the time. So I ordered some new thermocouples off eBay and I will drill a hole in the tinware in the right place to get the wire through without squashing it.

    I also bought another Max6675 module as I think doing left and right CHT is more fun.


    So far the setup has

    AFR - the PLX Devices computer - running as the first device in the chain
    RPM - Working - have the code from the old rev counter , the problem is the timing from the distributor is all over the place at low RPM so the engine runs like junk and the RPM appears to shoot all over the place. Added some filtering and now it reads sensibly.
    CHT - Reads temperature - can wave probe in front of laptop air vent for 49 deg C reading. But now have broken the sensor in the cylinder head.
    Battery 1 - Wired up to leisure battery, reads voltage OK and with a bit of filtering
    Battery 2- Wired up to starter battery., reads voltage OK with a bit of filtering
    MAP - Reads vacuum but do not have calibration yet. I think it does not cover extreme vacuum levels but it reads 1019 engine off and about 670 with the engine idling. When pressing the throttle it increases and if you snap the throttle shut it goes to zero.. Since getting it working the barometer has stayed at 1019 mB ... so now I need a storm.

    Oil Pressure - Reads 2 PSI if I blow very hard into sensor. Working OK but I want to add an offboard electronic warning light switch. (power supply, comparator, transistor and normally closed relay to run oil light so I get the light coming on at 4PSI or whatever. Will not use the computer to do this as I want to be able to remove the computer but keep the electronic oil warning light. )

    I had to create a new measurement item in the PLX protocol for CHT as there is either fluid temperature or Exhaust Gas Temperature as options in the PLX protocol , which are either around 100 deg C max or 1000 deg C max. For now CHT is 0 to 300 deg C. But it is easy to change the entry in the table to alter the scaling.

    I blew a 2 amp fuse when I connected everything to the same fuse - PLX devices computer with its heater for the lambda sensor, my engine bay computer and the dash display computer in the engine bay.
    Changed the fuse for a 3 amp fuse.

    I am working out how to put the code up somewhere so people can take a look.
     
    Valveandy and nicktuft like this.
  12. Love it Mike.
     
  13. Like what you are doing, thought about doing something similar a few times but never got round to it. Post your code up in gitlab or similar, will give you version control as well :)

    Sent from my Nexus 6P using Tapatalk
     
  14. At the moment, I have put up the two Subversion repositories I have been using at

    http://host.hamble.online/websvn

    Expect it to be a bit slow.

    The makefiles are based on some I found in Olimex's OlimexODS which was what started me off with ARM and GCC. But that is old now.
    I have upgraded the Eclipse IDE, the C compiler and the OpenOCD tools.

    Uses as an IDE : Eclipse Mars 2 CDT with extra plugins - OpenOCD falls apart under Eclipse Neon CDT at present with silly errors,
    The IDE uses OpenOCD to talk to the debug board... and there are a few other bits and pieces - wrote the instructions down and forgot them. Will try to recover the information.

    And the C compiler is https://launchpad.net/gcc-arm-embedded
    The system designer is STMCubeMX from ST Microelectronics. - the .ioc file gives the settings used for the project.
     
    Last edited: Feb 5, 2017
    Valveandy and 67westy like this.
  15. Dude, this rocks!
     
  16. Baysearcher

    Baysearcher [secret moderator]

    I've just read this and can honestly say I don't understand a word of it.
    Good work Mike!
     
  17. For my current straw man design of my CHT I am looking at using the MAX31855 which interfaces a thermocouple, with cold junction compensation and converts the signal to digital. I am planning to use a raspberry pi as the microcontroller and then bluetooth alerts to my pebble smart watch. Your screen idea sounds interesting but I want to first get my worry gauges working.

    Great stuff. Much more intresting than all that VDO sh1te!
     
  18. Thanks. The MAX chip I have also features cold junction compensation and has a simple SPI interface which covers 0-1023 deg C in 0.25 degree steps.
    It was cheap on eBay.

    I am thinking of sticking a Bluetooth to serial module on a spare UART port on the dash display end and making it stream CSV formatted sensor readings rather than rely on Bluetooth from the engine bay.
     
    Cov1987 likes this.

Share This Page