BBoard Theremin

It's been a while, as I sort of got tied up in other things, but one of the devices that's been sitting on my desk for the last few months is a BBoard.

These little boards from Al's Tech Garage have three LED's, two switches, a buzzer and a light sensor, and are designed for plugging into Arduino's. They're pretty nice, though my one gripe would be that the Pins are labeled B1-9, rather than what they actually do, so you'll need to keep this handy table close to hand at all times:

I happen to know Al (of Al's Tech Garage) likes plugging them into Arduino Nano's because they're super cheap. If you're using a Nano, then you can plug them along one side of the board, and use the following Sniff declarations to set up the pins:

make pwr digital output D2

make button2 digital input D4

make button1 digital input D5

make buzzer digital output D6

make greenLight digital output D7

make amberLight digital output D8

make redLight digital output D9

when start

.set pwr to on

This is a little naughty as it uses D2 as the power supply, but the board draws sufficiently small amounts of power that it should be fine.

To plug in to an Uno then you can plug the board in with B1 into A5. You'll find that B7 (the light sensor) falls in the gap where the Arduino has no pins, but then B8 and B9 conveniently land in Vin and 0V. Strictly we shouldn't use Vin here, as if you're using a non-standard power supply it could be greater than 5V, but if you're powering over USB this works great. Of course we can't use the light sensor, but that's probably OK if you're getting started.

In fact the most obvious thing you'll want to do is make a traffic light! Yes - you've got three LED's of the right colours, a couple of buttons and a buzzer all ready to go. what else are you going to do? I've already written about implementing traffic lights a long time ago using the PiBrella. To make that work on the BBoard, just change the pin definitions to the above and you're good to go.

The next thing I wanted to build was a Theremin, using the light sensor to detect how far away my hand was. Unofrtunatly to make that work I couldn't use the "easy plug" method above, so had to use jumper cables to wire up the bboard as:

make light analog input A0

make buzzer digital output A1

make switch digital input A2

To make a sound with the buzzer we need to push it in and out (you can also use it with the Sniff music device, which is really cool, but we won't do that now). That's really easy:

make halfCycle number

make buzzerOn boolean

when start

.forever

..set buzzer to buzzerOn

..wait halfCycle microsecs

..set buzzer to off

..wait halfCycle microsecs

If buzzerOn is "off" then this does nothing. If buzzerOn is "on","yes", or "true" then this pushes the buzzer in and out, making a sound. The frequency is controlled by the variable halfCycle.

For a quick test we can just set the halfCycle something reasonable:

when start

.set halfCycle to 500000/440

440Hz is the standard frequency of the note A, which everything else tunes to. If something is oscillating 440 times per second then the duration of each pulse is 1/440. However we want half of that so we have 0.5/440. Finally we want the duration in microseconds, so we get 500000/440.

Once that was working I could rewrite to use the light sensor:

make frequency number

when start

.forever

..set buzzerOn to switch

..#say [light]

..set frequency to (light*220)+220

..set halfCycle to 500000/frequency

..wait 0.02 secs

the reading of the light sensor can be between 0 and 1, so we set the frequency to a value between 220 and 440Hz (one octave). Then calculate the halfFrequency. We do this 50 times a second, as that was sufficient to produce a smoothly changing note.

And that's it a BBoard Theremin! it works pretty well as long as there's plenty of light.

Microbit Thermometers - is it hot in here?

If you go through the posts here, you'll find that a bit part of what we think is important is taking computing and linking it to the rest of the curriculum. We did a presentation at a recent event called "Banana Physics", which shows how you can use devices you probably already have like the Lego Wedo, and Scratch Picoboard to do real science (We'll also be showing this as a poster at Scratch@MIT2016). Measuring and recording real data and combining that with maths and physics to actually learn real things about the world - stuff you might have learned in KS4 or A Level physics in a chalk and talk class you can easily turn into practical sessions which put computing to work for real applications. By making it practical much younger kids can apply results from much more advanced theoretical classes.

One of the things you should absolutely do with your microbit is measure and record temperatures. This is one of the cheapest, and simplest pieces of equipment you can attach to a Microbit, so (as many of you are probably new to this),  I thought I'd do a quick roundup of the options available to do that:

Built in Sensor

Wait a minute, doesn't the Microbit have a built in thermometer? Well yes, sort of... it actually has two - one built into the bluetooth chip, and another in the magnetometer. So what's wrong with these? Well they're designed to monitor the chip, not the outside world. If the chip is working too hard, smart software will give it a rest to cool down (your phone does this, so it gets slower when it gets how. Similarly for laptops - they also use this to control the fans). As a result they can misleading readings. They're also not really calibrated, so you may need to add/subtract an offset before they're even slightly meaningful. 

make thermometer microbitTemperature device

make temperature number

when start

.forever

..tell thermometer to "read"

..say [temperature]

..wait 1 secs

As of release 28 (not out yet, as I write this), you can use this device just by telling it to "read". It's probably good for saying "its hot in here" at appropriate moments, but after that you should think about something more accurate.

Thermistor

The classic way to measure temperature is with a Thermistor - their resistance changes with temperature. The most common type is a 10K NTC, so you can connect one from 0V to D0, and a 10K resistor from D0 to 3V. We can measure the voltage using an analog input and use that to calculate the resistance (using Ohms law!), and then apply another equation to convert resistance to temperature:

make v analog input D0

make r number

make t number

when start

.forever

..say join "Voltage:" [v]

..

..set r to v/((1-v)/10000)

..say join "Resistance:" [r]

..

..set t to (ln of (picoRa/10000))/3950

..change t by 1/(25+273)

..set t to 1/t

..change t by -273

..

..wait 1 secs

The 10000 is the nominal resistance of the device at 25C. 3950 is the B value for the thermistor, and we need to remember to switch between C and Kelvin at appropriate points.

This does work pretty well, and should be pretty accurate. It's super cheap (a thermometer costs pennies), and for not much more you can get on enclosed in a waterproof case so you can put it "in" things to measure their temperature.

DHT11, DHT22

While thermistors are great,and the programming is at a level that if you put the equations on a worksheet kids should be able to work through it, the coding just to measure temperature is a lot of work in itself. Sometimes we want to do the measuring and do something with the result. In which case the dht11 (blue) is a go-to component for anyone doing this kind of thing. They cost less than a pound and can be just connected directly to 0V, 3V and a data pin (one pin is unused).

make thermometer dht11 device D0

make temperature number

make humidity number

when start

.forever

..tell thermometer to "read"

..say [temperature]

..say [humidity]

..wait 1 secs

Not only do they measure temperature, they also measure humidity. However they're not that accurate. If the data you're collecting is important, then you'll need to spend £2 on a dht22 (white). This is an almost identical device, but has a much better spec, for both accuracy and range.

make thermometer dht22 device D0

Functionally they're identical so all you need to do is swap out the line which makes the dht11 to one that makes a dht22. You can buy a load of dht11's for everyone to play with, and just replace them with a dht22, when it comes to actually recording real data. In fact you'll see that all of the devices apart from the thermistor work very similarly. They can also all be wired up to a 3 pin connector (0v,3v, signal) like the one on the MB^5 we designed.

DS18B20

The final way to measure temperature is using a DS18B20. Again these cost about £1 for a waterproof version, and connect via three pins to the microbit (you need an additional 4k7 resistor between signal and 3v). We used two of these connected to an Arduino to compare the temperature of our pond to the air temperature - it was very exciting! You can connect multiple sensors, of the same or different types to different pins  and see how different things behave differently (block box/white box/shiny box?).

make thermometer ds18 device D0

make temperature number

make humidity number

when start

.forever

..tell thermometer to "start"

..wait 1 secs

..tell thermometer to "read"

..say [temperature]

One gotcha here is that the ds18 takes about 1 second to take a reading. We don't want to hang around for 1 second doing a reading, so we tell it to start, wait 1 second and then come back to collect the result. If this starts to make your code more complex that you'd like, remember you can always do this in a separate script, and then just use the measured temperature in a another script.

DS18's are a bit timing sensitive, and don't work reliably on Microbit in Release27. Release 28 fixes this.

i2c

There are couple of other devices you can use (like the bmp180) which include temperature, that can be connected via i2c. However even if you have the kitronik breakout, it puts the i2c pins on a separate connector, making external i2c devices a bit clunky to wire up. In any case these devices are generally designed to do something else (air pressure) and temperature is just an "extra", so if you just want temperature they're not the best choice.

In summary, I'd go for a dht11 as my basic choice, dht22 if I need more accuracy, and ds18b20 if I need waterproof.

All of the simple devices can be easily attached to the Microbit just using croc clips if necessary, and if you have some kind of break-out then they can be wired to just plug straight in. Add an SD card and you've got a great data-logger. However you choose to measure temperature, its really easy and the potential to link coding, building and science is really great. What's the point in coding if you only ever code in computer class?

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.

Wedo Speed Trap

We've got a couple of live events coming up in the next few months, and at one of them we plan to talk about how the Picoboard, Wedo and Flotilla can be used to do "real" science experiments rather than just fun e-toys. While there's nothing wrong with fun gadgets and demo's to attract attention at some point we need to harness that interest and show that programming can solve "real" problems. (I need a way of advancing my presentation slides and all I've got is this size of pizza and a $50 interface box designed for this exact situation is neither real nor a problem). It doesn't really matter what that problem is, but there needs to be some element of writing code to do something that's extrinsically relevant (and better in some way than alternative approaches - pizza has many great features, but some kind of ir or bt remote is a way better and cheaper method of controlling slides).

