confusion.

When I started studying Computer Sciences and Communication Systems, one of my first courses was an introduction to ANSI-C. To be honest, C is not the easiest language to learn. You have to care a lot about problems which are not even known in typical hobbyists languages of choice. You have to care about memory management, pointers, boundary checks and a lot more which is typically cared for by the compiler, interpreter or virtual machine for most newer languages like Java, the .NET languages or interpreted ones like Python or PHP.

However, on the other hand, C is a great language to learn what’s programming about and to get a deep knowledge and feeling for what a more complex platform might do when you call a “simple looking” function and you are wondering on the impact it has. As a language C is “high” enough to spare you from the pains of assembler and “low” enough to not bedazzle you with shiny functions you actually cannot find out for how they do their magic.

Back to the “historical” part, for me the greatest pain working with ANSI-C was to do user inputs. I always ran into problems when I wanted to read characters, interpret input as an integer or even as a double! So, when my knowledge was good enough, I started developing a pretty small but useful library to ease user inputs – and from the first version on I used it in a lot of projects and, as far as I know, it was in use by several further classes, too. Some days ago I did a little project in C and – although I didn’t use it (I had no user input) – I remembered my little library and so I wanted to post it here. Don’t expect too much, it does no magic and it was one of my first works in C

Basically it provides only four simple functions to be used for reading multiple characters (up to 4096), a single character, an integer or a double value:

    int     readCharacters(char*	buffer, int chars);
    int     readCharacter( char*	buffer);
    int     readInteger(   int*		value);
    int     readDouble(    double*	value);

The library comes with a short example application (with comments in german ). As usual, the short library is provided “as is” under the MIT license here for download.

Recently I gave you a short introduction in communicating with iTunes from your own objective-c application using the Apple Scripting Bridge. As for several reasons my current development environment is much windows centric than I wish it would be, I came to the idea of checking on how to integrate iTunes in a .NET based application. And, to my surprise, it is nearly as simple as using objective-c – while both have their very own weak-points.

Basically the support for inter-application communication in classical Windows applications is realized using COM, the Component Object Model. COM provides two important technologies to do so: the communication infrastructure and a factory for dynamically allocated objects. The main advantage however is, that COM based objects (which can be both, applications and DLLs) are language- and version-independent. While the first feature offers you the possibility to select a comfortable environment, the latter one eases the pain of supporting multiple versions of the target application – which might become a problem for rapid-evolving applications like iTunes. Although sounding fancy, the latter feature is similar to the approach of scripting bridge: both use a specified interface to communicate and the server application (the COM provider, in this case iTunes) can “decide” if to support the interface or not. As both interfaces, the one for scripting bridge and the one for COM, change quite seldom and so far managed to stay downwards-compatible, this technique is quite future-proof.  For more information on COM, see the Wikipedia entry or the MSDN.

Working with COM in C# can be a bit fuzzy and hard to debug sometimes. The most strange paradigm is that you have to work on interfaces only and creating a new “instance of an interface” is not a quite common approach for most developers . For example, getting the iTunes application COM instance you use:

var app = new iTunesApp();

If you have a quick look in the Object Browser you will find the following entry for iTunesApp:

public interface iTunesApp
Member of iTunesLib

If your Visual Studio is revoking to accept iTunesApp you might have missed to add the iTunesLib COM reference. You can add it like any other assembly to your project by just selecting “COM” and then “iTunesLib” in the “Add Reference” dialog instead of browsing for an assembly. So how to get information on the COM supported functions? Simply: jump to the next entry in the object browser, the <pre>iTunesAppClass</pre> which is the “backing” class for the iTunesApp interface. However, keep in mind that the instantiation of iTunesAppClass will always fail – the paradigm is simple to remind: you request the server application (iTunes) to create an instance of iTunesAppClass by telling .NET that you want an object that is interfaced as an iTunesApp.

So, before I will continue with a short example, I’d like to mention some differences. Quite nifty is the COM support for server-side invoked function calls, which might be more common for as “Events”. You can register to  a set of events on the iTunes COM interface which provide you instantaneous information on iTunes’ state changes, like playing another track:

    this.app = new iTunesApp();
    this.app.OnQuittingEvent += this.AppITunesQuitting;
    this.app.OnDatabaseChangedEvent += this.AppITunesDatabaseChanged;
    this.app.OnPlayerPlayEvent += this.AppITunesPlayerPlay;
    this.app.OnPlayerPlayingTrackChangedEvent += this.AppITunesPlayerPlayingTrackChanged;
    this.app.OnPlayerStopEvent += this.AppITunesPlayerStop;

