• Morning Jan

    Couldn't find an obvious error so decided to re-write the UHF code from scratch and it now works. Obviously a bracket, spelling or dot thing going on but I couldn't see it.

    UHF radio is there because users will want to see the numbers going round, it makes them think we have UHF. I had planned for numerical displays but try as I might I couldn't get them to show, no errors in the sim just no display, perhaps an electrical thing going on there. Will need to correct this as I hope to have the TANS displays working one day.

    Saitek Panels.....=O, not even added Sender stuff yet.. Already have NAV1, COM1 and now UHF1. Will the introduction of UHF 1 interfere with COM1

    Thanks again

    Steve

  • no, UHF won't be recognized by the panel... So the frequency tuning will be limited to Cockpit only

  • HI Jan

    Would you be so kind as to look at the coding in the zip file.

    It's simply rotating knobs. One works the other doesn't yet it's the same code. I have tried various control messages but still the same error, the UHF knob refuses to work ( no sound or knob movement) If I link the graphics to the VHF output both knobs move simultaneously. I also tried the knob next to the VHF (TAC1) and its the same problem. The selctor below works fine

    As there are 3 of these boxes and the smaller ones below I really need this to work, not that they will do much but users like to see knobs and switches move

    Many Thanks

    Steve

  • Hi Steve, I looked at your your code and couldn't spot any mistake. Are you sure you are editing the correct tmd and controls files and not one from the intermediate directory and the other from the aircraft directory?

    Are there any tm.log errors?

    If you swap the order of the knobs in the tmd and controls, is there any difference? (If yes it might indicate a missing bracket)

  • Hi Jan

    Thanks for looking though the code. A bracket count on both TMD files shows no problems. I always edit the live TMD's

    Strange thing is, I used the same code for the pilots and Pax comm boxes, changing names and locations, and it all works perfectly. So I copied this code back to the co-pilots box and the same 4 knobs still refuse to work. It's like there is a black hole in the cockpit where things just stop. Any one seen a towel .....

    Steve

    They started working.........Didn't adjust anything....they just started when I sat in pilots seat =O

    Edited once, last by larrylynx (April 12, 2019 at 1:25 AM).

  • Hi Jan

    I need to input groundspeed and drift angle to a gauge.

    I can see PitotTube.GroundSpeed and both PitotTube.WindSpeed plus PitotTube.WindDirection as outputs in the Q400. Is It ok to use these as they stand or do I need to do anything else.

    Of course I can't test anything as I am still awaiting shipment of my engines. Will they be based on the q400 ?

    Steve

  • For the drift angle you should probably use the flight path vector outputs.

    But does the display show the actual drift angle between heading and ground track or does it only show the side slip angle as measured from a beta angle vane?

    We developed a modular engine system which is currently not yet added to the release version of the q400, so no the engines will be a bit different but not completely of course.

  • Hi Jan

    To be honest we vary rarely used the drift gauge, perhaps at night to aid with a high hover it would have been more use to Navy pilots.

    The gauge receives it's info from, pitot pressure and static, plus a doppler based measuring system. It was only effective at bank angles less that 20 degrees as the doppler would go into memory mode (most of the time for us). The only time we ever did less than 20 degrees of bank was probably hovering, more like 50 to 70 was the norm.

    I would guess that depending on the selection in the TANS (Tactical Air Navigation System) it would be a mixture of both. From memory I think the knots readout also does backward and sideways component flying

    Steve

  • Hi Jan

    Whats the difference between

    <[float64][RotationSpeed][2090.0]>

    <[float64][DesignRotationSpeed][3927.0]>

    <[float64][DesignRotationSpeed][3927.0]>

    They all refer to the HP spool.. Top one refers directly to the HP Spool and the middle one refers to the turbo_compressor and the bottom one to the turbo_turbine

    As they all refer to the same shaft I would have thought the HP Spool would be the same number as the other 2

    Thanks

    Steve

    • Official Post

    RotationSpeed is the speed at which the shaft spins at the beginning of the simulation (initial rotation speed)

    DesignRotationSpeed is exactly that - the speed at which the compressor or turbine are designed to work at, a.k.a. 100% N1 in rad/s (in this case 100% N1 is defined as 37500 RPM = 3927.0 rad/s)


    That design parameter changes the efficiency of the compressor or turbine at off-design points, or put in other words: the maximum efficiency is reached at that design rotation speed.

  • Hi jan

    I have a 2 fuel collector tanks (left and right) which have inputs from their main tanks (left and right for each tank) and a forward tank which supplies both collector tanks through on/off switches ( easily left off as I know through experience :rolleyes:)

    Is it possible to add forward fuel to each collector from the single tank or would it be easier to cheat and add a left and right forward tank. Also, can the collector tank have more than one input in the tank entry similar to a fuel line connection, ie 2 pressures and 2 add flow or do we need to add a fuel line connection somewhere into the mix even though the tank itself doesn't really have one

    I have also noted that you use new entries in the tank section

    <[float64][MassFull][193.0]>

    old entries used to be

    <[float64][MaximumQuantity][377.0]>

    Are these interchangeable

    Steve

    Edited once, last by larrylynx: Added further question (May 16, 2019 at 1:12 PM).

    • Official Post

    Hi Steve,

    MassFull is the new name for MaximumQuantity, the latter will be removed at some point. They both control the internal MassFull varibale, I just left the old name in so that the user aircraft won't crash right away but they will eventually crash if they don's switch to MassFull (just not yet).

    To mix multiple fuel inputs for a tank you should use the fuel_line and just keep adding fuel onto it. The fuel collector tank is then just connected to the fuel line. But: this is not working 100% consistently, so you can overfill the collector tank and it will happily void some of the fuel (simulated as if it would overflow through the fuel vents). I wouldn't put too much effort into this, rather keep it simple because we plan on overhauling the entire fuel system which will break yours. So don't spend to much time here, it will change at some point.


    I would do sth like this: two fuel tanks, two fuel lines connected to those and those two lines connected for cross feed, then, from each fuel line, run a pump to the engine fuel line - done. Leave the collector tanks away for now.

  • HI jan

    Is it ok to renumber the engine stations. I have renumbered from 2 to 8 to be in line with the diagram I am using. no other reason but wondering if the sim expects the numbers you have in the Q400

    Also after 100 second's the sim reloads the aircraft. The ITT seems to be running away so I'm assuming at this stage its reaching a maximum value and the sim re-loads, everything else is running down ? . Only guessing at the moment. No problems reported in the TM.log, just a reposition and settling as normal.

    How can I make the aircraft load with the engines shut down. I tried to change the rotation speed to 0.0 but this just froze the aircraft, sim still running as I could esc out to the aircraft load screen no problems.

    Thanks, Steve

    Edited 2 times, last by larrylynx (May 17, 2019 at 2:12 PM).

  • Hi jan

    Quick update as I answered most of my problems

    Changing Station numbers seem to be ok, I just needed to make sure to re-number them correctly. I had 2 combustion (burner) numbers the wrong way round causing the burner to self feed, so the ITT kept climbing. Although the engine loads as running it shuts down immediately as all the switches are set for cold and dark. So would still like to load the engine in a shut down state.

    Sim still resets after 100 seconds so more investigation needed

    Steve

    • Official Post

    Hi Steve,

    try initializing the speed at 0.1 or so, small but non-zero, this should help.

    The numbering we use follows the international agrees standard for turbo engines but you can rename the objects as you wish.

    What actually matters is how you connect the components, e.g. hook up the compressor between stations 2 and 3 (or what ever name you give them), etc.

    I've never seen the ITT running away, maybe you have some internal connections not set up correctly? E.g. if one component adds mass flow to the wrong station or gets values from the wrong station you could get a lot of unwanted side effects. (Essentially violating actio=reactio)

  • Hi Jan

    Yet more questions.

    I have fully working engines and a fuel system that behaves itself. Electrics are mostly there too, yep. I'm shocked too =O

    Could you explain the entries in the fuel controller please, pretty please :)

    Are engine values fixed or do the entries above cause things like ITT values to alter. Main reason for this is gauges are reading different values from monitored values, so is it just down to mapping or a combination of both.

    I have found it necessary to have a condition lever, after many hours of the engines refusing to start I un-commented this and boom, the engine burst into life. Heli's don't have a condition lever, hence why I left it out, so I linked it to the throttle mapping for now. Of course output is a magical mystery tour for the moment as I don't have a rotor system till you let me see the heli TMD setup. I have linked it to a prop with a small mass (1.0) for now. This was causing the 102 second reset, it didn't like the c90gtx mass (50.0) for some reason

    Also, there is a pronounced ITT jump of 400 degrees plus during engine start, pretty much an instant jump, and then it settles back. This doesn't seem natural and not something I have ever witness in real life. Yes I know combustion takes place but real life gauges never jump like this, it's a lot more controlled so can this be tamed down

    Many Thanks, Steve

    • Official Post

    Hi Steve,

    Fuel Controller

    here are all properties that are available currently:

    The FuelFlowLowIdle, Maximum control the fuel flow range (in kg/s) which are basically the hard limits for your low ground idle (where the engine can run without assistance and your full power (which melts your engine).

    PFuelFlowNH is a constant that defines how much fuel is to be added per target NH increase, that is roughly: (fuel_max - fuel_idle) / (nh_max - nh_idle) - more means the engine will add a lot of fuel to accelerate up to target nh and less means not burning up in flames.

    PFuelFlowThrottle is a feed forward control from the InputThrottle, that's like how much fuel goes in - can be tuned via throttle map

    FuelFlowLightUpFlat controls how much fuel is injected for the first part of the engine start - that fuel should be enough to stabilize the flames but shouldn't flood the engine at such low speeds - NHLightUpFlatEnd is defines the NH at which the controller switches to NH governing mode. The NH start is when you manually introduce fuel but you could just use a logic_greater NH > some value to change your condition lever input.

    NHTarget is the target rotation speed at the start of the simulation, needed because internally the FADEC ramps the target up and down slowly.

    NHRating is the maximum takeoff power core rotation speed, which could be 1.07 or 107% or 1.04 (104% NH)

    ThrottleMap is a mapping from your throttle input to a fraction between NHIdle and NHRating, for input 0.5 that mapping above returns the half way point between idle and rating. So basically nh_target = nh_idle * ( 1.0 - mapping_value ) + nh_rating * mapping_value. This is very useful because the actual thrust or power curve of the engine tends to be non-linear, this would be a way to counter that and could artificially increase the target NH early so that you have 50% thrust or power for 50% throttle input. Normally this would not be the case because the engine components get more efficient for higher power settings (towards their design power setting).

    The condition lever has a cut off range from 0.0 to about 0.1 I think and above that it goes from low idle target to high idle target (which you can adjust if you need) - you can think of that as your engine start/stop switch if your helicopter has that, if not - it probably has a cut off switch, then use that.

    ITT

    Yes the ITT rises nearly instantly, this is realistic in a sense that the actual ITT follows very close to the fuel flow, if you burn more fuel you heat up the gases very quickly. What you have experienced in the real world is the time delay caused by the heat transfer within the ITT probe. You can't directly measure the temperatures, your probes would melt, so you use other methods with metal parts that don't melt, but those need to get hot first before you can see an ITT increase.

    If you want to see your ITT increase slower you can use a first order delay:

    Code
                <[first_order_low_pass][EngineTOT][]
                    <[string8][Input][EngineStation45.OutputTotalTemperature]>
                    <[float64][TimeConstant][3.0]>
                    <[string8][Value][755.8]>
                >

    This simulates the probe heating up and your indicated turbine temperature becomes slower.


    Generally speaking this is how our engine stimulation works:

    Each turbo component simulates the thermodynamic process of that part with compressor maps, turbine maps, efficiency coefficients, etc. etc. These parts together create what we call an engine. Currently the only place we can adjust is the fuel flow, but we might add stuff like reverser flaps, mach inlets, variable stator vanes, bleed air extraction, etc. And we have connections to the outside using gear boxes to the core shaft and also the power turbine shaft. Those connections are necessary for the generators and starters.

    The fuel flow that we add to the combustion chamber is in kg/s and it can either be controlled fully manually if you create some form of mapping from the throttle lever or it can be fed through the simple fuel_controller, which is pretty stupid on its own, or it can be generated by the FADEC which can have more complex, fully digital control loops.

    So far we have only implemented a few FADECs specifically for that particular engine (see q400) but I think when we add more FADECs for the turbofans for example, we might create a more generic FADEC which can handle a certain engine category (e.g. twin spool high bypass turbofans or an afterburning jet fighter engine or maybe even a helicopter one with rotor speed governing, etc.)

    What I love about this

    The problems that you will encounter with controlling the engine are actually really similar to real world problems. It helps me better understand the physics behind real world engines.