• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

How to build a power source

Messages
22
Country
italy
Dears,

many people wondered for years how to build a power source in FS. Latest versions of FS have an APU feature, that is missing in FS9, but still works only in certain situations.
There is a way I found today, and deserves to be shared with the community.
Electrical system works with a battery with an uncontrollable capacity and a certain voltage. Then there are systems that drain the battery. Systems are regulated via the [electrical] section in the aircraft.cfg. This section contains entries like this:

light_landing = 0, 5, 17

where the first number is the bus the system is connected to, the second is the current adsorption in ampere and the 3rd is the limit voltage that make the system functional. In the specific case, switching on the landing light a consumption of 5 A is added in bus 0, and the system works until the bus is above 17 V.
Important remark is that (for this system) a landing light must be defined in the [light] section. It has nothing to do with the light itself, but with a simulated system.
Nevertheless, the amperage can be set negative, and in this case it will CHARGE the battery. It means we can sacrifice one of the 10 possible lights of the plane and use it to simulate a power source (APU, GPU). I am personally using light #9, logo light.

light_logo = 0, -100 , 15.0

When logo light is on, it will charge the system with 100 amps. The rest is easy, create your APU or whatever that trigger this light.

An extra info. The panel will go off and "electrical failure" will trigger in the moment when "additional_system" reaches it's critical voltage, typically 17 V.
Normally the line is set as
additional_system = 0, 20, 17

The failure is not irreversible as it is often believed. You just need to recharge above this voltage and it will be operational again. In order to do it be sure that light_logo will have a min voltage lower than ALL other systems. In this way you can operate it and it will charge the battery and restore functionality.
If battery is below the light_logo limit voltage instead, that system will not work and battery will be dead forever.

Tested on Fs2004, don't see a reason why it will not work for newer FS

Hope it will be useful for anybody. It was for me.
 
Last edited:
Since FSX, you've got an APU that doesn't use fuel and an entry for the aircraft.cfg that basically provides infinite electrical power.
 
SHUTES! Never thought of that!
It may work better than my current approach to APU/GPU involving a 3rd engine, and juggling the starter... thanks, may update my systems!
 
I have no FSX, but I read the APU in FSX is only for jet engines.
I have been spending years figuring out how to create electrical energy... tried the 3rd engine option. Only 2 days ago i though i found a solution by creating a simple battery that switched off the electricity when discharged (and uses FSUIPC to keep the real battery always charged)... then i started to think that i may not even need FSUIPC, by setting all electrical consumption to 0... then a bad idea came to my mind: what if i put negative consumption... and voilà....o_O
I felt like an idiot...

PS: still this solution needs to be attached to something that simulates an apu start/stop (easy), consumes fuel (i use the DSD fuel dump gauge) and possibly generates compressed air for engine start (also easy via normal XML). The main problem with the battery charging turns to be solvable in a very easy way.
 
That's a really clever tip to use a negative number to charge the battery.

If someone is using C++ and simconnect then it is possible to write directly to A:ELECTRICAL BATTERY VOLTAGE,volts using SimConnect_SetDataOnSimObject.

I use this method as my aircraft has a battery hoist. Lower the hoist and it will disconnect the battery (there are two prongs on the hoist which physically connect the battery) so when this is done I firstly store battery level and then set the level to 0. Then, when the hoist is raised again I restore the battery level.
 
I have no FSX, but I read the APU in FSX is only for jet engines.

Jets just don't require an extra entry for the APU in the aircraft.cfg. I've successfully added APUs to turboprop and piston powered aircraft.
 
Since I do not want GPU/APU power to activate my night lighting, I used "Standby Vacuum pump" instead. My gyros are electrically powered anyway. Also, you may set minimum voltage to -1!!
Off to remove engine #3 and code APU/GPU with this system!
 
Does anybody know how all these systems work? For the moment I have found this:

flap_motor --> This is for motorized flaps. Think inactive if flaps are not electrical. But untested
gear_motor --> This is for motorized gears. Think inactive if flaps are not electrical. But untested
autopilot --> Cannot make this work. If I enable autopilot i do not see this consumption
avionics_bus = --> Not sure what is this for
avionics --> This is on when avionic switch is on
pitot_heat --> I assume is for pitot heat, but on jets seems not working
additional_system --> This is the main aircraft consumption. If fails it triggers on "electrical failure"
marker_beacon --> Suppose if for the beacon. Untested
gear_warning --> Gear warning sound? Untested
fuel_pump --> I suppose it's the fuel electric pump Untested
starter1-4 -> These should be the starters. On jet i didn't see them working.
light_xxx --> 10 lights systems. Only work is at least 1 light of that type is defined in the [lights] section
auto_feather --> I suppose it's the auto father for turboprops. Untested
auto_brakes --> I suppose it's the auto brakes. Untested
standby_vacuum --> I suppose it's the standby vacuum. Not working in jets. I doubts in any other types. Isn't it there a sound associated to standby vacuum? Untested
hydraulic_pump --> No idea what it is. I thought the pump was powered by engine rotation. No idea on how to make this system working.
fuel_transfer_pump --> I guess it's for fuel transfer pump. Untested
propeller_deice --> Like pitot deice, also this does not seem to work
directional_gyro --> Never seen this working
directional_gyro_slaving --> As well
 
This could be really handy when simulating a ground power unit for propliners without APUs. Set up the plane properly, the green light comes on and the GPU (logo light) starts feeding power into the system. The battery really isn't normally supposed to charge in this situation, but that's a minor quibble.

Thanks,
 
So far, I figured:


avionics_bus = --> avionics are connected here. everything connected to Bus #1 (avionics) depends on power being available to the bus you connect this to. Do not enter bus 1 here or a black hole will suck in your Aircraft... :p
avionics --> place this in bus 1 (avionics) or avionics switch will get stuck (pity, I wanted to have avionics on main, and a lot of other stuff on avionics bus, read "Essential" and "main bus"...)
fuel_pump --> electric fuel pumps. Needs to be enabled in aircraft.cfg. draw not tested
starter1-4 -> as you said, no power draw on jets....
standby_vacuum --> works as intended if enabled in the .AIR REC1512. if you have electric gyros, you can use as the APU-GPU trick...
hydraulic_pump --> electric_pumps=1 in Hydraulic_system for it to work, not tested the power draw yet...
 
Nice tip for sure, thanks.
Personally I never thought of doing such a test.

I actually write to the AVar directly using SIMVARS class from XMLTools, which enables a better control of battery discharge (FS rate is quite unrealistic)
I also don't care a bit about the [electrics] section; usually I leave the default data as I custom code all of the electrical buses.

Tom
 
Interesting approach that I tried to apply last night.. however, I could not get it to work properly. Probably something I have missed, but this is what I did so far.

In the Aircraft cfg I have under the [electrical] section : light_logo = 0, -100 , 15.0

Under the [lights] section : light.18 = 9, 1,1,1, simulated APU charge ------this is possibly where I went wrong?

And an XML gauge on the APU panel that is the generator switch with it coded like this... <Value>(A:LIGHT LOGO,bool)</Value>

APU works and the switch functions, but the battery still dies. I have a registered copy of FSIUPC and turned off the extend battery life to try this solution out.

Any help as I would love to have this option work.

Thanks, Greg
 
light.18 = 9, 1,1,1, simulated APU charge ------this is possibly where I went wrong?


Thanks, Greg

Yes, that is where you went wrong, the FX file needs to be valid. Here, have a null effect :D

Code:
[Library Effect]
Lifetime=5
Version=2.00
Radius=-1

[Properties]
VirtualCockpit=0
Spot=1
Tower=1
Map=1
Cockpit=0


[Emitter.0]
Lifetime=0.50, 0.50
Delay=0.00, 0.00
Bounce=0.00
No Interpolate=1
Rate=1.00, 1.00
X Emitter Velocity=0.00, 0.00
Y Emitter Velocity=0.00, 0.00
Z Emitter Velocity=0.00, 0.00
Drag=0.00, 0.00
X Particle Velocity=0.00, 0.00
Y Particle Velocity=0.00, 0.00
Z Particle Velocity=0.00, 0.00
X Rotation=0.00, 0.00
Y Rotation=0.00, 0.00
Z Rotation=0.00, 0.00
X Offset=0.00, 0.00
Y Offset=0.00, 0.00
Z Offset=0.00, 0.00

[Particle.0]
Lifetime=0.00, 0.00
Type=19
X Scale=0.0, 0.0
Y Scale=0.0, 0.0
Z Scale=0.00, 0.00
X Scale Rate=0.00, 0.00
Y Scale Rate=0.00, 0.00
Z Scale Rate=0.00, 0.00
Drag=0.00, 0.00
Color Rate=0.00, 0.00
X Offset=0.00, 0.00
Y Offset=0.00, 0.00
Z Offset=0.00, 0.00
Fade In=0.00, 0.00
Fade Out=0.00, 0.00
Rotation=0.00, 0.00
Static=1
Face=1, 1, 1

[ParticleAttributes.0]
Blend Mode=2
Texture=fx_2.bmp
Bounce=0.00
Color Start=0, 0, 0, 0
Color End=0, 0, 0, 0
Jitter Distance=0.00
Jitter Time=0.00
uv1=0.00, 0.00
uv2=0.00, 0.00
X Scale Goal=0.00
Y Scale Goal=0.00
Z Scale Goal=0.00
Extrude Length=0.00
Extrude Pitch Max=0.00
Extrude Heading Max=0.00
 
I personally just created a dummy.fx with almost nothing inside
Code:
[Library Effect]
Lifetime=5
Version=2.00
Enough to make it work
 
Personally, I am using the "Stadby Vacuum pump". Just enable it in the.AIR for jets. No worry abut effects, and will not trigger night lighting if present in your model:
Air File REC1512:
(INT32) Emergency vacuum pump,1
(DBL) Emergency vacuum suction,5.15 <-- You could set this lower than -- (DBL) Vacuum min for gauges -- so that it does not affect your ghyros. My gyros are electrical anyway...
 
(>K:TOGGLE_ELECTRIC_VACUUM_PUMP)

Regarding A: variables to check its state, the only thing I can find in the FS9 SDK is:

(A:CIRCUIT STANDY VACUUM ON, bool)

but I don't know if that tests for the pump itself. And there may be a typo in the SDK so it might be STANDBY.
 
Interestingly enough, an addon I bought earlier (Adlabs6 B1900C Panel) has all the electrical loads in the CFG set to 0, and uses the XML gauges to calculate everything based on what systems are on and what is powering these systems. I'm thinking of using something like this for my projects that aren't going anywhere.
 
Well, this worked for me:

Code:
(L:GPU_ONLINE,bool) (L:APU_ONLINE,bool) or (A:CIRCUIT STANDY VACUUM ON,bool) != if{ (&gt;K:TOGGLE_ELECTRIC_VACUUM_PUMP) }

So, the typo is actually in the code base and not in the SDK, that simply reported it as-is (APU and GPU variables are controlled somewhere else).
 
Back
Top