SUL37

Simulator weekend

2010-12-10T10:46:00.000+01:00

Last weekend all developers, instructors etc involved in the SUL35 and SUL37 projects met at the annual simulator weekend. The SUL37 is currently unavalable as the bus is stored for the winter. However the Sul35 is becomming better and better, and now we even have three screens. That makes a huge difference both for the feeling and situational awareness.

Second move

2010-02-25T11:07:00.000+01:00

I've now moved for the second time in half a year, and I hope it is the last time for a few years. I've also got a new job so there has not been very much done on any of the simulation projects. At the moment my computer is standing behind a wall of boxes and are inaccessible. But the good news is that the new apartment is big enough to have one room as a dedicated office, so when I get everything up and running I will be able to work relatively undisturbed. However that is still much to do before I get to that point. Walls to paint, shelves and lockers to be assembled and tons of stuff to be places where it belongs. I hope this will not take too long as I'm itching to get back to FSW.

Weapons and multiplayer

2009-12-07T20:21:00.002+01:00

I spent this weekend flying in our cockpit simulator SUL35. You can read about it here (unfortunately only in Swedish). Except for having fun I also managed to find the main problems with implementing multiplayer support for FSW and conceptionally solve them. While it is far from anything working, I feel that MP is very much possible and will be even better than I first imagined. Still there is a lot to do before I can confirm that my ideas really works.

FSWControl

2009-10-14T13:12:00.003+02:00

Some of you might wonder why there hasn't been any updates for a very long time. The simple answer is that I've quit my job, I'm looking for a new one, I've sold my car, I'm trying to sell my apartment and I'm moving right across the country to Stockholm. Why? Well, what don't you do for love ;)

So except for the obvious reason that I have very limited time to spend on FSW, I've also very limited access to my computer as it has been moved to my new home while I'm still in Gothenburg. Anyway, I've actually been able to so some work on a software that was first only intended as a test program for the interface of FSW. Stuff like reload weapons, fire weapon, set target and so on. This was something I could do on my laptop without access to FSX.

However it soon grew to something larger than what was first intended. A GoogleEarth view was added and I started to plot the objects in the FSX-world. And soon I was manipulating stuff in the simulator, such as placing targets where I wanted them, changing weather and visibility and so on. I also found a bug in FSW this way. It turns out that FSX do not destroy my weapons when they go outside the "bubble" as it does with all the AI objects. When the simulator had been turned on for a long time, I discovered the missiles I fired the day before was plotted in the GE view somewhere over the northpole. And half a day later they where somewhere over South America. that bug would have been hard to discover without this program.

Here is a film showing the program used together with our Draken cockpit simulator:

Vacation

2009-08-10T22:00:00.002+02:00

Just got back from the beautiful Loire valley in France. Lots of châteaus and lots of wine tasting. So not much have been done on FSW for a few weeks. I'm quitting my job and moving to Stockholm so I don't know how much time I will have this week either. But I will post here as soon as I have anything to post.

More FSW

2009-06-16T17:37:00.011+02:00

Since my last update I've got a lot of questions about FSW. I hope you understand that I can't answer all of them. Partly because lots of things are still to be determined, but also for commercial reasons.

First I'd like to reiterate. this module will NOT destroy your civilian simulator experience. You will not be forced to install it and no one will be able to shoot you down in multi-player unless you have it installed and have actively chosen to use it.

This brings me to the first question: multi-player.
I don't want to reveal much about multi-player at this moment. All I can say is that I have identified problems and pitfalls, and they are conceptually solved, but the current version do not support MP. Part of the solution is to have a client-server solution parallel to the MP-functionality in FSX. So yes, MP is very much possible, and it will be supported, but it might not be in the first released version.

Second question: How will FSW be licensed?
At the moment I'm working with the idea of licensing the module to payware add-ons on a per copy basis. That means for you as a costumer that you will not have to purchase FSW. It will be free to download but will only work with licensed aircrafts. Weapon enabled aircrafts might cost slightly more than other ones due to the license fee. But that is entirely up to the company that is selling the aircraft.

