The provided software only supports the bare minimum, both in functionality and user interface:

It’s Windows only, there is no zooming functionality and no exact value readout. The file format for the “Log file” is some obscure binary format. In short, inadequate.

The hardware

The provided communications hardware is decent. It’s a small ~1*3cm PCB with a female mini-USB connector on one side and a pigtail leading to a female Futaba J-type connector on the other side, which plugs into the charger.

This board is actually just an USB-to-Serial convertor by SiLabs. SiLabs provides drivers for Windows, Mac (local copy) & Linux
(local copy).

The protocol

The protocol seems to be fairly simple. Just connecting the charger to PC already produces a stream of bytes. There is no need for the computer to send any requests. I use a simple perl script that opens the serial port in the correct mode and produces the read bytes on STDOUT. The bytestream consists of 74 byte long messages wrapped in curly braces (`{` (0x7b) and `}` (0x7d)).

7B 9E 84 84  D0 85 80 EE  81 81 81 80  81 94 8A 80
81 96 82 8A  82 8E 86 81  81 80 8A 80  8A 80 8C B2
80 82 95 87  CC 80 80 80  80 8D CF 80  BA 83 D8 83
D6 80 80 80  80 80 80 80  80 80 80 80  80 80 80 80
80 80 80 80  80 80 81 8F  A4 38 30 7D

The last two bytes each contain 4 bits of the 8-bit checksum of the first 72 bytes:

(0x9e + 0x84 + … + 0x8f + 0xa4) % 0x100 = 0x80 -> 0x38 0x30

The 72 data-bytes all have their high 0×80 bit set, it only contains 7 bits of data. For the rest of this discussion, I’m only referring to the lower 7 bits of each byte. Here are the data-pieces that I discovered. Byte numbers start at 0 for the first data byte (i.e. 0x9e).

• Byte 7 contains part of the state
• bit 0×01 is set when charging, clear when discharging
• bit 0×10 is set when cycling, clear when single charging or discharging
• Byte 8 contains the set NiCd charge current in dA
• Byte 9 contains the set NiCd discharge current in dA
• Byte 12 contains the set NiMH charge current in dA
• Byte 13 contains the set NiMH discharge current in dA
• Byte 14, bit 0×01 contains the cycle mode, set for {Charge,Discharge}, clear for {Discharge,Charge}
• Byte 15 contains the cycle count
• Byte 16 contains the set Li__ charge current in dA
• Byte 17 contains the set Li__ charge cell count
• Byte 18 contains the set Li__ discharge current in dA
• Byte 19 contains the set Li__ discharge cell count
• Byte 20 contains the set Pb charge current in dA
• Byte 21 contains the set Pb cell count
• Byte 22 contains the mode:
• 0×80: Config
• 0×81: Li
• 0×82: NiMH
• 0×83: NiCd
• 0×84: Pb
• 0×85: Save
• 0×86: Load
• Byte 23 contains the running state: bit 0×01 is set when running, cleared when standby
• Byte 24 & 25 contain the set NiMH discharge voltage in daV and cV
• Byte 26 & 27 contains the set NiCd discharge voltage in daV and cV
• Byte 32 & 33 contain the actual current in A and cA
• Byte 34 & 35 contain the catual voltage in V and cV
• Byte 40 & 41 contain the input voltage in V and cV
• Byte 42 & 43 contain the charge in dAh and mAh
• Bytes 44 & 45; 46 & 47; 48 & 49; 50 & 51; 52 & 53; 54 & 55 contain the individual Li__ cell voltages in V and cV
• Byte 69 contains the time in minutes

Or if you’re lazy, just feed in the bytes into this perl script.

The specs

The charger is run from DC power. It accepts 11-15V DC, so it’s designed to run of a car battery or an equivalent power supply. Make sure your power supply can provide enough power! I used an 28A 13.8V switched-mode power supply.

The box contains 4 independent chargers, with only their input connected together. In fact, they are so independent, that they even crash independent:

Each of the 4 chargers can charge:

• Lithium-based batteries (Lithium-ion, Lithium Polymer and the newer Lithium Iron Phosphate), up to 6 cells in series (22.2V) with built-in balancer
• Nickel-based batteries (NiMH and NiCd), up to 15 cells (18V)
• Lead-Acid batteries, up to 10 cells (20V)

