One of several undocumented achievements this year, and probably my proudest, was this speed/tach for EA’s F1 2024. I managed to pull in the whole family to make this happen, with some amazing contributions from each member.

Work had sent me to Cisco Live in June, where there was a pretty sizable McLaren F1 presence since Cisco are one of their major sponsors. Zak Brown and Oscar Piastri were there for one of the major keynotes.

Anyway, there was a Splunk demo booth at the show floor with some racing simulators set up. I tried my hand and managed to get second place at the time (not that huge of an achievement since it was pretty early in the day. I checked back in a few hours later and the best time was several seconds faster than the one I had posted). On the sides of the booth, Splunk was demoing a plugin that tracked telemetry data streaming out from the game. It saw everything from tire temperatures to steering and throttle/braking inputs, but for the purposes of Cisco Live, it had a simple map of the Montreal track with a heatmap of speeds that players were traveling at.

The main takeaway from this was, there was some manner of data being streamed out from the game. Some further research brought me to a forum post where there was a pretty formal looking pdf file detailing the spec.

Apparently, when set to do so, the game puts out a stream of UDP packets to a port and destination of your choosing. The payload of each packet is a bunch of unstructured binary information to pick apart. This was where I enlisted my wife, who deals with data streams in her day job. I showed her the doc from EA, and she knew exactly what to do with it. At this point it was only a passing “Hey wouldn’t it be neat” sort of thing but a few hours later she came back and told me she had written a preliminary parser for the telemetry stream, and from there it was up to me to figure out what to do with that data.

I had to tweak the code a bit because I really just wanted to focus on the speed and tachometer metrics (you really get everything out of this stream, including car pitch/roll, track temperature, individual tire temperatures, etc.), but my contribution to this all was on the network side. The only way to test the code was to capture a live stream, and the only way to have a live stream was to be (ostensibly) playing the game. For the first few iterations I would have to play the game while my wife watched the printlines to the console, but I realized I could simulate this with a packet capture.

Wireshark has a replay feature where you can give it a recording of packets and it will send those back out on the network at your request. This is where things like replay attacks happen. Anyway, I recorded the UDP stream of myself driving around Suzuka, and had Wireshark replay that over multicast on the network. From there, whoever was interested could listen in and test their parser.

So, now we have some relevant data. What next? Our kid has a Circuit Playground Express that he noodles around with now and then. With the CRICKIT attachment it can control a few servos, which we would use for the gauges. The only problem was, it had no network capabilities. That was where the Feather M0 came in. It has wifi, but no CircuitPython support, which was key for having our kid involved. So, I had to configure the Feather to talk to the CircuitPlayground via a serial stream over the alligator clips.

Our kid was in charge of the servo code. His task was to write a function with two inputs, and move the servos to the right spots on the gauges. I have a huge regret here in that we did not preserve the code because we were just coding it live on the CircuitPlayground. Along the way we had a handy little test and calibration suite too. It was relatively simple, but the code was entirely his and we were all extremely proud of it. Unfortunately it was wiped when we started our next project, which I may get around to posting here.

In any case, it works! Here’s us testing it. He did a great job on that chicane too! Github repo for the project here.

He was 8 years old at the time of the video.

Uh oh.

Now that it’s almost the end of the year I reminded myself that one of my 2024 New Years Resolution was to document my accomplishments more, and this blog was supposed to be the medium. I got a few good ones at the beginning of the year but like all my New Years resolutions I fell off at around April.

Since the last post I’ve reinstalled my OS a few times, taking my home folder along with me, which for the most part has been working just fine.

…until now.

I had to reinstall Ruby to get Jekyll going again. Unfortunately what I got was the above error, along with a whole day’s worth of other errors as I fell into a edit-check-retry loop.

Eventually I came across this line in the Arch page for Ruby:

A sudo pacman -S ruby-sdlib finally cleared up the last of it. I’m actually not sure if that was what started everything in the first place but it was the end of several hours of reinstalling and updating and uninstalling Ruby and Gems and Jekyll and editing files all over the place.

When Arch says to read the manual, you really can’t skim the manual because of things like this where there’s a line that says “you could do this thing if you needed to, and chances are you do need it, but we’re going to leave it up to you.”

