How to Build a Simple Software Log for Pulling Data

A pulling season produces far more information than a final distance or winning time. A team may record tyre pressure, ballast position, engine temperature, turbo settings, track conditions, hitch height, fuel use, weather, and repairs at every meeting. Without a reliable system, those details end up scattered across notebooks, phone photos, messaging apps, and memory.

A simple software log brings those records into one searchable place. It does not need to be an expensive race-engineering platform. A well-designed spreadsheet, form, or lightweight database can show what changed between runs and help a team make better decisions before the next hook.

The best system is quick enough to use in the pits. If entering a result takes ten minutes while the tractor is being unloaded or the truck is being checked, the log will soon become incomplete. The goal is a practical record that captures the important facts without interrupting the work of a pull day.

Australian teams can adapt the same approach to local conditions, from a dry Saturday at Dubbo to a humid Queensland meeting or a long tow between regional venues. Keeping distances in metres, temperatures in Celsius, pressures in kPa, and dates in day-month-year format prevents confusion when data is shared between crew members.

Choose the information worth recording

Begin with the purpose of the log rather than the software. A driver may want to compare launch performance, while a crew chief may be more interested in wheel speed, boost, or clutch adjustment. An organiser may need a separate record for registration, class, draw order, officials, and verified results. These uses should influence the fields you create.

A useful event record normally includes the meeting name, venue, date, class, vehicle, driver, track lane, placing, distance, and result status. Add a field for the type of run, such as qualifying, exhibition, competition, or test pass. For association-style events, it is also helpful to record the class rules or technical category that applied on the day. The OTTPA resources provide a useful example of the kind of event, registration, result, and notice information a pulling organisation may need to keep accessible.

A run record should then capture the conditions surrounding that attempt. Useful fields include track surface, moisture, air temperature, wind, humidity, tyre pressure, ballast arrangement, hitch setting, engine rpm, boost, wheel speed, distance, and driver comments. Do not create fields simply because a data logger can measure them. If nobody reviews a value or uses it to make a decision, it may add clutter without adding insight.

Keep descriptive fields consistent. Use “hard dry,” “soft damp,” and “freshly watered” instead of allowing every crew member to enter a different phrase. Create dropdown options for class, vehicle, track condition, and run type. Free-text notes still matter, especially for unusual failures, but controlled entries make later filtering much easier.

Select a tool that works in the pits

For many teams, a spreadsheet is the right starting point. Microsoft Excel and Google Sheets are familiar, inexpensive, and flexible enough for a season of results. A shared Google Sheet can be updated from a phone at the track, while Excel may be preferable when a team works offline or already uses a laptop for engine data. Both can support formulas, filters, charts, and separate tabs for events, runs, servicing, and parts.

A mobile form linked to a spreadsheet can make data entry faster. The person recording the run taps the vehicle, enters the distance, selects the track condition, and adds a short note. Forms reduce accidental changes to the main table and provide a consistent timestamp. They are particularly useful when several people record data during a busy meeting and the crew does not want to hand around a laptop.

A small database becomes worthwhile when a team has several vehicles, multiple drivers, or years of historical records. It can connect a vehicle table to an event table, then link every run to a particular setup. That structure avoids typing the same sponsor name, engine combination, or class repeatedly. However, a database should solve a real problem rather than create a technical project. A clean spreadsheet is usually better than a complicated system that nobody maintains.

Australian connectivity can affect the choice. A meeting outside Toowoomba, Bendigo, or Perth may have unreliable mobile coverage, so the log should work offline and synchronise later. Keep an exported copy on the phone or laptop, and avoid making cloud access the only way to see setup notes. Use the same time zone and date convention across devices, particularly when data is collected by people travelling between states.

Build a clear record structure

Separate the log into related areas instead of putting every fact into one enormous row. An events sheet can hold one row per meeting. A vehicles sheet can store the vehicle name, class, engine, tyre size, gearing, and current owner. A runs sheet can contain the individual attempts. A maintenance sheet can record parts fitted, service dates, operating hours, and faults. This arrangement keeps repeated information under control.

Every run should have a unique identifier, such as “2025-08-16-DUB-TRK-03.” The code does not need to be complicated. It only needs to distinguish one attempt from another and make it easy to connect measurements, video, and comments. If a data logger creates its own file name, place that file name in the run record so the raw data can be found later.

