martinboehme

Hi Nick,some destinations I can recommend in terms of there being good freeware scenery available:KBOS (Boston)VHHX (Hong Kong Kai Tak)VHHH (Hong Kong Chep Lap Kok)Cheers,Martin

Ah...! Thanks for that, that's more detail than I'd hoped for!Martin

>P.S to WarpD: I'm not trying to offer this DME for pilots,>it's just helping me for my autopilot system calculations. Not>so big deal :)Hm, can jump in here and take this off on a tangent...? ;-)I'm guessing what you want to do is adjust the sensitivity of the autopilot's corrections depending on your distance to the runway... so that as you get closer, your corrections become smaller and smaller...?This is something I've thought about as well (one of those "projects I'd like to do when I find the time" is a custom autopilot), and I've wondered how autopilots do it in the real world. Computing a "fake" DME is something that obviously can't be done in real autopilots -- so how do they deal with this? This is something I'd love to know... if anyone has this knowledge, please share it!I'm guessing that real autopilots do one of two things, depending on their level of sophistication:1. Just ignore the fact that LOC and GS get more sensitive the closer in you are. Adjust the gains in the autopilot controller until it works "reasonably well" between say ten miles out and 2/3 of a mile out (i.e. CAT I decision height).2. Use radar altitude as a surrogate for "distance to the threshold" -- this is probably a good enough substitute for adjusting the autopilot gains, and it's going to get more and more accurate the closer you get (CAT II/III even has certain guarantees).Has anyone got any real-world knowledge on this?Cheers,Martin

>Presumably the code section is smaller and in blue because>you used the {code} script tag to preserve the formatting:Yep, that's just what I did...>For some reason though, it doesn't seem to switch back to>"normal text" even after the {/code} closing tag!So I guess it's just a known bug and I wasn't doing anything wrong?

Sure... as a simple example: HMENU hmenu;UINT id;HWND hwndFS;// Let x and y be the position on screen where we want the popup menu// to appearint x=50, y=50;// Create the menuhmenu=CreatePopupMenu();AppendMenu(hmenu, MF_STRING, 1, "One");AppendMenu(hmenu, MF_STRING, 2, "Two");// Find window handle of the MSFS windowhwndFS=FindWindowEx(NULL, NULL, L"FS98MAIN", NULL);// Show the menu. The ID of the selected item will be returned in idid=TrackPopupMenu(hmenu, TPM_LEFTALIGN | TPM_TOPALIGN | TPM_NONOTIFY | TPM_RETURNCMD | TPM_LEFTBUTTON, x, y, 0, hwndFS, NULL);// Destroy the menuDestroyMenu(hmenu); This would then return either 1 or 2 in id (or 0 if the user cancelled the menu), and we can then perform the appropriate action.I just cobbled this up (my code constructs menus dynamically, so there isn't anything I could lift directly)... so the code isn't tested, but it should work, possibly with a few quickly corrected compiler errors.Cheers,Martin

Thanks for letting me know! By the way, my browser shows the text below the code snippets in blue and in a smaller font -- do you know how I can avoid this happening?

Update: My previous post was a bit premature... Turns out the technique is not very robust. For example, if the user switches to a different view, the frame counter will stop counting... menu selections etc. can also cause the technique to go wrong.However, I've since discovered a different technique that doesn't seem to suffer from these problems. The idea is to change a single pixel on the screen, then on the next PANEL_SERVICE_PRE_DRAW call, check to see if that pixel has been overwritten by Flight Simulator. If so, the front buffer is currently being displayed on the screen, and we can open the menu: case PANEL_SERVICE_PRE_DRAW: if(wantToShowMenu) { if(!haveSetPixel) { // Change a pixel on the screen hwndFS=FindWindowEx(NULL, NULL, L"FS98MAIN", NULL); hdc=GetWindowDC(hwndFS); colorref=GetPixel(hdc, 0, 0); colorref=colorref ^ 0xffffff; SetPixel(hdc, 0, 0, colorref); ReleaseDC(hwndFS, hdc); // Remember the color that we drew colorrefDrawn=colorref; // Remember that we've set the pixel haveSetPixel=true; } else { // Check if the color of the pixel now is different than // when we set it... hwndFS=FindWindowEx(NULL, NULL, L"FS98MAIN", NULL); hdc=GetWindowDC(hwndFS); colorref=GetPixel(hdc, 0, 0); ReleaseDC(hwndFS, hdc); if(colorrefDrawn!=colorref) { wantToShowMenu=false; ShowTheMenu(); } } } break; I'm hoping this code should be more stable -- I can't currently think of anything that could go wrong here, but who knows what further testing will uncover...MartinEdit: Switched off emoticon option

Hello everyone,just wanted to share a discovery I've made. I'm currently working on a C gauge where I want to display a context menu when the user right-clicks on the gauge. The API call to display this kind of menu is TrackPopupMenu(), and in windowed mode, this works just fine. In full screen mode, however, the menu only appears half of the time; the other half of the time, the menu seems to be "active" but is not displayed.After some searching on the Internet, I found that the reason for this is that Flight Simulator is constantly switching between two graphics buffers when it does its rendering, whereas GDI always draws to the same buffer. So if I get lucky, the GDI buffer is active when I open the menu, and it gets displayed; if I'm unlucky, the other buffer is active, and I don't get to see the menu.There are a couple of API calls in DirectX to make the GDI buffer active before trying to display a dialog or menu -- FlipToGDISurface in DirectDraw and SetDialogBoxMode in Direct3D. However, to be able to call these routines, I would need to have access to FS's Direct3D interface, which I don't.However, I've come up with a hack that does pretty much the same thing. Figuring that FS switches buffers every frame, I decided that I would just count the number of frames from the point when FS initializes its rendering surfaces. I should then display the menu only on even frames, when the right graphics buffer is active. To paraphrase the code: case PANEL_SERVICE_PRE_INSTALL: frameCounter=0; break;case PANEL_SERVICE_PRE_DRAW: if(wantToShowMenu && (frameCounter%2)==0) { wantToShowMenu=false; ShowTheMenu(); } frameCounter++; break; And then I set wantToShowMenu to true in the mouse handler when the user clicks the button. PANEL_SERVICE_PRE_INSTALL seems to be the right place to reset the frame counter because it gets called when switching between full screen and windowed mode and when the window gets resized.Admittedly, this is a monstrous hack, but it seems to work, and I can't think of any other way to do the same thing. I haven't tested to see if it's graphics-driver dependent, but I'm hoping that it's not.I believe a similar technique could maybe be used to draw overlaid windows in FS, similar to what FSNavigator and FSInn do, though I haven't tested this. The idea would be to respond to a WM_PAINT by validating the client area (without doing any actual painting) and setting a flag that would cause the actual painting to be done in PANEL_SERVICE_PRE_DRAW.Hope this helps some of you who may be grappling with a similar problem...Cheers,Martin

You're right -- FMCs _are_ complex...If you want to get an idea of how these things can be implemented, take a look at Alex Wemmer's vasFMC, which is a pretty comprehensive open source implementation of an Airbus FMC (and it has a Boeing-style nav display, too). Version 2, which will include a lot of new features, is currently in alpha:http://forum.vas-project.org/viewforum.php?id=2vasFMC is a standalone program, but a gauge implementation is planned for the upcoming version 2.As for documentation, the FMC manual or FCOM is probably a good place to go for all the "little details"...

Bjoern,PID cotrollers are pretty much the standard method for building autopilots... so they should definitely be up to the job.Not that I have any practical experience with autopilots (I've been thinking of getting my hands wet for a while, though), but it sounds as if your gains need some tuning. Specifically, if the controller doesn't correct quickly enough when the target speed is reached, it sounds as if the gain for your "I" component is set too high relative to the "P" component. Also, to simplify things, you could try starting out with just a PI controller, then when you've got that working, add in the "D" component if needed for some fine-tuning.Martin

Hi Bjoern,I'd say the problem is that your controller is trying to control the aircraft indirectly through another controller (Microsoft's autopilot). So a) you're introducing extra latency into the system (in effect, you're "twice removed" from the variable you want to control) and :( you're pretty much at the mercy of how well that second controller (in this case, Microsoft's autopilot) is doing its job...So I would suggest that instead of letting your controller act on the vertical speed setting of the autopilot, you let it act directly on the elevator... that should make the behaviour of your controller more predictable.HTH,Martin

10 degrees is the number I remember, too. Just to clarify, that's TAT, not SAT... because TAT is what determines the skin surface temperature. In contrast, the -40 degree number below which anti-ice is not required is SAT, IIRC...Cheers,Martin Boehme

