Blog Archives

Höhenflug mit Delta-Modellflieger über der HSLU T&A

Was macht man mit einem iPod mit eingebauter Kamera, einem Swift 2 Delta-Modellflieger, einem total überdimensioniertem Motor und einem Dach auf ca. 25m Höhe?

Richtig, man füge all diese Komponenten zusammen und schlussendlich entsteht ein Film in atemberaubender Höhe über Horw.

[youtube width=”480″ height=”390″]http://www.youtube.com/watch?v=VBJ5mur2aZ4[/youtube]

PS: Leider war die Kamera zu nahe am Motorenregler angebracht, darum die lästigen Wellenmuster im Film. Beim nächsten Mal kommts sicher besser, versprochen 😉

Hier noch ein kurzes Video von einem schnellen Takeoff vom Boden aus. Der Motor würde noch einiges mehr leisten, es wäre auch möglich direkt senkrecht zu starten 😀

[youtube width=”480″ height=”390″]http://www.youtube.com/watch?v=1kDTeOyOF2s[/youtube]

Category: Fliegen  Tags: , , ,  Leave a Comment

stackoverflow is EVIL

Haha, recently I logged in on stackoverflow and recognized that I’ve got some additional reputation points.

Look at the number 😉

I also added the Stack Overflow Widget to show the actual stackoverflow points on in WordPress. Thank to Steve Robins.

Category: Fun  Tags:  Leave a Comment

Eindeutige Fehlermeldungen

Wurde soeben mit einigen Fehlermeldungen konfrontiert.

The world's #1 browser, to download another browser!Informative Sharepoint Fehlermeldung

Category: Fun  Tags:  Leave a Comment

SnūzNLūz – Die effektivste Art schnell aufzuwachen

Habe mir vor über einem Jahr einen Schlafphasenwecker (aXbo) gekauft.

Muss schon sagen, keine schlechte Sache. Er misst die Bewegungen des Handgelenks und ermittelt, ob sich der Schlummernde im Tief- oder Halbschlaf befindet. Daraus kann er den optimalen Weckzeitpunkt ermitteln und einem sanft mit einer friedlichen Melodie aus dem Schlaf holen.

Der aXbo bewährt sich sehr gut als Schlafexperte. Man wird nicht aus dem Tiefschlaf gerissen und braucht anschliessend nicht den ganzen Vormittag um auf Touren zu kommen.
Aber das Ding funktioniert auch nur dann gut, wenn man auch tatsächlich aufsteht. Es hat deshalb extra auch keine Schlummer (Snooze) Taste, da man sonst in Versuchung gerät weiter zu schlafen und man wieder in den Tiefschlaf fallen kann.

Ich leide teilweise unter diesem Schlummer-Phänomen und wache dadurch einiges später auf, als ich eigentlich geweckt werden wollte. Also habe ich mir gedacht, ich bräuchte eine zusätzliche Motivation um auch tatsächlich aufzustehen, wenn der aXbo angeht.

Ich hab mir schon früher Gedanken darüber gemacht, einen Wecker zu entwerfen, welcher an bestimmte Organisationen (am Besten solche, die man als besonders lästig empfindet) Geld spendet, wenn man nicht rechtzeitig aufsteht.
Hat auch den Vorteil, dass man Ende Jahr die Spenden auch von den Steuern abziehen kann. Wäre eine spielerische Weise, um einerseits pünktlich aufzustehen und andererseits mit der Spende auch etwas für die Allgemeinheit zu tun (es kann ja auch eine sinnvolle Organisation sein, müssen ja nicht die Zeugen Jehovas sein).

Und siehe da, da sind schon andere auf die Idee gekommen und haben glatt einen entsprechenden Wecker, der SnūzNLūz, entworfen.
SnūzNLūz

Der SnūzNLūz kann via WiFi oder RJ45 mit der Aussenwelt kommunizieren. Konfigurieren kann man ihn über seinen eingebetteten Webserver. Dort gibt man die Bankdaten an und die Organisation, zu der man die Spende tätigen will. Drückt man auf die Snooze-Taste, so spendet der Wecker knallhart den entsprechenden Betrag an die Kirche, oder den Scientologen…

