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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel