Atmosphere Gauge calcs

[cyberKerb]

I'm read a range of forum post, the wiki, the wiki discussion and reddit, but there doesn't seem to be a known calculation for deriving the Atmosphere Gauge value between 0-1

I've seen how the RPM/MAS mod hooks into the object to read the value directly, but I was wondering if anyone had worked out the calculations to match the gauges values?
@richfiles - did you end up working out the details for your gauge? I saw the comment about atmos being " .000001 of 1 ASL atmosphere", but where do you calculate or grab that 1 ASL value from in the API? Is it a lookup table?

Edited July 31, 2019 by wile1411

[richfiles]

In the end, I found the issue to be such a pain, I just went with a 0-100% scale. 

The issue ended up being trying to apply a scale based on the number of divisions the KSP onscreen atmosphere density readout shows. I think it was an odd number, and at one point I'd considered going with an order of magnitude scale, adding a decimal location and a zero to the density each time. (This is actually what I did, but with SI units). I decided I didn't like the guestimation nature of that, the fact that it might not represent actual numerical values, and the fact that even the onscreen one has no numeric values, I ultimately went with percentage. (went with an order of magnitude scale that references ASL density and scales over an arbitrary order of magnitude scale)

Edited July 31, 2019 by richfiles

[cyberKerb]

Just now, richfiles said:

In the end, I found the issue to be such a pain, I just went with a 0-100% scale. 

The issue ended up being trying to apply a scale based on the number of divisions the KSP onscreen atmosphere density readout shows. I think it was an odd number, and at one point I'd considered going with an order of magnitude scale, adding a decimal location and a zero to the density each time. I decided I didn't like the guestimation nature of that, the fact that it might not represent actual numerical values, and the fact that even the onscreen one has no numeric values, I ultimately went with percentage.

Did you use the 'Density' value that is the only atmos value in the KSSerialIO mod? If so, what were you using as the max number you were dividing by to get the percent?
github source line: KSPSerialPort.VData.Density = (float)ActiveVessel.atmDensity;

Or did you fork the KSSerialIO and add your own value? I want interested to know what you ended up with sourcewise see at the Max value changes for each celestialbody.

[richfiles]

I was about to come back and change my post. I'll just add, I guess. I have done no software yet. Between getting hurt at work in 2016, The Nintendo Switch coming out (with a new Zelda) in 2017 (which was an easy pastime while dealing with a healing shoulder), and the latter half of 2017 and all of 2018 being absolute madness at my old job, with them trying to cut labor down, but not the workload, I hadn't touched this since way back then.

Had I scrolled just another screen or two down, I'd have seen where I did come up with a scale of atmospheres, rather than percentage.

Now I remember it. It's still a "relative" scale, like percentage, but at least this one has a unit (being a single atmosphere at sea level). As I said, it's been a long time since looking into this stuff, so I'd forgotten how the atmospheric density was sent.

Sounds like it's based on an actual numeric value. Presumably, you'd want a lookup table with every body that has an atmosphere. You'd have to read your SoI, I think, to pull the right value, and then just divide that by the number of steps your output resolution supports (if it's an 8-bit output, then divide it by 255, for example). You would just divide the atmospheric density value sent by the plugin by that value. You could just store the result of dividing max atmospheric density for each separate body by 255 in your lookup table. The scale isn't a hard numeric translation either. I WAS correct in recalling one thing. The numbers are krackenspew. I derived them purely by taking the onscreen Atmospheric density meter and it's four shading divisions, and divided the graduations on the scale into seven divisions, simply to line up with an order of magnitude scale that looks pretty, has one end at 1 ASL, and has a low value at the other end that is more or less considered "near vacuum". There's literally nothing more to it. Their gauge is an awful jumble of graduations that the scale makes little sense to me. Software wise, it will be a proportional linear scale, based on the numeric value sent. If it displays wildly differently than what's on screen, then it probably will get tweaked, but I'm a long way away from software. If it is positionally similar, then I won't touch a thing.

Edited July 31, 2019 by richfiles

[cyberKerb]

Thanks @richfiles for going back and looking through all that. It covered what I'd already read on the forum.

Here's what my searching uncovered:

RPM formula for Atmo Depth that is used when the gauge GUI object is unavailable::

upperAtmosphereLimit = Math.Log(100000.0);

