I'm currently developing the concorde cockpit (slowly), But I've decided
to fix other things as well, at 50,000ft the IVSI jitters so I'm looking
into it. I know very little C++, but from what I can tell at first, the
IVSI data was a bit off. I ended up using these tables:
I added another decimal place to this list:
static double altitude_data[][2] = {
{ 0.00, 0.00 }, //These values are pressure values converted
from (1-delta(alt))*29.92
{ 3.058, 2952.76 },
{ 5.857, 5905.51 },
{ 8.416, 8858.27 },
{ 10.749, 11811.02 },
{ 12.874, 14763.78 },
{ 14.803, 17716.54 },
{ 16.552, 20669.29 },
{ 18.133, 23622.05 },
{ 19.559, 26574.80 },
{ 20.842, 29527.56 },
{ 21.993, 32480.31 },
{ 23.024, 35433.07 },
{ 23.935, 38385.83 },
{ 24.727, 41338.58 },
{ 25.414, 44291.34 },
{ 26.010, 47244.09 },
{ 26.528, 50196.85 },
{ 26.977, 53149.61 },
{ 27.366, 56102.36 },
{ 27.704, 59055.12 },
{ 27.997, 62007.87 },
{ 28.252, 64960.63 },
{ 28.472, 67913.39 },
{ 28.663, 70866.14 },
{ 28.828, 73818.90 },
{ 28.970, 76771.65 },
{ 29.094, 79724.41 },
{ 29.201, 82677.17 },
{ 29.294, 85629.92 },
{ 29.374, 88582.68 },
{ 29.444, 91535.43 },
{ 29.505, 94488.19 },
{ 29.558, 97440.94 },
{ 29.604, 100393.70 },
{ -1, -1 }
};
I figured out what the slope table actually was, It's more correct like
this (I think). The old slope table was somehow 2952.76 (900m to feet)
divided by these variables, and they weren't even that close. It makes
no sense like that, so I'm using inHg per fps.
static double pressure_data[][2] = {
{ 0.00, -0.0648736 }, // Not a guess anymore.
{ 2952.76, -0.0594508 }, // These values are actually
(delta(alt+30ft)-delta(alt-30ft))*29.92
{ 5905.51, -0.0543818 },
{ 8858.27, -0.0496502 },
{ 11811.02,-0.0452403 },
{ 14763.78, -0.0411364 },
{ 17716.54, -0.0373236 },
{ 20669.29, -0.0337873 },
{ 23622.05, -0.0305132 },
{ 26574.80, -0.0274875 },
{ 29527.56, -0.0246969 },
{ 32480.31, -0.0221284 },
{ 35433.07, -0.0197694 },
{ 38385.83, -0.0172583 },
{ 41338.58, -0.0149748 },
{ 44291.34, -0.0129935 },
{ 47244.09, -0.0112744 },
{ 50196.85,-0.00978270 },
{ 53149.61, -0.0084883 },
{ 56102.36, -0.0073653 },
{ 59055.12, -0.0063908 },
{ 62007.87, -0.0055452 },
{ 64960.63, -0.0048115 },
{ 67913.39, -0.00416220 },
{ 70866.14, -0.0035993 },
{ 73818.90, -0.0031144 },
{ 76771.65, -0.0026964 },
{ 79724.41, -0.0023359 },
{ 82677.17, -0.0020248 },
{ 85629.92, -0.0017561 },
{ 88582.68, -0.0015240 },
{ 91535.43, -0.0013233 },
{ 94488.19, -0.0011496 },
{ 97440.94, -0.0009994 },
{ 100393.70, -0.0008692 },
{ -1, -1 }
};
Then I changed the ft_per_s line to this
_speed_ft_per_s = rate_inhg_per_s / slope_inhg;
I do understand the jitter just may be a fact of life because it is an
IVSI, but looking at the inputs it uses, I don't really see why it
jitters so much.
And I cannot seem to get this into the property tree like this (to see
if it jitters too). It's just a debugging line, I'm not actually going
to export inhg/s as it is useless. It does seem to flicker once every 10
seconds or so however...
_inhg_diff_node->setDoubleValue(rate_inhg_per_s);
This is just as jittery with 1/500'th of the responsiveness value, but
atleast I can see it in the property tree. (More debug code).
_speed_rt_per_s = fgGetLowPass( last_speed_rt_per_s, _speed_rt_per_s, dt
/ 100 );
Sorry If I have broken any procedures with the mailing list, This is
also *nearly* the first time I have ever touched C++ (first mailing list
post too), but /src/Instrumentation/inst_vertical_speed_indicator.cxx is
not hard to understand.
The updated table values were taken from my spreadsheet, I calculated
the delta values and plugged them into the formulas to convert them to
inHG difference from 29.92, and finally inHG difference between alt+30
and alt-30 (it gives fps this way, the line is sampled over 60ft
though). The old values might have been sampled over a larger step
perhaps. They are kinda close to (my value) * 2952.76 / 60.
If I manage to debug this (aka get lucky at the moment), I'll create a
merge request with the fixed tables included.
TL;DR: IVSI jitters like crazy and I want to know if I can write a
double on the property tree without filtering it through fgGetLowPass.
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel