Go Back   EcoModder Forum > EcoModding > Instrumentation > OpenGauge / MPGuino FE computer
Register Now
 Register Now
 

Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 09-05-2008, 10:42 PM   #1 (permalink)
testing the waters
 
Join Date: Jun 2008
Location: usa
Posts: 40
Thanks: 0
Thanked 1 Time in 1 Post
Help w/ mpguino space shuttle code please

Here's my attempt at smoothing out the vss output

(idea courtesy ac7ss)

Takes 3 values (say 50, 51, 70)

Finds out if the current reading is way off (70) by comparing it to the other two values (50, 51).

If it is a strange number, it just takes the other two values and averages them:

return (50 + 51) / 2


I think it helps some but it still will show an absurd value time to time like when accelerating or putting the clutch in, mabey my threshold needs to be adjusted...

This code could be added to your mpguino for better accuracy if you have funny readings

dcb, I'm sure you could write a better version, but I think it needs to be added for us guys with worn out speed sensors, it won't hurt the guys with good ones


Code:
// CUSTOM BY FORGOTTENMINDSET
// FOR ERROR PROOFING

unsigned long g_vssReading[3];
unsigned long g_vssSorted[3];
unsigned long g_vssReadingCount = 0;

unsigned long instantmph(){      
  cli();
  unsigned long vssPulseTimeuS = (lastVSS1 + lastVSS2) / 2;
  sei();
  init64(tmp1,0,1000000000ul);
  init64(tmp2,0,parms[vssPulsesPerMileIdx]);
  div64(tmp1,tmp2);
  init64(tmp2,0,3600);
  mul64(tmp1,tmp2);
  init64(tmp2,0,vssPulseTimeuS);
  div64(tmp1,tmp2);
  
  //////////////////////////////////////////////////////////////////////////
  // VALIDATE
  // WEED OUT ANY ODD READINGS FROM VSS Sensor
  //////////////////////////////////////////////////////////////////////////
  
  // Counter Mechanism
  if( g_vssReadingCount < 3 )  
    g_vssReadingCount++;
  else
    g_vssReadingCount = 0;
 
   // Update vss reading chain
   g_vssReading[g_vssReadingCount] = tmp1[1];
   
   
   // Find any way off readings, 10 mph threshold
   switch( g_vssReadingCount )
   {
     case 0:
      // Is 0 similar to 1?
      if((g_vssReading[0]-g_vssReading[1])<5000ul || (g_vssReading[1]-g_vssReading[0])<5000ul)
        // Is 0 similar to 2?
        if((g_vssReading[0]-g_vssReading[2])<5000ul || (g_vssReading[2]-g_vssReading[0])<5000ul )        
            // Good reading, return normal
            return g_vssReading[g_vssReadingCount];
            
      // Unsimliar value found, return best guess
      return (g_vssReading[1] + g_vssReading[2]) / 2;
      break;
      
     case 1:
      // Is 1 similar to 0?
      if((g_vssReading[1]-g_vssReading[0])<5000ul || (g_vssReading[0]-g_vssReading[1])<5000ul)
        // Is 1 similar to 2?
        if((g_vssReading[1]-g_vssReading[2])<5000ul || (g_vssReading[2]-g_vssReading[1])<5000ul )        
            // Good reading, return normal
            return g_vssReading[g_vssReadingCount];
            
      // Unsimliar value found, return best guess
      return (g_vssReading[0] + g_vssReading[2]) / 2;
      break;
      
     case 2:
      // Is 2 similar to 1?
      if((g_vssReading[2]-g_vssReading[1])<5000ul || (g_vssReading[1]-g_vssReading[2])<5000ul)
        // Is 2 similar to 0?
        if((g_vssReading[2]-g_vssReading[0])<5000ul || (g_vssReading[0]-g_vssReading[2])<5000ul )        
            // Good reading, return normal
            return g_vssReading[g_vssReadingCount];
            
      // Unsimliar value found, return best guess
      return (g_vssReading[0] + g_vssReading[1]) / 2;
      break;
   }  
  
  // return normal since no bad reading was found
  return g_vssReading[g_vssReadingCount];
}

  Reply With Quote
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 09-05-2008, 10:44 PM   #2 (permalink)
testing the waters
 
Join Date: Jun 2008
Location: usa
Posts: 40
Thanks: 0
Thanked 1 Time in 1 Post
Basically, I'd like someone to throw any input they can and/or install the code on their box and perfect it
  Reply With Quote
