insert newline RSS

Aeon Photo Frame

Sat, 22 Feb 2025 00:00:00 GMT

Introduction

Colour e-ink displays are a relatively new technology that have become available to consumers in the last few years. E-ink displays are unique in that they are bistable, meaning they only consume power when the image displayed is changed. This makes them ideal for applications where the displayed image is static for long periods of time, such as e-readers. They also have the added benefit of working reflectively, increasing their visiblity as the level of ambient light increases.

The relatively recent commercial availability of these displays served as the inspiration for this project. Digital photo frames that utilise these displays already exist; however, these would only run for a few years on a single charge (which is, admittedly, still quite impressive). I wanted to build something that would run (effectively) indefinitely, keeping to the theme of what I think is the coolest feature of e-ink displays, their ability to retain a displayed image forever. As such, this project was designed from the ground up with a focus on longevity.

The final device should be indistinguishable from a normal photo frame, in both appearance and typical usage. That is, you should be able to treat it like a normal, static photo frame, and it should just work, ideally for an extended duration of time (think a decade or two). The only difference to a normal photo frame, the photo displayed will change maybe once a day, and to achieve this functionality, the device should never need to be charged.

Hardware

The central device that Aeon was designed around was the Waveshare 7.3" 7-colour e-ink display, chosen for its ability to display a range of colours, and its suitable size to fit in a 6x4 photo frame.

Since the final appearance of the device was important, all the electronics were required to fit within a fairly thin profile, which necessitated the use of a custom PCB.

The main electronic systems on the PCB consist of the following:

Power management: energy harvesting and storage, output regulation and voltage rail switching
Processing: a low-power microcontroller to transfer image data from an SD card to the display, an FRAM IC to store configuration data
Display driver: power circuitry for the e-ink display

Power System Architecture

The power system of Aeon was designed to be as efficient as possible, with the goal of minimising the quiescent current consumption of the device.

Energy Harvesting

One of the design goals for Aeon was continuous operation without the need for charging. This required finding a suitable ambient power source that could be harvested. Since the devices' power profile involves the majority of consumption ocurring when the image is changing, with near-zero power usage when displaying static image, the average power consumption should be very low.

In terms of energy sources for harvesting, light stands out as really the only option. The household environment that Aeon is intended to be used in does not have a particular abundance of other sources that can be harvested (e.g. heat, vibration, RF). Hence, light harvesting using solar cells was chosen for the design.

Aeon's power management circuitry is based around the E-peas AEM10941, an impressive little chip that integrates a basic MPPT controller with dual cascaded DC-DC converters to extract as much energy as possible out of the solar cells, even under poor lighting conditions.

Energy Storage

The choice of energy storage element was evaluated throughout the development process. I initially intended to use dual 6F supercapacitors to achieve the maximum longevity for the device, however, the energy storage to size ratio for these were quite poor. My calculations showed that a cold start would be required if the solar cells didn't see sun for even just a few days.

To avoid these issues, I went with a tiny 160mAh Li-ion battery instead. Under normal usage in a well-lit environment, this battery only sees very shallow charge-discharge cycles. Since Aeon doesn't rely on anything even close to the full 160mAh capacity of the battery (with a 24hr refresh cycle, it would run for months on a single charge), it would be reasonable to expect that the usable lifetime of the battery could last a decade or more.

Battery Protection

In the pursuit of absolutely minimising quiescent current consumption, I elected to remove the protection circuit of the Li-ion cell. Extreme care is needed during this process, accidentally shorting will cause even a tiny 160mAh cell to output 20+ amps of current, which can cause burns (ask me how I know). Additionally, extended shorting will permanently damage the cell and potentially cause thermal runaway.

So on the whole, I would recommend against this procedure, but I decided it was worth it to save a few microamps of current consumption. I tried to ensure that the features provided by the protection circuit would also be facilitated by the Aeon power management circuitry. I included a PPTC resettable fuse that should limit current in the unlikely event of some other failure on the board, and the AEM10941 directly protects against overcharge and overdischarge conditions.

Voltage Rails

The Aeon power architecture consists of two voltage rails, the main 3.3V rail is sourced by a low-quiescent current LDO voltage regulator, and is always active while the battery is within an acceptable voltage range. The microcontroller is powered by this main 3.3V rail. While the AEM10941 does include a built-in 3.3V regulator, it was not used because the display driver’s power requirements exceed the regulator’s current limit during refresh cycles.

The second voltage rail is an auxiliary 3.3V rail. This powers all the peripherals (SD card, FRAM IC, display driver). The auxiliary rail is manually enabled by the microcontroller through a P-channel MOSFET when a refresh cycle is initiated. This allows the peripherals to be completely powered off when not in use, minimising quiescent current consumption.

Processing

The brain of this project is the STM32L412K8 microcontroller.

The selection criteria for this role was primarily minimal power consumption. The STM32L412 series has reasonably low power consumption when active, and, more importantly, has impressive low power modes. In the case of the STM32L412K8 used in Aeon, the IC theoretically consumes an incredibly low 0.2uA in standby mode, while allowing it to wake up from the internal RTC or an external signal.

This microcontroller handles interfacing with the SD card and the display, as well as scheduling RTC wakeups to ensure display refresh cycles occur at the configured intervals. Additionally, it monitors the battery voltage using the ADC and controls the auxiliary 3.3V rail, ensuring efficient power management. The STM32 communicates with all peripherals over SPI.

FRAM

A 4 Kbit FRAM IC is used to store configuration data. FRAM is a non-volatile memory technology that has the advantage of being able to be written to an effectively unlimited number of times, unlike EEPROM which has a limited number of write cycles. This IC is used to store various configuration data such as current image index, remaining sleep duration, etc.

Buttons and Switches

The PCB contains two buttons, one wakes the STM32 from standby and perform a manual refresh of the display, and the other is simply wired to the reset pin of the microcontroller.

Additionally, two 6x DIP switches are used to set configuration settings:

ON/OFF switch for the device
Enable/disable shuffling of images
Refresh cycle duration in hours (configurable between 1 and 1024)

Display Driver

The display driver circuitry mainly consists of two DC-DC converters required to generate the necessary voltages for the display. These were not designed by me, but were taken from the reference design provided by Waveshare for this display.

Electronics Development

The Aeon schematic is shown below. For full design files, please see links at the end of this post.

This was the first custom PCB that I had designed, so there were several minor mistakes made. Additionally, due to time constraints, I worked on this project on-and-off over a few months; but these breaks worked out in my favour, as it gave me time to order new PCBs with bugfixes.

I went through five revisions. Several of these were semi-preventable by adding some bodge connections, but since I had the time, I decided to fix up any minor issues properly.

Frame Design

One of the key design goals for Aeon was that it should be indistinguishable from a normal photo frame. This meant the structure thickness had to be kept less than 8mm in order to fit in a standard 6x4 photo frame.

This constraint posed quite a few challenges during the design process, since this thin profile had to accommodate the PCB, the display, the solar cells, and the battery.

The design consists of a main body that the display, PCB and solar cells are mounted in, and a removable back cover that contains a slot for the battery. A back stand was also designed to emulate the functionality of a typical photo frame; however, its shape is slightly unconventional, designed to minimise the shadow cast on the solar cells.

Main Body Assembly

The parts were designed to be 3D printed, and as such, certain objects are printed in separate pieces that then need to be assembled by gluing together. Cyanoacrylate (superglue) was used for this purpose.

