Thursday March 08, 2007 Alan Perry's Blog
Thursday March 08, 2007 The OpenSolaris Developers Conference
A week ago, I was in Berlin, Germany for the first OpenSolaris Developers Conference. I was there to present a paper that I wrote that describes my effort to port OpenSolaris to the Apple Mac Mini and port MythTV to OpenSolaris. This is part of a longer term personal project to build an OpenSolaris-based set-top box from ordinary PC hardware (look inside a Mac Mini and you will see that the component are ordinary PC components).
The conference was presented by the German Unix Users Group (GUUG) and was co-located with their Spring 2007 meeting. The organizers tell me that about 35-40 people were there for the OpenSolaris conference.
I thought the conference was very well done. The technical content was very good. The presentations were engaging. And, while most of the presenters were from Sun, many weren't and the conference was organized by the GUUG, not Sun.
My favorite presentation was made by Moinak Ghosh from Sun. He is the guy behind the Belenix distribution of OpenSolaris and he spoke about creating Live Media. When I first saw Belenix last year, I was surprised that it could fit on a CD and boot so quickly. It was very interesting to learn how it works. Moinak is a very clever guy.
The conference organizers tell me that there will be an OpenSolaris Developers Conference next year and I will be definitely be there.
( Mar 08 2007, 10:16:42 AM PST ) Permalink
Wednesday February 21, 2007 Setting up a Mac Mini for dual booting Solaris and MacOS X
As I mentioned in an earlier blog, I have been working with Solaris on an Apple Mac Mini. Once you get Solaris installed, it works pretty well, but, in my experience, getting Solaris installed (or, more specifically, getting the disk set-up before the install) was fairly awkward.
Before I get too far into this, I would like to point out that I am not an expert in almost any of the topics involved here. I read up on a lot of new topics as I encountered problems. I spent a lot of time on trial and error experiments, trying to determine which steps I could leave out. I would get Solaris installed, then scrub the hard disk and try it again. Unfortunately, each iteration took around 3-4 hours.
What I am saying is there could be a better way to do all of this.
So, what do you need? Obviously, you need a Mac Mini. I am using the current 1.66MHz Intel Core Duo base model. You also need an external hard disk with MacOS X installed because you are going to be booting up in MacOS a few times. Since you will be messing with the MBR on the internal disk, I wouldn't bet on being able to boot MacOS from it. You need a Solaris Express installation DVD, preferably a recent build.
1. Install MacOS on the internal HD. If MacOS is not already installed and you have to reformat the drive, make sure to zero out the drive (a formatting option with the MacOS Disk Utility). Some of the later steps may interpret whatever happens to be on the disk as valid data and complicate things.
2. Make sure that your Mac Mini has the latest firmware installed and then install Apple's Boot Camp application. You can get it from the Apple Web Site.
3. Run Boot Camp Assistant. This will set up your Mac Mini so that it can boot Windows (and other operating systems like Solaris), allow you to repartition the internal hard disk with a "Windows" partition and start "Windows" installation. The "Windows" partition is where you will install Solaris. I repartition what will be the Solaris partition to 32G. Before hitting the button to "Start Installation", be sure that the Solaris install DVD has been inserted in the drive and recognized by MacOS. After hitting the button, the Mac will reboot from the DVD drive.
4. Boot into Solaris from the installation DVD. At this point, prtvtoc(1m) and format(1m) both report the contents of the MBR as the VTOC. Exit from Solaris installation and confirm this for yourself.
5. Boot into MacOS from the external hard disk. Unmount the internal hard disk. Change the Win32 MBR partition into a Solaris2 MBR partition using fdisk. It should be the third entry, but look for the one with partition type 0B, labelled Win95 FAT-32, to be safe. Edit the entry to change the partition type to BF (Solaris2). fdisk does not recognize the type and labels it as <unknown ID>.
6. Boot into Solaris from the installation DVD. Attempt to install Solaris. It should fail when it tries to partition and label the internal hard disk. However, somewhere during the process enough information is written to allow you to proceed. Without this step, prtvtoc continues to report the MBR info as the VTOC. With this step, if you reboot into Solaris, you can see that prtvtoc acts as if the EFI partition on the internal hard disk is the Solaris partition.
7. Boot into MacOS from the external hard disk and then unmount the internal hard disk. Using fdisk, change type of the EFI partition to something that Solaris doesn't understand (such as AF (HFS+)).
8. Boot into Solaris from the installation DVD. Exit from Solaris installation and run format from a terminal shell. Use format's type command to enter the geometry info for the Solaris partition. After that, you need to reboot for some reason in order for the geometry info to stick.
9. Reboot into Solaris from the installation DVD. You should be able to run through Solaris installation. Just to be safe, before running installation, I set up the VTOC using fmthard(1M).
And it is all that simple.
When you reboot, if you hold down the option key as the Mac Mini comes back up, you will be presented with a couple of disk icons, one labelled Mac OS and the other labelled Windows. The Windows one is actually Solaris.
That's it. Have fun.
( Feb 21 2007, 08:16:20 AM PST ) Permalink Comments [1]
Wednesday February 07, 2007 Look for me at the OpenSolaris Developers Conference
Just a heads up. I will be at the OpenSolaris Developers Conference in Berlin, Germany on 2 Mar, 2007. I will be presenting on my work Porting MythTV to OpenSolaris and the Mac Mini.
This is actually a personal project that I have been working on in my spare time. I wanted to put together a set-top box type system based on OpenSolaris. I used to work on set-top box software and the systems that I was building my code on top of weren't that reliable or that nice to program for. I figured that OpenSolaris would be an improvement and started the project to see if it would work.
I ended up picking the Apple Mac Mini as the set-top box hardware (yeah, I know, it is a computer, but it is a small form factor box and it has a DVD slot as well as an IR remote) and MythTV as the application (so I wouldn't have to start from scratch on the PVR, DVD, OSD, et. al. code). To find out more, come see me in Berlin. I can't wait to see how it works out!
Anyway, I submitted the idea for a paper on the project on a whim to the OpenSolaris Developers Conference after the conference asked me, as lead for the Seattle OpenSolaris User Group, to post the Call-For-Papers to my user group's mailing list. To my surprise, they accepted it. So, now I am spending lots and lots of time trying to get the project in a state that is suitable to present.
One thing that came out of this work is the complicated process that I came up with for installing OpenSolaris on a Mac Mini so you can still multiboot into MacOS to play Backgammon or something. I'll be blogging about that soon.
After the Developers Conference, watch this space for an announcement for a community project to finish off my MythTV port.
That's it and I hope to see you in Berlin.
( Feb 07 2007, 04:41:52 AM PST ) Permalink Comments [1]
I guess I discovered this back in November, but it didn't sink in until yesterday when a friend asked me if I had one to sell. Apple has silently discontinued the Apple iSight external firewire camera. They continue to brand the USB-based cameras that are integrated into the MacBook laptops and iMac as iSight, but if you want a camera for your Mac Mini or Mac Pro, you can't buy one from Apple anymore. USB alternatives that just plug-and-play with MacOS are available or will be soon, I guess. The story in the Apple Discussions area is that the iSight was discontinued because it contained too much hazardous material (hmmm, don't recall seeing a Proposition 65 notice on the box).
As far as I know, the iSight was the last consumer grade IIDC camera available on the market. The professional grade cameras like the Point Grey Research Dragonfly are still available, so IIDC isn't dead. This is just bad for people who wanted a high-quality, inexpensive IIDC camera. There are obviously unhappy people posting their displeasure in the Apple iSight Discussions area.
This is great for the folks who own iSights, but weren't using them because the cameras are now selling for more than when they were new on eBay. It is not great news for the folks who wanted one and didn't realize that Apple was discontinuing the model. I am sure if you continue to wait, prices will come back down to something sane in short order.
Ironically, I was finally getting around to implementing support for the iSight in the Solaris IIDC camera driver (dcam1394). Good thing for iSight fans that I didn't start implementing it sooner.
( Feb 07 2007, 04:06:46 AM PST ) Permalink
Friday January 12, 2007 DCAM1394_CMD_PARAM_GET vs. DCAM1394_CMD_REG_READ
The Solaris dcam1394 driver allows access to an IIDC camera's control command registers (which I will abbreviate as IIDC registers) through two different methods.
One method is through the DCAM1394_CMD_PARAM_GET and DCAM1394_CMD_PARAM_SET ioctls (which I will abbreviate as PARAM_GET/SET). Under this method, the ioctls provide an abstraction for the IIDC camera's parameters (as well as some driver parameters). The parameters supported by this abstraction are documented in the dcam1394 man page.
The other method is through the DCAM1394_CMD_REG_READ and DCAM1394_CMD_REG_WRITE ioctls (which I will abbreviate as REG_READ/WRITE). Under this method, each IIDC register is individually accessed by the application. This requires detailed knowledge of the IIDC register set.
How do you use these ioctls?
For PARAM_GET/SET, refer to the blog that I wrote last year on the topic.
For REG_READ/WRITE, the application passes the IIDC register's offset (and, if writing, the value to write) to the driver through the ioctl. This is what code that does this might look like:
/* dcamctl_fd is the file descriptor from opening /dev/dcamctl */
dcam1394_reg_io_t cam_reg;
cam_reg.offs = 0x100; /* inquiry register for video format */
if (ioctl(dcamctl_fd, DCAM1394_CMD_REG_READ, &cam_reg) == -1) {
perror("reading the video format inquiry register failed");
}
printf("video formats supported:\n");
if (cam_reg.val & 0x01)
printf("vga uncompressed format\n");
if (cam_reg.val & 0x02)
printf("svga uncompressed 1 format\n");
if (cam_reg.val & 0x04)
printf("svga uncompressed 2 format\n");
if (cam_reg.val & 0x40)
printf("still image format\n");
if (cam_reg.val & 0x80)
printf("scalable image size format\n");
Why would you want to choose one over the other?
The obvious reason to choose the PARAM_GET/SET ioctls is that their use is documented in one place. The ioctls and the complete set of parameters that one can access through them are described in the dcam1394(7d) man page. Another reason is that, if the application needs to access a large number of parameters, PARAM_GET/SET are much more efficient interfaces.
The reasons not to choose PARAM_GET/SET are also the reasons to choose REG_READ/WRITE instead. For starters, the parameters that are available through PARAM_GET/SET were determined based on the first version of the IIDC spec (1.04). Additional parameters have been added to newer versions of the IIDC spec. Those parameters are not available through PARAM_GET/SET and are available through REG_READ/WRITE. Also, the PARAM_GET/SET interfaces have a lot of overhead when used to access a single parameter. On the other hand, the REG_READ/WRITE interfaces are very simple to use to access a single parameter.
The disadvantage of REG_READ/WRITE is that they require familiarity with the IIDC register set. The IIDC specifications are available from the 1394 Trade Association. Alternately, a simple Google search can be used to find a copy of the specification. Yet another alternative is the device specification from the manufacturer of the camera that you have (such as the manual for the Sony XCD-910 line of cameras).
While the big advantage of REG_READ/WRITE is that they can be used to handle devices that were implemented to newer versions of the IIDC spec (or to handle vendor-specific features), this is not sufficient for controlling all IIDC cameras.
The dcam1394 driver does not read the configuration ROM to determine the base address for the IIDC registers. Instead, it uses the base address that is used by most of the IIDC cameras on the market. Unfortunately, an example of a camera that uses a different base address is the most common, consumer-grade IIDC camera on the market, the Apple iSight (though Apple seems to be phasing it out, hence no link here). Also, the Solaris device discovery mechanism (/etc/driver_aliases) has only been set-up to attach the dcam1394 driver with a camera that claim to be a IIDC 1.04 device. To have Solaris attach the dcam1394 driver to cameras that claim to implement a newer version of the IIDC spec, the driver_aliases file needs to be updated so that there is an entry with spec_id and sw_version_id values that correspond to the version that the camera claims to support. Fortunately, the IIDC specs are backwards compatible.
Note that an application cannot completely depend on one of these sets of interfaces to control an IIDC camera. For example, the DCAM1394_CMD_FRAME_RCV_START and DCAM1394_CMD_FRAME_RCV_STOP ioctls (used to start and stop isochronous data transfers) require synchronization between the internal state of the dcam1394 driver with accessing the IIDC registers, so these accesses are done automatically. Also, some of the parameters that are accessed through PARAM_GET/SET are driver parameters, not IIDC parameters, so have to be accessed through PARAM_GET/SET.
I think that's it.
( Jan 12 2007, 02:12:21 AM PST ) Permalink
Friday December 29, 2006 So, I have this problem when I start writing a blog entry with any substance to it. When I start writing the blog, I am usually very exciting to write about the topic and let the world know what is going on in Solaris with Firewire. In response to my blogs, folks who are trying to use the stuff contact me directly and getting that feedback (good and bad) helps focus me on what needs to be done.
The problem is around the time I get halfway done with the blog entry, I am so bored with the topic that I look at what I have written and think "who is going to want to read this junk?" and set the blog entry aside. My "Drafts" folder on the blog tool is full of unfinished entries.
So, I am gonna trying really hard to blog more in the upcoming year. I have a backlog of interesting 1394 topics. For example, my realization that using DCAM1394_CMD_REG_READ/DCAM1394_CMD_REG_WRITE is better than DCAM1394_CMD_PARAM_GET/DCAM1394_CMD_PARAM_SET for doing IIDC device control and interesting things that you can do with the hci1394 using unsupported IOCTLs (isn't opensource wonderful?). I have also been working on new stuff like trying to make a set-top box out of a Mac Mini. I also have some 1394-based audio mixers. Would anyone like me to make them work with Solaris?
Let me know what Solaris Firewire topics that you want to hear about.
( Dec 29 2006, 07:26:06 PM PST ) Permalink
Tuesday September 05, 2006 Back in January, I had big plans to do regular, technical blogs about IEEE 1394 in Solaris. This started off with plans for a series of blogs describing the Solaris API for accessing 1394-based web- and industrial-cameras (IIDC devices) through the dcam1394 driver. Unfortunately, as I was writing part 2 in that series, I discovered an apparent bug in the dcam1394 driver that affected the sample code that I intended to use to illustrate the APIs.
I had to determine the root cause and then fix that bug. However, while in the middle of doing that, some higher priority work came up and then some other stuff even more important stuff came up and then some stuff even more important than that came up.
Now, those other things are now mostly cleared out of the way and, while I still haven't fixed that dcam bug, now I can get back to blogging about 1394. Not only that, but I have had to get a better understanding of some areas of the Solaris 1394 support that I didn't understand as well as I should have in January, so the technical content of my blogs should be better.
So, in a couple of days, look for a write-up on how to use DCAM1394_CMD_REG_READ and DCAM1394_CMD_REG_WRITE to get more from your industrial camera than you can with DCAM1394_CMD_PARAM_GET and DCAM1394_CMD_PARAM_SET.
( Sep 05 2006, 12:45:00 AM PDT ) Permalink
Monday September 04, 2006 Seattle OpenSolaris User Group forming
To coincide with the Seattle Sun Tech Days (including the OpenSolaris Day), we are starting the Seattle OpenSolaris User Group and I volunteered to lead the group. Despite its name, the group is intended to provide assistance and comraderie for OpenSolaris users throughout the entire Puget Sound region. (Hopefully, at some point, we will get enough users throughout the Puget Sound region that we will need to break up the User Group into smaller regions, but we aren't there yet).
The web site for the User Group is at http://www.opensolaris.org/os/community/os_user_groups/seosug/.
The first meeting of the Seattle OpenSolaris User Group will be the last session of the OpenSolaris Day. That happens this Wednesday afternoon. If you just can't wait until then to join up, you can sign up for the User Group's mailing list.
Look forward to seeing you (well, seeing those of you who come to the meeting!)
( Sep 04 2006, 06:25:00 PM PDT ) Permalink
Tuesday January 17, 2006 Part 2 of the Writing 1394 Digital Camera Apps is coming
Just wanted to note that part 2 of my blog on Writing Solaris apps for 1394-based Digital Cameras is coming, though a little later than intended. It will explain how to set up the isochronous end of things and how to read video frames from the camera. There will also be a part 3 where I explain the interface for directly accessing the camera's registers.
In the process of writing the blog, I discovered that some sample code that I had been handing out for the last nine months is wrong and I need to correct it. Then I have to check my blog against it. Then I can post the blog.
But it is coming!
( Jan 17 2006, 10:18:00 AM PST ) Permalink
Saturday January 14, 2006 Watch Arrested Development on Feb 10
A two-hour long season finale (yes, Fox is called it a season finale, not a series finale) for Arrested Development will air on your local FOX affiliate on Friday, February 10th, starting at 8pm ET/PT. It will not interfere with you watching Battlestar Galactica.
The last four episodes shot will make up the finale. Part of the storyline concerns Michael Bluth (played by Jason Bateman) discovering that he has a long-lost sister (played by Justine Bateman, Jason's real-life sister).
After this, the future of Arrested Development is not known.
( Jan 14 2006, 11:20:00 PM PST ) Permalink
Wednesday January 11, 2006 Writing Solaris apps for 1394-based digital cameras
Since Solaris Express 8/05, support for 1394-based digital cameras (also referred to as IIDC cameras) has been available in Solaris for SPARC and x86/x64. This support includes a public software interface to allow applications that use these cameras to be developed.
Actually, this support has been available on SPARC for some time. However, it was intended as part of a Sun video package that used a particular piece of hardware that is no longer available. Also, the software interface to that driver was not a public interface.
These cameras generally fall into one of two categories. At the low end are inexpensive web-cam devices, such as the (now defunct) Orange Micro iBot and the Apple iSight. At the high end are industrial cameras, such as devices from PixelLINK and Sony. These cameras implement the 1394-based Digital Camera Specification (later called the IIDC specification) from the 1394 Trade Association.
The driver in Solaris that deals with this class of devices is dcam1394 (referred to as dcam in this discussion). It currently supports the 1.04 version of the IIDC specification. Work is underway to enhance it to support the latest version of the specification. Unfortunately, the Apple iSight camera will not work with Solaris until this work has been completed.
When a dcam device is connected to the 1394 bus on a system running Solaris, there are two device files created for each instance of the device. /dev/dcamctlinstance is used to control the camera (the control device) and /dev/dcaminstance is used to read video frames from the camera (the streaming device).
Control of the camera is done through IOCTLs sent to the control device file. The ioctls and the data strutures that are passed to them are listed in the header file sys/dcam/dcam1394_io.h and you should include this file in your application.
There are three different types of control operations - simple camera operations, accessing camera registers directly and setting and querying camera parameters.
Most of the simple camera operations are involved with reading video frames from the camera, so I will defer that topic to the discussion of the streaming device. Also, directly accessing camera registers is not the preferred method of camera control, so I will defer discussion as well.
Setting and querying camera parameters is done in a manner that is a little awkward for accessing one parameter at a time, but very handy for accessing several at once. You allocate a parameter list, enable the parameters that you care about, assign new values to parameters (if setting values), pass the parameter list to the driver through an IOCTL and access the values read from the camera (if getting values).
What does this look like in C code? This is how you would read a parameter.
/* dcamctl_fd is the file descriptor from opening /dev/dcamctl */
int current_video_mode; /* video mode from camera */
dcam1394_param_list_t param_list;
PARAM_LIST_INIT(param_list);
PARAM_LIST_ADD(DCAM1394_PARAM_VID_MODE, DCAM1394_SUBPARAM_NONE);
if (ioctl(dcamctl_fd, DCAM1394_CMD_PARAM_GET, param_list) == -1)
fprintf(stderr, "cannot get video mode\n")
current_video_mode = PARAM_VAL(param_list, DCAM1394_PARAM_VIDEO_MODE,
DCAM1394_SUBPARAM_NONE);
This is how you would set a parameter:
/* dcamctl_fd is the file descriptor from opening /dev/dcamctl */
int new_video_mode = 1; /* new video mode for the camera */
dcam1394_param_list_t param_list;
PARAM_LIST_INIT(param_list);
PARAM_LIST_ADD(DCAM1394_PARAM_VID_MODE, DCAM1394_SUBPARAM_NONE);
PARAM_VAL(param_list, DCAM1394_PARAM_VIDEO_MODE, DCAM1394_SUBPARAM_NONE) =
new_video_mode;
if (ioctl(dcamctl_fd, DCAM1394_CMD_PARAM_SET, param_list) == -1)
fprintf(stderr, "cannot set video mode\n")
This is how you would set multiple parameters at once:
/* dcamctl_fd is the file descriptor from opening /dev/dcamctl */
int new_video_mode = 1; /* new video mode for the camera */
int new_frame_rate = 2; /* new frame rate for the camera */
int new_exposure = 128; /* new exposure value for the camera */
dcam1394_param_list_t param_list;
PARAM_LIST_INIT(param_list);
PARAM_LIST_ADD(DCAM1394_PARAM_VID_MODE, DCAM1394_SUBPARAM_NONE);
PARAM_LIST_ADD(DCAM1394_PARAM_FRAME_RATE, DCAM1394_SUBPARAM_NONE);
PARAM_LIST_ADD(DCAM1394_PARAM_EXPOSURE, DCAM1394_SUBPARAM_VALUE);
PARAM_VAL(param_list, DCAM1394_PARAM_VIDEO_MODE, DCAM1394_SUBPARAM_NONE) =
new_video_mode;
PARAM_VAL(param_list, DCAM1394_PARAM_FRAME_RATE, DCAM1394_SUBPARAM_NONE) =
new_frame_rate;
PARAM_VAL(param_list, DCAM1394_PARAM_EXPOSURE, DCAM1394_SUBPARAM_VALUE) =
new_exposure;
if (ioctl(dcamctl_fd, DCAM1394_CMD_PARAM_SET, param_list) == -1)
fprintf(stderr, "cannot set video mode\n")
For a list of parameters that you can access, refer to the dcam1394_io.h header file or the dcam1394(7D) man page as well as the IIDC specification or the documentation for your camera.
In a few days, I will describe how to read video frames from the camera.
( Jan 11 2006, 09:35:00 PM PST ) Permalink Comments [3]
Monday January 09, 2006 Yeah, I know, I should be posting something about Firewire. I have a nice dcam1394 piece in the works, but customers might to try to use the info presented in it to do something useful, so I want to make sure that it is correct. This rally stuff, on the other hand, is less critical to get right.
So, what does it cost to run a rally?
Well, first you need to have a rally car. You can build, buy or rent one. My rally car cost me $4000, which is about as inexpensive as you can get a sorted out rally car for. The bare minimum to build and equip a rally car (if you can't weld up a roll cage yourself) is around $8k. A quick scan of Ben's Rally Classifieds shows that you can get a very fast Group 2 Golf for around $11k. You can get the car that won the Rally America national championship for around $50k. You can rent an Evo VII (with service) for a weekend for around $20k.
Please note that the rally car needs to have liability insurance because it is driven on public roads between the stages.
OK, so you have the car. Now you have to get it to the rally. You need a tow rig and trailer. Single car, open trailers are preferred because you might have to drive it up some gravel road to retrieve your broken rally car. As with the rally car, the options here vary too much to try and put a general price on it. Budget a few thousand more for this (or find a friend that you can borrow a truck and trailer from).
After you have your rally car on the trailer and the trailer attached to the truck, you have to fuel up the truck. A truck hauling a loaded trailer gets less than 10 miles per gallon. Also, if your tow rig is also your service rig, the truck needs to be driven to all of the service areas during the rally. The costs will depend on how far you have to tow to get to the rally.
You get to the rally and now you need to pay the event entry fee. Those fees run between $300 and $1200. You also need to have a competition license. Those costs are described in my previous blog.
You also need to find somewhere to stay. Rally registration and technical inspection of the rally car (called scrutineering) usually happen the day before the running of the rally. For a two-day rally, you need two nights at a motel. The Ramada Express Rally has 2 days of recce and 3 days of rally. That is 5 nights of motel for the driver, co-driver and service crew.
Service crew? Yes, you should have one or two guys to help work on the car during the service breaks while running the rally. Luckily, you usually just need to feed them and pay for their accomodations. And don't forget to stock the service rig with food and drinks for the whole gang during the rally. You don't want your co-driver wigging out on stage because he hasn't had anything to drink all day.
So, you have your rally car. You have gotten it and your co-driver and you service crew to the rally and found them a place to stay. You have gotten through rally registration and scrutineering. You are now ready to run the event.
If you keep the car on the road, the only costs that you have are wear-and-tear and consumables. The consumables in a rally car are primarily fuel and tires. In a low horsepower rally car, these costs will be low. A set of tires might last all season and a tank of regular unleaded might last the entire rally. However, in a high power, all wheel drive rally car, you could go through a 55 gallon drum of race fuel (at $6/gallon) in a weekend and a set of tires (at $600/set) in less than that. Also, as tough as rally tires are, they can get punctures and have to be replaced.
I don't even want to start getting into what the costs could be if you make a mistake and crash your car.
Is it becoming clear why I became a co-driver and why I sold my rally car ...
( Jan 09 2006, 10:00:00 AM PST ) Permalink Comments [3]
Sunday January 08, 2006 Rally Costs: A Co-driver's Perspective
I have been asked what does it cost to go rallying. Even though I have owned a rally car and have been constantly reminded about the costs of rallying by some drivers, what I know best is the costs for co-drivers.
Your primary upfront costs will involve personal equipment. While some teams provide some equipment (like a driving suit so that the crew will have a common look), usually you have to purchase your own.
The minimum set of personal equipment that you need are:
- driving suit. You need a driving suit that meet FIA standard 8856-2000 or SFI 3-2a/5. FIA 1986 Standard suits are still accepted by Rally America and seem to be accepted by NASA, though their rulebook states otherwise. Karting suits are not allowed. An inexpensive driving suit will run about $500 and a top-of-the-line suit is a bit over $1000. Used driving suits are also available.
- helmet. You need a helmet that meets one of three standards. With one notable exception, most helmets used in rally are Snell-rated. You need a SA-2000 or newer helmet. You can also run a SA-95 helmet through this year. Helmets can be open face or full face. Open face helmets are more common in rally for a variety of reasons. Get an open face helmet if you get car sick. Helmets can had for around $400.
A company named Peltor makes helmets specifically designed for rally with integrated intercom headsets (Peltor also makes intercom systems). Their helmets cost about $500.
- intercom headset. There are a number of intercom system manufacturers, but most intercoms used in rally are either Peltor or Terraphone. If the intercom system is something else, the team should provide you with a headset to install in your helmet. Terraphone intercoms are not as well built as Peltor, but are less expensive. You should probably carry a spare headset, because they do fail. Headsets run about $100 new and can be found used. Peltor-to-Terraphone adapters run about $50 (most of the cost is the Peltor plug!).
Optional personal equipment includes nomex underwear, racing shoes, head-and-neck restraint devices (such as the HANS device) and arm restraints. Co-drivers generally do not wear driving gloves (it is hard to turn the pages of the route book with gloves on). They often do not wear driving shoes, opting for something like hiking boots instead (better when you get stuck on stage and have to push the car out of a ditch). Also, most rallies are two-day events (and some are three-day events), so you probably want to have an extra pair of nomex socks, for example.
One more upfront cost is licenses and memberships. To compete in Rally America events, you pay $115 for the license plus $25 if you want to be scored in a Regional Championship and $95 if you want to be scored in the National Championship. To compete in NASA events, you pay $40 to join NASA and a competition license for $50. To compete in USAC rallies, you pay another $100 for a USAC license.
Those are the upfront costs. What about the ongoing costs?
There is little agreement on what the co-driver ongoing costs should be. Some drivers view co-drivers as partners, including sharing all expenses. Other drivers view co-drivers as necessary volunteers, like service crew, and pick up all costs and cover the co-driver's expenses. Some drivers view co-drivers as the primary funding source for their rallying effort.
When I first started rallying, I was in a partnership arrangement with a driver, Ross Foster. I would spend a lot of time at his place helping to build the car. When we started running rallies, we would swap who paid for what. This included things like entry fees, accomodations and food. He always covered towing costs and vehicle expenses (however, my road car was the same model as the rally, so parts were sometimes borrowed from my car). His parents and friends did service.
Ross slowly dropped out of rally and I started working with other drivers. Since then I have experienced almost everything from "pay for everything" to "pay for nothing".
Now that I am an experienced co-driver with a proven record, my normal financial terms are that I will pick up my costs, which include transportation to and from the rally, accomodations and stage note costs. Obviously, transportation and accomodations will vary. Stage notes run about $175. If the driver wants to pick up these costs, I don't insist on paying them myself. With certain drivers, I am willing to pay additional sponsorship money in exchange for putting some advertizing on the car.
Next, I will outline the costs involved in running a rally.
( Jan 08 2006, 12:00:00 AM PST ) Permalink Comments [1]
Tuesday January 03, 2006 Worry About Hurting Yourself Or Hurting The Car
Dmitri Trembovetski commented on one of my recent blogs, asking, when competing and a rally driver lifts, is he more worried about hurting himself (or the co-driver) or hurting the car.
As you might imagine, it all depends on the driver and the circumstances. Since I started rallying in 2001, I have co-driven for about 20 different drivers. However, the drivers that I have worked with have mostly been with fast, experienced drivers, so my experience is a little skewed.
Generally, the drivers that I have worked with push as hard as they think they can. There isn't any thought of either hurting yourself or hurting the car (let alone the co-driver!). When they lift, it is because they think if they don't lift, then will be going too fast to go around the next turn.
While rally competitors generally acknowledge the inherent risks in what they do (and accidents like the ones that killed Michael Park and Mark Lovell and Roger Freeman remind us of those risks), we all all take steps to reduce those risks. We are all in the car inside a strong roll cage, wearing helmets and fire-resistant suits, strapped in our seats. Some people wear arm restraints or head-and-neck restraints or sit in head-restraint seats. It is much safer than being in a normal car involved in an accident on the road, even if you are more likely to be in an accident.
Actually, a driver who is concerned about hurting himself or the car while rallying probably shouldn't be rallying. There are more important things to worry about (like staying focused on the road) and worrying about these things should help keep you from getting hurt.
So, what about the drivers who have lifted because they were worried about hurting themselves or the car?
As far as hurting themselves, there are types of situations where I have seen drivers concerned about hurting themselves. One is when they are new to the sport, don't yet focus on driving and see or feel something that scares them. This could be a big cliffs that they could drive off (called exposure in rally-talk) or the car slides on the gravel more than expected. This usually goes away as the driver gets more experienced. The other is when the driver comes across something totally unexpected and dangerous. This could be a turn that the co-driver did not call correctly (you come over a crest and the road makes a sharp right instead of continuing straight), an error in the route book or stage notes (same as above) or, say, non-rally traffic that managed to find its way onto the road and does not realize that the road is closed for a race. These are usually just concerns of the moment, unless they keep happening repeatedly (at which point, the driver rightfully loses faith in his co-driver, the route book or the rally officials).
As far as hurting the car, one unfortunate fact about most any kind of racing is that you have to be prepared to possibly have to throw the car away. Stuff happens and cars get wrecked. Sometimes folks overextend themselves to go rallying and know that they can't afford to make repairs. Sometimes they don't realize the ongoing costs of rallying until after they have to pay for repairs after a big off. When they figure out that they can't afford to pay (or don't want to pay) for hurting the car, they drive more carefully. Sometimes they forget about it. Sometimes they get even more concerned about hurting the car. The thing about rally is that even driving a clean rally, cars get hurt, so if you can't afford to pay (or don't want to pay) to fix your car, you probably should not be out there. I sold my rally car and bought a vintage road race car because rally cars generally go down in value and vintage race cars generally go up in value.
My whining about what happened at the Ramada Express Rally was more a matter of my expectations not being met with regards to experience that I would gain and exposure for my sponsor compared to my contribution of time and money to the effort.
Dmitri asked how the finances work in another blog comment. That ties nicely into this, so I'll describe that in a future blog.
( Jan 03 2006, 06:50:00 PM PST ) Permalink Comments [4]
Monday January 02, 2006 Winning A Championship in the Worst Possible Way
I won the California Rally Series Open 4WD Co-driver championship. I beat SoCal-based John Dillon, 1230 to 1092. I had a 200 point lead going into the last rally, the Ramada Express International Rally, so we just had to finish. And that's what we did - just finish.
The title of this blog is a bit of an exaggeration. I can imagine many ways in which it could have come out worse. It was still pretty bad.
I was co-driving for Doug Chernis, who has been my regular ride all season, in his Group N Subaru WRX.
Doug and I have been working together since his first rally last year. We started this season with an overall win at the Seed 9 Rally and a moral win (we won six of eight stages and had no brakes on two of the stages). Then we rolled the car at the Rim of the World Rally in May and missed the Treeline and Gorman rallies while the car was being repaired. We were back for the Prescott Rally in October, but Doug was driving with the throttle pedal connected to his wallet, that is, very slow and cautious.
Leading up to Ramada, Doug was talking about being comfortable in the car again and driving at a competitive pace. Unfortunately, this isn't what happened. He was backing off on the straights and not putting in competitive times. However, he was showing signs of getting more comfortable.
At the start of the second day, Doug seemed to be getting even more comfortable and put in a respectable time on the first stage. Unfortunately, on the second stage, I made a bad mistake in calling a turn and we had an minor off-course excursion that could have been really bad. We were lucky to get away with a puncture. However, that was the end of the rally for us as far as putting in competitive stage times.
The near-off stuck in Doug's head for the rest of the day and he drove so slowly. We were slower than last year by minutes and this was his second rally ever then. The last stages were run after the sun went down. The wind went away with the sun and heavy dust hung over the stage. This made us even slower. The only car slower than us on the last stage suffered a headlight failure and was lead out by a sweep vehicle. We were slower than a car that had to stop after it had struck a deer.
I could understand that Doug had a lot of money invested in the car and didn't want to damage it. However, it is a competition car and he chose to entry it in the rally and cars get damaged in rally. (That is one of the reasons that I sold my rally car and bought a vintage Formula Ford.)
Also, he asked me to make a substantial financial contribution to the team and I think that I was owed a better effort as a result. I could have taken that money and paid for entry fee, notes, hotel and recce vehicle rental for someone else who would have made an effort to the end.
Whine, whine, whine. At least, I won my championship.
( Jan 02 2006, 12:54:00 PM PST ) Permalink Comments [2]