At the moment I'm not going to make it work with freeware and other non commercial add-ons. Why? Because this project is taking a lot of my spare time and resources to develop, so I need to get something back from my "investment" to make it worthwhile. Hopefully that will help me develop FSW further and add more features in the future and make it work even better. But it's also a matter of ensuring that FSW is implementing with the add-on correctly, and in a way that is user friendly. Though I'm not totally closing the door to making it free for non commercial add-ons, very much like the license for FSUIPC works.

Will FSW be able to have multiple active pylons?
Yes and no. To make a long story short. FSW will eventually support AMRAAM and other modern weapons. But multiple target following is more a matter of the add-on aircraft systems than anything special FSW has to do. FSW will be released in new versions continuously. Which means that if a feature is missing in the first release, it might be added in the second, or the third and so on.

Will FSW be extendable with a DLL for more weapons?
No, not initially at least, and probably never. I want to keep a high quality and ensure that the add-on is stable. When multi-player is added it is also important to keep the integrity of the module. Further more, there is no reason for it really, since I will continuously add new weapons and features.

Finally I would like to repeat that FSW is developed iteratively, which means it will be release as soon as possible with a minimum of functions, and then continuously evolve into a increasingly complex program.

FSWeapons update

2009-06-10T10:20:00.005+02:00

Since I released the film showing FSW in action I've got a lot of response. In some forums I was expecting more "You bastard, you've destroyed my civilian simulator". But except one or two comments about being shot down online by some random kid, most comments have been very positive or even downright ecstatic.

The number of visits to this blog has risen enormously, so I feel some responsibility to post more regular updates. I would like to start by explaining what I am doing right now.

At the moment FSW is in a stage were it might be called a technology demonstrator rather than anything close to a product. So the most important thing now is to clean up the code and address the flexibility issue. The final product will implement any type of weapons, air to air, air to surface, and even surface to air. New weapons is supposed to be easy for me to add, but that requires that I have a structure in the program to handle it. The version used in the first released film has a very hard connection to the sidewinder. My internal simulation of the weapon environment and connection to the simulator is directly connected to one sidewinder object. Once it is released and placed in the queue for released weapon another ready sidewinder object is created, hence giving the shooter an unlimited supply of sidewinders, and sidewinders only.

What I'm doing now is to create a structure with virtual pylons that can hold any type of weapon and handles the communication with the weapon. It will also keep track on what pylon is the active one. Further more, I will take some of the code from the sidewinder class and distribute it to more general classes that the weapons can inherit from. Rocket propulsion in one class, guidance in another, calculations of impact in yet another one and so on. This will make it easy to put together new weapons by inherit the proper base classes and then glue it all together with some code specific to that weapon.

While all this is very important for the stability and expandability of the program, it doesn't really give me anything to show. So you'll have to wait some time before I'll post any new films showing something being shot at.

That is all for this update. If there is anything specific you want me to write about next time, please leave a comment.

Guided weapons in FSX

2009-05-27T12:00:00.010+02:00

Will we ever seen someone make guided weapons in Microsoft Flightsim?

Yes, it has been done some time ago. I've been working on a general weapon module for FSX for a while (remember this?), and I feel it's time to reveal some of my result. At the moment I have only implemented a simple AIM-9B but the main focus is on the modularity of this addon. It is done so that any weapon can be added without too much programming. There is still very much left to do before this is even near a beta, but it looks promising so far. Don't you agree?

Tracking target in PS011A

2009-03-18T13:42:00.003+01:00

I've been working hard on implementing some very interesting stuff in the radar simulation for SUL35. I've achieved a fairly good visual simulation of a CRT radar screen with the appropriate fade. Target plotting is also implemented and several different modes are all but finished. Soon I will start working on target lock on. I also have another neat feature for FSX I conjunction with this that will reveal at a later point. Stand by for a nice surprise in the near future.

Here is a film showing some of the new features in the radar.

Radar indicator for J-35J

2008-11-10T12:33:00.005+01:00

As the Viggen simulator is placed in winter storage work has begun on programs for the Draken simulator. Most notably is the radar indicator.

Due to the problems we've had with using an old CRT TV monitor for the radar in SUL37, we tried a different approach for the SUL35. A small and cheap LED projector as back light for the radar display seem to do the trick. We've got a great source of information about how this radar worked. So we'll hopefully have this unit up and running and plotting targets in the sky in no time. The fact that we're using FSX for the SUL35 makes it even easier since it allows me to use SimConnect that presents nice functions for importing positions of other air planes.