The far more substantial challenge was wiring and potting the solar cells. The solar cells are wired in series, and the wires are routed through the channel in the main body into the PCB area. The bare solar cells I used were incredibly thin and fragile. Soldering onto them is fairly difficult, flux is absolutely required to get the solder to flow onto the contacts on the cell. After wiring each one, they can be glued into the body using two small dabs of hot glue.

Once all the cells are glued in place, clear epoxy resin can be poured onto the inset area around the cells. This is a bit of a messy process, but it is necessary such that the device can be handled without worrying about damaging the solar cells.

I discovered the hard way that the resin can leak into the PCB area if the wiring channel is not properly sealed. Small amounts of epoxy can be carefully removed after curing using isopropyl alcohol and a scraping implement.

Final Assembly

The front side of the main body has an inset slot for the display to be placed into. For mounting, I simply used kapton tape on the rear of the display.

A paper mask was cut to size and placed between the display and the front glass to hide the display flex cable (for printable template, see links below). Once this is in place, the front becomes almost indistinguishable from a normal photo frame

The battery is attached onto the back cover using tape, and this cover can be slotted in to cover the PCB area of the main body. Finally, the removable back stand can be pushed into the slot on the back of the main body.

Software

The software for this project is split into two parts: the firmware running on the STM32 microcontroller, and the image conversion scripts.

Firmware

The firmware for the STM32 is generally quite straightforward. The basic logic that needs to be achieved is:

Read next image from SD card
Send image data to display
Enter standby mode and set RTC wake interval for next refresh cycle

In practice, there is a bit more complexity to this. For example, the STM32L412K8 does not have enough RAM to store an entire image, so the image data is read from the SD card in chunks and sent to the display as it is read.

Additionally, the maximum RTC wake interval duration is around 18 hours, so the firmware needs to handle this limitation by chaining multiple wakeups together to achieve the desired refresh cycle duration. The FRAM is used for this chaining, and additionally for maintaining the current image index to allow the images to be changed in the desired sequence, even after a cold start.

Further logic is also present to monitor battery voltage, and to handle the various configuration settings that can be set using the DIP switches.

Image Conversion

The 7-colour e-ink display used cannot display images in the typical RGB format. Instead, images need to be converted such that each pixel is one of the 7 available colours. This conversion is done using a Python script that reads an image file and uses the Pillow library to perform the necessary dithering and colour mapping steps.

Additionally, Aeon requires images to be in a specific format to be displayed correctly. The microcontroller does not have enough resources to decode image formats like JPEG, so the SLIC format was chosen. This is a small and simple image format that was expressly designed for use in memory constrained embedded systems, while still providing a reasonable compression ratio.

The provided script handles all the necessary image conversion steps. The generated .slc files can be copied to the /images directory on the SD card.

Evaluation

Aeon was designed to be a set-and-forget device, and I'm happy with how close it came to this ideal. However, there are a few limitations that should be noted.

Energy Harvesting

One of the main limitations is the energy harvesting capability of the device. Rather, this was very informative experiment that showed how little energy is available for harvesting from indoor light sources. Initial designs had solar panels on the front of the device, but due to the inability to harvest enough energy (and since they would be visible and unsightly), these front panels were removed.

The final design relies on the solar cells on the back of the device, which means the device must be placed somewhere that receives outdoor light every so often. The device can run for months on a single charge, but if left in a dark room for an extended period of time, it will eventually run out of power. Somewhere such as a windowsill would be ideal. Direct sunlight is not necessary, even indirect light from outside is sufficient to keep the device running.

Overall, I'm satisfied with the low power consumption of the device. The quiescent current consumption of the device is <10uA (possibly even lower, I don't have the equipment to measure this accurately), meaning if the refresh interval is increased to longer than 24 hours, the device could stay functioning for a very long time even without any light.

Display Hardware

The e-ink display that was used has a few limitations.

The display takes around 30 seconds to refresh, which is quite slow. This is not a huge issue for a device that is intended to be set-and-forget, but since it takes a full minute to clear the screen and display a new image, the power consumption for a refresh cycle is quite high (in comparison to a B/W e-ink display, which would only take a few seconds to refresh).

Additionally, I wasn't able to achieve the advertised 800x480 resolution. The provided example firmware for the display writes 400x480 pixels of data (pixels on the display appear to be twice as wide as they are tall). This cuts the effective resolution in half, on a display that is already quite low resolution for its size. Update: this issue has been fixed!

Lastly the colours of the display are quite muted. This is a limitation of the technology, however it does help the display appear more paper-like.

It would be interesting to create an equivalent device using a monochrome e-ink display, which have much better resolution and refresh speeds, given that they are a simpler and more mature display technology.

Final Thoughts

Aeon was a very fun project to work on, and I'm pretty happy with how it turned out. It gave me the opportunity to design a custom PCB, which was a great learning experience. Designing a power management system to target low quiescent current consumption was also quite interesting, I'm particularly looking forward to using the AEM10941 again in future projects.

The device is currently sitting on my windowsill, and I'm looking forward to seeing how long it will run for.

Links and Downloads

Firmware, Image Conversion Scripts, and PCB Design Files → GitHub Repository
Display Mask Template (A4) → aeon-display-mask-template.pdf
3D Design Files → aeon-frame-3d-design.step

Credits

The following resources were used in the creation of this project.

Software Credits

SLIC image format library by bitbank2

Image Credits

Introducing Confab Comments

Sat, 28 Dec 2024 00:00:00 GMT

In my very first blogpost, I mentioned that I would like to implement a comments section for this blog at some point, followed immediately by saying that I didn't have the greatest track record with completing projects; I didn't want to initially take on too much work (since I already had plans for other things that I wanted to tackle first).

Well, it was a smart idea... that I didn't stick to for very long. A week later, I made the first commit on the project that would end up being Confab Comments.

I've worked on Confab on and off for about a year and a half now, and (while still not completely production ready), it's at a stage now where I'd consider it to be generally feature-complete. For the small-scale site that the project is aimed at (like this blog), I think it has more than enough functionality for both users and administrators.

More information about the project is available on the website, and all the source code is available on GitHub (feel free to leave me a star while you're there 🙂). I've also made the effort to write up comprehensive documentation to hopefully make integrating Confab and using it effectively on your site as easy as possible.

A demo instance is available on the website, or you can try it out by leaving a comment right here on this blogpost!

GPS Clock

Wed, 24 Jul 2024 00:00:00 GMT

Introduction

I created this simple clock with a straightforward goal: I'd never have to set the time on it manually. Not when the battery ran out (it doesn't have a battery), not when daylight savings time started or stopped.

Time Source

Since I didn't want to set the time manually, I had a few options for the sources of time, including Wi-Fi and GPS. I ruled out Wi-Fi because I wanted the clock to be a reliable, self-contained device that isn't reliant on anything (such as a particular Wi-Fi network) that may be unavailable at times.

Since the many GPS satellite constellations going offline is quite unlikely, GPS is a better choice. Using this, I'd be able to power up the clock anywhere in the world and have it automatically grab the time accurately.

Electronics

For the display, I chose a 8x32 LED matrix display based on the MAX7219, and for the GPS module, I chose a cheap U-blox NEO-6M breakout module. For the microcontroller I went with an ESP8266 (Wemos D1 Mini) due to its compact size.

Quick note regarding the GPS module: I purchased this device for around $10, and for this price, it's almost definitely a fake. The quality is also slightly questionable: the breakout board contains a small coin-cell battery that is used to hot-start the NEO-6M by storing satellite information for a duration after power off, on the board I purchased, this battery was definitely not functional. This blogpost covers this issue of fake GPS modules, and how they likely have worse performance compared to genuine modules.

