Long-term Memory

When it came to tuning my nitro engine, most guides referred to subjective measurements: “enough smoke”, “accelerates swiftly”, “sounds good”, … I, as a nitro-engine newbie, did not know what an engine should sound like and how much smoke it should produce.

I finally found some objective criteria to figure out whether the engine is too rich or lean: the temperature. This PDF by Tony Chaveiro reviews a CarbSmart needle controller, which uses the head-temperature as a feedback mechanism.

Apparently, 100°C is a nice head temperature to aim for. Leaning the mixture will increase the temperature, giving more fuel will cool it down.

I don’t know how I’ll use this knowledge to tune my engine, but at least I have an objective way judge the mixture.

I just came across some very weird behavior on a family members Apple MacBook. For whatever reason, Finder does NOT show all files in a folder. The folder is located on an SMB share, but I’m not sure if this has anything to do with it. The machine is fully patched with all software updates available on the day of this post.

Here is a screenshot illustrating the behaviour (some text blurred intentionally to protect privacy):

As you can see, the Terminal DOES show all files (e.g. the “untitled folder”).

Until here, this seems strange, but is probably some weird setting somewhere. But it gets a lot weirder.

Continue reading ‘Weird MacOS X Leopard behaviour: Finder hides files’ »

I keep a logbook of every flight I make with my Raptor. Here is the entry for today. I’ll probably do some history-posts to get my complete logbook in the same database.

Place: Halle
Tanks flown: 2.5
Time flown: 1h20 (cumulative model timer: 20h38)
Rx battery recharged with: 1861 mAh
Tx battery recharged with: 773 mAh
Glow heater battery recharged with: 763 mAh
Starter battery recharged with: 1416 mAh

Comment:
A lot of wind at the field; it was difficult to keep him in a stable “hoover” (read: sideways flight into the wind).

Tried some figure-8’s with nose pointing in the right direction (i.e. forward). I learned the hard way that turning from downwind to upwind requires a lot more power than the other way around. That, combined with a pilot error, left we with my heli falling down much faster that anticipated. I don’t recall what happened next, but some scary moments later I found my heli coming to a stop at 1m altitude, fighting gravity at full power…

I convinced myself to fly another tank; to overcome the fear. Hoovering in front of me, I noticed some vibration in the rotor, along with a strange sound. I couldn’t see the tracking very clear, but it seemed to be fairly good. I landed and verified all links on the rotorhead; none of them felt loose. When trying to restart the engine, the glow-heater wasn’t able produce much current. I’ll have to check my glow extender and plug.

When I finally got the engine running again, the first few minutes where fairly normal flight. Next, the strange sound reappeared. Also, my RPM was somewhat lower than usual. The sound came and went, but it was definitely the rotor producing it. After landing the heli I found the source:

I guess I’ll have to re-balance the rotor again…

One of the things I like about Vim is its support for syntax highlighting and folding. Especially when reviewing or editing config-files, the coloring is a true relieve. (Yes, I am aware that emacs can do this much better, nicer, easier and with a lot more Meta-Control sequences.)

Googling for a syntax file which would color the Cisco configuration files for me didn’t get me very far. So I decided to run my own. Here is the result:

(Public IPs in the screenshot are masked by 0’s)

Continue reading ‘Cisco config syntax highlighting in Gvim’ »

As a follow-up on my previous post on the Futaba FF9 trainer interface, I’m reporting the measurements of my E-Sky “0404” remote.

The E-Sky uses a much more popular 4-pin miniDIN connector:

Pin numbering is left-to-right, bottom-to-top: left-bottom is 1; right-bottom is 2; left-top is 3; right-top is 4; shield is all around.

Using the described pin-numbering, I measured the following signals:

• pin 1 – shield: negative modulated PPM. Mostly high (1.7V), shorter pulses low (0V)
• pin 2: high impedance/not connected
• pin 3 – shield: 4V DC; probably used for remote power to the slave
• pin 4: low impedance, no signal; probably PPM input when in master mode

