Arduino Manager Development for All

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. :fire:

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… :slight_smile:

Thus the reason why it is a debated topic, and really a gray area. :slight_smile:

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

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.

No need to fix this code it works.

1 Like

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.

1 Like

Thanks for sharing Matt.

I am in process of deciding how I want to set up my controls and instrumentation.

At this point in life, I am pretty addicted to KISS and fully manual systems.

IMO, proprietary systems and secretive vendors in collusion with politicians (read OBDII etc.) have just about ruined automobiles.

On the other hand, I am attracted to the open source hardware and software community, and can see where these tools can genuinely make systems better AND less expensive (discrete instrumentation, alone, adds up, such as thermocouple displays, etc.)

So, I am toying with the idea of incorporating some arduino technology from the outset, at least for sensor read-outs…

This is one of the obstacles of gasification, getting an engine to run it without intervention. This is one of the tools that will be a major help especially on systems that do not have very linear gas flows. So this and the grate and hopper timers Ive put out here for you all.

With all three of these systems the more reliable the machine becomes. The grate and hopper agitators really help keeps flows linear and prevents other issues from occurring. These two systems are not corrective action, they are preventive measures. Once you have the gasifier breathing and flowing consistently the fuel mixer can then run with less effort. The loading of the generator is where this is really handy you can not do this manually like the arduino it positions valving very fast with precision.

The other thing is because this is open sourced and the tools were given to me for free i dont have an issue giving back.

Some of the stuff we do is our technology though and we really don’t have a choice but to keep it protected at this point. Especially upcoming technology, If we don’t get it patented someone else will and it can be turned on us. Its a cruel world sometimes.

2 Likes