HE351 code for me78569

[hakcenter]

Delays could change output.

What is the exact code you're using for 4 intervals? Are you not running it the way i am?

[me78569]

Code Select Expand

void loop() {

  // Freq Measure
  unsigned long sum[4];
  unsigned long final_sum;
  byte count = 0;
 
  // loop
  while(1) {
    t1.update();
    t2.update();
   
    // Freq Measure
    if (FreqMeasure.available()) {
      // average several reading together
      sum[count] = FreqMeasure.read();
      count++;
      // turbo_rpm = Freq(sum / count) * 60
      final_sum = 0;
      for (int i = 0; i < 4 ; i++) { final_sum += sum[i]; }
      turbo_rpm = FreqMeasure.countToFrequency(final_sum >> 2);
      turbo_rpm = (turbo_rpm << 6) - (turbo_rpm << 2);
      if (count > 3) { count = 0; }
    }
  }
}


32 is the lowest number of reads that has steady reads. 

think possibly I am running too many things in my keeptime that is causing a delay in the freqcount?

I will comment out stuff and see I guess haha.



I really like how the rpm mapping works on the low end, but the more I think about it I think the turbo speed up high should set a position rather than map like you said.  I also think TPS should be taken into consideration and increase or decrease that position from there. 

[hakcenter]

Imho the first thing in your code i would take out is the lcd. And see how it fairs

[Rx7man]

There's gotta be a reason for it.. but be darned if I know what it is   some help I am eh?

[Rx7man]

Oh, here's ONE possibility.. freqmeasure isn't catching all the pulses... I wrote my own code for it, and with some rough testing it seemed to work well..

So you have a global variable

Code Select Expand


int TSScounts;

And you have an interrupt enabled pin and routine

Code Select Expand


void Setup(){
.
.
.
  /* Here's the interrupts on various boards
  Board         int.0 int.1 int.2 int.3 int.4 int.5
  Uno, Ethernet 2 3
  Mega2560 2 3 21 20 19 18
  Leonardo 3 2 0 1 7
  */
  attachInterrupt(1, TSSpinISR, FALLING);
}



And whenever you want the RPM updated, call this sub to update the global variable (TSStimeout is a global variable too, but could be localized if you want...

Code Select Expand


void CalculateTSS() {
  static unsigned long LastMicros = micros();
  unsigned long Now = micros();
  unsigned long Timespan = Now - LastMicros;
  unsigned int NewRPM = 60000000 / Timespan * TSScounts;
  int counts = TSScounts;
  if (Timespan > TSStimeout) { // a second has elapsed without accumulating enough counts, thus the turbine is stopped
    // Serial.println("Reset RPM to 0");
    TSS.Reset(); //one of the rare times you access the storage directly
    LastMicros = Now;
  }
  else  if (counts > TSSminCounts) {//only update value if we have enough counts to do something with.. rather increase the timespan (by waiting until the next go round) to get a closer approximation
    TSScounts = 0;
    LastMicros = Now;
    TSS.UpdateValue(NewRPM);
  }
}



//And finally the very simple ISR
void TSSpinISR() {
  TSScounts++;
}


[hakcenter]

FreqMeasure falls on an interrupt pin and 64bit blah blah blah roll over blah blah blah

It's accurate and fast on pin 8.

However fast the code can come around and measure will drastically affect the average.

If one time you got to count for 100ms then next time counted for 150ms, there's going to be variation.

[me78569]

yep,

I am looking elsewhere at this point. 

I am more concerned about the overspin and tuning the top end as I can user averaging of 32 reads to gt good rpms results.

[hakcenter]

If you have any libraries that disable interrupts that can royally ruin FreqMeasure as well

[Rx7man]

that's a very good point!

[hakcenter]

Well... I went back to stock 1.1 code minus the top end.

Code Select Expand


  // Update vane_position every 10ms 100k+ / 25ms 60k - 100k / 100ms 0 - 60k
       if (timer % 10 == 0 && turbo_rpm > top_end_rpm) { update_vane_position = true; }
  else if (turbo_rpm > curve_rpm[4] && timer % 25 == 0) { update_vane_position = true; }
  else if (timer % 50 == 0) { update_vane_position = true; }


Code Select Expand


  // Vane smoothing between large values
  if (turbo_rpm < top_end_rpm) {
    if (vane_position >= last_vane_position + 20 && last_vane_position < max_position - 10) {
      final_vane_position = last_vane_position + 10;
    } else if (vane_position <= last_vane_position - 20 && last_vane_position > min_position + 10) {
      final_vane_position = last_vane_position - 10;
    } else if (vane_position - 10 >= last_vane_position || vane_position + 10 <= last_vane_position) {
      if (vane_position > last_vane_position + 2 && last_vane_position < max_position - 2) {
        final_vane_position = last_vane_position + 2;
      } else if (vane_position < last_vane_position - 2 && last_vane_position > min_position + 2) {
        final_vane_position = last_vane_position - 2;
      }
    }
  }
  // Update last_vane_position


Code Select Expand


      for (int i = 0; i < 64 ; i++) { final_sum += sum[i]; }
      turbo_rpm = FreqMeasure.countToFrequency(final_sum >> 6);
      turbo_rpm = (turbo_rpm << 6) - (turbo_rpm << 2);
      if (count > 63) { count = 0; }


Code Select Expand


} else {
               if (performance_mode && turbo_rpm <= 120000) { vane_position = map(turbo_rpm, top_end_rpm, 120000, turbo_curve[4] + performance_position, 580); }
          else if (turbo_rpm <= 120000) { vane_position = map(turbo_rpm, top_end_rpm, 120000, turbo_curve[4], 580); }
          else if (turbo_rpm <= 122000) { vane_position = 500; }
          else if (turbo_rpm <= 124000) { vane_position = 440; }
          else if (turbo_rpm <= 126000) { vane_position = 340; }
          else if (turbo_rpm <= 128000) { vane_position = 220; }
          else { vane_position = map(turbo_rpm, 128000, 130000, 220, min_position); }
        }


Working great on my truck! Infact I had to move the last position 1cm, tuned it in half cm increments. Comes in pretty hard, slightly slows down, gets stuck for a long time, rolls into mapping to 0 then comes slightly back!

Truck is still a rocket as well... really enjoying it, obviously the idle walkdown needs more work I found instances where it popped out of it... so I'll have to figure something out.

[me78569]

I am going to attempt that top end tomorrow.  Looking forward to it.

[me78569]

Much better,  I need to adjust my curve a bit, but it tried pretty hard to stay right at 130000

[me78569]

And the two other libraries that I am using are

#include <Wire.h> 
#include <LiquidCrystal_I2C.h>

Looking through them now to see any funny business about disable interrupts

[Rx7man]

I don't know much about the Wire library, but perhaps the I2C library uses an interrupt of higher priority, and if it does a lot of stuff in there it might delay yours... Just another of my thoughts

[me78569]

I see other people using freqmeasure using the i2c library together. 


The more I read the more I am thinking the lcd update is causing the hiccup in the freqmeasure.