Where to spend money as a new motorcycle rider (Part 1)

Introduction

Today’s ride made me consider some points I wish I had known earlier as a motorcycle rider. Those who know me can attest that I am slightly frugal when spending money on toys and gear. Not that I don’t buy stuff, but I usually want to be really sure that it’ll do what I imagine before committing to a purchase, especially when it comes to stuff with large price tags. This planned series of articles will contain information that wasn’t readily available to me before I actually bought the gear. My hope is to be able to share what’s worth its price and perhaps some stuff that I bought which quite frankly is a waste of money.

Hearing protection

Get custom molded ear plugs. Really.

Earplugs
In the package: One set of earplugs, a cleaning tool, and a mild cleaning agent (not shown).

They will set you back a bunch – the ones I bought at Hear Nordic, the HearSafer HN9 (Blue) cost around SEK 1700, or almost $200. True, you can buy quite a lot of plugs for that kind of money. But having tried all cheap and not-so-cheap kinds for almost a decade, and then riding with these more expensive ones during this season, here are my arguments for this investment:

Molded plugs are not painful to wear for extended periods of time.

Foam plugs will heat up to your body temperature. This can have one of two effects: Either, they will expand slightly, creating pressure inside your hearing canals, which will become extremely painful after a couple of hours. Similarly, the baffles of “christmas tree” style ear plugs will create painful pressure points in the hearing canals. The problem with wearing hearing protection that hurts, is that after a while you won’t – you will need to rest your ears for a while every couple of hours. Unless you’re disciplined enough to drive so slowly that the wind noise stays at a safe level, you will cause temporary or permanent hearing damage. This isn’t a matter of opinion. It’s a fact.

Molded plugs in contrast are made from a hard resin which doesn’t lose its shape over time. Since they are individually molded exactly to the shape of your hearing canals, there is nothing which will create pressure points, and only large jaw movements like yawning can flex your ears enough to let some unwanted sounds in.

Molded plugs won’t move around with your helmet

A constant problem with both foam plugs and baffle plugs are that they will move around in your ears due to the movements of your helmet and your jaw. Some rides, you simply won’t be able to get them to fit properly to block sound as they should, and that’s really just as bad as not wearing hearing protection.

Molded plugs are manufactured to end flush with your ear hole. A small ridge or depression in the end allows you to fit a finger nail to pull them out, but that manual intervention is what is required to pull them out. Since they follow the natural curvature of the canal, they won’t accidentally move into a position where they let unwanted sound through. Even large jaw movements like yawning only temporarily extend the hearing canal enough to let some noise pass on the outside of the plugs.

Molded plugs will let some frequencies through easier than others

Professionally molded plugs come with a “vent” that a) allows a little air through so you don’t block it in when inserting the plug, and b) allows for a selectively filtered frequency band to pass through less obstructed than other noise. This ensures that you hear other traffic noise and even human speech to a better extent than massive plugs would.

Pros and cons

This really is a no-brainer: The single negative of molded ear plugs are the price. Save up and get a pair if you ever plan to spend more than about an hour on your bike in a day.

Setting up my gaming computer in Ubuntu 16.04

Hardware

Stock Intel i5-based computer that like most PCs boots into vanilla Ubuntu without any trouble at all.

The special stuff:

  • nVidia GTX 670 graphics card (requires proprietary driver to give acceptable 3D acceleration)
  • Foris FG2421 screen capable of running at 1920×1080 @ 120 Hz (requires the existence of a monitors.xml file to keep this refresh rate across reboots)
  • CH Products Fighter Stick and Flight Sim Pedals (the latter aren’t seen as a joystick device since they lack buttons, and so the permissions get screwed up so they can’t be read by games and simulators like X-Plane)
  • Secondary drive where I have my Steam stuff (120 GB is OK for a boot drive, but get some custom scenery into X-Plane, or install World of Warcraft, and it eats stuff up pretty fast)

NVIDIA drivers

  1. Search for drivers and run the application.
  2. Change from Nouveau to NVIDIA 361.42 (as of may 2016) – Apply changes and reboot.
  3. Search for NVIDIA X Server Settings and run the application
  4. Resolution -> 1920×1080, 120 Hz and apply

Permanent screen resolution settings

  1. Run System Settings -> Displays.
  2. Change a setting, change it back and Apply. This should be enough. Check the monitor’s On Screen Display menu to confirm the resolution and refresh rate.

For troubleshooting purposes, the above points should have created ~/.config/monitors.xml – if not, the screen will revert to its default refresh rate of (usually) 60 Hz after re-logging or rebooting the computer.

Contents of my ~/.config/monitors.xml:

<monitors version="1">
  <configuration>
      <clone>no</clone>
      <output name="DVI-I-0">
      </output>
      <output name="DVI-I-1">
          <vendor>ENC</vendor>
          <product>0x2457</product>
          <serial>0x01010101</serial>
          <width>1920</width>
          <height>1080</height>
          <rate>120</rate>
          <x>0</x>
          <y>0</y>
          <rotation>normal</rotation>
          <reflect_x>no</reflect_x>
          <reflect_y>no</reflect_y>
          <primary>yes</primary>
      </output>
      <output name="HDMI-0">
      </output>
  </configuration>
</monitors>

 

Joystick + Pedals configuration

My own take on the write-up at http://developer.x-plane.com/2012/09/linux-joystick-permissions/ – in turn courtesy of a Bill Good:

  1. The relevant output from lsusb
    ...
    Bus 001 Device 008: ID 068e:00f2 CH Products, Inc. Flight Sim Pedals
    Bus 001 Device 007: ID 068e:00f3 CH Products, Inc. Fighterstick
    ...
  2. Create the file /etc/udev/rules.d/99-CHProducts.rules and give it the following two lines:
    KERNEL=="event*", ATTRS{idProduct}=="00f2", ATTRS{idVendor}=="068e", MODE="0666"
    KERNEL=="event*", ATTRS{idProduct}=="00f3", ATTRS{idVendor}=="068e", MODE="0666"
  3. Run sudo udevadm control –reload-rules to load the rules without invoking an unnecessary reboot.

Steam on a separate drive

There are two ways to go about it; earlier I mounted my secondary drive as /opt and put a symlink from ~/.steam towards /opt/games/steam, but I figured I can just as well put my entire home drive on the other drive just for good measure.

Relevant output of blkid /dev/sdb1:

/dev/sdb1: UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx" TYPE="ext4"

Add the following line to /etc/fstab:

UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx" /home    ext4    defaults    0    0

Move the home directory (unless you already have one):