Old 09-06-2008, 03:41 AM   #3 (permalink)
dcb
needs more cowbell
 
dcb's Avatar
 
Join Date: Feb 2008
Location: ÿ
Posts: 5,038

pimp mobile - '81 suzuki gs 250 t
90 day: 96.29 mpg (US)

schnitzel - '01 Volkswagen Golf TDI
90 day: 53.56 mpg (US)
Thanks: 158
Thanked 269 Times in 212 Posts
LOL, I like the "Space Shuttle" characterization

I did try it, and it was still bouncy (would drop to 17 from 27mph on occasion).

Tried a couple other things:
1. track the last 3 pulse time stamps and do a "vote", still wonky

2. track last 4 vss pulse lengths and average. Better, but jumpier than just vss tic count per half second.

3. keep track of the minimum pulse timing (max speed), reset when instantmph() is called (every 1/2 second). Actually was pretty consistent reading, a couple minor jumps, but it was really off. @20mph the guino was saying 35mph.

4. keep track of the maximum pulse timing (min speed), reset when instantmph() is called. Even more consistent, but also off. @20mph the guino was saying 12mph.

So something to mull over anyway.

I also did some coasting with the raw instant screen to see how the vsspulse looked. The number of pulses per half second would drop smoothly, not dropping more than 1 pulse at a time when slowly decelerating. So the counter logic looks good, just this instant timing is hard to nail down.

I got some metro bits from coyote (thx coyote/shultz!) so will probably hook up a reed switch on the bench and hack at it, and dissect an ECU
__________________
WINDMILLS DO NOT WORK THAT WAY!!!

Last edited by dcb; 09-06-2008 at 09:14 AM..
  Reply With Quote
Old 09-06-2008, 01:32 PM   #4 (permalink)
dcb
needs more cowbell
 
dcb's Avatar
 
Join Date: Feb 2008
Location: ÿ
Posts: 5,038

pimp mobile - '81 suzuki gs 250 t
90 day: 96.29 mpg (US)

schnitzel - '01 Volkswagen Golf TDI
90 day: 53.56 mpg (US)
Thanks: 158
Thanked 269 Times in 212 Posts
I was thinking about a "speedometer algorithm" this morning, after dissecting a speedometer. You know, add a "spring" component to reduce the speed towards zero, and weigh each pulse evenly and have that as a force input, and the balance would be the actual speed. BUT,

I went for a drive this morning, and watched the speedo more closely than usual, and the needle itself bounces. Like up and down 1mph 4 times a second at 20mph! I realized this is not just warn bushings, but the cable itself and it's sheath, and the junctions/gears, plus reed switch fun on top of all that for the guino.

I also took a look at the ecu circuit, nothing special there as far as I can tell. Just a diode for protection and a voltage divider. I think I realized that this particular car computer doesn't really care about accurate mph at lower speeds. When monitoring the speed value on the obd port, it is really slow to react, doesn't bounce like the mechanical speedo, so they probably just look at a lot of pulses over a longer period of time.

So, we could take that approach too, but I was encouraged by the discovery that keeping track of the maximum pulse length produced fairly consistent results. It may be that we add another setup parameter to compensate for the "slop", i.e. 1.6 (or 1600) for the metro. This would not be a memory or computationally expensive thing. Hopefully the "slop" isn't too speed sensitive
__________________
WINDMILLS DO NOT WORK THAT WAY!!!
  Reply With Quote
Old 09-06-2008, 04:18 PM   #5 (permalink)
Addicted
 
bbjsw10's Avatar
 
Join Date: Jul 2008
Location: Findlay,OH
Posts: 555

bbjsw10 - '91 Geo Metro Xfi
90 day: 51.06 mpg (US)
Thanks: 0
Thanked 11 Times in 7 Posts
Quote:
Originally Posted by dcb View Post
I went for a drive this morning, and watched the speedo more closely than usual, and the needle itself bounces. Like up and down 1mph 4 times a second at 20mph! I realized this is not just warn bushings, but the cable itself and it's sheath,
I was thinking about this last night while trying to fall asleep. I think it would be a good idea on older cars to pull cable and re-lube them just to help smooth out a little more. Or maybe making or finding some kind of adapter that would go on the tranny end of cable to get rid of this problem. That just means more money and not so plug and play, which is nice.
__________________
  Reply With Quote