However, the asynchronous calls used in with SimConnect presents a few problems to my FSapp-framework. But it's just a matter of time before those issues are handled. Here is a film of some early test we've performed with the new software I'm developing:

One feature I'll need to add is the latency in the original screen that makes plottings stay visible for some time after the sweep has passed. I first intended to solve this by using the accumulation buffer but it turned out to have some nasty limitations, so I might have to go with frame buffer objects (fbo). But before that I will try to use auxiliary buffers. I'll get back on the result of these tests.

Here is a few films from youtube were you can see the radar in use:
At 3:37 in this film...

...and at 0:44 in this film.

Engine stalls

2008-09-03T15:10:00.008+02:00

Last weekend was spent instructing people flying the Viggen simulator at the air show at the local airbase Säve. Though it was hard work it was also much fun and revitalised my commitment to this project.

We've been discussing for some time how to simulate engine stall, something that was quite common in the AJ37. After some comments on the lack of this feature by some previous Viggen pilots I've now seriously started to dig into this.

From my sources I've found that there were three major types of engine stalls. Reversing the engine with too much thrust at too low speed. Increasing throttle before the engine RPM has decreased enough after throttle decrease or decreasing the throttle to rapidly at high altitude and high alpha. Finally, you can get engine stalls just by flying with high alpha at high altitudes. Engine stalls are perceived as loud "bangs" in the fuselage or when at low altitude as a growl. You will also see a small flutter in the needle of the engine pressure gauge. If the condition that triggered the stall is maintained, the engine will eventually stop.

Engine stall when reversing on ground has a very simple condition. Under 130km/h you risk getting engine stall with high thrust. However I still need to d some more research before I'm able to have a complete condition for this.

I've been told that for increasing or decreasing the throttle at high altitudes and high alpha. A realistic condition would be to start stalls at alpha>20 degrees at 5000 meters and at alpha > 15 at 6000 meters. Below 1000 meters it would be virtually impossible to get engine stalls this way so I chose to set the condition to alpha>30 at 1000 meters. In the end I got a nice curve that could be described with a simple second degree equation. I'll calculate a factor from the change of throttle and let the sensitivity for this value be linear to the alpha and the altitude. And hopefully I will get a nice behaviour for this kind of engine stalls.

Engine stall from just high alpha at high altitude should be quite simple but I only have one value for this so I need to do more research before I start implementing this. What I do know is that at 6000 meters it's reasonable to assume that you will get engine stalls at 18 degrees alpha.

Implementing engine stalls will be an important step towards our goal of realism. Another important thing I wanted to add is inducing engine fire when using afterburner when reversing. However that is not possible in FS2004 so this is a feature that will have to wait for us to switch to FSX.

Finally I got some time for my sim projects again.

2008-08-12T13:07:00.004+02:00

The priority is at the moment (as usually) SUL37. And in this case I'm trying to implement the functionality of reference numbers. Instead of entering latitude, longitude, runway direction etc into the flight computer, most airbases has a number that refer to all needed data. I hope to have this finished in time for the air display event here in Gothenburg 30th-31th August. This will in turn open up for TILS simulation and make instrument landings possible. Unfortunately I suffer from some bad design decisions i took early in the development. I'll see if I'll be able to work around these or if I need to redo some old stuff. I've also moved the whole CK37 to Borland Builder. I'm not sure that was a wise decision though. I did it because the GUI stuff is easy to make in Builder and because it has some vital XML support, but I doubt I really gained that much. In the long run I would like to do my own GUI in OpenGL or something similar and not have to rely on any particular development environment or operating system. However the gain of such a decision could also be argued.

My MFD project is coming along slowly. I've been trying to find a Linux distribution that suits my needs and get it to work with my hardware. So far I've had no luck. On the hardware side, I've done a lot of research about what material to use for the box, how to achieve a good modularity and so on. This has made it possible to start making some CAD drawings to make sure everything fits and to get an idea of how it all will come together. However I have nothing to show at this moment.

