SUL37 in the media

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

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

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

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

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

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?

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

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

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

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

Radar display

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

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

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...

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

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

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

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

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

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

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.