Jump to content

Programer Needed At Aerosoft


Don Hamilton

Recommended Posts

Peter, Ian, Wolfgang Piper, Or somebody,

Mathijs Kok at Aerosoft is looking for someone to build the flight computer for the upcoming Discuss glider. The orginal contractor could not deliver the goods so the project is on hold until he can find someone to program the computer. If you are interested in taking on this task (for pay), contact Mathijis at: support@aerosoft.com

Information about the computer:

Flight Coputer PDF File

Information about Aerosoft's Discuss Glider project:

Aerosoft Forum

This would be a great FSX sailplane if it is ever completed.

Don

Link to comment
Share on other sites

I *might* see if I can do something to help out... the glider's been a long time in development so it can't be that much of a rush. I actually own a C3, the predecessor to the C4 - they're excellent pieces of kit with a very good user interface.

Creating the C4 shouldn't be that big a deal (although I'm not really planning on doing it) because I'm assuming they'd skip all the complexity of computer setup. I reckon there are two major hassle factors:

1) unless you have CumulusX the vario audio is uncompensated which is a complete waste of time

2) the C4 can calculate final glides around multiple waypoints, but XML gauges can't access the flight plan, so this feature realistically would have to be missing unless the gauge was in C/C++ and the code read the actual .PLN file which would be a ridiculous amount of hassle for a simple function. Actually it's worth mentioning the final glide calculation itself isn't exactly trivial, but I think that part is ok in my NETTO vario now.

The other bits of the glide calculator - display volts, outside temp, etc are trivial.

Ian

Link to comment
Share on other sites

I *might* see if I can do something to help out... the glider's been a long time in development so it can't be that much of a rush. I actually own a C3, the predecessor to the C4 - they're excellent pieces of kit with a very good user interface.

Hi Ian,

sad to read that you're not really planning to do it - I'm sure you would have been the right one to develop the C4. As I'm in steady contact with the developer I know about the problems that caused the project on hold. Need more information, just ask (I could even tell you the range of your reward). If you change your mind, just let me know. I'll hand you over all contact information you'll need.

Creating the C4 shouldn't be that big a deal (although I'm not really planning on doing it) because I'm assuming they'd skip all the complexity of computer setup. I reckon there are two major hassle factors:

1) unless you have CumulusX the vario audio is uncompensated which is a complete waste of time

I'm not sure about this one. As far as I got with my research, you could calculate a complete new netto-vario-gauge without touching CumulusX!, or am I wrong? My Idea was to calculate sink/lift by using static and dynamic preassures which i could get from altimeter and by recalculate dynamic preassures from ASI. Does this idea lacks of something?

2) the C4 can calculate final glides around multiple waypoints, but XML gauges can't access the flight plan, so this feature realistically would have to be missing unless the gauge was in C/C++ and the code read the actual .PLN file which would be a ridiculous amount of hassle for a simple function. Actually it's worth mentioning the final glide calculation itself isn't exactly trivial, but I think that part is ok in my NETTO vario now.

That's one of the two points why i dropped thinking about doing it myself. :winks:

True, final glide calculation isn't exactly trivial but by searching for McCready one gets all information, ready formulas and more.

The other bits of the glide calculator - display volts, outside temp, etc are trivial.

Ian

Full ACK.

We'll have to see how this odysse continues - or if it continues. The whole story really is sad but true.

:cheers2: Dirk

Link to comment
Share on other sites

Hi Dirk - I agree totally the sentiment that programming the computer vario is an interesting project - I'll PM you to find out how much cash is on the table - LOL everyone has his price... Regarding your points:

(1) TE, Netto - these absolutely can be done in XML - Peter and I independently did a TE mod to the FSX default vario, and I more recently programmed a Netto calculation. If you haven't got my netto vario I highly recommend it for ridge soaring! *BUT* I'm not clear how the FSX glider AUDIO sound gets triggered, and by default that is un-compensated. Peter does something clever to persuade FSX to play the compensated sound, but I'm not sure what - maybe you can *write* the 'VARIOMETER RATE' value and have that alter the sound, but I don't know. My concern is there is no way unless you drop into C/C++.

(2) Final glide calculation - I have just finished (I think) programming this in XML as another mod to the FSX cambridge vario - I'm now flying with the instrument and as in the real world it's quite interesting to watch on those marginal glides... My code attempts to read both the GPS (distance to next waypoint) and a mission variable (distance to Point of Interest) with the latter taking priority, and then displays the expected arrival height at that waypoint given the current Maccready setting, wind, etc. *BUT* I don't think the information is available to XML to calculate arrival height around *MULTIPLE* legs in the current flight plan. The computation isn't any more complex, it's just unclear to me that it is possible to find out distance and bearing from the next waypoint to the one after (in the flight plan). I *know* it is impossible to know what the next-but-one Point of Interest might be, because missions create these on the fly. *HOWEVER* now I'm flying with the single-waypoint-arrival-height version it is *definitely* value-added to pilots with a sense of real-world competition flying techniques. For what it's worth I've known pilots screw up the multi-leg final glide thing (you can only do so much in the air) so it has it's plusses and minusses.

Ian

Link to comment
Share on other sites

Hi Ian,

I agree with Dirk. You would certainly be the one to develop the the virtual C4 computer. I hope it will be possible for you to do the job or at least develop something that will be suitable. I think the glider project is very dear to Mathijs's heart and I think he would pay you a fair price for your work. The Discus would also be a huge step foward in virtual sailplane development.

Cheers, :smiles:

Don

Link to comment
Share on other sites

... but I'm not sure what - maybe you can *write* the 'VARIOMETER RATE' value and have that alter the sound ...

That's correct, however it is not fully reliable, which leads to the bit squirky sound. Still you can deactivate the vario sound the aircraft.cfg totally and set up your own instrument if you run a dll-gauge (as Max' varios do).

... Final glide calculation ...

You should consider wind vectors here.

I personally use frequently the freeware GPS_LOG on a separate PDA hooked on over serial I/F to FSX GPS output. It does IGC logging, too, btw, and is the same I use in RL too. But there is also a desktop version.

regards,

Peter

Link to comment
Share on other sites

... You should consider wind vectors here. ...

naturlich... it's not a great pic but I have the properly calculated arrival height showing in the bottom of the Cambridge here (the maccready setting is at the top): (by the way if you compare the two vario's you'll see the Cambridge reading netto as well):

The calculation takes into account the bearing and distance to the waypoint, the current wind speed and direction, the polar of the glider, and the maccready setting. So far it seems ok but I'll fly with it a bit more to make sure I've got all the +'s and -'s and the sines and cosines in the right order. For the Cambridge purposes I haven't implemented the ballast value - I'm assuming full water. It behaves just the same as in real-life though - you end up focussing on it as you head towards a difficult turnpoint willing it to rise rather than fall. The fact is with CumulusX, as with real life, external air movements can turn you from hero to zero on a final glide, but if you start with a high maccready setting you can ease off and still make it, unless you've royally screwed up.

Ian

post-16-1214334240.jpg

Link to comment
Share on other sites

BTW, have you figured out the FSX-DG polar, or took it from the original? I have the feeling that the FSX' polar is ridicolously bad.

Cheers,

Peter

True. I figured it out - flew in still air for two steady minutes at each speed and measured the L/D from the IGC trace, testing the error sensitivity too - in FSX it was actually quite easy to get stable at a steady speed for accurate results. I'll post up the results when I'm near them. You're absolutely right - the polar is worse than the published DG figures, particularly at higher speeds. What I didn't do is measure the polar for every speed/flap setting (i.e. I measured the composite polar with -ve flap at higher speeds and +ve at lower) - I'm not convinced the flaps are accurate either. From memory 60 knots = ~43:1 and 95 knots = something like 24:1 fully ballasted (I didn't measure zero ballast either).

What the analysis did do is tell me not to fly the FSX DG faster than about 95 knots !

Ian

Link to comment
Share on other sites

  • 1 month later...

If you're interested, this 'little' project is moving along... so far I've got a working variometer that does pretty much all it is supposed to do, but there's a lot of tidying up still to do. The project required a sub-project of the creation of a FSX/directx sound DLL that can emulate the C4 vario sound - I'm guessing this is exactly what fssound.dll did - the hard part is to continuously vary the wavelength of a waveform without introducing a distortion due to the update cycle (i.e. you seamlessly stretch the cycles using floating-point math on the bitstream you are passing to the directsound API.) The sound is now controllable from within a gauge simply by changing frequency/duration/gap variables.

