Jump to content

flightace37

Members
  • Posts

    116
  • Joined

  • Last visited

Posts posted by flightace37

  1. Not sure if the fuel weight is accounted for yet but I notice a lot of people hardly ever switch tanks. result...imbalance wonky aircraft

     

    Definitely modeled. Make sure to drain a few gallons off the left main tank to make room for fuel return, then switch to burning your auxiliary (fuselage) tank down. After that, keep alternating between the L/R main tanks.

  2. Definitely set RPM to be consistent across the entire formation, and jockey with power. The real ticket is fine adjustments. Keep your aircraft trimmed and your control movements small (including throttle). Don't forget to whine at lead if he's not giving you enough to play with, especially when you have members who are new to formation work.

     

    When my squad is up for formation flights in a prop sim, we have lead call RPM changes a few seconds in advance, to give the flight time to adjust. We rarely call manifold pressure, except to get people in the ballpark when they're joining up. There's just not much point in cluttering the radio with the latter, since everyone is going to be running slightly different power settings anyway.

  3. Work in Progress.

     

    The engine definitely has issues running in cold weather at the moment. I have a number of missions set fairly cold (8*C), and run into random sputtering from time to time. I think you can avoid the problem by keeping your missions above 15*C.

  4. The mission editor works. User-made missions are normally stored in ~/Saved Games/DCS/Missions.

     

    When you open a mission, you'll need to choose from the My Missions or System Missions set. There's also other options, like aircraft-specific missions.

  5. The flight manual reccomends 46" manifold @ 2700 RPM for cruise I believe. Would be a good starting point for you tests. Then you have to account for the supercharger kicking up over 12k feet also.

     

    46" and 2700 is the maximum continuous setting. Max cruise is 36" and 2400. These limits are posted in the manual, and on a plate in the cockpit. The real training manual contains several pages of charts describing expected speeds, fuel consumption, and range for various power settings.

     

    The supercharger can kick in over a very wide range, and the specific point depends upon power settings and outside conditions. I think 12k is a little bit low, and believe the range settles between 14,000 and 19,500 ft. You'll want to double-check those figures. The real values should be in the book.

  6. Edit-sniped again.

     

    Yes, sobek. I strongly believe the coil is fed directly from the 28.5V bus. The diagram on pp. 331 clearly states that is the case.

     

    Edit: I'm going to bed. I'll see if there are any more posts (or edits) here tomorrow. ><

     

    And Edit again: 28.5V bus, not battery.

     

    Edit: Unless that's a battery symbol near the bottom of the right switch panel "box" in the diagram. I think we've determined that the booster coil is not fed from the ignition switch, at least. And... bed time.

  7. From what material I could find on Google, the booster coil essentially sits there and builds up charge through magnetic induction until it is grounded. At that point, it discharges very rapidly, providing enough voltage for a spark.

     

    It still has to be connected to the spark plug through the RH mag to prevent early spark.

     

    With regards to the behavior effte witnessed in his tests, and given the electrical diagram clearly showing the coil wired to the RH mag, I think the only way that the coil could be prevented from generating a spark would be if the magneto somehow included a relay that opens the circuit from the coil unless there is power from the ignition switch.

     

    That seems like a silly thing to do, especially given that the pilot could then just run the starter motor with the ignition off until the booster coil fails in spectacular fashion (ie, boom). It is far more likely that the design is simple, with both the booster coil and ignition hooked directly to one side of the magneto (together), and the spark plug hooked up to the other.

     

    EDIT: Yeesh, lot of out of date edits going on tonight. I'm absolutely loving this discussion though.

  8. Yeah. I mis-read that figure. It's showing how to hook up the booster coil for testing. I didn't see how it could avoid being wired to the RH mag either.

     

    So the the thing is, even with the ignition switch set to Off, according to the two diagrams (pp 330 and 331 like effte said), the booster coil is connected to the RH mag. Whenever the starter motor is actuating, the booster coil is also actuating. Wouldn't you expect to see current through the RH mag? It has two inputs: one from the ignition switch, and one from the booster coil. The electrons just flow to ground from either of those.

     

    Basically, the diagram on pp. 331 says that the booster coil gets current any time the starter switch is held down. The one on page 330, to me, says that the booster is hooked directly to the RH mag, in parallel with the ignition system. For it to cut out when the ignition switch is off, the booster coil would have to somehow get it its electrons through the ignition switch, but it gets them straight through the starter switch.

     

    Side-note: The right-hand magneto is the only one that actually provides ignition spark. The manual says the left-hand mag provides exhaust spark... Sounds a little strange to me, but there it is.

  9. Maybe this kind of diagram presumes notation conventions that i am unfamiliar with, but i have to say that i can't draw a definitive conclusion from that.

     

    It's tough, and I'm not 100% on it either. Take a look at the earlier pages describing the ignition system, and you'll see a drawing that shows the high tension lead from the booster coil literally being wrapped around the lead of a spark plug, with power for the booster coil coming straight from the switch.

     

    And the diagram probably presumes conventions from more than 60 years ago... I imagine there's been some change in that time. :\

  10. The dummy is more interested in filming a tree, but you can see some a/c and rudder movement.

     

    Couldn't see a thing with all the bouncing and panning that guy was doing with the camera. All I want to do now is take a torch to that tree. Oh well.

     

    We did get a nice look at the tail wheel. I think it moved around a little bit with all the vibrations, but never actually flipped around towards the front of the aircraft like it does consistently in our sim, nor does it auto-center without the aircraft in motion. There's a little bit of work to be done in that case, but we need to be patient with the devs.

     

    Thanks for the video!

  11. However - finding time to implement such a feature is another matter - it would require implementing a new GUI interface within DCS.exe too.

     

    Time is always the problem anywhere you go, and I imagine ED has much bigger fish to fry with its resources.

     

    I personally would like to see reintegration of the GUI and Simulator - however that would cut off 32bit users.

     

    I took a look at the DCS World Launcher.exe and found that it consumes about 380MB of memory right off the bat. Is most of that from the mission editor? I know you guys don't have time to do it right now, but if you did commit to reintegration and still wanted to retain 32-bit users, would separating the M.E. cut enough fat to bring the rest of the Launcher.exe functionality back in?

     

    I'm just throwing ideas out there, but you probably already looked at most of them when you made the decision to split the game up in the first place.

     

    There's also the possibility of asking 32-bit users to enable Windows features to open up more user-mode memory. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx. That is probably impractical though, given the nature of it.

     

    Of course, then you get into all the re-work that has to be done to support the larger address space, and you may as well do lots of other things to make it work within the 2GB limit, like going completely overboard with dynamic loading. Painful and time consuming. :doh:

  12. Effte, that is actually not true. The effect of caster angle (whether in an arrangement like a bike, or a shopping cart caster) is to cause the contact patch of the wheel to trail behind the intersection of the pivot axis and the ground. Sideslip friction (for lack of a better term) on the wheel while the object is in forward motion is what causes it to return to center, not weight.

     

    I just went outside and ran an experiment on my bicycle to test this. I set the wheel at a moderate angle from center (yaw), and pushed down hard, with the bike sitting vertical. There was no centering tendency at all. Moving the bike forward (at moderate speed) keeps the wheel aligned due to sideslip forces. This is what allows some (crazy) people to ride hands-off without having the wheel flip all over the place on them.

     

    If that's not enough, think about a shopping cart wheel. With the cart sitting on flat ground, rotate the wheel with your foot. It doesn't try to return to the original alignment; it just sits there. The same is true with rake/negative caster on a bike. The contact patch offset is just created using a different method.

     

     

    Now let's move on to the specific arrangement on the P-51. If you examine the tail wheel assembly closely, you'll find it looks something like this:

     

    *
    *
    *
     *
       *
         *
         wheel
    

     

    This is the exact design of a shopping cart caster, with all of the same properties. With the pivot axis perfectly perpendicular to the ground, there will be no torque applied unless the vehicle is in motion. The trouble comes when the pivot axis is not aligned perpendicular to the ground. This introduces a compounded problem. (You can call it caster of something that is castered, if you like; I don't know if there's a specific term for it, or if that description is even valid.)

     

    With this additional tilt, the wheel will tend to self-center when weight is applied because CG height is now a function of wheel yaw angle. The things you describe in your most recent post apply.

     

    If you rotate that diagram a few degrees counter-clockwise and then imagine applying weight straight down, the wheel will tend to flip towards the right, placing the weight closest to the ground. Imagine tilting it clockwise now. The wheel will tend to flip to the left for the same reasons.

     

    We seem to agree on the basic concept here, but it is not the angle of the actual pivot axis alone that is causing the tail wheel to flip. It's a combination of the displacement of the wheel from the pivot axis's contact point with the ground (which creates a caster angle), and the angle of the pivot axis itself (which would be caster angle if the wheel was directly in line with the pivot axis). I'm sure you'll agree with that assessment.

     

    So, given what we are seeing in the simulator, I think it's safe to assume that the pivot axis is modeled to be vertical when the aircraft is strictly horizontal. The problem is the aircraft is not horizontal while sitting on the ground. If we think about the aircraft in the same "diagram" that I made above, with the propeller on the left side, and the tail on the right, we can see that the pivot axis would be tilted clockwise. This causes the tail wheel to flip around to the left.

     

    The question that needs answering then, is whether this design is correct or not. I can't imagine that to be the case, because it would have caused endless ground handling pains. The optimum design would ensure that the pivot axis is perfectly vertical when the tail wheel is in contact with the ground. When the aircraft moves, the wheel would swing to trail behind in the direction of motion, without having to fight a centering force caused by weight and this compounded caster mess.

     

    I think I derailed my own topic, and it looks like we may be fighting over confusion of terminology, Effte. Unless you see a flaw in this analysis, what's say we call it quits?

  13. If you bang that video up to 1080 & fullscreen it, then watch the wheels as the rudder moves, don't you think it does squirm a little bit ?

     

     

    (Edit : beaten to the punch badly while reading... )

     

    Indeed. I wasn't sure if it was a trick of my imagination or not, but that's at least two other people who have confirmed my observation so far. With regards to your edit, "Don'tcha love forums?"

     

    I continue to be impressed with the detail of the flight model in this sim. What we need now to alleviate all the concerns about rudder authority is a video of a real Mustang wagging its tail like I did in this video. No need to risk the prop by lifting the tail off the ground. We just need to see rudder deflection in the prop wash. Even a relatively low-power civilian bird ought to be enough to demonstrate how pronounced the effect might be.

  14. My understanding of the throttle handle control lock, is that it functions as a friction lock, which will prevent the throttle handle from moving on its own, but still allow the pilot to move the throttle as needed.

     

    That is correct. How much you tighten the lock down determines the amount of friction. Unfortunately, the setting needed to prevent electrical noise from moving his throttle for him is also the setting needed to completely lock the throttle.

  15. This is an issue with the stability of the wheel on your stick. It's jumping around on you because of all the electrical noise coming from your computer. You can alleviate the issue by plugging into a powered USB hub instead. (It won't go away completely though).

     

    The throttle lock does exactly what it is designed to do: prevent the throttle from moving.

  16. Regarding power changes:

     

    Power was as constant as my physical throttle would allow (which is pretty darn good, being a CH Pro Throttle). The reason that the elevator wasn't having a very sudden effect is because I only applied enough power to barely get the tail off the ground at full deflection. If you watch carefully, you'll see that less deflection was required with the tail further up. That's something we would expect as the CG moves further towards the wheels.

     

     

    Regarding the rudder:

     

    Actually, I was doing some checks on ground rudder authority earlier yesterday. I turned the aircraft into a hockey puck by holding some directional brake and kicking the power up pretty high, then releasing brakes. Once spinning, I tried using the rudder to adjust the rate of rotation and it didn't do a thing. Only the brakes had any effect. It's true that the CG is aft of the wheels, but the rudder is still well on the outside, so it should have had some effect over the long term.

     

    Same results for both left and right spins, so it's not just a matter of engine torque completely overcoming the rudder. I think that it's either not modeled, or modeled very weakly. Whether or not weak modeling is realistic, I'll leave up to the people with tail dragger experience.

     

    @Viper: Cool. I'm not crazy then.

     

     

    On another topic:

     

    The tail wheel has a severe tendency to flip around when unlocked. Even with the brakes held, it flips around the wrong way under the weight of the aircraft, and stabilizes in that position. I think that the caster behavior might actually be modeled backwards.

     

    EDIT: Thinking about that a little more, caster effect does require forward motion of the airframe. The real question is how the weight of the aircraft will affect the wheel, given the design. Does the tail sit lower to the ground with the wheel forward, or backwards? Does the wheel produce enough static friction to prevent it from moving?

×
×
  • Create New...