Fun with timings « LeafLabs Garden

LeafLabs Garden » Support » Maple Hardware Support

Fun with timings

(49 posts) (7 voices)

Started 5 years ago by Feyr
Latest reply from Silntknight

« Previous 1 234 Next »

Silntknight
Moderator
So here's the basic idea: http://s1221.photobucket.com/albums/dd470/Hari_Ganti/?action=view&current=EngineFlow.jpg
```
void setup() {
  Timer3.setPeriod(36000000);
  Timer3.setChannel2Mode(TIMER_OUTPUTCOMPARE);
  Timer3.attachCompare2Interrupt(spark);
  attachInterrupt(0, pulse, FALLING);
  pinMode(11, PWM);
}

void loop() {
  pwmWrite(11, pulseDelay); //pulseDelay has to be modified...
  //Why can't pwmWrite support microseconds...
  Timer3.setCompare2(sparkDelay); //Again, needs modifications...
}

void pulse() {
  Timer3.setCount(0);
}

void spark() {
  digitalWrite(12, HIGH);
  delayMicroseconds(3); //Not sure if this is necessary
  digitalWrite(12, LOW);
}
```
I'm pretty sure 36,000,000 microseconds is a valid period (considering the max is 1 minute). If not, let me know. My idea is that there are an integer number of cycles/count. This way, the PWM counter increments at the same rate regardless of when the counter resets. This makes later calculations (like the PWM value for pulseDelay and the counter value for spark) much easier because the count is constant.

It's like this: |---|--|----|----|---|---|--|-|-| and so on. The dash represents one count and a line represents a count reset. It'd be hard to draw what this is compared to, so I'll describe it. The other system has the period vary so that there is the same number of dashes between the lines, but not all dashes are equal valued. The second way makes calculations later much harder, and is much more math intensive (as if this project isn't!) That being said, my method, the first one, might not work. What do you all think? Meanwhile, I am going to recalculate the pulseDelay and spark compare-to values.

EDIT: A good way to compare the two systems is to imaging a an exchange of money between two people. If one owes another a dollar, that "space" could be filled with 100 pennies (many of equal values), or 1 dollar bill (same of unequal values). The next time the first guy owes the other money, assuming the same two systems, if he owes 50 cents then the break-down would be either 50 pennies (equal value to the pennies before, but a different quantity) or 1 half-dollar (inequal value to the dollar bill, but the same quantity of material exchanged- one unit). Hope that helps future readers.
Posted 5 years ago #
Silntknight
Moderator
Well Gbulmer, I think I have a finalized code:
```
#define PERIOD 36000000

void setup() {
  Timer3.setPeriod(PERIOD);
  Timer3.setChannel2Mode(TIMER_OUTPUTCOMPARE);
  Timer3.attachCompare2Interrupt(spark);
  attachInterrupt(0, pulse, FALLING);
  pinMode(11, PWM);
}

void loop() {
  pulseDelay = (pulseDelay*65535)/PERIOD;
  pwmWrite(11, pulseDelay);
  sparkDelay = (sparkDelay*65535)/PERIOD;
  Timer3.setCompare2(sparkDelay);
}

void pulse() {
  Timer3.setCount(0);
}

void spark() {
  digitalWrite(12, HIGH);
  delayMicroseconds(3); //Not sure if this is necessary
  digitalWrite(12, LOW);
}
```
Of course, this is just the (former) powerStroke code rewritten, but I will incorporate it into the main code if this turns out to be fine. Thinking about it some more, all I really need is for the period to be longer than the maximum period of the engine. In that case, I should just choose a the smallest multiple of 65535 that satisfies that criterion. That way I can just divide by the multiple number (2, 3, 4...) and save one instruction. It'd make the code a little simpler. Also, I hope my flow diagram helped.
Posted 5 years ago #
gbulmer
Moderator