So far I couldn’t figure out a technique for objective-c to realize a similiar good state change reporting. A bit more anoying is the implementation of starting and monitoring iTunes. While there is an is-iTunes-running function for objective-c, there is none for COM – and, in case you simply call a COM function, Windows will start iTunes without any further notification. For a bit more comfort you can “simulate” the is-running function by using System.Diagnostics:

        public bool IsRunning
        {
            get
            {
                var process = Process.GetProcessesByName("iTunes");
                return process.Length > 0;
            }
        }

On the other side of the life-cycle you should always register to the OnQuittingEvent of the COM interface and avoid using COM functions after the event has been sent until iTunes is available again or you want iTunes to startup . Remember that starting iTunes uses a quite big amount of time and will block the COM function call until done.

OK, so to sum-up and finish let’s have a short example on how to use the COM interface to get the list of user-playlists from iTunes, it’s quite simple:

    var enumerator = this.app.Sources.GetEnumerator();
    enumerator.MoveNext();

    var source = enumerator.Current as IITSource;
    if (source == null)
    {
        return new List<IITPlaylist>();
    }

    return from IITPlaylist list in source.Playlists
            where list.Kind == ITPlaylistKind.ITPlaylistKindUser
            select list;

The snipped assumes that “app” is an iTunesApp instance. Then, the Sources property provides access to the iTunes sources, similar to the Scripting Bridge version. In case you prefer the indexing operator for arrays: forget it, they don’t work in this case – you have to use the enumerator. Calling MoveNext once will bring you to the first source which is always the Library (“Mediathek” in German). The rest is simple: check if it is a valid Source and get the Playlists array. Using a bit of LINQ-magic you can filter those playlists that are of the user-kind and then you have all playlists.

In Oktober of 2007 I finished my first academic studies as a Bachelor of Science in Computer Science and Communication Systems at the HTW in Saarbrücken, Germany. To do so, I had to write a bachelor thesis during the last months of the semester. Together with a fellow student, Thomas Stein, we decided to do something more special than a typical software implementation (which sometimes is more than challenging for such a short thesis time, too).

Fortunately we were in good contact to some profs from the high frequency, computer science and telecommunication departments who had a complex problem in their current field of research, which was WiMAX (Wikipedia has some info, if you don’t know WiMAX). They wanted to precisely measure the variability of packet transmission latency over time, which is commonly known as “jitter” or packed delay variation (see RFC 3393).

Measuring jitter in computer networks is typically done in two ways: For precise one-way-measurement (variance in transmissions from one network device to another one), loop-devices can be used. These have two network-interfaces, one for the outgoing packet and a second one for the incoming. As both are driven by the same timer-base, the measurement accuracy is only dependent from the operating system’s qualities. As second way to measure jitter is to use round-trip-measurements. To do so, the measurement sends a packet over the network to a recipient who transmits a packet back to the sender.  This is quite similar to the commonly known “ping” command. So, if you know that the client always needs the same time to respond, you can measure the jitter by comparing the transmission times over time. Both methods have their own big ”but …”. The first one, the one-way-measurement, is only applicable for “local” installations as you need the cabled loop. The latter one can only measure round-trip times, which is quite dissatisfying if you expect different delay and jitter measurements for up- and downstream (especially in asymmetric or wireless networks).

As a solution for this problem we developed “SynchronQoS”,

[...] a measuring device for quality aspects of IP-based networks was developed using a real time platform and the global satellite system GPS. It provides the ability to analyse one way trip times, round trip times, packet loss and the variance of trip times. Time measurement accuracy is below 10 μs independent from the global placement of the gauging stations.

Aim of the work was to create a system that is able to measure packet transmission (especially one-way jitter) aspects between two globally distributed endpoints. Because we wanted to develop a system that can be used for any distance between the two endpoints, it had two consist of two independent devices that could not be time-synchronized with an additional reference cable (e.g., fibre cable), which is a quite common solution for short distances, too. In order to measure one-way delay and it’s jitter, however, the devices needed to be synchronized. To solve to problem we decided to rely on the global positioning system (GPS) which is also a time-critical system and therefore can (and needs to) provide a precise timing (and position).

