Longpost on Hill's Space

Not Real Numbers

hillexed@email.com (hillexed) — Fri, 25 Oct 2024 00:00:00 +0000

I rediscovered the xkcd up goer five text editor, which lets you type using only the 1000 most common english words. So here’s my attempt at writing a description of something:

Not Real Numbers

We know how to do many number problems. Number problems with adding are easy. Adding the same number over and over is also easy. If you take a number and add it many times, the same number of times as that number, you get a box number.

We can go forward from number to box number. Sometimes you want to go back from box number to smaller number. In fact, if you have a number problem with box numbers and adding over and over and adding, you learn in school a box problem answer form to do the problem. But part of the answer form says to go back from box numbers.

A box number is always above the nothing number, or is the nothing number. Five boxed is twenty five, and so is five under nothing boxed. Even numbers under nothing, if you box them by adding them that many times, are above the nothing number. But for some problems, the box problem answer form wants you to find a number where its box number is under nothing. Oh no!

So the number people made up a new number, to imagine its box number is one under nothing. Some people were mad and called these new numbers not real. They were surprised when these not real numbers were good for doing problems! We only need to make up one new number to do all number problems with adding and adding over and over! Also, we can draw not real numbers by imagining they go in a different direction than real numbers.

Pifinder Perils

hillexed@email.com (hillexed) — Mon, 04 Dec 2023 15:29:08 +0000

I’m building a PiFinder! It uses a camera to take pictures of the sky, connected to a raspberry pi which uses a database of stars to tell you where in the sky your telescope is pointing. But a PiFinder is $550 new. A stock pifinder uses the newest and most expensive options for pis and cameras, and when I looked at the parts list, I thought: I can build something similar for a fifth of the price! And so began the quest to create the Sliced PiFinder: a DIY PiFinder made from an used raspberry pi for a small slice of the cost. Previously, I bought a $33 camera and 3D printed a custom enclosure for it.

On the one hand, if I can successfully modify this project so I don’t need expensive parts, I save $400! On the other hand, my hubris has led to consequences.

This is a longpost about those consequences and the shenanigans I found to work around them.

(None of this would be possible if the pifinder wasn’t open source, so thanks to the creator brickbots, who has given me tons of help!)

Problem 1: Camera FoV

We live in a world where I use software written by a space agency across the ocean for free. What a world we live in.

Once the PiFinder takes a picture of the sky, it needs to use a database of stars to figure out where in the sky the camera was looking when the picture was taken. That process is called “plate solving” because we used to take star pictures on photographic plates.

How do you plate solve? Amazingly, that’s the easy part! The European Space Agency released an open source python library called “tetra3” that does it all for you! All you need to know is… hmmmm… the exact position of every single star in the sky your camera can see.

Amazingly, you can just download a database of every single bright star in the sky! Astronomers have been making star catalogs for thousands of years, including launching space telescopes like Gaia devoted to doing nothing but star cataloging. The PiFinder software downloads a database of stars automatically!

However, for tetra3 to plate solve, it needs to know your camera’s field of view (FoV), so it knows how far apart various stars will look to the camera. Different lenses change FoV. The PiFinder software expects you to have a Raspberry pi HQ Camera ($50) and 25mm lens ($20), which has a FoV of 10.2. I’m using an IMX462 camera ($33) and 12mm lens from a different camera ($10), so how do I figure out my FoV?

One option is math. I tried pointing the camera at Orion, taking a picture of the screen, measuring the distance in pixels between stars in orion, and comparing that to the known angular distance. That gave me an estimate of 15 degrees of FoV. Unfortunately, I didn’t know at the time that the the picture was wider than the screen.

Then I realized I was using a raspberry pi and could access the raw hardware. I SSHed in, used the command line to take a picture, then downloaded the raw .png. Now I knew what the software was looking at. I uploaded it to nova.astrometry.net, which plate solved my image and told me not just the exact coordinates of where I was looking (and the constellation!) but also the image’s FoV.

(Also, just for fun, I used it to take my first ever long exposure shot of 30s, and was blown away by the number of stars visible. Image above!)