I just started to work on weapons for FSX again. Sometimes it's a good idea to let a project rest for a while and get at it again with fresh ideas sometimes later. I've now forgot all the frustration I experienced last time I tried this. I've also decided to ignore the problems with the initial position of fired weapons this time. If I can achieve all other goals for the weapons, that will be a problem I can live with, and perhaps I might solve it along the way anyway.

New projects

2008-02-21T11:36:00.006+01:00

I've started a few new projects for the simulator. First I'm working on a control system for the simulation where it will be possible to remotely change time and weather, move the aircraft to different predefined positions, change the fuel status, trigger faults and lot more. Further down the line it will be possible to change weapons in this system. But the most interesting part is that I've managed to integrate this into Google Earth, which means it will be possible to see the aircraft on the globe and also track it's flightpath. AI aircrafts will also be plotted the same way and it will be possible to add new AI aircrafts simply by point and click. My first tests are promising, but there is still a lot of uncertainties.

Another project I've been working on is porting the CK (flight computer) to Borland Builder. This is mainly due to that I work with this IDE at my job, but also since I find it much easier to do a GUI with Delphi. This is progressing just fine, but I still have a few quirks to straighten out.

The idea to use the original electronics to drive the radar, sight and flight computer fr the SUL35 project failed due to lack of some critical equipment. So now I will have to make a similar software suit for this project that I've been working on for the SUL37. Luckily much of the basic stuff can be reused so it will not take much time to have something running.

My last new project for now is a little bit different. I'm working on making a system for modern MFDs in general with an emphasis on JAS 39 Gripen in particular. I will build both hardware and software. The hardware will consist of a bezel with backlit buttons, a 10.2" widescreen LCD in portrait configuration and a mini-ITX as computing unit with a CF-card as persistent memory. Everything will be built into an aluminum case adapted for easy mounting. The buttons on the bezel will be connected to the processing unit through a common keyboard interface and the whole unit will communicate with the simulator and other units through ethernet connection. At the moment the hardware is not much more than drawings due to lack of funding, but that is just a question of time. The software is under development and much of the framework is finished, but no particular implementations are done yet.

The idea is to have Linux as operating system on this unit and I've had my eyes on an interesting small distribution called MyOS. It is very small and has no X-windows, but it still support OpenGL rendering. Sounds ideal for my purposes. Using Linux has one problem though. I can't connect directly to MSFS. There is no implementation of SimConnect for Linux. So I have to use my own protocol to communicate. Luckily we've been planning this for the SUL37 project, so eventually I will have an indigenous solution. I will post more information about this project as it progress.

SUL37 in the media

2007-11-14T10:48:00.003+01:00

Today there is an article about SUL37 in the newspaper NyTeknik. The paper version is a whole page with pictures and stuff, but the text is also available here: www.nyteknik.se, it's in swedish though.

Weapons for FSX

2007-09-30T13:43:00.000+02:00

Contrary to my intentions I have not posted much lately. I've started my new work and it takes a lot of my time, but primarily much of my mental focus. However I have been able to do some stuff that so far is more like a prototype than anything actually working. I've been working on adding weapons to FSX.

The main idea is to add weapon objects into the simulated world through a SimConnect client, simulate their behaviour (i.e. guidance) and then calculate and project the damage they inflict on other simulated objects. Simple enough. But it's much harder to implement than you might think first.

Due to the fact that the SimConnect communication is asynchronous, I cannot guarantee that the positions for my weapon objects correspond 100% to the other objects in the simulated world. This not a big problem when the weapons are fired since they are then free objects that aren't really affected by any other objects. However, before the weapons are fired, they are firmly connected to the aircraft's hardpoints and to avoid them jerking around, another solution had to be found. My idea is to make all possible ordinance for the aircraft a part of the 3D model. Then my SimConnect client tells the model what weapons should be visible at what hardpoint. When a weapon is released, my program simply tells the model to hide that weapon and replaces it with a new free object at that position. The drawback is that you have to edit the 3D model of the aircraft to allow it carry new weapon types. But compared to the alternative, I think it's acceptable.