Basically, GPS receivers measure the difference in runtimes of signals coming from multiple satellites. As the signal runtime is equal to the distance from the satellite, a receiver can triangulate it’s position on the surface – three satellites are sufficient for a position on the earth’s surface, a fourth satellite provides a height above the zero-level (typically, more satellites are used for speed and precision improvement). However, to measure the relative runtime between multiple signals, the transmission-times needs to be known. Therefore, each GPS satellite contains an atomic clock and transmits it’s position and the time of transmission. By using the satellites’ positions, the runtimes and additionally position correction information, a quite exact position determination is possible. Furthermore, knowing the exact position from triangulation, the receiver can quite exactly synchronize to the global time by adding the signal runtime to each signals transmission time and averaging on multiple time/runtime sets from different satellites.

In our project, for which the basic concept is shown in the figure, we used two separate devices whose time is synchronized using the GPS. With this common time base, packet transmissions over a local, distributed or even global network (like the internet) can be measured. To reduce costs of production and increase the usage flexibility we decided that both devices, the transmitter and receiver should be identical and the operation mode should be defined by software.

The software, in turn, was another great challenge. We had to design a quite low-cost and easy to build device with a software whose function execution (time) is highly predictable. To achieve these key requirements we decided to base up on a microcontroller-centric real-time platform. Communication with the device should be implemented using standard TCP/IP communication, like telnet.

Finally, after a lot more of project planning and discussions, we concluded with a reliable concept, ready for implementation. Thanks to another good contact from the HTW, we managed to get hands on a TriBoard TC1130.300 microcontroller board with a TriCore MPU. For the GPS part we bought two Resolution T receivers from Trimble with external antennas for high signal gain. The receiver had two advantages: First, it was designed for high precision position measurement using a multi-measurement smoothing algorithm that could be configured to use several thousands of triangulation rounds to fix the position very precisely. Second, the device is able to generate a pulse-per-second signal with an astonishing one-sigma-precision of 15ns, we used as an interrupt to synchronize the microcontrollers time once every second.

Finally we pieced everything together: The GPS receiver was connected to the TriBoard using a custom-built signal level shifter board and an additional interrupt signal for the PPS. Voltage regulators were added to operate the device with a single power supply of 9V DC. The TriBoard itself could be connected to a PC using Ethernet for serial setup and using JTAG for programming.

To reduce the time of implementation and to have a reliable base for real-time operation we used PXROS-HR by HighTec EDV-Systeme (the same company who gave us the boards), a high-performance real-time operation system for the TriCore platform. We use 5 different tasks with different priorities to minimize the response time for time-critical parts like processing the PPS or incoming TCP/UDP packets in measurement mode.

Although facing a lot of problems we finally built up two prototypes we could use for first tests and measurements before our thesis time was over and we had to refocus on the challenges of the Master courses . Our measurements using available network hardware showed that we could reach a precision of about 10-30 µs without optimization. Looking back on our work we finally added a large chapter on possible improvements and further work-to-do to our thesis document; a lot of things we concerned but couldn’t focus on due to the time-limitations. In this case, time had been a challenge in every aspect – or to say it with Hector Berlioz’ words:

“Time is a great teacher, but unfortunately it kills all its pupils.”

– Hector Berlioz –

Vor kurzem hatte ich glücklicherweise die Gelegenheit eine der für mich schönsten Städte zu besichtigen: Mailand. Die zweitgrößten Stadt Italiens lädt nicht nur zum schoppen (vorrangig natürlich Mode) sondern auch einfach zum flanieren und genießen ein. Die Bilder sind rund um den Duomo (den Mailänder Dom) und im Parco Sempione, einer großzügig angelegten Parkanlage mitten in Mailand, entstanden.

Um das fehlende Sommerwetter etwas zu überbrücken, ein paar Bilder die ich auf einer kurzen Wanderung Ende April geschossen hab. Alle Bilder sind mehr zufällig als geplant entstanden und sind nur minimal bearbeitet (und verkleinert natürlich ).