Richard,this isn't about building a conventionally-powered aircraft that just happens to have flapping wings... this is about building an aircraft where, to quote the "How It Works" section on the website, "All of the thrust and nearly all of the lift is created by the mechanical flapping of the ornithopter's wings."Here's the link:http://www.ornithopter.ca/how_it_works_e.htmlCheers,Martin

Hi everyone,I've been working on an algorithm for computing and displaying flight paths in an FMS, i.e. with the right "curves" at flyby and flyover waypoints. I've put up an article about this here, if anyone's interested:http://www.martinboehme.de/fs/fms_flight_path.pdfComments are of course welcome!Cheers,Martin

Been doing some more work on this... I've changed course slightly and decided that I probably won't crack the question of how signal strength gets computed any time soon. Instead, I'm going to reimplement the VOR and ILS functionality, except for the signal strength computation... I can then have one NAV receiver cycling through all of the relevant frequencies, periodically checking their signal strengths and coordinates (in case we've come in range of a different VOR station on the same frequency).My plan is to have NAV1 doing this cycling -- I've done some tests, and MSFS seems to take about a second to update the NAV information when I change the frequency, so that would mean a four-second update cycle if I've got a DME hold on both NAV sets. I've got to do the cycling on NAV1 exclusively because I need NAV2 for doing audio idents of NAV stations.I've got the VOR and ILS code just about finished; there's just one small issue left to deal with, the localizer beam width -- see the discussion over on Pete Dowson's forum:http://forums.simflight.com/viewtopic.php?t=61197The problem is that different localizers have different beam widths, and that value can't be read via FSUIPC. Pete has identified a mystery two-byte field that may contain the beam width, but if that doesn't work, I have a Plan B: In principle, I can compute the beam width from the current localizer deviation (as reported by MSFS) and the angular deviation (which I compute myself), but that only works as long as the needle isn't pinned. And in the standard ILS interception scenario, the needle starts off pinned, and then when it does start moving, it starts moving pretty fast. With NAV1 taking about four seconds to cycle through the frequencies, it can be four seconds before I realize that the localizer has come alive. That's a bit too much... However, NAV2 can come to the rescue and monitor the localizer in this situation, since it's pretty unlikely that the ident feature will be in use during the interception. So that problem is pretty much covered, too.There is one open question, though: Does your panel use the standard autopilot functionality, or do you have custom autopilot code? If you're using the standard autopilot, then it's going to get seriously confused if I start cycling the NAV1 frequency around... so in that case, I would have to write some custom autopilot logic, too. Keeping my fingers crossed that you already have custom autopilot code in place...Cheers,Martin

