BBC micro:bit – handle with care

Here’s the TL/DR version of this blogpost: if you are using the BBC micro:bit, especially with children, make sure they heed the advice on these panels in the middle of the back of the ‘Getting Started’ leaflet. In effect this means you can’t easily use the micro:bit buttons when it’s plugged in to a computer, as the natural way of holding it is to put a finger behind the A button to support it as you push:

Still interested? Here’s the background.

I’ve had 3 preview teacher micro:bits for a few months, and they all worked swimmingly… until I started using them with children. One unit got warm but still worked, another got incredibly hot (dangerously so) and failed. I sent it back to the BBC and got a replacement unit, which worked fine again – until I started using them with children. The new unit also started getting warm, but it still worked.

The BBC told me the chances of having multiple failures were ‘billions’ to one, so there must be an environmental factor. They sent me 5 more micro:bits to test in the same ICT room, on the same computers: HP Chromebooks. I spent about an hour testing them – and they were all perfectly fine. Must have been a fluke. A billion-to-one fluke.

Then I tried them out with my Year 5 computer club – and 2 of the new 5 micro:bits also now started getting warm. Not dangerously so, but noticeably warmer than normal.

Logically the only explanation for the mystery of the micro:bits was: children. I toyed with the idea of positing a new particle called a childon. Children must emit childons which have the effect of frying integrated circuits.

It turns out that my experience with the micro:bit is reproducable, and is, I am told, caused by 3 things happening at the same time:

  • The micro:bit must be plugged into a USB socket that can deliver enough current to charge a phone
  • The user must be touching the metal test pads on the back of the device
  • The user must cause an electrostatic charge to go into the device

Now this is a bit of a problem, because I think these 3 things will happen really quite often indeed. Firstly, most children test code, upload it, tweak it, upload it again. Combine that with the need for batteries, I think most micro:bits will be plugged into computers most of the time. Our HP Chromebooks are not unusual devices in schools, they have USB 3 sockets, and apparently these provide enough current to be a problem.

Secondly, it’s hard to avoid touching the test points on the back, especially as the ones in question are immediately behind the A button. It’s natural to hold it there as you push the button. Is it reasonable to expect children always to remember to hold them by the edges?

Thirdly, electrostatic shocks. My problems were in a room where I’d never noticed static shocks, but the floor is covered in carpet tiles, presumably nylon, so it’s a possibility. In my main ICT room I get shocks all the time, so when we use the class sets with Year 7 we will all have to keep earthing ourselves on something – not quite sure what. Do I need to run an earth to every desk?

I write all this with a heavy heart. I like the device, I love the microPython on it, I’ve written Python games for it, I’ve re-made the ‘happy plant‘ physical computing project, I’ve planned lessons for it.

But I fear that unless teachers and children read the leaflet carefully and heed the advice, an awful lot of micro:bits will fail, some may even get dangerously hot – though I should stress only 1 out of 9 initial units felt hot enough to burn, but a high proportion of the micro:bits I’ve actually allowed children to use run warmer than they should and draw more current than they should. I do wonder what would happen to the warm units if left plugged in for a long time – there is another warning panel about not leaving them unattended and unventilated on the back of the Getting Started leaflet. Where do I stand legally, as a teacher, if I give a child a micro:bit to take home and at home it causes an injury or fire?

The project is already beleaguered by insane delays – we were supposed to get them near the start of the academic year. That was 2015. We finally got our class sets for Year 7 last week, but because of upcoming exams and school trips, I now can’t use them until after half term in the Summer 2016 term. It’s a one-off giveaway, so the current Year 7s will only get a few weeks’ use out of them – and then we may struggle to use them in class. “Right Year 7! Only hold them by the edges! Earth yourself! Don’t use them when they are plugged in to the computer!” I may be an exceptionally poor teacher, but I find children do not always hear, understand and follow instructions in class. And the supplied USB leads are so short, usage will anyway be quite comical given our PC base units are built into the bottom of the desks.

It all just seems like a tragic mess, a wasted opportunity. I wish the BBC had been able to say “we messed up, let’s hold it over a year and you can hand them out next year’s Year 7s, or Year 8s if you already told them they were coming.”

Luckily I have still not told my current Year 7s about the micro:bit. And I am still not sure what to do with them.

How not to handle a micro:bit:

Posted in education, ICT | Tagged , | 3 Comments

Coding as a way of understanding the Monty Hall problem

The other night a maths teacher and I were sharing a few cold drinks and we fell to discussing the Monty Hall Problem.