It supports charging at up to 5A or 50W (whichever limit is reached first) per charger, which isn’t particularly fast. However, this isn’t particularly important when charging Lithium-based batteries. These require a CC-CV charging process: batteries are charged with a constant current (CC-phase) until they reach 4.2V/cell. After that, the charger switches to constant voltage (CV-phase) and maintains that 4.2V/cell by decreasing the charge current. When the charge current reaches 0 (or practically, 2% of the original charge current), the battery is considered full. This means that the CV-phase will always take the same amount of time, independent of the charge current during the CC-phase. This graph suggests that the CV-phase takes ~24 minutes.

The hardware interface

The input side consists of two 4mm “banana” bullet connectors which plug right in to most power supplies. They also provide clamps, so you can clamp on to a car battery.

The side of the batteries has 4 pairs of 4mm sockets. The included accessories include conversions to crocodile clips, male Tamiya connector, female Futaba connector and female JST/BEC connector.

The balance connections are unkeyed and spaced 2.54mm (0.1″) apart, so you can plug JST-XH connectors straight into the charger. The box also provided a board that receive 2S-6S FP/TP, and a second board that receives 2S-6S JST-XH.

The computer interface

The charger also supports a computer interface. To be honest, it was a bit of a disappointment. For one I expected to be able to get detailed voltage/current from all 4 chargers simultaneously. Turns out that not only I’m limited to one charger at a time, only charger 1 and 2 have the needed output port to connect to! Also, the software was provided on an 8cm CD-ROM, which I can’t read in my slot-loading drive! More on this in my next post.

This is a great helicopter for beginners. Its setup is very gentle and it can take some gusty winds. The governor allows you to concentrate on flying before having to fine-tune the engine. It’s also fast to refuel (in contrast with recharging a LiPo battery).

I’m selling it because my new club does not allow nitro.

I’m selling, preferably as a whole:

• The helicopter itself, including manual
• All servos (3x Futaba 3152, 1x 9206, 1x 9254)
• OS 50SX-H Hyper motor (incl manual)
• Gy401 tail gyro (incl manual)
• GV-1 governor (incl manual)
• Rx battery 3600mAh 4.8V, not new but still usable
• battery-monitor: shows the charge-state of the Rx battery
• NO receiver
• fuelpump
• Starter engine & pin
• 4 liters of fuel
• glow heater

In summary: everything you need to fly expect the transmitter, the receiver & a battery charger

I prefer you come and pick it up near Brussels, Belgium; that way I can show you it still flies.

If you are interested, feel free to propose a price.

Of course, all my batteries were fairly dead. The glow heater was completely gone (0V), but was still usable after charging. My starter-battery was dead beyond repair. The LiPo’s of the miniTitan were is fairly good shape after more than a year in the fridge: 3/4th charged.

Before the flights, I upgrade my CastleLink software to version 3.40.0, and upgraded the ESC firmware to 3.27 along with these (PDF) new settings.
Place: Roeselare
Tanks flown: 2
Time flown: 0h29 (cumulative model timer: 32h51)

I was glad the Raptor still started without much trouble after collecting dust for over a year. The engine sounded like before and I did not notice any drop in power.

However, for the first time, I’m starting to feel the limits of my servo’s. They’re fairly low-end Futaba 3152′s which are great to learn to fly, but can’t keep up in more aggressive maneuvers.

I also took the miniTitan out for a fly (log). It hoovered well, but felt underpowered. Didn’t take long to figure out why: 2000RPM isn’t particularly fast for a 450-sized heli, and I already figured out to set the governor gain higher than low.

Time flown: 0h18 (cumulative model timer: 4h58)
Flight battery recharged with: (2) 539 mAh

After the flight, I had some trouble connecting to the Castle ESC to download the logs: I had to bypass the QuickConnect.

Installing

I again used the openwrt modules, openvpn has its own package. There are, however, several dependencies:

• libssl.so.0.9.8 and libcrypto.so.0.9.8 from libopenssl
• liblzo2.so.2.0.0 (and symlinks) from liblzo

I already had libcrypto installed, so I only needed 713kB of free space.

Configuring

Setup was fairly straightforward. Just make sure to do all heavy calculations on your desktop computer (i.e. generating keys). I installed the CA and host certificate into /jffs/etc/ssl, and added my openvpn-specific config files into /jffs/etc/openvpn. I did rewrite the verify-cn script from perl to bash, since dd-wrt doesn’t come with perl.

Next, I wrote a very simple wanup script to get openvpn (re)started at the appropriate time:

# openvpn.wanup
if [ -e /tmp/openvpn.pid ] ; then
    kill -HUP `cat /tmp/openvpn.pid`