Old 09-06-2008, 06:49 PM   #6 (permalink)
EcoModding Lurker
 
Join Date: Sep 2008
Location: Olympia, wa
Posts: 96

Red Beast - '82 Honda V45 Sabre Vetter Fairing
90 day: 39.38 mpg (US)

The Wife's bike - '82 Honda CM450E Red
90 day: 57.22 mpg (US)

Yellow Submarine - '04 Dodge Neon SXT
90 day: 28.71 mpg (US)
Thanks: 6
Thanked 1 Time in 1 Post
Quote:
Originally Posted by forgottenmindset View Post
Here's my attempt at smoothing out the vss output

(idea courtesy ac7ss)

Takes 3 values (say 50, 51, 70)

Finds out if the current reading is way off (70) by comparing it to the other two values (50, 51).

If it is a strange number, it just takes the other two values and averages them:

return (50 + 51) / 2


I think it helps some but it still will show an absurd value time to time like when accelerating or putting the clutch in, mabey my threshold needs to be adjusted...

This code could be added to your mpguino for better accuracy if you have funny readings

dcb, I'm sure you could write a better version, but I think it needs to be added for us guys with worn out speed sensors, it won't hurt the guys with good ones
Code:
// CUSTOM BY FORGOTTENMINDSET
// FOR ERROR PROOFING
// Mod By AC7SS

unsigned long g_vssReading[3];
//AC7SS Remove unneccesary global variables

//AC7SS I assume this is to return valid VSS time value correct?
unsigned long instantmph(){      
  cli();
//AC7SS remove  unsigned long vssPulseTimeuS = (lastVSS1 + lastVSS2) / 2;
  sei();
  init64(tmp1,0,1000000000ul);
  init64(tmp2,0,parms[vssPulsesPerMileIdx]);
  div64(tmp1,tmp2);
  init64(tmp2,0,3600);
  mul64(tmp1,tmp2);
  init64(tmp2,0,vssPulseTimeuS);
  div64(tmp1,tmp2);
//AC7SS: Added internal values:
  unsigned long minVssPulseTime;
  unsigned long maxVssPulseTime;
  unsigned long avgVssPulseTime;

   
  //////////////////////////////////////////////////////////////////////////
  // VALIDATE
  // WEED OUT ANY ODD READINGS FROM VSS Sensor
  //////////////////////////////////////////////////////////////////////////
  
  // Counter Mechanism
// AC7SS replace with shift of registers.  
//  if( g_vssReadingCount < 3 )  
//    g_vssReadingCount++;
//  else
//    g_vssReadingCount = 0;
   g_vssReading[0] = g_vssReading[1];
   g_vssReading[1] = g_vssReading[2];
   // Update vss reading chain
   g_vssReading[2] = tmp1[1];
   
   
//AC7SS: simpler algorithm:
  //Three cases:
    //find minimum/max/average of all three values:
    minVssPulseTime = g_vssReading[0];
    maxVssPulseTime = g_vssReading[0];
    if(g_vssReading[1]<minVssPulseTime) minVssPulseTime = g_vssReading[1];
    if(g_vssReading[2]<minVssPulseTime) minVssPulseTime = g_vssReading[2];
    if(g_vssReading[1]>maxVssPulseTime) maxVssPulseTime = g_vssReading[1];
    if(g_vssReading[2]>maxVssPulseTime) maxVssPulseTime = g_vssReading[2];
    avgVssPulseTime = (g_vssReading[0] + g_vssReading[1] + g_vssReading[2])/3;

  //case 1: all are within tolerances (say 3%), return last reading.
    if((minVssPulseTime/maxVssPulseTime)>0.97) return g_vssReading[2];

  //case 2: last reading is anomalous: return previous reading. (Please re-write to get the correct method, I am away from my reference material)
    if(1.03>(g_vssReading[2]/avgVssPulseTime)>0.97) return g_vssReading[1];
  //case 3: either of the other readings is the anomalous one:
    return g_vssReading[2];

}
Run this through the compiler and check the byte counts. (I know I made errors, deal with them.)

The meat of the program is the last 3 lines of code. no conversion to mph is necessary, all you want to do is set a threshold for rejection (3% in this code example). You never change the actual values of the readings, so if they are real readings that are outside of the range, it will still return the real value. I figure you will not be able to make a 3% change in speed between pulses. at 5 mph, you would have to speed up to 6 mph in 7 pulses. At 50 mph, you would have to speed up to 53 mph in 2 pulses. at 4000 pulses per mile, NOT BLOODY LIKELY.
__________________
  Reply With Quote