depth = (float)
		(
		  (
		    upperAtmosphereLimit + Math.Log
		      (
		      FlightGlobals.getAtmDensity(vessel.staticPressurekPa * PhysicsGlobals.KpaToAtmospheres, FlightGlobals.Bodies[1].atmosphereTemperatureSeaLevel)
		      /
		      FlightGlobals.getAtmDensity(FlightGlobals.currentMainBody.atmospherePressureSeaLevel, FlightGlobals.currentMainBody.atmosphereTemperatureSeaLevel)
		      )
		  )
		  /
		  upperAtmosphereLimit
		).Clamp(0.0f, 1.0f);

 

I came up with the following formula trying to match the density curve to the GUI gauge curve during a test launch.
VDensity = (vesselairpressure*1000)/(287.053*atmosTempK)
Gauge % = 10^(LOG(VDensity)/4)-0.021808

In "spreadsheet land", it stays within 0.02% of the gauge (on average). It's worst when the pressure is really low near space. I'll run both calcs, the RPM & my kluged version,  tonight to see how they compare to the actual gauge value.

Edit: OK the kludged version works well, but only for Kerbin - kinda expected. Now to throw more formulas and to plug numbers in until I get the curve I'm expecting.

KSPSerialPort.VData.AmtosDepth = (float)Math.Pow(10, ((Math.Log((ActiveVessel.staticPressurekPa * 1000.0f) / (287.53f * ActiveVessel.atmosphericTemperature), 10.0)) / 4) - 0.021808f);

Edit2: Better calc at bottom of thread

Edited August 3, 2019 by wile1411

[cyberKerb]

Ok - I'm done for the night. I've taken the non-math/Kerbal route to try to get something together for this math problem.
The results aren't bad, as all values are within +-0.5%
I would be good if someone who is more knowledgeable that me in this area to see if they can tease out the correct formula. My fumbling in excel was just tweaking the shape of charts based on formulas to make expected lines match.

Kludge Calculations
Step 1
CalcAirDensity = (float)(ActiveVessel.staticPressurekPa*PhysicsGlobals.KpaToAtmospheres*1000/(287.058*ActiveVessel.atmosphericTemperature));
Or
CalcAirDensity = (float)FlightGlobals.getAtmDensity(ActiveVessel.staticPressurekPa * PhysicsGlobals.KpaToAtmospheres, ActiveVessel.atmosphericTemperature);

Note: Don't use (float)ActiveVessel.atmDensity My wild guess is that this might be a legacy property. The atmDensity field doesn't have a value until it's >= 0.00000001.
I need to recheck if the GUI gauge is still showing > 0 in these cases or if it's zeroing ahead of time, but I don't think this is the case. My logging shows that GUI gauge still has values all the way until pressure is 0.

 

Step 2
(float)(Math.Exp((Math.Log(CalcAirDensity) / 4) - BodyVal) * 10)
Substitute the BodyVal with applicable value below.
Don't ask me where '4' come from - I randomly entered it in and the gradient of the chart matched what I was looking for. So I went with it. 

BodyVal number based on testing
Kerbin = 1.1983
Duna = 0.575
Laythe = 1.0811
Eve = 1.5071
If anyone works out how these can be derived from the celestial body properties, let me know.

This gives me an atmosphere value between 0.0 - 1.0 that correlates closely to the Atmosphere Gauge on the GUI.

If you fork your own KerbalSerialIO, you could add the code in C# to a variable in then you'll be able use the value for setting a physical gauge.
However, this isn't intended to be a 'solution', just a step towards finding the right formula.
Pinging a few people who might be interested / serious math god. @zitronen, @hugopeeters @richfiles @Arrowstar

EDIT: found better formula - see below.

Edited August 3, 2019 by wile1411

[zitronen]

Is it not just air density? Where sea level is 100% (1.225kg/m^3) and space is 0%?

[cyberKerb]

16 hours ago, zitronen said:

Is it not just air density? Where sea level is 100% (1.225kg/m^3) and space is 0%?

The numbers moved out of sync with what I was seeing on the gauge when I used density / sea level.
I tried that initially and these are the values for the foll0wing calc:
 ActiveVessel.atmDensity   /   FlightGlobals.getAtmDensity(FlightGlobals.currentMainBody.atmospherePressureSeaLevel, FlightGlobals.currentMainBody.atmosphereTemperatureSeaLevel);