The SDI C4 reads out all the information you get from the real C4, including climb average and achieved glide ratio, with auto-switching between climb and glide modes. The glide ratio tells you just how inaccurate the polar of the FSX DG808S is!

The 'tidying up' is a lot of work though (re-doing all the graphics, fixing the polar for the Discus, actually connecting the sound to the gauge)

cheers

Ian

Link to comment
Share on other sites

  • 3 weeks later...

Three million man-hours later and the gauge is taking shape. I've written a C++ sound DLL replacing the FSX sound - it's a shame VARIOMETER RATE isn't writable as that would have saved a few days effort. I've just posted to the Aerosoft forum to update the users there, but here are the screenshots for the virtualsoaring.og community:

c4_1.jpg

c4_2.jpg

c4_3.jpg

c4_4.jpg

Ian

Link to comment
Share on other sites

Ian,

The computer is looking great! Now they want to redo the flight files. The computer probably exposes their errors in the Discus's polar curve. I would think rewritting the flight files would be easier than writting the files for the flight computer. Looks like Aerosoft is one step closer to getting the Discus out the door thanks to you. I hope this glider makes it out of the hanger before Christmas. :D

Cheers, :smiles:

Don

Link to comment
Share on other sites

  • 2 weeks later...
If you're interested, this 'little' project is moving along... [snipped the rest of this post]

Hi Ian,

great to hear that sort of news. :respect: I had a phone call from Joachim yesterday. He just informed me about the actual (overall) project status. I'm really looking forward to flying these gliders. But I have to admit that I'm quite curious now. :embaressed:

The sound you made. Would it be available to new (additional) gauges as well? Will it be additional to original FSX sound or will it replace original vario sound?

Have you had to make a lot of compromises? What about the "multiple waypoint problem" - have you found a way to get around this one or did you have to cut it down to "just the next waypoint"?

:cheers2: Dirk.

Link to comment
Share on other sites

The sound DLL I've made is in addition to the FSX sound, just as was fssound.dll - I control the pitch of the tone by altering a variable within the gauge i.e. the gauge has to be written to exploit the presence of the DLL.

For the SDI C4, pretty much the only thing I've compromised on is the calculation of arrival height around multiple waypoints. In effect I guess this means I'm emulating an SDI C4 version 3, not the final version 4 of the SDI software. FSX doesn't make the flightplan available to a gauge via any normal API - just the next waypoint. I've considered using C++ to interpret the underlying FSX files but we'll never ship the product if I do that.

The SDI C4 is a fairly complex product to develop for FSX, and it gradually dawned on me that the FSX project actually means writing pretty much the exact same software that is presumably inside the real device that sold for $1000. In terms of in-flight usage, I'm certain the users will not be able to notice any difference between the interface in the sim and the real thing - there are effectively 20+ cursor/sub-cursor positions and they're all implemented - some were dead easy like 'display outside temperature', while others took days (arrival height/safety margin/maccready setting/bug-on-wings/ballast) to write.