else
    /jffs/sbin/openvpn --cd /jffs/etc/openvpn --config server.conf --daemon --log /tmp/openvpn.log --writepid /tmp/openvpn.pid
fi

Obviously: don’t forget to add the corresponding configuration to the firewall.

Since we currently already have an OpenVPN tunnel, I preferred to stay with OpenVPN rather than switch to a different stack. Turns out OpenVPN supports IPv6, but under a series of assumptions. Among others, you need OpenVPN 2.3 on both the client and the server to be able to use the new config directives such as route-ipv6. At this moment, 2.3 is still beta. While I enjoy beta-software on a daily basis, rolling it out as a production VPN seems a bit to risky.

To provide maximal compatibility, I decided to stay with OpenVPN 2.2 and use the tap-interface. I wrote my own up-scripts to take care of the required IPv6 configuration steps.

Communicating the parameters

OpenVPN has a setenv config directive, which sets additional environment variables for the up-script. Its brother setenv-safe (which prefixes all variables with OPENVPN_) can also be pushed from server to client, allowing arbitrary parameters to be communicated from server to client. I use these three:

push "setenv-safe IP6_PREFIX 2001:db8:0:1::/64"
push "setenv-safe IP6_GW 2001:db8:0:1::1"
push "setenv-safe IP6_ROUTES '2001:db8:0:0::/48 2001:db8:1234::/48'"

Configuring the client

The client now has all the information it needs to enable IPv6 on the tunnel-connection. It just needs to apply that knowledge. I wrote some very basic shell scripts to accomplish this. Basically, the script looks for the MAC-address of the (virtual) VPN interface, which it uses to form a SLAAC address together with the supplied prefix. At this moment, it does not check for duplicate IP addressing. Next, it configures the calculated IP onto the interface and adds the supplied routes to the routing table.

For those interested, I provide, without any warranty <insert legalese disclamer here>

• The MacOSX version, written in bash
• The Linux version, written in bash
• The Windows version, a batch-file and powershell hacked together

For the most part, this major changeover happened without as much of a hitch. In fact, if I hadn’t known it was World IPv6 day, I wouldn’t have noticed anything. But I’m not a normal web-user, so I did notice some issues.

Where it did went wrong

After some troubleshooting, they all boiled down to a single cause of oversight. They were not bugs or issues with IPv6 per se, just some “expected behavior” that we didn’t anticipate: IPv4-only VPNs.

Most servers in our datacenter are not publicly accessible; none of them are manageable over the public internet. In order to connect to them, you need a VPN connection. This serves multiple purposes: it secures all communication between client and server (so even plain-text http can be used securely to manage servers), it limits the number of users with access and most importantly (in the IPv4 world) it allows us to use RFC1918 addresses internally and still get the routing to work out. Technically it behaves an an extra (virtual) network card with a (virtual) cable connected straight to the datacenter. Additionally, some routes are configured automatically on the client to make sure traffic to the servers is sent over this “cable”.

We use two kinds of VPN-connections, but none of them was IPv6 enabled (i.e. could carry IPv6 data through the tunnel). Since by default client software prefers IPv6 connections, this caused the IPv6-internet connection to be preferred above the IPv4-VPN connection. Obviously, the firewall at the datacenter didn’t agree and refused access.

The solution was fairly obvious to state (enable IPv6 through the tunnels) but difficult to implement. In fact, I have not been able to get it to work well enough to install it on someone else’s computer.

The attempts

IPsec in transport mode

The “natural” solution would be to secure the IPv6 packets with IPsec, preferably in transport mode, between the client and the firewall. Since there are no NAT-issues, tunnel mode is not required.

However, I was not able to get this to work, even in manual keying mode (i.e. without ISAKMP). I couldn’t get setkey to accept the src-dst parameter in the SPD:

# setkey -c
spdadd 2001:db8:0:1::1 2001:db8:1:1::3 any -P fwd ipsec esp/transport/2001:db8:1:0:2-2001:db8:1:1::3/require;
^D
# setkey -DP
2001:db8:0:1::1[any] 2001:db8:1:1::3[any] any
 fwd prio def ipsec
 esp/transport//require
 created: Jun 14 12:13:53 2011  lastused:                    
 lifetime: 0(s) validtime: 0(s)
 spid=1641 seq=1 pid=10485
 refcnt=1

This seems to be a Linux issue (Ubuntu 10.04 LTS with kernel 2.6.32-28-generic and ipsec-tools 0.7.1), since this does work on MacOSX (10.6.7).