Silntknight - the sequence diagram is great! I can see how it is intended to fit together, and there are more parts than I had understood, so that helps me. I find those sorts of diagrams help me keep track of the overall system structure. I hope it wasn't too tedious to create.

I must apologise but I am busy today (running an Arduino workshop for undergrads), but I'll try to think a bit more tonight.

It seems like the structure of the problem and the solution are becoming aligned, which is often a good sign.

A small idea which I have not thought through, but maybe its possible to set the repetition rate for pwm and timer to match a reasonable engine idle speed?

Take care GB-)

Posted 5 years ago #
Silntknight
Moderator

I hope it wasn't too tedious to create.

No, it was somewhat fun. I enjoy using MS Paint whenever possible and avoiding the use of paper (real paper, e-paper is fine). In fact, this may have helped me clearly see the layout, even though I understood it before. Also, the LCD component is largely speculative at this point, thus the ??? for pin. I am thinking about using a serial backpack to have an easier interface.

Anyway, please take your time to respond. I appreciate well-thought answers, like all of your so far, and the project doesn't need to be finished for 2-3 more months. I definitely gave myself time to work out all the bugs I could before testing it.

The only problem I might have is the Timer3.setCount(0); part. I question this because the Timers article says, "You can probably make it not work if you try!" I am mildly confused by this, but it does concern me nonetheless. Also, a pulse is triggered each time the counter is at zero, correct? This is important because if the PWM still follows the period, even if the counter is resetting, then my code won't work.

A small idea which I have not thought through, but maybe its possible to set the repetition rate for pwm and timer to match a reasonable engine idle speed?

I did think about something like this. I didn't think it all the way through though. My qualms with it are just that it is unnecessary and could create problems if the engine dips to lower speeds (longer periods) than what I set. I think setting the period to a multiple of 65535 would be best just from a speed standpoint. As long as the clock accepts that period (so setting it close to a prescaler multiple of the clock), it makes the math simpler and keeps the code efficient. Just a thought. Anyone know any good multiples of 65535 that are also multiples of the clock?