I think users will 'get' the SDI C4 concept very quickly as the simulation is a faithful implementation of the real thing and that has a consistent design. My guess is the users new to gliding and/or flight computers will spend more time getting there heads around our faithful implementation of the C4 *as in a real Discus BT (i.e. Joachim's)*. There are additional external switches on the panel to switch speed-to-fly/total-energy, and a pneumatic switch to select forward static or the pressure from the fin-mounted total-energy probe. If you start the engine without switching the instrument to forward static the prop-wash will drive it crazy.

I won't use any of the code in the SDI C4 development in any subsequent freeware stuff I get back to, but 3-and-a-half-thousand lines of code later means I've pretty much learned as much as there is to know about implementing the gliding calculations within an FSX gauge and that will feed into subsequent developments I do. There has been a *fun* aspect to it (mostly it's a grind) in that if FSX you can create instruments that don't exist in the real world. As my FSX C4 is calculating 'speed-to-fly' continuously in real-time, in addition to using this to drive the audio and vario needle as per the real C4 I've also modified the ASI gauge (just on my dev setup) to display 'speed-to-fly' as a small indicator that runs around the outside edge of the ASI display. So if you glance at the ASI you immediately see the delta between your current speed and the right speed to fly. In cruise you can just fly by chasing the 'speed-to-fly' mini-needle with the ASI - it's so neat I don't know why this hasn't been done before even as an experiment - you can ignore it if you want.

Regarding the .air file config for the Discus I should correct any misunderstanding I could have introduced - at the moment the dev Discus is flying with a 'temporary' air file config - the specific piece of work of tuning a production air file to accurately model the real Discus is yet to be done, so my C4 hasn't added or detracted any understanding of the flight config. I believe it will give the air file developer a better tool to fine-tune the performance model than anything available to previous developers though. In the meantime we're flying the existing FSX gliders with some very inaccurate polars. The FSX DG808S at 100knots, full ballast, full negative flap, has an L/D of........ of......... of........ wait for it.......... 14:1 !

I've got a pipeline of freeware stuff I could do - I was about to release a freeware final-glide-computing vario before getting caught up in this work, although that one was only designed for full ballast and the UI was a maccready knob and that was it. But, when my panel programming for the Discus is done, the first thing I want to do is create another soaring mission - this won't take long though.

Ian

Link to comment
Share on other sites

Hi Ian,

sounds like it was a lot harder to implement than we thought on first sight. But I'm glad you went through it. this Discus(es) will be a definitive "must have" in my hangar. Can't wait for them. Please be sure that the C4 is not the smallest factor for that. :yahoo:

Glad to hear that you're planning a new mission, too. Although still i'm not through with mifflin.

BTW: Let me know if you need ideas for new missions :winks: I could hand you some coordinates for a challenging task or two, if you are interested.

:cheers2: Dirk.

Link to comment
Share on other sites

I could hand you some coordinates for a challenging task

Cool! I've reached the point that the most important work for the mission is choosing well placed turnpoints that take the pilot along interesting scenery, with carefully matched weather that makes for a good task. The final glide is worth particular attention.

My preference is for tasks that are triangles or quadrilaterals because that's what real flights generally are, but if you find a complete set of coordinates (preferably plus suitable weather) then I can fly it and confirm I like it too and I'll be happy to wrap the 'mission mechanics' around it.

cheers - Ian

Link to comment
Share on other sites

a lot harder to implement than we thought

actually, I shouldn't complain as there are half a dozen reasonable computations, like total energy compensation or arrival height computation, but apart from that it's all about programming the 20+ cursor positions and the 130 separate segments that make up the display. Just the tiny 'glideslope graphic' that gives a simple indication of how you're above or below glideslope is six separate images, each of which needing a small piece of code telling it whether or not to display.

The C4 is capable of 'auto-switching' between cursor positions and speed-to-fly versus total-energy based on it's calculation whether you are thermalling or cruising, or you can have a mechanical external switch. Joachim has the physical switch in his Discus (that we're modelling) but I have implemented the C4 algorithm and I expect (but don't guarantee) I'll add an extra sub-cursor position to toggle into 'auto' mode if you don't want the 'realism' of the panel switch... see - there's an unending list of details if you get to them...

Ian

Link to comment
Share on other sites

In the meantime we're flying the existing FSX gliders with some very inaccurate polars. The FSX DG808S at 100knots, full ballast, full negative flap, has an L/D of........ of......... of........ wait for it.......... 14:1 !

Ian

Ian, how did you calculate that. When I flew the DG808S with wind set to zero (user defined, with all the wind layers set to 0 KTS), CumulusX and Simprobe disabled, from 6000ft to 3000ft at 100KTS speed in a straight line, I read the IGC into SeeYou, and SeeYou told me that the L/D was 22:1. Still not good, I guess, but a lot better than 14:1.

BTW I did the same with the Astir I am working on, and that test, flying at 115km/h speed came out with an L/D of 48:1 (wishing that were true in the real world :sideways: ). So I have to include some extra drag an reduce the lift_scalar into the airfile and/or the aircraft.cfg to get it more realistic.

Bert

Link to comment
Share on other sites

my 14:1 was from memory - as my C4 reads it out directly (and I've installed it in the DG808S as well as the DiscusBT) I'll fly it again and check... to program an earlier instrument to get the netto calculation right I had to measure the DG polar before and that time I did the same IGC trick you did - no wind but sim_probe ON so at least I got an IGC file :)

Ian

Link to comment
Share on other sites

no wind but sim_probe ON so at least I got an IGC file :)

Oké, you caught me on that one :blush: . But I can assure you that there were truly no ridges above open sea where I did the test. And having season set to winter, CumulusX showed no thermal- nor wide sink-activity either.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use