So I have been mulling over a way to pull fueling when smoke is being blown out the tailpipe.  

 

This is going to take a few revisions, but my basic plan is to put an arduino between the apps and the ecm then read input voltage from the APP's while watching for smoke out the tailpipe, then adjust the APPS voltage to the ECM to reflect less TPS input if smoke is detected.

 

 

couple of issues,

 

1. keeping the sensor clean

2. version 1 won't work at night, since there is no natural light

3. placing the sensor at the end of the tailpipe may cause too much of a delay due to the time between stabbing the throttle and the time it takes for the plume of smoke to reach the end of the tailpipe.  

4. If I place it in the downpipe I will reduce the lag time before I sense smoke, but I also then have to deal with heat, and also have to include a light source, which would fix issue #2, but adds complexity.  ( guessing this is the route I will go)

5. Need to figure out a good way to output a given V to the ecm.  I dont know if I can use PWM from the arduino or not.

 

 

Ordered Parts.

 

6 pin Deutsche Plugs:

http://www.ebay.com/itm/331678354561?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

 

Arduino light sensor:

http://www.ebay.com/itm/Adafruit-ALS-PT19-Analog-Ambient-Light-Sensor-Breakout-Arduino-I2C-5v-3v-RoHS-/181959945589?hash=item2a5da86d75:g:2lQAAOSwbdpWbK9m

 

Some light source:

Uknown but looking for a 14v LED that can put up with heat.  Need to think of a way to protect

 

Arduino:

http://www.ebay.com/itm/Arduino-Mini-USB-Nano-V3-0-ATmega328-CH340G-5V-16M-Micro-controller-board-DIY-/322100994176?hash=item4afeb72080:g:KbwAAOSw2x1XLoTl

 

 

 

Now for the basic code thoughts.

 

input V from the APP's should be betwee .5v and 4.5v ( I think)  On a timer I need to watch for the analog input of V from the apps, then output the inputted voltage to the ecm.  This can be done once ever few ms.   Really just code that acts as a passthrough.

 

Next I watch the input V from the light sensor,   again .5v to 4.5v depending on how much light is visible.  In the middle of the above loop I need to watch the input V form the sensor, then negate the output V to the ecm by the % based upon the smoke levels in the exhaust.  IE: if there is a %5 reduction in visible light in the tailpipe then I need to reduce APPS V to the ecm by %5.  

 

 

 

 

 

In terms of big picture it would be like torque management, but based upon smoke output.  

 

Edited May 20, 20168 yr by Me78569

Well the more I think about it the more I am leaning away from a Opacity sensor and more towards a throttle sensitivity buffer.  

 

If you were to watch boost, ( already doing that with my turbo controller), and TPS input you could watch for snaps in throttle position, then buffer or limit the increase in TPS to a slower point.    If boost was above a given PSI, 10 for example you could just apply the demanded throttle position, but it it was less than that you could programmically roll into the throttle.   Heck you could even use this as an Anti-bark tool,  just in the same way as watching for snap increase in throttle you could watch for snap decrease in throttle and slow the release of throttle.

 

I know with my truck if I snap to %30 throttle from a standstill I get a good puff of smoke, where as if I roll into the throttle to %30, even if it is just a second or 2 to get there, I am %100 smoke free.

 

just more thoughts to keep me up tonight.

Edited May 20, 20168 yr by Me78569

I'm interested to see how you'd throw all this together. This is well beyond my knowledge scope so I'm all ears!

I think the TPS buffer idea is the best so far. Wrapping my brain around the idea.

You will still have %100 power but you would never have a snap TPS situation, thus no smoke  Rather you would have a smoothing effect on the throttle.    Joe blow could get in your truck, with the turner turned up and floorboard it without causing issues.  

 

 

You could pretty easily put a potentionmeter in place to define how much of a buffer is put in place.  off with the knob turned one way, then half position = 1 second to reach desired TPS then full turn = 2 seconds to reach desired position.  

 

You would have to put in a anti bark process that didn't buffer unless going from high TPS to 0.  Maybe a jump from %70+ TPS to 0 TPS would result in a %70 -->%20---> %0.  

 

the only issue I see with it is you may end up a situation when your need the ecm to listen to you and you would have that "delay" dunno how much this would matter, but something to consider.  

 

 

In the middle of this I am working on talking to the truck again with the arduino to read rpm ect from the obd rather than tapping all the wires under the hood.

I like the anti bark setup! I think that's harder to control then rolling on the throttle to reduce smoke. It would be nice if you didn't want to have smoke at all, but it seems easier to just tell yourself 'dont stab at it!' and the problems gone. To me, when getting on it and getting up in the boost, it's hard to remember to let off slowly.

Issue I have is Emissions here at 7000' altitude.  I cannot pass emissions without a smarty and setting the truck to 1/2 mode, because they do snap tests at idle, at 35 mph, and at 45 mph.

 

 

I am trying to solve that issue, but thought I could also solve the bark issue.

Edited May 21, 20168 yr by Me78569

Emissions in Colorado?! 

Yep,

 

In El paso county colorado, diesel trucks need to be emission tested every year.

 

 

Emissions are coming across the board.

How can they force emissions on a truck that didn't come with any restrictions  from factory, I thought it was 2007 and up.

Opacity testing from the tailpipe.

37 minutes ago, Me78569 said:

Opacity testing from the tailpipe.

 

So for people with fuel mods they catch you on the snap test for opacity. So Me78569 idea would be a way to forcibly control the snap test allowing you to pass without changing your tuning. I still wondering on the buffer and delay interval. You could base it on boost signal and limit max throttle on boost pressure.

Man that's rough, hope that doesn't turn into the norm up here in Washington.

Alright the code is ready for testing.

 

Here is a snippet to show my train of thought.

 

if ( BufferAdjust >= 2){
    if(LastOutTPS > InputCorrected + 13 || LastOutTPS < InputCorrected - 125){  // 13 is aprrox %5 TPS change for increasing TPS, 125 is about %50 TPS change for anti bark.
      if(BufferCount > BufferAdjust){
        
        BufferCount = 0;
        
        if(LastOutTPS < InputCorrected){
          APPSOutput = LastOutTPS + 1;
        }else {
          APPSOutput = LastOutTPS - 1;
        }
      }else {BufferCount++;}  
    }else {APPSOutput = InputCorrected ; }
   }else {APPSOutput = InputCorrected ; }

Pretty much it will adjust TPS input once every defined period.   you can adjust that period ( different section of code) from 0 to 2 seconds.  If you adjust the period down to 0 then it skips the above code.

 

If it the code runs it will increase or decrease TPS input by 1 until the TPS that was commanded was reached.  

 

Pretty much the TPS from the arduino should follow the requested TPS input from the apps as slow or fast as it configured via the Period defined.

 

uploading video now 

Here is version 1.0 beta

 

 

I am writing version 1.1 now, which has different delay for increasing throttle vs decreasing throttle so you can have antibark enabled without the increasing throttle delay.

Nice work Nick!

 

How different does it sound to the ear? That's the last thing I can think of that might tip of joe smo smog checker that maybe it doesn't sound like the throttle was blipped like it should've been according to pedal input ya know?

Sounds exactly the same, just acts like you have a laggy truck.

Do I hear a new product for sale in the store. Hmmm....????

I dunno, makes me really nervous to sell a device that sits between the ecm and TPS input.    

 

Heaven forbid the unit freezes at a high TPS input or something.

Totally agree with nick on that one.  Liability is nuts.  I won't have any part of it.  Shareware, mabe, but sale? nein.