Lil' Blackbox

Coding => v2.0 => Topic started by: hakcenter on August 28, 2016, 06:30:05 PM

Title: Truck RPM
Post by: hakcenter on August 28, 2016, 06:30:05 PM
So I've finally hooked up the spare pin to my trucks hall sensor.

It works for the most part, I feel like I'm getting a ton of false positives so I may use a LM311 comparator circuit to see if it can't be cleaned up for the most part. But it is definitely a 5v output.

For those with as 98+ truck, the sensor output goes to pin 8 on the black connector at the PCM.

Also when using int0, make sure to disable the interrupt during FreqMeasure.available(), otherwise all sorts of wonky stuff starts to happen.

I'm going to try to compute it during the keep_time Timer, but for now it is in the main loop counting up to 5 hits, which would be 5 revs @ 800rpm in 400ms. The math is pretty close with the interrupt counting.. but there does seem to be more triggers than there should be.
Title: Re: Truck RPM
Post by: hakcenter on August 30, 2016, 04:33:40 PM
Ha maybe I should of looked at the crank hub, it has 2 notches.. LOL so ya its reading double :)
Title: Re: Truck RPM
Post by: Rx7man on August 31, 2016, 12:44:46 AM
haha, yep, it sends a 4 cylinder style tach signal (2 per rev).  I'm still quite certain there's a wire in the loom somewhere there you could connect to that gives you a cleaned up signal that goes to the tach

I think you'll find it useful if you couple it with a TPS sensor
Title: Re: Truck RPM
Post by: hakcenter on August 31, 2016, 10:32:05 PM
Don't need a 'clean' signal, the hall sensor is a digital out, it just plainly works. I'm catching all the falling in an interrupt, and computing rpm every 100ms.

Thing is rock solid.

Finally got bluetooth working with my linux laptop, using rfcomm. Pretty snazzy not needing cables anymore. Got a bit more work to do with the android app, just rudimentary bugs, like not having bluetooth on, then trying to connect, need to close out the app etc lol.. I'll get that fixed up when I get time at my desk.

Lastly going to add a spare value into the mix, that way you can see it on the app, regardless if the spare pin is used for counting or output / input.
Title: Re: Truck RPM
Post by: hakcenter on November 17, 2016, 11:16:19 AM
So I wanted to update this thread and wrap it up.

I'm using
Code: [Select]
  //---- Spare Pin Interrupt ----//
  if (timer % 250 == 0 && startup < 2 && spare_count_1 > 0) {
    // Spare Counting Fast
    spare_rpm_1[spare_counter_1] = spare_count_1 * 125;
    spare_count_1 = 0;
    spare_value_fast = (spare_rpm_1[0] + spare_rpm_1[1] + spare_rpm_1[2] + spare_rpm_1[3]) / 4.0f;
    if (spare_counter_1 == 5) { spare_counter_1 = 0; }
    if (spare_value < 1500) {
      spare_value = (spare_value_fast + spare_value_slow) / 2.0f;
    } else {
      spare_value = spare_value_fast;
  if (timer % 1000 == 0 && startup < 2 && spare_count_2 > 0) {
    // Spare Counting Slow
    spare_rpm_2[spare_counter_2] = spare_count_2 * 25;
    spare_count_2 = 0;
    spare_value_slow = (spare_rpm_2[0] + spare_rpm_2[1]) / 2.0f;
    if (spare_counter_2 == 3) { spare_counter_2 = 0; }

And basically what happens is there are 2 ints being updated in the interrupt at the same rate they come in at, but one is counted every 250ms the other is counted every 1000ms / 1second.

The fast one, has a rolling average of the last 4 values, ie an average of 4 @ 250ms = 1 second
The slow one, has a rolling average of the last 2 values, ie an average of 2 @ 1000ms = 2 seconds

Then the spare_rpm is counted by averaging the 2 second average against the current fast updating average. You wouldn't think that this would be necessary, but even 250 @ 4 averaging rolls around quite fast and you can get a lot of ups and downs, since our crank hubs only have 2 triggers, and low rpms means very few interrupts.

So averaging over a longer time, really helps keep the value stable, but you do want it to update at a decent rate, so averaging between them makes a very stable, not too slow, rpm count.