We wanted to build something a little more interesting than a regular box made from building blocks, so we turned one into a small password-protected safe.

The idea is simple: use the A and B buttons on a micro:bit as the keys, enter the correct combination, and let a motor open the door. But we also wanted it to behave a bit more like an actual safe, so we added a few extra rules.

The default password is AABB. Each time a button is pressed, the micro:bit records the input and displays how many characters have been entered on its 5×5 LED matrix. It only shows the number of characters, not the actual password.

Once all four characters have been entered, the program waits five seconds and checks the combination automatically. There's no separate submit button needed. If the password is correct, a check mark appears and a PlanetX Smart Brick Motor connected to port M1 on the Nezha Pro rotates 90 degrees counterclockwise to open the door.

Of course, getting the password wrong is part of the fun.

The first two incorrect attempts show a cross on the LED display, giving the user another chance. But make three consecutive mistakes, and the safe gets a little less friendly: the display flashes a warning, then starts a 10-second lockout countdown. During this time, button inputs are ignored. Once the countdown finishes, "TRY AGAIN" scrolls across the display and the safe is ready for another attempt.

We also added a couple of useful controls. Pressing A+B while entering a password clears the current input, so there's no need to start over if you accidentally press the wrong button. After the door opens, A+B rotates the motor 90 degrees clockwise to close it again.

The mechanical part was just as important as the code. We used the Nezha Pro Sport Kit to build the safe body, hinged door, and motor linkage. The door needs to move freely, and the motor's starting position needs to match the fully closed position. Otherwise, even a perfectly correct password won't help if the door gets stuck!

The project uses a micro:bit, a Nezha Pro Breakout Board, and one PlanetX Smart Brick Motor. We used the Nezha Pro's angle-based motor control to make the opening and closing movements 90-degree rotations, rather than simply running the motor for a set amount of time.

It's a small project, but it combines quite a few ideas: button input, variables, timing, conditional logic, error handling, and mechanical movement.

Now I'm wondering what would make this safe more interesting. Maybe a longer password, a different combination system, or even a second condition before the door unlocks?

Would you trust a building-block safe to protect your snacks? 😄

Hello all

I’m very new to this, but daughter has been doing a microbit after school club for half a term, and has really enjoyed it!

Her birthday is coming up soon and we’re keen to build on that and get a kit for home. What do you recommend? Budget up to £100 or so!

Thanks in advance!

I’m new to Micro:bit and looking to learn as much as I can. I’d love to hear about some of the most interesting projects people have built, especially anything involving sports, cameras, photography, or videography.

I’m a K–2 school media specialist, and I want to introduce more hands-on coding and STEAM activities into our daily library time. I think Micro:bit could be a great way to get my students involved while also challenging myself to learn something new.
Outside of school, I’m really into sports media, mainly basketball 🏀 and football 🏈, with a big interest in photography and videography. I’m also interested in AI and using Claude Code to build websites, interactive learning tools, and other creative projects.

I’m curious how people have incorporated Micro:bit into sports-related projects, camera experiments, computer vision, or even AI.

I’ve started watching YouTube tutorials and working through the beginner material, but I’d appreciate advice from people with hands-on experience.

A few questions:
What’s the coolest project you’ve built with Micro:bit?
Have you used it for sports, cameras, photography, or videography?

What beginner mistakes or learning curves should I expect?
What resources, tutorials, or YouTube channels would you recommend?

I’m starting with the basics, but I’m interested in eventually taking things much further. I’d love to hear what you’ve experimented with and what you wish you knew when you first started!

I’m starting with the basics, but I’m interested in eventually taking things much further. I’d love to hear what you’ve experimented with and what you wish you knew when you first started!

I've always thought it would be fun to build a robot that could actually play a musical instrument. Not just move its arms around, but hit something in rhythm and make a little music. So we decided to try building a small desktop drumming robot.

The idea is pretty straightforward: two robotic arms hold drumsticks and take turns hitting a tire. We used a micro:bit, a Nezha Pro Breakout Board, two PlanetX Smart Brick Motors, and building pieces from the Nezha Pro Sport Kit to put everything together.

The two motors are mounted on opposite sides of the structure, with each one controlling a drumstick. Since the arms are installed as mirror images of each other, their movements need to be adjusted separately to make sure both drumsticks hit the right spot. We set the motors to swing back and forth through an angle of around 35 degrees, creating the repeated striking motion.

For the controls, we programmed three different playing modes:

• Press A: Plays a basic 16-hit drum beat.

• Press B: Plays a drum fill over three rounds.

• Press A+B: Continuously switches between the basic beat and the drum fill.

The part I found particularly interesting was the calibration feature. Getting both drumsticks into the correct starting positions can be a little tricky, especially when the motors are mounted in opposite directions. Rather than having to take the structure apart and adjust everything manually, we added a calibration mode using the micro:bit V2's gold logo touch feature.