>FS models three types of VORs...High, Low, and Terminal. Um... yeah, you're right. Didn't remember what the names of those types were (it's a couple of weeks back that I did the measurements) and I wanted to restrict myself to two types to keep the description simple... but I actually measured both Low and Terminal VORs (previously, I had been measuring only High VORs), and they are both different from High VORs. They are similar to each other, but not identical...>Let's assume that the unattenuated signal strength at the>station is a constant for each type (why wouldn't it>be?)>>Then if we know the means to compute the signal strength for>each type, all I have to do is compute the expected signal>strength for each type of station, and then compare it to the>value being reported by FS. That should give us the ability>to determine what kind of station it is, and how to emulate a>signal coming from it locally in the panel.Yes, that's a good idea! There will still be the small risk of encountering an ambiguous situation where the expected signal strength for two types of station is the same (or almost the same)... this can happen because the Terminal VOR, for example, starts out with a higher slope, then bottoms out earlier, while the High VOR starts out with a lower slope, but bottoms out higher... so at some point, they intersect...But the probability of encountering this situation should be fairly low...>The multiplexing will be needed anyway, maybe every 5 sec or>so, just to make sure that the navaid on the freq being held>is still the one we're emulating...necessary in areas of>overlapping coverage where capture effect dictates which>station is displayed.That's a good point... I had thought of this, too, but decided to ignore it (on the grounds that DME hold will usually be used in a terminal environment, where it isn't likely we'll be straying very far from the "held" VOR anyway -- a bad hack, I admit). Question is, if we're multiplexing anyway, why don't we just decide to be lazy and let that handle the signal strength issue as well? Not as intellectually pleasing, I admit... but it would take care of the problem of the mystery constant c, which is also still open.>So what we'll need is the function for each of the three types>of VORs in FS...then I'll bet I can make the rest work in>software.I'll see what I can come up with. Can't make any promises as to when I'll be able to work on this, though...Martin

Bob,yep, it's the inverse of the distance, not the square of the distance. h and c are in feet, and d is in nautical miles.Unfortunately, though, all of this may be moot... I've made some more measurements in the meantime, intending to unravel the mystery of the constant c. I found out something else in the process, though...All my measurements up to that point had, by coincidence, been on enroute VORs. I then made a few measurements on short-range terminal VORs, and it turns out that they have different slopes in the function f and a different "cutoff" height (i.e. the height after which the signal becomes constant). That cutoff height is around 1000 feet for terminal VORs, compared to 5000 feet for enroute VORs.This pretty much kills our prospects of being able to work out the "innate" signal strength of the station. Say we're at 3000 feet and measure a certain observed signal strength. Depending on whether we have a terminal VOR or an enroute VOR, we would have to use a different formula (i.e. a different case in the formula for f(x, h)) to work out the "innate" signal strength. But we don't know whether the VOR is enroute or terminal... so we're stuck.The only possibility I see of really solving this problem is to use a "multiplexing" approach on one of the VOR receivers: Every second or so, we tune to the frequency of the "held" VOR to check its signal strength, then tune back to the station we're really supposed to be receiving. Of course, that will cause us to lose reception of the "non-held" VOR station for a certain amount of time, which is probably not acceptable if we're flying an ILS approach. So we'll have to implement a function that takes the GPS coordinates of the VOR station and computes the VOR radial or ILS localizer and glideslope deviation so we can have that information available all the time, even when we're tuned over to the "held" VOR to check its signal strength. That sounds like a bit of work... ;-)If I find some spare time at some point, I'd like to look into implementing such a system (and probably making it available as a library for others to use), but I probably won't get round to it anytime soon...So it looks as if you'll have to put off the DME hold functionality for the moment or implement it using a fixed reception range...Cheers,Martin

Rob,the German language FS magazine FlightXpress did a series of articles on Innsbruck approaches and departures a few issues back, and in response to that I tried that departure a few times, though in the 737 Classic by a company that shall not be named here... ;-) I wouldn't expect the PMDG to handle much differently, though.You can find charts for the departure on www.vacc-sag.org, though it's all in German -- try this page:http://www.vacc-sag.org/?PAGE=airport_overviewFrom there you should be able to get what you want even if you don't understand German.I would suggest that you should delay acceleration at the very least until you have completed the turn. Two reasons: You want to keep the turn radius small, and you want to achieve the maximum climb gradient. 175 knots sounds a bit too high... Edit: On second thoughts, that's coming from the -300 at relatively light weights, and if you're maintaining V2+20 in a heavy -800, then that could well be in the ballpark of 175 knots...Another important point: Once you're airborne, you should initially make a slight turn to the _right_ to a heading of about 270 -- this will give you extra manoeuvering space to the left, and you'll want all the space you can get.You definitely shouldn't be losing altitude during the turn -- make sure you "nail" the airspeed for the initial climb all the way through the turn.Have fun... and try a Salzburg runway 16 departure as well...Martin

Bob,didn't intend to imply that I was "dumping this in your lap" (if that's how it came across)... I hope to research this to a point where I can give you working code to work with... the elevation issue seems to be a bit of a stumper, but I hope with some more research that I'll be able to crack it...Cheers,Martin

Michael,> But the wing lights should be off when not on the ground, right?That's entirely up to you -- they can be controlled from the cockpit. ;-) I'm not entirely sure what the policy regarding use of the leading edge lights is -- I guess their primary purpose is to be able to inspect the leading edge for ice formation, but I've heard they should also be turned on at night (below 10,000 ft?) for better visibility.Regarding the landing lights, those should be on below 10,000 ft to improve the visibility of the aircraft -- both for other aircraft and to avoid birdstrikes.Cheers,Martin Boehme

Pete,ahhh... thanks for "enlightening" both of us... ;-)Martin

> I was completely sure, that all modern jets are equipped with gear doors. Is the 737 the only one of that kind or are there more (Airbusses or something)?Well, to give the 737 credit, it does have partial gear doors... they just don't cover the wheels themselves. I guess the idea is that it makes the design simpler (and lighter!) without incurring too much additional drag.The Embraer family of regional jets are pretty much the same:http://www.airliners.net/open.file/1196788/M/http://www.airliners.net/open.file/1178590/M/http://www.airliners.net/open.file/1193107/M/http://www.airliners.net/open.file/1194420/M/There may be others... the Airbuses all have "proper" gear doors, but maybe some bizjets or regional jets do it the 737 way?> They were white and located, if I'm not mistaken, between flight deck side windows and the passenger door.Hm... the 737 shouldn't have lights there, as far as I know... that screenshot would definitely help.Cheers,Martin