EDIT: After some rather tedious math, I determined that a period of 6553500us is the optimal period. It is ~6.5 seconds, so long enough, but is both a multiple of 65535 (if you didn't already see that) and is close to a factor of 72,000,000 which is the clock speed. In fact, there are 10.99 cycles per count, so very close to 11. This then simplifies the math that I have to do because instead of pulseDelay = (65535*pulseDelay)/100; which is the duty cycle for the fuel injector PWM, I can just modify the original code. Both sparkDelay and pulseDelay are multiplied by 1000 to get to microseconds, so I just multiply by 10 instead and it is calibrated! I'm going to double check my math to make sure of this, but then I'm going to go ahead and update my main code.

Posted 5 years ago #

Silntknight
Moderator

I think it's done:

/*ECU/EFI for Maple V1.0
*Copyright (c) 2010 Hari Ganti
*More stuff will go here later...
*/

//Pins in use: 15- pot, 17- pressure, 19- temp, 2- interrupt, 3- kill, 11- injector, 12- spark, 14- servo

volatile int delta_t; //Period of the engine

int corr = 0; //Correction factor for spark timing based on rpm (or fuel pulse grams or both...)
int a; //Servo PWM
int p; //Manifold Absolute Pressure
int t; //Manifold Air Temp
int pulseDelay; //Pulse length time (in microseconds)
int sparkDelay; //Delay after injector fires (in microseconds)
int tach = 0; //Tachometer

void setup() {
  pinMode(15, INPUT_ANALOG);
  pinMode(17, INPUT_ANALOG);
  pinMode(19, INPUT_ANALOG);
  pinMode(2, INPUT_PULLDOWN);
  pinMode(3, INPUT_PULLUP);
  pinMode(11, PWM);
  pinMode(14, PWM);
  pinMode(12, OUTPUT);
  Timer4.setPeriod(20000); //20ms
  Timer3.setPeriod(6553500); //6.5535 sec, 65535 counts/cycle, 10986496 clocks/cycle
  Timer3.setChannel2Mode(TIMER_OUTPUTCOMPARE);
  Timer3.attachCompare2Interrupt(spark);
  attachInterrupt(0, pulse, FALLING); //Trigger void pulse when sensor is deactivated (digital pin 2)
}

void loop() { //The fun stuff goes on here
  if (digitalRead(3) == LOW) {
    a = (analogRead(15)*2949)/4096+1966; //Servo PWM duty cycle
    pwmWrite(14, a); //Servo control from 0 to 90
    p = ((analogRead(17)-164)*230)/3850+20; //MAP actual (kPa)
    t = (analogRead(19)*500)/4096; //MAT actual (K)
    pulseDelay = 10*(((.79*2*14.01+.21*2*16)*7920*.148*.6)/(.0821*14.9*101.325*20))*(MAP/MAT); //Stoichiometry
    pwmWrite(11, pulseDelay);
    delta_t = delta_t/2;
    sparkDelay = (7.79*delta_t)/360; //Delay before spark fires
    Timer3.setCompare2(sparkDelay);
    tach = 60000000/delta_t;
  } else {
    delayMicroseconds(5);
    if (digitalRead(3) == LOW) {
      delay(1000);
    }
  }
}

void pulse() { //Synchronize the PWM for the fuel injector
  delta_t = Timer3.getCount(); //Get twice the period in microseconds
  Timer3.setCount(0); //Reset the timer
}

void spark() { //Ignite the spark plug
  digitalWrite(12, HIGH);
  delayMicroseconds(3); //Check if it's necessary
  digitalWrite(12, LOW)
}

I just need to know if Timer3.getCount(); returns microseconds or what. As Poslathian suggested on another thread (http://forums.leaflabs.com/topic.php?id=262), I added a debounce to the kill switch. I'm not sure how to do that for the valve position sensor because it is run on an interrupt and VERY time sensitive. I might just have to get a really good switch with high electrical isolation (thinking solid state relay).

Posted 5 years ago #

gbulmer
Moderator

Quick one - on my way to land of nod

Wow! Looking good.

What is the valve position sensor currently? Is it mechanical? I would have imagined Hall effect just for robustness, in which case, it make not need anything doing to the signal.

Side note. You could program the spark handler just to start another timer which delivers the right duration of spark pulse.

Posted 5 years ago #
Silntknight
Moderator

What is the valve position sensor currently?

It is mechanical. I was going to use a simple switch. I am going to modify the engine to use rocker arms with pushrods instead of its current system. As the rocker arm moves, it will also depress the switch. A Hall wouldn't really work (see the other thread about that).

You could program the spark handler just to start another timer which delivers the right duration of spark pulse.

What exactly do you mean? The spark's duration shouldn't change all too much. I just need to test it to see if not having a delay causes problems later down the line. What's funny is that this controls a solid state relay, which controls an ignition coil, which controls the spark. As far as the spark duration goes, I would be fine with adding a separate timer for that, provided it didn't make the interrupt last longer. Later, I'll be running this on the engine with a diagnostic version of the code so that I can manually adjust things like injector pulse length, spark delay, and spark pulse length.
Now that I think about it more, I will definitely add an LCD to the setup. If a computer isn't present, I can use it to debug the code.

Posted 5 years ago #
Silntknight
Moderator

I'm starting to get the terrible feeling that there are no button switches that have high electrical isolation. To make things worse, the only switch I saw that had a datasheet was rated for no more than 200 throws/min. I'm going to be revving the engine up to 4000 rpm... Anyone have ideas? I am starting to consider attaching a Hall to the crankshaft, though adding a magnet and calibrating it will be terrible.

Posted 5 years ago #
poslathian
LeafLabs

This may have been said before, but heres an idea for an overall design:

1) use whatever mechanism you like to measure the frequency of your engine, you can use a hall sensor with a gain stage so that you get a nice pulse at the same point in the stroke, or you can use some other mechanical trick, like a beam break sensor...anything that will give you a pulse once per stroke at the same point in the cycle. You can even put multiple of these sensors in such a way that they trigger in sequence during a single stroke (such as a beam break sensor with 8 fins on your output shaft, so youll get 8 ticks per turn). This way you can update your estimate of your engine period more than once per cycle. You can take this to the limit and build what is effectively and encoder.

2) attach this pulse input to an external interrupt. At each pulse, update your estimate of the motor period and get out of the ISR (interrupt)!