This led to revisiting a few of our old experiments, and prepping to fit as many cool demo's into 30minutes as possible. On of the things we wanted to demo was the hot wheels speed trap, but based using the pico board or the wedo. Both proved pretty easy to do, but we found that the pico board doesn't deal well with updating more than about 100 times per second. It gets swamped somehow, and just gives up. This is fine for measuring longer time intervals, and we set up a tube, with a light sensor at the top and bottom to measure how long a beanbag took to fall the length of the tube. However for measuring the small intervals required of the speed trap it was too slow.

The wedo on the other hand proved to be very reliable, and worthy of a mention here.

We simply placed two motion sensors at opposite ends of a board, and measured that the distance between them. Just by being Lego we git instant "extra" value (I hesitate to say free value, as its stupid expensive), it makes a big difference just being able to stuck together some kind of structure, even as simple as this, just to hold things in place.

Then just wait for the first to detect something, then wait for the second and measure the time between them (15 studs 0.8mm per stud=12cm)

make wedo device

make wedoConnector number

make wedoValue number

make startTime number

make recordedTime number

make recordedSpeed number

make sensorDistance number 0.12

make message string 

when start

.forever

..say ""

..set wedoConnector to 1

..tell wedo to "readDistance"

..repeat until wedoValue < 0.06

