Clearly I’m not a layout specialist, but the functionality is there.

Comments:
Got my miniTitan repaired; at around €20 it was fairly cheap. But the governor-config still needed to be done. So I gave the collective a punch while in a hoover and noticed a drop in RPM, as it was last time. I changed the settings to have a governor gain at “Medium (25)” instead of “Low (15)”.

The drop in RPM was noticeably less. I’m not sure if I’ll get it completely eliminated, but I started to notice some high-frequency oscillations just after spoolup; an indication of a too-high governor gain. I’ll see how this setting holds up in normal flights. As for the logging:

Before the change:

After the change:

I also tried full negative pitch on the ground. Maintaining the desired RPM required almost 100% power output, peaking at just over 26A. After the flight, I did some temperature measurements of the motor: the copper windings were around 58ºC.

Castle also released an updated firmware (v3.23). It’s currently in beta, so I won’t try it just yet and stick with the latest stable (3.20). I do note it here however, since they changed the throttle ranges: old, new. Remember that I needed to extend my END-POINTS to get the ESC to arm; aparently so did a lot of other people.

Comments:
My miniTitan was repaired and had a new ESC. Time for the first test flight. After a minute of hoovering, I shortly pushed full collective to check the governor. The headspeed dropped, not surprisingly since the governor is set to it’s lowest setting. So I pushed full collective again, to see if the governor is able to compensate.

Again the rotor headspeed dropped. The governor did compensate, but only the motor rpm increased, not the rotor’s… And then the ground intervened. I squeezed the remaining rpm’s out of the rotor to soften the crash, but it did hit fairly hard.

Damage report:

• Both Battery side plates snapped
• Base plate ruptured as well
• Canopy retaining post broken off

Cause of the crash: the pinion gear was slipping over the motor axle on high torque. This may have been the case all along since the previous crash, but went unnoticed since this was the first high torque test…

The log confirm this: after the crash, I tried to spool up again. The “rotor” speed as seen by the controller gets back up to 2200rpm, but the current required to do so is way to small compared to what it should be (around 5A).

As soon as you download the data, the Log viewer is opened automatically presenting the full log. You can limit the graph to only one session (flight). The bottom shows the different datasets. Clicking their name adds them to the graph. You can zoom and pan by using the mouse; while hoovering the cursor, the bottom numbers show the numerical value of the different parameters at that instant in time.

You can save the data into a “csv file“. The term CSV is rather loosly interpreted, as the file contains some “comment lines” that are not in CSV-format. While the Log Viewer tool provides an export function for the graph data as well, I didn’t feel like exporting half a dozen of graphs for every flight by hand. So I stirred some perl magic and gnuplot wizardry together into a script that reads the CSV log file and produces a set of graphs for each session (flight) in the log:

I decided to upgrade to a more advanced ESC: the Castle Creations Phoenix Ice 50. In comparison with the original one, it has:

• a switching BEC instead of a linear one
• can switch more current (50A vs 40A)
• has data-logging capabilities

I didn’t really care about the current, since my motor can only handle 20A (30A peak). The data-logging was something I wanted from the beginning, but I didn’t want to put yet another box onto my heli. I bought the Castle Link and the QuickConnect as well, so I could access the data easily. Total price: €102 (including shipping).

For future reference: this is the configuration of the ESC when first connected. Out of the box, my motor turned “backwards”. I know you can switch any two cables to fix this, but that would ruin the color-coding of the cables. I also enabled governor mode, and tweaked some other settings to my taste. Here are my current settings.

I needed to change my Tx as well. Apparently Futaba’s zero-throttle position isn’t low enough to be recognized. I needed to extend the end-points (ATV’s) up to 130. My Throttle-Hold switch is configured to be at +10%, which is recognized as “autorotation mode” by the ESC. Basically this cuts the engine, but bypasses the slow-start-up phase when you switch out of it. The old throttle curves (60%) gave me roughly 2200rpm headspeed, so I left them unchanged.

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)

Given that k = 1.38×10^-16 erg/°Kelvin [1.38 × 10⁻²³ J/K], and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10^-16 ergs [4.41 × 10⁻²³ J] every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.

Now, the annual energy output of our sun is about 1.21×10⁴¹ ergs [1.21 × 10³⁴ J]. This is enough to power about 2.7×10⁵⁶ single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2¹⁹². Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.

But that’s just one star, and a measly one at that. A typical supernova releases something like 10⁵¹ ergs [10⁴⁴ J]. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.

These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

The calculations are slightly off; however, it does give a very good indication how far bruteforcing can go, ever.

When you cycle through all possibilities by incrementing the counter, the number of bit changes is higher. To count up to N, you need N flips of bit 0 (the least significant bit); N/2 flips of bit 1; N/4 flips of bit 2; … Some clever mathematicians proved that 1+1/2+1/4+1/8+… = 2, so you need 2N bitflips in total. A 187bit counter hence requires 2 * (2^187-1) bitflips, roughly 3.9E56.

By iterating in a smart way, you can reduce the number of flips to half of that. Calculating this smart way may however require more energy than you’re saving…

echo 3 > /proc/sys/vm/drop_caches

Writing 1 only clears the pagecache; 2 clears the dentries and inodes; 3 clears all.

I have a Futaba FF9 remote, so they wanted me to buy the “adapter cable to FF9″ for €16. Since I already had the pinout of the FF9-connector figured out, I figured I could make this cable myself.

Since the FF9 connectors are hard to find, I wanted to reuse the one I have. So I worked out a wiring scheme that would allow me to connect pretty much everything to everything.

The standardized interface

I chose an RJ45-jack (officially called 8P8C), since they’re easy and cheap. I got my inspiration from the RS232-over-RJ45 idea:

1. not connected
2. not connected
3. ground (output)
4. signal out
5. signal in
6. ground (input)
7. sim signal
8. sim signal

I numbered the connector ((c) David Monniaux) from right to left, but as long as you are consistent it should work. The two sim signals are shorted on the slave-side. On my FF9, that activates simulator mode: switch on the device, but without HF-transmitter on.

Note that by simply crossing over the pins, the output is fed into the input of the other remote. My “master-slave” cable does this crossing for pins 3, 4, 5 and 6; it also shorts pins 7-8 on the slave-side.

FF9 pinout

My FF9-cable now looks like this:

1. not connected
2. ground – connected to RJ45 pins 3 and 6
3. signal out – connected to RJ45 pin 4
4. sim signal – connected to RJ45 pin 7
5. sim signal – connected to RJ45 pin 8
6. signal in – connected to RJ45 pin 5

Phoenix pinout

The phoenix cable terminates on an 3.5mm male mini stereo jack ((c) Dinesh Pratap Singh) (officially TRS connector). So I tied together a female socket and an RJ45 connector:

• sleeve – ground – connected to RJ45 pins 3 and 6
• ring – ??? – not connected
• tip – signal in – connected to RJ45 pin 5

Comments:
Looking for, buying and rennovating a house appears to have a remarkable ability to consume every bit of spare time I had. I finally found some time to wake my bird from hibernation.

I topped the batteries to compensate their self-discharge during the last 10 months. I wasn’t expecting my nitro-engine to start smoothly, but it worked perfectly.
I only hoovered a bit around to regain my muscle memory.