The only aspect of GPS performance that matters for this project is how quickly the module is able to get the first GPS fix (it displays a loading screen during this initial wait period). If you find that this period is too long (which might particularly be an issue if the clock is being used indoors away from windows where GPS signals will be weaker), you may want to spend a bit more on a genuine GPS module.

The clock also contains two pushbuttons which are used to adjust the display brightness.

These components should be connected together as shown in this schematic.

And this is what this simple circuit looks like when implemented.

Conclusion

After some extended use, this clock has been working great. Having a (non internet-connected) clock that keeps time perfectly, and automatically changes to match daylight savings time, feels a little bit magical.

If you're interested in building something similar, as always, all links and files are available below.

Links and Downloads

Purchase Links

MAX7219 8x32 LED Matrix → Aliexpress
NEO-6M Breakout Module → Aliexpress

Downloads

GPS Clock Enclosure → GPS-clock-front.stl, GPS-clock-back.stl, GPS-clock.step

LED Driver Design + Death Stranding Lamp Build

Sun, 21 Jul 2024 00:00:00 GMT

Introduction

Death Stranding is an action-adventure game with some intriguing story and lore. An integral part of this is the Odradek terrain scanner, a futuristic piece of sci-fi equipment that facilitates some core game mechanics. Besides this, it also looks really cool. So when I found this incredible Odradek lamp build on Printables, I knew I had to build my own.

Since the 3D model files have been provided by the original creator of the lamp above, in this blog post I'll be focusing on my custom electrical design for the lamp, which consists of dimmable warm/cool white LEDs, with additional support for IR remote control.

Electronics

One of my core goals from the start was that the lamp had to be dimmable, and had adjustable colour temperature. This led to me choosing a 24v dual warm/cool white LED strip as the light source. For simplicity, PWM control was chosen to control the brightness of each channel. I chose the Arduino Nano as the microcontroller (since extra features such as Wi-Fi was not necessary).

Based on these requirements, I designed the following schematic.

Read on for an explanation of each of the different sections of the schematic. For pictures of the final circuit implementation of this schematic, see below.

LED Driver

I used a pair of IRLZ44N N-channel logic level MOSFETs to drive each LED channel. I also decided to use a dedicated MOSFET gate driver IC, the MC34152, since I wanted to use a high PWM frequency for the best light quality when dimming (to prevent any visible flickering). This has the additional benefit of reducing switching losses in the MOSFET by minimising the time it spends in the saturation region for each switching cycle.

Using the maximum PWM frequency of the Arduino, 62.5kHz, the drain (CH1) and gate (CH2) waveforms of a MOSFET looks like this when switching the LEDs.

The ~67v voltage spike on the drain, which is caused by small stray inductances in the load, shows that the gate driver IC is doing it's job switching the MOSFET on and off very fast. The voltage spike should also pose no issues, as we can rely on the MOSFET's avalanche behaviour to clamp this voltage.

Additionally note that the MC34152 requires a decoupling capacitor placed close by to prevent instability in the supply rails. Since this IC is charging/discharging the MOSFET gates as fast as possible, it has large instantaneous current requirements.

Power Supply

I wanted the ability to power this device using USB C Power Delivery, which requires the 5-20V input to be boosted to 24V for the LEDs. Additionally, for the Arduino and the LED driver circuitry, a lower voltage level is necessary, so a small buck converter was used to get a 10V rail.

I would like to note that the power supply circuitry is non-ideal; the ON/OFF switch on the lamp doesn't actually disconnect power to the 24V boost converter, and the 10V buck converter being fed from the 24V boost converter output (which results in poor efficiency). This is because the use of USB C PD was a bit of an afterthought which required me to add the boost converter to the design to step up the USB C PD voltage. (The original plan was to use a dedicated 24V PSU.)

Brightness Control Inputs

I wanted to be able to set the light brightness using control knobs on the lamp, and also using a remote control (to control the lamp from a distance). For the control knobs, a pair of potentiometers were used, and to facilitate remote control, a simple IR receiver.

Sound 🔊

I decided to also add a buzzer to the design, which is always nice to include as it allows for the option of using sound to communicate information to the user.

Firmware

The firmware is available on this GitHub repo. I'll briefly cover the functionality here, but for detailed instructions on compiling and flashing this firmware yourself, see the readme file on the repo.

Overview

The main functionality of the firmware involves the Arduino continuously reading the potentiometer values and setting the PWM duty cycle for each LED channel based on this value.

The Arduino is also continuously waiting for signals from the IR remote control. When any IR code is received, the program switches from setting brightness from the potentiometers to instead using the data received from the remote control. In this mode, the brightness can be set independently of the value set on the potentiometers.

The input mode only switches back to the potentiometers if there is any change in the potentiometer inputs. This allows the lamp to be controlled using both the physical controls knobs and the remote control.

IR Functionality

The IR remote adds the following functionality:

Power on/off
Warm brightness up/down
Cool brightness up/down
Overall brightness up/down
Setting brightness presets

Setting presets utilises the buzzer to provide audible feedback when the lamp is waiting for the user to select a slot, and when a preset has been set successfully. Preset brightness values are stored on the Arduino's built-in EEPROM, so they persist between power cycles.

3D Model Modifications

Since my design includes a few extra features compared to the original lamp, I had to make a few modifications to the original 3D models. Each of these modified files can be found at the downloads section below.

Body enclosure left → New holes and mounting was required for the two brightness control potentiometers. Additionally, I used a smaller switch switch size of 15x10.5mm.
Eye front → I replaced the hole for the blue LED with a small mounting slot for the IR receiver

I also had to tweak tolerances on the desk mount to body joint part. You may have to also manually fix tolerances for certain parts depending on your 3D printer.

Assembly

The assembly of the lamp went relatively smoothly since it was quite well designed. I was mostly able to follow the assembly instructions provided by the original creator.

Here are a few tips for the assembly process:

The wiring channels to each of the light frames are quite small. Since I had to route 3 wires (Warm Anode, Cool Anode, Cathode), I used 0.4mm enamelled copper wire.
Using a soldering iron makes inserting the nuts into the printed parts a lot easier.
The tolerances on these parts are quite tight, so double check all your wiring before closing everything up.

Electronics Assembly

The driver circuit was implemented on perfboard (which was cut to size to fit inside the enclosure section of the lamp).

I used an old USB charging cable as the main power cable. I decided to repurpose the D+ and D- wires of the old cable to allow for reprogramming the Arduino Nano after closing everything up. As can be seen on the picture above, I desoldered the Mini USB connector from the Nano and soldered wires to the D+ and D- terminals.

The required reprogramming terminals (GND, D+, D-) can be accessed at this separate enclosure I designed to house the USB C PD trigger board.

Conclusion

The final product turned out quite good, I'm particularly happy with the remote brightness and colour temperature control. Additionally, using USB C PD as the power source means I have the flexibility of also powering the lamp with a portable charger when needed.

Once again, massive thanks to @NilsKal on Printables for providing the 3D design of this lamp and making this build possible.

Links and Downloads

Purchase Links

Warm/Cool White LED Strip → Aliexpress
Micro Buck Converter → Amazon or Aliexpress
Mini Boost Converter → Aliexpress
USB C PD Trigger Board → Aliexpress

Downloads

Modified Body Enclosure Left → body-left-modified.stl
Modified Eye Front → eye-front-modified.stl
USB C PD Trigger Board Enclosure → usb-pd-trigger-enclosure-top.stl, usb-pd-trigger-enclosure-bottom.stl, usb-pd-trigger-enclosure.step

Hardware I2C (and Pong) with FPGA

