There are folks who have tested cdi units and have posted characteristics. Try the search engine here and on RCG.

All engines do indeed have different characteristics. You can play with static timing and fuel mixture to squeeze out extra ponies, however it's risky. 28 degrees btdc and the leanest mixture possible, in the air, is the safest i.e. the engine will just quit running, with no harm done, if there is a fueling issue or overheating issue. The engine will not detonate, it will just quit running.

Advancing the timing requires a complimentary richer fuel mixture. If you experience a fueling issue, for example, the engine could run too lean for too long, causing excessive heat and detonation. Not a risk I'm willing to take for a couple hundred rpm gain.

Here I am merely parotting Bert's expertise and evaluations. He's the expert on the finer points of internal combustion engines. If I have posted incorrect info he'll be along to correct me......which I truly enjoy.

I've managed thé engine (4strokes thunder tiger f91s) and one os46 sfh ringed ) rebuild and seals and gadjets changes, the fuel tank and dust collector, CDI adaptations are Turned and set for both, i have Brutus full system ( and a few others) o place one my plane and parallel i built a xiao version to have a tryout. This last version doesn't work fully for instance, i suspect the MOSFET to bé Fake because it claims to be vishay which dip4 IS in different casing
I've ordres so from different source i will test AT reception, meanwhile i will re maje breakin' of the old glow engines

Yes... A strobe light and an accurate Tach go a long way :D

But there are no "characteristics" as such... There is a digital processor inside, and the advance/retardation is strictly linear over 20 degrees from 1000 to 4000 RPM.
Digital processor is programmed such that it measures RPM, and calculates necessary delay. Above 4K it fires without delay upon triggering, at 1000 RPM it delays the trigger corresponding to 20 degrees.

What telemetry receiver?
 

I am interested to know what telemetry receiver(s) you are using then Bert? Also, how is the telemetry useful for "getting a good tune"? (I probably should already know this - pardon my ignorance).

The reason that I abandoned use of telemetry receivers years ago was that I had a run of FrSky telemetry receivers failing. I have a thread documenting these failures (and crashed planes), over on rcgroups. (More than one failed on the bench!).
(A flying buddy also had similar experiences and we both bought up and since use "V" series FrSky receivers. Zero problems experienced with them, and I have not read of one single failure from other flyers.)

Nothing in this regard is irretrievably locked in for me; I could now use another brand; maybe FlySky which to my knowledge, have a good reputation. Also, they produce a 10 channel rx. which would add an extra advantage as I am running out of channels on both my two stroke powered tugs; resorting to sharing one channel for two control surfaces etc. (Y leads).

So, to sum up; what Chris has provided for me will get the project moving forward, which is my primary need.
His assistance has increased my understanding of arduino basics and with some further work on my part in due course, I may be able to get a "full" sketch to verify.
I am completely open to flashing my XIAO board with the full sketch and to order another 10 channel FlySky receiver. (I have one in commission somewhere - cannot remember this morning!)
I have no legal flying field locally, so cannot fly until sometime next year - so I have plenty of time to experiment and modify etc.
The little XIAO board can be flashed (uploaded) with the limited sketch and then flashed again with the full sketch when and if I get a sketch to verify on my system.

Thanks for reading all this, I did not intend to clutter the discussion up with extraneous matters.

Jim.

Full sketch verified and uploaded!
 

A few hours later..........I have downloaded David's full sketch from the GitHub site again and installed/updated the necessary libraries in my arduino IDE.
It verified and is now flashed/uploaded to my little XIAO board.
Once I found out how, it all seemed so easy! I cannot fully explain what I was doing wrong, but it's only theoretical at this point.
I will now proceed to construct my controller following instructions on the GitHub page.
Progress happens!
Thanks to all and apologies for any unnecessary fuss etc.

Jim.

Jim.. No need for apologies as the Arduino IDE exercise was a good brain workout.. Not my strongpoint and this was a little win for me to be able to help out with solving this... was also a good exercise to maintain currency on how the MPU process works - I updated all my Arduino IDE software and libraries and "renewed" all my working sketches...

