Sniff from Scratch

Now we've got a release running on microbit it seems like a good idea to run through some basic tutorials on using the Microbit with Sniff, and also some ideas for introducing kids to text based coding using it.

We've now got quite a lot of experience of introducing kids to Sniff, and generally spend about an hour moving them from blocks to text before setting them loose on a real project. I've been to presentations on "moving from blocks to text", which talk about how difficult it is, and how they spend sessions before hand "laying groundwork", and how emphasising parallels between the two systems, but with Sniff its something you can get out of the way within a single session and move on to something more exciting.

We start with a quick revision of Scratch, and I usually ask them to write two programs:

• ask for my name and then say hello using my name
• count from one to ten

The idea isn't that either of these should be hard - the exact opposite in fact. Kids should be able to make both of these in Scratch in a few minutes. In fact many struggle with the second example - they're not comfortable using variables or even loops...

Once they've completed those tasks in Scratch, we introduce Sniff - emphasising that its basically just Scratch written down. Typicaly we've made a desktop shortcut to the "clickMe" file which fires up a copy of SniffPad, so they click on that. The first program I write would be something like

when start

.say "hello"

Here we example that start is green flag, and that the dot attaches shows that the "say" is linked to the "when". Everyone types this in, and we explain compiling and running on the computer by clicking the compile and run buttons.

Then we write

when start

.repeat 10

..say "hello"

Now most of the handwork is done! So get the to rewrite the "ask your name" example in Sniff. They should be able to do this with only a little support:

when start

.ask "what's your name?" and wait

.say join "hello " answer

Refer them back to the Scratch version which you should keep visible throughout this part of the session. Some of them might have used the say mmm for n secs block in Scratch, but simply explain it doesn't make sense in Sniff, as the messages get printed out one ofter the other, so once its printed its always visible.

Before they can tackle the second example you'll need to introduce a couple of concepts using an example like:

make x number

when start

.set x to 22

.say [x]

The important things to discuss are that we're making a variable 'x', but that its specifically going to be number. In this case its the number 22, but when we print it out we print out two two. Two and two makes 22, because we're printing out the words not the number. X is a number, but say prints out strings so we put it in square brackets to convert the numbers to a string. There's a bit more going on here, but this is sufficient to get  things rolling. For now all they really need to remember is to put square brackets around numbers when they print them out.

With this in place we're ready to ask them to write

make x number

when start

.set x to 1

.repeat 10

..say [x]

..wait 1 secs

..change x by 1

I've taken children as young as 8 through this, though normally they'd be a bit older. They make mistakes, but simply reassuring them that typing errors are just part of programming, and getting them to read the error messages to fix problems gets them up to speed quickly.

It takes about an hour to get this far depending on the group, and they're now programming in text.  We've covered enough Sniff that kids can now just carry over their Scratch experience, start having fun. From here they can start editing their code. Everyone wants to count to a million! It takes a while but actually sitting watching it count that high (WITHOUT the wait!) is actually an interesting idea - sure it takes a few minutes counting at full speed, but its a few minutes to realise how big a million really is. Try counting down, count in 2's....

We're programming in text, without any painful moments!

We has Micro:bit!

It's been a rough ride with the BBC Micro:bit... We were really excited by the initial announcement, as its a perfect platform for Sniff, and Yr 7's are exactly the age group we think should be ready to move from blocks to text. Then came the waiting. We did some work on MBED to get things rolling, then then the MBED platform developed its own issues.

Finally we got our hands on a Microbit, last week and all is forgiven.  With a final blitz we've been able to get Sniff running on the Microbit. Because we're so excited about this we've pushed out a 27PRE special release. If you don't have a Microbit then stay away from it, as it may have introduced bugs on other platforms like Arduino, but it runs pretty well on Mac and Windows. If you're using Linux then it should also work, but you'll need to figure out the file paths for your system.

