# 10/23 Raptor Video

### Help Support HomeBuiltAirplanes.com:

#### Pops

##### Well-Known Member
HBA Supporter
Log Member
Up high in a C-172 and hit some turbulence over mountains and happen to be looking out the door window and seen the wing tip go up and the landing gear shake and it knocked the breath from me and hurt my lower back and the windshield make a large cracking noise. Slowed it down and had a wild ride for a while. Takes the fun out.
Amazing amount of bending even in an alum wing.

Last edited:

#### TarDevil

##### Well-Known Member
My old company owned a lot of private jet aircraft, and occasionally we'd have one that would scrape a wing on landing
I'm reasonably sure there's some difference between scrapping the wing of a 10,000 lb Mach .80 jet and a 3800 lb composite piston aircraft.
Yeah, if look it over but Raptor's wing scrape can hardly be compared to dinging the wing of a jet.

#### PPLOnly

##### Well-Known Member
I'm reasonably sure there's some difference between scrapping the wing of a 10,000 lb Mach .80 jet and a 3800 lb composite piston aircraft.
Yeah, if look it over but Raptor's wing scrape can hardly be compared to dinging the wing of a jet.
Landing speed is about the same...

#### TarDevil

##### Well-Known Member
Landing speed is about the same
But not the weight (read, force exerted on the wing), nor the stresses in flight regimes of jets vs Raptor.
There's just no comparison.

#### BoKu

##### Pundit
HBA Supporter
Well they won't "almost touch each other", but the '20 wingtips will indeed flex upward about 4 feet during a normal XC or contest flight in desert/mountain turbulence. I'm pretty sure they would break well before they actually touched, but at my advanced age and decrepitude I'll have to leave that to the LBA test pilots (and one or two US contest pilots I knew) to prove that out for certain

The fact that the rather complex aileron and flaperon functions on that wing will continue to function correctly during a four foot deflection is a magnificent achievement for Waibel and his design team. One of the great honors in my time was to be able to shake Waibel's hand in person and thank him for the AS-W20.
I asked him what the tip angle would be at 10g. He shrugged and then held his arms up in a U shape, fingertips vertical.

#### Pilot Rick

##### Member
The real question we should be asking is ...was the bag of lead he stuck out there damaged in the wing strike!

#### Mike0101

##### Active Member
HBA Supporter
Not true for our ECUs. Not sure why you'd have any FF, duty cycle or pulse width displayed when none is happening. No injector frequency means zero fuel in reality. Reporting reality seems like a better idea...
The Motec was reporting it's reality of fuel flow (with strange offset), yes the engine wasn't running. Somehow an error or offset got introduced along the way. When PM first hired people to do initial calibration, I'm reasonably (99%) sure that the 20mg wasn't there. But along comes PM to do things his way... He either intentionally or unintentionally created a +20mg offset, that likely globally effects fueling. If a competent tuner or calibration engineer was asked to assist, they would be greatfull to see the 20mg offset. It would be a strong indication that things are wrong. I for one would want to see it, and wonder how big the iceberg really is.

So a bit of trip down past ECUs. The first good ICE specific or optimized MCU was the venerable MC68332. The oldest datasheet I can find on it was version 2, from 1993. The first Formula 1, ECU was based on it. I'm not sure but believe it was in limited availability several years before that 1993 date. What makes the 68332 relevant is, it already had a sophisticated I/O co-processor. It's strength was converting time domain to angular domain. The co-processor handled crank angle tracking, injectors, ignition coils and could trigger ADC (analog to digital converter) conversions/samples, for such things as MAP. It will happily do so with little main CPU intervention. The Motec uses an evolution of this MCU, as do lots of OEMs.

