I use the pot only to get things started, I dont use pot to determine our ideal. We want the O2 sensor to determine this and drive the mixture to around 14.7:1. Once in auto mode the pot input should no longer be used or am I missing something.
The reason I have the code to set at the pot when we switch over, is because if we dont the servo will go to 0* before starting the loop and kill the engine when we switch over. Once we switch to auto mode, the controller will drive the system to our set parameters. Even if I set the manual at say 12:1 the controller will then drive the system to around 15:1 when we switch over.
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.
Now that I have figured out your code it is pretty cool, once we debug this it will be a cool option for the tutorial I did. 
It is really meant to complement your tutorial. Hopefully it is easy enough people can be successful with it.
1 Like
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
1 Like
Is there a max rpm? Will it handle like 4500 rpm? Is there an advantage over this system vs a small board PC like Odroid C1?
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.
1 Like
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ām confident an Arduino or any SBC will accomplish your entire list of activities with ease.
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.
1 Like
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.
1 Like
Any updates on how well this mixture control has worked out in practice over the past few months?
Anybody trying this on a KG?
Iāve done tutorial on how to build one with a wide band O2 sensor. The code has been updated since, but it very polished and works quite well now.
3 Likes
Where is the code written?
Btw fine job chum.
1 Like
1 Like
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.
Far out question time:
Maybe a single station controller is the answer and leave the arduino out of it.
http://www.ebay.com/itm/Red-Lion-T-48-Series-Temperature-Controller-T481100-85-250-VAC-/111908276686?hash=item1a0e40c9ce:g:WdQAAOSwKtlWr4xY