EM broken again

The latest problem I'm having definitely seems to be a hardware issue, the voltmeter goes to 0.70V (or effectively 0V), and the fuel counter starts counting 'less'.

I also have my doubts about the tach ever working right. I was getting 3000+ RPM on climbouts and straight and level flights, which should be impossible unless I firewall the throttle and point the plane straight down.

I haven't yet figured out why the voltage going bad also makes the fuel counter go bonkers.

All I know is that it seems to be a hardware issue, like a bad soldering joint. This has happened before, it seemingly shakes itself apart.

Oh yeah, about the plane

I flew from Livermore, CA (KLVK), to Gwinnett county-briscoe field (KLZU) last week. It took about 14 hours or so, I had amazing tail winds the first day, I was seeing ground speeds 190KTS or more, even hitting 200+ at one point.

The EM had a strange problem in that it would basically stop working after one gallon (or when the counter hit 32768). I 'sorta' fixed it that night by putting in a watchdog timer, but that was only a band-aid. The real problem was some more signed/unsigned problems with the internal counters and some of the math.

Once the value hit 32768, it would 'go negative', and a bit shift would shift in a 0xffff causing a cascade of nonsense values. It caused it to hang before I put in the watch dog.

Now that is all fixed. There is still an occasional crash on the app side, and sometimes my windows machine simply hangs, or 'stalls' for long periods of time. If I can move to an embedded linux or other CF card friendly OS, I'm hoping I won't have that problem.

Plane and EFIS update

As mentioned previously, I ported to GTK (via gtkmm), which generally went OK. However, cairo on windows (at least 2.16) is amazingly slow. So slow in fact, it can't render a few lines (airspaces and SUAs) on my moving map in less than 400ms.

400ms?? Seriously? It's drawing lines, not a voxel based renderer. I couldn't figure out how to make it any faster, but I found out how to create a DIB and get a good ol' GDI DC on it.

So, while the rest of the app is in GTK, with a smidge of cairo, the main drawing is handled in GDI. Thats not the best port in the world.

Now I'm thinking that I might want to ditch C++ altogether and just make a Java version of this (with stock AWT), that makes it stupendously portable, so instead of recompiling for linux, I could theoretically just drop some class files and go.

The other idea would be to nab one of the upcoming android tablets, and just make an android app out of it. That way, customers could use their cell phones, or just grab their own tablet of whatever size they want, (like a Dell Mini 5, Archos 7, JooJoo, or whatever)

This starts to make more and more sense the more I think about it.

I'm sure my friend Trimbo will chime in with "I told you to do this in the first place".