Jump to content

Recommended Posts

I have to mention RobG and cubeberg have helped with this. THANKS!!!!

 

What it is, is one pressure sensor affecting two, 16 bit DAC output channels.

 

What it will do (hopefully ;-)) is read an (automotive) industry standard MAP (manifold absolute pressure) sensor- in this case an MPX4250A 20-250 kPa (kilo Pascal) / 2.9-36.3 PSI sensor (~100 kPa / 14.7 PSI is ambient pressure at sea level), and appear as up to two potentially different sensors. Possible uses could include: replacing obsolete MAP sensors with more readily available ones because of different output range / scaling; fooling a vehicle's engine control unit to allow for bigger injectors or turbocharging; splitting one MAP signal for two purposes; or affecting pressure controlled devices.

 

The aforementioned MAP sensor will be connected to whatever vacuum / pressure source. The MCU will sample that and generate an output. But instead of doing a mathematical conversion, there will be look-up tables. This will permit non-linear adjustments to be made, allowing for compensation factors to be applied to the output, tuning.

 

What I am uploading now, is a Booster Pack version of this, which should be usable with MSP430 and Stellaris/Tiva LaunchPads. Eventually, I want to have a complete stand-alone, with software to interface with it from a PC. I think we are close to that too; but still some details to work out.

 

Hardware is:

- MPX4250AP absolute pressure sensor- http://www.freescale.com/files/sensors/doc/data_sheet/MPX4250A.pdf

- AD8644A quad op-amp- http://www.analog.com/static/imported-files/data_sheets/AD8614_8644.pdf

- LTC2602IM dual-channel, 16 bit DAC- http://cds.linear.com/docs/en/datasheet/2602fa.pdf

- 25AA512 eeprom- http://ww1.microchip.com/downloads/en/DeviceDoc/22021F.pdf

- supporting resistors, capacitors, do dad's and whatnot's.

 

Should probably mention I have added jumpers to disconnect V+ from either of the output sensor connections... the board is meant to be connected to the sensors and use their 5V+ to power the op-amp and provide external voltage reference for the ADC, but on my motorcycle one of the sensors has 12v and an internal voltage regulator. Therefore, I put the jumpers in so any sensor with inappropriate V+ could be kept out of the system. I've also put a jumper between the 5v from the sensors and the 3.3v LDO so that the LDO can be disabled if the LaunchPad is operating off USB.

 

I do not have any presentable code to offer at the moment but am working on it; suggestions will be appreciated... and I'm working in Energia, which might have been evident with my post in the Energia forum: http://forum.43oh.com/topic/4292-multiple-slaves-on-spi/, so be kind. ;-)

 

SingleBP.brdSingleBP.sch

 

Comments and suggestions greatly appreciated.

 

* Please ignore the name "SingleBP". I used that because the 500T version of my motorcycle uses 4 MAP sensors, and the 650T uses two. So "Single" means one unit needed for the 650T.

post-26656-0-95821600-1377484483_thumb.jpg

Share this post


Link to post
Share on other sites

As I mentioned, no reasonably presentable code....

And Energia, to refresh your memory.
 

#include <SPI.h>
/* hardware pin assignments */
const int AIN0 = P1_0;                             // input for the MAP sensor ADC
const int AIN1 = P1_3;                             // reserved for future use
const int MEMCS = P2_1;                            // EEPROM chip select pin
const int DACCS = P2_2;                            // DAC chip select pin

/* Other connected pins (MSP430G2553, 20 pin):
 VCC= 3.3v
 GND= Ground
 P1_1 - RXD
 P1_2 - TXD
 P1_4 - ADC external voltage reference
 P1_5 - SCLK / SCK / CLK
 P1_6 - MISO / SDI / SI
 P1_7 - MOSI / SDO / SO */
 
/* LTC2602 DAC http://ww1.microchip.com/downloads/en/DeviceDoc/22021F.pdf 
 EEPROM commands based on the datasheet.
 
 Prior to writing, a WREN (Write Enable) instruction must be sent and chip select be brought HIGH.
 
 Still working on this. */