MAP isn't dependent on time or crank angle in our ECUs. Not sure why it would be. MAP is simply pressure in the manifold and you can read that even with the engine not running in our ECUs.
As far as MAP. Take an oscilloscope and probe MAP (manifold absolute pressure) sensor analog output. At low speed, you'll see a sinusoidal like waveform on SI engines. The peaks and valleys can be large, especially on engines with small plenums (surge tanks). Aircraft engines have small plenums, because they were designed for carburation (need to keep velocity up). What if one time ADC captures, peak, then valley, then something inbetween. Yes a low pass filter cleans some of it up, but syncronous sampleing tied to crank angle is the better way. Most ECUs will sample MAP just before intake valve closure as that best reflects probable cylinder charge pressure. Intake manifolds resonate, and ideally you want to create that resonance so that reflected pressure wave arrives just as intake valve is closing, in essence creating a supercharging effect. This is another reason for synchronous sampling, as the resonance doesn't work across entire RPM range. Some engines have variable length runners, others have 2 lengths via a flap valve, while most are fixed length.

To put this into perspective, even the Mega Squirt, and Micro Squirts have crank angle based MAP sampling... Obviously you switch to crank angle based sampling after engine is running. Then also, you want to know ds/dt or rate of change on your MAP. This would be for enrichment, or proper fueling of transients such as boost spikes which can occur with rapidly closing throttle body.

MAF is zero with engine not running in reality. Anything other than zero is false.
Any automotive MAF I seen in the last 2 decades is a thermal dispersion type or technology. Once you understand how it works, you quickly realize that it is least accurate at low flow. OEMs put in allot of effort to try to characterize this low flow region. It's actually surprising how well a sub $100 device to OEM works. You don't get a true "zero" flow. You can try to justify these errors if you want but in the end they are just plain wrong and the results of lazy programming. True data from logging makes it easy to understand what's going on. Erroneous data doesn't, as we see in this case. I am not justifying any errors, but would rather know an error is present versus masking it, with don't display XYZ variables unless engine is running. How PM's 20mg fuel offset got there, I don't know... Also remember ECUs have had multiple processors for coming on 3 decades. They do not work like your SDS unit. I am not a Motec fanboy, but do understand how they went about certain things and wouldn't call them lazy. #### Mike0101 ##### Active Member HBA Supporter I was just looking atthe vids where he modified the redrive. The two bottom tubes off of the oil collar were welded up and a drain added to the case. Then he made a comment about the crankcase being designed to operate under a vacuum so its sealed up to some extent. Something caused the crankcase pressure to jump and force the oil out. A turbo seal would be on the short list of suspects. I was referring to high crankcase pressure perhaps hindering oil return flow. You'd be surprised how much blow by can be generated on a failing engine. As others mentioned, hard to generate a vacuum without a throttle. If PM thinks he is generating a vacuum, well I guess it's about par for the course. Last edited: #### rv6ejguy ##### Well-Known Member As far as MAP. Take an oscilloscope and probe MAP (manifold absolute pressure) sensor analog output. At low speed, you'll see a sinusoidal like waveform on SI engines. The peaks and valleys can be large, especially on engines with small plenums (surge tanks). Aircraft engines have small plenums, because they were designed for carburation (need to keep velocity up). What if one time ADC captures, peak, then valley, then something inbetween. Yes a low pass filter cleans some of it up, but syncronous sampleing tied to crank angle is the better way. Most ECUs will sample MAP just before intake valve closure as that best reflects probable cylinder charge pressure To put this into perspective, even the Mega Squirt, and Micro Squirts have crank angle based MAP sampling... Obviously you switch to crank angle based sampling after engine is running. Then also, you want to know ds/dt or rate of change on your MAP. This would be for enrichment, or proper fueling of transients such as boost spikes which can occur with rapidly closing throttle body. Any automotive MAF I seen in the last 2 decades is a thermal dispersion type or technology. Once you understand how it works, you quickly realize that it is least accurate at low flow. OEMs put in allot of effort to try to characterize this low flow region. It's actually surprising how well a sub$100 device to OEM works. You don't get a true "zero" flow.

I am not justifying any errors, but would rather know an error is present versus masking it, with don't display XYZ variables unless engine is running. How PM's 20mg fuel offset got there, I don't know... Also remember ECUs have had multiple processors for coming on 3 decades. They do not work like your SDS unit. I am not a Motec fanboy, but do understand how they went about certain things and wouldn't call them lazy.
The thing is you don't need any of this (over) complication to make an aviation engine or automotive race one run well. The CPU operates much faster than the relative glacial pace that mechanical events in the engine occur at. The proof is that SDS is on the fastest EFI equipped vehicle in the world- Andrew Findlay's 2 time Reno winning Lancair- over 430 mph on telemetry. This engine runs on the ragged edge of destruction, so it's a challenging environment.

