I figured you used the pot to tune it since there is a bit of fuzziness as to what the ideal setting actually should be.
I just updated the code, you can use a hardset value as the ideal now.
In autorun mode moving the pot will change the ideal now without flipping the switch, it takes 30 seconds before it starts back in autorun mode.
I also flipped the reading of the on/off switch around, so the switch isn’t needed if you are just going to use the pot to tune it. however, I think what you are saying is you want it to eliminate the pot.
Yes finding the window of the output of the sensor where we want to run at is roughly 2.5 v on the kit I have now. But the other kits it is different. I kinda like how you have this now with the pot set. I wonder if we could do a EEPROM with a push button instead. So basically the user will just set this where desired and then it is hard set and stored. It wont ever change unless this is reset.
Question, never could find a solid answer, is this microcontroller ok for controlling spark? I thought I read somewhere that it might need a real time clock. Would another system with a real time clock work? Like Odroid C1?
Robert, the Arduino microcontroller is fully capable of controlling spark using interrupts. Here’s a video of KenB and RonO’s successful Lister spark conversion at APL a few years back:enter link description here
75RPS(4500RPM) shouldn’t be an issue, an Arduino can process millions of instructions per second. The only SBC I’m familiar with is the PCduino, and my only comment would be there is much more overhead running in the background on a SBC vs. an Arduino.
Ok. Thanks Billy. A two cylinder four stroke at 4500 rpm would require 75 rps but an 8 cylinder would require 300. Plus if you add fuel injection, for running hybrid and starting, this climbs to 600. Is this pushing it for a single board? I don’t expect to run that high of RPM I’m just trying to find out my limits before spending any money.
I am not so sure… The -real- difference between a microcontroller and a single Board Computer (SBC) is really the scheduler to get to real-time operations. The SBCs can usually do orders of magnitude more processing, however, it is really how the processing is scheduled is what makes a microcontroller tick.
It runs in a lockstep fashion so it is -really- consistant. The SBC has a lazier scheduler, so it isn’t really guaranteed to be consistent to the millisecond or less.
Now if you can find something like FreeRTOS or another real time operating system, that changes the scheduler which then works in a lockstep fashion then you shouldn’t have any issues. But you probably aren’t going to find a free RTOS to run on it. The Odroid uses a Exynos chip, which has very minimal linux support because they sparsley released documentation or patches for the linux kernel.
That being said, it may or may not work without a RTOS. I wouldn’t try it without a rtos on an engine I cared about. FreeRTOS has some support for the RaspberryPi, I don’t know about the pi2. It -should- work for that, but I would see if someone tried it already.
DIYEFI.org is probably where I would look. The use a Freescale MC9S12XDP512 microcontroller.
Instead of getting an Arduino, I would probably get a teensy 3.1 board. You can use the Arduino sketch system, but the teensy appears to be a far superior microcontoller for 20 bucks. it has a 72mhz processor instead of the 16mhz my arduino has, and it has like 4x more ram, storage, etc as well too.
Sean,
Thanks for the clarification on SBC schedulers. My only SBC exposure is to the PCduino, and I’m still getting my feet wet with it. I agree the teensy is a better choice, especially now that breakout boards are available for them which allows easier access to the center pins.
SBCs might actually work. Add the preempt_rt patches to the linux kernel, and that gives you the hard timers you need. With the preempt_RT patches, the interrupt reaction lag is < .25 milliseconds. Without the patches, you can still do a lot of traditional micro controller types of things as most things that use a microcontroller, can lag much more then that. To put it into perspective, 100x more then .25 milliseconds, is 25 milliseconds, or 25/1000ths of a second. So how accurate do you have to be…
Thus the reason why it is a debated topic, and really a gray area.
Woodgas is using natural aspiration, the electronics are greatly simplified over using EFI. The ignition is probably the hardest part. And I should note somewhere in here, because of the magnetic field interference of the engine, everything needs to be shielded.
I just briefly skimmed the code ( forgive me I am not a C programmer ).
From what I gather you set up a pair of upper and lower tolerable limits and then operate in a dead band.
A delay function prevent instability or overshoot undershoot.
My only concern is the DELAY command.
If I am not mistaken this halts the program steps and literally waits.
Did you tinker with this from the arduino library?
PID(&Input, &Output, &Setpoint, Kp, Ki, Kd, Direction)
Other useful pieces of codes I see could be.
SetMode(mode)
SetTunings(Kp, Ki, Kd)
SetControllerDirection()
In particular instead of wait maybe SetSampleTime(SampleTime)
Could speed up things.
Just throwing this stuff out there.
I have never used these commands and I am not familiar enough to say they will speed things up or improve stability.
However I have used somethings like RED LION and Foxboro single station controllers.
With so much processing speed and power maybe its pointless to worry about short wait times.
Yes the delay at the end of the run is just for stability and is just 10 microseconds… The mapped delay however, changes almost instantly.
If it sees the sensor reading less than 650 or greater then 700 it will react. It the reading is in between these parameters than it does nothing.
The delay is mapped to those parameters and you can achieve from 0 on up to 3000 microseconds of delay in the delay function. So if the reading is at say 649 the delay will be almost at the max delay assigned as the readings go closer the zero the amount of delay follows this. So if you have a wide open throttle and it pegs out at 0 volts the servo will not have any delay and will respond at its maximum speed. In this scenario it typically will over shoot and this is fine and is actually desired as it gives it a chance to clear the rich condition created from loading. At this point it is now reading lean but I have the start delay at 800 so it creeps back into to the safe parameters without over shooting.
I may be able to eliminate the void set up code. This was for previous code and I was having an issue with the servo moving during transition from manual mode to automatic. But I think now this may not be an issue Ill have to try it and see what happens.