The big problem is to position the new object. I'm not getting very good precision. It differs up to a meter or two. To position the new object (the weapon) I calculate a vector to the hardpoint from the center of the aircraft. Then I split this 3D vector into a 2D vector and a difference in latitude. The 2D vector is then used to calculate a latitude and longitude based on the aircraft's latitude and longitude. First I used a totally spherical earth model, since it's easiest and fastest, and I didn't think it would matter that much. But when I didn't get the precision I wanted I switched to WGS84 which is supposedly what FSX use. WGS84 did however not give me that much better precision, if any. I can't figure out where the problem is. Is it my formulas, is it in the communication with FSX or is it possibly a problem within FSX? I don't know if I will spend much more time on this or if I will just I accept the lack of precision. As it is now it's at least better than nothing.

Other things I have worked on is a crude targeting system similar to what you would find in early types of the Sidewinder missile - just point at the target and get a value of how good lock you have. Better targeting and communication, with for instance a targeting radar program, will be introduced later. I've also been able to make the released weapons fly where I want them to, and even make targeted aircrafts loose control and go down into the ground. Engine fire seems to be an exclusive feature for the player aircraft so I will have to add my own smoke and fire, and also make explosions when a missile hits a target. Further down the line I also plan to add multiplayer weapons and AI aircrafts that fights back, perhaps even SAMs and AAA shooting from the ground. But first I need to get the most simple stuff working.

New Project

2007-07-11T12:59:00.001+02:00

The SUL37 project was recently expanded to also include a J35 simulator (SUL35). Though this is an older aircraft which means less systems for me to make programs for, it seems to require the same type of programs. One program for simulating the sight, though not really a HUD I think it was some sort of gyro stabilized reflector sight. One program for the radar and one for some sort of flight computer and simulation of all the systems. I don't really know much about what kind of system the J35 has, but I guess I will find out.

I will not start a new blog for this the SUL35 project, but rather write about it here instead. Now I need to do a lot of research to find out what I need to do. But it will not be necessary to do anything for a while yet. First the mechanical and electrical stuff have to fixed, and that is not my responsibility.

The cockpit is a former Swedish air force J 35J and is fairly complete, except for two gauges and the stick. But this is stuff that will be fixed in one way or another.

My thoughts about radar - part 1

2007-07-03T12:42:00.000+02:00

When I got the opportunity to try the AJSH37 simulator at F7 airbase in Såtenäs, I never got to see the radar display in action. The reason for this, they said, was that it was still classified. I thought that was a little strange since this is an obsolete aircraft that was about to be scrapped and there isn't really anything from this system that is used in the new JAS39, except perhaps for shooting boundaries displayed in some weapon modes. When I tried the AJSH37 simulator at SAAB they also thought it was a bit strange but unfortunately their simulator did not have any simulation of the radar image. I got to see the symbology though. And we've been able to get a few glimpses of the radar image through different showcase movies from the air force, and there are a few scenes showing the radar in the film "Älskar älskar inte".

However, at F7 though I never got to see the radar display itself, I got to see the unit that produced the radar image. It was a locker as large as a couple of fridges. The whole simulator was housed in a room as large as tennis court. Inside the locker there were two large vertically placed silver coated glass plates with the topography of Sweden (and some areas around) etched into i. Basically you could say it was a silvery 3D map of the area of operation. The reason there were two plates is that Sweden is a very long country, and it was easier to handle this way. Just above the surface of this 3D map there was a moving unit with a light source, representing the radar of the aircraft, and a camera picking up the light from a "God's perspective". It might sound a bit strange, but it's actually really genius, considering this sim was built in the early 70's. If you think about it, it is almost the way a radar really works.

Take a flashlight and lay it on an uneven surface, like a gravel road, lightening along the surface. Then view the surface from above. You will notice that all bumps will produce small shadows behind them, all in the direction away from the light source. The parts of the surface receiving light are all visible from the the light source, the other parts are dark. So what you see from above is exactly the same as from the flashlight, only from a different perspective. The radar receiver in an airplane is located in the same place as the sender, "light source", not a few miles ahead and above the airplane. However radar also gives you depth information so it's a piece of cake to translate it into a "God's view".

This is a somewhat simplistic view of how a radar works, not considering refraction, jitter effect, polarization etc. But for the purpose of a Viggen simulator it's good enough. After my visit to F7 I started thinking about the possibility to make a similar radar simulation with 3D hardware, using OpenGL. I will discuss this in part 2.

Been busy

2007-07-01T14:27:00.001+02:00