IPsec tunnel mode

Since I’m not entirely sure that what I tried above (transport mode) is even supposed to work, I also tried tunnel mode. This worked, but is a pain to configure. I only tried manual keying, but using racoon to do username/password authentication will be even harder to explain to users…

The Mac built-in VPN client only supports “Cisco IPsec“. This uses the mode configuration stage to communicate the set of “networks” to tunnel (i.e. the SPD). However, according to racoon.conf man-page, I can only push IPv4 networks in the split_network directive.

OpenVPN with tun driver

According to the OpenVPN FAQ, IPv6 is only supported if the underlying TUN-driver supports it. The tuntaposx-page does not mention IPv6 at all and hasn’t been updated for almost 2 years, so this seems unlikely to work.

Also, OpenVPN does not provide configuration directives to push IPv6 routes over from server to client.

OpenVPN with tap driver

Even when using the TAP-driver and router advertisements, MacOSX does not seem to like enabling IPv6… Even after manually enabling it, MacOSX still doesn’t pick up its SLAAC address:

# ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 7e:95:80:00:90:0e
 inet 192.0.2.10 netmask 0xffffff00 broadcast 10.90.9.255
 open (pid 3847)

# ip6config start-v6 tap0
Starting IPv6 on tap0.

# sleep 60 # Wait for Router advertisement to show up

# ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 7e:95:80:00:90:0e
 inet 192.0.2.10 netmask 0xffffff00 broadcast 10.90.9.255
 inet6 fe80::7c95:80ff:fe00:900e%tap0 prefixlen 64 tentative scopeid 0xa
 open (pid 3847)

And this still doesn’t allow me to push IPv6 routes to the clients upon connecting.

The conclusion

IPv6 is very stable and capable, but there are certain network-issues where there is still some work to do. If you happen to know a VPN-solution which supports IPv6 and works on Windows, linux and Mac, please let me know!

Edit: I worked out my own solution.

You can set up Time Machine to automatically back up all your important files, including your documents, music, photos, applications, and any other items you keep on your hard disk.

I consider my iTunes authorizations important, but apparently Apple does not. Seems that these are specifically excluded from backups… Removing the “SC Info” line from the /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist file solved this.

I know I should have de-authorized my machine before reinstalling, and I know you can “de-authorize all” to fix this as well; but it’s pretty disturbing to see iTunes remove all your applications from your iPhone…

So I wanted my own router to establish the PPPoE connection and obtain a public IPv4 address. It seems that even here the default setup of the b-box2 is good: PPPoE passthrough is enabled by default. This technique allows you to establish a PPPoE connection from the “LAN”-side of the router, effectively bypassing it. There are numerous posts how to reconfigure the b-box into RFC 1483 bridge-mode, but this is not required! So just plugging in my router and configuring PPPoE on it was enough!

There are some finishing touches however that can be learned from the bridge-posts:

• I disabled my PPPoE connection on the b-box itself. I will not be using it, so there is no need to waste a public IPv4 address here.
  In the webinterface (http://192.168.1.1/ by default) go to Advanced Settings – Network Interfaces. Open the Wan PPPoE and Disable it, confirm by clicking OK.
• I also disabled the built-in WiFi access point, since I have my own 802.11n access point right next to it. This is even officially documented.
  Advanced Settings – Wireless and click Deactivate.

So I wrote a very simple perl-script that automates this for me. It behaves like cat, but inserts empty lines between input lines proportional to the amount of time between them. The numbers of lines inserted in logarithmically proportional to the elapsed time: one line for the first second, a second line for the next two seconds, a third line for the next 4 seconds, …

$ tail -f /var/log/mail.log | logtail.pl | sed 's/ .*//'
2011-03-09T10:33:02+01:00
2011-03-09T10:33:02+01:00
2011-03-09T10:33:02+01:00
2011-03-09T10:33:02+01:00
 
 
 
 
2011-03-09T10:33:36+01:00
2011-03-09T10:33:36+01:00
2011-03-09T10:33:36+01:00
 
 
 
 
2011-03-09T10:34:01+01:00
2011-03-09T10:34:01+01:00
 
 
 
 
 
2011-03-09T10:34:36+01:00
2011-03-09T10:34:36+01:00
2011-03-09T10:34:36+01:00
 
 
 
2011-03-09T10:34:48+01:00
2011-03-09T10:34:48+01:00
2011-03-09T10:34:48+01:00