PitWall Devlog 7

New functions:

DRS Effect Analyzer

get_drs_effect checks where drs was used in a lap basically when the rear wing was open (drs zones) and calculates the speed gain within each one, entry speed vs peak

Lap Time Delta Chart

get_lap_delta compares two drivers’ laps by interpolating both onto the same distance grid using then subtracts one from the other at every point to get a time gap across the lap.

Driver & Constructor Standings

get_driver_standings and get_constructor_standings basically show the total points accumulated per team and per driver after a certain race

A small issue

• the drs effect function doesn’t work for this year’s races because of the regulation changes and there isn’t exactly drs now but active aero but works for other years

PitWall Devlog 6 - Championship Battle, Overtakes, and Track Evolution

What I built

Championship Battle Tracker

get_championship_battle tracks points for a list of drivers during a season round by round and adds up the points also, tries to load a Sprint session for the same race if it exists it adds those points too, if not it just moves on since most weekends don’t have one. chart_championship_battle is the chart that shows it and it uses the team colors like the other charts and makes the line dashed if there are teammates

Overtake Analyzer

get_overtakes looks at every position swap between consecutive laps , for each pair of laps it takes everyone’s position and checks every pair of drivers to see if their order flipped, also i had to exclude inlaps and outlaps since when you pit usually you drop many positions get_overtake_summary is just a counter for the overtakes chart_overtakes shows it

Track Evolution

get_track_evolution looks at how the track itself gets faster as a session goes on, takes every driver’s laps together, sorts them by LapStartTime then tracks a running best lap and an average pace over a window chart_track_evolution visualises it

Problems I hit

• i forgot to exclude inlaps basically the first lap out of the box when you warm the tires for the track_evolution function

PitWall Devlog 5 Weather, Degradation, and Historical Performance

What I built

Weather Performance

get_weather compares average qualifying position for a list of drivers across wet sessions vs. dry sessions and calculates a wet_advantage which is basically just dry avg minus wet avg so a positive number means someone performs better in the rain rather than in the dry. chart_weather visualises it

Tire Degradation

get_tire_degradation takes each stint and calculates lap-time loss per lap of tyre age. The laps are first filtered so that there are no inaccurate laps and that means excluding laps where there was a red flag, yellow/double yellows, exclude inlaps and outlaps and also if there was a safety car/vsc and also TyreLife > 2 to exclude also the first 2 laps of the stint where in general you have to nurse the tires to warm them up. chart_tire_degradation just visualises it.

Teammate Gap

get_teammate_gap compares best qualifying times between two teammates across a season. Because not every driver reaches Q3, it falls back Q3 - Q2 - Q1 to find each driver’s actual best time for that quali session. chart_teammate_gap visualises it, red or cyan depending on who was faster.

Historical Performance

get_fastest_lap_history finds the fastest lap from every quali session since 2018 as that’s how far the data goes. get_driver_circuit_stats does the same thing but for a driver, pulling qualifying position, race position, fastest lap, and finishing result for each year at a given circuit.

Sector Times and Pit Stops

get_sector_improvement breaks a driver’s sector times down by stint and tyre age, using the same filtering to exclude some laps as the degradation function, get_pitstop_performance calculates stop duration by matching a driver’s pit-in lap to their next pit-out lap, discarding anything under 15s or over 60s since those aren’t really representative.

Career Head-to-Head

get_h2h_career compares two drivers’ qualifying head-to-head win rate at specific circuits across multiple years, returns a win percentage per location. chart_h2h_career again visualises it.

Problems I hit

• First pass on pit stop duration had no bounds so I was getting stops showing as 3s and 140s which were basically laps flagged as pit laps during safety car periods which is a lot shorter so I added the 15–60s filter
• also in general I had issues with how tidy the charts looked for example when looking at the stints, each stint is shown with the color of the compound so yellow for medium and so on and for some races which aren’t one stoppers you often use one compound more than once so I lowered the opacity if there is a second stint on the same compound, it’s not a perfect solution but it works

PitWall Devlog 4 Circuit DNA and Qualifying Analysis

What I built

Qualifying Analysis

get_quali_improvement tracks a driver’s best lap time across Q1, Q2 and Q3 using session.results which returns the results from the three sessions. chart_quali_improvement calculates each driver’s progression between 2 sessions (Q1 and Q2 and so on)