Sun, 07 Jul 2024 00:00:00 GMT

Introduction

FPGAs (Field Programmable Gate Arrays) are cool devices that contain internal logic elements that can be reconfigured using what's known as a Hardware Description Language. HDLs (such as Verilog, which I used for this project) may look like normal programming languages at first glance, but work in a completely different way, because you use HDLs to describe the actual hardware that you want your FPGA to configure to, which may be logic elements such as AND, OR, NOT gates, adders, etc.

In this blogpost, I will outline how I implemented hardware for I2C communication between a DE0-Nano FPGA and a ST7567S based 128x64 LCD display. Then I'll show how I used this implementation to play a basic game of Pong.

Planning

To keep things simple, I decided to maintain a 128x64 frame buffer on the FPGA. I would then be able to implement a module that repeatedly iterated over this frame buffer and send pixel data to the ST7567S over I2C.

This design would allow writes to the frame buffer without the need for any clock synchronisation with the module that handles the I2C communication. This should hopefully make it easier to optimise the I2C clock speed (hence, maximise the refresh rate of the display).

I2C Implementation

Again, to keep things simple, I skipped a full I2C implementation and instead went with only what was required to write data to the LCD. The ST7567S IC internally contains a DRAM frame buffer that supports both read and write. Since we are maintaining a frame buffer on the FPGA, reading from the LCD frame buffer is not necessary. So, we only need to implement a write I2C transaction.

Specifics of interfacing with the ST7567S over I2C is detailed in the datasheet (see Links section below).

Signalling

I2C consists of two open-drain connections, SDA and SCL. SCL is the clock, which in this case will only be driven by the FPGA, so SCL doesn't strictly need to be open-drain here.

However, SDA will be driven by both master and slave. So on the FPGA side, a tri-state buffer is required to output either a high-impedance state (Z) or a low state (0) on the SDA line. SDA will also need a pull-up resistor to 3.3V.

As such, the connections between the FPGA and LCD will look like this.

Transmitter Module

To keep things short, I won't cover the low level details of how I2C works (there are great resources available elsewhere). At a high level, the write I2C transaction consists of the following parts:

Start condition
Slave address
Receive ACK from ST7567S
Register address
Receive ACK from ST7567S
Data byte to save to register
Receive ACK from ST7567S
Stop condition

The I2C transmitter module (i2c_transmitter.v) has been implemented using a Finite State Machine (FSM). I found that a good starting point was to create one state for each part of the transaction above. I then added a few more states to handle the stop condition correctly.

Initialising LCD

With the I2C transmitter ready, the next step involves actually sending data to the LCD. Before we can start drawing anything to the display, the LCD has to be initialised. For this, a sequence of data is written to the LCD to reset it, configure LCD drive parameters, then enable the display. See the source code linked below for a full explanation of all static data that is sent during initialisation.

This static data is stored and sent to the I2C transmitter module from the i2c_data_static.v module. After this data transfer is complete, the init_complete flag is set, which switches the data source for the I2C transmitter from the static data to the frame buffer.

Frame Buffer Implementation

After the initialisation data is sent to the LCD, the frame_buffer.v module takes over to send data to the I2C transmitter. This module simply iterates through the frame buffer and continuously sends display data to the LCD.

Optimisations

To get the fastest update speed possible, I had to perform some optimisation on the main update cycle. Rather than setting the page (row of bytes) and column before sending each byte of data, the Read-modify-Write mode of the ST7567S was used, which auto-increments the column pointer when a byte is written. Additionally, incrementing the page number is only done when starting a new row.

With these optimisations, I was able to achieve a display refresh rate of ~14.7Hz, with a corresponding SCL frequency of 890KHz. This decently fast for I2C, and I was likely limited due to the wires and breadboard connections I was using for my test setup.

Further optimisation is still possible, as the ST7567S supports burst writes (writing multiple bytes in single transaction). Using this would allow for faster writes as the additional overhead of sending the start and stop condition would be removed. I decided against implementing burst writes for this small proof-of-concept project to keep things simple.

Pong! 🏓

With the frame buffer functional, I needed something to test the whole system. I chose to implement a basic version of the Pong game since it's quite simple.

The process.v module implements the game, which essentially involves moving through each column of 64 in the frame buffer, and for each column, setting bits to 1 where a paddle or the ball is found. This module can run at arbitrarily fast clock speeds in comparison to the I2C logic, as the frame buffer writes are independent of reads.

The user inputs to move the paddles are from four pushbuttons (with corresponding pull-down resistors) connected to four GPIOs on the FPGA.

Conclusion

That's it! Feel free to check out the Verilog source files in the Links section below.

Links and Downloads

Downloads

ST7567S Datasheet → ST7567S.pdf

Solis Solar Data Acquisition with ESPHome

Sun, 23 Jun 2024 00:00:00 GMT

Introduction

I recently had a solar system installed, which included a Solis S5-GR1P5K Inverter and a Solis-EPM1-5G Export Power Manager (EPM).

The inverter is responsible for the DC to AC mains step-up required to use the energy generated by the photovoltaic (PV) cells for grid-connected appliances in the house, and for backfeeding into the grid when there is an excess of generated power. The EPM is simply measuring the power flowing in/out of the house. This is necessary for consumption measurement, since the inverter only reports the power generation.

This system comes with a Wi-Fi adaptor that reports all generation/consumption data back to the manufacturer, Solis, who makes these available to the user through the SolisCloud App.

Naturally, I wanted direct access to this data to integrate it into Home Assistant. This would let me view live data on my own custom dashboards, and also maintain long-term statistics.

Why Not Use Solis API?

To get access to the raw data values, Solis does provide an API to pull this data from their servers. Someone has created a Home Assistant integration for this purpose, which works quite well. However, this solution comes with quite a few downsides.

Firstly, Solis asks you to sign an NDA and agree to T&Cs to get access to the API, which is an unnecessary hassle; you shouldn't need to sign anything away to get access to data that is generated by hardware that you paid for and own.

Secondly, the data ingestion rate for SolisCloud is every five minutes, meaning the max rate that you can get data for your PV system is quite slow.

Local Data Access

This entire project would not be necessary if Solis provided a local data access method so that we could query the PV system locally without having to go through their servers. Since this is not the case, I'll be detailing how we can do this ourselves to get the data we need directly from the PV system.

Hardware

The Solis inverter, EPM, and Wi-Fi adaptor communicates with each other using the RS485 protocol. The inverter and EPM have registers that the Wi-Fi adaptor reads/writes to using this protocol (to read data, or set certain settings on the inverter or EPM). Our task is to replace the functionality of the Wi-Fi adaptor with our own hardware.

For an extremely detailed reverse engineering of the original Solis Wi-Fi adaptor (plus additional details on what it takes to replace it), see this GitHub Repo. When I was working on my own implementation detailed here, this resource was an invaluable starting point.

The above repo provides information about reflashing the original Wi-Fi adaptor with ESPHome. This may be the best option if your solar system is outdoors, as the original device is weatherproof.

However, my installation is indoors, so I do not need it to be weatherproof. So I decided not to do this due to a couple of reasons: I wanted to keep my original Wi-Fi adaptor functional, and building a replacement was cheaper than buying a second one.

Electronics

The design of the replacement is quite simple. All we need is a RS485 (Modbus) to UART module (I used the HW-0519), and an ESP8266/ESP32 (I used the ESP32) to use as the ESPHome node. These are connected together, and also to the Modbus connector as shown.

The system here is powered by the 5V rail from the Modbus connector.

Connector and Enclosure

