Enjoy!
5 minutes of portwork, still rough cutting
https://www.youtube.com/watch?v=yyJS0EctzEY&t=200s
Enjoy!
5 minutes of portwork, still rough cutting
https://www.youtube.com/watch?v=yyJS0EctzEY&t=200s
Quote " This tests just for comparisons and interval between Black/Green graphs - 2 hours. Red/Blue tests on second day.
All tests done until power goes down, when engine temperature reached 70-80 C."
The big problem there is that a set of tests "on the second day " could easily be 3-5% wrong due to just a change in RAD.
And I know very well that the difference in power of a 125 race engine at 45*C and 65*C is over 1.5HP - going as high as 80* makes the test completely invalid.
In answer to 444, the water circuit change was a test for Franco at TM , to show that cooling the transfers first with cold water made better power.
This was part of the Exhaust duct cooling saga.
My test was trying to convince him to run the cold water (that enters the engine between the crankcase and the gearbox ) across above the mains, and into the cylinder
each side of the boost port.
The test had small drillings in the plugs under the Exhaust duct,to cool that area,and the head cover was modified with equal size slots for water entry at the front and rear.
The Tech team at Kartsport NZ have deemed the hose in the front of the cylinder as illegal.
I dont accept this ruling, as in the homologation papers there is no hose at all, thus with that logic all engines, with any hose ,must then be illegal.
And nowhere in the CIK rules does it say anything about " stock appearing ".
But I am not going to chance a protest, so I have found another way to direct the cold water back over the transfers ( keeping the small drillings as well ).
As far as LucF is concerned, I wont even comment, as I cant access any of the links.
But if he comes on here with more bullshit app generated so called "dyno " printouts,then I think he should be blocked,as he has done to many others.
Ive got a thing thats unique and new.To prove it I'll have the last laugh on you.Cause instead of one head I got two.And you know two heads are better than one.
LucF replying to whether it was dyno or app .Using FB translate feature from Dutch
"Jan that is based on weight and time at the 150 meters. And I've really stayed on the thrifty side with the variable. I've been using this program since 2000 to analyze sprints when I was driving 400 m. The program was made by my son to the tudelft."
.
Now that shifting premises at work has been done and things are beginning to sort out and find their new homes and life is starting to get back to normal. I can begin thinking about my EFI project again.
Ok my other EFI airflow ideas have not worked out that well, but maybe the Max Min Difference thing will be the ticket.
My last effort was to try and tell if the motor had fired or not and therefor how much fuel was required on the next cycle. For that I developed a pulse sensor and Arduino Nano program to look for a cylinder pressure pulse just before exhaust port opening. The concept worked Ok but it did not help that much with refining the fueling required.
![]()
![]()
4T's often divide the fueling into a volumetric efficiency VE map for throttle settings below 25% and an Alpha-N map for power settings.
The Alpa-N map only needs to know throttle position and rpm. Alpha-N is easy enough to get working well above 25% throttle.
A VE map requires some way of knowing what the airflow is and Automotive hot wire and flapper valve type systems don't work well on tuned 2T because of all the air reversion and fuel spit back.
For a 2T there needs to be another way to determine air flow if we want to use a VE map.
From experience I have learn't that the average pressure (Red line) does not vary much over the total power/rev range of the motor so that is pretty useless.
But there must be a maximum as the piston descends and minimum as the pipe sucks mixture from the crankcase (Black Lines).
I expect these maximum and minimum pressures to become more pronounced as airflow through the motor increases and the difference between them could be a usefull indication of air flow.
My plan is to determine the Difference (Blue line) between the maximum and minimum pressure on each cycle and present it as a pseudo MAP value to the EFI CPU.
The crankcase pressure will be read by a 2.5bar MAP sensor. The Arduino will just be an interface between the MAP sensor and EFI CPU.
Why a MAP sensor and not a pressure sensor. A MAP sensor because it measures absolute pressure and can tell the EFI's CPU if the throttle is closed or the pipe is boosting air flow through the motor. A normal pressure gauge measures gauge pressure Ie., any pressure that is above atmospheric pressure.
Here is my initial code for finding the max and min values. It compiles but as yet untested. There will need to be a little extra bit of code added to match the Difference value to real world MAP numbers expected by the CPU.
The pulse from the ignition pickup is used to mark the end and start of each cycle.
It is counter intuitive that the code starts with Max=0 and Min=1024 but it becomes obvious when you think about it.
// MaxMinDifference
// Arduino Nano Routine.
// The routine is for providing a MAP value to a volumetric efficiency (VE) map for a high performance EFI 2T engine.
// By using a MAP sensor to determine the difference between Maximum and Minimum pressures in the crankcase for each cycle.
// And then calculating the Difference and outputting this as a MAP signal to the EFI's ECU.
// This difference should be a useful representation of the volume of air being drawn through the motor when at < 25% throttle opening.
// From experience, the Alpha-N methodology works well at throttle setting > 25%.
// The ignition trigger pulse is used to signal the completion of each cycle.
int CrankCasePressure = (16); // analog input pin for crankcase pressure as read by a MAP sensor.
int Maximum = 0; // Variable
int Minimum = 1023; // Variable
int Difference = 1023; // Variable
int MAPout = (17); // analog output pin for pressure difference as a MAP value to the EFI CPU.
const byte EngIgn = 2; // the number of the ignition pulsar interrupt pin.
boolean IgnPulse = false; // Boolan - using the ignition pickup pulse as a marker for a completed cycle.
void setup()
{
pinMode(16, INPUT); // initialize analog pin A3 as an input.
pinMode(17, OUTPUT); // initialize analog pin A2 as an output.
pinMode(2, INPUT); // initialize digital interupt pin D2 as an input.
analogReference(DEFAULT);
attachInterrupt(digitalPinToInterrupt(2), IgnitionPulse, RISING); // ignition pickup pulse.
}
void IgnitionPulse () {IgnPulse = true;} // we have seen a pulse from the ignition pickup.
void loop()
{do
{CrankCasePressure = analogRead(16); // read CrankCasePressure value from the MAP sensor analog input.
if (CrankCasePressure > Maximum)
{Maximum = CrankCasePressure;} // increasing high crankase pressure.
if (CrankCasePressure < Minimum)
{Minimum = CrankCasePressure;} // decreasing low crankase pressure.
Difference = Maximum - Minimum;
if (Difference > 0)
{MAPout = Difference;} // MAPout becomes an indication of air flow through the motor.
}while(IgnPulse != true); // keep looping until there is an ignition pulse.
analogWrite(17, MAPout); // pressure difference as a MAP value sent to the EFI CPU.
int Maximum = 0; // Reset the Maximum Variable so as to find the next crankcase maximum pressure.
int Minimum = 1023; // Reset the Minimum Variable so as to find the next crankcase minimum pressure.
(IgnPulse = false); // reset IgnPulse for the next cycle.
}
"Second day" tests indeed can be doubtful, but after 2 days with SX65 and 3 days with SX85 and so much dyno graphs, feels, that rounded piston, together with other head/cylinder adjustment, reach std piston mid power, better on top and very nice over revs power. Maybe track tests and words from little boy would help to understand more.
I really like your idea about outside transfers cooling, flow from crankcase all around cylinder - looks very promising.
Interesting, on NSR 250 cylinders, there is two cooling passages on each side of the C port, but as the crankcase without any holes, there is no flow in these passages (add pic).
The MatLab program is a general computer program that is used for all kinds of physical calculations at technical universities such as TU Delft
When my son studied there, he wrote as an exercise a program in MatLab that was made especially for drag racing. But it can also be used for speed records at Saltlake Utah.
He graduated cum laude in Aerospace cum laude in 2004 and now makes calculations for missiles for his daily work.
All necessary variables can be entered. I was able to test this program directly in practice when in 2000-2004 I did 50cc dragrace on the 1/4 mile in Drachten.
3 distances were measured on the track: in time and speed. It is important that all distances in time and speed are just right in the MatLab output.
In addition to the correct weight and all gears, this can be done by the correct input of torq, cd value, +/- wind in bft, shift time e.o.
For the 18 hp 50cc sprinter in those years, that should happen very precisely. Later I made a lot of calculations with this program, not for Ryger.
Also based on G-measurements I made with MrDyno on the sprinter. Or take over from camera pictures on a racing bike.
Some examples that you can find in this photo album on Facebook https://www.facebook.com/luc.foekema...5454134&type=1
The fact that so many people stick to the results of that test bench, with all the different results, is a mystery to me.
I have seen many test bench results in my life and especially lately with extreme deviations.
A test bench also depends on calculations, which is no different from what happens in the MatLab program.
But I use data recorded on the road under the right conditions and not in a box where the circumstances always deviate.
It seems to me that data measured on the basis of practice is somewhat more reliable.
Today test - Red rounded piston with matched head/piston, Blue - Std piston tested two days ago.
The thing is the question of variables Luc. For your on-road assessment method (say MatLab), you have so many variables: frontal area (rider position, head up, head down)), road surface over the distance, tyre pressures, rolling resistance, wind, gear change variabilities, temps etc, etc, and in your case an engine that only has to survive for 400 metres rather than a full GP distance, the comparison to other engines under different test conditions is pretty inconclusive.
An inertia dyno, assuming the conditions (temp, humidity and pressure) can be well monitored & corrected for (eg RAD), so there is a minimum of variables compared to an on-road prediction.
For me, I’d like to see a direct, same dyno, A:B:A:B comparison on the same day before drawing any conclusions. However, even with that, when we have to add to that the cooling, mixture, exhaust design and ignition etc might be optimized for a possibly different application, then the numbers almost become meaningless.
The ultimate dyno is who wins on raceday in their particular genre of competition. And irrespective of that, is that we can all learn from each other and, importantly, all have a giggle on the way and not get too serious.
"Success is the ability to go from one failure to another with no loss of enthusiasm.”
as according to you dyno's are shite, how have you determinned the correct input of torq ? and if you can determine the correct number of torq before matlab, you can also determine the correct horsepower ... just multiply torq with rpm. so basicly your program is a fancy gimmick that has no real purpose ???
Hi Ken, long time ago!
You can merge many variables to one value that you can use, because they all have to do with resistance, in the program I choose a cd value for 1m2.
For my drag racer I was able to determine the correct value as described earlier: 3 measurements of time, speed and distance on the 1/4mile at 60ft - 201 - 402 meters.
If you choose only a little bit wrong in torq or cd, then not one of the 3 matches the real measurements in time and/or speed, made by the organization Explosion.
My little front wheel was not always visible for the time measurement, so I had a very fast 60ft time that nobody understood.
When I shortened the distance of 402m in MatLab with 1.4m of the wheelbase, the starting speed changed from 0 to 14 km/h, everything was right again.
For me a proof that it worked 100% because the backwheel was measured first.
https://www.facebook.com/photo.php?f...type=3&theater
Also measurements for road racing were done with a camera on the rpm or tachometer and you have an extra controle with the switching times and speeds.
So even from a video, the correct Cd value can be separated from the correct torq value.
The best examples are the 50cc speed records on YouTube video with the camera, time and milestones.
You are a little while busy before everything is correct, but you will know if you need it.
For a quick calculation on the 150m I only need weight and time. Because a little change of CD value does not do much anymore.
For my drag racer there were no differences to measure with applying a little streamline or not.
The same counts for correction for wind + of - which can be used in the program, but on short sprints at 150m it will change very little.
And the higher the power and/or the shorter the distance, the less important that CD value and wind becomes.
In the present case, 72cc the Derby, which is not mine, was already tested on the dyno with 31.9 hp at 13.900 rpm
Photo's of the graph are visible on Racehelden forum https://www.deraceheldenvanweleer.nl...p?topic=2007.0
Beside it was already written here by Yannik, but most people apparently do not want to see this.
So the outcome with 32.75pk was no surprise to me and especially not when you see how this Sietse and Gerard made it !!
There are currently 5 users browsing this thread. (0 members and 5 guests)
Bookmarks