To run it, first set up a working Sniff install for your local machine (on Mac just unzip the Sniff download, Windows users follow the instructions in the recent post and demo video.

Then install yotta from mbed.org. This provides all the microbit tools.

Then plug in your microbic, and you should be able to start running Sniff programs on microbit either by hitting the microbit button in sniffpad, or compiling code with mb-sniff.

There are loads of demo and test examples in the examples/microbit folder, but (if your new to Sniff) you should probably start with blink:

make led digital output D2

when start
.forever
..set led to on
..wait 1 secs
..set led to off
..wait 1 secs

We'll have a full Release 27 in the next week or so, once we've check that we didn't break anything else by adding in the microbit code. I'll also post a few tutorials over the next few days.

Installing on Windows

Installing Sniff on Windows is a bit more tricky than on other platforms. This is mainly because both Mac and Linux provide a standard, more or less built in set of developer tools. While these might not be installed by default, they're pre-configured so they pretty much install automatically. On Windows we need to install a few things manually, and installing things on Windows is always a pain. There's also been some problems with these tools changing (and different version of windows), so here's an up to-date install guide:

Step One: Install MinGW

MinGW is MINimal Gcc for Windows. It provides the heavy lifting backend, to turn programs into executables. Go to their website, and click the button on the top right that say "download installer". Once its downloaded, run it and you'll get the option to configure your system. If you want you can install everything, but you simply need to select "base", and "msys". Click the Install button, and off it goes.

Once its done, you'll find you've got a folder C:\mingw (it's possible to install elsewhere, but lets not!). Inside that is C:\mingw\msys\msys.bat. This is the program we want, so drag a shortcut to the desktop/startmenu or wherever you want it. If you double click in it you'll get a bash shell - type "ls", and/or "pwd" to check its working (it's a basic Unix/Bash shell so you can pretend you're using a proper computer).

There's one more file to edit before you've got a working MinGW. Open the folder C:\mingw\msys\1.0\etc. In there you'll find a file called "ftab.sample". Copy this (or rename it) to fstab - no extension, in the same folder.

Now if you start another shell (running the msys shortcut) you'll find that the command "gcc" will say something like "no input files". That means its installed and ready to go.

Step Two: Install Sniff

Download the latest SniffW release. There's actually no difference between the Unix and Windows packages, but we just delete the un-needed bits from each version to keep the file size small. You can place the unzipped folder anywhere you like (please avoid path names with spaces in!), but its easiest to just put it in the users msys folder. To do that open an msys window and type "start .". Then drag the Sniff folder into the folder that has just opened.

Step Three: Lets Go!

In the Sniff folder there's  file called "clickMe.bat". If you do click it then you should get a working version of SniffPad, which you can use to get started writing Sniff programs. You can also create a shortcut to clickMe.bat and put it on your desktop (and rename it to something more memorable), to make things really easy.

When you run Sniffpad like this it runs in the Documents/SniffProjects folder, so you can copy any examples files from the release to that folder to run them.

At some point you'll want to do more than you can just using Sniffpad, so start an msys shell, then cd to the Sniff folder - it you've placed it in the Sniff folder as above, then "cd Sniff26WRelease" or whatever version you're using. Then type "source setup" or ". ./setup" (they both do the same thing) to initialise everything.

Now in the shell, you can run "sniffpad".  cd into the examples folders and off you go. For a more advanced user you can use any text editor you like, and compile programs from the shell, by typing "sniff myprog.sniff".

Step Four: Install Arduino

This step is optional - if you don't want arduino, then just don't install it. You can also install it any time afterwards. Download the installer from the arduino site, and do a regular/standard install. The next time you run the sniff setup, it will say that its found an arduino installation and now in sniffpad you can click the arduino button to compile and download to an Uno, or use uno-sniff to compile from the command line.

You should be able to use more or less any version of the Arduino IDE, but recent versions have a rather nasty bug where the compiler (actually the linker) crashes! This is a problem that the Arduino Forums have been struggling with for a while, as its difficult to reproduce - it only happens for certain programs on certain hardware. However it turns out that Sniff blows it up nearly every time! If you get an error message about "ld.exe", then  try downloading the Arduino 1.0 IDE, and using that. It's a very old version, but seems (at least for me) seems to work OK.

COM Port Discovery
When you initialise Sniff (either by clicking on clickme.bat, or "source setup' from the command line) it detects the first com port and tries to use that whenever it tries to talk to an Arduino, Flotilla, Picoboard, or Lego Control Centre. If you find that any of these aren't working, then try removing other serial devices, and make sure that Sniff is talking to the right piece of hardware.

And that's it... It's a bit more fiddly that Mac/Linux, but not really so hard.

Release 26: TLC for Windows

Release 26 is aimed squarely at Windows users.

Since we last did a windows focus release, a lot of things have changed in terms of the packages we rely on - MinGW, Arduino and Window's itself, so this time aroundwe've dedicated some time to getting everything to work as smoothly as possible for Windows users. We'll have a more detailed blog post soon, re-ittereating the Windows install requirements, but basically install MinGW/Msys, then just unzip the Sniff folder!

Now everything should run a bit smoother on windows, and we've even added a file called "ClickMe.bat"... which fires up sniffpad, and you can just start coding!

Unfortunatly the Arduino backend for Windows is crashing (its actually a bug in gcc!), so if you get a message that ld.exe is hanging when compiling for Arduino, try installing the old 1.0.6 version of Arduino.

If you're running Windows, then get over to the downloads page immediately. There's also few other minor fixes and features for everyone else too...

Banana Physics

Yesterday I presented a talk at ICT Conference for Schools, in Southampton. We're (hopefully) going to be presenting something similar in Boston this summer. I thought it would be good to just summarise it here, and post the code examples I showed.

Banana Physics starts with the Banana Piano - the classic Makey Makey project... or should I say the ONLY Makey Makey project. Despite their claim its an "invention kit" which can "make anything", their idea of "anything" is rather limited to being a keyboard made out of fruit! More or less any fruit you'd like!

In addition to being limited, we don't actually learn anything from the piano project. It's fun (for a few minutes), but what are we trying to teach? That Banana's are fun? The best thing we might learn is that Banana's conduct electricity... 

Except they basically don't. To understand we need to investigate RESISTANCE. If we use a pico board, instead or a makey makey we can actually do science!

This is the circuit that the pico board (and pretty much everything else) uses to attach your banana to the computer. R1=10K, and the banana replaces R2. With a bit of good old school Ohm's law, we can write an equation to calculate R. It turns out the Banana's have a resistance of around 40K-50K ohms. Not good conductors at all.

The next step is to drop a thermistor in place of R2. With a bit more complex maths, we can turn that resistance into a pretty accurate temperature (or up to 4 different temperatures on the different channels). It's pretty easy to log that data over time. On the one hand Picoboards aren't cheap (about £30 in the UK), that's really nothing compared what you'd pay for a 4 channel data logger, or even a good multimeter.

We then switch out the thermistor for a light dependant resistor. We could track light levels, but we can also use it to detect an object moving in front of the sensor. We set up two about 70cm apart, and time a beanbag to fall from the top one to the bottom one. Applying kinetic equations we know starting speed (0m/s), distance (0.7m), and we measure time. Which allows us to calculate acceleration - gravity.

Alternatively we can use the Lego Wedo... Two distance sensors make a great speed trap, so we can measure the speed of an object. If we drop the beanbag 70cm, and measure its final speed, kinetic equations will give us gravity again. In the talk I just did a very casual demo, and dropped it from a very rough distance, and it came up with a value of 8.5m/s/s. Pretty good.

The final demo was using the wedo tilt to measure the period of a pendulum. Again putting together  a bit of maths/physics, and coding I got a value of 10.5 this time. Again, this is pretty good for a guy standing in a room with a laptop and a few bits of Lego.

Here's the code I used for the demos. Check out the "Science" tag on my blog posts, to get more detail on these projects (perhaps built with different hardware), and ideas for other code based science.

The point of the talk was (in addition to promoting Sniff!), to show how using coding and making you can make high school science really fun. If coding is writing, then the whole point of learning to code is to unlock new ways of expressing and exploring. If coding just lives in the ICT class then its a total waste of time. If it lets you explore and understand the universe better, then that's pretty amazing.

Lego Dacta Control Lab B

So far I'm very skeptical about the Wedo 2.0. It's yet another lego electrical plug standard that's incompatible with both the existing Wedo/PF range or the EV3. That means not only do we have to buy new motors and sensors but we have only two sensors and one motor (where as Wedo 1 can use st least use several motor types, the servo, and lights). The argument that the new plug will by more versatile and flexible is exactly the argument that was used when the Wedo/PF plug replaced the older Lego 9V system, but in practise there were less components produced for PF than for the 9V system.

In fact looking back at the Lego 9V/RCX system, it seems the most complete, and well thought out of the many the different (incompatible) Lego electrical systems. While it is a bit limited, and in theory the more modern systems should have a technical advantage the older and simpler system has one fantastic thing in its favour: compatibility. 

While currently lego uses one plug for its technics range (Power Functions) another for Wedo 2.0, and a third for EV3, the older system used the same plug for all its products, so technics users could add an RCX controller. Even when NXT (and subsequently EV3) was introduced an adapter cable allowed 9v/RCX sensors to be used. Even today the Power Functions extension cable allows 9V motors to be used (and PF motors to work with 9V controllers).

The old 9V plugs were also simple: a positive and negative terminal which could either provide power, or be connected to a resistive sensor. With a bit of cleverness, they could be persuaded to do both at the same time, so powered sensors were possible. Putting the same system in the hands of the public, and educators led to an explosion of creativity (that neither the Wedo or the Microbit are able to enjoy!).

However while the 9v system is well remembered, one of its greatest creations is all but forgotten:

 Dacta 9751 Control Lab B

Look at that thing and ask yourself what more you could ask for from a system. 8 inputs, 8 outputs, connected via a serial port (so no drivers needed). Compatable with a wide range of cheap sensors. You'd need 8 wedo to do the same job! It was released in 1995, and its bigger and better than anything available now.

As for what you could attach, there were a choice of motors in various sizes, various types of lights, two different sirens, a light sensor, a rotation sensor, a button, and temperature sensor. The light sensor is actually very similar to the Wedo distance sensor (though not quite as robust), but the rotation sensor leaves the Wedo Tilt in the dust - It can measure angles of rotation in 22.5 degree steps, which compared to the Tilt's forward/backwards just shows how much we've dumbed down!

We were able to pick up one of these, and a whole load of sensors for less than half the price of a Wedo set. We also got some PF extension cables so we can use our existing PF motors (or hack them up to make new sensors!).

Cables:

If you have the original cables and PSU then great, but if they've gone missing, the PSU is 10V AC, 7VA. Note that this is an AC-AC transformer, so most PSU's won't work.

The second thing you need is a serial cable. Again most probably won't work! For you youngsters too you wet behind the ears to remember serial cables, gather round and I'll tell you about the olden days...

You see serial cables were designed to connect computers to modems. Modems would talk over a phone line to the another Modem, which would then have another serial cable to a computer. The Modems just passed the message along, so were called Data Communications Equipment (DCE), while computers were at the ends of the signal path, so were called Data Terminal Equipment (DTE).

Now if you've ever encountered a pin on a circuit board marked "TX" you'll know the dilemma - is this the pin that the board is transmitting on (so you connect it to your RX) or is it the pin that you should use to transmit, so connect it to your TX. Well with DTE and DCE its really easy: DTE is "in charge", so TX on DTE is an output, and TX on DCE is an input.

On a 9pin conector, pin 2 is RX and pin 3 is TX. Thats the same for DTE (male plug) and DCE (female socket) so you just connect all the pins straight across and you're good to go...

But what if I'm not talking to a modem? I'm talking to an I/O board here... They should both be DTE? Well the "correct" thing to do is to use "null-modem". In theory thats a small box that has a DCE socket on each side. You connect each piece of DTE equipment to the Null Modem and the null modem crosses over the RX and TX wires.

But that's a lot of hassle - two cables and a box when we could just make our I/O board look like a modem. Put a female socket on, wire it like a modem, and use a regular cable. Or we could just get one cable and put a twist in it, so we'd have a female-female null modem cable. Or we could do something totally crazy...

which is exactly what Lego have done... They've put a female (DCE) connector on the box, so you need a male-female cable, but they've wired it as DTE. That means you need a M-F DB9 null modem cable!!! They do exist and you can get them cheaply on eBay, but they're not the sort of cable you're likely to have in your bits box.

Between the odd PSU and odd serial cable I hate to think how many of these gems have been thrown away as "not working", when they just need hooked up properly.

With that in place, you'll probably need a USB-Serial converter - any with a DB9 connector on will do. While using old school serial might seem tedious compared to USB, the benefit is that we're now good to go - no drivers, or difficult code to write. Just send some text and it works.

Lets Go:

Even when you get everything hooked up, you still need the right software to get the thing to jump into life. I spend some time wondering if mine was broken, before getting it working reliably.

Plug it all together and fire up Sniff, release 25 or later. It should find the serial port (it'll call it an Arduino, but it calls everything an Arduino!). If you're on Windows you'll need to set ARDUINODEV to be the com port you're using. The example files are in examples/Hosted/dacta/test.

make lego dacta device

make legoValue number

make motor dactaMotor device 1

when start

.forever

..set legoValue to cos of (timer * 60 )

..tell motor to "update"

..wait 0.1 secs

To control a motor, the first thing we need is a dacta device. the variable legoValue is used to communicate with modules. We then create a motor device on port 1. To set its speed, just set legoValue and tell the motor to update. If your familiar with the old Wedo Sniff API then you can also communicate with a specific port by using the legoConnector variable, but the new style API is nicer. The Wedo also can use this new Object based style (check the examples).

To read from a device like a button:

make lego dacta device

make legoValue number

make button dactaTouch device 1

when start

.forever

..tell button to "update"

..say [legoValue]

..wait 0.2 secs

Interestingly the lego "Touch" sensors are actually analog, and can report the strength of the push rather than just being on or off.

The dactaLight, dactaTemperature and dactaRotation devices work in exactly the same way, returning a value whenever you call "update".

 One minor thing to watch is that the Control Lab has a fail safe - it if doesn't receive a message within 2 seconds it shuts everything down. Normally this isn't a problem as you're probably reading sensors more often than that, but if it is just add

when start

.forever

..tell lego to "update"

..wait 1 secs

somewhere in your program, and it will just keep the board alive.

The Wedo 1 is a great device, the Wedo 2 maybe in the future, but the Control Lab B is really the Mother of all Wedo! It's an amazing device, and its a shame that we can't have something quite as cool available today.

Release 25: Soul-Silver release!

Release 25 if Sniff is now with us, and brings the usuall cornucopia of goodies.

Features:

• SniffPad improvements
• Flotilla Support Improvements
• Lego Control Lab B support
• Improved Wedo Support
• Embedded GPS support

A big call out, and thanks to Robin Newman for his help it getting the Flotilla support close to complete. The new release is more stable, and supports the changes made to the Flotilla in in its "shipshape" update/pre-release - make sure your FW is updated to this. We've were unable to test the full Flotilla system "in-house" as we only had access to a small number of the modules. Robin's done a great job testing the code (often long before we got close to making it work),  bug fixing, and demoing the system. The Motion module is the one outstanding thing to build and we'll have that going in the next few weeks.

We also 'discovered' the Lego/Dacta 9751 Control Lab B... and just had to get hold of one, and add Sniff support. These are about 20 years old and are one of the first Lego/Computer systems. Look at what they had available then, and what they have now, someone is clearly going in the wrong direction - 8 inputs & 8 outputs, easily controlled from a computer without any complex drivers or installs needed - that's like 8 Wedos in one box! There are more (and better) sensors available than the Wedo, and you can pick them up super cheap second hand. I hate to think how many of these have been thrown away when someone couldn't get the SW to work, or because they're just "old". Grab em while you can!

As we were building the SW for the Control Lab, we looked at what we'd learnt developing for Flotilla, and built a more "object oriented" interface to it, than we had for the Wedo. So then we went back and re-worked the Wedo to support the new way of talking to this hardware. You can code for Control Lab or Wedo using either the old Connector based numbering system or using the new method.

We've updated SniffPad so that it now does basic keyword highlighting, and formats text a little nicer, so you can see what's going on in your code so much better. 

On other minor thing you might need to know... To make the Pi versions easier to work with we've moved the GPIO support from the "sniff" command. Compiling on Pi with the command "sniff" just generates a regular executable. This means you don't need to run it as root. To access the gpio you can compile with the pi-sniff command.