I've been very busy at work the last 6 months, so not much have been done on the programs. However I'm now unemployed (have a new work starting in September) which means I have a lot of time to spend on this project. Some progress have been made. It's now possible to give the flight computer data about runway directions on takeoff and landing waypoints and channels for the TILS landing system. For normal waypoints two angles can be defined to mark borders. This is then presented in the radar display (CI).

Further more I have implemented a drift in the navigation, which means that over time the navigation system will be slightly off course. And to counter this you can fix your position by known positions. Since I haven't implemented the radar simulation, radar fixes are not possible. So for the moment you can only fix your position optically.

The whole simulator has now been moved into the bus and has been on tour a few times already. You can find pictures of the move here. This is a part of the project I'm not really involved in since I live several hundred miles from where the simulator is located and can not work with it physically. However in the future I will write some about the hardware since it's imperative to know how that works to understand what I am doing. Now that I've moved the programming diary to this blog, I also hope updates will be more frequent.

Radar zoom

2006-08-21T14:18:00.000+02:00

The circle marker in the radar display is now moving according to the current waypoint and it's possible to change between 15, 30, 60 and 120 km zoom. I've been told that the way I control the circle marker with the handle on the radar panel is wrong, but it's not a very big problem since at the moment you can't use this function for radar fixes anyway.

Here is a film of some flying and a landing at a road base.

Long time no progress?

2006-07-28T12:52:00.000+02:00

I haven't updated the blog for some time now, but that doesn't mean there has been no progress. The video marker in the radar display program (CI) is working and you can control it with the handle on the radar panel.

Here is a film showing this.

The navigation system is starting to work and it is now possible to give the flight computer waypoints through the datapanel. The HUD, the radar display and some other gauges is then feeding the pilot with instructions where to fly.

Here is a film of the working data panel and displays.

Typing positions for waypoint by latitude and longitude is a bit tedious so I hope to implement reference number input. I also look forward to do the instrument landing system TILS.

Three programs

2006-02-24T12:36:00.000+01:00

Short about the progress. We now have three stand alone programs (CK,SI and CI) that communicates with each other and the simulator through FSUIPC. We're still bug testing to make sure we haven't lost any functionality when we split the program into three. To communicate with each other the programs use some "free" offsets in FSUIPC that is not used by any other system we use.

The communications between the hardware (buttons, switches and numeric displays) is also handled with these offsets in contrast to emulated keyboard input as we used to have. At the moment we have an 8 bit offset reserved for key codes from the cockpit but it can easily be expanded if 256 different buttons is not enough. This progress means that I can start working on the navigation system.

Flying with friends

2006-02-05T16:42:00.000+01:00

Another film from the cockpit. This time some of the people involved in this project flew an online session together to practise some formation flying.

Viggen full throttle

2006-01-31T16:47:00.000+01:00

Here is a film showing many of the current features in the simulator. Engine startup, HUD, gauges and much more.

Radar display

2006-01-12T12:13:00.000+01:00

The altitude calculations seems to work properly with the exception of the radar altimeter needs some low pass filter. Unfortunately I haven't been working much on the HUD program for some time as all my time has been spent on the radar display (CI). The result is a decent version of this new program with the basic symbology and some kind of eye candy radar sweep. Since there is no radar simulation the sweep has no other function than to give the feeling of having a radar.

Here is a film of the radar display.

Altitude calculations

2005-12-13T12:06:00.000+01:00

The cold turned out to be the flue of the year, so I haven't been able to do much on this project for some time. Now I'm out of the fever fog and have been able to do some research about the altitude calculations and such. This is something I have to work on, but I will get back with more details as I start to implement it.

Low alt warning

2005-12-07T11:27:00.000+01:00

Headache, soar throat, a voice like James Earl Jones and some slight fever. The diagnosis is a cold. But nothing is going to stop me from working on this project.

I had planned to start working on the input into the flight computer, but we decided that we needed to get the low alt warning to work properly. After some research it seems like we will be able to make all the different low alt warnings work. AJ37 i a rather old plane so it had a rather simple system compared to modern aircrafts. All conditions for low alt warning are based on the current height and do not consider any obstacles in front of the aircraft, which would have been impossible or at least not feasible to do in Microsoft flight simulator since there is no functions or variables to get that information. The only ways around that would have been to either have our own set of terrain height data which would probably not match the terrain in the simulator good enough, or we would have to hack the terrain file format in the simulator and that would be a very big project. Luckily we don't have to that.