atmDensity	   SL Density	   Result	Actual Gauge
0.80186027	/  1.22988546	=  65.2%	90.0%
0.49960122	/  1.22988546	=  40.6%	80.0%
0.29447165	/  1.22988546	=  23.9%	70.1%
0.15967405	/  1.22988546	=  13.0%	60.2%
0.07618099	/  1.22988546	=   6.2%	50.0%
0.03136805	/  1.22988546	=   2.6%	40.1%
0.00990661	/  1.22988546	=   0.8%	30.0%
0.00197034	/  1.22988546	=   0.2%	20.0%
0.0001245	/  1.22988546	=   0.0%	10.0%
0	        /  1.22988546	=   0.0%	 0.6%

I went back and tried some regression analysis and a far simpler formula popped out.
SLDensity = (float)FlightGlobals.getAtmDensity(FlightGlobals.currentMainBody.atmospherePressureSeaLevel, FlightGlobals.currentMainBody.atmosphereTemperatureSeaLevel);
AtmosDepth = (float)Math.Pow(ActiveVessel.atmDensity / SLDensity,0.25f);

As a quick test in the morning, I found it works for Duna, Kerbin, & Laythe - so I think that's the one . I'll test again tonight to see if I need to add some decimals to that 0.25 figure to be slightly more accurate.
EDIT: Re-ran the numbers through the tool (here: https://planetcalc.com/5992/) and confirmed that the formula is best fit. Kinda chuffed that it worked 

@richfiles Calc all done for you when you get to your software stage. I've had a few attempts working with hardware a few times like what you've posted on the forums. This time around I'm trying to stick with software and work those issues out first. Hopefully I make it further than last time and have a few working components.

@zitronen Not sure there's any point adding SL Density to the protocol on it's own. While it's required to do the calc, it would be a different Sea Level Density figure depending on what planet you were on. All that would result in would be getting ppl to do the calc on their microcontroller and it's preferable to avoid the log, ln, power function were possible on those little things.
Probably be simpler to just replace Density with the Depth calculation below. Last option would be to read directly from the GUI Atmosphere gauge value.

Suggestion to substitute the Density value and supply a atmosphere depth value that should be between 0 and 1. 
KSPSerialPort.VData.Density = (float)ActiveVessel.atmDensity;
with
KSPSerialPort.VData.Density = (float)Math.Pow(ActiveVessel.atmDensity / (FlightGlobals.getAtmDensity(FlightGlobals.currentMainBody.atmospherePressureSeaLevel, FlightGlobals.currentMainBody.atmosphereTemperatureSeaLevel)), 0.25f);

Edited August 3, 2019 by wile1411
extra testing of new formula

[zitronen]

Hmm this is weird. Why would you want to know this value? If you just want to know how deep you are in the atmosphere why not just use altitude and remember atmo start height for each planet? That formula is also odd since IRL density ratio is exponential, not 4th root.

Density by itself is useful, if density halves your drag and lift halves at the same true air speed, which is why I included it.

[cyberKerb]

8 hours ago, zitronen said:

Hmm this is weird. Why would you want to know this value? If you just want to know how deep you are in the atmosphere why not just use altitude and remember atmo start height for each planet? That formula is also odd since IRL density ratio is exponential, not 4th root.

For me, it was to create an atmosphere gauge to view on a physical controller while in IVA view.
I didn't use the alt vs maxheight calculation as that a linear value. The gauge is sourced from an exponential value, but it's converted somehow so it moves different to the values you'd expect it to use.
The formula I had is not perfect by any means but it at least replicates the atmosphere gauge +- 0.5%. Not idea why 4th root gets close or works as well as it does. Main reason I posted it is there have been a couple of threads (here and reddit) querying what the calcs are behind the gauge. I figured I'd try.

Also aware there are opinions that the atmosphere gauge is useless and takes up screen space, so no loss if no one interested.  Richfiles even mentioned the scale was weird, the tick marks don't make sense and the color bands are another mystery

Atmos	MaxAlt
Gauge	vs Alt%
90.0%	96.0%
80.1%	90.9%
70.1%	86.0%
60.0%	81.4%
50.0%	76.0%
40.0%	69.5%
30.0%	61.1%
20.0%	48.7%
10.0%	23.5%
0.7%	0.1%

8 hours ago, zitronen said:

Density by itself is useful, if density halves your drag and lift halves at the same true air speed, which is why I included it.

This is the stuff I need to learn but don't know it's contextual application.

Edited August 4, 2019 by wile1411