The hard part is done now - the hardware part is easier in my estimation..

Mine too! I am life long electronics amateur and I worked for a short time in the industry.

I once thought I was passably clever, then I discovered Arduino!..............

I get that. If not for Raleighcopter's offline guidance I never would have gotten the Arduino working. But I'm a complete diga-idiot.:D

What is that controller that you are using in this video Bert? (Bottom right of the video display).
It is clearly not either a transmitter or one of Dave's controllers, as described in his GitHub page.

Jim.

Alternative SPort 10 channel receiver.
 

Since writing this, I have realised that FlySky does not support SPort.
Does this mean that I am limited to using FrSky telemetry capable receivers in order to utilise the tuning benefit that Bert and others refer to above?

Have I missed something?

Jim.

I Use nowadays the X8R or XR8R (from memory, forgive me if the designations differ a bit from reality) receivers, with the in Europe compulsory "listen before talk" protocols and max 100 mW TX power, and I do not experience any issues.

Having telemetry data in itself (with which I mean, the option to read data from the display while flying) is not all that important... But what IS important and has brought good progress both in developing this solenoid stuff, as well as solving tuning issues, is the data-logging option, which allows to represent each flight in graphs.

In order to utilize this, it is necessary to fly test-protocols (a predetermined series of engine-manouvres, if needed combined with certain flight conditions) and "marker manouvres" in order to be able to identify the running conditions.

As an example of how it helped: Remember that servo slow down that I recommend in order to prevent engine stumble on acceleration?

It IS possible to remedy that stumble by fattening up the idle mixture. But above trendcurve analysis learned that while idle RPM on the ground is as intended, once airborne idle won't come down for the following reason: A rich idle mixture on the ground forces the idle air opening to be larger in order to sustain, say, 1500 RPM. Unloading in the air causes the mixture to lean out however, and the larger air opening and now leaner mixture will easily keep the engine at 4, maybe even 5K and landing becomes a challenge.
Especially in 2-strokes, that run rather rough at lower RPM and rich settings, this is inaudible to the naked ear, but telemetry data combined with overlaid throttle position data makes this very visible. I would not have known this without telemetry and datalogging.

But it can also help identifying non-audible rich or lean spots in the curve by for example flying 30 seconds at 20% throttle, 30 seconds at 30%, 40%, 50 etc and comparing the changes in throttle with th changes in both RPM and CHT.

It is time consuming, but extremely educational if you know what to look for.

That was a custom built "local controller" that I used in the very first concepts of the solenoid idea. Back then, I did not yet have programmable TX and telemetry and stuff, and the idea was to hook up a stand-alone unit in the throttle servo lead with an on board storage for a fuel curve. That system was intended for a helicopter with autonomous RPM control (governor) so a throttle or pitch based system would not work, it HAD to be an on-board stored curve acting on the governor-output.

That system never came off the ground, since the biggest issue was the user interface, and the (im)possibility to ground-test a fuel curve intended for flight, since running conditions are not th same in a heli.

The controller was a box that allowed to control the throttle servo with the knob, and program a curve that would simultaneously drive the solenoid. I used it to run a glow engine, found that it was at least somewhat possible, then marriage got in the way and the idea was shelved. After my wife died, I kinda fell into a dark pit and picking up the idea was a way to get out of that dark place.

Full disclosure:
This is one of the first tests with forced fuel mixture.
What you see is a (very old and worn) Veco 19, running glow. Needle valve is removed, and fuel supply is forced by a manually controlled positive displacement pump (kinda like a dosing pump). It was sheer horror to get the engine started (forced feed, so the fuel would flow regardless of whether the engine ran or not, flooding was very difficult to prevent). Since engine RPM (and thus carb vacuum) had zero effect on the fuel flow per minute of time, stability could not be achieved, or only extremely difficult maintained manually.

