New Electrical system - External power "battery" type

Version: 1.5.3

Frequency: Consistently

Severity: NA

Context: What package? Mounted

Bug description:
The new electrical system V2, is increidble good, I love it as it allows to configure so many realistic behaviors.

However one little thing that is not allowing me to do, is to configure external power units based on “Battery”.

Basically with modern times and how new airports are operating, most FBOs are now implementing GPUs based on battery, example: Battery Powered Ground Power Unit - ITW GSE 7400 JetEx

I am trying to simulate this properly, and unfortunately once you try to configure a suppleir type battery, the consumer with the correct Ah capacity, watts, etc., the system refuses to initialize the external power unit in the electrical system, saying, you cannot use external power with battery configurations.

But, they exist in real live see the link abive, and if you guys allows me to extend the usage it will be really cool, because, when you use these new types of external power units, which can push VDC, they react in the electrical circuit / tension like a battery does with the new electrical system (a drop with high power wattage ussage), so when you hit the starters of a jet, depending of the size of the GPU, you see will see the drop in the voltage in the system via the PFD / MFD displays, at the same time, your airplane batteries get “hit” a bit, but not as much.

I am currenlty developing an aircraft which uses these types of starts, the entire fleet in USA are using E-GPUs, and real life pilots have send me the videos of the start procedure, is supper cool to see how the tension on the line drops, even when connected to a GPU.

if I set in MSFS the GPU as a supplier DC / 28V, I never see a drop on the voltage / tension despite that I am trying to fire up a 400A starter (24V x 400A = 9600W of power for 6 to 8 seconds).

Repro steps:
Easy, configure a consumer, a supplier and a external GPU likes this:

consumer.N = Name:ConsumerX #CType:Battery #Capacity:xxx #Voltage:28 #Wattage:xxxx

supplier.n = Name:eGPU #SType:Battery #Type:LithiumIon

externalpower.1 = Name:GPU #SupplierCfg:eGPU #ConsumerCfg:ConsumerX

Unless of course I could set some curves for the DC GPU? to allow me simulate this? in which case how?

Best,
Raul

Hello @SimbolFSReborn

This is a limitation for the current implementation, and using a DC typed one is the way to go for now.
The team also doesn’t have the bandwidth to consider adding the support for this at the moment unfortunately.

Regards,
Sylvain

Hi @FlyingRaccoon,

Copy and understood, do DC support any curves? or not at the moment?

Best,
Raul

Unless I missed it, we are still waiting for the 2022 promised simulation of battery Internal Resistance, which will enable a multitude of battery characteristics to be added and simulated by the developer.
ie voltage drop on load, dependent on battery charge . ie Lights dim when starter motor is run.