Now, you may have heard of the Monty Hall Problem even if you don’t know it by that name. It goes like this: you are on a TV game show. There are 3 doors. Behind one door is a car, behind the other two there are goats. Assuming you want to win the car (thank you, Son B), you pick a door; the host then opens a door to reveal a goat and gives you the chance to change your choice. Should you change your choice, stick with the one you have, or does it make no difference?

This problem has infuriated me for ages because I’ve always been firmly of the opinion that it makes no difference. Which is a problem, because, in fact, if you change your choice you are TWICE as likely to win the car as if you stick with your first choice. To most people, this seems utterly mad, certainly counter-intuitive.

My maths teacher friend tried explaining it to me with glove puppets and I still didn’t really get it, so I decided the best thing was for me to write a computer simulation of it in Python. And by golly, not only does it prove him right, it also helped me understand the problem in a way I never had previously.

I think this would make a great combined maths/computing activity, because even just planning out the code helped me see the logic of the problem in a way I never had before because I was forced to confront what happens in every possible scenario. I could then see that being told what one of the wrong doors was actually changes everything – or at least it gives you a whole lot more information and that’s the key to seeing why you should change your choice.

To simplify the coding, I decided that for each game I’d always have the car behind the third door (which is door number 2, of course, Python being a zero-indexed language). I don’t think this makes any difference as long as the door choices the players make are random – an extension activity would be to rewrite the code so in every game the car is behind a different door.

This is how my code works – I’d be very happy to hear more elegant solutions, but it was when I wrote this out that the penny dropped and I finally understood the problem. Here’s how my (possibly flawed) thinking worked:

        |-----------------------|
door no.|   0   |   1   |   2   |
        |-----------------------|
        | goat  |  goat |  car  |
        |-----------------------|

I decided that I’d have two players who both pick the SAME random door in each game; player 1 would stick and player 2 would always change their choice having been ‘shown’ the door with the goat. If the car is always behind the last door, I think the sequence works like this…

If the players choose door 0, the host must open door 1 to reveal a goat, and player 2 must change their choice to door 2 – winning the car!

If the players choose door 1, the host must open door 0 to reveal a goat, and player 2 must change their choice to… door 2 – winning a car again!

If the players choose door 2 (containing the car), it doesn’t matter which of the other 2 doors the host opens, but I have decided they always open door 0 to keep things simple. In this case player 1 actually wins the car, but it’s the only way they can win it – a 1 in 3 chance. With bitter irony, player 2 has actually picked the right door first time but they will be forced to change their choice and win a goat instead – but the crucial thing is that they won in 2 out of the 3 scenarios. The changing player has a 2 in 3 chance of winning, the stick-in-the-mud has only a 1 in 3 chance.

Just sketching this out in a simple flowchart aids understanding of this problem, I don’t think any actual programming is necessary. You can see how the player who changes is twice as likely to win a car:

flowchart of possible simulation of Monty Hall problem

And indeed when I run this code for about 1000 games, player 2 does indeed win about twice as many cars as player 1:

A nice side-bar to this (especially as we teach in a girls’ school) is that it was a woman, Marilyn vos Savant, who proposed the correct solution to this problem, and 1000s of people with PhDs (mostly men, I bet) wrote to say she was wrong. She wasn’t.

Here’s my code, run it yourself in Python3. You can also download it here. It runs an awful lot faster in the OS X command line than it does in IDLE, and I expect I’ll find the same with Windows.

Monty Hall simulation running in OS X terminal and IDLE

If you improve it or use it in school, please let me know! Some bar charts might be nice…

# A computer simulation of the Monty Hall problem,
# a counter-intuitive logic and probability puzzle.
# by @blogmywiki - www.suppertime.co.uk/blogmywiki

print('Welcome to the\n'
'    __  ___            __           __  __      ____\n'
'   /  |/  /___  ____  / /___  __   / / / /___ _/ / /\n'
'  / /|_/ / __ \/ __ \/ __/ / / /  / /_/ / __ `/ / / \n'
' / /  / / /_/ / / / / /_/ /_/ /  / __  / /_/ / / /  \n'
'/_/  /_/\____/_/ /_/\__/\__, /  /_/ /_/\__,_/_/_/   \n'
'                      /____/ show\n'
'        |-----------------------|\n'
'door no.|   0   |   1   |   2   |\n'
'        |-----------------------|\n'
'        | goat  |  goat |  car  |\n'
'        |-----------------------|\n')

while True:

    import random

    print()
    answer = input('How many games do you want to simulate? (q to quit) ')
    if answer == "q":
        break
    else:
        tries = int(answer)

    doors = ['goat','goat','car']
    # door no. 0      1      2

    # I don't think it matters that these are not random
    # and keeping this fixed makes coding easier. 

    # Both players will pick the same door, but
    # when a door is opened with a goat behind it,
    # player1 will always stick with their 1st choice
    # whereas player2 will always change.
    # We will then keep a tally of who won more cars.

    player1_tally = 0
    player2_tally = 0

    for i in range(tries):

        chosen_door = random.randint(0,2)
        # pick a random door number between 0 and 2

        print('Game',i)
        print ('door',chosen_door,'chosen, containing a',doors[chosen_door])
        player1_choice = chosen_door
        if chosen_door == 0:
            player2_choice = 2
            print('Host opens door 1, player2 switches choice to door 2')
        elif chosen_door == 1:
            player2_choice = 2
            print('Host opens door 0, player2 switches choice to door 2')
        elif chosen_door == 2:
            player2_choice = 1
            print('Host opens door 0, player2 switches choice to door 1')

        if doors[player1_choice] == "car":
            print('Player 1 won a car!')
            player1_tally = player1_tally + 1

        if doors[player2_choice] == "car":
            print('Player 2 won a car!')
            player2_tally = player2_tally + 1

        print()

    print('Player 1 who stuck won',player1_tally,'cars.')
    print('Player 2 who changed won',player2_tally,'cars.')

And here’s a Trinket with a Python 2(ish) version of the code which you should be able to run in a web browser:

Posted in computers, education, ICT | Tagged , , , , | Leave a comment

Would you want to work at Matthew & Son?

I’ve been familiar with the 1966 Cat Stevens song ‘Matthew & Son’ since I was a youngling, and indeed back then it seemed like a grim existence working for the Man. And his son. And yet it was only the other week I stopped to think about exactly what it must have been like working for Mr Matthew. Or indeed his son. Let’s take the song line-by-line and examine the evidence.

Up at eight, you can’t be late
for Matthew & Son, he won’t wait.

Up at EIGHT? I dream of getting up at 8. My alarm goes off at 5.45, 6am if I’m having a lie-in. Matthew & Son have waited quite long enough, you laggard!

Watch them run down to platform one
And the eight-thirty train to Matthew & Son.

How I chuckle at this line as I run down to platform 3 for the 0629.

Matthew & Son, the work’s never done, there’s always something new.

Well, I’d bloody well hope for your future employment prospects that ‘the work’s never done’. And ‘always something new’ – better than the same old same old, Cat.

The files in your head, you take them to bed, you’re never ever through.
And they’ve been working all day, all day, all day!

I don’t think I ever had a job where I didn’t carry some baggage home with me. Being a BBC radio studio manager was probably as good as it gets in this regard, but even then I’d wake up screaming at 3am having dreamt that all the tape machines in S46 had turned to blancmange as the producer brings in 7 new spools of breaking news on a solo World Briefing.

There’s a five minute break and that’s all you take,
for a cup of cold coffee and a piece of cake.

I know primary school teachers who would kill for a whole FIVE MINUTE break, and us teachers like cold coffee because we can drink it in a hurry. Plus THERE’S CAKE.

He’s got people who’ve been working for fifty years
No one asks for more money cuz nobody cares
Even though they’re pretty low and their rent’s in arrears

Look on the bright side: a low-staff turnover is a GOOD sign. And clearly the job is itself reward enough! Who needs money?

Matthew & Son, Matthew & Son, Matthew & Son, Matthew & Son,
And they’ve been working all day, all day, all day!

Welcome to reality. Just be glad you’re not working all night, all night, all night. Night shifts are bloody horrible.

On balance, if Matthew & Son are hiring, I’d probably consider pinging them my CV.

Cake. I like cake.

Posted in music | 3 Comments

Logging classroom temperature on a Raspberry Pi

Today I logged the temperature in our ICT room as part of a wider Y7 project on data handling, spreadsheets and climate change. We’re taking real historical weather data, analysing it in Excel and making Word documents about our findings.

A simple Python script running on a Raspberry Pi logs the time and temperature every 5 minutes in a CSV file. I then opened the CSV file in Libre Office on the Pi and made a simple line chart.

The temperature sensor is part of the excellent CamJam Sensors EduKit thepihut.com/products/camjam-edukit-2-sensors – this costs an insane £7 for a tin box containing a breadboard, jumper wires, huge LEDs, a buzzer and light-dependent resistor.

See if you can spot:
a) when I turned the air-con on
b) when the classroom filled up with students
c) when those students turned their computers on
d) when lunch time was
e) when the afternoon classes arrived.

One problem I had was that the Raspberry Pi can’t get on the internet until AFTER it has logged in (it requires authorisation on a web page to join the school network), so to set the clock to roughly the right time & date I used the following command:

sudo date -s "Apr 20 09:30"

And here’s the Python 3 code, modified from the CamJam EduKit code. My new bit is at the end where it displays the temperature in the console but also writes the date/time and temperature to a file called temp.csv.

# CamJam EduKit 2 - Sensors
# Worksheet 3 - Temperature

# Import Libraries
import os
import glob
import time
from datetime import datetime

# Initialize the GPIO Pins
os.system('modprobe w1-gpio')  # Turns on the GPIO module
os.system('modprobe w1-therm') # Turns on the Temperature module

# Finds the correct device file that holds the temperature data
base_dir = '/sys/bus/w1/devices/'
device_folder = glob.glob(base_dir + '28*')[0]
device_file = device_folder + '/w1_slave'

# A function that reads the sensors data
def read_temp_raw():
    f = open(device_file, 'r') # Opens the temperature device file
    lines = f.readlines() # Returns the text
    f.close()
    return lines

# Convert the value of the sensor into a temperature
def read_temp():
    lines = read_temp_raw() # Read the temperature 'device file'

    # While the first line does not contain 'YES', wait for 0.2s
    # and then read the device file again.
    while lines[0].strip()[-3:] != 'YES':
        time.sleep(0.2)
        lines = read_temp_raw()

    # Look for the position of the '=' in the second line of the
    # device file.
    equals_pos = lines[1].find('t=')

    # If the '=' is found, convert the rest of the line after the
    # '=' into degrees Celsius, then degrees Fahrenheit
    if equals_pos != -1:
        temp_string = lines[1][equals_pos+2:]
        temp_c = float(temp_string) / 1000.0
#        temp_f = temp_c * 9.0 / 5.0 + 32.0
        return temp_c

# Print out and log the temperature until the program is stopped.
while True:
    fd = open('temp.csv','a')
    date = str(datetime.now())
    temp = str(read_temp())
    print(temp)
    fd.write(date+','+temp+'\n')
    fd.close()
    time.sleep(300)
Posted in computers, Raspberry Pi | Tagged , , | Leave a comment

What is the point of the BBC micro:bit mobile app?

I had another go with the BBC/Samsung micro:bit mobile app this week – and I’m afraid I was left wondering what the point of it is.

Now, I should admit I spent no more than an hour playing with it, mainly because I had to borrow the mobile devices as my own phone won’t run the app.

First I tried again with the Android version of the app on a Motorola Moto G phone, with an old and a fresh micro:bit, newly-flashed with some block code. And neither micro:bit would pair with Moto G phone after numerous attempts. I gave up. The reviews on Google Play are now littered with people who had similar Android pairing problems, so I know I am not alone with this.

Next I tried the iOS version of the micro:bit app on an iPhone 5C. This would pair with the exact same micro:bits, suggesting the Android app may not work with all phones – perhaps it only works with Samsung products since it’s their app?

I managed to write and flash some code from the basic block editor on the iPhone to the micro:bit, but I found using the block editor very fiddly on a phone screen – I think you need something tablet-sized at least.

There were two problems: the buttons to compile the code got easily lost off the top of the screen and were hard to get back to; and on my first attempt I could not edit the text in the ‘show string’ block – though this did work normally on a later attempt.

The compiling process does work for the block editor on an iPhone, though it’s not quite seamless. You get presented with this screen:

You then click on ‘open in micro:bit’ and then you can flash the HEX file to the micro:bit over Bluetooth. But man, is it slow! I mean, really slow, much slower than flashing over USB.

I had less luck with the official Python editor on the iPhone. When you compile the code you get an error message that makes sense on a desktop computer, but not a phone. You then get an error message saying the file cannot be downloaded.

Now struggling to find a reason to use the mobile app, I tried to write some block code to trigger an event on the phone:

I may have been doing something wrong, but even with the camera app open on the phone I couldn’t get it to trigger an event (other than displaying the words ‘say cheese’).

So: writing code on mobile devices is fiddly, pairing devices seems to be a lottery, and it’s very slow to transfer code. Add to this the fact that we are told only ever to power micro:bits from batteries or a computer’s USB port, and I am really struggling to see the point of the app, especially if you are powering the micro:bit from a computer that is easier to code on and faster to transfer the files.

If you have had better (similar, or worse) experiences with the mobile app, please let me know!

Posted in computers, education, ICT | Tagged , | 1 Comment