For MAP, you simply take multiple samples in software and average them before the injection event. Crank angle doesn't need to be considered.

You are coming back to justifying these display errors here. There is zero fuel flow and airflow with the engine not running- period, end of story. To display anything other than zero is erroneous.

Typically with throttle closed (SI), we shut off the fuel in automotive applications so there is no fueling to worry about there. With a throttle plate, we don't care what upstream pressure is because that's separated from the engine and the MAP sensor anyway.

SDS displays all sensor inputs, engine running or not but they all read correctly at least. Why wouldn't MoTec?

MoTec makes some of the best ECUs around, no argument there, but you simply need the AFR and spark timing to be correct- period. We've run SR20 race engines back to back on the dyno, SDS vs. MoTec and the result was no difference in power.

Peter's fiddling may have resulted in this FF display error. I certainly don't know enough about MoTec to say but at least with SDS, the user cannot manipulate anything with programming to have FF display anything other than 0 with the engine not running, so I'd say that's something in the MoTec architecture which could be addressed.

Last edited:

#### Rataplan

##### Active Member
My old company owned a lot of private jet aircraft, and occasionally we'd have one that would scrape a wing on landing. The inspections for those were substantial. From weeks to months out of service depending on what the engineers said we needed to do. There is simply no room for "probably" when it comes to your wing. Especially with a clean sheet airframe with limited data. If he cannot calculate the actual loads of his wing strike than he needs to do a thorough inspection, not a walkaround, of his structures. I am hoping that is what he is doing over these next 2 weeks.

He really should be applying these same principles to his eBay engines too, as I stated before. He should be bringing them to a known-state with an overhaul before flying it. He has no idea the condition they are in upon receipt.
I fully agree with you.
I read here a lot of people talking about deflection of the wing tip, but they compare static with dynamic deflection.
Take a wingtip and push it up and down with small deflections in a certain ritme and at a certain point a wave trough the wing appears which also can introduce extreme forces trough the wing although with deflections smaller than static deflections.

About the Audi engine, well perhaps because in Europe Audis with these engines are 'tortured' by its users and start having problems after 100.000 km and needs overhauls at 300.000 miles (there are exceptions).

On average a second hand engine will have undergo 1500 hours runtime under harsh conditions and preparing it for use in an airplane should imply dismantling the whole engine.

#### flywheel1935

##### Well-Known Member
I don't think any of us will expect Raptoman to strip and examine his 'ebay' engine purchase, I think to save face he wants the Raptor airborne asap, so the West Coast investors can start the 'production plan', My guess is they going to "evaporate" soon, or plow their cash into Chocolate Teapot Manufacture !!! ( more chance of sales and a cash return)

#### Rataplan

##### Active Member
Well they won't "almost touch each other", but the '20 wingtips will indeed flex upward about 4 feet during a normal XC or contest flight in desert/mountain turbulence. I'm pretty sure they would break well before they actually touched, but at my advanced age and decrepitude I'll have to leave that to the LBA test pilots (and one or two US contest pilots I knew) to prove that out for certain

The fact that the rather complex aileron and flaperon functions on that wing will continue to function correctly during a four foot deflection is a magnificent achievement for Waibel and his design team. One of the great honors in my time was to be able to shake Waibel's hand in person and thank him for the AS-W20.
Well you know (glider) pilots always make their stories a little bit bigger LOL.
Never met Waibel but as child several times met Rudolf Kaiser (the designer of the famous Schleicher K series) when he visited our home and remember he liked the dutch cookies My little sister and me baked for him .

#### lelievre12

##### Well-Known Member
HBA Supporter
So that's what I'm going by - the amount of deflection of the wing is FAR less than would be imparted by the 3.8G, 4.4G or 6G loading that would have been imparted by testing, or that would be predicted by analysis. The tip didn't move a couple of inches at most with respect to the root - that's a pretty low loading. Remember, the airplane was not fixed at the wing root - any force at the wingtip would just move the whole plane, restricted only by the inertia of the rest of the plane, not a fixed cantilever end.
Yes agree. The moment of inertia is all that would have resisted the wing tip bang whereas my 'sand bag' analogy really applies to an evenly distributed load across the entire wing. Although a 3G-->6G sand bag loading will safely deflect the wing a lot more than a point impact tip load ever could.