3) setup a single timer, with a total period of your engine stroke period. You can change this period throughout the program in 2

4) setup multiple outputcompare interrupt channels on this single timer. I think you can get up to 4. Set each channel compareval to go off at the right time in the stroke. You can adjust these with your motor period, or not depending on how you set things up.

5) each output compare fires a different interrupt to do whatever, fire your relays and such.

Posted 5 years ago #
gbulmer
Moderator

I'm starting to get the terrible feeling that there are no button switches that have high electrical isolation. To make things worse, the only switch I saw that had a datasheet was rated for no more than 200 throws/min. I'm going to be revving the engine up to 4000 rpm... Anyone have ideas? I am starting to consider attaching a Hall to the crankshaft, though adding a magnet and calibrating it will be terrible.

Use a Hall switch. They are fast (1.5uS switch time), and quite robust as there are no physical switch contacts.

Maybe you can attach the magnet to some part of the crankshaft to make calibration easier.

Posted 5 years ago #
Silntknight
Moderator

Poslathian, that seems like an incredibly robust system. The problem is that I am a high schooler working in a woodshop with relatively few metalworking tools, let alone anything to get a nicely set up system like that. I never said this before, so I understand the assumption that I would be able to do that. That's just for the idea about multiple sensor breaks. The code aspect is possible, but the engine speed doesn't change appreciably between intake valve openings, especially above 1200 rpm. I might use your idea about basing the period on the actual period. It might add a little math, but it would, hopefully, make the code run more reliably. What do you think? If I adjust the period, it makes the math run slower because I add another instruction (divide) to each step that requires timer calculations. The rest is very close to what I have (as I understand it), so it's good to see that you agree! Quick question, I am pretty sure that if I initialize a variable and assign a value before the setup, it only does that once, so it can be changed in the loop and will not revert to the original value. Am I right?

