Create FG1000 panel variant

[wlbragg]

I hope there isn't already an issue for this. I couldn't figure out how to effectively search through the existing issues.

Because glass is now the future of aircraft, I think we need a glass variant. I did the PA-18 and it really wasn't that difficult to retrofit it. We could do the same thing with our flagship and probably should. I think it would have to be done the same way as I did the PA-18 and it would have to have it's own set file and that would be the only way to access it. Not on the fly like the gear and engine changes. It's too heavy and cause the other PA-18 variants to lag even when in the background.

What I think is needed most for this is just some good cockpit reference material the matches our c172p model as best we can find. This winter when I'm holed up maybe I can start on this with a little help here and there.

[wlbragg]

I need pictures of the twin front dome lights and the back passenger dome light, also showing their positions. Also the LED lighting of...

Pedestal lighting consists of a LED strip light incorporated into the Throttle/Flap Control Lever panel located on the bottom of the center instrument panel and a second LED strip light incorporated into the pedestal directly above the 12 volt cabin power outlet.

Basically all of the following...

Interior lighting is controlled by a combination of dimmable crew area flood lighting, internally lit switch and circuit breaker panels, avionics panel lighting, standby instrument lighting, pedestal lighting, pilot control wheel map lighting and passenger area flood lighting.

[wlbragg]

@stuartbuchanan Does the GFC700 logic have any power source logic for something like a breaker? This aircraft has a breaker direct to the autopilot power. I'm looking for that connection if there is one. Otherwise I guess I need to use something like the AP/GA switch? Also, did you do any kind of "Annunciation Window" and supporting system? If not any plans to? I would consider designing it but would want to follow your design strategy using canvas, which I am not all that familiar with. Maybe even if you could set up the framework I could fill in the mundane data and triggers for it?

@tonghuix Can you tell me how that works? If you switch of the breaker, what exactly happens to the AP? Does it show anything in the PFD or does it just take down the mechanical hardware?

If it is hardware only and If the logic isn't there maybe we could simulate it by conditioning whether we can use any of the control filters basses on electricity (breaker)?

[wlbragg]

I've done a little investigating and discovered the following. The load on the buses are wrong in as much as any load that isn't conditioned on a switch as well as the breaker is not correct. Such as...

    if ( getprop("/controls/circuit-breakers/flaps") ) {
        setprop("/systems/electrical/outputs/flaps", bus_volts);
        load += bus_volts / 57;
    } else {
        setprop("/systems/electrical/outputs/flaps", 0.0);
    }

    # Pitot Heat Power
    if ( getprop("/controls/anti-ice/pitot-heat" ) ) {
        setprop("/systems/electrical/outputs/pitot-heat", bus_volts);
        load += bus_volts / 28;
    } else {
        setprop("/systems/electrical/outputs/pitot-heat", 0.0);
    }
    # Interior lights
    if ( getprop("/controls/circuit-breakers/intlt") ) {
        setprop("/systems/electrical/outputs/instrument-lights", bus_volts);
        setprop("/systems/electrical/outputs/cabin-lights", bus_volts);
        load += bus_volts / 57;
    } else {
        setprop("/systems/electrical/outputs/instrument-lights", 0.0);
        setprop("/systems/electrical/outputs/cabin-lights", 0.0);
    }

    # Gear Select Power
    if ( getprop("/controls/circuit-breakers/gear-select") ) {
        setprop("/systems/electrical/outputs/gear-select", bus_volts);
        load += bus_volts / 5;
    } else {
        setprop("/systems/electrical/outputs/gear-select", 0.0);
    }

    # Gear Advisory Power
    if ( getprop("/controls/circuit-breakers/gear-advisory") ) {
        setprop("/systems/electrical/outputs/gear-advisory", bus_volts);
        load += bus_volts / 2;
    } else {
        setprop("/systems/electrical/outputs/gear-advisory", 0.0);
    }

    # Hydraulic Pump Power
    if ( getprop("/controls/circuit-breakers/hydraulic-pump") ) {
        setprop("/systems/electrical/outputs/hydraulic-pump", bus_volts);
        load += bus_volts / 40;
    } else {
        setprop("/systems/electrical/outputs/hydraulic-pump", 0.0);
    }