Another complication: images are 2D. Does tetra3’s FoV input mean horizontal FoV or vertical FoV or diagonal FoV? I didn’t see it anywhere in the documentation. (It was horizontal)

In the end, my new IMX462 camera with 12mm lens had about 26deg of horizontal FoV. I could buy a new lens to reduce that down to the PiFinder software’s expected 10.2 degrees… but instead brickbots helped me write software to crop the image down to 10.2 degrees. Now plate solving works!

Problem 2: Alt/Az

Let’s say you want to see the andromeda galaxy. How do you know if it’s is visible in your night sky right now or not? Should you look north or east or south to find it?

Since the earth is a sphere, “down” changes from place to place. Since north is perpendicular to down, that means north/south/east/west look at different parts of the sky based on your place on earth.

Thankfully, if you know your location on Earth and the time, since Earth rotates once per 24 hours you can do some math to figure out where to look relative to your local north and down directions. Those coordinates are called “altitude” and “azimuth”.

The PiFinder gets your location on Earth and the time from a $50 GPS USB dongle. But that’s expensive and my phone already has a GPS. If I can modify the software so I can enter my coordinates and the time, I save $50.

It turns out parts of the software don’t work unless it knows your coordinates, but instead of showing an error message some features simply do nothing. I edited the software’s config file to add my GPS coordinates… but coordinates in the config file are never used, since all previous pifinders have had GPSes and got coordinates from there. So I had to modify the existing “GPS_fake.py” (which previously did nothing) to actually send fake GPS and time messages.

And because computing altitude and azimuth isn’t complicated enough: the raspberry pi has no internal clock, so every time it starts up the time is wrong (unless it can connect to wifi and download the time using NTP). This works for me at home, but if I want to take this to dark places, I eventually need to program a screen that lets you enter the coordinates and time on the device itself!

Problem 3: Gyroscope Fusion Failures

If you move a telescope with a PiFinder left or right, changing your azimuth, its screen should move the star display left or right quickly. That’s hard for a few reasons.

First, the Pifinder needs long exposures to capture dim stars. If it moves during a long exposure, the image it captures will have stars that look like smeared lines instead of dots and it can’t plate solve. That means if you bump the device, there’s a few seconds of delay before the camera can lock on to the sky again.

To get quicker feedback during unsuccessful pictures, the PiFinder uses an intertial measurement unit (IMU) chip, which combines a gyroscope (measures changes in angle), an accelerometer (measures acceleration, including gravity), and a magnetometer (measures Earth’s magnetic field). The PiFinder uses a fancy $30 IMU chip called the BNO055, which has a tiny processor that computes the chip’s current altitude and azimuth 100+ times a second.

However, I scavenged an LSM6DS3TR-C + LIS3MDL IMU from a different project with the exact same sensors: magnetometer, gyroscope, accelerometer. Surely, I thought, I could write some code to compute altitude/azimuth from those sensors and save $30!

Combining data from the 3 sensors is called “sensor fusion”. It’s incredibly hard. Thankfully, I’m not the first to study sensor fusion (drone builders want it too) and there’s two main sensor fusion algorithms which already exist, named mahony and madgwick. Adafruit has an AHRS library which implements both… in C++, but I was using python. Eventually I found an implementation of both and downloaded it, loaded in my sensor readings… and spinning the device 90 degrees didn’t change the output by 90 degrees. Why?

Problem #1: Axis remapping!

In my PiFinder, the IMU is oriented so the sensor’s +Y direction is the one the camera is pointing towards, but I had a hard time figuring that out because the chip was buried inside a circuit board and the code has many options to switch coordinates based on how a PiFinder is mounted on a telescope.

Problem #2: Units

The Madgwick filter expected the gyro’s inputs to be in degrees/second when they were in radians per second. No problem, I can just multiply them by 180/pi. Then I took a look at the Madgwick code, and it requests degrees because it multiplies the numbers by pi/180 to turn them back into radians. Aaargh.

Problem #3: Calibration!