Michael,> The wheels were retracted, but could still be seen stowed in the fuselage when watching the plane from down.That's just the way the 737 is... see this photo for example:http://www.airliners.net/open.file/0771144/M/See here for more information:http://www.b737.org.uk/landinggear.htm> Then I noticed, that two exterior light on both sides of the fuselage were still on, though I had switched the landing lights off after crossing 10000ft.What colour were they, and where were they located, exactly? Could be the nav lights or strobes...Cheers,Martin Boehme

An update: The DME1 elevation issue was due to a bug in my code. I checked the values at that offset using FSInterrogate, and it worked perfectly. So that problem's resolved.Also, I've collected a couple more data sets, and the interesting thing is that for two data sets that I collected while the aircraft was over water, the values for c match almost exactly (to within about 1.5 ft). Of course, water is completely flat... so maybe MSFS really is using a slightly different way of calculating ground elevation internally, which doesn't show up when the aircraft is over perfectly flat terrain (in this case water)?Martin

Bob,I've been working on the signal strength issue, and I've got it almost nailed, but there is a slight random variation that seems to defy explanation -- which is kind of frustrating. Anyway, I thought I'd share what I've got so far in hopes that maybe you or someone else can come up with an idea.The good news is that the algorithm is less involved than I had originally feared. The three variables that enter into the calculation are the station's "innate" signal strength s (or transmission power), the horizontal distance d along the ground from the station to the aircraft's current position, and the height h of the aircraft above ground.The strength s_recv of the signal received by the aircraft can then be computed as follows:s_recv = f(s/d, h)where f is a function that attenuates the strength of the signal the closer the aircraft gets to the ground:f(x, h) = if h <= 218+c ft: x*0.0004*(h+261+c) if 218+c < h <= 4887+c ft: x*0.000173*(h+890+c) if h > 4887+c ft: xThe constants are derived from linear regressions that I ran on several sets of test data. The regressions fit the observed data beautifully -- the residual error is in the range of one or two units of signal strength, for signal strengths that range in the thousands.Unfortunately, however, the equations contain a constant c, which I have to set to a different value for every set of data (where a set of data is the signal strengths recorded at the same position for different heights above ground). The values for c that I have observed are not large -- they range between -86 feet and 88 feet -- but they are large enough to make an accurate estimation of the "innate" signal strength of the station impossible when the aircraft is close to the ground.The obvious question is: Why am I so sure that h has to be height above ground? Unfortunately, I have been able to disprove the two obvious alternative hypotheses that come to mind:Alternative hypothesis 1: h is not the height above ground at the aircraft's position, but height above the elevation of the station. I disproved this hypothesis by taking measurements at two different positions, at the same distance from the station, but over different ground elevations (around 1000 ft in one case, and 4000 ft in the other). If h was really measured relative to the station's elevation, I should have observed the same signal strengths at the same altitudes in both cases -- but the signal strengths were wildly different. The formula above explained the data much better, albeit with a variation in the constant c of about 170 feet between the two locations.Alternative hypothesis 2: h is aircraft altitude. This is disproved by the same data mentioned above because, again, the observed signal strengths should be the same at the same altitudes, which they were not.As I say, the model fits the data beautifully as long as an appropriate value for c is chosen for any given location. This is why I am pretty much convinced that the signal strength depends on some form of height or altitude, and not some angle or other alternative value. And the fact that c remains within +/- 100 feet seems to indicate that the ground elevation is involved in some form. By the way, c does not appear to depend in any systematic manner on distance from the station or on the ground elevation itself.The only explanation I can come up with at the moment is that, internally, FS2004 uses some coarser form of the "ground elevation" value than the one that is made available externally. My hope at one stage was that there could be a difference between the FSUIPC ground elevation value at 0020 (which I was using initially) and the one reported at 0B4C (which is an alternative, less precise variable), but again, this turned out not to be the case. The radio altimeter value at 31E4 was a third candidate, but this also turned out to be consistent with 0020 and 0B4C.So I'm kind of stumped here... I'm not ready to let this thing go just yet, but I'm out of ideas at the moment. Any suggestions?MartinEdit: The part of the message after the "code" sections came out in a smaller font, but I can't work out why... oh well... changed it back to use a proportional font throughout, since that seems to be more readable.