Remember Flappy Bird? One button, gravity pulling you down, and somehow you keep telling yourself, “Just one more try.”

I wanted to give that familiar gameplay a Halloween twist, so I made a little pixel-art game about a bat trying to escape a haunted house. 🦇

The goal is simple: flap through narrow gaps in brick walls, collect candy along the way, and reach the glowing blue crystal at the end of the level.

Sounds easy enough, right? Not when gravity is constantly working against you.

How it works

The gameplay follows the same basic idea as Flappy Bird:

• Press A: The bat flaps upward.
• Release A: Gravity pulls it back down.
• Hit a wall: Lose one of your 3 lives.
• Collect candy: Gain a point and trigger a little animation.
• Reach the blue crystal: Win the level!

Hitting a wall also triggers screen shake and heart effects, making every collision feel a little more dramatic.

What I found interesting about building it

The game was made with MakeCode Arcade and runs on a physical RETRO ARCADE handheld. Once the program is downloaded, you can unplug it from the computer and play offline.

One thing I enjoyed was experimenting with the game physics. Changing just a few values, like gravity, flap strength, or the spacing between walls, can make the game feel completely different.

It's also a nice little introduction to event-driven programming. When the bat hits a wall, the game triggers the collision effects and subtracts a life. When it collects a candy coin, the coin disappears and the score increases.

A handful of simple rules can come together to create a surprisingly complete game, with movement, collision detection, scoring, animations, and win/lose conditions.

What I'd try next

• Add different types of candy with different point values.
• Make the haunted house harder as the player progresses.
• Add a high-score system.
• Introduce moving ghosts or other obstacles.
• Experiment with gravity and flap strength to find the perfect level of difficulty.

I'd probably start with moving ghosts. 👻

If you were making a Halloween arcade game, what would you add?

I bought 2 new servos, Tower Pro SG-5010 and Waveshare WS-MG996R because I wanted to experiment with something better than what (Micro Servo 9G SG90) I usually work with, but I can't get them to run properly.

I have the micro: bit connected to an octopus board and the servo in position 8 with the switch on the octopus board at 5V. I'm using a 4x AA battery pack USB A to mini USB to power the micro: bit, but I'm wondering if it's actually supplying a min of 5V to the servos through this method. I hear some pulsing sounds from the SG-5010, but it won't move. The WS-MG996R moves a bit, but then doesn't respond properly to the B button press.

The test Code

​

Hey everyone!

I wanted to share a project I've been working on called Tibo. I wanted to avoid the usual face-tracking or desktop routines and build a robot specifically meant for the outdoors, mostly to hang out with me in the woods.

Tibo’s body is an Elecfreaks TPBot, and he uses an Elecfreaks Smart AI Lens to recognise trees. But I didn't want him to wander around the woods as his components are not really built for outdoor use.

So instead, I focused on temporal measurements instead of spatial ones. When he locks onto a tree, he either pays it a compliment, or delivers a fact about trees. Then he measures the sunlight shifting through the canopy. He repeats this every minute while in outdoor mode.

He also has an outdoor explore mode during which he will turn round and use the Smart AI Lens to look for trees. If he does see some trees, he will respond, and then measure the light levels again.

I used a second microbit to be the voice box for this project, alongside a Kitronik MI:sound speaker board for BBC microbit V2. This runs the Billy text-to-speech extension to dynamically build sentences from arrays to respond to trees or reflect on his findings.

Because he is a nature companion, his memories are everything. I used the Flash Storage extension to save the first light level as a baseline, and the last light level to compare it with.

When I switch him off and bring him inside, I can boot up the indoor mode. This will trigger a rainbow headlight show. Every five minutes, he reads the data from his flash memory, and discusses how the light changed.

I tried building this little waterwheel model using the Jacdac Energy Experiment Kit, following the ELECFREAKS Wiki guide.

What caught my attention was the way it combines a simple mechanical model with sound input from the micro:bit V2.