and if the master avi switch is set then a total avi load is calculated regardless of whether or not the device is turned on. Its all thrown at it with...

load += bus_volts / 20.0;

So this all need to be fixed in the default electrical as well as I am correcting all of this in the fg1000 electrical system.

[wlbragg]

Also, does anyone know anything about this?

    # Air-cond
    if ( getprop("/controls/circuit-breakers/aircond-pwr") ) {
        setprop("/systems/electrical/outputs/aircond", bus_volts);
        load += bus_volts / 57;
    } else {
        setprop("/systems/electrical/outputs/aircond", 0.0);
    }

and we set it to true if we haven't selected to "save switch state". That starts a draw for it.

        setprop("/controls/circuit-breakers/aircond", 1);

I know we have a blank breaker for this but it isn't being used and needs to be commented out?

I think I know why we use volt as the draw, it is becasue the failure break point is volts. At > 12 volts things fail. So the discharge logic for the battery is using volts. If someone wants to research this and come up with a more realistic or appropriate formula, it wouldn't be hard for me to convert this current voltage drain system to something more appropriate, or confirm this is the right way to do this?

[tonghuix]

For the Standby Battery switch, when you press to TEST position, the light will illuminate, note that the switch will spring back to OFF position if you don't press. So for pre-flight procedure, I have to set the switch to ARM position, and light will NOT illuminate. However anytime Standby Battery kicks in, the light will illuminate again. And ampere, I really don't know exactly number. Here is a quota from Pre-Flight procedure, note that why PFD is on because Main Battery not connected (Master switch off at this time), and Standby battery kicks in.

For the breakers, there is a breaker designated to GFC700 autopilot, so you maybe need another breaker for the AP. If you pull the breaker in flight, all connection will disconnected, because no electrical is provided to instruments and mechanical. I never test it in real flight.

[wlbragg]

so you maybe need another breaker for the AP. If you pull the breaker in flight, all connection will disconnected ... because no electrical is provided to instruments and mechanical. I never test it in real flight.

Right, I'm wanting to know if the PFD autopilot displays show anything when that breaker is pulled or if any annunciator window pops up? Or if the autopilot hardware just stops working?

[wlbragg]

Well, the electrical for the c172p is wrong. Needs some work. I'm fixing some of the easy stuff, but there is some more complicated changes that need to be made. I need a good electrical diagram for it.

[tonghuix]

Right, I'm wanting to know if the PFD autopilot displays show anything when that breaker is pulled or if any annunciator window pops up? Or if the autopilot hardware just stops working?

I never test pull the breaker out in real flight. Well, I found some videos for you:

GFC700 training: https://www.youtube.com/watch?v=TnOUxBdM2m4 G1000 Basic: https://www.youtube.com/watch?v=WsXxoqfaTFw G1000 Garmin Tutorial: https://www.youtube.com/watch?v=I0y6p0ct1m0

[tonghuix]

Well, the electrical for the c172p is wrong. Needs some work. I'm fixing some of the easy stuff, but there is some more complicated changes that need to be made. I need a good electrical diagram for it.

Note that, elec system for C172P and C172SP are totally different, here is the diagram for C172P:

[wlbragg]

Thank you for the diagram, I saw this one but didn't have a clear copy of it. Looking a little closer, our original electrical is really close to this. Especially once I change the conditionals of when to apply loads to the bus. It'll probably not really be noticeable, but it will be more accurate.

[tonghuix]

I pulled the FG1000 branch, but still six-pack instrument, how to enable FG1000?

[wlbragg]

You have to select the fg1000 variant at the start from the aircraft selection screen in the launcher.

[dany93]

I don't understand the logic behind the 'load' in nasal code in this message from @wlbragg.

When I read load += bus_volts / 57, what does 'load' means?

My preference (hypothetical guess) would be that 'load' is the current pulled by a system. Each time you activate one more system, its consumed power (Watts) is added to the previous one, and its current (amps) is added to the previous total intensity (=load?) from the others. The current (amps) is straightly additive in the upstream wires. The current value is the one which makes each breaker to switch to open (protection). Like a fuse. But this is not consistent with the nasal code such I understand (??) it.

