Monthly Archive for May, 2010

XGDC emulator and screenshots

Completed some more modules and software. mod_nav now loads the airports and runways database. These databases can be generated from X-Plane’s apt.dat, so the databases will always match X-Plane database.

Also I have created a small emulator, based off SLAVA application for running SASL avionics outside of X-Plane. This emulator supports running the OS, emulates some basic sensor values and stuff like that.

You can download the latest emulator and OS sources here: https://anonsvn:anonsvn@svn.wireos.com:81/svn/xgdc/ (SVN repository)
Right now there is windows version only, and it uses slightly customized version of SASL. Once a new one is released, it will use that instead.

Here are some screenshots:

XGDC basic core

I’ve completed programming the basic OS core, and some support for loading modules. The OS itself is slightly based on the original XGDC, it shares same general outlook, but now internally it is much much easier to write software for.

The message logging now supports multi-line messages properly, and you can scroll through them smoothly. Here’s an example of a very long message (source file read from flash memory, and printed on screen):

There’s also a splash screen module, it allows to display a nice image while the OS modules are loading some data (it supports mod_nav, which loads airports and navigation databases):

XGDC2 realtime OS

I’ve decided to rewrite XGDC OS from scratch. XGDC is the operating system that powers the XS Venture spacecraft.

The new OS is called XGDC2, or alternatively XGDC avionics operating system (XGDC stands for “XSAG GuiDance Computer”). It’s a highly modular realtime operating system that provides various functionality to the aircraft. I have designed it in such way that I would be able to use it in various different aircraft – most of code would be shared this way, so fixing bugs in OS core, or official system modules would allow all planes to be updated with the new software.

Much easier to manage, and it’s very easy to build plane systems by simply customizing various settings. The system is written in Lua. Here’s a list of core system features:

  • Event system and message logging (with support of custom events, for example system error checking)
  • Filesystem and file management (supports reading/writing to flash memory, reading data from ROM)
  • MFD driver (can drive any amount of various MFD screens, provides basic symbol text output)
  • Supports various kinds of input: keypad input, buttons on a MFD screen, keyboard input, touch screen input
  • Page system for running several data pages on a single MFD screen, including default functionality for all kinds of the system input
  • Navigation math (all kinds of utilities for calculating courses, etc)
  • System utilities (resource management, etc)
  • Configuration/platform settings support (customize OS behaviour by aircraft-specific settings files without modifying OS itself). It even supports overriding OS core features

Now core system itself is pretty useless – it doesn’t allow you to do anything. But you can install additional modules by simply dropping them into specific folder:

  • System displays – message log, timer and modules information, RAM browser (internal system data display), flash memory browser
  • GPS navigation – airport database, course plotting and calculating, list nearest airports, navigation information (ILS, ADF, etc)
  • Navigation hardware support – commands navigation hardware of the aircraft
  • Splash screen/GUI support – support for layout-based image GUI instead of default symbol-based one
  • Avionics – customizable PFD, EFIS, etc
  • Flight data recording – record information from many sensors at different data rates in binary or text format
  • Orbital guidance and navigation – flying in space
  • Maps – navigation maps, tied to GPS if available
  • Digital autopilot – advanced programmable digital autopilot

This is a complete high-level on-board computer operating system. It supports all features you would ever find in an on-board system in great detail.

Small physics simulation

Okay, this is not exactly physics simulation, it has only distinct relation to real universe. This simulation is based on two things: the light (signals) travel at finite velocity, and that there is a certain global “zero reference” coordinate system. This is not a real coordinate system, but it’s a suggested way that allows to receive information about all points in universe at once (not limited by speed of information).

But this system is not a model of real universe, and it does not agree with general relativity (because it lacks the statement about the inertial systems). Actually this is a reason why it’s a bad idea – it would only comply with general relativity if the clocks in all points ticked at different rates for whatever reason. Describing that is not as obvious as in the general relativity, but I’ll still try to (I want to try it).

I’ve started with a simple experiment first – two satellites orbitting a stationary point. Left view is zero reference system, green waves are the continious signals about the satellites positions (well, it’s only displayed for just one satellite). Right view is what the stationary point sees (what shows on radar):