Aber guckt doch gleich selber mal rein. Den SnūzNLūz gibts bei thinkgeek.com für knapp 40$. Für die reichliche Ausstattung des Weckers ein sehr niedriger Preis. Aber vermutlich spendet der SnūzNLūz auch etwas an seine Erfinder 😉

Category: Fun  Tags:  One Comment

OMG, what a price!

Wollte mal eben wissen wie teuer das Adobe InDesign CS5 bei digitec ist.
Die haben ja mächtig aufgeschalgen mit dem Preis 😉
OMG, what a price!

Category: Fun  Tags:  Leave a Comment

High delay in RS232 communication on a PXA270

I’m experiencing a long delay (1.5ms – 9.5ms) in a RS232 communication on a PXA270 RISC PC/104. I want to minimize the long delay but I’m a beginner with embedded devices and C++ so I think I’m missing something.

RS232 delay on PXA270

RS232 delay on PXA270

The mentioned delay is at the time when the PXA board receives a packet from the external device via RS232 (115200 baud) until it sends an ACK custom packet back to the external device. I measured the delay on the PXA board with an oscilloscope, one channel at the Tx (green) and the other on the Rx (blue).

The PXA board is running an Arcom Embedded Linux (AEL). I know, it’s not a real-time OS, but I still think, that an average delay of 4.5ms is way too high for extracting the received packet, verify it’s CRC16, construct an ACK packet (with CRC) and send it back the serial line. I also deliberately put the CPU under heavy load (some parallel gzip operations) but the delay time didn’t increase at all. The maximum size of a received packet is 30 bytes.

A C++ application (another former co-worker wrote it) is handling the reception of the packets and their acknowledgement. One thread is sending and the other is receiving the packets.

I thought that the RTC on the PXA board has a very bad resolution and the AEL can not align the timing to the internal RTC resolution. But the RTC has a frequency of 32.768 kHz. The resolution is sufficient, still don’t explain the high delay. Btw, I think the OS is using the internal PXA clock (which has also a sufficient resolution) instead of the RTC for the timing.

Therefore the problem must be in the C++ app or in a driver/OS setting of the RS232 interface.

The following control flags are used for the RS232 communication in the C++ application according to the Serial Programming Guide for POSIX Operating Systems:

// Open RS232 on COM1
mPhysicalComPort = open(aPort, O_RDWR | O_NOCTTY | O_NDELAY);
// Force read call to block if no data available
int f = fcntl(mPhysicalComPort, F_GETFL, 0);
f &= ~O_NONBLOCK;
fcntl(mPhysicalComPort, F_SETFL, f);
// Get the current options for the port and set the desired values
tcgetattr(mPhysicalComPort, &options);
cfsetispeed(&options, baudRate);
cfsetospeed(&options, baudRate);
// no parity (8N1)
options.c_cflag &= ~PARENB;
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
// disable hardware flow control
options.c_cflag &= ~CRTSCTS;
// raw input
options.c_lflag = 0;
// disable software flow control
options.c_iflag = 0;
// raw output
options.c_oflag = 0;
// Set byte times
options.c_cc[VMIN] = 1;
options.c_cc[VTIME] = 0;
// Set the new options for the port
tcsetattr(mPhysicalComPort, TCSAFLUSH, &options);
// Flush to put settings to work
tcflush(mPhysicalComPort, TCIOFLUSH);

I think I’m missing something very simple. I think, that if the process of the app is running under a higher priority, this will not solve the problem. There must be something, which instructs the RS232 driver to handle the requests with a higher priority to minimize the latency.

Does anyone have any ideas? Thank you very much in advance for your help.

The Solution

I was able to reduce the delay to ~0.4ms. The command setserial(8) was referenced in the AEL manual. And bingo, I found the low_latency flag there with the following description:

Minimize the receive latency of the serial device at the cost of greater CPU utilization. (Normally there is an average of 5-10ms latency before characters are handed off to the line discpline to minimize overhead.) This is off by default, but certain real-time applications may find this useful.

I then executed setserial /dev/ttyS1 low_latency and the delay was reduced to ~0.4ms *yay*
But I wanted to implement this behaviour in the C++ app, without setting this flag globally with setserial (this command is by default not included in all distros).

I’ve added the following code lines, which had the same effect as the low_latency flag from setserial:

#include <sys/ioctl.h>
#include <linux/serial.h>
// Open RS232 on COM1
mPhysicalComPort = open(aPort, O_RDWR | O_NOCTTY | O_NDELAY);
struct serial_struct serial;
ioctl(mPhysicalComPort, TIOCGSERIAL, &serial);
serial.flags |= ASYNC_LOW_LATENCY; // (0x2000)
ioctl(mPhysicalComPort, TIOCSSERIAL, &serial);

Have phun 🙂

Category: C++  Tags: , ,  Leave a Comment

Hey dude, where is my door?

Hey dude, where is my door?

Category: Fun  Tags: ,  Leave a Comment

Java Information Hiding

I asked some IT students at my workplace to describe the principle of Information Hiding in Java.

This was the answer (in German):

Category: Fun  Tags: ,  One Comment

Android: Trusting SSL certificates

Two weeks ago I got the task to establish TLS secured connections via certificates to a service endpoint.
I thought it’s not a big deal, because the endpoint already uses an EV certificate from a trusted CA (SwissSign) in Switzerland. Therefore I shouldn’t have to worry that the certificate would be considered as untrusted so I don’t have to import it to the trusted certs in the  Java  key store etc.
FAIL! I’ve got a security exception, cert is not trusted. Same problem when I visit the website with the browser. Ok, that’s bad, SwissSign is not such a big player like thawte, so, it needs some time till it will be added to the android trusted CA list. But, when I visit thawte.com, their cert is also not trusted by android. WTF?
Windows Phone and iPhone trust my SwissSign CA and don’t complain.

So, let’s ask google, stackoverflow and the blogosphere. Found a lot of solutions how to disable certificate checking entirely.
Yeah, great, this will solve my problem, my connection will be “secure” and everyone will be able to intercept my connection and inject his own certificate. But I finally found the solution with help from other sites and some testing and debugging.

The Solution

The following main steps are required to achieve a secured connection from trusted Certification Authorities.

  1. Grab all required certificates (root and any intermediate CA’s)
  2. Create a keystore with keytool and the BouncyCastle provider and import the certs
  3. Load the keystore in your android app and use it for the secured connections
    • Don’t use the standard java.net.ssl.HttpsURLConnection for the secure connection. Use the Apache HttpClient (Version 4 atm) library, which is already built-in in android. It’s built on top of the java connection libraries and is, in my opinion, faster, better modularized and easier to understand.

Step 1: Grab the certs

You have to obtain all certificates that build a chain from the endpoint certificate the whole way up to the Root CA. This means, any (if present) Intermediate CA certs and also the Root CA cert. You don’t need to obtain the endpoint certificate.
You can obtain those certs from the chain (if provided) included in the endpoint certificate or from the official site of the issuer (in my case SwissSign).

Ensure that you save the obtained certificates in the Base64 encoded X.509 format. The content should look similar to this:

-----BEGIN CERTIFICATE-----
MIIGqTC.....
-----END CERTIFICATE-----

Step 2: Create the keystore

Download the BouncyCastle Provider and store it to a known location.
Also ensure that you can invoke the keytool command (usually located under the bin folder of your JRE installation).

Now import the obtained certs (don’t import the endpoint cert) into a BouncyCastle formatted keystore.
I didn’t tested it, but I think the order of importing the certificates is important. This means, import the lowermost Intermediate CA certificate first and then all the way up to the Root CA certificate.