From the well known electrical formula P = U*I, i.e. Power (W) = Voltage (V) * Intensity (A), I = P / U Not consistent with load = bus_volts / 57 for one system as written in the nasal code, if 'load' is the current. Notice that, to calculate the intensity (= load?) due to a system, you have to know its consumed power (in Watts). We should have I total = I1 + I2 + .... In = (P1 + P2 + .... Pn) / U (with U = 24 volts). At least for a given battery. Could it be that 57, 5, 40, 20, etc... would the pulled power, with mistakes in the formulas? With is hypothesis, the current pulled by flaps or interior lights would be 57 (W) / 24(V) = 2.375 (A). Equivalently, an instrument or apparatus 'consumption' can be given in amperes (by I = P / U = P / 24).

For me, in such a system management, the important criteria is the intensity. A breaker triggers OFF at its rated intensity. A 25 Ah battery can give 25 A during 1 hour, or 6.25 A during 4 hours.

Either something is wrong, or I understand nothing in the logic and the nasal code (I'm not very good in nasal).

[wlbragg]

OK, this is the battery Note: it suggests passing of "AMPS".

# Passing in positive amps means the battery will be discharged.
# Negative amps indicates a battery charge.
BatteryClass.new = func (x) {
    var obj = { parents : [BatteryClass],
      ideal_volts : 24.0,
      ideal_amps : 30.0,
      amp_hours : 3.1875,
      charge_percent : getprop("/systems/electrical/battery-charge-percent/"~x) or 1.0,
      charge_amps : 7.0 };
    setprop("/systems/electrical/battery-charge-percent/"~x, obj.charge_percent);
    return obj;
}

Note: the charge_percent, this is how this system keeps track of the available power in the battery. It is a percentage of ?.

This is the volts output function of the battery. it uses the charge_percent of the battery

# Return output volts based on percent charged.  Currently based on a simple
# polynomial percent charge vs. volts function.
BatteryClass.get_output_volts = func {
    var x = 1.0 - me.charge_percent;
    var tmp = -(3.0 * x - 1.0);
    var factor = (tmp*tmp*tmp*tmp*tmp + 32) / 32;
    return me.ideal_volts * factor;
}

and finally the output_amps function, again using the charge_percent value.

# Return output amps available.  This function is totally wrong and should be
# fixed at some point with a more sensible function based on charge percent.
# There is probably some physical limits to the number of instantaneous amps
# a battery can produce (cold cranking amps?)
BatteryClass.get_output_amps = func {
    var x = 1.0 - me.charge_percent;
    var tmp = -(3.0 * x - 1.0);
    var factor = (tmp*tmp*tmp*tmp*tmp + 32) / 32;
    return me.ideal_amps * factor;
}

the interface to the battery happens by adding up the load or draw of what, property amps or volts?.

    load += electrical_bus_1();
    load += electrical_bus_2();
    load += avionics_bus_1();
    load += avionics_bus_2();
    load += essential_bus();

then pass the load to the apply_load function

battery.apply_load(-battery.charge_amps, dt, "a");

here is the apply_load function

# Passing in positive amps means the battery will be discharged.
# Negative amps indicates a battery charge.
BatteryClass.apply_load = func (amps, dt, x) {
    var old_charge_percent = getprop("/systems/electrical/battery-charge-percent/"~x);

    if (getprop("/sim/freeze/replay-state"))
        return me.amp_hours * old_charge_percent;

    var amphrs_used = amps * dt / 3600.0;
    var percent_used = amphrs_used / me.amp_hours;

    var new_charge_percent = std.max(0.0, std.min(old_charge_percent - percent_used, 1.0));

    if (new_charge_percent < 0.1 and old_charge_percent >= 0.1)
        gui.popupTip("Warning: Low battery! Enable alternator or apply external power to recharge battery!", 10);
    me.charge_percent = new_charge_percent;
    setprop("/systems/electrical/battery-charge-percent/"~x, new_charge_percent);
    return me.amp_hours * new_charge_percent;
}

[wlbragg]

All I have really done so far is... 1) make the new buses conform to this existing system. 2) correct whether or not any single device tied to any single breaker is actually drawing power or not off this system at any given point in time. 3) added another battery to this system including the logic as to when it is in use. Note the new stby batt is using the same class as the main bat and that can't be right because i think it is a smaller battery with far less capacity. I would need to rewrite the class and add the ability to pass the initial, ideal_volts, ideal_amps and amp_hours. I already modified the class to track individual battery "charge_percent" independently. That was the minimum that had to be done.

