Radar indicator for J-35J

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

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.

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

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.