Saturday, July 19, 2014

LCD pins too short

The black plastic spacer on the pin headers of the LCD that goes onto the System RED Controller 10.4 are quite high.


This makes the actual pins quite short. They're so short that they barely make contact in the pin sockets on the controller board. So I just removed the plastic spacer and now the LCD sits much better in the pin sockets.


Thursday, June 19, 2014

HT16K33 interferes with DCF77

I decided to order an Adafruit 1.2" 4-Digit 7-Segment Display w/I2C Backpack and a GA1A12S202 Log-scale Analog Light Sensor for my clock. In the end I want something that works and has the features I need. It doesn't have to be fancy and I don't want to spend too much time on building it. Here's an image showing the current prototype:


Obviously, it's not showing the current time yet, but just the number of minutes and seconds since the last DCF77 reception error. It seems that the HT16K33 LED controller IC on the back of the 7-segment display interferes with the DCF77 signal. I don't even have to send commands to the IC, simply powering it is enough to cause the issue. I tried different orientations and putting a metal shield in between the two but it didn't help. The only thing that helps is distance. Once I put the DCF77 antenna and the HT16K33 IC about 20cm apart it works. You can see that it worked for more than 49 minutes before I took the picture and stopped the test.

I planned to put all of the clock parts into a simple case made from three pieces of plastic. Well, now I'll need two cases, because I don't want a clock so big that I can get 20cm distance between the IC and the antenna.

Sunday, June 15, 2014

Arduino + DCF77

I've never done something with an Arduino before. So I decided to buy one (an Arduino Leonardo to be precise) along with a DCF77 receiver module. I wrote some simple decoding code for the DCF77 protocol. It worked and you can find it on GitHub.


This was last year. Some weeks ago I got annoyed about the lack of a decent clock on my desk. I have one, but it's not self-illuminated which makes it hard to read during the evening and night when the room is not brightly lit. So I decided to build my own one. It will have the following features:
  • Get its time information from DCF77.
  • Have an illuminated display of some sort to show the current time.
  • Measure the ambient light and adjust the brightness of its display accordingly.
Just these three features, nothing else, probably not even a button. For the DCF77 part I dusted off the Arduino setup mention before and started to improve the code from last year. You can find the current version on GitHub as well.

I originally started the decoder to sample the DCF77 signal at a fixed interval for 10ms, because I could not get it working with interrupts for some reason. This worked well, as the DCF77 signal consists of one 100ms or 200ms long pulse per second. I'll probably keep it this way for the clock because I think that it'll be easier to integrate with the display logic.

I didn't decide on the kind of display yet. I looked at different options:
  • Nixie tubes have a nice old fashioned look, but require high voltages. There are Nixie tube clock kits.
  • As people like the look of Nixie tubes they fake them using edge-lit displays.
  • Another option would be a word clock, such as the QLOCKTWO. There are many people that have build versions of this clock or sell kits, for example here and here.
  • An easy way out would be the typical 7-segment display. Not as creative as a word clock but easy to use and easy to read. There are nice 7-segment clock kits, such as the Alpha Clock Five
I think buying a clock kit of some sort is not an option for me. It is not as interesting as having to solve the problems and challenges on my own. Also the kits I found don't cover my feature list or have way to many features or are just a bit expensive.

The look of the Nixie digits is nice. I already build a prototype of an edge-lit fake Nixie tube but could not make it as bright and clear as I want it to be and gave up on this idea. Here's an image of the prototype:


Tuesday, June 10, 2014

Soldering done

The manual says that the estimated construction time for the controller and the H-field amplifier would be about four hours. Well, it took me the whole weekend.

As I assumed the GPS module was the most tricky to solder, because it doesn't have regular pins but comes in an LCC package that has small pits along the side of its PCB. Took me several attempts to get it soldered without bridges between the pits and between the pits and the metal shield above them.


Compared to the GPS module the amplifier ICs in SOIC-8 packages with normal pins were much easier to solder.


Here's an image of Amplifier 13.1 half done. There is quite a variety of ceramic capacitors on this board. Not difficult to solder, just takes a while.


Because I don't have much more to talk about right now I'll just show more images for the finished boards. The next images show all boards in a top view followed by all boards at an angle to get a good look at all of them.