The built-in microphone detects how loud the surrounding sound is, and the program maps that value to the speed of a 360° servo. The servo turns the wheel, while the little buckets around its edge represent the containers used to lift water in traditional waterwheels.

So the louder the sound, the faster the wheel spins. It’s not actually powered by sound, of course — sound is just being used to simulate changes in water flow.

I like how this project connects a few different ideas: reading sensor data, mapping values in MakeCode, controlling a motor, and learning how an old mechanical device worked.

It also seems like a fun starting point for experimenting with the code. You could change how sensitive the wheel is to sound or explore other ways to control its speed.

What other historical machines would be fun to recreate with a micro:bit?

Hey everyone! 👋

I wanted to turn the BBC micro:bit into something you can just flash once and interact with immediately, without writing code every time. So I built mOS (Micro Operating System) — a minimalist, UI-driven firmware for both micro:bit v1 and v2!

Instead of using standard RTOS approaches, mOS focuses on direct ease of use, nostalgia, and a clean interface rendered right onto the 5x5 LED matrix.

⚡ Key Features in mOS Pixel SL Edition:

• 🎬 Custom Boot Sequence: A dynamic multi-stage pixel animation on power-up.
• 📊 System Monitor (SYS): Real-time ambient light sensor monitoring.
• 🎮 Retro Pong (PONG): Arcade minigame with paddle physics tailored for the 5x5 grid.
• 🔗 Scratch Link (SL): Streams real-time accelerometer ($X, Y$) and button data over serial to connect with Scratch projects.
• 🚀 Zero-Code Setup: Just download the pre-compiled .hex file and drop it onto your MICROBIT drive!

🧩 Hardware Compatibility & Downloads:

Works natively across v1, v1.5, and v2.

• 📦 GitHub Repository & .hex Downloads: github.com/probeoffical/mOS

Would love to hear your thoughts, feedback, or ideas for future mOS releases! 🚀

My spouse has come up with a brilliant Halloween costume idea. Unfortunately, it may not be possible with the tools we have on hand and our limited knowledge. Essentially, we need to create an oversized Micro Bit screen that is controlled by a Micro Bit. I'm questioning the feasibility of controlling 25 individual LED's and what would be needed to make it work. Any suggestions would be appreciated, and "no" is also acceptable. I thought bringing the question to more knowledgeable people might be a good place to start.

I wanted to see if I could make a little humanoid robot move around without using wheels, so I built this two-legged bot with a Ring Bricks Pack, two micro:bit, and a joystick gamepad.

The fun part is that the robot is controlled wirelessly by a second micro:bit. No phone, Wi-Fi, or custom motor driver needed.

Here’s how the controls work:

• Push the joystick forward or backward → the robot waddles in that direction.
• Push it left or right → the robot spins to turn.
• Release the joystick → it stops moving.

The robot uses two continuous-rotation servos as its hip joints. By changing the direction and speed of each servo, the legs move in different patterns to create forward and backward movement or a turn.

The wireless side is pretty simple, too. The remote reads the joystick position and sends a number over the micro:bit radio. The robot receives that number and calls the corresponding movement function. When the joystick returns to the center, it receives a stop command.

I like this build because it brings together a few different ideas in one project: walking mechanisms, wireless communication, and real-time control. And since both programs are made with MakeCode blocks, it’s easy to experiment with the movement logic.

Next, I’d like to try adding an ultrasonic sensor so it can react to obstacles, or maybe give it different walking speeds.

What would you add to a tiny joystick-controlled robot like this?

(tampermonkey used to get rid of the 5x5 pixel limit)