$ sudo mkdir /mnt/sdb1 ; sudo mount /dev/sdb1 /mnt/sdb1
$ sudo mv /home/* /mnt/sdb1/
$ sudo umount /mnt/sdb1

Note: At this point you have no home directory, which may cause some errors until you’ve re-logged on.

$ mount -a

re-logon, install Steam, and move any existing Steam directory to ~/.steam

Verify by starting Steam. You should see your game library, with previously downloaded titles available for immediate play.

Changing screen refresh rate in Fedora 23

I’ve just installed Fedora 23 on my gaming computer at home, switching from Mint 17.3.

I have an nVidia card (using RPM Fusion to install the non-free drivers still necessary to get any kind of 3D performance out of it), and an Eizo Foris monitor capable of running at 120 Hz refresh rate. It took me a while to figure out how to make the latter work in Mint (create a ~/.config/monitors.xml). Unfortunately, this approach – along with a number of others – didn’t work in Fedora 23.

The solution (and its cause) was embarrassingly simple: I followed the general gist of the initial posts in this discussion thread, using xrandr to output the necessary data and creating a Gnome autostart item  (~/.config/autostart/xrandr.desktop) which starts xrandr with the correct output, mode and refresh rate options. I did not disable the Wayland session where gdm initially runs.

SSL load balancing with HAProxy in VMWare

So this is a new project I’ve recently finished.

Objective
Create a secure high availability (HA) load balancing service spreading user load across two pairs of two servers, providing two different sets of services:

One service requires SSL passthrough, while the other is a websockets connection over SSL, where the use of a proxy demands SSL termination. Securing communications with the web backend for the latter is done by routing the traffic via an OpenVPN tunnel.

The software I’ve chosen for this, is HAProxy 1.5 on FreeBSD 10.1-Release, running in a VSphere 5.5 environment.

Basic server setup

All programs and services are installed via the excellent Ports system, which in itself is a reason to love FreeBSD in a server environment.

The requirement to pass on some SSL traffic untouched and terminate and send on other SSL traffic means I need the two URLs to point at different external IP addresses, and listening on separate addresses in my DMZ after the firewall has taken care of the NAT. The way to be able to listen to several addresses on the same subnet, is to create aliases for the network interface:

/etc/rc.conf:


ifconfig_vmx3f0=”inet 172.27.1.15 netmask 255.255.255.0″
ifconfig_vmx3f0_alias0=”inet 172.27.1.20/32″
defaultrouter=”172.27.1.1″

Note the /32 mask for the alias interface. This is not an error.

HAProxy setup

I’ve set up two separate front-ends for the server. The “integration” part passes on SSL traffic to be terminated by the web server, and the “application” part terminates the SSL connection:


/usr/local/etc/haproxy.conf:


frontend integration_frontend
bind 172.27.1.15:443
mode tcp
option tcplog
log global
option logasap
default_backend integration_pool

frontend application_frontend
bind 172.27.1.20:80
redirect scheme https code 301 if !{ ssl_fc }
bind 172.27.1.20:443 ssl crt /etc/ssl/sitename.pem
mode http
log global
option httplog
option logasap
option forwardfor
default_backend bfx_application_pool

acl is_websocket hdr(Upgrade) -i WebSocket
use_backend websocket_backend if is_websocket

In the “application” section, I add an X-Forwarded-For field to the http header after terminating the SSL connection. The background for this, is that otherwise, the originator of the requests for data from the application web servers seems to be the HAProxy server. With the field in place, the application can return data directly to the actual client.

I also listen for the “upgrade” word in the http header, to be able to properly handle web sockets, using access control lists (ACLs).

The difference between option tcplog and option httplog is that the latter examines the http header, while the former doesn’t attempt to go deeper than the actual tcp packet information. The reason for the difference in configuration, of course, is that if I don’t open the SSL packets, I can’t know the contents of the http header nor manipulate it.

The backend setup:

/usr/local/etc/haproxy.conf


backend integration_pool
log global
option tcplog
balance roundrobin
option ssl-hello-chk

server webserverdmz01 172.27.1.150:443 check
server webserverdmz02 172.27.1.160:443 check

backend application_pool
mode http
log global
option httplog
option http-server-close
balance roundrobin

stick-table type binary len 32 size 30k expire 30m
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
tcp-request inspect-delay 5s
tcp-request content accept if clienthello
tcp-response content accept if serverhello
stick on payload_lv(43,1) if clienthello
stick store-response payload_lv(43,1) if serverhello

server webserver01 10.0.5.1:80 check
server webserver02 10.0.6.1:80 check

backend websocket_backend
mode http
option http-server-close
option forceclose
no option httpclose
balance roundrobin

stick-table type binary len 32 size 30k expire 30m
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
tcp-request inspect-delay 5s
tcp-request content accept if clienthello
tcp-response content accept if serverhello
stick on payload_lv(43,1) if clienthello
stick store-response payload_lv(43,1) if serverhello

server webserver01 10.0.5.1:80 check
server webserver02 10.0.6.1:80 check

One immediate difference between the “integration” and the “application” sections, is that the integration section naturally tests for the existence of its web servers using SSL.

The sections that begin with “stick-table” in the application and web socket sections create what’s called a sticky session, where we attempt to direct a given user to the same web server for every new request they make. This simplifies life a bit for the web application programmers.

Finally, in the application and web-sockets sections, I connect to the respective web servers on port 80, which I can do since I connect via OpenVPN connections directly to the servers.

OpenVPN 2.x and Windows Firewall

The documentation for OpenVPN is pretty good, but I found a detail that may cause some confusion in a Windows environment, so I thought I’d address it here:

What do you do if you need to run OpenVPN but still want the Windows Firewall to work on your Windows server?

The background for this issue is how Windows decides what profile to use for a specific network: It reads the gateway address. The TAP interface for OpenVPN doesn’t automatically receive a gateway, so the network profile for it will be “Unknown network”, and so it won’t allow the necessary traffic for the OpenVPN connection to be properly established.

So what do don’t you do?

First, open up a port in your firewall to allow for the initial handshake to be made between the client and the server. By default, this is UDP port 1194.

The next step is to turn off the Windows firewall in all profiles for the OpenVPN network device:

During the OpenVPN installation, a network device of the type “Tap-Windows Adapter Vx” was created. Rename this device from Ethernet or whatever it’s called to OpenVPN, so you know which device to manipulate. Then open the Windows Firewall with Advanced Security console, open the Properties dialog, and Customize the Protected network connections in each tab (Domain, Private and Public profiles). Uncheck the OpenVPN device in each profile and confirm your changes. Voilá: Your regular network adapter will only be open for the specific traffic you need, and the OpenVPN adapter will be open for all traffic.

Wow; bummer. We really don’t want that, do we?

The real workaround

We’ll do two things:

1) Give the OpenVPN TAP device a gateway. In the server configuration for OpenVPN, you assign a subnet to be used by OpenVPN. The server will be [subnet].1. The gateway will be [subnet].2.

2) Some people claim that the above doesn’t always work unless you set the status of the TAP device to “always connected”, so let’s do that.

The result?

You now have control over data in the VPN tunnel too, using Windows firewall, meaning that you can stop unexpected traffic within the tunnel easily.

Norway tour 2012 debrief

Having spent the weekend riding some 1400 kilometers in the beautiful Norwegian fjord and mountain landscape, I feel like jotting down some notes and almost-reviews.

Scala Rider

This intercom system worked so much better than I thought when I first saw it. I bought a NeckMike system a while ago, since I wanted to combine ear plugs with intercom functionality. In reality, the Scala Rider system does a better job when it comes to communication (it’s got full duplex for one, and second, it’s wireless, which means no forgotten cables when you step off the bike). It’s also fully functional up to about 120 km/h (on an effectively fairing-less bike) with or without ear plugs.

There are three main drawbacks:
1. I needed to “slightly adjust” my helmet to fit the speakers. It doesn’t come with depressions for this kind of communications system, so I needed to cut open the noice-reducing padding on the inside of the styrofoam protective layer to avoid getting cauliflower ears from the speakers pressing against my earlobes. Since the fabric cover for the chin pads is removable, I could do it without destroying anything.
2. The carrier rack for the communications module sticks down below the helmet if you don’t choose to glue it in place. This makes putting on and (especially) removing the helmet somewhat painful after a while, since the opening in effect becomes a little tighter than usual, so the ear on the receiver side tends to snag a little.
3. The accumulator is pretty integrated into the system, which means that with use, the time available for communications will diminish and you can’t do anything about it. Anyone familiar with Apple gear knows this problem. It’s OK if you plan on getting new stuff every other year or so, but a system like this shouldn’t be that upgrade prone, and therefore I count non-serviceability as a drawback.

As I mentioned above, wind noise renders the system useless above 120 km/h or so on a bike without a large windscreen. The sensitivity for voice activation needs to be adjusted or you’ll get closer to 8 than 13 hours of battery life out of it, and on the pair we used, one speaker quit working within a day of use, which probably is an individual problem rather than a design one – but again, miniaturization makes for lousy serviceability.

GoPro HD Hero 2

I never really saw the point of video cams until I really tried one. This one basically has a power/function button and a start/stop button, but it’s surprisingly easy to make nice movies, thanks to the fisheye lens. I edited the resulting raw film with iMovie on my Mac, and the result of an evening of playing around with the material can be viewed below.

The Zero Gravity Tall Windscreen

This was my first real test of the higher windscreen for my bike. Windscreens are a tradeoff between environmental feedback and comfort. Where the XB12X is an excellent hooligan bike and canyon carver, the R1200GS is a ride which lets the pilot step off the bike fully rested after 300 kilometers of highway.

Basically, even with the taller screen, the air – and, as I frequently experienced during this ride – the rain, hits me at the upper part of my chest. At highway speeds, this means my helmet gets pressed into my face, and I need to fight to keep my posture against the wind, and if it rains, it means all the rain that hits the front of my bike will end up on my jacket, drop down, and finally create a puddle in which I sit. This is OK with proper rain gear, but textile riding gear without GoreTex membranes soaks right through after a while in these conditions.

The next thing to try, of course, is a windscreen bracket from Palmer Products, to get the windscreen up a bit and make it adjustable. This should also fix the potential problem of the original rubber grommets breaking at highway speeds, giving me a face-full of windscreen at a hundred mph.

Zero Gravity Buell Touring windscreen review

As per my latest post, I recently received a higher windscreen for my Buell XB12X.

The stock windscreen is low – it puts the slipstream straight in the rider’s stomach or lower chest area. This is perfectly alright for shorter rides – I’ve even seen people entirely remove the windscreen for a more street fighter-like look, but on longer rides or when riding in cold weather, this gets tiring.

Enter the Zero Gravity Touring Windscreen.

It’s only a couple of inches higher than the stock one, but transfers the slipstream to shoulder/helmet level when sitting in an active riding stance, lowering upper body buffeting and making wind noise noticeably quieter. The effect of this is that longer rides become a lot more relaxed, even if it’s not as effective as the barn door of a wind screen that’s mounted on the BMW R1200GS. The difference lies mainly in how you can sit on the bike and still be protected. The larger screen of the GS lets a rider of average height sit upright when riding even at speed. On the other hand: A Buell Ulysses isn’t first and foremost a touring bike, but a sporty bike capable of touring duty. Mounting forward pegs, handlebar risers and sheepskin seat covers goes against everything in the bike’s philosophy, so I simply reject the claims of hard buffeting with the ZG windscreen from riders who’ve done such mods on their bikes – sitting further back naturally puts you in a more turbulent area, and that area naturally lies closer to a smaller screen than it does to a higher one.

Another problem people have written about, is the touring windscreen breaking loose at speed. Some have gone to great lengths to avoid the problem, including mounting large mounting brackets on the flyscreen. I understand the thought, but for now I believe it’s enough to simply use new grommets when fastening the larger windscreen. When testing my setup in controlled circumstances, the windscreen worked perfectly well, albeit with some flexing, in sustained speeds up to 160 km/h. That’s perfectly acceptable when touring. For hooligan duty, it might be safer to go with the lower stock screen, though.

To conclude this post, I’d say that next to the heated grips, this mod is definitely worth it, both for extending the riding season and for making long rides more comfortable.