Project: Bike Safety Light Prototype

One-sentence summary

In this lesson we design a small bike safety light prototype that flashes in the dark, using the micro:bit's light sensor and accelerometer.

Why does it matter?

I enjoy riding my bike, and I noticed how important it is to stay visible when the evening light starts to fade. That led to a question: could a micro:bit start flashing on its own when the surroundings get dark?

This project brings together pieces we met all through the module. The LED matrix, the light sensor, the accelerometer, conditions and loops... We saw each one on its own. Now we join them in a single program that tries to solve a real need.

I want to be clear about one thing from the start: this is a teaching prototype, not a replacement for a real bike light. Our aim is to see how sensors and code work together, not to keep anyone safe in traffic. On real rides you should always use an official, approved bike light and reflectors. That is the nice thing about prototyping: we can try an idea safely and watch how it behaves.

The prototype idea and the micro:bit's role

A prototype is not a finished product; it is a first attempt built to test an idea. Engineers usually start with a simple prototype before making anything expensive or complex.

What will our prototype do?

Let's sum up the plan in three lines:

1. When the surroundings get dark, the LEDs should start flashing.
2. When it is bright, the screen should stay off and not waste battery.
3. As a next step, it should show a different pattern when slowing down (braking) is sensed.

What the prototype is *not*

Keeping this clear matters for safety:

• It is not a real brake light or turn signal.
• It is not bright enough to catch a driver's attention; micro:bit LEDs are hard to see from far away in daylight.
• It is not equipment that meets traffic rules.

So this project is not about saying "look, I made a safe light." It is about understanding the question "how do sensors detect darkness and movement?"

Sensing darkness: the light sensor

The micro:bit has no separate light sensor; instead it briefly uses the screen LEDs as a receiver to measure the surrounding light. The result is a number between 0 (very dark) and 255 (very bright).

Here is a familiar everyday example: street lamps. Many street lamps have a light sensor inside; they switch on by themselves when it gets dark and switch off when morning comes. What we are building is the same idea, just at a very small scale.

First we need to choose a threshold. The threshold is the line where we say, "if it is darker than this, start flashing." We try a few numbers in the room and pick a good one; 50 is a fine first guess.

With MakeCode blocks

forever
  if <light level < 50> then
    show icon heart
    pause 100 ms
    clear screen
    pause 100 ms
  else
    clear screen

This program loops all the time. If the light level drops below the threshold, the heart flashes on and off; if it is bright, the screen stays off.

With MicroPython

from microbit import *

while True:
    if display.read_light_level() < 50:
        display.show(Image.HEART)
        sleep(100)
        display.clear()
        sleep(100)
    else:
        display.clear()

The logic is exactly the same in both languages: measure, compare, flash if dark. The only difference is how the commands are written.

Sensing slowdown: the accelerometer idea

On a real bike, the rear light glows brighter when you brake. Trying to imitate this on the micro:bit is a fun experiment. The board's accelerometer can measure movement and changes in tilt.

Here is the second everyday example: a car's brake light. When the driver presses the brake, the light glows and tells the driver behind, "I am slowing down." We will try a similar idea by showing a different pattern at the moment of slowing.

Measuring this perfectly is hard, so we choose a simple approach: show a "stop" pattern when the board is clearly jolted (for example, a sudden movement). This is not real braking, but a rough imitation of it.

from microbit import *

while True:
    if accelerometer.was_gesture("shake"):
        display.show(Image.SQUARE)   # "stop" pattern
        sleep(500)
        display.clear()
    elif display.read_light_level() < 50:
        display.show(Image.HEART)
        sleep(100)
        display.clear()
        sleep(100)
    else:
        display.clear()

Here was_gesture("shake") tells us whether the board was jolted a moment ago. Remember that this part is experimental: a real braking sensor is designed far more carefully.

Mini practice

Build and test your own prototype step by step:

1. Load the first light-sensor program (MakeCode or MicroPython) onto the board.
2. With the room light on, look at the screen: it should stay off.
3. Cover the board with both hands or turn off the light: the heart should start flashing.
4. Try the threshold as 20 and 100 instead of 50. Which number works better in your room?
5. If you like, add the accelerometer version and watch the "stop" pattern appear when you shake the board gently.

Ideas to improve it

• Use an arrow or your own pattern instead of the heart.
• Adjust the flashing speed by changing the sleep times.
• If you have two micro:bits, could one send a "slowing down" message to the other, like in the radio lesson? Note this as your next experiment.

A test-and-fix example

On my first try the screen kept flashing even when the light was on. I found the problem like this:

Goal: Keep the screen off when it is bright
Problem: The heart flashes even with the light on
Check: The threshold is set to 200; my room is darker than that
Fix: Lower the threshold to 50 and try again

Writing the expected result, observing what actually happens and changing just one thing; those are always the same steps of debugging.

Common mistakes

Leaving the threshold untested

Every room has different lighting. Instead of writing 50 once and leaving it, you should try a few values in your own space and pick the best one.

Forgetting to clear the screen

If you do not write display.clear(), the LEDs stay on and the "flashing" cannot be seen. Clearing the screen after showing a pattern is an important part of the loop.

Mistaking the prototype for a real light

This is the most important mistake. micro:bit LEDs are weak and this project was not designed for traffic. The prototype is for understanding the idea; using it as a safety light on the road would be wrong.

Trying to adjust the board while riding

Code and threshold settings are always done at home, while stopped. Looking at or touching the board while riding is a distraction.

Safety note

• This is a teaching prototype, not a replacement for an official bike light. On real rides, use an approved light and reflectors.
• Connect the battery pack and any external parts with an adult's help. Use only the micro:bit's own low-voltage battery pack; never work with mains electricity.
• If you attach the board to a bike to try it, fix it firmly so it cannot fall; tying a loose object to the handlebar is dangerous.
• Do not interact with the device while riding. Looking at the screen or pressing a button takes your attention off the road. Make all adjustments while stopped.
• Do not use the electronic parts in wet weather; the battery and circuit must stay dry.

Review questions

1. What is the project’s safety goal, and what is outside its responsibility?
2. Why should brightness be tested in more than one lighting condition?
3. How can the program avoid changing patterns accidentally because of sensor noise?
4. What is a safe way to attach the prototype without interfering with steering or brakes?
5. Which test proves that the light still works after repeated movement?
6. Why must the project be described as a learning prototype rather than certified safety equipment?

Answers

1. The goal is to improve visibility during a supervised learning test; it does not replace legal reflectors, approved lights or safe riding behaviour.
2. A pattern visible indoors may be too weak in daylight or uncomfortably bright in darkness.
3. Use a threshold with hysteresis, averaging or a short confirmation time before switching state.
4. Use a secure removable mount away from controls, moving parts, cables and sharp edges, then have an adult inspect it.
5. A shake and ride-simulation test followed by a visual and electrical inspection checks the mount, wiring and program stability.
6. It has not undergone regulatory, weather, impact or long-term reliability testing required of real safety equipment.

Lesson summary

• A prototype is a first, simple attempt to test an idea safely; it is not the final product.
• The micro:bit measures surrounding light as a number from 0 to 255; we detect darkness with a threshold.
• The same logic can be written with MakeCode blocks or MicroPython; only the form changes.
• Imitating a slowdown with the accelerometer is a fun but experimental add-on.
• This project does not replace a safety light; on real rides an approved light and reflectors are essential.

Check your understanding

1. In what number range does the micro:bit report the light level?
2. What does the threshold do, and why can it differ from room to room?
3. What happens if we forget to write display.clear()?
4. Why should we not use this project as a real bike safety light?
5. Which sensor and which movement did we use to imitate slowing down?

Answers

1. It reports a number between 0 (very dark) and 255 (very bright).
2. The threshold is the line where we say, "if it is darker than this, start flashing." Because every room's lighting is different, the right threshold changes too, so we find it by testing.
3. The LEDs stay on, the screen is not cleared, and the flashing effect cannot be seen.
4. Because it is a teaching prototype: its LEDs are weak, it does not meet traffic rules, and it was not designed for safety. Real rides need an approved light.
5. We used the accelerometer and sensed a shake with was_gesture("shake"), that is, a sudden movement. This is a rough imitation of real braking.

Source and verification note

For “Project: Bike Safety Light Prototype”, verification focuses on whether the relationship between The prototype idea and the micro:bit's role and What the prototype is *not* remains consistent across examples. MakeCode and MicroPython names can vary slightly by version. Test in the simulator first; when external components are connected, check the board’s pin and voltage limits separately.

Next lesson

The Arduino module: After the micro:bit, we meet a new board where you build your own circuits and code them line by line.