Blog

Real-Time Visual Synth Driven by RP2350

January 13, 2026

RP2350 is the dual-core microcontroller at the heart of Raspberry Pi Pico 2 boards. Although the RP2350 has two identical Arm Cortex-M33 cores, it is usually programmed in an asymmetric multiprocessing (AMP) style, which doesn’t provide a shared task scheduler (e.g. a la FreeRTOS SMP). It’s still simple to divide and pin different tasks onto either core and use the two fast hardware FIFOs for inter-core communications.

Recently, I acquired a 1.3” 240x240 LCD made especially for Raspberry Pi Picos. It can be attached directly to the board pins, where the command and data signals are sent to its ST7789VW control chip via SPI and the joystick and 4 button inputs are received via 9 GPIO pins. This provided a chance to test how far I can push the microcontroller in creating a real-time visual synthesizer.

With help from generative AI, I created a “plasma effect”, which is generated by combining several sine waves over a 2D grid and animating them over time. The rendering happens using a single frame buffer. For each pixel, its coordinates and distance from the center are fed into sine functions, and the results are added up to create smooth interference patterns. A time parameter continuously shifts the phases of these waves, making the pattern flow and evolve. Another phase offset is used to cycle through colours for an extra ethereal feel. I programmed the joystick to shift the colour phase and change the animation speed, and the 4 buttons to switch between 4 presets for plasma parameters.

The visual synth demo on LCD

You can find the source code on GitHub. The LCD vendor provides a C SDK shared between multiple products. I extracted the part specific to my display and changed it to use a 240x240 frame buffer for rendering, before sending every frame to the display.

At first, I used a single core to render each frame in memory and then send the entire frame via blocking SPI. The rendering uses floating point calculations, which are expensive, even with RP2350’s single-precision FPU. I didn’t make any attempts at optimizing the rendering code itself (except creating a sine look-up table upfront), as I was curious how much faster/smoother the animation can get if the tasks of rendering and driving the display are divided between the two cores. The rendering represents any CPU-heavy graphical calculations.

The single-core demo got me to a measly 3.3 FPS, which is too choppy and unacceptable even to a non-gamer! I then separated rendering and writing into the display to run in parallel between the two cores. Once the frame is ready, the renderer sends a signal to the display core to shovel the data out. Typically, writing into and reading from the same frame buffer could create “tearing” glitches, but with the relatively slow-moving and flowy animation, it wasn’t an issue. The dual-core demo reached 5.5 FPS, which feels more like an animation even if it’s still choppy.

To further play around with my Pico, I could be using Direct Memory Access (DMA) or Pico’s unique Programmable I/O (PIO) to speed up the display driver. Currently, the renderer is much slower than the driver (equivalent to 8.5 FPS), so even using CPU-free solutions to move pixels won’t be enough to speed up the animation. Perhaps splitting the rendering into the 2 cores to run in parallel could help, but we’re then gradually getting into why GPUs exist in the first place!

Sonar-Powered Creepy Halloween Ghost

December 02, 2025

I recently bought a Raspberry Pi Pico W, which comes with a Bluetooth module, along with an HC-SR04 ultrasonic rangefinder. I wanted to hide it inside Halloween decorations and program it to make a creepy ghost sound that intensified as my child’s Halloween party guests approached it. The children might have already aged out of being scared by it, but it was a technical success after all. I’m sharing the source code and some of the details here.

The ultrasonic rangefinder works by emitting high-frequency sound pulses and measuring how long it takes the echos to return from nearby objects. The emission and measurement has to be manually driven by the microcontroller. The microcontroller’s job is to measure the distance regularly and if someone is standing within the range, produce a creepy ghost sound; a sine wave within 300-600 Hz with some extra low-frequency modulation to give it a “breathing” effect.

Circuitry