get_perfect_lap gets its own chart chart_perfect_lap shows the perfect theoretical lap vs actual best lap where the best lap is the three fastest sectors overall per driver

Circuit DNA

It classifies a circuit based on its traits (power track, high/low df, high/low drag and so on) get_circuit_dna analyzes the fastest lap telemetry from any session and extracts 6 metrics: full throttle percentage, braking percentage, top speed, average corner speed, low speed corner percentage and high speed cornering percentage.

classify_circuit uses those metrics to label a circuit as High Speed, Power Track, High Downforce, Stop/Go or Balanced. Tested across a few circuits as well

chart_circuit_dna shows a radar chart overlaying multiple circuits so you can visually compare their personalities

get_team_circuit_affinity and get_driver_circuit_affinity calculate average qualifying positions per team and driver based on circuit type

Results

• Silverstone: High Speed — 65% full throttle, 162 km/h avg corner speed
• Monaco: High Downforce — 34% low speed corners, 27% braking
• ANT is the strongest qualifier across all circuit types in 2026
• Mercedes dominant on Balanced circuits, Ferrari strong on High Speed

Problems I hit

• FastF1 doesn’t support Q1/Q2/Q3 as separate session types so i had to use session.results which has cleaner segment times
• Circuit classifier kept misclassifying Silverstone as Power Track in the if/elif part of the code
• Team affinity chart showed each team 3 times in the legend fixed it with dict.fromkeys() to remove the duplicates

PitWall Devlog 3 — Mistake Detector

What I built

Mistake Detector it compares a driver’s telemetry lap by lap at the same point on track. FastF1 gives car data sampled every few milliseconds but the points aren’t evenly spaced by distance, so I used scipy to interpolate both laps onto a common grid every 10 meters, then subtracted one speed trace from the other to find where time was lost.

detect_mistakes finds every zone where speed dropped more than 5 km/h, calculates time lost using distance ÷ speed physics, and maps each mistake to the nearest turn number using FastF1’s circuit info.

chart_track_mistakes draws the full circuit map colored by speed using matplotlib, green for fast, red for slow and with mistake zones highlighted and labeled with turn number and time lost.

get_perfect_lap finds the best individual three sectors from all of a driver’s qualifying laps and combines them into the theoretical fastest possible lap, showing how much time they left on the table.

chart_perfect_lap visualizes this as a grouped bar chart, green for perfect lap sectors, driver’s color for actual best lap.

Results from British GP 2026 qualifying

NOR had 5 mistake zones totalling 0.77 seconds lost between his best and second best lap. Biggest mistake at Turn 18 — 22.7 km/h speed loss, 0.31 seconds gone.

Problems I hit

• Interpolation was the hardest concept to understand and implement, two laps have telemetry at different distance points so you can’t compare directly. scipy’s interp1d solved it
• Had return fig accidentally inside a for loop in chart_race_pace and only the first stint would show up
• Also needed to fix charts where you’re comparing 2 drivers from the same team because they have the same color which makes the chart unreadable

Also done this session

• Set up GitHub and pushed the code so far
• Changed the color scheme for the charts
• Fixed teammate differentiation across the charts

Building the physics core

Started an F1 lap time simulator in C++with no prior CMake experience, so the first few hours were mainly setup issues.

Once the build worked, I got into the calculations part: drag force, top speed via iterative approximation and a cornering-grip model from centripetal force. Then added tire degradation with compound-specific wear curves and a “cliff” effect, Medium tires lose ~0.012 grip/lap until lap 25, then fall off a cliff at ~0.06/lap.

Put it all together so far into a full race simulator comparing pit strategies. My one-stop vs two-stop comparison came out within 1 second of each other over a 30-lap race.

PitWall Devlog 2 — Charts and Visualization

Spent this week visualising the data itself and turning it into interactive charts.

What I built

chart_race_pace shows a driver’s lap times across the entire race with each stint colored by tire compound. Pit laps are shown as grey X markers so you can see the inlaps and outlaps.

chart_head_to_head overlays two drivers’ pace on the same chart using their official team colors pulled directly from the session data. When comparing teammates who share a color, one line becomes dashed automatically.