Hold the gold logo for about two seconds to enter calibration mode. Press A to adjust the left drumstick and B to adjust the right one. Pressing A+B switches the adjustment direction, either inward or outward. Each button press changes the motor position by 3 degrees, so you can fine-tune the drumsticks until they line up with the drum surface. Hold the gold logo again to save the positions and exit calibration mode.

We also used the micro:bit's 5×5 LED display to show different status icons, making it easier to tell what the robot is doing.

One small detail worth mentioning: the gold logo touch feature used for calibration is only available on micro:bit, so this particular control method depends on that version.

Overall, this was a fun way to experiment with motor control and mechanical movement. I especially like that the calibration is built into the program, because it makes adjusting the robot much less frustrating.

If we continue developing it, I'd like to experiment with more complicated drum patterns, different striking speeds, or even add another drumstick and see what kind of rhythms we can get out of it.

What would you add to a little desktop music robot like this?

We wanted to make something fun for Halloween, so we came up with a little pumpkin monster that can actually move around and scare people.

It's basically a Cutebot Pro dressed up as a jack-o'-lantern, with two skeleton hands sticking out of the sides.

At first, it just looks like a funny little pumpkin on wheels. But get too close, and those hands suddenly swing downward while the lights turn red.

Definitely more interesting than a pumpkin sitting on the doorstep. 👻

What we used:

• Cutebot Pro

• 2 × 360° Servos

• Joystick

• 10-LED NeoPixel strip

• Pumpkin shell

• Skeleton hands and mounting brackets

• micro:bit

How we made it

We started with the Cutebot Pro as the base and mounted a servo on each side.

Then we attached the skeleton hands to the servos. This took a little adjustment to make sure both hands could swing freely without hitting the pumpkin shell.

We added the pumpkin cover and wrapped a NeoPixel strip around it. The idea was to make it look like a normal glowing Halloween decoration until the scare happens.

The interesting part is how we made it move and react.

We used a joystick to control the robot remotely. It sends the joystick's X and Y values over radio, and the Cutebot Pro uses those values to control its left and right wheels.

For the jump scare, we added an ultrasonic sensor.

Normally, the skeleton hands stay raised at 90°. When something gets within 15 cm, the robot stops, both servos move to 0°, and the lights switch to red.

Once the object moves away, the hands go back up and the lights return to orange.

So the whole sequence is basically:

Drive around → Someone gets close → Hands drop + red lights → Back to normal.

A few things we thought about trying next:

• Add a spooky sound when the hands suddenly drop.

• Make the two hands move at slightly different times.

• Try different sensor distances to see which gives the best surprise.

• Add more decorations to make the pumpkin look even creepier.

It was a fun little build, especially seeing the robot go from a simple moving car to something with its own Halloween personality.

I wonder what other characters we could make with the same setup. A spider? A little ghost? Something even more ridiculous?

We wanted to make something fun for Halloween, so we came up with a little pumpkin monster that can actually move around and scare people.

It's basically a Cutebot Pro dressed up as a jack-o'-lantern, with two skeleton hands sticking out of the sides.

At first, it just looks like a funny little pumpkin on wheels. But get too close, and those hands suddenly swing downward while the lights turn red.

Definitely more interesting than a pumpkin sitting on the doorstep. 👻

What we used:

• Cutebot Pro

• 2 × 360° Servos

• Joystick

• 10-LED NeoPixel strip

• Pumpkin shell

• Skeleton hands and mounting brackets

• micro:bit

How we made it

We started with the Cutebot Pro as the base and mounted a servo on each side.

Then we attached the skeleton hands to the servos. This took a little adjustment to make sure both hands could swing freely without hitting the pumpkin shell.

We added the pumpkin cover and wrapped a NeoPixel strip around it. The idea was to make it look like a normal glowing Halloween decoration until the scare happens.

The interesting part is how we made it move and react.

We used a joystick to control the robot remotely. It sends the joystick's X and Y values over radio, and the Cutebot Pro uses those values to control its left and right wheels.

For the jump scare, we added an ultrasonic sensor.

Normally, the skeleton hands stay raised at 90°. When something gets within 15 cm, the robot stops, both servos move to 0°, and the lights switch to red.

Once the object moves away, the hands go back up and the lights return to orange.

So the whole sequence is basically:

Drive around → Someone gets close → Hands drop + red lights → Back to normal.

A few things we thought about trying next:

• Add a spooky sound when the hands suddenly drop.

• Make the two hands move at slightly different times.

• Try different sensor distances to see which gives the best surprise.

• Add more decorations to make the pumpkin look even creepier.

It was a fun little build, especially seeing the robot go from a simple moving car to something with its own Halloween personality.

I wonder what other characters we could make with the same setup. A spider? A little ghost? Something even more ridiculous?

I built this for hackclub stardance!
A game for the BBC micro:bit. You control the car on the bottom row, and dodge the incomming obstacles from the top. The longer you survive the faster the obstacles fall. All displayed on the microbits LED display. Please give it a go!
https://github.com/zeept1234/Microbit-endless-racing-game

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?