Magnetometers and gyroscopes will drift - if they output a range, say, 4 units wide, instead of getting sensor readings from -2 to 2, your actual readings might be shifted so you read values from 0.5 to 3.5. Magnetometer readings shift in a similar way for a different reason: Earth’s magnetic field is different everywhere. You can take many many readings and average them to find the true zero point, then subtract that from all future readings to make zero the middle point.

For a gyroscope, those readings need to be taken while the gyroscope isn’t moving. I realized I could use the accelerometer for that - if the accelerometer’s gravity direction isn’t changing, I can use that to know I’m not moving and grab some gyroscope readings. Once you integrate the gyroscope over time, it looked pretty stable, with only around 0.3 degrees of error.

For a magnetometer, spin it around as much as possible, and the unchanging 3D vector of earth’s magnetic field, as measured by the magnetometer’s 3 axes, should trace out a sphere! Then you can use the center of that sphere as your reference zero point.

Engineers did what engineers do in overly specific fields and made up magnetometer calibration number jargon. The values for center of the sphere (which should be at (0,0,0) but usually isn’t) are called the “hard-iron offsets”. But you can get fancier: if you have a magnet (or some other electrical device) near the magnetometer, it might make its own magnetic field and skew one axis at a time, and that skew is called the “soft-iron offset”. They’re just coefficients in a calibration matrix!

The simplest way to calibrate a magnetometer is to ignore soft-iron entirely, keep track of maximum and minimum values in all 3 magnetometer axes as you spin the device around every which way, assume the hard-iron offset is the average of the max and min, and subtract that calibrated value every time you read from the magnetometer in the future.

I had to do all that calibration myself. The output still didn’t work very well. The sensor fusion algorithm’s output reported altitude and azimuth axes which didn’t measure down correctly. Why wasn’t it working?

Problem #4: EVERY SINGLE MAGDWICK FILTER EVER WAS WRONG 3 YEARS AGO

According to this research by someone named Mark Uckermann from a British bike GPS startup,, apparently almost every Magdwick library has a subtle bug in the code compared to the original paper, invisible if you use a small enough “beta” parameter. Oops. That was 3 years ago, and I think my library has fixed it? But I can’t tell since the variable names are slightly different.

Problem #5: Speed

The sensor fusion algorithms involve lots of math. Doing these calculations myself in python (along with the camera and plate solving and everything else the pifinder was doing) took up so much time that on my pi 3, the IMU code was only able to read values from the sensors around 12 times a second. The sensors were updating 104 times a second. That meant I was losing tons of info, including updates of “how much the angle shifted since the last time you checked” data from the gyroscope. I could configure the sensors to slower speed… But the gyroscope+accelerometer could only go to discrete values like 12.5 Hz while the magnetometer could only go to different discrete values, like 10 Hz. Aargh.

After all that… turning my device 90 degrees still wouldn’t make the azimuth output change by 90 degrees. Aaaaargh.

But wait. If my sensor fusion algorithm wasn’t working… maybe it was a problem in the sensor fusion algorithm code? The accelerometer tells me the direction of gravity - maybe I can compute azimuth. The IMU can tell me where magnetic north is. If I measure both… maybe there’s a way to compute altitude and azimuth directly? Maybe, just maybe, if I sat down and did a ton of galaxy brain math, I’d be able to use my own scavenged IMU instead of buying the pifinder’s recommended BNO055 for $30!

Oh yeah. The BNO055 chip is $30. It does calibration for you.

I gave up, desoldered my old IMU, bought a BNO055, and soldered it in.

It better work.

I'M MAD AT AMERICAN PIPES

hillexed@email.com (hillexed) — Wed, 10 May 2023 18:39:09 +0000

I have a 1/2" diameter hole. I want to put a pipe inside the hole. What size PVC pipe fits into a 1/2" hole?

Did you guess 1/2" pipe? WRONG. “1/2 inch pipe” isn’t half an inch big on the outside. It’s closer to 7/8". You might think “ah so the 1/2” refers to the inner diameter". Wrong. The inner diameter of 1/2" PVC pipe is legally required to be 0.602 inches, according to the Schedule 40 standard. Want a pipe with outer diameter 1/2"? The closest size of PVC pipe is of course 1/4" PVC pipe. But even that won’t quite work, because, 1/4" pipe has outer diameter 0.54", which is more than 0.5" and way more than the 0.25" in the name of the pipe. PIPE SIZES ARE ALL LIES