The rangefinder requires 5V and Ground that could be easily obtained from Pico’s VBUS and GND pins. Its TRIG pin, to drive wave emissions, can be controlled by a regular GPIO pin (GP2) as 3.3V is enough, but its ECHO pin outputs 5V. In order to prevent the rangefinder from frying the board by sending 5V into the receiving GPIO pin (GP3), I use a simple voltage divider using a 10K and a 15K ohm resistors. ECHO is separated from GP3 by 10k ohm, which is in turn pulled down to GND by 15k ohm. This brings down the voltage to about 3V, which reliably registers as high for a GPIO pin.

There isn’t anything else to the circuit besides powering the board via USB.

The circuit on a breadboard

Source code

Instead of using the standard C/C++ SDK, I opted for Arduino-Pico v5.3.0. You can still program the board in C++ (Arduino styled), but it comes with a convenient Bluetooth driver and the IDE makes debugging via the serial port simpler. The entire source code is inside a single file.

The setup defines the I/O pins and makes a connection to the Bluetooth speaker as an A2DPSource. For connection to the Bluetooth speaker, I specified my speaker’s MAC address for reliability and simplicity. The main loop is in charge of driving the rangefinder and calculating and streaming the ghost sound, so to keep it tight and performant, I pre-calculate the sine function for 256 values (with linear interpolation between them) during the setup and store them in a look-up table.

The main loop polls the ultrasonic sensor by sending a 10-15 micro-second TRIG pulse and measuring how long the ECHO pin stays high. From this round-trip time, I compute the distance. The results are surprisingly accurate. If an object is within the range (15-150 cm), it starts generating a sine wave, whose frequency (300 to 900 Hz) and amplitude are a function of distance. This creates the illusion that the “ghost” is screaming harder as you get closer. As the pure sine wave can sound a bit artificial, I add a low-frequency oscillator to the mix. I maintain two separate phase accumulators; one for the main tone and one for the modulation, and read both from the lookup table. I apply smoothing and clamping functions to avoid clicks or harsh transitions. This is the part where generative AI and a few iterations helped me get the best results.

The audio output is then calculated at the sample rate of 48KHz. The left and right channels have the same value (mono) and I use a 2048-frame buffer for streaming the audio via Bluetooth. Raspberry Pi Pico is not exactly a high-performance microcontroller, but it could handle driving the sonar sensor and Bluetooth streaming in the same loop with occasional buffer underrun (resulting in clicks). To avoid that, the second core could be used to separate the sensing and streaming tasks, and ensuring the streaming takes priority over sensing (no major change in distance is expected anyway).

Serverless Photo-Sharing App Using Amazon Web Services

March 10, 2017

As the self-appointed IT director of my new family, I was tasked with finding the best solution to easily upload, back up, and share pictures and videos of our newborn daughter. While there are a myriad of cloud services that a normal person would go for, I didn’t want to rely on them to safeguard our most precious moments. To be honest, I was also itching to create a serverless app on AWS, without committing to much cost or maintenance overhead.

AWS has a host of relatively cheap services that makes creating small serverless apps easy. The JavaScript API allows you to keep most of the logic in your browser, where you can access AWS directly or through a proxy (e.g. API Gateway). I’ll explain how I used them:

  • Cognito for authentication: The main users of this app were my family and friends, so I only had to worry about unintended mistakes as opposed to malicious abuse. This allowed me to create pre-defined users for different roles (e.g. admin and visitor), and use Cognito to authenticate them. The JavaScript API lets you safely hard-code the public codes in the web page, and log in using a password only.

  • IAM for authorization: Once users are authenticated, IAM should give them minimal privileges to do their tasks. For example, I gave file upload access to admin users, but only read access to visitors. The Principle of Least Privilege prevents users from wreaking havoc. IAM didn’t have the finest-grained access levels, but for a trusted set of users, that should be good enough. For more flexibility in authorization, of course, it has to be done on a proxy or web server.

  • S3 for storage: Amazon’s simple storage is truly simple to use. I used it to store media files, thumbnails, and the static website assets. You may make the static site public, but put media files behind Cognito. The nice thing about S3+Cognito is that you can use the Cognito token in the S3 URL and access it in your website as you normally would with hosted images.

  • DynamoDB for database: The list of galleries and files, timestamps, captions, user access, and comments have to be stored somewhere. While S3 provides limited ability to store metadata for each file, the permanently-free tier of DynamoDB has enough capacity to store them in a few tables. The NoSQL (or rather schemaless) nature of the database makes it easy to quickly add new features.

  • Lambda for processing: A serverless architecture will not be complete without a function-as-a-service component! In this case, I used a S3-triggered function to create an entry in the database and process newly-uploaded images and videos. It could do anything as simple as generating thumbnails (Lambda is pre-packed with ImageMagick), or dealing with EXIF idiosyncrasies.