...tell wedo to "readDistance"

..

..set startTime to timer

..say "go"

..

..set wedoConnector to 2

..tell wedo to "readDistance"

..repeat until wedoValue < 0.06

...tell wedo to "readDistance"

..

..set recordedTime to timer - startTime

..set recordedSpeed to sensorDistance/recordedTime

..

..set message to "time      :"

..set message to join message [ recordedTime ]

..say message

..

..set message to "speed     :"

..set message to join message [ recordedSpeed ]

..say message

The "readDistance" command sets wedoValue to an estimate of the distance in metres, so we check to see if its less tham 6cm. Then we switch to the second sensor and check that. Once we have the time, we divide that into the distance (14 studs x 0.8mm/stud) to get the speed.

If we drop a beanbag from a know height, and measure how fast its going when it passes the beam we can use the equation:

Vf^2=Vi^2+2ad

As we're dropping it, its initial velocity is 0, so we can simplify and rewrite as:

a=(Vf^2)/2d

So we can calculate gravity (again!) - it came out at about 9m/s/s this time, which is pretty close.

Best of all the sensor proved to be very robust. We've used light dependant resistors to do this sort of things before, and there's always a bit of tweaking involved to get the lighting, and threshold values just right. Because the lego sensors are self illuminating and (semi) calibrated, they work without requiring much adjustment in a wide range of conditions. The lego sensors detect things in front of them rather than shadowing them, which is much easier to work with. They're also easy to mount, so you could use them for all sorts of things where you need to measure speed.

