Dandy E205

This is not about a high-performance sailplane but about building something that you knew about maybe 30 years ago...

Graupner used to have a glider kit called "Dandy". I found a new-old-stock Dandy kit offered on eBay, but it went for what I considered way too much. So I decided to build something similar to the Dandy, and luckily found the web site http://www.koralpe.biz/dandy.html which has nice pictures of the original kit and a plane built from it.

I had also read about the Eppler 205 airfoil, both good and bad, so I decided to try that.

Finally, the "glider" should have an electric motor because using a high-start is somewhat cumbersome. The motor and prop combination was determined by trying various things in online motor calculators and by comparing with off-the-shelf models of similar wingspan, weight and type.

Wingspan	170cm
Length	105cm
Airfoil	E205
Stab	E193, 50 x 11cm
Wing Area	39.1 dm2
Weight	1156g
Wing Loading	29.6g/dm2
Decal Font	Optima Extra Black
Motor	Turnigy C3530-1100, Kv1075, 73g, 15A Max, later MVVS 10 2/1120
Prop	9x5 Folding Prop
Speed Controller	25A max
Battery	2200mAh 3S LiPo

The center of gravity came out somewhat too far in the back unless two batteries are packed into the front of the plane. The total weight of about 1.2kg includes the two batteries and radio gear. The original plane had a slightly smaller wingspan, weight of 1.0kg, and a wing loading of 16-29g/dm2.

First flight was on the morning of August 28, 2011. Two brief flights before breakfast. It flies nicely! I was surprised how slow. Current draw is 13A at full power, and about 5A when cruising around.

--

17 July 2016: Axis of Turnigy snapped off (!) during climbout. Managed to land ok, but prop vanished in the woods.
Replaced with MVVS 10 2/1120. On summer evenings using about 400 mAh for 10 minute flight.

Oracle JDBC Version Woes

Ran into a strange Oracle error today in a Tomcat program.

The code ran fine in two other Tomcat instances, but failed in a third one.

The error happened to be

ORA-03115: unsupported network datatype or representation

which basically means: There is a version mismatch between the database and the JDBC library.

Reason

That Tomcat instance had a copy of ojdbc14.jar in its lib/ subdirectory that was used instead of the ojdbc14.jar included in the application's *.war file.

Unfortunately it is hard to tell the version of an ojdbc14.jar from the outside.

Possible Solutions

1. Unzip the ojdbc14.jar and check its manifest file.
2. Get the version programmatically

The latter can for example be displayed on some 'internal' web page of your application:

Connection connection = ...;

DatabaseMetaData md = connection.getMetaData();

out.append(...md.getDriverName() + " " + md.getDriverVersion() ...);

That way it is possible at runtime to check which version you are actually using.

Moral

Don't put *.jar files in the Tomcat lib/ directory. Include them in the *.war file.

Yes, this way you might load multiple copies, one for each *.war, but that beats later wating time to debug an app that suddenly stops working because some Tomcat instance has the wrong *.jar in its lib/ directory.

Mercurial seems to hang in SourceForge connection because of host key change

Had a problem where mercurial seemed to hang forever in a SourceForge transaction.

It was run from within Eclipse via MercurialEclipse, and there was no indication as to

what's happening nor any way to stop it other than to kill Eclipse.

This was under Windows with hg calling putty, which in turn was configured to use an ssh key pair registered with SourceForge that had worked OK some time ago.

When executing hg from the command line, it would also hang, but I could stop it with Control-C, and then it would show the following message:

hg clone ssh://name@....hg.sourceforge.net/hgroot/....

interrupted!

remote: The server's host key is not cached in the registry. You

remote: have no guarantee that the server is the computer you

remote: think it is.

remote: The server's rsa2 key fingerprint is:

remote: ssh-rsa 2048 86:7b:1b:12:85:35:8a:b7:98:b6:d2:97:5e:96:58:1d

remote: If you trust this host, enter "y" to add the key to

remote: PuTTY's cache and carry on connecting.

remote: If you want to carry on connecting just once, without

remote: adding the key to the cache, enter "n".

remote: If you do not trust this host, press Return to abandon the

remote: connection.

remote: Store key in cache? (y/n) ^C

Again this was under Windows. On a real operating system the host key change prompt might have appeared before the Ctrl-C and thus be more obvious.

Anyway, the fix:

Run

putty -i path\to\the\key.ppk

once which will show the same host key change prompt and this time you can accept it.

From then on, hg works OK again.