As for front-end, there wasn’t much needed for this app. Besides the good ol’ AWS JavaScript API, I used Bootstrap for easy styling, Knockout for two-way data binding, and Unite Gallery for media viewer. Unite Gallery is an open-source library with a few available themes and easy setup. However, getting videos to play on mobile and JPEG EXIF orientation proved to be challenging.

If I found time to improve the app, these areas would come up next:

  • CloudFormation: As of now, most of the configuration has been manually done and its persistence is at the mercy of AWS. I can use CloudFormation to formulate how everything was set up, so it can be retrieved if anything goes wrong. Amazon provides CloudFormer to create a template from an existing architecture, but it didn’t cover the bulk of my configuration around Cognito and security policies.

  • Automatic rotation: not all browsers can show the right orientation of cellphone images based on their metadata. I can use a Lambda function to automatically rotate images based on their EXIF orientation field.

  • API Gateway: Using the combination of API Gateway and Lambda, there would be no need to give users direct access to AWS resources. This will improve the security and may make the app useful for other people who can have a more serious use case for it.

  • Backup: A scheduled task that backs up media files and database records and writes them onto cheaper storage (e.g. AWS Glacier). For a more paranoid approach, I can also store them on another cloud service provider such as Google Cloud.

I’d be happy to get feedback on the design, and ways to improve the architecture.

Chilkoot Trail: The World's Longest Museum

August 08, 2016

Chilkoot Trail, a 53-km trail from Dyea, Alaska to Bennett, BC, was the main way for gold rush prospectors in late 1890s to get to Klondike River in Yukon. This slideshow contains photos of my 5-day hike through this historic trail.