Gbulmer, to be honest, I hate the idea of a Hall on the crankshaft just because it has such a small diameter that I might get false reads, but I'll check that out on my own. Much as I hate it, I think that is what I am going to do. I'll just weld a small magnet to the crank (and hope the heat from welding doesn't affect the magnetic properties!) I'm sure I can come up with a mount that keeps both parts vibrating the same amount so that it is steady in the crankcase.

Poslathian and Gbulmer, what are your takes on reed switch vs. Hall sensors? The former is less expensive and I can get something like twenty and just play around with them for the same cost as a Hall.

I realized that Timer3.getCount() returns a uint16, not the actual microseconds since the last pulse. I am going to modify the code with the parts I stated in this post. Thanks, both of you.

EDIT: I'm actually not going to have the period for the PWM be based on the real engine period. It makes the code way to complicated, at least for me. I'm not too sure of how much of a benefit it will have either.

Posted 5 years ago #

Silntknight
Moderator

I thought I could edit past posts, but I guess I can only do so relatively quickly after the latest one. Anyway, here is my new code. I had intended to just edit the one in which I posted it before:

/*
*ECU/EFI for Maple V1.0
*Copyright (c) 2010 Hari Ganti
*More stuff will go here later...
*/

//Pins in use: 15- pot, 17- pressure, 19- temp, 2- pulse, 3- corr_deg, 4- corr_injector, 5- corr_PWM, 8- corr_state, 9- kill, 11- injector, 12- spark, 14- servo

volatile int delta_t; //Period of the engine

int corr_deg = 0; //Correction factor for spark timing- calibrated in degrees
int corr_injector = 0; //Correction factor for injection length- calibrated in counts (100us)
int corr_PWM = 0; //Correction factor for spark length- calibrated in microseconds
int a; //Servo PWM
int p; //Manifold Absolute Pressure
int t; //Manifold Air Temp
int pulseDelay; //Pulse length time (in microseconds)
int sparkDelay; //Delay after injector fires (in microseconds)
int tach; //Tachometer

void setup() {
  pinMode(15, INPUT_ANALOG);
  pinMode(17, INPUT_ANALOG);
  pinMode(19, INPUT_ANALOG);
  pinMode(2, INPUT_PULLDOWN);
  pinMode(3, INPUT_PULLDOWN);
  pinMode(4, INPUT_PULLDOWN);
  pinMode(5, INPUT_PULLDOWN);
  pinMode(8, INPUT_PULLDOWN);
  pinMode(9, INPUT_PULLDOWN);
  pinMode(11, PWM);
  pinMode(14, PWM);
  pinMode(12, OUTPUT);
  Timer4.setPeriod(20000); //20ms
  Timer3.setPeriod(period); //6.5535 sec, 65535 counts/cycle, 10986496 clocks/cycle
  Timer3.setChannel2Mode(TIMER_OUTPUTCOMPARE);
  Timer3.attachCompare2Interrupt(spark);
  attachInterrupt(0, pulse, RISING); //Trigger void pulse when sensor is deactivated (digital pin 2)- can be changed if needed
  attachInterrupt(1, corrDeg, RISING); //Trigger void corrDeg when button is pushed
  attachInterrupt(5, corrInjector, RISING); //Trigger void corrInjector when button is pushed
  attachInterrupt(6, corrPWM, RISING); //Trigger void corrPWM when button is pushed
}

void loop() { //The fun stuff goes on here
  if (digitalRead(9) == LOW) {
    a = (analogRead(15)*2949)/4096+1966; //Servo PWM duty cycle
    pwmWrite(14, a); //Servo control from 0 to 90
    //
    p = ((analogRead(17)-164)*230)/3850+20; //MAP actual (kPa)
    //
    t = (analogRead(19)*500)/4096; //MAT actual (K)
    //
    pulseDelay = ((100*2029712256)/2478997185)*(p/t); //Injector delay length
    //pulseDelay = (818763437/10000000)*(p/t); //Simplified, less accurate- compare graphs later
    pulseDelay = pulseDelay + corr_injector;
    pwmWrite(11, pulseDelay);
    //
    delta_t = delta_t/2;
    //
    sparkDelay = ((77+corr_deg)*delta_t)/36000; //Delay before spark fires
    Timer3.setCompare2(sparkDelay);
    //
    tach = 60000000/delta_t;
  } else {
    delayMicroseconds(5);
    if (digitalRead(9) == LOW) {
      delay(1000);
    }
  }
}

void pulse() { //Synchronize the PWM for the fuel injector
  delta_t = Timer3.getCount(); //Get twice the period in microseconds
  Timer3.setCount(0+corr_PWM); //Reset the timer
}

void spark() { //Ignite the spark plug
  digitalWrite(12, HIGH);
  delayMicroseconds(3); //Check if it's necessary
  digitalWrite(12, LOW)
}

void corrDeg() { //Diagnostic spark timing utility
  delayMicroseconds(5);
  if (digitalRead(3) == HIGH) {
    if (digitalRead(8) == HIGH) {
      corr_deg++;
    } else {
      core_deg--;
    }
  }
}

void corrInjector() { //Diagnostic injector length utility
  delayMicroseconds(5);
  if (digitalRead(4) == HIGH) {
    if (digitalRead(8) == HIGH) {
      corr_injector++;
    } else {
      corr_injector--;
    }
  }
}

void corrPWM() { //Diagnostic PWM phase utility
  delayMicroseconds(5);
  if (digitalRead(5) == HIGH) {
    if (digitalRead(8) == HIGH) {
      corr_PWM++;
    } else {
      corr_PWM--;
    }
  }
}

Posted 5 years ago #

gbulmer
Moderator

A quick comment (off to work)

The code is looking good. Have you got an approach to testing it? Are you testing this on an ordinary computer to see how it works?

what are your takes on reed switch vs. Hall sensors? The former is less expensive and I can get something like twenty and just play around with them for the same cost as a Hall.

I am definitely not an expert on these things. I know that an awful lot of telephone systems used reed switches, so they are very reliable under normal "office" conditions. I am concerned that the vibration and heat combined might stress them. If this is a school project, where the engine only runs for short periods, you might be okay.

I know that Hall sensors are used a lot in the auto industry, but now that I think about it, I am not sure they are put inside the crankcase of an engine. What sort of temperature does that reach? Clearly cooler than boiling oil :-)