A point loading at the wing tip is an ugly load that often results in bent wings seen usually in ground loops. In the case of my Cessna the wing failures are usually mid span just inboard of the ailerons where for some reason many cantilevered (195/337/210/177) Cessna's have a spar weakness. They rarely if ever fail at the root. Or the wing tip itself (which has no spar) is damaged. All this occurs at way less than 3G-->6G so point loadings are nasty. However with aluminum, all is nicely detectable with skin rippling etc. unlike carbon.

Despite above, I agree with you. Peter's spar is probably just fine in that the impact point was actually not the weakest 'tip' like a conventional aircraft. With a canard that position is much further along the spar at the tip of the winglet. And so the structure at the Raptor impact point is going to be a heck of a lot more beefy than a Cessna tip. Peter's impact point is actually mid span when the winglet is considered as part of the wing. A canard 'wing tip' is where the spar is substantial. Combined with only a light roll inertia resisting the impact = not likely to exceed the carbon UTS at all.

And the smooth pavement really would have resulted in a scrape not a bang. Had it occurred statically in the hangar, say by a gear collapse there would be little issue. So the 'dynamic' impact really doesn't add much in this case unlike what a soft field could have.

#### berridos

##### Well-Known Member
The fence didnt looked crushed. From my point of view the fence showed abrasion and only to half of its depth. That wingtip touch was irrelevant from my point of view.

#### Geraldc

##### Well-Known Member
The wing fence rubbed the pavement.
The wing itself did not hit anything.There does not appear to be any damage above the scrape mark.
Case closed.
Edit further proof .Two people on opposite sides of the world posted the same thing at exactly the same time.

#### Rataplan

##### Active Member
The wing fence rubbed the pavement.
The wing itself did not hit anything.There does not appear to be any damage above the scrape mark.
Case closed.
Edit further proof .Two people on opposite sides of the world posted the same thing at exactly the same time.
View attachment 107556
As engineer I think your post is the most ridicules post of 2021.

#### Geraldc

##### Well-Known Member
As engineer I think your post is the most ridicules post of 2021.
I see you have been on this site for 2 days.
There have been 1637 posts on this topic and 7658 previous posts on Raptor.
If you are giving out prizes read them first.

#### Mike0101

##### Active Member
HBA Supporter
So I think I understand where the disconnect is...

