Matthias' Blog

Currently, my school's FSAE team uses a Bosch PBX90 to distribute power from the car's low-voltage battery to all low-voltage systems in the car. Its main purpose is to monitor for overcurrents, control the order in which boards are powered when the car is turned on, and control power to certain systems in response to commands it receives over a CAN bus. However, the PBX90 has several limitations that needed to be addressed. First of all, the team plans to use a 24-volt low-voltage battery next year, and the PBX90 only goes up to 20 volts. Additionally, the vertical connectors made packaging more difficult and are generally more difficult to use than the Ampseal connectors we use on the rest of our boards. Finally, the PBX90 costs several thousand dollars, so manufacturing an equivalent board in-house would also save money. Thus, I volunteered to design a power distribution unit (PDU) to replace the Bosch PBX90 in next year's and in future ca...

A few months ago I got an old TDS540A oscilloscope in working condition. Unfortunately, after sitting unused for several months, the scope developed an interesting fault. Instead of occupying the whole screen, the captured waveform was chopped up and repeated several times as shown below: My initial guess was that there was a broken address line, so I opened up the oscilloscope and had a look at the boards. There were no obvious signs of damage (such as a corroded trace from a leaking capacitor), so I decided to take a look at the schematic. I found some schematics on the TekWiki page for the TDS540, but the schematics did not match up with what I was seeing on the board. It turns out that TDS540A is more similar to the TDS544A than to the TDS540. After finding the schematics for the TDS544A, I spent a while looking at the schematics and probing random points on the board. Since I didn't know what any of the signals should look like, this wasn't terribly productive, so I tr...

In this article I will explain some of the main features of the new lightsaber PCB design and some of my thoughts behind them. I will also give some updates on the other aspects of the lightsaber project. Schematic changes Power distribution While trying to work out how the lightsaber would be powered, I found out that the LED strip consumed 70mA even when all of the pixels were off. Since the plan was to program the lightsaber to go into a low-power mode if it was inactive, this presented a problem. Even if the Nano and the audio amplifier were completely shut down, the lightsaber would still consume power until it was switched off. This also would have required a more expensive switch, since the switch would have to be able to switch the full current of the LEDs. To fix this, I added a MOSFET which could turn the power to the LED strip on and off. I also separated the LED and Arduino/amplifier grounds. This allows the Arduino to be powered through the protection circuit on the...

In a recent post on Hackaday , I described my initial plans for a lightsaber prop. The final device should be able to generate the characteristic buzzing noise, play sound effects stored on a flash chip, and respond to motion. In this article, I will explain the technical details of the first prototype. Overview As I described in the Hackaday aticle, my plan was to use an ATtiny85 to generate the audio and write to the DAC and use an Arduino Nano to read from the accelerometer and control the lights. The buzzing sould consists of a loop of 833 one-byte samples that are stored in the program memory of the ATtiny. The sound effects are stored as WAV files on the flash chip. The Nano can then write to the ATtiny to control the amplitude of the buzzing or start playback. Thus, the ATtiny must therefore be able to read the buzz sample from program memory, multiply it by its amplitude, multiply the previous playback sample by its amplitude, mix the buzzing and the playback, write to the ...

In a previous article, I explained a type of water level sensor that works capactitively and therefore passes no direct current through the water. When I wrote that article, I had already made two of these sensors and installed one in each of the two sump pump wells in my basement. These sensors have been working quite well for a long time, but they have a few issues. In this article, I will describe the improvements I have made to the sensor design and how I calibrated the sensors to allow me to determine the water flow rate and the volume of water the sump pump pumps each time it comes on. Introduction The two water level sensors I installed in the sump pump wells were equipped with nRF24L01 wireless modules. They transmitted measurements every 30 seconds to a Raspberry Pi, which recorded them to a database. This allowed me to visualize the water level in the sump-pumps in real time and see roughly how often the sump pumps came on. However, the water level followed this interest...

In a modern washing machine, the moter that spins the drum is controlled by a motor driver, which is separate from the main control board that manages the washing cycle. The main control board sends commands that set the speed of the motor, and the motor driver generates the three-phase power needed for the motor and regulates the speed of the motor. In this article I will explain how I reverse engineered the motor driver (Magnetek 4246-99-1) from a washing machine and then controlled it with an Arduino. Reverse engineering the original setup In the washing machine, the motor driver received mains power through a relay on the main control board. The motor driver was controlled by the main control board via a 5-pin cable. The pinout is shown in the image below: The main control board communicates with the motor driver using an SPI bus. Data is transmitted in bytes with the most-significant-bit first. On the rising edge of the clock signal, the main board updates the signal on the MO...