Sinc pumping did not work, I had a look at the solenoid.
The bucket video you have seen.

I then ran the engine. I did maybe 20 or 30 testruns, of which the first 3 were documented, but then progress stopped, and the principle stranded (gasoline was not yet on the horizon back then):
In this first test, I was manually controlling throttle, and separately controlling the fuel feed, in order to get a feel for what was needed. It became fairly quickly clear that the fuel flow was in part manually controlled, but ALSO affected by RPM (carb vacuum) and basically with this set-up it was fairly easy to achieve a stable run, be that rich or lean, and controlling the engine on a constant throttle setting was no harder than setting a conventional needle.
Come to think of it, It was actually during THIS particular run, that I discovered the atomizing effect of the modulating solenoid, because the Perry carbs allow a good visual on the fuel exiting the spraybar. Funny how those memories return...

In this second tst, the throttle servo was also hooked up, and a single knob controlled both servo and fuel feed. Setting a curve turned out to be fairly doable, but it is clear that all the linkages were very sloppy, and results not really consistent

third test, by now I started to overthink how to implement this in a practical model, and ran into the issue of the human-machine interface... How to do that sitting next to a running helicopter? some sort of handheld terminal to change curves on the fly was needed, some form of graphic rpresentation was needed, etc etc, and my then TX did not have that...
That was before the gasoline days.
Then I took to gasoline and planes, and I first messed a bit with modifying existing glow carbs.
Only after buying a Taranis, suddenly I realized that this transmitter basically allready had everything I needed to finish this project as standard options...
All I needed was a different, much simpler driver. But gasoline turned out to be a MUCH broader subject than glow/methanol...

I am happy to read that report Bert.
However, my history with them has not been such a happy one. There was a historic firmware problem, which has been remedied via an update which is installed in new receivers for some time now.
However, some of the early release X8R, prior to this update, have been associated with catastrophic failures.
Two threads documenting some of these:

https://www.rcgroups.com/forums/show...eiver-failures

https://www.rcgroups.com/forums/show...is-Rx-lock-out

While this problem has been "fixed", my personal experience in FrSky receivers has been shaken severely due to this history I regret to say. I could most likely purchase a new X8R receiver, install it in a plane and never have a RF connection problem.
However, it comes down to a confidence and trust issue for me due to the above. I would tremble before flying with one installed on my valued craft.
Not totally logical?
No I agree, but that is my feeling around this at this moment in time.

All that is completely clear to me; you have explained it all very well!

I am beginning to realise that this project is not for me. Not just for the realities outlined by you above, but for other reasons that will make the last part of your explanation ("the tuning flights") simply impossible.
I have no access to a local, legal authorised flying field, and at this stage, it does not look like this will change.
I have been attending a flying event once per year, and otherwise just flying hand launched craft in a nearby paddock, probably breaking some law or other!
Here in my country, we are losing flying fields on a regular basis - the "squeeze" is on so to speak.
As a result, I will be unable to do multiple flight testing to evaluate and tune up the system, like you describe.

Quite despite this sober realisation, I will likely still go ahead and assemble a controller, set it up on a converted two stroke on the bench just for the exercise.
A bit crazy I know! But still will be a bit of fun.

Thanks again,

​​​​​​​Jim.

Double Post.

In all fairness, I always flash any receiver I buy to the update that I know works for me. I have had a few issues, but they were nowher near as dramatic as described in those links.
All I noticed, was a very occasionally (maybe once per month or so) only one function (always ailleron) responding a fraction of a second late. So little that I usually discarded it as a bit of turbulence countering my own imput, always so little that I only wondered a few seconds after the occurrance "huh? Was that me, or did the plane really not respond for a microsecond?".
Never lost a plane due to it, never even came into trouble because of it, never even remotely close to critical... Just enough to notice aftrwards that it happened again.

I never lost faith due to it, I just know that I need to flash any new receiver, and that's the end of it for me.