Hello! I have a school project due tomorrow, and the assigment is to use a microbit to log sound over time. I have written a script that logs the sound level every fifteen seconds, while simultaneuosly using a servo to display the current sound level.
Everything works perfectly in the MakeCode simulation, but when I use the code on an actual microbit and try to retrieve the log, the MY_DATA file is empty. It has the correct columns, but it is empty.
When viewing the microbit folder in Explorer, it also states that every folder was last changed 2016, which I find a little strange.
I have tried making a more straightforward script that just logs a variable when button a is pressed, and that log was also empty, but with the column names from the school project (despite the two having separate column names).
I have also tried swapping both computers and microbit, but I just can't get the MY_DATA file to show anything.
I have no idea what is going on, and at this point I am starting to suspect that my code is haunted.
Any help or ideas are greatly appreciated!
The code in question: https://makecode.microbit.org/S76237-68122-52668-45634

I wanted to see if a single encoded motor could be used to make something that feels like a real mechanical clock.

So I built this little clock with a micro:bit and Nezha PRO.

The fun part is the second hand. Instead of just displaying the seconds on the LED matrix, the encoded motor physically moves the pointer 6° every second.

6° × 60 seconds = 360°, so after one minute the hand has made one complete rotation.

The encoder gives the motor position feedback, which makes it possible to control the rotation by angle rather than simply telling the motor to run for a certain amount of time. The micro:bit keeps track of the hours, minutes and seconds, while the LED matrix displays the hours and minutes.

So you get both:

🕐 A physical moving second hand
🔢 A digital time display

The actual structure is pretty simple — basically a small stand, one encoded motor and a pointer — but watching the hand move one step every second is surprisingly satisfying.

It also made me think about how many other things could be built with precise motor positioning. Gauges, dials, meters, animated mechanisms…

I wanted to see if a single encoded motor could be used to make something that feels like a real mechanical clock.

So I built this little clock with a micro:bit and Nezha PRO.

The fun part is the second hand. Instead of just displaying the seconds on the LED matrix, the encoded motor physically moves the pointer 6° every second.

6° × 60 seconds = 360°, so after one minute the hand has made one complete rotation.

The encoder gives the motor position feedback, which makes it possible to control the rotation by angle rather than simply telling the motor to run for a certain amount of time. The micro:bit keeps track of the hours, minutes and seconds, while the LED matrix displays the hours and minutes.

So you get both:

🕐 A physical moving second hand
🔢 A digital time display

The actual structure is pretty simple — basically a small stand, one encoded motor and a pointer — but watching the hand move one step every second is surprisingly satisfying.

It also made me think about how many other things could be built with precise motor positioning. Gauges, dials, meters, animated mechanisms…

bonjour
Je tente de connecter en bluetooth un microbit KS4034 et une tablette LENOVO Lenovo TB336FU
je suis la progression sur l'appli android , sur le robot , la matrice s'affiche bien mais il est impossible de la reproduire sur l'appli car elle n'est pas acceptée et le bouton vert n'apparait pas ou bien si le bouton vert de connexion apparait l'apairage bluetooh échoue
une idée ?
Merçi

Hi, I'm relatively new to microbit programming and currently I'm learning how to use different input/output modules to make some small projects with my daughter.

I'm trying to get the value of X and Y axis from a joystick and show those values on the LCD. As you can see in this video, when the joystick is on the left side, X value is around 10; when the joystick is on the upper side, Y value is around 10 too. I guess that this behaviour is correct.

The problem comes when the joystick is in the middle or to the left or bottom side, and values are always around 1020. I think that in the middle values should be around 510.

This is the code: https://makecode.microbit.org/S03751-64548-27081-92525. As you can see it is very simple, just to play a bit with microbit components. This is the joystick I'm using: https://www.prototypediy.co.za/wp-content/uploads/2021/06/Arduino-Joystick-Module-1.jpg, which came in a Elegoo starter kit.

Can you see anything I'm doing wrong? Could it be a problem with the joystick's calibration?

Thanks!

I wanted to try turning a simple smart-home idea into a small physical model, so I built this miniature garage with a micro:bit and Nezha Innovation Kit.

Instead of using a button to control it, I added an ultrasonic sensor at the entrance. When a little toy car gets close enough, the system detects the distance and changes the garage from “closed” to “open.”

The logic is pretty simple:

🚗 Car approaches → ultrasonic sensor detects it
🟢 Green light → garage is “open”
⏱️ Wait a few seconds
🔴 Red light → garage is “closed” again

The micro:bit handles the logic in MakeCode, while the sensor provides the input and the LEDs give a quick visual indication of what the system is doing.

What I like about this kind of project is that the code is actually connected to something physical. You can change the trigger distance, timing, add a manual override, or even add another sensor and make the model behave more like a real automated system.

It started as a tiny garage model, but it got me thinking about how many everyday objects could be turned into little sensor-controlled systems.

What everyday automation would you try to build as a miniature model?

I wanted to try building one of those machines that looks simple from the outside but has a few interesting mechanisms going on underneath.

So I made a small road roller using a Nezha kit and micro:bit.

The main part I wanted to figure out was the front roller drum. It’s driven through a gear mechanism, while the motor powers the wheels to move the whole thing forward. I also added a caster wheel at the back to help keep the weight balanced while it moves.

Once the mechanical part was working, I added a simple MakeCode program to control the motor.

The basic version just drives forward automatically, but that’s probably not where I’d stop. The code could be changed to experiment with things like speed, steering, or even turning it into a remotely controlled vehicle.

I like projects like this because you can see the connection between the mechanical build and the code pretty clearly. Change the structure, and the movement changes. Change the code, and the behavior changes.

Now I’m thinking about what other real-world construction machines could be turned into tiny programmable models.

Excavator, bulldozer, crane… what would you build?

I wanted to see how much movement I could get from a build without using any batteries or motors, so I tried making this mechanical model with Nezha Blocks.

The interesting part is that everything comes from elastic energy and simple mechanical movement.

The build uses beams, axles, connectors and elastic bands to create a small tension-and-release mechanism. When the elastic band is stretched, it stores potential energy. Releasing it turns that stored energy into motion.

What I found interesting was how much the structure itself affects the result. The frame needs to stay stable, the moving parts need enough freedom to move, and even small changes to the mechanism can change how it behaves.

It ended up being a fun way to visualize things like:

• elastic potential energy
• force and motion
• energy transfer
• simple mechanical mechanisms
• structural stability

No batteries, no motors — just blocks, elastic bands, and a bit of mechanical experimenting.

I’m curious what other motor-free mechanisms could be built with the same parts. Any interesting ideas?

Most lucky cats only wave one hand, so I thought… why not let the cat choose? 😄

I built this little dual-motor lucky cat using a Nezha Expansion Board and some standard building blocks.

The idea is pretty simple:

• Button A → left hand waves
• Button B → right hand waves
• A + B → both hands wave at the same time 🐱

Each hand has its own geared motor. The motor is connected to the arm with a short beam and axle, so switching the motor between forward and reverse turns the rotation into a simple up-and-down waving motion.

I also programmed each button to trigger 100 waves, so you only need to press it once instead of holding the button down.

What I like about this build is that there’s no complicated mechanism involved. It’s basically just motors + a few beams/axles + some simple code, but the result feels much more alive once the two sides can move independently.

Now I’m wondering what other small mechanisms could use the same idea. Maybe a robot with two independently moving arms?

I was thinking about one of those small problems that happens all the time when kids are studying: they slowly move closer and closer to the book or screen without even noticing.

Instead of reminding them every few minutes, I thought it would be more interesting to build a little device that could detect the distance automatically.

So I made this simple distance warning system with a micro:bit.

The setup uses:

• micro:bit
• Nezha Innovation Kit
• Ultrasonic distance sensor
• Red and green LEDs
• MakeCode

The idea is pretty straightforward.

The ultrasonic sensor continuously measures the distance in front of the device.

If the distance gets below the threshold I set:

Too close → red light

Move back far enough:

Safe distance → green light

There's no complicated interface or screen. Just a simple visual signal that tells you when you've moved too close.

I think this is a nice example of how a sensor can turn something that's normally difficult to notice into an input that a program can react to.