[wlbragg]

So if we can come up with...

1) the correct formulas for drawing and charging 2) the correct values for the stby battery of ideal_volts, ideal_amps and amp_hours.

I can easily modify this.

[wlbragg]

@dany93 to answer this question

I don't understand the logic behind the 'load' in nasal code in this message from @wlbragg.

For example, this is how the flaps were configured...

    if ( getprop("/controls/circuit-breakers/flaps") ) {
        setprop("/systems/electrical/outputs/flaps", bus_volts);
        load += bus_volts / 57;
    } else {
        setprop("/systems/electrical/outputs/flaps", 0.0);
    }

So effectively, if the flaps breaker was closed and the bus was receiving power, then the draw on the battery was bus_volts / 57 at all times. It should also be conditioned on whether or not the flaps motor was actually in use. This one was a bit tough to figure out becasue flaps deployment uses a 4 step normalized value Flaps can be any of the following 0, .3333, .6666, 1. But when in operation it is anything between 0 and 1 but not any of those 4 values. I couldn't figure out any available property to monitor directly for the value that captures movement. So I wrote my own and included it in the breaker statement as follows. It is approximate and not perfect but way better than a constant draw of 57 just becasue it is on the bus. Basically it is draining 57 for 3 seconds every time the flaps lever is changed.

var old_flap_position = 0;
var current_flap_position = getprop("/surface-positions/flap-pos-norm");
...
    # Flaps 10 amp breaker
    if (getprop("/controls/circuit-breakers/flaps")) {
        setprop("/systems/electrical/outputs/flaps", bus_volts);
    } else {
        setprop("/systems/electrical/outputs/flaps", 0.0);
    }
    current_flap_position = getprop("/surface-positions/flap-pos-norm");
    if (current_flap_position != old_flap_position) {
        old_flap_position = current_flap_position;
        if (getprop("/systems/electrical/outputs/flaps") > 12) {
            load += bus_volts / 57;
            settimer(func(){
                load += bus_volts;
            }, 3);
        }
    }

I did that for the amphibious landing gear as well. There were other items like the avionics equipment that were drawing power even when they were off. All that logic is straitened out in both the default and fg1000 electrical systems, but not necessarily the correct values.

Now what I haven't done is check the new draw totals against any instruments (volts meter). That is something that needs testing, at some point, by those used to looking at and understanding these numbers.

[wlbragg]

Oh, and I must say, I have no idea how accurate our total drain on the battery is over time. I can tell you it still seems quit fast. If someone has time it would be interesting to test how long it takes to drain the battery with a small load of X value and compare it to real life known values. Maybe that all gets corrected if we figure out the correct formula for drawing down the battery.

I've still have a ton to do, audio panel, finish the stby batt test lamp illumination logic, fuel pump logic (in whatever form, ie: simple or complex), and other stuff I can't remember at the moment.

The most time consuming for me I think will be to learn and understand how all the avionics tie to the fg1000. Those connections may not be there or may require modification. Things like the old com-nav were on the same radio and used the same bus connection. Now it is is separate bus connections and how do I trip, say the nav breaker, and have that effect only the nav portion of the fg1000? Maybe @stuartbuchanan can shed some light on that portion.

[wlbragg]

OK, enough for everyone to filter through and see where I am at and how you all might be able to help sort some of this stuff out if you know or can find out. Find me the info and I will gladly put in the time required to do the work. The hard part is identifying and then conveying the issues that need researched and then how to resolve them.

[tonghuix]

I tested, the elec system is fantastic! But for G1000 it self, a lot of work should do, I think we should programing at FG1000 base code.

[wlbragg]

