That basically is what I meant. As long as it more or less mimics the RATIO of pressure rise and fall, it should be tunable. But for that you first have to figure out HOW it rises or falls. Does it go linear with RPM? Squared? Cubed?
Same for throttle position.
Once you have that figured out, it should be possible to superimpose those two factors onto each other.

For the RPM, I do not see much problems, but for the throttle position, is the "base value" the servo position (in which case the transmission ratio of servo arm, pushrod and throttle arm plays a role) or is it angular movement of the throttle barrel? Or perhaps throttle opening cross section surface area?

I suspect the latter (muffler pressure being a direct, squared or cubed function of cross section area), but I would not know how to put that into a formula, how to let the controller know how large that area is...

Chris's code attempts to calculate two components and it adds them together to produce the air pump speed command.

The first component is based on RPM and he applies an exponential curve to the RPM to generate that component.

The second component is based on throttle position, plus or minus from full off to full on.

I would think I would like the RPM component to be based on actual muffler pressure measurements and then we could adjust that value up or down by either scaling values (apply a multiplier) or just shifting them (add the correction) I'm not sure which would work better or if it's a function of both. Chris's code adds the correction. I don't know if that's the correct thing to do but if it works, it works. Still, I like to know why it works so I can apply some science to the calculation like we do with the pressure and temperature data.

At this point, I can implement Chris's control strategy with non-blocking code (so it plays nice with the other functionality) but I'd really like to understand how he got there.

I guess I need to get an engine on the stand and collect some data to program the base RPM component. That may take some time. My digital manometer needs (8 nimh AA batteries)