Apart from the warnings you get altitude hold and some special warnings at different weapon choices, which are not indicated in the HUD anyway, there are two conditions for low alt warning: bottenvarning and metspövarning (translates roughly to bottom warning and pole warning). The bottom warning is induced by the radar altitude falling below 150 m and at the same time is not less than half the altitude measured by air pressure. The pole warning is induced by the current sink rate predicting the aircraft to hit the ground within 7 seconds. There are also some extra conditions for these warnings.

Low alt warning is indicated in the HUD by the altitude pole package is blinking with a 5Hz frequency. This is now done for the pole and bottom warning except that the only extra condition I've implemented is that no low alt warning is induced under 50 m if the landing gears are out. To implement the rest of the conditions I need to do more research.

At the same time I put back the function that turns the HUD off at climb angles over 15 degrees or under -15 degrees. This function has a hysteresis, which means that it's not turned on until the climb angle are lower than 12 degrees or higher than -12 degrees. This function was implemented earlier, but was commented out when I did a restructuring of the program last summer.

I don't know if anyone is reading this programming diary, but if I sometimes am a bit to technical, use terminology you don't understand, I might not be technical enough or there is something you wonder about then feel free to tell me. Maybe some one would like to see some screenshots?

Now I'm returning to the bed so I can get rid of this cold.

I got and idea...

2005-12-04T01:37:00.000+01:00

Some early morning work. Woke up and had a slight feeling that it was actually possible to get an acceleration value from flight simulator. When you wake up in the morning and have an idea, you shouldn't stay in bed. It's imperative to act while the idea is still fresh. And quite right.... there is a value for acceleration over the X, Y and Z axis. Can't understand where I got the impression there wasn't. Then it was just half an hour work to make the time line for rotation order to move.

This means that start mode (or takeoff mode as you would probably call it in English) is 100% finished, and it's time to start working on input and output from the data panel. This is to be able to present navigational data in the other HUD modes.

Speed error indicator

2005-11-29T01:30:00.000+01:00

Today I've fixed the steering of the speed error indicator in landing mode (the little vertical line on the velocity vector). The function has been there since before, but now I've also got the logic for it. The code is written for both 12 degrees and 15.5 degrees alpha, but since we haven't connected the button to change between these, only 12 degrees work at this moment. I've also fixed the warning for critically low speed.

Low nav mode

2005-11-26T01:18:00.000+01:00

the low nav mode that I made earlier is now connected with the new logic and seems after the first test to work as it should. In this mode I've also added the functionality to toggle the course indicator by pressing the ref. omk. button. Now I only have a few things left before I start working on the input and out put from the CK program to the data panel.

Adjustments and settings

2005-11-19T00:56:00.000+01:00

Today's work was primarily to put all possible adjustments to the HUD into an INI-file. This way the adjusments and calibrations don't have to be med everytime the program is started. Additionally I have once again made it possible to use the ref. omk. button, but with slightly modified functionality. And I've also added the possability to tilt the HUD display at takeoff and landing. Since a HUD of this type has a very limited field of view, and much of the interresting presentation at takeoff and landing is positioned lower than you would like in normal flight, it is possible to physcally tilt the reflector glass of the HUD. But to get a proper presentation this has to be accompanyed by a similar tilt in the computer generated image. When the glass is tilted, a microswitch is pressed and the HUD-program gets a signal to tilt the image to a preset position... As simple as that.

Flight computer

2005-11-18T00:33:00.000+01:00

Restructuring of the HUD (SI) program completed. I've implemented some variant of the bridge design pattern to control the different modes of the HUD. I hope that the HUD program this way will be easier to maintain. The hard thing about this project is tat we don't really know from the start how things are going to work. We do have a lot of documentation, but it's far from complete. And when I try to implement one thing we usually find that the way we assumed it worked is simply not true, or at least not the whole truth.

I've now started the flight computer program (CK). But since I haven't worked out the details for the communication between my programs, I included the whole CK program in the SI program with an interface between. This way it should be simple to just lift the CK code to a separate program when I want to. The restructuring means that we've lost some of the functionality. But this is simply a matter of not reaching it at the moment. The code for it is still there.