The Esplora temperature sensor...

We got an Arduino Esplora for Xmas!! or more strictly a knock off copy. Official Esplora boards are way too expensive,  but copies are starting to appear, and for about £20 you can get a board, with a TFT screen included. We wasted no time getting everything working with Sniff, and we'll post details in a future post (once we've released the drivers in the next code batch). However its basically an Arduino Leonardo (use leo-sniff) with a bunch of sensors built into the board.

While overall we're fairly positive about the board, when we started coding for the temperature sensor, we ran into some problems, which might be of interest to others using the board.

The first thing we found was that readings were inconsistent and jumped around. A little research showed that this is a fundamental design problem with the Esplora.

The board uses a tmp36 and we can learn all about those from those helpful people at Adafruit. The great thing about the tmp36 is that it outputs a voltage dependant on temperature of between 0.2 and 1.75V over a range of -25 to 125 degrees. We can easily convert a given voltage to temperature using:

T=(1000V-500)/10

In other words the tmp36 is a solid, well thought out/built device that is well suited for many applications. However its inclusion in the Arduino isn't well thought out or well suited.

The AVR has a 10bit ADC, so when we apply a voltage to an analog pin we get an integer value:

A=(Vin/Vcc)*1024

Or to put it another way, our estimate of Vin is:

Vin=(A/1024)*Vcc

Dropping that in to the first equation gives:

T=Vcc*100*(A/1024)-50

and as Vcc is 5V

T=500*(A/1024)-50

which is exactly the equation you'll find inside the Esplora library. But here's the first real problem... What happens if we change A by 1? T changes by 500/1024 or about half a degree. The absolute  best we could hope for is that the temperature is going to change in half degree steps.

Now that would be OK in many cases - accurate to the nearest 1/2 degree over a range of -25 to 125 degrees is pretty impressive. The ds18b20 is a similar, or worse spec, and its great - I regularly drop it in coffee, or buckets of ice to see what happens. But the ds18b20 comes in a waterproof case on the end of a wire. The sensor on the Esplora is soldered to the board underneath the TFT screen. It's only going to measure air temperature in nice people friendly environments. Drop it in boiling water and you've got a bigger problem than half degree errors. Most of its life is going to between 20 and 25 degrees. Getting it wrong by 0.5 degrees is quite a lot when you'r only expecting a swing of 5 degrees anyway. Had the designers being paying attention to that graph on the Adafruit page they'd have noticed its got three lines on it, and the other two which represent the tmp34 and tmp35 are much steeper. In other words they give a bigger voltage swing for a given temperature change.With the tmp36, even in extremely hot or cold rooms we're never going to see more than a 0.1V swing, which the AVR ADC just isn't sensitive enough to measure well. They picked the wrong component for the job.

But things get worse... That half degree accuracy is only good if was assume our device is operating perfectly. A 10bit ADC might give you 10 bits of accuracy, but it probably won't. That last bit or two is going to wander around as it picks up noise from the surrounding circuits, so the reading jumps up and down by half a degree, essentially at random. Fortunately we can fix this by averaging the results. I averaged 10 results taken over 1 second and was able to get something fairly stable, and if the noise is truly random it can actually make the results a bit more accurate...

So wrote a demo app, averaging the temperature, which was reading a consistent 23 degrees and displaying it on the screen. Then I moved it to run from a USB PSU, rather than from the computer and the temperature reading dropped 5.5 degrees. Moving it back to the computer and it was high again. Moving it from the USB hub to being directly plugged in dropped it 5 degrees.

Going back to a previous version of our equation:

T=Vcc*100*(A/1024)-50

