[Rx7man]

For the current scope of this project, the VGT control, and the next 'add-on', we know we're going to need a CAN bus shield, and possibly a stepper driver if we do an AFC delete.. would the Uno be capable of this?


So far for inputs I'm looking at
Crank sensor
EGT
MAP
EGP
TPS
(I'd love to find a way to put a TPS sensor on the fuel rack too)
Coolant temp
Intake air temp
Turbo outlet temp (optional)
Turbine speed (through CAN bus?)

I'll try it with the Uno first, and if I have issues I got the Mega 2560 as well.. Would be nice if the 2560 had a bit a higher clock speed, but considering the Holley Commander 950 is only 4mhz we should be able to pull this off


The Due seems to have an impressive clock speed, but the 3.3V inputs would be a limiting factor in automotive applications, and for designing boards too.

[hakcenter]

Ya I really don't know what they were thinking with the 3.3v Due, that just sucks the big one IMHO.


You can check the Wiki here, v1_0 [Lil' Blackbox]

I'm working on a newer layout, 1.1, that'll have the pullup for the VR ic, and moving a bunch of traces, and adding cap filters to some of the chips just because.

CANBus is already working on my board, it doesn't really take up anymore space, I could put it on the 2nd layer if space is needed but the v1.1 layout has a ton of spare space.

I'm not sure how to have shaft speed && rpm on the same board. You might be able to use FreqCount and Measure at the same time ?? No idea there, otherwise maybe some kind of triggering multiplexing unit we're in control of to measure shaft speed, then measure rpm, etc.

Shaft speed is through the VR sensor on the turbo, its a separate plug, you may not have known. I count it with FreqMeasure on Pin 8, FreqCount library only goes by 1second intervals sucks, not safe to use.

EGT/MAP etc can all be 5v inputs on the ADCs

[Rx7man]

I think the Mega has several interrupt triggered input pins if I'm not mistaken, though at 140,000x per minute you better have efficient code if you don't want to mess everything else up... Perhaps a there's a pulse counter/divider chip that we could divide the pulses by 100 which would make it much more reasonable...

How do these VR sensors work?  Is it kinda like a Hall Effect in the sense it provides an approximate square wave?

[hakcenter]

There's a magnet (which is what the VR ic interfaces) and then a cutout on the shaft. Like how ABS brakes work.

Mega only shows pin 49 for FreqMeasure, so not sure on that.


Maybe it is possible to adjust the library or make another one, that uses the other interrupt change pins, and count those. However the canbus chip connects via pins 10-13

[Rx7man]

well, 140000 RPM = 2.5kHz, which really isn't much for electronics, but if you're approaching the capacity of your processor, it may be best to move it... I'm sure there's a binary counter that we could adapt.. even if it's just divided by a power of 2 (8 bit sounds good for 256), and the logic would be dead simple, just tie the output pin for 8th bit to the input of the arduino  with a rising interrupt and you have the divider..  2.56 kHz becomes 10hz, and we can easily deal with that frequent an interruption ... I'm going to look for an IC that'll do it.. they're probably dirt cheap..

This looks like a good start TC74HC4040AP Datasheet(PDF) - Toshiba Semiconductor, and with a couple supporting IC's I think I could make it run without an interrupt capable pin.. an AND gate to control the reset, and an R/S latch to hold the value between reads while the counter continues.. the program would check on every crank pulse to see if the input is high, then trigger a pin to the latch to reset.. I think we could have reasonable resolution with it, but would require 3 IC's since I don't think there are any that do it all in one.. I'll have to think about it longer though.


As for the Due, I think all the high speed chips are predominantly 3V, so it was more of a constraint placed by chip manufacturers than a desired spec from the Arduino designers

[hakcenter]

I haven't had any issues counting up to 2.5khz while still maintaining my 1ms timer, I guess I could run some milis checks to verify timing.

Using FreqMeasure the code isn't on an interrupt, it just counts the rising edge into the icp1, and includes overflows of the 16bit timer gets full ? Never really read into it.

I put my FreqMeasure in the main loop only, count the frequency and average the last 4 measurements. Also update the two timers.

You might want to look into pulseln, for checking other pins input frequencies.

[Rx7man]

I didn't think of PulseIn(),.. here's what the manual says about it
pulseIn()
Description

Reads a pulse (either HIGH or LOW) on a pin. For example, if value is HIGH, pulseIn() waits for the pin to go HIGH, starts timing, then waits for the pin to go LOW and stops timing. Returns the length of the pulse in microseconds. Gives up and returns 0 if no pulse starts within a specified time out.

The timing of this function has been determined empirically and will probably show errors in longer pulses. Works on pulses from 10 microseconds to 3 minutes in length.
Syntax

pulseIn(pin, value)
pulseIn(pin, value, timeout)


it sounds like it waits (probably with a millis timer), which hangs up the rest of the code I'd assume.

I didn't sleep that well last night, brain working, and I came up with this.. only using that toshiba binary counter.
If you put the Bit 7 (/256) output into an input pin, it would stay on for a long time, giving you time to check for it in the crank angle sensor interrupt.. an output would be sent after it's read to reset it... the only problem is it would be slightly inaccurate because of the delay from the time the pin is turned on to the time the arduino sees it and resets it... might not be a big deal though

[Rx7man]

What version of the CAN bus does the VGT need? I see CAN 2.0, and ECAN?

I'm looking at the PIC18F family of microcontrollers from Microchip, and I think I could offload enough stuff onto that chip to be able to still use an UNO board... The PIC18F have built in CAN bus, as well as IO's etc in a DIP package.

How does it work to have one controller 'talk' to the other?  Over I2C? SPI?  How does one controller send data to the other, I'm talking is it a PITA to interface it programatically?


Also, I found a better solution to reading the turbine shaft speed input.. still with a binary counter, but if you take bit 7 for example, you don't need to reset it... in the program code you just have a static boolean value, if the value is the same, you do nothing, if it's different, then you count it as an 'increment'... you will always have a 50% duty cycle off a single pin of the binary counter, which make it work perfect... I'm actually thinking of using this idea (with less bits) for the engine speed, and perhaps even a vehicle speed sensor. 

[hakcenter]

pulseln stuff:

Code: [Select]

// period of pulse accumulation and serial output, milliseconds
#define MainPeriod 100
long previousMillis = 0; // will store last time of the cycle end
volatile unsigned long duration=0; // accumulates pulse width
volatile unsigned int pulsecount=0;
volatile unsigned long previousMicros=0;

void setup()
{
  Serial.begin(19200);
  attachInterrupt(0, myinthandler, RISING);
}

void loop()
{
  unsigned long currentMillis = millis();
  if (currentMillis - previousMillis >= MainPeriod)
  {
    previousMillis = currentMillis;   
    // need to bufferize to avoid glitches
    unsigned long _duration = duration;
    unsigned long _pulsecount = pulsecount;
    duration = 0; // clear counters
    pulsecount = 0;
    float Freq = 1e6 / float(_duration);
    Freq *= _pulsecount; // calculate F
    // output time and frequency data to RS232
    Serial.print(currentMillis);
    Serial.print(" "); // separator!
    Serial.print(Freq);
    Serial.print(" ");
    Serial.print(_pulsecount);
    Serial.print(" ");
    Serial.println(_duration);
  }
}

void myinthandler() // interrupt handler
{
  unsigned long currentMicros = micros();
  duration += currentMicros - previousMicros;
  previousMicros = currentMicros;
  pulsecount++;
}
Precise frequency measurements with Arduino microcontroller

If you want, maybe tomorrow I can run get the laptop and add a milis to my arduino, to verify speed and timing, and ass-haulingness

I don't know if it is wise to add another microprocessor on there, unless you plan to program it off PCB and land it back on ?

[Rx7man]

OK, I'll have to look at that a little harder and see if it'll work.. I downloaded a whack more datasheets, and a new digikey catalog, mine was getting old.

What kind of wave output does the VR sensor give?  does it need much preconditioning outside of perhaps a couple resistors and a clamp diode before being fed to an input?  We could probably even read it with an analog input if we didn't care about accuracy too much... it may be an option, though 10 bit resolution leaves a little to be desired.


I'll try and get a list for my Digikey order for you to look over and see if I'm missing anything evident.. I can probably recycle some stuff like small caps, etc from dead stereos..
Some stuff like the binary counters, and/nad/xor gates, op-amps, NPN transistors 5v zeners, and all the basics I'll just get a bunch of so I'm set for a while
What chip are you using for the CAN bus and I'll add that to the list

[Rx7man]

Speaking of analog frequency counters...
Check this out.. specificaly for VR sensors, I think that would be the best way to read the turbine shaft speed for now at least... just need an analog input.. RPM accuracy with 10 bits would be +-150 RPM, but seriously if it's +-1000 (there's other inaccuracies) it'll be close enough to do what I need it to.

www.ti.com/lit/ds/symlink/lm2907-n.pdf

Best part of it is it doesn't take many CPU cycles to figure it out, and you could have the identical circuit with a different scaling factor for RPM as well..  the decoding would just be analoginput*scalefactor = RPM, and it could be read at any time, it'll be spike-free since it's analog, which naturally incorporates averaging, and doesn't need interrupts (you said you really like to save that one pin with an interrupt didn't you?)

There's always more than one way to skin a cat, and looking at all the options (maybe trying them all?) is good.

Benefit to the binary counter method? very high accuracy at high RPM's, but had a long delay at low RPM, doesn't take too may CPU cycles and doesn't need an interrupt though, but must poll the pin at at least double the rate of your peak input frequency... Only requires one CHEAP chip ($.58) and one digital input pin

Benefit to the LM2907 analog?  Can read the voltage any time you want the RPM, requires virtually no CPU time, easy to scale, does require an analog input (we're going to be needing a LOT of those, maybe more than are available), Suffers from poor accuracy with 1024 bits + LM2907 non-linearity.

[hakcenter]

Ya no good if its not linear, requires math on top of the problematic multiplexed ADCs on the Arduino. You usually loose 1-2ms on ADC reads on the arduino, because you have to read them twice. Once usually reads the last pin depending on spe ed of your code, so you have to read it twice and wait for the gate switch overs.

Good idea though... I would use it for non-essentials, like RPM, and update every 10ms maybe even as slow as 25ms

I'm using an MCP2551 and MCP2515

[Rx7man]

Exactly, RPM being off by a bit wouldn't hurt much, except perhaps at idle if it's too far off.. the the turbine shaft speed I think it would be perfectly suitable though and really help the simplicity.. ditto for the vehicle speed sensor input if we use one

[hakcenter]

Problem is VR sensors are not Hall, and increase voltage and noise.



I wouldn't count the shaft speed with anything less than a dedicated IC. I use the max9924 to do all the dirty work and output a nice and safe 5v frequency pwm

[Rx7man]

I think a dedicated IC for the turbine shaft speed is good, I think our trucks already have a hall effect sensor for engine RPM so less preconditioning will need to be used with it, and since it's only going to be ~200 hz peak, it's not going to be hard to deal with... I'll look up that max9924.

Which of the MCP2551 or 2515 do you prefer?  Datasheet doesn't say what input mode it uses.. they say a differential, so it makes it sound like RS485.. the 16 pin I think says it uses SPI