Day 0: I fly to Whitehorse, Yukon where the group will get together the day after to drive to the trailhead. I have some time to explore the city.
The world's largest wind vane at the Yukon Transportation Museum. The wind is blowing eastward.
Whitehorse in Arabic letters
A common mode of transport in the old days, used by Royal Mail.
SS Klondike was the largest ship that operated on Yukon River
SS Klondike's engine room
SS Klondike's kitchen
"Gold! Gold! Gold! Gold!" An old newspaper from Seattle shows how the gold rush started. When a large shipping of gold from Yukon arrived in the US, media started creating hype, and people desperate from the economic downturn swarmed towards Yukon to get a piece of that pie. Little did they know how brutal the winter conditions are, and how little gold they can claim after the news was already out.
Gold rush prospectors had to carry a huge amount of luggage with them. After arriving in Alaska, they had to take Chilkoot trail, and after reaching Bennett Lake, they could use Yukon River for rafting up to Dawson City (gold fields). Pictured is the 45-degree-sloped Chilkoot Pass which was the most difficult part of the trail. The Canadian police was stationed at the top of the pass.
Day 1: all packed up and ready to hit the trail. First we need to drive to Alaska for the trailhead.
Emerald Lake gives a preview of how the last part of the trail will look like.
Fireweed is Yukon's flower (their official floral emblem)
The road to Skagway, Alaska goes through White Pass, which was another major way during the gold rush. The railway on the less-steep White Pass made Chilkoot Trail obsolete in 1899.
This is how much "teeth" a train needs in order to carve through snow
Skagway, Alaska. After the gold rush, people's major occupation here was trapping animals. They now trap cruise ship tourists.
After watching a short movie about how to avoid or possibly fight bears, we take a short drive to Dyea, Alaska. The sunny weather at the trailhead is promising.
Beaver-created ponds. The first part of the trail is mostly swamps in a coastal rain forest. We have to keep making a lot of noise to scare the bears away.
Finnegan's Point is where we stop for the first night. It's after 10PM, and the sun has set behind the glacier across Taiya River.
All food, fuel, toiletry, and pretty much anything that smells has to go inside the bear cache, which is at least 50 meters away from the tents.
Day 2: It's still sunny and we are still in the rain forest. This means a lot of mosquito bites. The trail permit hanging from each hiker's backpack shows we are one of 50 people that are allowed on the trail at the same time.
Devil's Club. Not so fun to whack to find your way through.
We only had to carry around 1 litre of water at a time. Fresh streams provided a reliable source of water throughout the trail.
Making your clothes wet could mean hypothermia at night. These finicky bridges can have up to one person at a time, but they mean no need to cross the river and risk getting wet.
Old baking oven in Canyon City. This city used to have thousands of people with shops and restaurants. It existed for about two years only and then was deserted.
Large boiler in Canyon City that powered the tramway. Only the richest prospectors would pay to use the trams.
Can you spot the old telegram cable?
Stove in a shelter to warm up
Our tour guide provides warm gourmet camping food. Priceless!
The second night at Sheep Camp has rain in the forecast. Time to pitch the tent tightly to avoid getting wet.
Day 3: This is the big day when we have to take the steep slopes, and to add insult to the injury, it starts raining. Leaving the camp at around 6am, we are pretty miserable.
The silver lining is that rain and fog make for good pictures. We are now exiting the rain forest and going above the tree line.
The old tram station at the top of the cliff.
The Scales: the Canadian government required gold rush prospectors to bring enough necessities to survive in the brutal winter of Yukon. The supply checklist includes items such as 150 pounds of bacon and 5 yards of mosquito nets. These scales were used to ensure the 1-ton supply is up to par.
This is where the Chilkoot Pass or "golden stairs" starts. The steep slope and grave winter conditions killed many people and horses. Their bones are scattered around the trail.
The Golden Stairs: this is the most difficult part of the trail, and the rain made it more dangerous. The top of the stairs is only a false summit; there are two more stretches of stairs left after that.
Snow patch and rain make for a fun slide, even if you don't intend to.
At the top of the stairs, on the US side of the trail, there's a monument to commemorate gold rush prospectors.
This is it; the summit! We are in Canada now and we get to go to the small warming hut to escape rain and gusting winds. We meet the Canadian warden who has worked there for decades. Time-wise, we're only halfway through the third day, but the psychological sense of achievement makes you forget that.
After the summit, we have a long trek through the Alpine tundra zone of the trail.
Wild flowers carpet the kilometer-high plains
After 10.5 hours we reach the aptly-named Happy Camp with the first sight of the washrooms. Probably one of the most scenic outhouse locations!
Didn't know a warm Lipton soup in a cup could feel so good!
Hanging wet gear to dry overnight
Having put warm and dry clothes on, we go to our tents for the third night of the hike.
Day 4: today is a rather short day to rest our bodies. We get the last view of "river beauties" before we exit the alpine zone.
It's called Long Lake. Isn't it?
Deep Lake. Glacial water and the sediments make interesting hues of colour.
We are now entering the Boreal forests. There are lots of evergreen trees and lakes.
The remains of a boat. After crossing the Chilkoot pass, prospectors started building boats to use lakes and rivers to carry their 1-ton supplies. Needless to say, they only worked for a few months of the year.
The lakes turn into rapids in canyons. Many people died in this canyon, trying to haul their supplies on an unprofessionally-made boat.
We meet a porcupine (far away on the trail). This is not bad considering we won't likely see any large animals. They're usually scared away from big groups of people.
We finally arrive at Lindeman Lake.
The sandy beach and the turquoise colour reminds you of Caribbean climate. The temperature disagrees.
This shelter is at the former location of Lindeman City at the shore of Lindeman Lake. It was a huge tent city to serve gold rush prospectors, and at its peak, its population reached more than 10,000 people.
The Lindeman Camp was closed a couple of weeks before us, because of a bear attack. Luckily only properties were damaged, but the two involved bears were shot to death.
An old first-nation cemetery.
Day 5: Our last day is another 12 km from Lindeman Lake to Bennett Lake. Our trek in the Boreal forest goes along many lakes. Pictured is Bare Loon Lake. We can hear loons around the lake, but I cannot see any.
As per our tour guide, this little lake is ideal for a family of elks to call home.
We don't see any elks, but the droppings are a telltale sign of their presence.
A small trapper's hut. The roof is adorned with bones of humans and animals.
If the trail wasn't diverse enough, we now have to cross sand fields. It looks like a desert.
Lo and behold: here's Bennett Lake. Bennett itself is still meters away, but it doesn't mean you can't take a triumphant picture.
Distances between campsites and landmarks if you start from the Canadian side.
This church is the only standing building from the gold rush times. It's only a shell so no one can enter.
Bennett Train Station. This is part of the old White Pass railway. Trains still operate here, but only for tourists. Since Bennett has no road access, this is a common way for hikers to get back to civilization.
A White Pass railway worker carrying supplies around. He doesn't know how old that car is, but it still runs fine.
To end the hike on a high note, we're skipping the train and instead taking a float plane.
The pilot gives us the usual safety lecture. "The red lever opens the door, but please don't do it during the flight"
The plane takes off pretty close to the trees.
A river snaking along
The river has changed course many times and has created such beautiful shapes
View of suburban Whitehorse along the Alaska Highway. This highway was created during World War II to connect Alaska to the rest of US.
Finally, downtown Whitehorse is in sight. The plane gets ready to land on a nearby lake.
The hike concludes with receiving a certificate. It shows an old picture of prospectors taking the golden stairs.