We simplified this using Vcc=5, because USB runs at 5V... except it doesn't. USB specifies a voltage between 4.75 and 5.25. There's always a margin of error, and its considered OK to have a value +-5%. That corresponds to a 5% swing in T+50, or about +- 4 degrees at room temperature.

Using a USB Voltage/Current meter I was able to measure my power sources, and found that my USB hub is borderline out of spec, giving a low voltage, and hence high temperature. Both the Mac port, and the USB battery are pretty close to being right on spec, but even the difference of 0.04V was enough to give a small change (after averaging).

USB hub: 4.7v 23.9C

Mac: 4.99v 18.8C

Battery 5.03V 18.3C

Unless you trust your power supply totally the sensor is accurate to with 4 degrees. Again that would be fine if we were measuring a range of temperatures, but as we're limited to measuring air temperature 4 degrees either way of a 22 degree reading is not knowing if its 18 degrees (put a jumper on) or 26 degrees (open a window).

At one point I was plotting the temperature on the screen and got a regular up/down cycle. It turned out my USB volt meter was dropping the voltage by a few mV every time it switched from volts to amps reading... enough to give a systematic temperature variation.

For reference I hooked up a dht11, and a ds18b20 to the tinker kit ports of the Esplora, and set it to display all three recorded temperatures. The DHT11 and ds18b20 produced different readings but they were consistent when I changed the power source. The DHT11 is known for being inaccurate, but if it constantly reads high (as mine seems to) then you can calibrate around it.

Now you might argue that its just a fun/toy beginners board and that it was built to a budget, but that doesn't hold water. For a start the official boards sell in kits for £70. Also while its pretty easy for me as an experienced engineer to deal with these issues, someone less experienced would just be sat with a gadget that didn't work reliably.

Perhaps the worst thing though is that there are other solutions out there that would do the job better and more cheaply. A tmp36 costs about £1 on eBay (pennies in bulk), but a thermistor costs pennies on eBay (decimal points in bulk). They provide similar accuracy but because you thermistors as a potential divider Vin is proportional to Vcc, which means that in the equations Vcc just cancels out.

The real ironic moment is when you realise they picked a component: the tmp36 that has as a design feature that Vout is independent to Vcc. The tmp36 behaves the same even if the voltage changes... which in this case directly leads to us getting the wrong results. It's not the tmp36's fault... They just picked the wrong component!

Sniff and Flotilla

I recently posted that my Flotilla Medium starter kit had arrived, and I documented the low level code that you might find useful if you were going to write your own code to talk directly to the hardware. You could actually to that yourself entirely in Sniff using the serialPort device, but the plan was always to add Sniff devices to support the Flotilla.

I've now got those working, and you can download them and add them to an existing Sniff installation. Normally I'd release this as part of a full Sniff release, but it's getting close to Xmas, and I probably won't get a full release out until the new year. There's a particular cool feature that needs a little more work, so I'm holding off until that's fully working. In the mean time here are the files you need to try it out. The drivers (in the XHosted folder) need to be added to the lib/XHosted folder you already have. There are also some examples which I'll talk about now... [Update: as of R24 Flotilla support is included i the current release]

To compile the examples, use the normal "sniff" commands. On Unix platforms the Flotilla gets found the same way as an Arduino when you run "./setup". On Windows you'll need to explicitly tell it by typing:

export ARDUINODEV=COM4

or whatever port you have it on in the shell after you've run setup.

make flotilla device

make light flotillaLight device

make brightness number

when start

.forever

..tell light to "update"

..say join "Brightness:"[brightness]

..wait 1 secs

The first thing you need to do is make a flotilla device. This represents a the flotilla dock and much like the dock you don't actually need to do much with it. It just acts as a hub for all the other devices you might want to use.

Once you've got a dock you can make an actual module and do something with it. Here I've attached a light module, by making a flotillaLight device and calling it light. The Flotilla has 8 ports, but you can plug the module into any of them - Sniff will look for a light sensor and use whichever port it finds it on. However if there isn't one plugged in then it will give and stop your program.

Alternatively you can specify which port the module is plugged in to:

make light flotillaLight device 4

This has the advantage that if you've not plugged it in yet you'll get a warning message but your program will keep running, and you can plug the device into port 4 later. In future you'll also need to use this if you want to plug in multiple devices of the same type (the mega-treasure chest includes two light modules and two motors). At the moment you can only attach one of each type of module, but that'll be fixed before the full release.

To read or write a sensor, just tell it to "update". You can also tell the dock to update, which you might want to do if you're not updating any other sensors for a long time just to give it a chance to do any housekeeping work, but this generally shouldn't be necessary.

In the case of the Light sensor "update" sets the variable brightness and we just print it out.

make flotilla device

make thermometer flotillaWeather device

make temperature number

make pressure number

when start

.forever

..tell thermometer to "update"

..say join "temp :"[temperature]

..say join "pressure:"[pressure]

..say ""

..wait 1 secs

Weather works in the same way, setting temperature and pressure.

make flotilla device

make keypad flotillaTouch device 

make key1 boolean

make key2 boolean

make key3 boolean

make key4 boolean

when start

.forever

..tell keypad to "update"

..if key1

...say "1" 

..if key2

...say "2" 

..if key3

...say "3" 

..if key4

...say "4" 

..wait 0.1 secs

Touch sets the four variables to be true of false depending on if the button is pressed.

Rainbow is the most complex module in the Medium kit, and works just like the neoPixel device, except that we change the names.

make flotilla device

make rainbow flotillaRainbow device

make rainbowShade list of numbers

make rainbowColor list of numbers

rainbowShade is the brightness (between 0 and 100), while rainbowColor is the hue between 0 and 360. 

Rainbow Thermometer

Lets look at how we can use that to make "thermometer":

make flotilla device

make sensor flotillaWeather device 

make temperature number

make pressure number

make rainbow flotillaRainbow device

make rainbowShade list of number

make rainbowColor list of number

make counter number

when start

.repeat 5

..add 0 to rainbowColor

.

.forever

..tell sensor to "update"

..#say [temperature]

..

..delete all of rainbowShade

..set counter to 1

..repeat 5

...if counter*2+20<temperature

....add 10 to rainbowShade

...else

....add 0 to rainbowShade

...change counter by 1

..

..tell rainbow to "update"

We make a rainbow and a weather device, then fill the rainbowColor list with 0's representing red. Then we read the temperature, and fill in rainbowShade. Using counter, we calculate a value for each LED from 22 to 30 degrees. If the actually temperature is greater than that we turn the LED on (red). If its less than that we turn it off.

The result is a thermometer that displays temperatures from 20-30 degrees in 2 degree steps. This is a handy range as its easy to see the display change just by holding the sensor.

Altimeter

One of the neat things you can do with the weather sensor is measure altitude. We did this last summer using an Arduino and BMP180, but now we can do it with Flotilla. The code required virtually no changes - just swapping out the BMP180 for a flotillaWeather module:

make flotilla device

make sensor flotillaWeather device

make pressure number

make temperature number

make altitude number

make seaLevelPressure number

make seaLevelTemperature number

make message string

when start

.tell sensor to "update"

.set seaLevelPressure to pressure

.set seaLevelTemperature to temperature+273.15

.

.forever

..tell sensor to "update"

..broadcast calculateAltitude and wait

..set message to join "Temperature:" [ temperature ]

..say message

..set message to join "Pressure:" [ pressure*0.01 ]

..say message

..set message to join "Delta:" [ (pressure-seaLevelPressure)*0.01 ]

..say message

..set message to join "Altitude:" [ altitude ]

..say message

..say ""

..wait 1 secs

when calculateAltitude

.set altitude to seaLevelPressure/pressure

.set altitude to ln of altitude

.set altitude to altitude * 0.1903

.set altitude to e^ of altitude

.set altitude to seaLevelTemperature * (altitude-1)

.set altitude to altitude/0.0065

Check the original post for more details on this one. You might need a longer USB lead to get the most out of this example but its still pretty cool

Simon