const byte memRead = 3;                            // 00000011 read data from memory beginning at address
const byte memWrite = 2;                           // 00000010 write data to memore beginning at address
const byte memWren = 6;                            // 00000110 set write enable latch (enable writes)
const byte memWrdis = 4;                           // 00000100 reset write enable latch (disable writes)
const byte memReadStatR = 5;                       // 00000101 read STATUS register
const byte memRriteStatR = 1;                      // 00000001 write STATUS register
const byte memPageErage = 66;                      // 01000010 page erase
const byte memSectorErase = 216;                   // 11011000 sector erase
const byte memChipErase = 199;                     // 11000111 chip erase
const byte memDeepPowerDown = 185;                 // 10111001 deep power down mode
const byte memExitPowerDown = 171;                 // 10101011 release from deep power down, read signature

void MEM () {                                      //still working on this
}

/* initialize hardware */
void setup()
{
  analogReference(EXTERNAL);                       // set ADC to external reference
  pinMode (DACCS, OUTPUT);                         // set DACCS pin to OUTPUT
  digitalWrite (DACCS, HIGH);                      // pull DACSCS HIGH so it ignores things
  pinMode (MEMCS, OUTPUT);                         // set MEMCS pin to OUTPUT
  digitalWrite (MEMCS, HIGH);                      // pull MEMCS HIGH so it ignores things
  SPI.begin ();                                    // initialize SPI
  SPI.setBitOrder (MSBFIRST);                      // MSB out first; might change in the future
  SPI.setDataMode (SPI_MODE0);                     // slaves clock in values on rising clock.
  DAC (writeAndUpdateDacA, 32768);                 // set DACA to mid-scale
  DAC (writeAndUpdateDacB, 32768);                 // set DACB to mid-scale
}

/* main program working variables */
unsigned int newMap = 0;                           // variable to store the current ADC value
unsigned int oldMap = 0;                           // variable to store the previous ADC value
unsigned int dacAout = 0;                          // variable to hold the output for DACA
unsigned int dacBout = 0;                          // variable to hold the output for DACB

/* main program */
void loop() {
  // check UART for tuning software connection and handle it (figure out how to interleave with a running system)
  // sample MAP
  // compare new MAP to old MAP and if equal, do nothing
  // MAP changed, calculate what to get from memory
  // get values from memory
  // send values to DAC for output
// send the values to UART, might need to scale this so as to not overwhelm it
}

Share this post


Link to post
Share on other sites

I was asked by someone elsewhere about "fault" modes and how this would handle it.

 

The motorcycle this is 'aimed' at can only sense open and short on the sensor signal wire. I kind of think that the unit really shouldn't do anything other than work or don't work, but if the input MAP sensor fails, perhaps the DAC could be told to go to 0v or full output. These are abnormal values as the sensors don't output less than 0.20 or more than 4.8v, and therefore 0v out would appear as a short to ground, and 5v out (more accurately the input rail) would appear as short to V+. Either should trip the ECU limp mode, where the ECU drops to a default, fixed value for the faulted sensor and lights a warning on the dashboard.

 

Another thought I had was the MCU could control power to the op amp and interrupt it if the MPX / input sensor output values exceeding it's specifications and thus create an 'open' condition on the outputs and trip fault handling in the ECU.

 

Maybe a 2nd MCU should be employed to handle faults? It could sample the outputs to verify they are within some bounds, though not necessarily within 'tolerance', and open the outputs to trip faults?

 

 

Who's the first to suggest Hercules?

Share this post


Link to post
Share on other sites

Damnit, beat me to it... was going to suggest Hercules right until your last sentence! ;-)

 

The Hercules can offer double-checking of the ADC, internal checking of its own CPU core & memory subsystem (via ECC), and then the ESM output pin (nERROR) is an open-drain that could be used to cut the connection to the ECU somehow.

 