Old 09-06-2008, 06:56 PM   #7 (permalink)
dcb
needs more cowbell
 
dcb's Avatar
 
Join Date: Feb 2008
Location: ÿ
Posts: 5,038

pimp mobile - '81 suzuki gs 250 t
90 day: 96.29 mpg (US)

schnitzel - '01 Volkswagen Golf TDI
90 day: 53.56 mpg (US)
Thanks: 158
Thanked 269 Times in 212 Posts
Do you guys not have guinos that you can test your own work? I appreciate the effort, but it can cause a lot of frustration to publish non unit tested code and take a loooong time to get sorted out. Testing is in many ways the hardest part.
__________________
WINDMILLS DO NOT WORK THAT WAY!!!
  Reply With Quote
Old 09-06-2008, 07:04 PM   #8 (permalink)
EcoModding Lurker
 
Join Date: Sep 2008
Location: Olympia, wa
Posts: 96

Red Beast - '82 Honda V45 Sabre Vetter Fairing
90 day: 39.38 mpg (US)

The Wife's bike - '82 Honda CM450E Red
90 day: 57.22 mpg (US)

Yellow Submarine - '04 Dodge Neon SXT
90 day: 28.71 mpg (US)
Thanks: 6
Thanked 1 Time in 1 Post
Averaging the 2 non-anomalous readings is bad, it introduces instability to the equation. With 3 readings we are counting on only one being bad, if 2 are bad, it will return the bad average anyway.

The plan that I had proposed would return the least anomalous of the last 2 readings.

If we need a larger sample to average, it would take a bit more code and variable space and we would merely make a average of 10 (Slower 'instant' readings at low speed) or running average of the last 10 (Instant update, lagging by 5 values). IMO, this would bypass the entire 'instant' reading idea. both also introduce errors at low speeds.
__________________
  Reply With Quote
Old 09-06-2008, 07:05 PM   #9 (permalink)
EcoModding Lurker
 
Join Date: Sep 2008
Location: Olympia, wa
Posts: 96

Red Beast - '82 Honda V45 Sabre Vetter Fairing
90 day: 39.38 mpg (US)

The Wife's bike - '82 Honda CM450E Red
90 day: 57.22 mpg (US)

Yellow Submarine - '04 Dodge Neon SXT
90 day: 28.71 mpg (US)
Thanks: 6
Thanked 1 Time in 1 Post
my parts are on order. I should have a guino in 2 weeks and will try it with the public code and try it with the additions.
__________________
  Reply With Quote
Old 09-06-2008, 07:16 PM   #10 (permalink)
dcb
needs more cowbell
 
dcb's Avatar
 
Join Date: Feb 2008
Location: ÿ
Posts: 5,038

pimp mobile - '81 suzuki gs 250 t
90 day: 96.29 mpg (US)

schnitzel - '01 Volkswagen Golf TDI
90 day: 53.56 mpg (US)
Thanks: 158
Thanked 269 Times in 212 Posts
I might be on to something with the min vss pulse spacing per half second approach mentioned in post 3 & 4. Need to do some more experiments though. An occasional glitch on the instant reading is ok, one can filter them out without much fuss, but it needs to be more stable than it is if you are trying to dial in best cruise mpg.

I'm not wild about just increasing the size of the sample pool either, or inviting floating point math to the party.

__________________
WINDMILLS DO NOT WORK THAT WAY!!!
  Reply With Quote
Reply  Post New Thread


Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
MPGuino release one workspace dcb OpenGauge / MPGuino FE computer 1061 01-17-2020 02:37 AM
Just some quick info on Scangauge vs. MPGuino NoCO2 OpenGauge / MPGuino FE computer 4 06-01-2015 05:58 PM
MPGuino installation/setup: 1998 Geo Metro (Pontiac Firefly) MetroMPG OpenGauge / MPGuino FE computer 12 10-11-2009 04:29 PM
Some suggestions and notes on the MPGuino SVOboy OpenGauge / MPGuino FE computer 4 08-01-2008 09:00 AM
Questions about mpguino mhmitszach OpenGauge / MPGuino FE computer 37 07-01-2008 08:38 AM



Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com