So need to revisit the multi-processor approach. Lets stick with main processor and I/O co-processor for now. The I/O co-processors handles synchronous events such as injectors and spark (SI example), based on crank angle.
When ECU starts up, let's say a very simplified of the following happens;
* Main processor starts and performs what ever it needs to in-order to be in a valid and safe running state.
* Main processor then goes and initializes I/O co-processor with appropriate configuration and tells it to "Run".
* Presumably main processor goes back and verifies I/O co-processor is running and everything is valid or no faults present.
* At this time if above is true, it can write "Initial Values" to co-processor, such as a "safe" ignition timing value(s). As an example 5 degrees of advance can be written. NOTE, 5 degrees is being commanded, but engine is not running or cranking. AND may be displayed on scanning tool/software (I'd want to see it).
* I/O co-processor has decoded cranking engine crank/cam and now immediately fires spark(s) at pre-configured angle.

What makes above relevant is - when co-processor correctly decodes crank and cam and is correctly resolving crank angle in degree or rotation, it "can" then fire spark instantly. Why would you fire off spark before adding fuel? Clear a flood, someone squirted in fuel or starting fluid, many reasons...

* Main processor is checking/polling co-processor to see if it has detected motion (crank is turning).
* Main processor sees crank angle resolving and then writes any other variables required such as injector pulse width and updates spark to appropriate value(s).

Above is obviously drastically oversimplified. In short I/O co-prrocessor handles critical events in a robust, deterministic and very repeatable manner. The main processor does the heavy lifting. The two are loosely coupled, therefore allowing main processor to run more complex code with an OS (operating system) without imposing large interrupt latency hits (again oversimplified). Or what needs to happen no mater what is handled by co-processor, variables can be pre-written, updated as required, and both do there own thing. It's a big departure from single processor super loop of days gone by.

The thing is you don't need any of this (over) complication to make an aviation engine or automotive race one run well. The CPU operates much faster than the relative glacial pace that mechanical events in the engine occur at. The proof is that SDS is on the fastest EFI equipped vehicle in the world- Andrew Findlay's 2 time Reno winning Lancair- over 430 mph on telemetry. This engine runs on the ragged edge of destruction, so it's a challenging environment.
Again Congrats.

For MAP, you simply take multiple samples in software and average them before the injection event. Crank angle doesn't need to be considered.
Lets agree to disagree. I'm in crank angle camp.

You are coming back to justifying these display errors here. There is zero fuel flow and airflow with the engine not running- period, end of story. To display anything other than zero is erroneous.
Again, lets agree to disagree. Refer to my ignition advance example above.

Typically with throttle closed (SI), we shut off the fuel in automotive applications so there is no fueling to worry about there. With a throttle plate, we don't care what upstream pressure is because that's separated from the engine and the MAP sensor anyway.
You lost me.

SDS displays all sensor inputs, engine running or not but they all read correctly at least. Why wouldn't MoTec?
So does the Motec. All analog inputs are sampled, run through transfer function and updated, regardless of engine state. They may change sampling trigger(s), but run all the time.

The 20mg fuel that was observed is NOT an analog input. It is some sort on offset, very likely created by PM. It could be a MINIMUM fuel to inject per event/cylinder.

MoTec makes some of the best ECUs around, no argument there, but you simply need the AFR and spark timing to be correct- period. We've run SR20 race engines back to back on the dyno, SDS vs. MoTec and the result was no difference in power.

Peter's fiddling may have resulted in this FF display error. I certainly don't know enough about MoTec to say but at least with SDS, the user cannot manipulate anything with programming to have FF display anything other than 0 with the engine not running, so I'd say that's something in the MoTec architecture which could be addressed.
I get it, you own SDS, congrats. That 20mg really bugs you... it is not measured fuel flow, it is not trying to turn on injector, it is some offset that got baked in (very likely by PM to get air conditioning running without an engine stall, ie minumum injector mass flow per shot or who knows). I turn my home heating/cooling electronic thermostat to off position, it's setpoint is 72 degrees F, by your logic that 72 degree setpoint should disappear or not be displayed???

Last edited:

#### tsap

##### New Member
So I think I understand where the disconnect is...

So need to revisit the multi-processor approach. Lets stick with main processor and I/O co-processor for now. The I/O co-processors handles synchronous events such as injectors and spark (SI example), based on crank angle.

(many words deleted)
As someone who has written embedded control software, I think you've missed the point badly.

The objections raised by rv6ejguy cannot be answered by jumbled long-winded explanations of how you think the Motec ECU software might utilize multiple cores. If its behavior is wrong, it's flawed software regardless of how many cores it runs on.

It may or may not be true that the flaw is related to the use of multiple cores. Doesn't matter. Even if (as you end with) it's just a case of reporting the fuel flow setpoint, if it's doing that and displaying it as the indicated current fuel flow even when the true flow is 0, that's still a flaw.

#### Rataplan

##### Active Member
I see you have been on this site for 2 days.
There have been 1637 posts on this topic and 7658 previous posts on Raptor.
If you are giving out prizes read them first.
I see you have been on this site for 2 days.
There have been 1637 posts on this topic and 7658 previous posts on Raptor.
If you are giving out prizes read them first.
Well I follow the raptor soap some years, not just two days, I just joined this forum because there are a lot of serious people like rv6ejguy and others here with real experience and expertise I learn a lot from as, especially in aviation, you are never too old to learn .
If you have followed this raptor soap for 7658 posts and several years, you should have noticed that what the serious people here with real knowledge and expertise predicted some years ago was right.

(Fatal) crashes in self designed home build aircraft due technical failure are in most cases a result of a builder with a mentality which does not fit save aviation .