chart_consistency compares multiple drivers’ consistency scores as bars. A lower score means that the driver is more consistent.

chart_quali_comparison breaks down each driver’s best qualifying lap into the three sectors side by side, instantly shows where one driver gained or lost time compared to another.

chart_position_change tracks each driver’s position lap by lap through the race, starting from their actual grid position as lap 0 so position gains and losses are accurate.

Problems I hit

The position chart was showing drivers starting from the wrong position because FastF1 doesn’t always record lap 1 position data cleanly. Fixed it by pulling the grid position directly from the session info and showing it as lap 0.

The teammate color logic also had to be rethought twice before landing on a simple used_colors list approach that works cleanly.

Devlog 1!

As an f1 fan and motosports fan in general, I wanted to create something that I’m going to use myself pretty often and work with data that genuinely interests me which is why I’m creating PitWall, a website that analyses data using FastF1, an open source F1 data library. The main idea is to pull real F1 data and let people analyze race pace, quali laps, driver mistakes, simulate alternate race strategies. I’m also going to be using NASA atmospheric data to correlate weather conditions with lap time performance.

Started off by working on analyze.py which for now has 5 functions as the core of the project:

get_clean_lap which filters out sc, vsc laps, track limits and such
get_race_pace calculates the average race pace per stint
get_head_to_head combines 2 drivers’ laps into one table for comparison get_consistency_score uses standard deviation to measure the consistency
get_h2h_summary compares 2 drivers’ pace and tells which one was faster

• I’ve also started working on charts.py to set up the dark F1 color theme and pulled the official team colors from the session data.
• I tested everything in the terminal, VER vs LEC in Australia 2023 showed that Verstappen’s pace was 1.667 seconds per laps faster on average.

• This here is Hamilton and Verstappen’s race pace in Mexico, 2022:

Shipping day!

Spent the last couple of days on everything around the code, which turned out to be way more work than I expected. Setting up git properly, fixing merge conflicts, getting PyPI to accept the upload, writing a .gitignore, creating a release tag. None of this is hard individually but it’s a lot of steps and each one has its own way of going wrong.
Also fixed two real bugs I hadn’t noticed: the tool would crash on non-ASCII characters like emoji, and nothing stopped you from saving the output as a .jpg (which would silently destroy the hidden data since JPEG is lossy). Both are one-liners to fix but they matter.
The project is now on PyPI at pip install steganohide, fully open source, with a proper README and release. It actually works and anyone can try it.

Devlog 3 — the decoder!

This one took more thinking than I expected. The decoder has to follow the exact same path as the encoder: same starting corner, same row-by-row order, otherwise it reads the wrong pixels and gets messy. The trickiest part was the stop signal logic. The decoder reads Red values one by one and asks “is this a 0?” at every pixel. If yes, stop and convert everything collected so far back to text. If no, keep going. Sounds simple but getting the edge cases right (what if the image has no message at all? what if it hits the end without finding a stop?) took a few tries.
When I finally ran encode → decode end to end and saw my message come back perfectly that was a relief.

Devlog 2!

Ran into my first real problem today, the SimpleImage library I started with wasn’t giving me direct pixel access the way I needed. Switched to Pillow and it made things a lot easier. getpixel() and putpixel() are what I needed.
Writing the encoder felt satisfying. You loop through every pixel, overwrite the Red channel with your character’s ASCII value, move to the next pixel, repeat. It sounds almost too simple but it works and the encoded image looks identical to the original.
Added a safety check too: if your message is longer than the image has pixels, it’ll tell you instead of crashing silently.

First devlog!

I’ve been wanting to build something that feels like actual secret agent stuff, and steganography caught my eye, hiding messages inside images that look completely normal. Nobody would ever know.
Getting started was harder than I expected. I didn’t know how pixel data actually worked at first, I just knew images were made of pixels. Turns out every pixel has three numbers (R, G, B) and ASCII characters are also just numbers, so you can literally swap one for the other. That clicked for me and I got excited.
Built the two core helper functions today: message_to_numbers which converts text to ASCII values, and numbers_to_message which does the reverse. The stop signal (0) idea came from wondering “how does the decoder know when to stop?” you need a flag at the end, like a period at the end of a sentence.