Then after some more playing around I’ve tried to replicate a kind of twins paradox-like experiment (but there is no difference in time when ship arrives, the Earth just catches up with events):

The twins paradox does really exist (see Hafele-Keating experiment), but actually I still don’t understand how. It is known why (the timespace curve that connects two events is not a straight line, but a curve instead), and the curve appears because the ship accelerates/changes direction of movement (okay, not so sure here), but how does that actually happen is what I don’t know.

Advanced ball logic devices

You can build some more complicated ball logic devices. Here are some basic logic gates (XOR gate is actually XNOR):

I will not go into much detail explaining how these devices work, you’ll have to imagine how they work yourself (it should be pretty intuitive if you imagine the signal as a falling ball).

Here’s a 16-bit ROM device, it allows you to store 16 bits of information in 4-bit words. The information will be read from specific address, and copied into target register:

The “logic amplifier” is actually just copying value into another register. It’s called amplifier, because if this was to be built mechanically using falling balls, you would need to relieve mechanical stress caused by connecting all of the bits together.

I’ve also created a 4-bit multiplier gate, but I didn’t draw scheme for it yet. I’ll eventually post it when I draw it. And it’s also possible to make RAM, if you use I-gates instead of L-gates in a clever way.

Ball logic devices

Here’s a most common and typical scheme you might see: a binary counter. But it is with a twist, it counts up to 10, not 16:

It works by directing signal through two branches – the counter itself, and the condition branch. It works like this: first it increments counter by 1, and then it checks the branch.

If branch succeeds, the signal goes through output which indicates that counter is complete (it would probably lead to circuit that resets the counter).

Here’s a binary adder – it will add two 4-bit variables. As you can see, it is very easily scaleable for many more bits:

You can further optimize it by connecting “0″ output of T-gates to input of next L-gate. This will save several cycles during addition (because single signal would be used for adding several bits, not just one).

Ball logic gates

There are 3 types of gates defined in ball logic. They are T-gate (toggle gate), L-gate, and the I-gate (identity gate). There are also two special gates – the inflow and the outflow.

If outflow is tied to the inflow, then the inflow creates a new signal every time signal reaches the outflow. This means that single scheme can have more than one inflow and more than one outflow (usually it has several outflows that indicate state).

Here’s the gates cheat-sheet (it includes suggested way of drawing gates in schemes):

State is the gate state before a signal enters it. New state is the gate state after signal travels through gate, and output is the output it will go through (they are marked on the scheme).

A set of gates can be connected together, so they all will store same value. There is also an extra rule, which is optional though: signal must flow from top to bottom. This is a physical requirement, not logical though. A lot of various devices can be built using this logic, I will cover some of them in the next post.

Ball logic (general information)

Recently I’ve became interested in the ball logic once more. In short, it is a kind of logic, mechanical analogy would be balls falling through mechanical “gates”.

It is very similar to widely known “marble logic”, in fact it started as that, but there is one difference: ball logic is a formal (at least that’s what I want it to be) logic, has small set of basic gates, and it doesn’t really require falling balls or any kind of mechanics. Most of ball logic devices can be built using mechanics though.

One of reasons for me to try to make this logic more formal is that there’s almost no resources on it on the internet, it’s mostly full of simple binary adders, and addition devices, which do not demonstrate true power of ball logic.

Ball logic is also different to the boolean logic. In boolean logic information is carried by the signals, which pass through basic gates, so to say. If you are evaulating a function, you’re interested in result of the function. On the other side, in ball logic information is stored inside the gates themselves, every gate has an internal state. You are interested of state of the function after evaulation only.

Although it also uses binary. Every gate in ball logic has one input, and two outputs. The input is called inflow, and two outputs are 1 (true), and 0 (false). There are two special gates though: the inflow gate, which generates output signal, and outflow will trigger new signal when signal arrives.

It is a very discrete logic – the signal is very short (unlike the regular boolean/digital logic where signal duration and timing matters), and there is only one quant travelling through the system.

Here’s an illustration of basic flip-flop element, which is most common, and everyone knows it. In ball logic terms it is called T-Gate:

Read next post for detailed explanation of how it works, and of all gates.