I’ve finally finished this project and it’s working exactly as intended. My only regret is that the two LED displays are slightly crooked. I had taken for granted that they would somehow align themselves on the circuitboard but I only realized that wasn’t the case after I had soldered the 14 pins.

It’s extremely visible and readable from across the living room.

In any case, another one in the books. It’s in Fahrenheit for now because the numbers were bigger. A single byte would cover up to 256 if I only wanted to display three-digit integers, but I wanted four digits of precision, so I went on a quest to learn how to send two bytes at a time, which turned out to be less than trivial. Send-a-byte/read-a-byte is pretty simple but sending an array of bytes required I reacquaint myself with C arrays and memcpy(). I had gotten too comfortable with Python’s list slices and completely forgotten the syntax for pointers.

Python and Arduino code for this project is here

I’m working on a CPU/GPU readout for my PC. So far it’s been a week of on-and-off soldering and handwiring and tinkering with this Arduino Nano clone, seven segment displays, and shift registers, for something one could probably find on Aliexpress for less than $10.

I mean, that’s not the point though. Neither is the coding part or the learning how electronics work, really. On paper this is pretty much a waste of time and money. I enjoy it though. It’s a great intersection between my love of technology and my love of craft. A successful solder joint gives me the same feeling as a good plane shaving. In this case though, it’s an additive process as opposed to subtractive. Instead of carving material off, you’re adding metal and silicon to your project, and you can feel the board getting physically heavier as you go along.

The handwiring bit is a carryover from my time spent building keyboards from scratch. For some reason I’ve come to enjoy working with magnet wire, thanks to my custom tool, which is actually just an Xacto knife with half the blade snapped off. I use it to carefully scrape off the enamel insulation. I find this better than working with plastic/rubber insulated wire, which tends to melt, shrink, crumble, etc. Also, the negligible thickness of the insulation means the wires take up way less space, so I can cross wires over a lot more before having to resort to creative wire routing.

Mostly, the shiny red wire is pretty and reminds me of a nervous system.

The hardware is all set up and appears to be working OK (with no magical smoke), but the digits are not showing up in order.

I was lamenting on Discord about having never found an on-ramp for linear algebra despite learning it several times over, and someone recommended The Ray Tracer Challenge by Jamis Buck.

It starts all the way from the bottom, from tuples to points and vectors and matrices, but doesn’t really get bogged down in the math a whole lot, which was what the entirety of linear algebra was like for me through high school and college. I even somehow slogged my way through a computer graphics class in college that probably followed the same curriculum in this book. By the time we got to any actual graphics work in that class, I was already mentally checked out having had to hand-compute matrix products and determinants. Not to mention, the class was held in C for a program that was taught primarily in Java.

However, Buck moves with a quick “let’s just go through this once and move on” pace and doesn’t take his time getting to why all these concepts are useful. This time around, I’ll be writing in Python. In addition, rather than implementing all the transformations by the book, I’m just going to take advantage of the power of NumPy, another thing I hadn’t really gotten too deeply into for lack of practical applications.

I swear, once I make it all the way through this book, I’ll come back and do a few more of these by hand, but for now this stuff is actually pretty exciting and I have made my first computer-generated image file since college:

def projectiles():
    height = 400
    width = 400 
    canvas = np.zeros((height, width, 3))
    
    for magnitude in range(4,100):
        start = np.array((0,1,0))
        velocity = np.array((1,1.8,0)) 
        velocity = (velocity / np.linalg.norm(velocity)) * magnitude* .2
        p_pos = start
        p_vel = velocity
        env_grav = np.array((0,-0.1,0))
        env_wind = np.array((-0.04, 0, 0))

        while p_pos[0] >= 0:
            #tick
            p_pos = p_pos + p_vel
            p_vel = p_vel + env_grav + env_wind

            #print(p_pos)
            ppm.write_pixel(canvas, int(p_pos[0]), height - int(p_pos[1]), ppm.RED)

    ppm.write_ppm(canvas, "projectile.ppm")

Anyway, that was just for outputting 2D files. I’m still working my way through 4x4 matrices before I get to the fun 3D stuff.

Also I did write the file output myself. The book works in PPM files, which are just plain text files, and quite handy for debugging.