I don't think the Hercules LaunchPad's chip (a sort of "value line" Hercules) has a DAC output, but it does have a ridiculously badass timer module (N2HET).  Probably massive overkill.

 

Power consumption is also a potential concern, as the Hercules draws somewhere in the vicinity of 100-150mA I think.  Maybe less, didn't actually measure it but going by the datasheet it was pretty high.

Share this post


Link to post
Share on other sites

@@spirilis - Gotcha!

 

As I'm coding in Energia, Hercules isn't supported. I might be able to target Stellaris then alter the code Energia passes to mspgcc to suit the Hercules since they are both ARM M4 cores and can theoretically run the same code. I would have to consider the dual core of the Hercules and figure out how to work with that. Wife's gonna love me having yet another board in the house. :D

 

Power wise, the regulator in the ECU providing 5v is assumed to be a Toshiba 2SD716, it's marked "D716", and by the datasheet is rated 6 amps at 5v. I assume this is also being used to power most of the electronics within the ECU as well as the sensors. It has common output and ground return rails for all the sensors and a friend says he measured ~850 mA consumed by the sensors. This includes 3 pressure sensors, two temperature sensors (coolant and intake air) and the throttle position sensor. As the temp and throttle sensors are resistive, I assume those account for more than half the current draw.

 

As this BP / board is intended to replace two sensors, those two sensors will no longer be drawing power thus releasing that current for this board to use. But worse case is the user only replaces one sensor with this so there goes half the current source.

 

RobG originally suggested having an external 12v source connection to the bike. I was hoping to use the sensors' power for this and at least for a few people I know mount it within a stock sensor's housing because they race and things have to appear stock. I might have to reconsider this and use 12v to power the electronics and only use the 5v from the bike's sensors to reference ADC and DAC.

Share this post


Link to post
Share on other sites

Hercules LaunchPad isn't M4, it's R4 (not R4F either like Stellaris/Tiva which is M4F; the Hercules LaunchPad only does integer math, however all the higher-end Hercules chips are in fact R4F with FPU), it's not supported by Energia and probably never will be (imo)... its configuration begins with TI's HALCoGen GUI configurator tool, which has all the hardware abstraction built in, and then the output of HALCoGen is imported into CCS or other tools and used from there.  Very different beast, for your use-case (or really most hobbyist's use-cases) I don't recommend it :grin:

 

Also the dual cores aren't used to enhance performance; the 2nd core is merely a lock-step redundant checker core, it always runs the exact same code as the first core just a few clock cycles behind, with an internal hardware module that "checks" the results of both cores to discover inconsistencies (indicating compromised CPU operation; this then triggers the nERROR pin output which should do something failsafe-ish).

 

I think Hercules would make a good fit for a project written from scratch (i.e. no Energia or Arduino baggage involved) that does require the safety considerations; i.e. critical digital power electronics in a hybrid or electric vehicle (with digital drive-by-wire; you DON'T want the electronic "throttle" to suddenly slam open due to a silly electronic malfunction in the CPU), the typical use-cases offered by TI include brake system control, steer-by-wire (!!! the thought of that frightens me even more than drive-by-wire, BTW), etc.

 

Anyway this is somewhat derail-ish since I don't think you want to use Hercules, but hopefully it's a good summary to get your familiar with what it is :)

Share this post


Link to post
Share on other sites

Thanks for the information. I hadn't looked at Hercules with any depth so the information you've provided is helpful. But I have to say that if this thing decided to bork at the wrong time, it's possible a pair of pistons could be ejected and cause some damage. ;)

 

This topic should be solely dedicated to the booster pack version and since it's still a work in progress I started a topic in Projects so any discussions can occur there.

Share this post


Link to post
Share on other sites

Somewhere along the line, I mentioned mcp4922 for the DAC....

Anyone see issues with these... other than the obvious "why did you use PDIP chips?" type of thing?

 

>see next post<

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...