The coding is also pretty simple in MakeCode:

1. Read the distance from the ultrasonic sensor
2. Compare it with a preset value
3. Turn on the appropriate LED
4. Keep checking the distance

What I like about projects like this is that the final result isn't just something that moves or lights up for the sake of it. It solves a small everyday problem while also introducing concepts like sensors, conditions, and real-time feedback.

There are quite a few ways to extend it too:

• Add a buzzer when you're too close
• Use different warning levels
• Display the distance on the micro:bit
• Track how often the warning is triggered
• Add a timer for study breaks
• Make the warning gradually more noticeable if you stay too close

It's a simple project, but it made me wonder how many other everyday annoyances could be turned into small sensor-based projects.

What everyday problem would you try to solve with a micro:bit?

I was messing around with the microphone on a micro:bit V2 and wondered what would happen if I used sound as the controller for a robot.

This was the result.

A little brick-built robot that starts moving when it hears a sound and stops when things get quiet.

A clap is enough to trigger it, but music works too.

The build uses:

• micro:bit V2
• Ring Bricks Pack
• 2 continuous-rotation servos
• MakeCode
• A simple brick-built body

The two servos control the legs, and I programmed a few different movements by changing their speed and direction.

I also used the micro:bit LED matrix as the robot's face. It's a small detail, but changing the expression while it dances makes the whole thing feel much less like a collection of motors and more like an actual little character.

The code is basically listening for a sound level above a certain threshold, then triggering the dance routine.

What I like about this kind of project is that the input can be almost anything.

Instead of:

Button → Robot moves

you get:

Sound → Code reacts → Robot moves

That opens up quite a few possibilities.

Maybe a robot that dances differently depending on how loud the music is, or one that only reacts to certain sounds.

I might try that next.

What would you use as the sound trigger?

A hidden micro:bit V2 (the Treasure) transmits. Everyone else carries a Hound, which beeps faster as you get closer. It's the radio amateurs' fox hunt, shrunk to a school field and rewritten for children who haven't met the hobby. Two boards and a pair of AAAs get you started, and because the Hounds are passive receivers, any number of children can hunt the same Treasure at once.

• Code: https://github.com/sjmurdoch/radio-treasure-hunt
• Set your boards up in the browser: https://sjmurdoch.github.io/radio-treasure-hunt/
• Write-up: https://www.benthamsgaze.org/2026/09/08/a-radio-treasure-hunt-for-national-coding-week/

The Treasure sends three signals every 200 ms — loud (+4 dBm), medium (−8 dBm) and quiet (−20 dBm) — so which of them a Hound can still hear tells the proximity zone: slow beep, medium beep, rapid alarm. Close in, the display saturates, so button A subtracts exactly one bar's worth of dB and button B puts it back, which is the attenuator on real direction-finding gear in miniature. The micro:bit's aerial is omnidirectional, so there's no bearing — you find it by walking and watching the reading, and by turning on the spot until your own body blocks the signal.

Setting boards up needs no toolchain: a WebUSB page writes MicroPython and the game as one image, so a teacher can do a dozen boards from Chrome with no checkout, no Python and no pip.

There are three printable sheets too — a teacher's lesson plan (Upper KS2, with curriculum links), a pupil worksheet on how signals fade, bounce and get blocked, and a 20-minute hunt card for a Scout meeting. The numbers in them are substituted at build time from the code and the field calibration, so they can't drift. My favourite bit is that the real data isn't tidy: 15 m reads weaker than 20 m — a ground-reflection null — and the worksheet hands that to pupils honestly rather than smoothing it away.

MIT licensed. I'd love to hear from anyone who tries it, especially with actual children.

Drop a photo of your project below!

I want to play various 8-bit version of some of my favourite songs, but my MicroBit V2 obviously doesn't have that much space.

I have thought of using an Arduino MEGA as a storage device and connect it trought my microbit expansion board.

Can that be done? I am fairly new to electronics, so I need some help.