Battery “TERMINAL” voltage dependent on load and battery (ambient or engine compartment temperature.

All these effect IRL depend on the battery and its internal Resistance (Missing in MSFS) and Charge (Present in MSFS ).

Without this internal resistance being part of the battery simulation, its effect “CAN” be simulated, but has to be coded for each individual load, which is very inefficient and gets large and messy, , and only justified for major loads.

A simple Variable, “battery internal resistance” modeled into the current Battery simulation, that dropped the battery"Terminal" voltage according to battery current would so simplify this, and make the effects of battery Internal resistance, natively present without any additional developer code.

All the developer would end to do is to control that Asobo battery Internal Resistance variable, as appropriate for their particular battery type, and dependent on whatever other factors they deem necessary, ie Temperature, battery type, battery age, battery charge (even loose and poorly connect battery !! )

Note: I am not suggesting that Asobo do a mass of addition work and coding to add all this dependent coding to Change that Internal Battery Resistance variable,( PLEASE DON"T !! ) as that control ideally should depend on the plane and battery type, etc, but to only add the Variable to the Battery simulation,
Then developers can code the value of that variable themselves, to be as highly simulated as they require, and it will then automatically drop the update Asobo Battery simulation “Battery Terminal Voltage” , dependent on total battery load.

Not sure I follow this answer. The major 2 external power is AC only so how can we charge a battery?

Update work around: We found you can just keep the AC external power then create a generator using the data.simvar to charge the battery. Then use external logic to trigger the external power as you do normally. Looking forward to a fix including fixing relays as these also do not work in major=2.

#GovernedRPM:[data.simvar(EXTERNAL POWER ON:1, Bool)]

But still no BUILT IN simulation of “Battery Internal Resistance” in battery Models, despite the promise that this was on the Dev list, and would be implemented in the Asobo battery model, in a soon to be release SU. That as well over a year ago.. more like 2 :frowning:

Including the “Battery Internal Resistance” is a critical improvement in the battery Model, to make so many Battery dependent features function automatically, without masses of FUDGE code elsewhere to FUDGE the effects.

It is the Battery Internal Resistance,and how it CHANGES WITH BATTERY CHARGE, LOAD, TEMPERATURE, THAT MAKES FEATURE LIKE LIGHT DIM WHEN THE STARTER (or ANY other high current drawing loads) IS OPERATING AND DRAWING CURRENT. - work AUTOMATICALLY without any additional FUDGE EFFECT code.

This IS NOT a request have ASOBO figure out how the resistance changes, but just at a minimum to include that resistance in the battery model, as a read/write variable, and allow the plane developers to then design & code how they want that battery resistance to vary.

Note: making that Resistance default to ZERO, will maintain compatibility with all previous plane models .

SO EASY FOR ASOBO, to add that simulated resistance FOR the developers to make use of.

If ASOBO want to make that resistance change according to their perceived (simple or complex) Physics of how it should change IRL – fine… but it is MOST important that the option be at least open for the DEVELOPER to control that Resistance, overriding any Asobo simulation of the Physics.

The CORRECT Physics is quite complex, and depend on so many factors, that it is unrealistic to assume that ASOBO can get it 100% accurate and as IRL, so better to leave it to the plane devs, to either force it to ZERO (ie NO effect), or make it vary by whatever design physics, and as complex as the Plane Dev wants to make the simulation as close as possible that THEY want it.

Battery chemistry is complex. Voltage and internal resistance are temperature and time dependent (batteries don’t last forever).

Whilst an internal resistance property can be added to a battery, it is very difficult to accurately simulate the voltage/current drops throughout a modern plane. The resistance of wiring becomes important, invertors by design will produce a stable output voltage regardless of ground power voltage input or internal battery voltage. Some planes have forward and aft ground power input, which adds more complexity.

Not actually THAT complex, if broken down correctly – but can be made as “Complex” as you want if you are controlling that part of the simulation
. (Been there, done it - WB-SIM C172 Enhancement Mod)

Again, as complex as the developer wants to make it, but without that Developer controller battery Internal Resistance, modeled into the battery, the task to even implement a basic model, becomes massive.

Hence the suggestion, model the resistance as a read/write Simvar , let it default to zero for backwards compatibility, and the individual plane devs can modify that resistance is whatever way they want to, or not at all, depending on their desired level of the electrical systems simulation.

So what them is also needed in the addition of Read/Write BUS Resistance and BUS-to_Device contact Resistance … but the battery Internal Resistance FIRST maybe ? .. lets RESIST getting too complex, too quickly and SHORTING OURSELVES Out

Yes for a Cessna the problem is simple, given the battery + wiring resistance and starter current.

The Dreamliner APU, for example, generates 1.5 Mega Watts, which is a huge amount of power to model, distributed as AC and DC. The goal is making the ELEC, APU and HYD screens realistic and the plane devs have done that, for Boeing and Airbus.

This topic has been automatically closed after 60 days of inactivity since it was marked as by-design.

If there is important new information about this same report, you can use the “Request reopen” button below to ask the moderation team to review it again.
For other issues or broader discussion, please open a new topic in the appropriate category.