​​​​​​​
Jim, I hear you WRT your local field-situation, but I have to say, you are giving up too early... A lot of what I explained about the use of telemetry, was for ME very important, because back when I started this, I ran head over heels into unknown territory, and I needed to use a more structured approach.
Most of it however is generic, and once known, for example the issue with that rich idle can be solved by simply setting it as lean as possible and use a servo slow down function. No need to first experience it, then do test flights and data-analyzing,.. Just follow the trodden path...
It is NOT so, that without telemetry and logging function, or without the possibility to fly test routines, tuning becomes impossible.

It is entirely possible to tune by ear to the rich side, and creep up on the proper settings by carefully adjusting.

I apologize for that message coming across the wrong way.

Hi!

Some news about my plane converted with the 25LA (without solenoid), I flew a few days but the last attempt my wing broke in two parts because of a structural weakness.
https://cimg6.ibsrv.net/gimg/www.rcu...d945ae815b.jpg
​​​​​​
The plane frame was ok for repair. So I adapt a Calmato wing and change the engine for a 40FP and reinstall the solenoid.
https://cimg4.ibsrv.net/gimg/www.rcu...f136bd3be5.jpg
https://cimg5.ibsrv.net/gimg/www.rcu...3c9bc3d86f.jpg
With this engine the small bubbles like dust that come from the solenoid have no effect on the engine operation.And now I can use the solenoid, and fine-tune the engine operation. So for me the 25LA is too small to work with the solenoid because of its sensitivity to small bubbles.
​​​​​

Very happy to hear that the .40 responds well to the solenoid.

I still think it is not so much the size, as well as the fact that the engine is bushed, and there is more heat generated in that area. The 40 is bushed as well, but the larger mass of metal, as well as the larger fuel flow mitigate the issue. I think a ballraced .25 would work OK on the solenoid, and for me, your experience with the LA 25 will be included when other people inquire after a set.

But that is all less relevant, happy to see that the solenoid is doing its job, and I am sure you will find, after some careful tuning, a much cleaner running and better responding engine as the result.

Please keep us posted on your experiences, good or bad, so we can learn from the good things and help solve the bad things.

Yes probably due to the heat by bushed design too.

Initially I wanted to swap the 25LA by a 40SF, but the extra weight of the 40SF compared to the 40FP made me change my mind.

But for my next plane I plan to use the 40SF converted to gas 😉

Is the SF that much heavier? I was not aware, but I am fairly sure the difference in power output would more than compensate for the additional weight.

And SF's are very nice runners...

Yes, the weight of the 25LA is 270g for 0.6hp
The 40FP 330g for 1hp
The 40SF 460g 1.2hp
And the 40SF has larger fixation points, and it's not compatible with my 40" trainer.

Hello, I managed to adapt the code for my esp32, but I'm not sure about the frequency to use for the solenoid pwm? I don't understand what frequency is set in your code?

Thank you

Any frequency between 25 and 30 Hz will work just fine.

i'm using somewhere around 33.6 hz. here's how....

from the xiao code:

line 101 divides the 48MHz main clock by 1000 (except this divider can only be 8 bits or a max of 256 so 1000 rolls over 3 times and leaves 232 which i changed in the experimentsl code but not here.) => this generates a 206,896.5 Hz clock.

line 127 divides the 206.8 KHz clock that i generated above by the 6145 (remember, with computers counting starts at 0) which gives a carrier frequency for the PWM of 33.66 Hz with 6146 steps of resolution.

i should change line 101 in the code so it's not so confusing but it works so there's that.

...i changed those clock dividers to 232 in the xiao and zero code. should be easier to follow now.

What is the zero code for? That is: zero_solenoid_controller.ino

Which of the two .ino files listed in your GitHub page do we upload to the XIAO board?
This has me totally confused; there must be some explanation somewhere in the old thread that I did not read properly or understand.

Jim.
https://cimg3.ibsrv.net/gimg/www.rcu...2d9e554471.png