The next step after soldering is to flash the firmware into the STM32F4 evaluation board and see if all of this actually works. Once that is done I have to build the antennas. I'll start with an H-filed loop antenna.

Saturday, June 7, 2014

Detecting lightning discharges

And now for something completely different...

Last month I read a German news article about the blitzortung.org project. It's about detecting the location of lightning discharges using a network of low budget receiver stations. The clocks of all receiver stations are keep in sync using GPS. This allows to combine the electromagnetic measurements of multiple receivers to calculate the location of a lightning discharge.

I decided to participate in this project and build my own receiver station. So I ordered the basics kits offered by the project founders for the different components of a receiver station. Here's an image showing the red PCBs for the Controller 10.4, the Amplifier 12.3 (H-field) and the Amplifier 13.1 (E-field) with the small Pre-Amplifier 14.1. Each PCB comes with a set of parts that are not easily available from online shops such as Reichelt or Conrad. The green PCB is an STM32F4 evaluation board that sits on top of the Controller 10.4 PCB and runs the firmware for the complete receiver station.



All the rest of the necessary parts can be ordered from Reichelt. There is even an order list with the Reichelt part numbers. Here's an image showing all the parts in a pile.


The next step is to solder all the components to the PCBs. This should not be that hard as most of them are through-hole, but some are SMD such as the GPS module and the amplifier ICs in SOIC-8 packages.

Monday, June 6, 2011

History of libvirt's ESX support

This is the story about how I got involved with libvirt.

I'm a computer science student at the University of Paderborn. An essential part of the masters program is a one-year project group. I participated in a project group about using virtualization technologies in a supercomputer environment. The targeted basis for our system was a supercomputer that runs different hypervisors, ranging from open-source hypervisors like Xen and KVM to commercial and closed-source hypervisors like VMware ESX and Microsoft Hyper-V.

One of our major tasks was to develop a system that allows to manage large amounts of virtual machines. We evaluated different approaches and decided to use libvirt as the hypervisor abstraction layer in our system, because it handles several open-source hypervisors already. My task in this project group was to extend libvirt with support for VMware ESX. The actual programming started in February 2009.
Because libvirt is written in C, the first problem that I had to solve was: How to manage a VMware ESX server from C? VMware provides several APIs to manage an ESX server, ranging from commandline tools over C libraries to full-fledged SOAP-based APIs. A good choice would probably have been the VMware VIX API, because it's implemented as a C library. But this library is closed-source and that doesn't mix very well with an open-source project like libvirt. Therefore, the decision was made to develop the ESX support using the SOAP-based VMware vSphere API.

This decision led to the next problem: How to handle SOAP in C? SOAP is an object-orientated protocol, that doesn't map directly to C. VMware provides Java bindings for the vShere API, but that doesn't help here. The typical way to get bindings for a SOAP-based API is to feed its WSDL file to a generator. There are some generator tool that can generate C bindings from a WSDL file. But each one has it's specific set of problems: csoap seems to be dead, Axis2C doesn't generate code for types that inherit from other types and gSOAP doesn't handle inheritance well either. This inheritance handling problems only occur when generating C code. For example, gSOAP generates perfectly working C++ code for the vSphere API. Another problem is the size of the generated C code. Axis2C generates over 100 MB of C code and gSOAP generates over 20 MB of C code for the whole vSphere API.

This led to the conclusion, that existing code generation tools cannot be used to generate C bindings for the vSphere API. Therefore, I've written custom C bindings using libxml2 for the XML deserialization and libcurl for the HTTPS transport. This fits well with libvirt, because it already depends and libxml2 and GnuTLS for its own XML handling and remote transport encryption. GnuTLS can be used by libcurl to handle the SSL part of HTTPS.

The custom C bindings started as a proof-of-concept and were overhauled some time ago to use macros for code generation. Later on I started to write a Python script that generates this macro-based C code from a simple object definition file. Currently this generator handles almost all vSphere API object types and methods used for the ESX support.

This custom vSphere API C bindings and the ESX support based on them are part of libvirt since version 0.7.0 (August 2009) and are under ongoing development since then. Finally we also wrote a paper about Non-intrusive Virtualization Management using libvirt that was published at the DATE conference in 2010.