Since we now have a CK program, I've got the mode selector to work. Start mode is activated and deactivated according to the right conditions.

Reading data from the simulator

2005-10-15T00:25:00.000+02:00

Today I've been able to read the aircraft's current position, which means the commanded course in the HUD is starting to work. This is stuff that should be placed in the flight computer, but since I haven't made that program yet these functions will have to be placed in the HUD program temporarily. However this means that for the moment there will not be anything else than hardcoded waypoints. I'll see if I have the time tonight to make the program change waypoint according to the right conditions.

Project overview

2005-10-12T23:29:00.000+02:00

It might be a good idea to give you an overview of this project to understand what I am doing.

SUL37 is a project to build a simulator based on a real SAAB AJ37 cockpit. We are 6 people from completely different parts of Sweden involved in this project. For simulation we use Microsoft Flight simulator 2004 which is projected on a big screen in front of the cockpit. Our goal is realism and we aim to be as true to the original as possible. Everything in the cockpit is original except for the displays for HUD and radar. Most of the gauges are modified to house stepper motors that we can control from our software, and there is only a few reserve gauges that aren't working so far. To top this there is a pneumatic G-simulation system fitted in the ejection seat.

My contribution to this project is the software for the flight systems. that includes the HUD presentation system, the radar display system and the flight computer for navigational calculations and other tasks. The programming is made in C++ and the graphical presentation is made with OpenGL. The different sub systems will be distributed to several programs on several computers. This way we can use old "junk" computers that don't cost us anything, but the different systems will then have to communicate in some way. To start with we will probably use FSUIPC since this is what we use to fetch data from the simulator, but we might want to make some interface of our own down the line.

The original hardware for the HUD (head up display), or SI as it is called in system 37, is kept as it is except we've replaced the small round CRT with an old b/w TV. Since the TV is slightly larger than the original CRT, and since we need to have a closer focus for the HUD presentation (the simulated world is projected just a few meter in front of the pilot instead of infinity as the real world) we've also placed our own optics between the TV and the HUD. The result is almost perfect.

The radar display, or CI as it is called in system 37, is also replaced by a b/w TV with a green filter and a Fresnel lens in front of it. The radar display presents some navigational aid, a horizon line and a radar image in PPI och B-scope. I have plans for a realistic radar simulation with shadows and proper illumination. But since this is very complicated it is not something I prioritize.

Finally the central flight computer, or CK as it is called in system 37, is the heart of the whole system. The flight computer has many different tasks, but one of the main things is navigational calculations. it controls what is presented in the HUD and radar display, but also many of the gauges. The pilot controls the computer from a panel on the right side.

I will write more about the different systems as I make the programs for them.

SI starting to take shape

2005-10-10T22:36:00.000+02:00

After a few hours in the AJSH37 simulator at the F7 airbase in Såtenäs, and now recently a few hours in a similar simulator at SAAB in Linköping, and after having gone through all not classified documentation we have been able to get our hands on and then some, I think I've got a somewhat good understanding of how the HUD works. The program I made last summer is now restructured and as a result it was easy and quick to add some new HUD modes. What we have now is the startmode (I'm still not entirely sure how to make calculations for rotation velocity though), a somewhat complete nav mode, low nav mode and optical landing mode.

Today I've also made some real progress of making the HUD-program communicating with the simulator.... With one exception. There don't seem to be any variable in FlightSim for climb angle. But I think it should be possible to calculate that from vertical speed and ground speed. This seems to give me correct values, but unfortunately these variables are not updated more than a few times every second which renders them almost unusable. So I have to find some other way. If anyone has any suggestions, I'd be happy to try it.

Finally I started to add functionality for commanded altitude, which seems to work just fine. I also adjusted radar altitude so it is presented correctly. Next step is to finish the commanded altitude, but that would require waypoints I guess, and that is a completely different part of this project.

After some thinking, drawing and calculting I think I've figured out a way to get the climb angle

climbAngle = pitchAngle - (sin(rollAngle) * beta + cos(rollAngle) * alfa)

At least it seems right to me, but if I'm thinking all wrong please tell me. Here is a video of the result