Guess how I found out? I’m building a telescope, and as part of that I’m building a mount. I bought a cheap collection of 3 pipes off the internet, but I needed a fourth, so I went to the hardware store to buy some pipe. Guess who learned a $6.99 lesson in nonsensical standards…

Chamomile comments:

Wow, this is way more infuriating than 2x4’s actually being 1.5x3.5 inches.

Porglezomp addition:

Your comment made me think “oh well i know why 2x4s are like that at least that makes sense” and then I realized that there was probably a reason for this one too, so I went and figured that out:

You see, a 2x4 is 1.5"x3.5". And I thought “well, at least that has a good reason from a century ago,” but then I realized that this probably has one of those too. So let’s look into it.

Dimensional Lumber

A 2x4 is 1.5"x3.5". So why is it named like that? Well, a century ago a 2x4 referred to a 2x4 of green lumber—it was commonly cut and shipped green. And then it would shrink as it dried, and be planed to a precise size on-site. Eventually, we got better at making and transporting dry lumber, but stuck to those post-drying actual sizes for the same nominal sizes. For compatibility. So it’s the fault of compatibility with how things were manufactured over a century ago. It made sense at the time. Nominal Pipe Size

You might think “ah so the 1/2” refers to the inner diameter". Wrong. The inner diameter of 1/2" PVC pipe is legally required to be 0.602 inches, according to the Schedule 40 standard.

Well it turns out this is also the same thing. When nominal pipe sizes were standardized, they referred to the inner diameter of the pipe, but those pipes had thicker walls. Now we build stronger pipes that have thinner walls, but the dimensions were still standardized and named for those older inner diameters, and now they’re all nonsense again.

The reason for the discrepancy for NPS 1⁄8 to 12 inches is that these NPS values were originally set to give the same inside diameter (ID) based on wall thicknesses standard at the time. However, as the set of available wall thicknesses evolved, the ID changed and NPS became only indirectly related to ID and OD.

Source: https://en.wikipedia.org/wiki/Nominal_Pipe_Size#Application

This standard is from 1927 / 1939 / 1949 ?? so it is more annoying than the lumber standard, to me. Diamètre Nominal

I’M MAD AT AMERICAN PIPES

Good news! European pipes are no better! A 15mm pipe has a 21.3mm outer diameter, and the inner diameter also completely depends on the material.

Source: http://www.piping-engineering.com/nominal-pipe-size-nps-nominal-bore-nb-outside-diameter-od.html

How Microprocessors Make Music

hillexed@email.com (hillexed) — Sat, 12 Nov 2022 18:11:52 +0000

So I’ve been working on trying to make a little Arduino powered synthesizer recently! Turns out it’s hard and sound is complicated and now I’m cursed with knowledge. The only way to get rid of curses is to dilute them, so here’s everything I’ve learned about how to make sound on an Arduino.

Speakers

A speaker takes some electricity and moves a little flat thing either outwards or inwards depending on the voltage, which pushes on air and makes sound. They convert changing electricity to changing sound waves. For a microprocessor to make sound, it needs to change voltage really fast so the speaker makes the right sound wave.

The Simplest Square Sound

Computers use zeroes and ones. Those are usually voltages: a zero is a low voltage, and an one is a high voltage. Any Arduino pin can easily output a zero or one, in the form of either 0 volts (“0V”) or 5 volts (“5V”). However, not all pins can output the values in between. Thankfully, there’s one easy type of sound wave you can output using only 0V and 5V: a square wave at maximum volume, which switches between 0V and 5V at a high frequency. Arduinos even have a built-in tone() function to do that, which uses a timer (timer1, which I’ll get to later) to manually switch whatever pin you want between 0V and 5V really fast in software. Unfortunately, to output other types of waves (like sine waves), or even just control a wave’s volume so your wave can fade out over time, you need to output values between 5V and 0V. For that you need PWM.

All the other sounds: PWM