Slideshow plugin by Pixedelic.

If you liked this, you may also like my Iceland Trip post.

JavaScript Online: hosting a static site cheaply and effortlessly

May 12, 2016

A friend of mine was trying to get hired as a software developer, so he asked me about resources to hone his skills and practice for programming interviews. I came across a few websites where you could solve programming puzzles online. Your code would be sent to a server to run in a sandboxed container, and you would shortly get the result. My friend was specifically learning JavaScript. That made me wonder how cheaply and effortlessly I can create and maintain a similar site for JavaScript only.

The most expensive parts of hosting are usually tied to the computing power of servers. No server can beat the increasingly cheap option of not having a server at all. If your website can work with static resources, you can store everything you need on a storage service, configure your domain, spend a few cents a month, and never have to break a sweat about how your website is running. But how much can you accomplish with a static website?

In the case of an online JavaScript practice service, you can get away with not having a server for many things:

  • Core: The core of your service, running users’ code, can be delegated to their browsers. For this, web workers are a great feature that cleanly isolate potentially harmful code, and are supported in modern browsers.
  • Assets: All assets on landing pages, blog posts, and other informational pages are static.
  • Security: Users can see how you are running their code, see your test data for programming problems, and reverse-engineer them. In this case, let’s agree, it is actually serving the purpose of teaching JavaScript.
  • Personalization: Local Storage can be used to store the history of their problem-solving. This doesn’t survive a browser data deletion or moving to another device, but oh well!
  • Community and Engagement: I haven’t added any feature of such nature yet, but there are free or cheap services like Disqus or SumoMe that can add comments or email collection widgets to your static page. I’m not aware of any service for a leaderboard, but I’m sure if the site becomes popular enough, I can roll my own AWS Lambda script to take care of that.

In order to create the site, I’m using a Node.js script. Jade templating engine, Markdown language, Uglify-js, and Express.js for a local test server have come in very handy. I’ve written an automated build script, where I only need to add a single JSON file for every problem, and it creates the whole page, adds it to the index and sitemap, and deploys new or updated files to Google Cloud Storage. Google Cloud Storage makes it easy to host a static website, but it doesn’t support HTTPS yet. I’m using Cloudflare’s free plan to add HTTPS, server-side analytics, a caching layer, denial-of-service protection, and even a widget to show warnings if a browser is not supported.

I might open-source this in the future, but for now, feel free to practice JavaScript online for fun or technical interviews!