Stream Deck - altimeter setting in inHg and hPa

[scoobie]

Hi.
ATC people in DCS always give you QNH in inches Hg, while many "metric" aircraft use hPa instead.

You may squander one of your Stream Deck's buttons to have a "live calculator", which always shows your altimeter's current setting both in hPa and inHg.

When the guy/gal tells you "altimeter 29.63" you just turn the knob in the cockpit and look at the Stream Deck until it reads 29.63.

Once you're finished, the altimeter setting window in the cockpit will read 1003.4 hPa (which is 29.63 inHg).

No need for calculators, conversion tables etc.

See the picture.
Another advantage (a side effect, actually) is that in some A/C you can't read the setting as the digits are so minute, so the Stream Deck gives an enlarged version.

 

Recipe:

Use New StreamDeck Plugin by @ctytler

Add to the export script for your plane something like below (CAUTION: This is just an example which works in the Spit! For other aircraft you need to modify it accordingly.).
 

function ExportScript.ProcessIkarusDCSConfigHighImportance(mainPanelDevice)
(...)
local hpa = 800 + 250 * mainPanelDevice:get_argument_value(29)
ExportScript.Tools.SendData(2029,
    string.format("%.1f", hpa) -- altimeter setting in hPa...
    .. "\n"
    .. string.format("%.2f", 29.92 * hpa / 1013.25) -- ... and in inHg
)
(...)

 

Then assign it in Stream Deck as in the picture below. The very picture shows how it looks on the real button.
Done.

 

 

[Bailey]

This is a nice idea. I think I might go through some the different modules and make some kind of “universal unit conversion panel”. An airspeed square. A pressure square. A QNH/QFE square. An altitude square. Etc. hopefully I can find some super unique export IDs so that the same buttons could be used for all modules. The math and compatibility would be done in the individual luas. 

[Bailey]

Making progress.

 

 

Don't mind the colors and typos. WIP.

I am working with a few other folks to get some aircraft conditions exported and read for some special treats.

[scoobie]

Nice job!
Yeah, you could come up with some unified ID's for such values (buttons) and then adapt all neccessary export scripts to that (so you can then just copy-paste a button in Stream Deck from one plane to another, if I understood you correctly) - good idea, actually, I think I may steal it from you!

BTW, are you from an "imperial" country, by any chance? I'm asking because... uhm... no offence, but recalculating meters into kilometers is slightly superfluous Metric system has some advantages - that's one of them. But yeah - whatever floats one's boat, none of my business, I know, no problem.

 