With the following command a new keystore (if not already present) with the password mysecret will be created and the Intermediate CA certificate will be imported. I also defined the BouncyCastle provider, where it can be found on my file system and the keystore format. Execute this command for each certificate in the chain.

keytool -importcert -v -trustcacerts -file "path_to_cert/interm_ca.cer" -alias IntermediateCA -keystore "res/raw/myKeystore.bks" -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "path_to_bouncycastle/bcprov-jdk16-145.jar" -storetype BKS -storepass mysecret

Verify if the certificates were imported correctly into the keystore:

keytool -list -keystore "res/raw/myKeystore.bks" -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "path_to_bouncycastle/bcprov-jdk16-145.jar" -storetype BKS -storepass mysecret

Should output the whole chain:

RootCA, 22.10.2010, trustedCertEntry, Thumbprint (MD5): 24:77:D9:A8:91:D1:3B:FA:88:2D:C2:FF:F8:CD:33:93
IntermediateCA, 22.10.2010, trustedCertEntry, Thumbprint (MD5): 98:0F:C3:F8:39:F7:D8:05:07:02:0D:E3:14:5B:29:43

Now you can copy the keystore as a raw resource in your android app under res/raw/

Step 3: Use the keystore in your app

First of all we have to create a custom Apache HttpClient that uses our keystore for HTTPS connections:

public class MyHttpClient extends DefaultHttpClient {

	final Context context;

	public MyHttpClient(Context context) {
		this.context = context;
	}

	@Override
	protected ClientConnectionManager createClientConnectionManager() {
		SchemeRegistry registry = new SchemeRegistry();
		registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
		// Register for port 443 our SSLSocketFactory with our keystore
		// to the ConnectionManager
		registry.register(new Scheme("https", newSslSocketFactory(), 443));
		return new SingleClientConnManager(getParams(), registry);
	}

	private SSLSocketFactory newSslSocketFactory() {
		try {
			// Get an instance of the Bouncy Castle KeyStore format
			KeyStore trusted = KeyStore.getInstance("BKS");
			// Get the raw resource, which contains the keystore with
			// your trusted certificates (root and any intermediate certs)
			InputStream in = context.getResources().openRawResource(R.raw.mykeystore);
			try {
				// Initialize the keystore with the provided trusted certificates
				// Also provide the password of the keystore
				trusted.load(in, "mysecret".toCharArray());
			} finally {
				in.close();
			}
			// Pass the keystore to the SSLSocketFactory. The factory is responsible
			// for the verification of the server certificate.
			SSLSocketFactory sf = new SSLSocketFactory(trusted);
			// Hostname verification from certificate
			// http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html#d4e506
			sf.setHostnameVerifier(SSLSocketFactory.STRICT_HOSTNAME_VERIFIER);
			return sf;
		} catch (Exception e) {
			throw new AssertionError(e);
		}
	}
}

We have created our custom HttpClient, now we can just use it for secure connections. For example when we make a GET call to a REST resource.

// Instantiate the custom HttpClient
DefaultHttpClient client = new MyHttpClient(getApplicationContext());
HttpGet get = new HttpGet("https://www.mydomain.ch/rest/contacts/23");
// Execute the GET call and obtain the response
HttpResponse getResponse = client.execute(get);
HttpEntity responseEntity = getResponse.getEntity();

That’s it. Took me long to figure it out, hope this helps and saves you that time.

I really hope that the android platform will implement a better mechanism in future releases for defining which Certification Authorities should be trusted or not or just expand their own trusted CA list. If they don’t, I can’t believe they will get good acceptance from the business sector. Ok, you can control which certificates you want to trust in your app, but you still can’t add thawte as a trusted CA in the android keystore and your browser will always complain about an untrusted CA. The only way I know to eliminate this problem is to root your phone (very user friendly) and add your CA manually to the android keystore.

Feel free to comment.

Category: android, Coding  Tags: , , ,  93 Comments

EPIC FAIL

Category: Fun  Tags: ,  One Comment