Hell, even I can't replicate it currently. Latest round of tests - another class, then went to post office to drop off/pick up mail, and got some snacks - hasn't had any problems. No Columbus randomly exiting.

I recommend making it a settings choice in Options then, if it's not too much of a PITA to code. Gives it to the people who want it, lets you keep it off by default for yourself and everyone else.

Didn't an earlier version have everything get resized slightly differently on that screen, so that the graphs all fit? (Your click on it to cycle idea works just fine too, though.)

@scavenger's results: If you're both overclocking and using bluetooth, that kinda makes sense. I'm not sure, how much the CPU is able to stay sleeping, and at what minimum frequency you put it - so I don't know how much overclocking WITH Columbus running is more or less battery conserving. Columbus runs fine for me without the overclock, so I say don't do it unless you see it fetches you better results battery-wise. Overclocking is only battery efficient when the N900 is able to get it's processor awake time reduced enough to outweigh the extra power draw spent on higher clock speeds. If the task keeps the processor awake non-stop, and doesn't let it drop down to a lower frequency... *Shrug*

Bluetooth radio being on on the otherhand, and actively streaming all that data from/to whatever it's streaming it to/from would make sense on the two-hour battery run-out.

I mean, with mine running using the internal GPS, I lasted over 4 hours, even with one of them spent actively being on the wifi.

Heat-wise, I THINK it's also mainly the bluetooth and the overclocking. Depending on voltage, especially the overclocking. I HAVE occasionally gotten heat from the GPS chip (or what I THINK is the GPS chip), but I normally only get it from battery, or heavy wifi/processor usage.

Both battery depletion and heat makes sense in context... Not sure if there's any way Columbus could be optimized to reduce those things, but it definitely seems to be no less optimized that most programs in that regard.

I think the GPS system does that normally - the first lock (one that's done for the first time recently in the area you're in now, or that's done in a different area than your last lock if your last lock is still cached somewhere), takes a while, because it uses some heuristics to shorten lock times based on the location of the previous lock. If the previous lock is in a totally remote area, or was too long ago to count, it can't use those heuristics.

So unless you moved a few hundred miles between the first lock and consequent quicker locks, that's standard behavior...

I don't know about the crashing though. Perhaps there's something to it though, and it may be correlated to my two-quick-succession crashes... What do you have installed that's likely to be running in the background while Columbus runs? I have the lxp injection-capable drivers loaded, X-Terminal windows open (I was browsing some directories, also editing the ~/.config/menu/submenus/ files that you can edit with ApMeFo to create folders in your menu structure... But with vi and X-Term instead of through ApMeFo because I'm a hardass like that.

I have a bunch of Python-based status menu applets running (Advance Interface Switcher, Advance Power, Advanced Clock Plugin) in the background, but updating and showing because I had status bar visible...

Ummm, I also have ShortcutD, I'm pretty sure I have SSH server up in the background, as well as a the regular slew of system daemons. The only thing out of norm is the power kernel's module that reports battery values, like temperature; I have that loaded at boot by default. But that wasn't being accessed to fetch any values at the time by anything that I can think of... I have the 'swappolube' mods, but I do it the old school way before swappolube - manually - and they're not standard swappolube values.