When configuring a bunch of devices (switches, routers or even computers), most of the configuration will be identical. The Konsole program of KDE has a nice feature which sends the keyboard input to all open tabs. By simply telnet-ing or ssh-ing into the devices and activating this feature, I can quickly configure them all at once.

At work, using my Windows laptop, I have been looking for a feature like this. After some googling I found PuttyCS. It’s a standalone application which emulates this behaviour: It sends emulated keypresses to all (or a subset of) open putty sessions.

Configuring 8 blade-switches with PuttyCS is a breeze: just open all the putty sessions and start typing in PuttyCS!

When learning to fly a remote controlled model, getting a good teacher is worth a lot. But if all the teacher can do is watch the plane crash, he/she is of not much use…

Most transmitters have a “trainer” connection. This allows two remotes to be connected together. One is preforming the master-role and is actually controlling the model. The other remote is the slave and sends signals to the master. The teacher can program his master-transmitter to copy some of the slave’s signals, thereby letting the student control the plane. A simple toggle of the switch returns the control to the teacher.

Obviously, each brand of transmitters has its own “standard” of doing things. Some use a DIN6 contact, others use a mono- or stereo 3.5mm jack and there is the obligatory “proprietary connector”. Here are my notes of the expedition into the trainer-cable jungle.

Continue reading ‘Futaba FF9 Trainer interface’ »

To deal with loops in switched networks, the Spanning Tree Protocol was developed. For a description of how STP works, see the Wikipedia page on the subject; in short, it disables certain ports on certain switches to break loops. So far so good.

When using VLANs, there are several alternatives:

• Use a Common Spanning Tree: i.e. use the same topology for all VLANs.
• Use Per Vlan Spanning Tree: i.e. run a separate STP instance for each VLAN.
• Use Multiple Spanning Tree: This is the IEEE standard and is a compromise.

In MST, VLANs can be mapped to instances. All VLANs mapped to the same instance share the same Spanning Tree. This allows some flexibility by using multiple instances, without the CPU problems of running a single instance for each and every VLAN.

Now consider the following situation:

This diagram uses only 2 VLANs: a data VLAN, drawn in blue, and a management VLAN, in red. The data VLAN is used to connect the Left and Right switch together, along with the attached servers. The management VLAN is only used to manage the switches.

When implementing this on Cisco switches (I tried it on Catalyst 3750s), everything works as expected. The two servers can talk to each other, both switches are manageable.

When implementing this on HP ProCurve switches (I tried it on 5400s, 2610s and 2810s), this does not work: Depending on the MAC-addresses of the switches, either the servers cannot talk to each other or one of both switches is disconnected from the management station…

Continue reading ‘HP ProCurve: MST misbehaves’ »

When demonstrating my Raptor last week, I noticed some resonance in the body just before reaching my normal flying RPM. I only noticed it briefly during the spool-up, once the rotor reached its normal speed of ~1700rpm the vibrations where gone. This called for a checkup of the rotor balance, which is what I’ve done this weekend. I used the page over at Raptor Technique to guide me through the process.

The blades seemed to be fine; their Center of gravity matches almost perfectly (less than 3mm difference). Their weight also looks fairly identical, as I could balance them on the (blunt) edge of a knife (1.5mm wide).

Next up was the flybar. I noticed that both paddles are not aligned as it should be. After some tweaking, this is the result:

Which seems a lot better than before!

All that’s left is give it a test-flight and see if it’s better; but with the current weather, it will have to wait a few days.

The main reason why I decided to start this blog is summarized by its title: to keep me from forgetting things. Instead of filling my (physical or virtual) desktop with post-it notes, I decided to share my long-term memory with the rest of the world.

In short, this blog will consist mainly of ideas, notes and how-(not)-to’s that I’d forget otherwise.