I think I'd avoid welding a magnet to the crankshaft.
Is the flywheel running at the same speed as the engine?

Maybe Mr Google can help with some of the questions? I can ask questions, but I feel out of my comfort zone.

Posted 5 years ago #
Silntknight
Moderator

If you can tell me how I can test this on a computer, I'd love to hear it. Otherwise, I am working on getting a Maple right now (school-sponsored project = delays).

I am getting both anyway. I found a Hall for about a dollar and my reed switch was the same, so it doesn't matter to me which is better because I am getting both.

I am not sure they are put inside the crankcase of an engine.

This is very true, and I am aware that very little is actually in the crankcase. Still, the temperatures really aren't that high. Most of the heat is contained in the cylinder (or so we hope).

I think I'd avoid welding a magnet to the crankshaft.
Is the flywheel running at the same speed as the engine?

I think it would be fine to weld to these, though I meant camshaft when I said crankshaft. And yes, the flywheel is directly connected to the crankshaft so it spins at the same speed. It also has a magnet on it, for the magneto. Like I said (elsewhere maybe), the crank and the engine turn at twice the rate I need them to, and I can't be sure of what cycle the engine is on. I was thinking that I could use some clever gearing and attach sprockets to the flywheel and have those sprockets turn at half the speed. Probably a better idea, the sprockets could be attached to the crankshaft so that the gears can be smaller. Then the Hall/reed can be externally mounted and everything operates at the right time.

Posted 5 years ago #
Silntknight
Moderator

I have another idea... This one is much more abstract, though there is a precedent for this (http://me.engin.umich.edu/autolab/Publications/Adobe/P1998_02.PDF). I am currently using a throttle plate (like just about every engine) to control the amount of air entering the cylinder. Assuming I can do the math right (not hard if I really sit down and do it), I could try another method of throttling that solves all the problems we have so far. Unfortunately, it adds a few dozen more; though, to be fair, they are more math oriented problems so I'd rather deal with them anyway. I am thinking about doing away with the camshaft altogether. Instead, I will use solenoids with return springs to control the valves. I wanted to make it overhead valves (OHV) from L-Head anyway, this makes it even easier, I guess. The idea is then that instead of using a throttle plate, which causes losses in energy from throttling, I just adjust the time that the intake valve is open. I had already decided to implement a Miller Cycle conversion (http://www.howstuffworks.com/question132.htm). Originally, I was going to modify the camshaft lobes to change how long the valve is open for. Now, I can just adjust that at will. I get the feeling that doing this right would do away with every problem from actually modifying camshaft lobes to determining stroke. As far as the latter goes, think of it this way. The engine just moves a piston up and down. If I choose when to open the valves (provided I use a Hall to time it right), then the stroke is always deterministic. I like this solution because it is, theoretically, the simplest. What do you all think? To be honest, I am finally unnerved by this modification just because it is so advanced. Most cars don't even have fully electric valve control.

Posted 5 years ago #

RSS feed for this topic

« Previous 1 234 Next »

Reply »

You must log in to post.