The RS485 connection is implemented in the Solis system using the Exceedconn EC04681-2014-BF connector. This can be purchased online, but doesn't seem to be available from first-party sellers, and third party sources (see purchase links) are quite expensive.

So, I instead modelled the connector and 3D printed it.

I printed this with a 0.4mm nozzle in TPU with, 0.12mm layer height, 0% infill and two outer wall layers. Since the connector is quite large, all the details present came through on the final print.

I also designed an enclosure that would hold the electronics. This should ideally printed in something more heat-resistant than PLA (e.g. PETG or ABS). The final implementation looks like this.

I stripped ~35mm of low gauge wire, pulled it through the connection holes in the 3D printed Modbus connector, then bent it around to the outside and hot-glued them inside the channels on the outer cylinder. These are the DIY contacts for the connector.

It's quite a janky solution, but since my installation has no weatherproofing requirements, it works without any issues.

Software

All the config files referenced here can be found on my fork of the original repo.

Base Config

I've made some modifications to the original base config to work with the ESP32, this can be found here. This config requires that you have a valid secrets.yaml file with the required values. You will additionally need to fill out the timezone string for your particular location.

Inverter and EPM Configs

The solis-modbus-inv.yaml and solis-modbus-epm.yaml files contain the specifics of communicating with the inverter and EPM respectively. These files should be placed in the paths specified in the packages section of the base config (esphome/common/ in this case).

The solis-modbus-inv.yaml file was forked from the previously referenced GitHub repo, with only minor changes.

I created the solis-modbus-epm.yaml file as the original author did not have a config for the EPM. This was created based on Solis RS485 protocol documentation (see below for download).

Limitations

The settings of the inverter and EPM can be changed over Modbus, however, I wasn't able to get this to reliably work for the inverter. Since I didn't require this functionality, I chose to remove these sections from my versions of the configs. See this GitHub issue for more information.

Additional Data Processing in Home Assistant

Outlier Rejection and Improved Power Resolution

While my own implementation has been working quite well over several months, I have noticed that occasionally some of the EPM values will go unrealistically high/low. This seems to be an issue with the data that is being returned by the EPM itself, so I've implemented some software filtering within Home Assistant to prevent these outliers flowing through to visualisations, etc.

Additionally, the power figures returned by the EPM have a maximum resolution of 100w. As a workaround to get better resolution, the voltage and current can be multiplied together to get the power.

Both of these fixes can be implemented as a template sensor:

# configuration.yaml

sensor:
  - platform: template
    sensors:
      solar_epm_power_a_high_res:
        friendly_name: "Solar EPM Power A High Res"
        device_class: power
        unit_of_measurement: W
        value_template: >
          {% if states('sensor.solar_epm_ac_i_a') | float <= 100 %}
            {{ (states('sensor.solar_epm_ac_i_a') | float * states('sensor.solar_epm_ac_v_a') | float) | round(-1) | int * (-1 if states('sensor.solar_epm_power_a') | int > 0 else 1) }}
          {% endif %}

Calculating Energy Consumption

A template sensor that monitors actual energy consumption can be implemented as follows:

# configuration.yaml

sensor:
  - platform: template
    sensors:
      solar_home_consumption:
        friendly_name: "Solar Home Consumption"
        device_class: power
        unit_of_measurement: W
        value_template: "{{ (states('sensor.solar_epm_power_a_high_res') | float + states('sensor.solar_active_power') | float(0)) | round(-1) | int }}"

Final Thoughts

That's it! After flashing the ESPHome config and plugging in the node, you should be able to access your Solis inverter and EPM data from Home Assistant.

Do note that since you will not be able to use the original Solis Wi-Fi stick concurrently with ESPHome, your solar production and consumption data will not be getting sent to Solis. This means the SolisCloud app will not work any more; if you need data visualisation, you will need to set this up yourself within Home Assistant. Additionally, you are now responsible for saving and backing up your own data. For long term storage I use InfluxDB.

Links and Downloads

Downloads

Modbus Port 3D Model → modbus_port.stl
Enclosure 3D Model → enclosure_p1.stl, enclosure_p2.stl
ESPHome Node Full Design (port + enclosure) → solis_esphome_node_full.step
Solis RS485 Docs → Solis_RS485.pdf

Purchase Links

HW-0519 RS485 to UART Module → Aliexpress
Exceedconn EC04681-2014-BF connector → eBay (third-party)

SV06 LED Lighting Fixture Mod

Sat, 10 Feb 2024 00:00:00 GMT

Introduction

Nice bright lighting for your 3D printer is almost necessary if you plan on doing any kind of timelapse of your prints. Lighting is also just useful when inspecting ongoing prints, or even just for taking glamour shots of your finished prints.

In this post, I'll show how I designed, installed and wired up this lighting setup for my Sovol SV06 3D printer.

If you're interested in installing this lighting fixture yourself, downloads and links, as always, can be found at the end of this post.

Design

To keep the electrical design minimal, I used LED strips which are rated for 24v, which is the same voltage as the printer power supply, meaning they can be wired directly to the printer's power supply without any additional circuitry.

Next, the physical design of the fixture. To get the best possible lighting, the fixture requires six separate parts. The first two parts are the mounts that slide snugly onto the z-axis gantry endcap of the printer.

The remaining four light 'sticks' can have LED strips glued onto them. Wiring channels are built-in, so that cable management is discrete. After the light sticks are slid into the mounts, cables can be managed at the back of the printer so they are less visible. Note that the two light sticks over the front of the printer have space for a double length LED strip section (~100mm), while the two rear light sticks only have a single length (~50mm).

Printing

Printing the mounts are very straightforward, and do not require any supports. They don't have any thermal requirements, and can be printed out in any material.

I tried a couple of orientations for printing the light sticks and found that the below is likely the fastest and uses the least support material. Don't forget to add supports.

These also need to be printed out in a material that has decent temperature resistance. I eventually ended up with PETG, but I did notice that there was some very minor warping with even PETG. I would recommend using ABS, if you are comfortable printing with this material. If you are having issues with warping, another option is to add some circuitry to run the LED strips at a lower voltage.

Installation

Firstly, prepare your LED strips by soldering adequate lengths of wires to them. For easier removal, I'd also recommend soldering male headers to the other ends of the wires (you can ignore polarities, since we can just flip connections as required).

Next, peel off the adhesive on the rear of the LED strips and stick them onto the flat sections of the light sticks. Then, route the wires through the channels and secure them in place with little dabs of hot glue.

Slide the mounts onto the z-axis gantry endcaps of the printer, then insert light sticks into the corresponding slots on the mount, making sure to guide the wire through the mount to the rear of the printer.

Preparing Power Supply

⚠ Warning ⚠ messing around with the power supply (PSU) can put you at risk of electrocution, or even turn your printer into a fire-hazard if you do the wiring incorrectly. Proceed at your own risk.

Disconnecting your printer from the wall, and disconnecting the yellow XT60 connector coming out of the PSU, remove the PSU from the printer frame by unscrewing the two screws. Carefully remove the protective cover over the front of the power supply by unscrewing the four additional screws. This will expose bare metal connectors. Do not unscrew the screw terminal that connects to the XT60 connector.

There should be a spare ground and +24v terminal that we can use for the lighting power. Unscrew each of these spare terminals, and screw in each wire of a female barrel jack connector. I highly recommend that you first prep the bare wire by soldering a spade connector onto it, so that the connection onto the screw terminal is secure.

You can now close the PSU back up, and screw it back onto the printer frame. Leave the female barrel plug extending outside the circular cutout on the bottom of the PSU cover. Don't forget to reconnect the yellow XT60 connector.

Wiring