PWM works like this. Let’s say you want to output 1 volt. Unfortunately, an Arduino physically cannot output 1 volt - it can only output 100% of 5V or 0% of 5V, with no in between. If only you could just output 20% of 5V. The arduino can’t output 20% of 5V, but it can output 5V, 20% of the time. If you switch between 5V and 0V really fast, outputting 0V the other 80% of the time, it averages out to 1V! That’s Pulse Width Modulation (PWM): switching between 5V and 0V really fast in order to output signals which are, on average, any voltage you want between 5V and 0V. (To do the averaging, usually a resistor and capacitor are placed in between the output and the speaker to act as an “RC filter”.)

Timing is everything

An Arduino has hardware built into the chip to do PWM. But that hardware is only built into certain pins of the chip. That’s because in order to switch between 5V and 0V fast enough to average out, you need a very fast and accurate timer to tell you when to switch. The ATMega328 chip which most Arduinos use has 3 timers built into it, so you can run 3 PWM outputs at different speeds at once if you really wanted to.

To control PWM, you’re really controlling the timers, and so you need to set specific bits in specific arcanely-named all-caps acronym variables like OCR1A which you can only understand by looking up “ATMega328 datasheet” and banging your head against a wall.

Timer 0 is used for the system functions millis() and micros(), so it’s encouraged not to use it if you have the option. Timer1 is a 16-bit timer, which means its PWM pins can output any multiple of 5/(2^16) volts at once. However, it can only output to digital pin 9 or pin 10 (hardware-chip-footprint-numbers 15 and 16). Timer2 is an 8-bit timer, which means it has less resolution than Timer1 and can only output 2^8 different values between 5V and 0V. It outputs on digital pin 11 or digital pin 5 (hardware-chip-footprint-numbers 17 and 11). That’s worse for audio, because you want smoother waves. Use timer 1.

PWM has some rough edges

Let’s say I want to output a sine wave at a frequency a. Mathematically, I want to output the function sin(at), where t increases over time. Mathematical sine waves are smooth, with infinite resolution. Unfortunately, sine waves created by computers are really just numbers, and those numbers have a fixed resolution.

Let’s say we’re using an 8-bit PWM. In order to use PWM and output your wave, you must tell the PWM an integer between 0 and 2^8 = 255, and it will interpret 0 means 0V and 255 means 5V, and anything in between is treated as a fraction with 255 on the bottom: 20 means 5 * 20/255 volts. The inputs are converted to integers. That means even if your wave is continuous, any values in between any two integers such as 4 and 5 will be rounded to either 4 or 5. Even if the math says your wave should output the value sin(1) * 255 = 4.45, that number will be rounded down to 4 and output 0.078V instead of 0.087 V.

(Math note: sin(at) is centered at y=0 and ranges from y=-1 to y=1. To properly fit sin(at) into the range 0 to 255, you really want to output sin(at) * 128 + 127 so that the center point is 127, the center of the 0-255 output range.)

The 8-bit timer forces us to round our numbers to 8-bit integers (0-255), and that causes some effects you can hear. Specifically, the rounding might sound like the wave is “tinny”, or has some extra buzzing. Some people like that sound because it reminds them of the old days of 8-bit computers and will add that effect into music on purpose, which is called “bitcrushing”.

In general, squeezing a wave into k bits will distort the sound less and less the bigger k is. 8-bit is pretty noticeable. 16-bit lets the values range from 0 to 2^16, and there’s basically no distortion. 16-bit audio is CD quality. Avoid 8-bit PWM for audio output and use something with more bits if you care about audio quality.

Multiple notes at once? That’s not in the budget

A piano can play more than one note at the same time. I want my microprocessor to be able to do that too!

Let’s say I’m stuck with my 8-bit timer, and I want to output two notes at once. Thankfully, it’s not too bad: to hear two things at once, just add up the waves. Then, output sin(at) + sin(bt). That’s just a number, so I can output it fine using PWM, right?

Unfortunately, sin(at) and sin(bt) both range from -1 to 1, so adding them together could give me a number anywhere from -2 to 2. That means if I used the same formula as before to convert the waves into the 0-255 range, wave(t) * 128 + 127, I’d get a value from −129 to 383, which is outside the valid 8-bit timer range 0 to 255. Whoops.