How did you "re-linearize" radalt on this plane? I'm asking because I wrote a dirty function for such things, but I'm a Lua Idiot 2nd Class (certified!) and for some reason the data displayed on the button sometimes "freeze", for a minute or two, and then "defreeze" and start working again without my intervention. I have no idea what bug it may be, I need to investigate. It must be an issue of type: "Lua doesn't work the way you think it does". I haven't even read Lua specification and I've never been a software dude (firmware, low-level stuff - yes, software - no) so for me Lua feels a bit exotic. So, perhaps you have something that works? Turning a non-linear value back into a linear one? These values are like "angular position" of the gauge's needle, while the problem is the scale is non-linear, so if you read such value, you can't simply recalculate it into final units (you'll get rubbish), you must first make it linear.

 

Edited July 15, 2021 by scoobie

[Bailey]

2 hours ago, scoobie said:

Nice job!
Yeah, you could come up with some unified ID's for such values (buttons) and then adapt all neccessary export scripts to that (so you can then just copy-paste a button in Stream Deck from one plane to another, if I understood you correctly) - good idea, actually, I think I may steal it from you!

BTW, are you from an "imperial" country, by any chance? I'm asking because... uhm... no offence, but recalculating meters into kilometers is slightly superfluous Metric system has some advantages - that's one of them. But yeah - whatever floats one's boat, none of my business, I know, no problem.

 

How did you "re-linearize" radalt on this plane? I'm asking because I wrote a dirty function for such things, but I'm a Lua Idiot 2nd Class (certified!) and for some reason the data displayed on the button sometimes "freeze", for a minute or two, and then "defreeze" and start working again without my intervention. I have no idea what bug it may be, I need to investigate. It must be an issue of type: "Lua doesn't work the way you think it does". I haven't even read Lua specification and I've never been a software dude (firmware, low-level stuff - yes, software - no) so for me Lua feels a bit exotic. So, perhaps you have something that works? Turning a non-linear value back into a linear one? These values are like "angular position" of the gauge's needle, while the problem is the scale is non-linear, so if you read such value, you can't simply recalculate it into final units (you'll get rubbish), you must first make it linear.

 

 

Thank you. You can see the code here https://github.com/asherao/DCS-ExportScripts/blob/master/ExportsModules/Mi-24P.lua, lines 1107 to 1276. The "universal" IDs are  44224 - 44231. I have used the same structure on the F16 too (https://github.com/asherao/DCS-ExportScripts). Take/copy what you want for other modules and improve on what I had. In the "extras" section you will see that there is support for image changes, for example, if you are about to hit 350 kmph in the hind, the background will turn red. A readme may be needed, but it's all there.

 

The reason for the km is specifically for the Viggen. That's it. 

"How did you "re-linearize" radalt on this plane?" Which plane? Can you show the code? I am currently having trouble getting radalt for the F16 due to a specific condition where if the thousands number is not present in the export, the system kinda freezes. I dont have this problem with the Hind or any other analog guage.

 

For the non-linear guages I get some samples into excel and have excel make a function via a line graph. From there I decide if I need to break up the equation into two or three parts. It takes a little bit to get used to doing, but it is more simple than trying to make some 4th order differential equation or something. You can cee an example of this in the Hind lua around line 1235, here: https://github.com/asherao/DCS-ExportScripts/blob/master/ExportsModules/Mi-24P.lua#L1235
So yes, you do need to make it linear, but it is still approximating the entire range of values. Kind of like drawing a square from a circle. The more lines you draw, the more it becomes more of a circle. 

[scoobie]

Thanks a lot, very much appreciated!
Yeah, I can see how you did it. Your files are very tidy, pleasure to read, but your linearization is hand written code. My idea was slightly different - to have a generic function that works on data copy-pasted from mainpanel_init.lua.
Now, my problems I mentioned above... the function seems to work, by and large at least, it does linearize. I've just been testing a bit and it seems the reason for my "freezes" is that the script "chokes", as if it didn't have enough time to run the code. I've written a few "patents" for my P-51... maybe too many? I'll try to figure it out, I'm a noob in all this.

 

I'll quote the function here - if anybody likes it or wants to build on top of it, or can come up with something better. Or perhaps points mistakes/bugs?
The loooong prologue tries to explain (in broken English) how to use the function - see "Example use".

(Sorry for strange naming convention - I come from a different world.)

 

-- Linearize() by scoobie (disclaimer: I don't undestarnd Lua!)
-- Recalculate steam gauge's needle position into a final value, e.g. gallons of fuel, indicated airspeed etc.
-- (Don't call this function if the gauge's scale is linear - in such case just recalculate the value on the fly, single linear formula.)
-- Parameters:
--   current_value - a variable, typically from 0.0 to 1.0, which indicates "angular position" of the gauge's needle.
--     You should find this variable in mainpanel_init.lua in your module's directory (in Cockpit\Scripts subfolder).
--   raw_tab, final_tab - these should be taken from mainpanel_init.lua.
--   Typically the whole part of mainpanel_init.lua with these values looks something like this (example only):
--     [QUOTE]
--       -- Fuel contents gauge
--       FuelReserveMain            = CreateGauge()
--       FuelReserveMain.arg_number = 109 <- THIS IS YOUR current_value, retrieve it this way: mainPanelDevice:get_argument_value(109)
--       FuelReserveMain.input      = {  0.0,  40.0, 100.0, 150.0, 175.0, 200.0, 225.0, 250.0, 264.0, 270.0} <- THIS IS YOUR final_tab
--       FuelReserveMain.output     = {0.000, 0.144, 0.347, 0.506, 0.599, 0.666, 0.753, 0.828, 0.877, 1.000} <- THIS IS YOUR raw_tab
--       FuelReserveMain.controller = controllers.FuelReserveMain
--     [/QUOTE]
--     Note that in mainpanel_init.lua the logic is reverse - input is for us "final", output is our "raw". This is because the module does
--     the opposite job. The guts of the module operate on pretty mathematical formulas and don't care about gauges in the cockpit.
--     Then, the result of their work must be "projected" onto gauge's faceplate, which may be non-linear.
--     As a side effect, we are forced to do the exactly opposite job here - recalculate the non-linear gauge into a pretty linear value.
--
--     Rewrite these tables to your export script.
--
-- Return value: number, the final value (e.g. US gallons of fuel, miles per hour of IAS etc.) representing current needle position.
--
-- Example use (according to the above quote):
--   final_main_tank_table = {0.0,   40.0, 100.0,  150.0, 175.0, 200.0, 225.0, 250.0, 264.0, 270.0}  -- respective US gallons
--   raw_main_tank_table   = {0.000, 0.144, 0.347, 0.506, 0.599, 0.666, 0.753, 0.828, 0.877, 1.000} -- variable value
--   ExportScript.Tools.SendData(2155, string.format("%d", ExportScript.Linearize(mainPanelDevice:get_argument_value(109), raw_main_tank_table, final_main_tank_table)))
--
function ExportScript.Linearize(current_value, raw_tab, final_tab)
  if current_value <= 0 then
    return 0
  end
  for index, value in ipairs(raw_tab) do
    if current_value <= value then
      local ft = final_tab[index]
      local rt = raw_tab[index]
      return (current_value - rt) * (ft - final_tab[index - 1]) / (rt - raw_tab[index - 1]) + ft
    end
  end
  -- we shouldn't be here, so something went wrong - return arbitrary max. final value, maybe the user will notice the problem:
  return final_tab[#final_tab]
end

 

2 hours ago, Bailey said:

"How did you "re-linearize" radalt on this plane?" Which plane?

The one with the very very light grey panel and on Stream Deck with green text. It reads "Alt (AGL)" and 73 meters - which seems a spot-on value, while the radalt is heavily non-linear.
As for the F-16, I wish I could help, but I don't have the Viper (yet).

 

Edited July 15, 2021 by scoobie

[Bailey]

I appreciate the praise of my code. I try to write it so that the next week version of me knows what the heck the last week version was thinking, hahah. Your “auto-linerazation” functions sounds like a great idea. Idk what would be causing the pauses. You code logic is way over my head, but I’ll take a look from time to time to see if something clicks. one thing that I saw that may be an issue is that some of the gauges use the negative side of the value numbers too. A quick example would be the vertical velocity indicator where it’s kinda like {-1,0,1},{-30,0,30}. Would your “if current_value <= 0, return 0” prevent the VVI from being read correctly?

 

The Hind radar altimeter gauge is quite linear before and after about 50 meters. Put some data points in Excel and you’ll see what I mean. In the right column put the number that you want to sample (such as 50) and then in the left column put the Value (such as 0.123). I sample the major representations and any that simply look like they could be a point in which the rate or linear-ness changes. So specifically for the Hind radar altimeter I sampled all of the numbered meters (0,20,40,60,etc). My result in excel was a line that had only 1 “elbow” in it, so that’s where I split the data and created the two equations.
 

Sometimes either due to how the gauge is modeled or through sampling error the lines are not perfect. If that’s the case I choose the “best fit” for the range that the player will be in most of the time. You will notice this with the hind airspeed. Above 400 kmph the SD readout gets some huge errors. But honestly, if you are that fast and you are worried about your airspeed, you were about 50kmph too late due to VNE and you are currently in an uncontrolled right bank dive 

On the other hand, whoever did the Vipers airspeed gauge did us a favor. The gauge itself isn’t linear, but it is coded such that 0.100 is 100kts, 0.200 is 200kts, and so on. The result is that if you smoothly increase the argument at a steady rate in modelViewer, the gauge will visually start fast and then slow down. It made the conversion super easy because all I had to do was multiply by some factor of 10 and there was no “re-linerazation“ that had to be done. 

[scoobie]

10 hours ago, Bailey said:

I try to write it so that the next week version of me knows what the heck the last week version was thinking, hahah.

Absolutely! If all programmers used this rule, we'd live in a happy world.

 

10 hours ago, Bailey said:

Would your “if current_value <= 0, return 0” prevent the VVI from being read correctly?

Doh! I completely forgot about this kind of gauges!
Yeah, this absolutely prevents VVI from working with this function... oh, boy  

It can be repaired easily, I think. All it takes is probably just replace it with "if it's <= first_raw_value_in_the_table then return first_final_value_from_the_other_table".

 

My code is basically doing what you are doing outside of the code. You look for "elbows" (vertices) in Excel and define these elbows as "if/else" (or if/elseif/else etc.), while I look for them in the code, running through the table (the "raw" table) stolen from mainpanel_init.lua. The other difference is that I calculate "a" and "b" for y = ax + b in the specific "range" - in between two adjacent vertices - in the code (equation of the line going through two points), while you feed "a" and "b" calculated outside of code. It's basically the same thing, though my "lazy" approach costs processor time, while you feed ready to use values directly in the code, so it's as fast as it gets. Good idea, the more I think about it the more I like it. I wanted to be lazy, but perhaps it's a bad strategy.

 

Oh, and it may be bad for one other reason, as I can see now... I put those example tables from my code into Excel (picture attached). And look what happens... it's a freaking straight line for the most part! Except for the very top, where there's a single elbow/corner (I call them "corners", you call them "elbows", whatever). So I could simplify it to "one elbow" only. Damn...

 

And it's not the end of the problems, I've just noticed. Something seems seriously wrong with those tables. I assumed that ED use polygonal chain (I think that's how it's called in English) to make non-linearity, which may or may not be the case. I can't check it now (I'll do that at home), but my example tables above I THINK come from P-47's fuel gauge - 270 gallons look like the Jug. If that's actually the case, it's all wrong.
For example, the table says that for value = 0.666 (66% of the needle travel range, as I understand it) it should read 200 gallons. It doesn't. 200 gal is more or less in the middle (as if it was for value... about... 0.550 or so, 55% of the needle travel). Picture attached.
Another problem... since this table defines, for the most part, a more or less straight line and - if you look at the gauge, 100 gal is at about 25% of the needle travel, then 200 at about 50%, 270 at 100%, so it's NOT a straight line at all.

Hmm... maybe you have the correct answer to that - maybe the variable itself is non-linear, just as the arispeed in F-16 - which you have discovered. Excellent clue, thank you!

I will check at home if this function works with the Jug's fuel gauge.

 

EDIT: Wait... what is this "modelViewer"?

 

Edited July 16, 2021 by scoobie

[scoobie]

Just an update to close open questions.

I did test it, it works, but actually I needn't have tested it
If one looks around in mainpanel_init.lua for P-47 you can quickly find other gauges that have linear scale in the file, for example:

 

-- Variometer gauge
Variometer            = CreateGauge()
Variometer.arg_number = 29
Variometer.input      = {-6000.0, 6000.0}
Variometer.output     = {-0.6, 0.6}
Variometer.controller = controllers.Variometer

 

while this gauge as seen in the cockpit is clearly non-linear (not a surprise in a VVI), so apparently the variable 29 is non-linear itself.
As simple as that.
Hence, everything works, I needn't have worried.

 

Now, if anyone prefers lazy approach, modify the first "if" - to my (VERY SHALLOW!) knowledge of Lua it should be this:

 

  if current_value <= raw_tab[1] then
    return final_tab[1]
  end

 

instead of this:

  if current_value <= 0 then
    return 0
  end

 

in this way the function should be good both for "unidirectional" gauges (going from 0.0 to 1.0) such as some airspeed indicators, fuel reserve gauges etc. and "bidirectional" (going, for example, from -1.0 through 0.0 to 1.0) such as VVI's etc. Without this modification it's good for the former type only.

 

As for the Mi-24, it seems your numbers in the script are doing just fine, see comparison: columns A and B are from mainpanel_init.lua, while column C is what gets out of your code. Very good match until above 400 km/h - is this what you call "huge error"? If so, than nothing to worry about, technically there should be another "elbow" there, but since it doesn't matter as the pilot is just about to die (as you noticed above yourself), than yeah - it's all good

 

Edited July 16, 2021 by scoobie

[Bailey]

You poor child, not using model Viewer! This must be addressed at once! Go to DcsInstallLocation/DCS/bin and you'll find something like modelviewer.exe. Launch it. Then Open a model. Navigate to DcsInstallLocation/DCS/aircraft/<pickAircraft>/cockpit/shapes/aircraftName.edm. The model of the cockpit should load. Now find the "show arguments list" button. Now while in the cockpit click the button on the toolbar with the running red stickman. You'll see everything animate. The trickiest part is knowing which one of the few hundred arguments go to which stwich, light, or guage. Trial and error is the main way of finding out unless someone else has written them down in DCS-ExportScripts, for example.

 

I'm busy, so that's all I can say for now. Looking forward to diving into your posts later. 

[scoobie]

Wy...w...wut?.... Why didn't anybody called me earlier? I had no idea such thing existed at all!
THANKS!
Ooo... this thing is cool...

 

EDIT: THE FORUM'S GONE NUTS! Strange things are happening here since... 2-3 day ago.

In my previous post my "EDIT" disappeard (the one asking about modelViewer)... but I haven't edited the post and deleted the text, the forum itself would show when I did it.

Edited July 17, 2021 by scoobie