Cut some wire to the required lengths to reach from the power supply to the right and left corners of the vertical gantry. On the ends that will connect to the light sticks, solder a couple of four female connectors, such that two light sticks can connect to the female connector set. On the side of the wire that connects to the power supply, solder a male barrel jack header. Cover any exposed wire with heat shrink or electrical tape.

Consult the wiring diagram below.

Once you have created your wiring harness, plug everything in and make sure all four light sticks work. Try reversing the connector direction on any light sticks that don't light up.

Cable Management

At this point you should have quite a few loose wires hanging everywhere. Let's neaten everything up. I designed the following inserts that can be printed out in TPU, then pressed into the aluminium extrusions that the SV06 frame is made from.

Guide loose pairs of wires into the channels on the aluminium inserts. Using some sort of long thin object, hold the loose wires against the sides on the inside of the channel. Gripping the TPU inserts with a pair of thin pliers, angle them and push them into the channel.

It might take a few tries to get the hang of, but once an insert is in, it should hold the wire securely inside the channel. The inserts can also slide along the channel, which makes adjusting the position of the wires very easy.

Final Thoughts

That's it! You should now have some nice lighting for your SV06 that lights up whenever the printer is powered on. If you want to turn off the lights, simply unplug the barrel jack coming out of the power supply.

Links and Downloads

Downloads

Light Fixture 3D Models All Files → SV06_light_fixture_stl.zip, SV06_light_fixture_step.zip
Light Fixture 3D Models
- Mount Left → SV06_lighting_mount_left.stl, SV06_lighting_mount_left.step
- Mount Right → SV06_lighting_mount_right.stl, SV06_lighting_mount_right.step
- Light Stick Left Front → SV06_lighting_stick_left_front.stl, SV06_lighting_stick_left_front.step
- Light Stick Left Back → SV06_lighting_stick_left_back.stl, SV06_lighting_stick_left_back.step
- Light Stick Right Front → SV06_lighting_stick_right_front.stl, SV06_lighting_stick_right_front.step
- Light Stick Right Back → SV06_lighting_stick_right_back.stl, SV06_lighting_stick_right_back.step
Channel Insert 3D Model → SV06_channel_insert.stl, SV06_channel_insert.step

Purchase Links

Led Strip 24v (these are just some examples, pick whichever LED strips work for you) → Amazon, Aliexpress

SV06 Klipper Input Shaping

Fri, 09 Feb 2024 00:00:00 GMT

Introduction

Input shaping/resonance compensation is the process that Klipper uses to minimise ringing/ghosting, which is a type of repeating artifact that appears on smooth surfaces of your prints, caused by the vibrations the printer creates as it moves (particularly as you start increasing print speeds).

To use input shaping with Klipper, you need to measure the resonance frequency of your printer. It's possible to do this manually, but it's a lot easier and reliable to use accelerometers to take these measurements for us instead. This post will go over this process.

For your reference, here is the Klipper documentation on measuring resonances.

Hardware

For most printers, only a single accelerometer is needed to measure both the X and Y axis. However, since the SV06 is a bed-slinger style printer, the extruder moves along the X axis, and the print bed moves along the Y axis. As such, it's necessary to use two accelerometers, one to measure each axis.

Using two accelerometers may pose some issues depending on the type of accelerometer that you use, as outlined in the Klipper docs. The documentation suggests connecting each accelerometer one at a time to do the measurements.

However, with a little creativity, you can get both accelerometers working simultaneously. The accelerometer I chose to use was the MPU6050, which uses the I2C bus to communicate. The RPi 3 (which is what I run my Klipper install on) does have a second I2C bus, but using it isn't as simple as the primary one. See this video if you are interested in going down this route.

Instead, the MPU6050 breakout boards that I used has an I2C Address Select pin (ADO), which, when pulled up to VCC, changes the I2C address of that accelerometer from 0x68 to 0x69. This lets us use both accelerometers on the same I2C bus.

Accelerometer Installation

Mounting

The next challenge is mounting the accelerometers to the extruder and the bed. My solution were the following mounts that can be 3D printed. Massive props to Sovol for making the SV06 Design Files available, which makes mods like this so much easier.

I recommend printing these parts in something like PETG rather than PLA, since they will be placed near heat-generating parts of the printer, and PLA might warp.

The MPU6050 boards screw into the mounts using M3 screws. The extruder mount is attached as follows, and secured using a cable tie.

The print bed accelerometer is mounted as follows. As shown in the second image, use a cable tie to secure the mount onto the post.

Warning: if you decide to keep the accelerometer wires installed permanently, they should be more securely cable managed.

Wiring

To wire I2C accelerometers to the RPi, Klipper documentation recommends using shielded ethernet cables.

The docs provide example wiring configurations for both two and three pair cables. Since ethernet cables typically come with four twisted pairs, I recommend the following configuration for optimal reliability.

3.3V+GND
SDA+GND
SCL+GND
GND+GND