Use a simple status field to distinguish confirmed data from estimates. A measured distance from official results is different from a crew member’s visual estimate. Similarly, an engine temperature taken from a calibrated sensor should not be confused with a value read from a gauge after the pass. Labels such as “official,” “measured,” “estimated,” and “not recorded” preserve the context behind each number.

Keep units fixed throughout the system. Use metres for distance, kilometres per hour for speed, kPa for pressure, degrees Celsius for temperature, and litres for fuel. Do not mix psi and kPa in different event rows. If a US-supplied component or data logger displays imperial units, convert the value before entering it or add a dedicated conversion field. Consistent units make charts and comparisons much more trustworthy.

Add validation rules to prevent obvious errors. A result distance should not be negative, an air temperature should sit within a sensible range, and a date should be a real date rather than text. If a field is not applicable, use “N/A” instead of leaving uncertainty about whether the crew forgot it. These small controls protect the value of the log without making the form burdensome.

Turn notes into useful comparisons

A log becomes valuable when it helps explain why one run worked better than another. Start with straightforward comparisons: average distance by track condition, best result by tyre pressure, failure rate by event type, or placing by vehicle setup. Avoid drawing strong conclusions from a single pass. A soft track, a missed gear, or a mechanical issue can distort the result.

Create a summary page with a few practical indicators. A team might track best distance, average distance, number of completed runs, number of mechanical stoppages, average engine temperature, and finishing position. Use filters for vehicle, class, driver, and season. A chart showing distance against track moisture may reveal a useful pattern that is difficult to spot in a long list of rows.

Record setup changes explicitly. If ballast was moved 200 millimetres rearward, tyre pressure changed from 110 to 105 kPa, or the hitch was raised by 5 mm, write the old and new values. A vague note such as “changed setup” has little value six months later. It is equally important to record changes that had no clear benefit, because that prevents the crew from repeating an unproductive experiment.

Video can add context to numerical data. Store a short clip or a file reference against the run ID, then note whether the vehicle spun, bounced, drifted, or lost power. A result may look poor in the table, while the video shows that the launch was strong and the problem occurred only near the end of the track. The combination of measured data and observation supports better tuning decisions.

Prize and payout information can be tracked separately from performance data. If a club records jackpot events, bonuses, or sponsor-funded awards, it should include the meeting, eligibility condition, amount, recipient, and payment status. A separate record prevents financial details from being confused with sporting results; background material such as jackpot event details can also be kept as a reference when organising event notes.

Protect the record and make it part of routine

Backups are essential because a season’s data can disappear through a damaged phone, a corrupted file, or an accidental deletion. Keep the working copy in a cloud service when practical, export a dated spreadsheet after each meeting, and retain the original data logger files. A simple naming system such as “PullLog_2025-08-16_Dubbo” makes old versions easy to identify.

Limit editing access to the people who need it. The person entering official results should not have to sort through tuning experiments, and a volunteer adding photographs should not be able to overwrite verified distances. Protect formula cells and use separate views for drivers, officials, and the workshop. If several people share a device, sign out of personal accounts after the event.

Make the log part of the normal post-run routine. One crew member can enter the basic result immediately, while another adds setup and mechanical notes during inspection. Before leaving the venue, check that every run has a result, the vehicle status is marked, and any failure has an associated maintenance task. This is easier than trying to reconstruct the day from memory on Monday.

Review the system after several meetings. Remove fields that are consistently ignored, combine duplicate fields, and add one only when a real decision depends on it. A practical build guide such as software build notes may offer ideas for organising a basic tool, but the final structure should reflect the team’s workflow, equipment, and level of technical confidence.

A useful log should also support safety and compliance. Record inspection outcomes, required protective equipment, fire-system checks, noise or technical concerns, and any official instruction that affects the vehicle. These entries should never replace the event’s formal rules or officials, but they help a team prepare consistently for the next meeting. Australian organisers may also need to track club paperwork, insurance documents, permits, and interstate travel details alongside the competition record.

Start with a spreadsheet containing event, vehicle, run, setup, maintenance, and result fields. Enter the last two or three meetings while the details are still available, then test whether the system can answer practical questions about performance and reliability. Once the structure proves useful, add a mobile form, charts, or automated calculations. Visit OTTPA.net for event-style information and pulling updates, then build a record that gives your own crew a clearer view of every run, every adjustment, and every result.