Absolutely, that is where I'm at. I think the base fg1000 code needs some hooks added to it. Although, I really haven't had the chance to learn how it all works, what does and what doesn't. When you come across issues with the fg1000 and how it interfaces to any of the equipment, please post it here so we have a list of issues to sort out.

[wlbragg]

Pushed some audio panel additions. I have all the buttons push-able with their indicator light illuminating. Created logic for... Com1 Mic Com2 Mic Com1 Com2 MKR Mute DME ADF Nav1 Nav2 I didn't really test anything except for the Com's logic so please let me know what is wrong and what the desired outcome should be when you find mistakes.

[dany93]

@dany93 wrote on 04 Nov 2020

Either something is wrong, or I understand nothing in the logic and the nasal code (I'm not very good in nasal). load += bus_volts / 57, Could it be that 57, 5, 40, 20, etc... would the pulled power, with mistakes in the formulas?

Now and with this, I understand that 57, 5, 40, 20, etc... is akin to a resistance, which gives a current (load) I = V / R.

[wlbragg]

Ah, OK, I'll take a look at that formula and see what its all about. I haven't looked yet but I am interested in getting a correct load reading in the PFD. I briefly read about where it was located in the PDF, but I don't know yet exactly what it is displaying, and definitely not the formula we need to get the value for the display nor if any of our current properties are correct for a tie to the PFD. Maybe I = V / R is the correct formula.

[wlbragg]

Pushed some audio panel additions. I have all the buttons push-able with their indicator light illuminating. Created logic for... Com1 Mic ... I didn't really test anything except for the Com's logic so please let me know what is wrong and what the desired outcome should be when you find mistakes.

I assume the Com'x Mic portion of the Audio Panel really doesn't do anything in the simulator as we don't have any transmission capability in the sim?

So I simply insure the com radio is turned on, turn the volume to 100, and then also activate the Com (receive) button to the right per the documentation. If you only select the Com (receive) button (right) then I also turn on the com radio and turn the volume to 100.

If anyone knows I'm wondering exactly how the com and nav radios work in the fg1000, are they always on? Does the Com button (rec, right button) just connect the radio to the speaker or headset and the volume is left at what? You have a volume knob on the PFD, does it retain the individual volumes for com1, com2, nav1, nav2, marker? Or is it the same volume for each? So a Com radio could be turned down and when you hit the Com (rec) button you still might not hear it becasue it is turned down on the PFD?

[wlbragg]

I discovered the FG1000 source comes with a audio panel (GMA1347). I looked for it initially but failed to see it so I built my own. The one Stuart made was only the base template and no ties to the actual equipment (as far as I noticed). So I decided to use the one I built because I had already done most of the work to tie it into the equipment and also the physical buttons are animated. None of the PFD, MFD or audio panel buttons on the fgdata supplied models has animated buttons. I would prefer to eventually animate those buttons and knobs, but I guess there was a reason Stuart didn't do that already? What a great bit of work by @stuartbuchanan though, hats off.

[wlbragg]

I'm looking at the 182 fuel pump and fuel system. It is going to be a big job to do it right and will require isolation same as the electrical was isolated.

[wlbragg]

FYI: A bug crept into non-fg1000 variants electrical system. I just fixed it and pushed the fix. The default electrical now tracks the load for all equipment. Total draw if everything is running can be as high as 320, the breaker trips at 330. I also fixed the electrical logic to track radio power and radio lighting independently. As I read the docs, the lighting on the radio is controlled by the radio lighting rheostat which is on a different breaker than the radio power (I'm referring to the default electrical system).

The Issue-1307 (compositor branch) is paralleling this work for anyone that is using the compositor.

There is an issue with the fg1000 EIS logic. I don't think @stuartbuchanan has done any more work on making it easy to localize custom EIS logic. I haven't completely finished researching what can be done to customize the EIS system. Right now it looks like we have to have any customizing files located in fgdata becasue of some of the core logic's path statement not having enough flexibility to call data from more than one location. But I think if it is accepted I could create a stand alone set of files that could be pushed to fgdata for the c172p. The EIS data that is problematic is the engine[0] VS engine[1] or active-engine. and now the customizable fuel system tank[0]tank[1] VS tank[2]/tank[3]. I was successful with custom files working in fgdata for the engine portion ~but not yet the fuel portion. Trying to change the class names for those files didn't work right out of the box, or I missed something~. This is currently slowing me down, trying to figure out a solution that doesn't involve fgdata. I don't se any way to get there without fgdata code revisions or placing the entire fg1000 code base in our local files which of course is not what we want.

@stuartbuchanan maybe you have a better solution or maybe I can help you with optimising the EIS code to allow for better customization. As I see it now I don't think you could "easily" support even a duel engine aircraft or an aircraft with multiple (more than 2) tanks.

[wlbragg]

If you want the EIS to work correctly, for now, when you download the branch you'll find four files in Nasal/Interfaces SelectableEISPublisher.nas SelectableFuelInterface.nas SelectableFuelPublisher.nas SelectableInterfaceController.nas

You will need to copy the files into the fgdata/Aircraft/Instruments-3d/FG1000/Nasal/Interfaces/ folder. The only thing I am still unsure of is exactly what the "Fuel QTY GAL" display on the EIS is actually supposed to be displaying. Is it actual gallons in the tank? Why then can you change it using the SYSTEM/RST FUEL/GAL REM/+/- GAL's?

Ah, now I think I know why some of this wasn't making sense to me. It looks like we're missing some data on the EIS. The LEAN and SYSTEM selectors look like they should be changing the EIS display?

@stuartbuchanan this is something maybe I could help you with if your still planning on extending these displays?

[wlbragg]

@tonghuix the POH describes the starting procedure for cold and warm engine. But it doesn't describe how hard it is to start the engine without following the POH guidelines? What I am asking is, if you don't follow the guidelines, will the aircraft still start? Do you have to turn on the fuel pump when cold? If you turn it on when warm, will it always or likely flood the engine? In order to program this realistically I need to know the off nominal behavior of this system and what exactly causes it?

[stuartbuchanan]

On Tue, Nov 10, 2020 at 1:40 AM wlbragg wrote:

If you want the EIS to work correctly, for now, when you download the branch you'll find four files in Nasal/Interfaces SelectableEISPublisher.nas SelectableFuelInterface.nas SelectableFuelPublisher.nas SelectableInterfaceController.nas

You will need to copy the files into the fgdata/Aircraft/Instruments-3d/FG1000/Nasal/Interfaces/ folder.

Do you need a hand fixing this bit?

The only thing I am still unsure of is exactly what the "Fuel QTY GAL" display on the EIS is actually supposed to be displaying. Is it actual gallons in the tank? Why then can you change it using the SYSTEM/RST FUEL/GAL REM/+/- GAL's?

My understanding is that while there are good fuel flow sensors in the 182 (and presumably the 172) there isn't an accurate fuel level measurement. So you have to manually update the fuel quantity when you refuel, and then the fuel flow sensors will accurately reduce the quantity remaining during the flight. RST FUEL should set it back to full fuel.

-Stuart

[wlbragg]

@stuartbuchanan

The LEAN and SYSTEM selectors look like they should be changing the EIS display?

I think this data is missing from the fg1000 EIS for the c172p? The documentation was referring to this data and I think I confused it with the FUEL QTY Gal indicator graphic and needles.

Do you need a hand fixing this bit?

Absolutely, I think those files I pushed are good to go into fg1000 in fgdata, unless you have a better way to handle it.

there isn't an accurate fuel level measurement. So you have to manually update the fuel quantity when you refuel, and then the fuel flow sensors will accurately reduce the quantity remaining during the flight. RST FUEL should set it back to full fuel.

Ok, makes sense. Again, my confusion was the displays above showing the outcome of those calculations in the EIS.

If there is anything I can do to help with any of this, let me know.

The next thing I have to do regarding the fg1000 is the amp draw. I don't think it is reading and rendering that information correctly, I need to verify this and determine why.

[tonghuix]

@tonghuix the POH describes the starting procedure for cold and warm engine. But it doesn't describe how hard it is to start the engine without following the POH guidelines? What I am asking is, if you don't follow the guidelines, will the aircraft still start? Do you have to turn on the fuel pump when cold? If you turn it on when warm, will it always or likely flood the engine? In order to program this realistically I need to know the off nominal behavior of this system and what exactly causes it?

Sadly, I never doing off normal behavior of this system. But for cold weather, my experience is the engine will not easily start when the oil temperature below 10C, so need some warm before start. For hot weather or just restart engine very short priod after shutdown (oil temperature above 150F), due to vapor lock in induction system pipes, it is easily flood the engine, so prime 3 sec is enough, and add throttle 1/2 inch in or half of the full range.

[D-ECHO]

Hi there, Great work!

Not sure whether you're already aware of this, but the autostart menu options on this variant fails with the log message 76.49 [ALRT]:nasal Nasal runtime error: No such member: reset_battery_and_circuit_breakers 76.49 [ALRT]:nasal at /home/delta/Aircraft/c172p/Nasal/c172p.nas, line 13 76.49 [ALRT]:nasal called from: /sim/bindings/menu/binding[223], line 1 (originally reported by User @NewoIsTaken on the FG discord)

[NewoIsTaken]

Also, it seems like when I arm the standby battery, the PFD doesn't turn on.

[hbeni]

Sadly, I never doing off normal behavior of this system. But for cold weather, my experience is the engine will not easily start when the oil temperature below 10C, so need some warm before start. For hot weather or just restart engine very short priod after shutdown (oil temperature above 150F), due to vapor lock in induction system pipes, it is easily flood the engine, so prime 3 sec is enough, and add throttle 1/2 inch in or half of the full range.

Hi @wlbragg, I'm not sure if you already looked at my injection simulation at the c182s/t, but the temperature sensitive start (and also warm start without priming needs) is already simulated there. I did plenty of research for the numbers, but didn't found anything concrete; so i tried to model it by gut feeling i got from lots of articles and videos. i think it is relatively good. At about 0° it gets notably harder to prime correctly and it will get really hard to prime when going to about -10°C or lower, and impossible at -25°C (technically, but for humans this is not possible to achieve). You definitely should use the preheater in those conditions (< -6°C the POH says its a must). The code for all that is mostly in fuel.xml.

For the EIS display, i already have tried to get that working, but i really think there is something missing in the FG1000 core (or i just lack the knowledge to interpret the nasal):

• Need CHT in the EIS: HHS81/c182s/issues/354
• Need to display battery amps: HHS81/c182s/issues/355

[wlbragg]

@hbeni I did look at it and my first reaction was one of intimidation. But I will get back to it and I think it is the way I want to go, I am also intimidated about making my own so I think in the long run adopting yours would definitely be the way to go. It's just a bit more complicated than I was expecting, nothing about what you did, only my own comfort in my abilities to adopt and implement it.

[wlbragg]

@D-ECHO I can't reproduce the autostart nasal error, was that maybe after a restart or something else?

@NewoIsTaken Also I can't reproduce this, If I have everything off and throw that switch the left glass panel comes on as per POH. Ah, just noticed you said "arm" I'll read the docs again and see if I understand your issue, thanks.

[wlbragg]

Wow, don't know how that happened, accidentally closed the issue there for a time?

[tigert]

I'm thinking of giving the choice of using either the KAP140 or the GFC700 when using the FG1000 variant. I need to see if I can easily hook up the GFC700 and if it is tuned .at all for the c172

Ugh, the KAP140 exists in early G1000 C172P's only because the GFC700 was not yet certified at the time. The integration is horrible, the Garmin only drives it left-right and you need to set altitude, baro, vertical speed etc modes in the KAP140. There is actually a single turn&bank gauge behind the right screen (MFD) of the G1000 that is the attitude / heading reference for the KAP140, the G1000 just says "turn left, now turn right, now straight". Ugh,

The G1000 has all that functionality but it cannot be used (and like the alt selector "works" in the G1000 but it does absolutely nothing apart from being a "postit note" so you can remember the number if you dial it in.) - that was the only option they had when they wanted to get the G1000 in the plane if they wanted an autopilot.

I mean, by all means, give a choice but I don't understand who would be such a masochist to choose it if GFC700 is an alternative... :-)

[stuartbuchanan]

I'll take a look at the CHT and battery amps. The problem is almost certainly that the wrong properties are being referenced in the EFIS.nas

RE: KAP140 - I suspect you'd struggle to get accurate integration between the KAP140 and the FG1000. You'd probably need to add an Emesary node to listen to the correct messages from the UI and then pass them onto the KAP140. I really don't think it's worth the effort.

-Stuart

On Thu, Dec 17, 2020 at 6:34 PM Tuomas Kuosmanen notifications@github.com wrote:

I'm thinking of giving the choice of using either the KAP140 or the GFC700 when using the FG1000 variant. I need to see if I can easily hook up the GFC700 and if it is tuned .at all for the c172

Ugh, the KAP140 exists in early G1000 C172P's only because the GFC700 was not yet certified at the time. The integration is horrible, the Garmin only drives it left-right and you need to set altitude, baro, vertical speed etc modes in the KAP140. There is actually a single turn&bank gauge behind the right screen (MFD) of the G1000 that is the attitude / heading reference for the KAP140, the G1000 just says "turn left, now turn right, now straight". Ugh,

The G1000 has all that functionality but it cannot be used (and like the alt selector "works" in the G1000 but it does absolutely nothing apart from being a "postit note" so you can remember the number if you dial it in.

I mean, by all means, give a choice but I don't understand who would be such a masochist to choose it if GFC700 is an alternative... :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/c172p-team/c172p/issues/1333#issuecomment-747620599, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC7C5GBKCBG6QUVXV7WQ7DLSVJFKHANCNFSM4QHO3THQ .

[wlbragg]

Just an info, our school do own some C172Ss equipped with KAP140 autopilot. But most of them are buggy, and not very reliable, mechanics are removing them

That is why I choose to leave the choice. Because of statements like "our school do own some C172Ss equipped with KAP140 autopilot". I think of it the same I do about any upgrades done to any aircraft. We are always improving on systems and technology in the real world, but that doesn't erase the history of what used to be, I really think it is important to retain that history when possible and practical. If I hadn't evolved this variant in the steps I took, which was using the KAP140 first, then adopting the GFC700, just like the timeline in real life, I may not have given this choice. But once the work is done, I see no need to remove it. It is a reality that actually existed and I guess I leave it mostly for nostalgia.

[wlbragg]

RE: KAP140 - I suspect you'd struggle to get accurate integration between the KAP140 and the FG1000.

@stuartbuchanan I think @tigert is referring to the implementation of the GFC700 in the "real world" G1000 equipped aircraft. And yes the integration with the fg1000 is about the same, so I leave it alone. It is a stand alone variant and has no connection anymore with the fg1000/GFC700 variant, no more work to be done. It's a done deal.

[wlbragg]

I'll take a look at the CHT...... . The problem is almost certainly that the wrong properties are being referenced in the EFIS.nas

@stuartbuchanan I think it is more than that, I think you may not have ever implemented the "Fuel Calc" portion. See https://github.com/c172p-team/c172p/issues/1333#issuecomment-724826960

[hbeni]

What i don't really understand - why does the G1000 do its own calculations on fuel, if it could just use the output of the tanks sensors?

[stuartbuchanan]

@wlbragg - Yes, you're right. I was getting confused between the EGT and CHT gauges.

On Thu, Dec 17, 2020 at 9:08 PM Benedikt Hallinger wrote:

What i don't really understand - why does the G1000 do its own calculations on fuel, if it could just use the output of the tanks sensors?

I think it's because IRL the fuel flow sensors are far more accurate than the fuel tank sensors.

BTW - I've fixed the issue that meant you have to put files into fgdata. I'll email you a patch.

[NewoIsTaken]

@wlbragg This is what is happening: video.

[wlbragg]

@NewoIsTaken @D-ECHO I haven't had much time to take a real close look at this but I will soon. However, are you sure you are using the most current version on the repository. Because I so far cannot reproduce this. I switch to ARM and the PFD lights up. Also, I vaguely remember actually seeing that nasal error in the past and I thought I got rid of it. But I also don't remember if it had to do with a reset or something like switching airports or seaports on the fly?

[NewoIsTaken]

@wlbragg No problem, just tell us if you uncover something!

[D-ECHO]

Unfortunately, this still happens with newest FG and c172