Finally I wanted to do something with Touch, so I build a game of "Simon". The computer flashes the Rainbow LED's in a sequence which gets longer each turn, and you have to copy the patten on the keypad.

make flotilla device

make rainbow flotillaRainbow device

make rainbowShade list of numbers

make rainbowColor list of numbers

make keypad flotillaTouch device 

make key1 boolean

make key2 boolean

make key3 boolean

make key4 boolean

make pattern list of numbers

when start

.repeat 5

..add 0 to rainbowShade

.

.add 0 to rainbowColor

.add 120 to rainbowColor

.add 240 to rainbowColor

.add 60 to rainbowColor

.

.tell rainbow to "update"

.

.forever

..broadcast playGame and wait

..wait 5 secs

This is standard flotilla setup. Then we have a list called "pattern" that we're going to store the pattern so far in. We put four distinct colours in the rainbowColor list, but turn all the LED's off by setting their brightness to 0. Then we're ready to go...

make counter number

make led number

when playPattern

.set counter to 1

.repeat length of pattern

..set led to item counter of pattern

..replace item led of rainbowShade with 10

..tell rainbow to "update"

..wait 0.3 secs

..replace item led of rainbowShade with 0

..tell rainbow to "update"

..wait 0.1 secs

..change counter by 1

To play the pattern we  simply loop over the list turning on the required LED of a short period with a smaller time gap between each.

when playGame

.delete all of pattern

.forever

..add pick random 1 to 4 to pattern

..broadcast playPattern and wait

..

..set counter to 1

..repeat length of pattern

...set led to 0

...repeat until not led = 0

....if key1

.....set led to 1

.....wait until not key1

....if key2

.....set led to 2

.....wait until not key2

....if key3

.....set led to 3

.....wait until not key3

....if key4

.....set led to 4

.....wait until not key4

...if not led = item counter of pattern

....broadcast flash and wait

....stop script

...change counter by 1

To actually play the game we add a random led to the pattern so far then play it back. Now we need to check the the touch pad. We go through the pattern one step at a time and wait for a key to be pressed. We record the key press then wait for the key to be released.... This is important otherwise just touching one key would be recorded multiple times.

Then we check that the key pressed was the right one. If it wasn't we run a script called flash to indicate failure, and end the came. If we get to the end of the pattern then we go background, add another light to the sequence and keep going!

when start

.forever

..tell keypad to "update"

..set dummy to pick random 1 to 10

..wait 0.01 secs

You'll not that when I'm checking the buttons I'm not calling update. I need to keep calling it, otherwise the variables representing the keys will never change, but it would make the code messy, so instead I've got a separate script which just keeps calling update. (it also randomises the game by throwing away random numbers - I've talked enough about that in other posts).

when flash

.repeat 5

..delete all of rainbowShade

..repeat 5

...add 10 to rainbowShade

..tell rainbow to "update"

..delete all of rainbowShade

..repeat 5

...add 0 to rainbowShade

..tell rainbow to "update"

That just leaves flash which is pretty obvious.

Conclusions

And that's about it. So far I'm pretty impressed with the hardware. It's really nicely built, and the design allows for lots of expansion. Price wise its not cheap - the Medium kit with a dock and four modules is £39, but its not too bad. Based on the prices of the different sized starter kits I'd expect individual modules to cost between £5 and £10 (some costing more than others) when they become available. Many of the modules have arduino compatible equivalents that cost about £1, but that's from overseas suppliers. From a regular UK seller they'd cost about £4 so a couple of pounds extra to have something kid friendly and just plugs in and works is actually good value. For comparison LittleBits charge $18 for their temperature sensor!!! On the downside, having got the Medium kit up and running,  I want to do more with it than I can with just four modules, so I will need to get more modules...

Where the HW has real potential is for expansion. The design allows new modules to be added. There are currently 12 available, but I'm surprised the so called "pirates" at Pimoroni forgot to include a compass. A 16x2 LCD text screen would also be simple to add. Right now its a nice piece of fun, but wth an ever expanding range of modules at good prices, then this could be a really great piece of kit.