The whole calibration and adjustment issue was why I was hesitant to follow that route that you and Chris are now going, because of the many testruns collecting data required while lacking the possibilities to gather that data (it would require both accurate pressure readings as well as some sort of variable load to simulate unloading in the air (varying RPM by 10% while holding constant throttle). I do not have the equipment for that.

The idea was to eliminate the crap trap. It's only worth eliminating if we can make the engine run better at the same time. I like being able to automatically prime but I don't like the added tuning complexities and I'm not willing to add anything to the controller that degrades performance and consistency from day to day is important. Currently, our system is set and forget. We're changing the mixture with this and I don't know how to program it to be set and forget.

A rewrite of the code and switch to s.bus does have some advantages. Since sbus (if I can read sbus) gives us all the channels, we can program anything we want. Want an acceleration pump? Want a deceleration pump? Want them on curves? Want a start mode? Pretty easy to add. I like those options more than I like this air pump at the moment.

My fear is that EVERY additional feature only widens the burden for the end-user when it comes to setting up and tuning.
I am happy with the system as it is right now, as it basically is a fuel curve and a servo slowdown, and a bit of tweaking here and there WRT servo arm/pushrod angle and such.
I find the craptrap to be not a problem, although I freely admit, that that for some part depends on the design of the plane and the type of craptrap the user comes up with.
I have at least 3 planes where I have never even needed to empty the thing, and most only require a minimal bit of attention at the end of the day.

Pre-solenoid, that was an entirely different matter, crud production was much, and dirty. Properly adjusted though, the crud is way less.

But IF you guys manage to find a basic "algorythm" (or whatever it is called) that can control that airpump, then eliminating the craptrap is a nice thing, but what good is it if it is replaced by a barftank that is much more specific in construction, I wonder...

I also don't understand the need for a barf tank. We're using a pump to mimic the pressure produced by the muffler. If barfing is a problem, it's always been a problem and it wasn't a problem on muffler pressure so....

Well, that's in so far not entirely true. Reducing throttle in negative G conditions causes a minor reflux from fuel tank to craptrap. That is a given that no one can get around. It is not huge but it is there. Most extreme example is my F3A plane, the flying style requires reducing throttle to half going from vertical to horizontal, and pullling all the way back in the vertical downlines. No way around that. It means that over the course of the flight the craptrap collects roughly 10 ml of reflux.

If, using an airpump, the tank needs to vent off pressure when pulling back the throttle, chances are fuel gets into contact with the pump. The venting is imperative, because with half or 3/4 depleted tank the pressure drop due to fuel consumption is way too slow and the engine will get a flooding tendency. Since the airpump Chris uses is not fuel resistant, that reflux MUST be caught under all circumstances, or every flight will cost a pump.

So the need for that tank is clear. The upside of it is that that fuel is recyclable. In the craptrap it's a loss.

sure but you don't want to reuse that fuel cought in your crap trap so you just understand that there's a bit of fuel waste. this isn't really about saving a penny of fuel. the pressure that the tank needs to vent off was there when we used muffler pressure. i feel like a tee in the tank vent close to the tank that vents to atmosphere and the other port on that tee goes to the air pump through a couple loops. surely there's enough flow from the pump to the tee to keep fuel from making it's way to the air pump.

i can get this pump to modulate fairly well only with a low pwm carrier frequency. below 8hz works well and it ticks like my omega at 5% pwm without issue at 40% pwm it sounds like one of our engines idling. at 1 hz it turns down to 1% but it's ridiculous slow and moves almost no air. at 99% it makes it's own tone beats and sounds horrid but it does vary its speed well at 8 hz carrier

Oh, I meant not so much "draining and collecting", more like that a clever designed barftank, due to it remaining clean, could be made to "selfdrain" back into the main tank in positive G conditions. That would make it maintenance free, hassle free and wow, a whopping 1 or 2% more fuel efficient.
The savings in fuel are too ridiculous to talk about, but the hassle-free thing would be a great plus, whichever way you turn it.

Alright. Got s.bus working. That means we have access to as.many channels we want. It uses one of the channels of a uln2003a as the s.bus inverter. Another channel for the solenoid. There's 5 more left, 2 earmarked for the rpm input and air pump. That leaves 3 more channels. I could use one to switch the ignition on/off.

Thoughts?

Wouldn't that put noise the Arduino and RX? As it is, designers go to great lengths to keep ignition noise suppressed, either by way of a optical connection or by capacitive filtering.

These radios and our ignitions have been connected for a while. I'll look at it on one of my scopes but if it doesn't generate noise that I can see, I just may add it.

I should gather data on throttle speeds and figure out how to program an acceleration pump or what do you call it when you reduce fuel flow when the engine is decelerating? One of those.

Modern CDI units may not generate much RF noise off the high tension lead when connections at the plug are good but they will if the connections are compromised. Without optic connections or multistage filtering the RX can fail to operate correctly. It's one thing to have the engine quit, another thing if you can't safely deadstick land the plane.

1. A loose spark cap will drown out pretty much all receivers.

​​​​​​2. When the engine dies, the radio comes back.

We program it to kill the engine on failsafe anyway.

with s.bus comes greater controllability. first off, the channel signal via s.bus is 11 bits wide (values from 0 to 2048 are available. when reading the RC channel on the current controller, a resolution of about 1024 is available. switching to sbus doubles channel resolution for us. i was thinking abour an acceleration pump. i could read an additional channel and also calculate the rate of change of the throttle channel and if it exceeds a minimum value, increase the amount of fuel by an amount scaled by the acceleration pump channel value. this could be as simple as a constant value that is al=pplied when the throttle moves faster than some amount or it could be a curve that varies across the throttle range based on throttle rate of change. it could even be scaled based on the throttle rate of change so when you slam the throttle open, the mixture also slams open by some amount but if you move the throttle slowly, the mixture is only increased a small amount. we could even make that specific multiplier programmable via another channel. i could see this working to increase fuel flow on acceleration but to also decrease fuel flow on decelleration. we've got 16-18 channels we can potentially use for our airplanes. is it too much to use 5 or 6 channels for our engines, especially since it only requires a single wire to the receiver?

https://cimg8.ibsrv.net/gimg/www.rcu...42a5760810.jpg
https://cimg1.ibsrv.net/gimg/www.rcu...332f2284d8.jpg


Guys i know this is unrelated..but i couldn't help but ponder the possibility of conjoined twins😁

i posted new code for the xiao controller using s.bus. this is step 1 and it will eventually read RPM and have the ability to control an air pump for whatever one decides to use an air pump for. i've not figured out how to operate that pump but there will be space in the code to modify its operation. i'll also add the acceleration pump shortly. code is at https://github.com/raleighcopter/my-...s%20controller and it's not completely cleaned up but it does work aqnd is useable. also coming is an improved and easier assembly instruction set using the uln3002a. this reduces construction cost by a buck or so and makes assembly much easier.

If the tank had a fuel bladder inside... the tank / airpump fitting could be plumbed so the air pressure acted on the outside of the bladder ( between the inner tank wall and the outsude of bladder )... you wouldn't need the "barf tank"

Could even use that fuel bladder setup with muffler pressure, and do away with the "crap trap"... the space between the inner tank wall and the bladder becomes the crap trap... just add another fuel nipple in the tank to rinse out the crap between the tank and bladder, cap it off afterwards.

i've seen people use a balloon to make a bladder tank but the balloon doesn't last long, especially with gasoline. what materials would you recommend or is there a bladder tank we can use off the shelf?

I think that is absolutely true.

The cleaning process is going to be VERY messy, and you'll need a receptacle for the crud and spent cleaning liquid.

I think the airpump and bladder are a feasible idea, but the tank will be a chore to build, and maintenance or at least regular checks are a requirement. A simple clunktank with feltclunk is way easier to install and done properly, absolutely maintenance free.
I like to (once more) refer to the Stihl Fuel tubing part no 42293587702 in combination with a slightly modified DuBro fuel tank. My oldest tank is in use since 2014 and still absolutely 100% maintenance and trouble free.
I have never had a glow fuel tank last that long without trouble, and using Tygon, a gasoline tank needs a refresher every 2 or 3 years (the Tygon hardens over time). True, Tygon ALSO hardens outside the tank but there it is no problem as long as you leave it in place.
The Stihl part is reported to survive up to 20 years according to one of my neighbours using Stihl garden equipment.

Attachment 2273371

Attachment 2273372

there's also this single tube bung that stihl makes which i've used and can confirm it does not harden with use. great for tank overflows and fuel cans too.

https://www.google.com/search?q=stihl+1123+358+7701

Right, I've seen those STIHL fuel tank bungs before when Bert first started his gas conversion project... a clear mylar film liner would work.

It was just a thought, it would get rid of either barf / crap traps, but tank accessibility would have to be made easier for maintenance for cleaning out between the bladder with the muffler pressure setup... not something I could do on the cub easily, thats why that AC will remain glow fuel... but there will always be variations in the design that create hurdels to overcome when you start increasing the complexity... stay with what works, and don't overcomplicate things, don't scratch Murphys back in other words.:)

That looks like the OS FF320 at first glance;)... that could work with a pusher / puller prop combination... but what AC would you put it in, something with an engine pod above the wing for sure.

yeah dont think id be able to run one engine in reverse..but running both engines both the same way and make a prop shaft to connect both engines to with a gear reduction is possible

Still the same question: What plane?
I can for example imagine two engines, one after another, with a common shaft running above both engines, each engne delivering power via belt or such to that common shaft, but that is a lengthy and heavy construction, I mean at best you've got 5 HP from a 3+ kilo set-up measuring 10+ inmches in length, and that's excluding the prop drive hub...