Create a wiring harness by cutting an old ethernet cable to size. I decided to make my wiring harness removable by adding female headers to both ends. Both accelerometers can be wired in parallel (don't forget to connect the ADO pin of one accelerometer to VCC).

Connect the wires to their corresponding connection pins on the Raspberry Pi (see the pinout below). Make sure to temporarily (or permanently) secure the wiring harness such that all axes can move to their full extents without interference.

Configuring Accelerometers

Firstly, you need to enable I2C on your RPi. Follow this section of Klipper docs to achieve that. After a restart, you can check whether the accelerometers are being detected properly by running the following commands.

sudo apt-get install i2c-tools
i2cdetect -y 1

You should see that positions 0x68 and 0x69 each have a device. If not, try restarting again. If it still doesn't work, there may be something wrong with your connections.

The next step is to tell Klipper to use the RPi GPIO as a microcontroller (because you would typically connect the accelerometers to a MCU, which you would then connect to the RPi). Follow Klipper docs here to set that up.

The final step is to add the accelerometers to the printer.cfg file. If you mounted your accelerometers with the same orientations as me, the following can be copied verbatim. Just remember to change the address of whichever MPU6050 whose ADO pin you pulled up to VCC.

#printer.cfg

[mcu rpi]
serial: /tmp/klipper_host_mcu

[mpu9250 extruder]
i2c_mcu: rpi
i2c_bus: i2c.1
i2c_address: 104 # This MPU has pin AD0 pulled low
axes_map: -x, y, z

[mpu9250 bed]
i2c_mcu: rpi
i2c_bus: i2c.1
i2c_address: 105 # This MPU has pin AD0 pulled high
axes_map: y, x, z

[resonance_tester]
# Assuming the typical setup of the bed slinger printer
accel_chip_x: mpu9250 extruder
accel_chip_y: mpu9250 bed
probe_points:
    100, 100, 20

If you mounted your accelerometers differently, you will need to work out how the axes of the accelerometer map to axes of the printer, follow the config reference here to determine your axes_map.

Validating

Finally, check that Klipper can read the accelerometers by entering the following commands into the Mainsail console.

ACCELEROMETER_QUERY CHIP=extruder
ACCELEROMETER_QUERY CHIP=bed

If everything is working, you should see the accelerometer readings printed out to the console.

Running Resonance Measurements

Start by installing the additional software dependencies required for the resonance measurements.

Once everything is installed, Follow these instructions to run the resonance measurements. Following the instructions here the first time, you will generate some cool graphs using the resonance data that you measure.

A resonance frequency of ~55Hz can be clearly seen on my printer's x-axis vibration graph above.

On the y-axis graph, vibrations of the bed (y-axis) has seemingly resulted in vibrations on both the y and z axes. This could actually be the bed movement inducing vibrations in the z-axis, or it could be due to poor accelerometer mounting, stemming from a poor mount design. Regardless, the resonances on the y and z axes lie at around the same frequencies, so the input shaping algorithm should work fine.

On subsequent runs, you can just use the command SHAPER_CALIBRATE to run calibration procedure for both axes automatically. It's worth noting that you should only run this procedure when you make any changes to the physical design of the printer, or move it to a new location, etc. Running resonance measurements regularly is not recommended, vibrations at the printer's resonance frequencies can be damaging.

Links and Downloads

Downloads

Extruder Accelerometer Mount 3D Model → MPU6050_SV06_extruder_mount.stl, MPU6050_SV06_extruder_mount.step
Bed Accelerometer Mount 3D Model → MPU6050_SV06_bed_mount.stl, MPU6050_SV06_bed_mount.step

Purchase Links

MPU6050 Accelerometer Module → Amazon, Aliexpress

SV06 Klipper Install and Setup

Thu, 08 Feb 2024 00:00:00 GMT

Introduction

This post will provide an overview of the process of getting Klipper working on a Sovol SV06 3D printer. There are better and more detailed guides around the internet on how to do each individual step in this process, but when I was undertaking this process myself, I wasn't able to find a guide that pointed me to which steps I had to do exactly.

So I'm hoping this guide will serve as a jumping off point, so that you can gain a basic idea of how the Klipper ecosystem works, and which software components you will need to configure to get to a working Klipper setup.

Klipper

Klipper is a really powerful custom firmware for 3D printers. The SV06 runs a custom version of the Marlin Firmware, but Klipper is generally considered to be superior due to the faster potential print speeds Klipper unlocks.

Klipper achieves this faster speed in a few ways. Firstly, all the processing that is typically done by the microcontroller (MCU) onboard your printer's controller is offloaded to a (usually faster) external MCU/computer such as a Raspberry Pi.

Secondly, printing faster decreases the quality of your prints through issues such as ringing/ghosting (repeating patterns appearing on print due to vibrations of your printer at it's resonance frequency), and oozing as the extruder moves, and blobbing when printing corners. Klipper aims to mitigate these issues using resonance compensation and pressure advance. These links also explains the issues and solutions in more detail, if you are interested in further reading.

Overview

Klipper has two parts, the Klipper Firmware runs on the printer MCU, and Klipper Host runs on a connected computer (I used a Raspberry Pi 3). The Klipper Firmware on the printer is 'dumb', all the smart logic, including parsing the Gcode and calculating the corresponding stepper movements are done on the Klipper Host, and sent to the Klipper Firmware on the printer, whose primary job is to forward these basic instructions the stepper drivers on the printer control board.

The key here is that Klipper Firmware does minimal processing on it's own, even the logic that drives the user interface on the inbuilt printer display is handled by the connected Klipper Host.

Firmware Installation

There is a fantastic GitHub Repo containing some great information on the process of Klipper installation on the SV06. I found this to be a very useful resource when going through this process myself.

This repo explains the installation process very well, and will be maintained better than I can update this blog post in the future. As such, I'll mostly be linking to sections of that repo rather than restating the installation process here.

Flashing

The first step is replacing the Marlin firmware on the printer with the Klipper firmware.

Follow the flashing instructions here. Note that the repo states that some users have had issues using the Sovol included MicroSD card for the flashing process. However, I was able to use the included card for flashing both Klipper and the original firmware without any problems. Your mileage may vary.

The flashing process is reversible, you can always go back to the original firmware provided by Sovol. The flashing process is identical, just remember to rename the .bin file you're flashing, because a particular filename can only be flashed once.

Host Installation

I'll provide a brief guide here of preparing and installing Klipper Host software on a Raspberry Pi, since most guides don't supply this info.

Many guides for Klipper available for this step suggests installing specific OS builds such as OctoPi or MainsailOS. These can make getting started with their respective software easy, but any customisation beyond the use of the intended software can result in issues.

As such, I'd recommend going with a vanilla Raspbian install, and then installing your preferred software stack on top of this. Additionally, Raspbian has very good community support if you run into any issues.

OS Install

For this step, you will need the following:

Raspberry Pi
MicroSD Card (32 GB should be adequate)
PC with Raspberry Pi Imager installed

Using the Raspberry Pi Imager, first select Choose OS → Raspberry Pi OS (other) → Raspberry Pi OS Lite (64-bit is preferred). Then, select the SD card you want to flash to.

Next, go to Advanced Options (cog icon in bottom right corner). Set username to pi and enter a password for your user account. Enter your Wi-Fi credentials. Enable SSH, and ensure access is enabled using the user account password (only use password access for SSH if you plan on using the RPi on a trusted local network). Optionally, if you want to access the Pi at an address such as 3dprinter.local, enable this option by setting a hostname.

Confirming that everything looks ok, flash the SD Card.

Preparing Devices

Firstly, make sure that you have a quality power supply and cable for the Pi that meets the power requirements and can reliably power the Pi. You've probably seen this advice on other guides, but it's particularly important here because if the Pi randomly turns off during a print, your print will also stop (recovering from failed prints in Klipper is not an inbuilt feature, and is a very involved, imperfect process). Mainsail will show a warning if the RPi has encountered power issues since the last boot up.

Secondly, it's necessary to prepare the micro USB cable that you will be using to connect the Pi to the SV06. We do not want the +5v connection of the USB cable, so it's necessary to disconnect it. The easiest way is to cut a thin piece of electrical tape (approx. 3mm x 15mm), and stick it on the +5v pin on the USB A connector.

Configuring Raspberry Pi

Insert the flashed SD Card into the RPi, and plug it in. Now would also be a good time to plug in the printer cable. Wait for the RPi to boot, then connect to it via SSH (easiest way to find the RPi IP is to check your router's device list).

We will be installing Klipper using KIUAH. KIUAH will greatly simplify the install process for the various software components required. Follow the install instructions here to install and launch KIUAH.

Next, use KIUAH to install Klipper (Host software), Moonraker (API for Klipper Host), Mainsail (Web UI for your printer).

From here, return to the SV06 Klipper GitHub repository, and continue setting up Klipper from this step. Follow the steps on the repo to Download OSS Klipper Configuration (download the files Klipper Host needs to correctly talk to the Klipper Firmware and control the SV06), Adjust Configuration with MCU Path (show Klipper Host how to connect to your SV06), Configure Your Printer (run calibrations and prepare your SV06 for printing) and Adjust Your Slicer (set the start and end Gcode that your slicer generates to work properly with Klipper).

After following these steps, you should hopefully have a working Klipper install. Mainsail, which is the web interface you will use to manage your printer, should be accessible at http://<ip of your RPi> (or something similar to http://3dprinter.local, if you set up a hostname previously).

Webcam

A webcam is super useful to monitor your printer remotely. I had an old laptop lying around and I was able to convert its built-in webcam to USB. Here's a great tutorial by DIY Perks on how to do this. My webcam was 3.3v, so I had to use a 3.3v regulator and some capacitors to drop the USB 5v down to 3.3v.

Once you have a webcam connected, run KIUAH again, and install Crowsnest (management software for webcams). If you have a camera attatched, the default configuration will start the stream automatically. For further configuration of camera settings, see here.

To add the webcam to the Mainsail interface, follow the instructions here. The default Crowsnest stream URL for your first webcam is /webcam/?action=stream.

Summary and Final Thoughts

My experience using Klipper has been generally excellent. After I performed all the tuning and calibration, things were really great. I was able to push print speeds higher than I had been able to with stock firmware. My prints were completing faster, with only a minimal drop on quality, thanks to input shaping and pressure advance.

I initially ran into a significant issue where the printer was randomly disconnecting from the RPi in the middle of print. Using dmesg, I found the error ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32. I tried several things to try to fix this, including double checking power supply to the RPi, changing cables to the printer, etc. I even ended up going back to the stock firmware.

But once you've used Klipper and experienced things like print speeds that consistently outperform the slicer estimates, it's really hard to go back. So I gave Klipper another try, this time using a different MicroSD card. To my surprise, this seems to have solved all my reliability issues.

Update: This did not in fact solve my reliability issues. See USB Reliability Update section below.

Next Steps

Now that you have Klipper installed, consider getting input shaping working to improve the quality of faster prints.

With Klipper you can save time and send Gcode to the printer directly from your slicer. Look into Klipper/Moonraker integrations for your slicer, here is the one for Cura (GitHub). Info for other slicers is available on the Klipper docs.

If you use Home Assistant, there is a Klipper integration that will let you use data about your printer for your automations.

Klipper also has other quality of life features. I've connected my printer to a smart plug, which automatically turns on the printer when I send a Gcode file, see Klipper docs and Moonraker docs for more info on how to do this. You could set up a Home Assistant automation to automatically turn off the smart plug after a print is complete to save on electricity.

Why not 3D print a case for your Raspberry Pi and mount it directly onto the printer? I 3D printed this sleeve case for my RPi and mounted it just above the control box using cable ties.

Now that you've got a full linux computer strapped onto your printer, the possibilities are endless.

USB Reliability Update (July 06)

After using this Klipper setup for a while, I noticed that the random printer disconnections with error ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 had not stopped. I initially assumed that this was caused by an unreliable SD card, so I attempted to solve this by switching to an SSD boot drive. However, this did not solve the issue.

I then found that others also seem to be having this issue with similar setups involving connections between a RPi and USB to UART ICs similar to the CH340G found in the SV06.

I decided to bypass the CH340G IC altogether and use the UART interface directly built into the RPi. This involved opening up the SV06 controller and soldering two wires like this.

Required connections:

CH340G Pin 2 (TX) → RPi GPIO14 (UART TX)
CH340G Pin 3 (RX) → RPi GPIO15 (UART RX)
GND → RPi GND

Some software configuration is necessary to get the UART interface operational on the RPi side, see this guide and RPi documentation. I followed additional steps to get the better performance PL011 UART working on GPIO14/15 of my RPi 3B.

Getting Klipper to use the RPi's UART interface is as easy as replacing the connection line in printer.cfg with serial: /dev/serial0.

After this modification, the connection between the RPi and the printer has been rock solid, no more random disconnects during prints.

Samsung S5 Dummy Battery

Sun, 23 Jul 2023 00:00:00 GMT

Motivation

The Samsung Galaxy S5 was my first flagship smartphone. It was an impressive piece of technology for it's time, but it's been almost a decade since launching in 2014, and my S5 has spent quite a few years in a dusty drawer somewhere.

Reusing old tech is always nice because, best case, the energy used for recycling is conserved, or worst case, it stays out of landfill.

Introduction

Old phones can be used to make security cameras, home automation displays, etc. Smartphones are particularly useful because they are small, energy efficient computers attached to a whole suite of sensors.

One issue with running an old phone in a scenario like this where they would be plugged in 24/7, is the battery. Exposing Lithium batteries to heat over long periods usually causes them to swell up. In a tethered scenario, it's pretty likely you'd be doing something at least moderately computationally intensive, such as recording and broadcasting video, so heat is usually expected.

Since the phone will always be tethered, there is no real need for a battery. Unfortunately, most phones will not boot without a battery. This is probably for good reason, because the phone may sometimes draw more power than the USB charging port is able to provide.

Design Decisions

Battery Circuitry

Opening up the rear cover of the S5, we can remove the battery.

There are four contacts on the battery, with positive and negative labelled clearly. I'm not certain what the other two contacts of the battery are for (at least one of them is used for the NFC coil integrated into the battery). We do, however, need the connector between positive and negative. To summarise, here are the pins that we need to emulate the battery.

A 10kΩ resistor needs to be connected between the centre pin and the negative terminal, the phone will not boot properly without this resistor. Other resistor values may also work.

Voltage Source

The battery here is Lithium-ion, so we need a voltage in the range of 3.7v and 4.2v. To power the phone, we will need an external power adapter. However, an external power adapter that you can buy off the shelf will likely have voltages higher than 4.2v.

To deal with this, we will need to use a buck (step-down) DC-DC converter. To keep things nice and compact, I used a micro buck converter (purchase links below) that is small enough to directly integrate into the dummy battery structure that we will design next.

Dummy Battery Design

I 3D modelled the dummy battery in Fusion 360.

The dummy contacts will be 3 male pin headers, which can be pushed into position on the dummy battery after printing. I've also included some area on the design to fit the buck converter and circuit wires.

The next step is to 3D print the model. Since the dummy battery will be exposed to relatively high temperatures by the phone SOC and the buck converter, avoid printing this with PLA, use something more heat resistant such as PETG or ABS instead. I made the mistake of using PLA for my first version, and after a few days of use, the dummy battery was warped (which you can see on the images of the blue 3D print below), and the pins weren't making contact properly.

Assembly

Here is the diagram for the circuit that we need to build.

I would recommend wiring up and testing the circuit beforehand. Don't forget to adjust the buck converter potentiometer until you have a voltage of ~4.2v on the output. Check that your circuit can reliably power the phone without causing brownouts (the camera app is a good way to test high current draw).

Soldering can be a little bit tricky, particularly for the male headers. These need to have wires soldered in a very specific way to make sure that the header can still be inserted into the slot on the 3D print, and such that the wires or solder don't intersect with the backstop. The backstop was added to prevent the header pins from sliding back

It's a good idea to solder with wires longer than you need, then trim to size later.

Here is what this circuit looks like assembled.

Final Notes

Supply Voltage

The buck converter used here should be able to step-down voltages between 6v and 24v. However, the converter will be less efficient at higher voltages, which results in higher temperatures. My buck converter reached ~75°C in open air when supplied with 24v during testing.

To avoid heat becoming an issue, choosing a supply voltage of around 12v should be optimal. Be careful choosing lower supply voltages such as 5v, as the voltage drop along longer power cables is sometimes enough to cause a brownout on the phone.

Also don't forget to make sure that the power supply you use can provide 15-20w of power, since the phone can have current spikes as high as 3A at 4.2v.

Deployment

After slotting in the dummy battery, the external power wire will likely mean that the rear cover of the phone will not go back on. This wasn't a deal breaker for me personally, because I used a case over the phone, and I routed the power wire around the side of the phone.

Links and Downloads

Downloads

Dummy Battery 3D model → dummy_battery.stl, dummy_battery.step

Purchase Links

Micro Buck Converter → Amazon or Aliexpress

Hello, World!

Sat, 22 Jul 2023 00:00:00 GMT

Hi! 😄

insert newline is a blog. I'm creating this site as a way to document my projects and adventures. These may involve stuff like programming, electronics, 3D design, etc.

This blog is very bare-bones at the moment, I've only spent a few days working on this, and most of the development time was spent attempting to make a nice reading experience for the blogposts.

I have ideas for additional functionality (such as blogpost comments) that I'd like to implement at some point, but I tend to start projects with too wide of a scope, so I'm trying to do this a bit differently by starting small.

In the mean time, if you would like to contact me, feel free to reach out anytime!