To fix this, instead of outputting sin(at) + sin(bt), shrink the wave vertically so it ranges from -1 to 1 by dividing by 2. Output (sin(at) + sin(bt))/2. Perfect.

You can even generalize this: to play eight notes at once, add up the 8 individual waves and divide by 8, and your signal will stay between -1 and 1. If you want your Arduino to be able to play up to 8 waves at once, you’ll want to output (wave1 + wave2 + wave3 + wave4 + wave5 + wave6 + wave 7 + wave8)/8. If you convert that into the range 0-255, it’ll be (wave1 + wave2 + wave3 + wave4 + wave5 + wave6 + wave 7 + wave8)/8 * 255 + 127. If you’re not playing all 8 notes at once, some of those waves might be 0 the entire time and not some form of sin(t).

However, if you program that into your microprocessor, then even just one note might sound very distorted! Why?

Remember, the less bits you have to store a wave, the more distorted it’ll sound. If sin(x) can take any value between -1 and 1, it’s converted to 8-bit number that’s rounded to any value between 0 and 255. But if 8 notes can be played at once, and we divided by 8, we’re effectively adding waves of the form sin(x)/8, which is rounded to an integer between 0 and 32.

This rounding has two effects: first, using the same speaker, our original 0-255 wave moves the speaker eight times more distance compared to an 0-32 wave, so the new wave sounds much quieter*. (This problem once tricked me into thinking my code stopped working, when really it was just too quiet to hear.) Second, rounding a wave to one of 32 values adds a LOT more distortion than rounding to one of 256 values, and you can hear that distortion very strongly.

*the wave is eight times weaker, but we hear volume logarithmically so it only sounds log_2(8) = 3 times weaker.

You could think of this as a “bit budget”: you can either spend your 0-255 range on one high quality wave, or give each wave 1/8th of the total range to represent them so that you can add up to 8 waves at once at the cost of bitcrushing each individual wave.

Use 16-bit outputs. That way you can play multiple waves at once without running into the bitcrushing problem as much, because an 0-65536 range divided by 8 is still a very high quality 0-8192 range. You’ll still have to make the speaker louder to counteract the volume loss from dividing your waves to play multiple notes at once, however.

Also, there’s intense time pressure

Humans can hear waves up to 20kHz, which means if you want to be able to output all possible waves a human can hear, your microcontroller needs to choose which value to output 40,000 times a second. That includes doing any math to compute sin(x), adding the waves from multiple notes at once, etc. It’s not too bad if you only play one note at once - in fact, for a square wave you can simply use a timer - but if you want to play multiple notes at once, time starts to become a problem.

An Arduino runs at a 16mHz clock speed by default. That means whatever code you write to choose which 0-255 or 0-65536 value to output, that code needs to involve less than 16000000 / 40000 = 400 machine instructions. Your function needs to be FAST. If it takes too long, you’ll get distortion!

Writing fast code is hard. I’ve successfully gotten up to 4 waves added together on an Arduino, but but as soon as I tried adding a few more additions to bring it up to 6 waves at a time, my code took too long to compute, lagged, and made weird digital noises instead of my crisp waves. Want to compute (wave1 + wave2 + wave3)/3? Too slow. The ATMega chip doesn’t have a division instruction built in, so dividing by 3 takes as much time as a good fraction of the rest of my code combined.

A library called Mozzi solves the gotta-go-fast problem by having its fast function be “read one value from the precomputed buffer and output it”, then updating that precomputed buffer only once every 256 function calls. Another technique for outputting waves quickly is called “wavetable synthesis”, where you save many values of sin(x) for various x in a table 1024 entries long, and that way accessing table[x] is very quick. Other projects go fast by abandoning the Arduino’s ATMega328 chip for an even faster computer, such as a Teensy. In fact, the device you’re reading this on is much faster than either of those, and that’s why people usually make music with computers nowadays.

In summary

Computers are made of workarounds upon workarounds upon workarounds, modern processor speeds are a miracle we take for granted, and I’d say music was a mistake but actually the cool noises you get at the end are worth it.