Friday, April 08, 2016

Tech giants and commercial weather and climate prediction

Update: See also http://arstechnica.com/science/2016/06/with-iphones-and-computer-models-do-we-still-need-weather-forecasters/



Much like aerospace and telecommunications the world of weather prediction has been dominated by government departments and international organisations for most of its history. However in recent years things have really started to change. Sure there have always been one man and a dog private outfits selling wishful thinking to newspapers, much as the astrologers do, but detailed accurate forecasts for the last 25 years or so have always been the product of specialised computer models running on high performance computers, the so called supercomputers from makers such as Cray.

Every country in the world has a weather service, as a minimum it makes observations that it then shares as part of a global network and issues forecasts for civil aviation. Most do a great deal more, providing valuable services that protect life and property and enable effective use of natural resources for the production of food, energy, and more. Only the very largest and wealthiest run sophisticated computer models providing accurate forecasts for land, sea and air across the globe. However an established practice of international collaboration means that weather services in even the poorest, or poorly governed, countries have access to a constant stream of forecast model output, satellite imagery and other data.

So what are these recent changes? Well two recent, and significant, news story headlines look like this -


What do these developments mean for users of weather forecasts and the established national weather services? One way of trying to evaluate these developments is through the sort of tools and thinking used by MBA graduates.  These are the type of managers who are often brought in to make such business decisions in the first place, and also to evaluate the moves being made by rivals.
One such tool would be Porter's five forces, there's a simple introduction here at MindTools
In the case of Panasonic we find that they've moved from being one of many suppliers to one, albeit globally important, national weather service to being a rival forecasting service.   Apparently this wasn't planned, so also shows how it's now relatively simple to acquire and use the technology and expertise needed to "launch" a weather forecast model.

From 2004 to 2011 it also sold its airplane weather data to NOAA. In reviews of the usefulness of that Panasonic weather information, known as Tropospheric Airborne Meteorological Data Reporting, or TAMDAR, agency employees reported that it significantly improved their forecast skill.


But when budget cuts came, the agency stopped purchasing from Panasonic. The company shifted its business to making custom forecasts for the private sector, Jacobs said, even though its original business plan was based on selling to NOAA. http://www.eenews.net/stories/1059997252 April 2014

Most scientists, forecasters and administrators in the existing major government owned weather services are likely, for the time being, to react - So what? We've got forecasts that are at least as good and are continuing to improve, and in those smaller services that receive free forecasts from ECMWF and similar they'll be unable to imagine ever being in a position to buy an expensive commercial service. I expect the decisions as to what happens next will likely be made elsewhere, so their position might not be all that important. There are now commercial services that can directly substitute for what are very complicated public services involving international collaboration, rapid sharing of data, the development of space programmes, standards, and much more.  I'm impressed - this will, I'm sure, very quickly change the world I work in.

More about IBM's weather services
 http://www.ibm.com/analytics/us/en/business/weather-insight.html

More about Panasonic's weather forecasting platform
http://www.airdat.com/about-airdat/

And latest news is of IBM also showing an interest in aviation services
http://www.zdnet.com/article/ibms-the-weather-company-partners-with-gogo-for-real-time-turbulence-reports/

Tuesday, September 01, 2015

Tim Hunt and being #Dawkinsed

For a couple of days my Twitter notificiations have been flowing fast and furious.  Here's why.


TL;DR

Getting the last laugh is (I believed) a common English idiom.  It has nothing to do with belly laughs and little to do with jokes, hence what I felt was a cleverly constructed Tweet.  Let me explain; to me it means despite early ridicule a person goes on to achieve more than those who mocked. Usage might be something like this -

They mocked him at school for his shyness with girls but got the last laugh when he married the prettiest woman in the lab, followed by a Nobel prize!

Clearly achieving greatness and then being mocked is not getting the last laugh.

Long version for those with interest in who Professor Tim Hunt is, sock puppets and more

Right now, Tuesday evening, the number of retweets and favourites for Dawkins response stands at 53 retweets and 239 favourites.  Follow the link to check for any updates, and maybe check out who all these Dawkins fans are.

https://twitter.com/RichardDawkins/status/638109171129425921

Odd eh?    So what's going on?    I'll fill in more as time permits but thought I'd better jot down some notes while I have time.   I did find this rather interesting, and probably relevant blog post that seems to relate, and well worth reading.

The Value of 3 Degrees of Separation on Twitter by Hilda Bastian.

Distinguished Me

As for Dawkins's question, I assumed it was rhetorical, since If I was properly distinguished he'd already know who I was, and perhaps even leap to my defence - after all I'm a 50 year old white Englishman and lifelong atheist.  Well except as a young child, since my parents had the sense to protect me from indoctrination.  However I did go to school, so have a reasonable, if imperfect, command of my native language.  Which, IMHO, is the significant matter here.   What??? you screech in a determined effort to be offended by my lack of regard for a Nobel laureate.  Well take a look at this -



http://www.telegraph.co.uk/news/science/science-news/11732143/Sir-Tim-Hunt-deserved-to-lose-his-job-over-chauvinist-comments-Nobel-Prize-winner-says.html

And if you favour the spoken word there's this -

BBC Radio 4 Today Programme - Tim Hunt

Though not distinguished I am from time to time available for a chat.  So if you'd like to meet and discuss any of the things I do have real knowledge of, and Tim Hunt isn't one, I'll be in London a couple of times in coming weeks.

Digital Design Weekend at the V&A  26 and 27 September.

 and

Mozilla Festival 7 and 8 November.


I'll make no claim that meeting me would justify the ticket price, but fortunately it's an absolute bargain anyway if you have even a passing interest in technology, the web, and our freedom to express ourselves online.


Final word


Afterword (10 Nov 2015)

The campaign to exonerate Tim Hunt for his sexist remarks in Seoul is built on myths, misinformation, and spin.


Tuesday, April 07, 2015

Digital Design Weekend

September saw the return of a small Met Office team of volunteers to the V&A for Digital Design Weekend. This is a wonderful event that is growing each year, not just in size, but in confidence. This year there were new many collaborators, including clever folk from Uniform, who expertly, and very quickly, crafted a book to capture the maker spirit of the event.  You can read about the book on the Uniform blog.
What I find most rewarding about Digital Design Weekend, through the very informal meetings and Skype chats where Irini (V&A curator) helps us develop a vision and thinking about what we might do, is that it remains so open ended.  Yes the event happens, but of course each thing that happens causes other things to happen.  Which is why, in early April, I'm writing about something that happened in September; because in truth it really happened for me in September 2013, and will happen again this September.  So far, for me, Digital Design Weekend is very different each time, and each time new, amazing, things happen as a consequence.
Ian and Jasmine of BBC R&D wrote a blog post about Open Collaborative Making at the V&A.

It was also a pleasure to be joined by Genevieve Smith-Nunes and dancers who rehearsed and performed the digital ballet [arra]stre in a room shared with hackers and museum visitors.  There's an interesting blog about the data and visualisations by Peter Cook -  [arra]stre Data Animations.
[arra]stre

Sunday, April 06, 2014

SensorTag and Raspberry Pi revisted

A year ago I posted some notes on my experiments with the Texas Instruments SensorTag and the Raspberry Pi - Raspberry Pi and TI CC2541 SensorTag.  From the comments received it's apparent that several others have done much the same.  So, thanks to their feedback this weekend I updated my ble-sensor-pi  github repository with a fix for more recent versions of the Bluez bluetooth library.  You'll also find in the README some notes on installing gatttool and enabling the bluetooth adaptor.
In the repository I've added a few extra files for anyone wanting to try sharing their data using Xively.  If you'd like to  try this out then you'll need to register - it's free - and create a new 'device'.  I've called mine 'Wearable Pi' which give a hint as to what I'm hoping to do with it.  Once you've created the device entry on Xively you'll need to create the following channels -
t006, accl_x, accl_y, accl_z, humd_t, humd_rh, baro_t, baro_p, magn_x, magn_y, magn_z, gyro_x, gyro_y, gyro_z
As the code is at present it will collect 10 measurement from each sensor at the default rate of one per second and then upload to Xively.  I did try uploading every second, but the Xively API only allowed this for burst of a few seconds.  There's obviously an opportunity here for some clever optimisation -  upload at a high rate when the data is changing rapidly (shake the SensorTag) and at a lower rate when readings are stable.  It will depend on your intended application.
As before I'm happy to take corrections and questions in the comments.  It would also be nice to know what others are doing with their SensorTag Raspberry Pi combo - so please share.
I'll be taking mine along to the 3rd International Space Apps Challenge on 12/13 April 2014 and maybe hacking some prototype space wearable tech.  

Thursday, March 13, 2014

The shed project

As some of my friends already know, for the last year Kathryn and I have been working with a local architect to design a new workshop at our home.  Planning consent has now been granted so if all goes to plan construction starts this summer.

This is what it should look like when complete.







 And here's what it looks like now.


Wednesday, September 25, 2013

Climate Change and Fashion Hackathon

On September 21st and 22nd 2013 a group of scientists, artists, and designers spent the weekend in the V&A Museum in London imagining future fashions in a world adapting to changing climates.

A design by Professor Helen Storey.
And another from Exeter College fashion students.
Ross tells a story, with his Peltier wrist band at the ready.

Some of the amazing items created by the teams.







 Listen to the judges thoughts on this event.

On other blogs -
Hacking in front of an audience
Fashion Meets Climate Change at the V&A

Tuesday, September 24, 2013

Geohack at FOSS4G Mappingham

A week ago I was at Nottingham University with other from the Met Office hackathon team setting up tables, chairs, and the rest, ready for the two day Geohack geospatial hackathon.  Of course the preparation for the event started months earlier as part of the even bigger effort of preparing for the FOSS4G conference.  FOSS4G is an international gathering of open source geospatial developers, and although I wasn't able to stay for the whole conference several of my colleagues did and it seems like it was a really well organised and interesting event.  There were certainly some great folks there judging from those who turned up a couple of days early to join the hackathon.
The hackathon was open to delegates and others who registered on the Geohack website. It was free to attended and you even got the traditional hackathon pizza and beer.

 It was an international gathering, so I got to meet and hack with folks I wouldn't normally get to meet back home in Devon.   Here I am with Willow Brugh and Steve Citron-Pousty doing that thing where everyone stares at their gadgets rather than have a conversation.
Seriously though, we had a good chat and hopefully we'll find more chances to work together if only for a couple of days.  Once Steve got over his jet-lag, or more likely just learnt to live with it he got stuck in and managed to "sell" OpenShift as the solution most of the teams needed.   He even found time to write a great blog post.

All the teams produced excellent work, and I wouldn't be at all surprised to see at least one or two turned into real services over the next few months.

So why didn't I stay for the whole of the excellent FOSS4G conference?  Well I had another hackathon to go to - of course.  More on that in the next blog post.

Sunday, September 08, 2013

Fashionably late - the Raspberry Pi bat phone

A few weeks ago I posted some early pictures of this project and promised I'd blog about  it. Although the hardware is done it still needs some software tweaks but I've decided to post some more pictures because I'm going to be really busy for the next few weeks and won't get much time for this project.

[ The reason I'll be busy is I'm doing two hackathons for my work, a geospatial hack  - http://2013.foss4g.org/geohack/ and a fashion hack - https://climate.makes.org/thimble/climate-change-and-fashion-hackathon ]

Hardware list -
Bakelite telephone. The earpiece is the original one but the microphone was a carbon type so I replaced this with an electret capsule.
USB audio adaptor. These can be imported from China via ebay.
Toggle switch and microswitches.  I've put a "sound/silent" toggle on the front, plus and LED with chrome bezel - all from the junk box.  The "sound/silent" plate for the toggle switch is from an old cine projector.
MCP23008 port expander. To interface the switches and LED to the Raspberry Pi using I2C (SMBUS).
WiPi - wifi adapter.
5V PSU.
Other than a few bits of wire, stripboard and the odd connector and nuts and bolts that's about it.

More pictures -





Thursday, July 25, 2013

Cassette is not dead inspired Raspberry Pi case

This idea for a Raspberry Pi case came a couple of months ago when I saw this
 - it's from OOO My Design.
Other than a cassette tape all you need to make it is a few nylon standoffs, or spacers.  I used nylon bolts too.  On the base I added an extra bolt to create a third foot for it to stand on.
A short length of leader tape is used to keep the case square.  Tie one end and use one of the cassette screws to fix the other end.
An extra bolt to the right provides a third foot.

Tuesday, July 23, 2013

8 pin MSP430 microcontroller - MSP430G2230

In earlier posts I've covered some experiments with NFC and UV sensors. I'm keen to take both these projects a little further and develop them into wearable devices.  The Raspberry Pi and Ardunio are great for prototyping such things, but to make something the size of a button will require a surface mount microcontroller.  At the weekend I came across the TI MSP430G2230, like the other MSP430 "value line" range these are very cheap low power 16 bit microcontrollers. Unlike the 14 and 20 DIL devices that are supplied with TI's incredibly cheap Launchpad these can't be plugged straight in. You'll need to either connect the programming lines to the SOIC chip somehow, or as I've done, build a couple of adaptors.  The first adaptor makes the MSP430G2230 into an 8 pin DIL device, and the second makes the 8 pin devices match the pins of the typical 14 pin DIL MSP430.

In pictures -

As simple as that!
I've found that it can be programmed in CCS as either MSP430G2230 or MSP430G2231 - it's the same device, but with some of its pins not exposed to the outside world.  The internal temperature sensor works fine,  so I reckon my first project will be to use the I2C interface to log temperature measurements to an M24LR dual interface (NFC/I2C) EEPROM.

Sunday, July 14, 2013

Building a UV Index recorder for MSP430, Arduino, Raspberry Pi. Part 1 - the sensor

A couple of weeks ago I found this is Lidl.

I did what any right minded person would do - took it apart to see how it works.


OK, so modern electronic gadgets aren't easy to disassemble and reassemble. Thankfully I had no great desire to put it all back together again. One nice thing was that the UV photodiode was on its own board. One interesting thing is that there's a skeleton potentiometer so presumably these things are calibrated/adjusted at the factory.

Google led me to this manufacturer as the likely source of the photodiode http://www.eoc-inc.com/UV-detector-GaN.htm and here's the datasheet for a device designed for UV Index monitoring http://www.eoc-inc.com/genicom/GUVB-S11SD.pdf
Good news is that device current increases linearly with UV Index,  bad news is it's measured in nano amperes.  Well I suppose that does mean the resulting device could be very low current; given the application it might as well be solar powered!
First things first,  I'm going to need an amplifier, so I went for a low power device I bought a few of a while ago but lacked the frequency response I needed, the TLV2252. Hooking this up on a breadboard with a circuit based on this one from http://www.ti.com/lit/an/sboa035/sboa035.pdf  I used 10M resistors and a 3.3V supply.


Covering and exposing the photodiode did nothing, so I started thinking I'd damaged it or the circuit wasn't right.  I swapped the UV photodiode for an LED and it worked like magic throwing the output to max when I directed a bright torch at it, so I swapped back the UV photodiode and went outside.  Yes it worked giving about 20mV per UVI.  OK, that's not a lot, but there's a second OP amp in the package so I used a 10K and 100K resistor to give extra gain of 10 and hey presto it's ready to interface to a ADC.   As it is the circuit draws less than 0.2 mA.



Sunday, June 23, 2013

It's Not For Crows - more NFC dabbling

Back in March I wrote about some simple experimenting with the  ST M24LR Discovery kit which feature a dual interface EEPROM - both NFC and I2C.  That kit got me thinking about how I might use NFC to move data to and from low cost devices.  Not just storing data on a tag, but mini data loggers and the like.   So I ordered a few parts to experiment with and yesterday I finally got around to building some I2C/NFC tags.  Here's one -
I wound my own antenna.  It this seems bizarre, consider that I grew up making crystal sets and the like - why would I miss the opportunity to wind a coil?  For anyone wanting to do the same,  it's 8 turns around a 4cm diameter former - in this case a plastic lid from a spice jar.  Slip the windings off and apply a few dabs of hot glue and it's done.  So far all I've done with this is read and write to it with my Nexus 7 tablet (NFC) and an Arduino Uno (I2C).  With this EEPROM no power, indeed no connections, are required when using NFC, just the antenna coil.
There was no particular project in mind when I assembled the parts, which is why I included the 0.1" pitch connectors to plug them into a breadboard.   What I notice once they were on the desk it that it's an ideal size to include in a Raspberry Pi case.  So I built another slightly different one.
This will fit inside the usual cheap type of case. Making this got me thinking about making a smaller one closer to the size of the pre-made tags you can buy but with the advantage of I2C.  So I built this -
The wire I used was Verowire, and the coil former is from the 1980s too. (12 turns on 2.2cm former)
Yes,  I reckon I'm going to build something gadgety into a cassette tape.  Not sure exactly what, but pretty sure it will use an ultra low power MSP430 microcontroller.
As for the Raspberry Pi interface, what I'd like to do with that is use it to change settings that are loaded on rebooting - so I can set up Wifi access codes using a phone or tablet, ideal for a "headless Pi".    

Monday, June 10, 2013

International Space Apps Challenge


What an amazing event!  Described by some as "a contest" - science.nbcnews.com though conceived as a hackathon in the Random Hacks of Kindness model.  See theatlanticcities.com for a different take.

Thanks to some incredibly enthusiastic and hard working colleagues the Met Office was able to host both Exeter and London events.

If you've never heard of hackathons or hack-days then most likely you don't work in IT, or you do, but don't surf the web, use social media, own a cat...  please keep reading.

For those who work in IT and haven't been to a hackathon -  it's like a free training course, with beer and good company.  Why do I say it's like a training course?  We'll it isn't really, but experience now tells me there's one type of IT guy (always a guy) it doesn't suit -  the one that already, thinks he, knows everything.

For those who aren't IT experts, and more and more are coming to such events, a hackathon is a chance to meet some really cool people who like making digital stuff, and prefer prototypes over long winded presentations and reports.  At a hackathon you'll see impossible ideas turned into amazing examples of digital genius.

What am I going to do next?  We'll I don't have total control of anything much, but I'm always happy to share ideas and try out new things.

Now some quick notes to self -


  • Back at the V&A in September.  This may well become a "fashion hack",  more on how we're working with the V&A in another post soon.
  • Working with other organisations in the South West of England, Exeter and Plymouth Universities, DigPen. It's great that the Met Office was able to bring hackathons to Devon, but they really belong to the community and I want to find a way to hand them over, perhaps through sponsorship.
  • On sponsors.  Our events, including Space Apps have been supported by a few great sponsors. We're not selling advertising, we're encouraging others to be a part of what we are doing and they seem to get this. I'm sure there are other organisation out there who'd like to join the party. 

What I'd really like to do - so will put some effort into, and yes do contact me if you'd like to help - is create events that wouldn't happen otherwise.

Saturday, April 06, 2013

Raspberry Pi and TI CC2541 SensorTag


Texas Instruments have yet another low cost development kit.  The SensorTag is a Bluetooth Low Energy (BLE) key fob filled with the sorts of sensors that you'll find in the latest smartphone - pressure, temperature, humidity, accelerometer, gyroscope and magnetometer. See the SensorTag User Guide for full details.

If you're interested in experimenting with the SensorTag and you've got one of the latest iPhones, or iPads, then there's no need for you to be reading this,  pop over to Texas Instruments SensorTag page and the ByteWorks blog.  For Raspberry Pi and other Linux users I'll describe what I've figured out so far.

What you'll need

The hardware is really simple, in addition to the SensorTag which can be bought direct from TI post free, you'll need a BLE (aka Bluetooth 4.0) capable dongle.  I'm using a Plugable USB-BT4LE which can be bought on Amazon.  A PC running Linux - Ubuntu 12.10 seems to have everything needed as standard, and it was by testing on a laptop with the Plugable dongle I was able to prove to myself that the dongle and SensorTag both worked and would communicate.   However,  the rest of this post will be about using the RaspberryPi, because that's what I set out to make work.

Software

This is my first RaspberryPi project so I started with a standard Raspbian "wheezy" image.

Testing

Finding the SensorTag
$ sudo hcitool lescan

LE Scan ...
90:59:AF:0A:A8:4E (unknown)
90:59:AF:0A:A8:4E SensorTag
ctrl c

Connect to the discovered tag
$ sudo hcitool lecc 90:59:AF:0A:A8:4E

Switch on a sensor and read its value
$ gatttool -b 90:59:AF:0A:A8:4E --interactive


[   ][90:59:AF:0A:A8:4E][LE]> connect
[CON][90:59:AF:0A:A8:4E][LE]> char-read-hnd 0x25
[CON][90:59:AF:0A:A8:4E][LE]>
Characteristic value/descriptor: 00 00 00 00
[CON][90:59:AF:0A:A8:4E][LE]> char-write-cmd 0x29 01
[CON][90:59:AF:0A:A8:4E][LE]> char-read-hnd 0x25
[CON][90:59:AF:0A:A8:4E][LE]>
Characteristic value/descriptor: a3 ff 7c 06
[   ][90:59:AF:0A:A8:4E][LE]>

The values 0x25 and 0x29 are "handles" that we either read from (0x25 holds the thermometer reading) or write to (0x29 must be set to a value of 01 to turn on the thermometer)

See http://processors.wiki.ti.com/index.php/SensorTag_User_Guide#Gatt_Server for details of the sensor handles.  We can also ask the sensors to send a continuous stream of readings.  To do this enter "char-write-cmd 0x26 0100", a value of 0000 will turn the stream off.

A working program

Having figured that out I wrote a simple python script that uses pexpect to drive gatttool.  Grab a copy from github if you're interested.

Building gatttool

I had to build my own copy of gatttool as the version included in wheezy wasn't able to write values to the sensor. To build bluez-5.2 you need to "apt-get install" the following - libglib2.0-dev libdbus-1-dev libusb-dev libudev-dev libical-dev systemd libreadline-dev

See comment from Klaus Seiler on how to build.





Sunday, March 03, 2013

Internet of little things

Not for consumers

Yesterday I read Rory Cellan-Jones' article about NFC which pretty much shows that so far there isn't a consumer killer app for NFC. I'm not a professional pundit, so I'm not going to argue with him, but reading his article made me decide to do some first experiments.


Before Christmas I had an idea that low cost lower power data loggers could use NFC to send data to a mobile phone. I mean really low cost, pence, and really low power, like a watch battery.  In fact a watch would be a good example of the kind of device I'm thinking of,  it could be set to current time anywhere in the world just with a tap from a phone. More recently I saw that Farnell are now stocking the new ST M24LR Discovery kit, it costs a few pounds and features an energy harvesting NFC/I2C EEPROM and everything needed to read and write data, including an LCD display.


Learning with the Arduino

I'm an infrequent Arduino user as I feel cheap though it is, it's overkill for much of my tinkering. However it's an ideal system for experiments with I2C bus devices.
Here's what I wrote.  It's a fairly simple program that writes some text to the M24LR04E, which it then reads back. The text can also be read using an NFC phone, or the Discovery kit USB NFC transceiver. The program also reads the current temperature from the I2C temperature sensor included on the Discovery board.




// Use the Arduino to talk to ST M24LR-discovery board.
// Michael Saunby. March 2013.

#include <Wire.h> //I2C library

// Deviceaddress is a 7 bit value. i.e. the read/write bit is missing and the rest
// is shifted right.
// i.e. deviceaddress = 0x53 is sent by Wire as 0xA6 to write or 0xA7 to read.

// Dual interface (I2C+NFC) eeprom
#define M24LR04 0x53

// I2C temperature sensor - see table 1 of data sheet.  Resistor selects address. 
#define STTS751 0x39

// See also - 
// http://playground.arduino.cc/code/I2CEEPROM
// http://www.developer.nokia.com/Community/Wiki/Understanding_NFC_Data_Exchange_Format_(NDEF)_messages
//

void i2c_eeprom_write_byte( int deviceaddress, unsigned int eeaddress, byte data ) {
    int rdata = data;
    Wire.beginTransmission(deviceaddress);
    Wire.write((int)(eeaddress >> 8)); // MSB
    Wire.write((int)(eeaddress & 0xFF)); // LSB
    Wire.write(rdata);
    Wire.endTransmission();
}
  
void i2c_eeprom_write_bytes( int deviceaddress, unsigned int eeaddresspage, byte* data, byte length ) {
    byte c;
    for ( c = 0; c < length; c++){
        Wire.beginTransmission(deviceaddress);
        Wire.write((int)(eeaddresspage >> 8)); // MSB
        Wire.write((int)(eeaddresspage & 0xFF)); // LSB
        Wire.write(data[c]);
        Wire.endTransmission();
        delay(10);
        eeaddresspage++;
    }
}

// 03 | nbytes | D1 |01 | payload_length | type | id | payload | FE
// nbytes = payload_len + 4
// payload_length = ‘enSome text here \FE’
// type = ‘T’ (text), ‘U’ (URI)
// id = 02,  03 (http://)

void i2c_eeprom_write_ndef( int deviceaddress, unsigned int eeaddresspage, byte* data, byte length ) {
  // Write NDEF header
  char header[] = "\003\000\xD1\001\000T\002";
  header[1] = length + 5; // Total bytes after D1 marker.
  header[4] = length + 1; // Will add \xFE to payload.
  i2c_eeprom_write_bytes( deviceaddress, eeaddresspage, (byte *)header, sizeof(header) );
  i2c_eeprom_write_bytes( deviceaddress, eeaddresspage+sizeof(header)-1, data, length );
  i2c_eeprom_write_bytes( deviceaddress, eeaddresspage+sizeof(header)+length-2, (byte *)"\xFE\0\0\0", 4 );
}  

byte i2c_eeprom_read_byte( int deviceaddress, unsigned int eeaddress ) {
  byte rdata = 0xFF;
    Wire.beginTransmission(deviceaddress);
    Wire.write((int)(eeaddress >> 8)); // MSB
    Wire.write((int)(eeaddress & 0xFF)); // LSB
    Wire.endTransmission();
    Wire.requestFrom(deviceaddress,1);
    if (Wire.available()){
      rdata = Wire.read();
    }
    return rdata;
  }

byte i2c_sensor_read_byte( int deviceaddress, int eeaddress ) {
  byte rdata = 0xFF;
  int rc;
  Wire.beginTransmission(deviceaddress);
  Wire.write((int)eeaddress);
  rc = Wire.endTransmission();
  Wire.requestFrom(deviceaddress,1);
  if (Wire.available()){
    rdata = Wire.read();
  }
  if(rc != 0){
    Serial.print("Error ");
    Serial.println(rc);
  } 
  return rdata;
}

 void setup() 
  {
    char message[] = "enHello World"; // data to write. N.B. language prefix 'en'

    Wire.begin(); // initialise the connection
    Serial.begin(9600);
    i2c_eeprom_write_ndef(M24LR04, 4, (byte *)message, sizeof(message));
    Serial.println("Setup done");
  }
  
  void loop() 
  {
    int addr=13; // location of text string in NDEF payload.
    byte b, lo;
    signed char hi;
    float temperature;

    Serial.print(' ');
    while (addr<53) 
    {
      b = i2c_eeprom_read_byte(M24LR04, addr);
      if(b == 0xFE)break;
      Serial.print((char)b);
      addr++;
    }
    Serial.println(" ");
    
    // read temperature
    hi = i2c_sensor_read_byte(STTS751, 0);
    lo = i2c_sensor_read_byte(STTS751, 2);
    if( hi > 0){ 
      temperature = hi + lo * 1.0/256.0;
    }else{
      temperature = hi - lo * 1.0/256.0;
    }
    Serial.print(temperature);
    Serial.println(" ");
    delay(1000);
  }

Lessons learnt

  • Read the data sheet.  When it doesn't work, read it again.
  • Wire uses I2C_device_address / 2. It that makes no sense, compare datasheet addresses with those used in the code.  Yup,  that caught me out.
  • The onboard microcontroller can be disabled with a jumper on reset.  But it's not necessary, two masters works in this case as the default ST code only reads.
  • NDEF -  yet another data format.  Yipee! 

What next?


Now I've figured out how to use these NFC EEPROMs I've ordered a few chips, they're less than a pound each. Of course I'll need to make my own antenna, but that should be easy and fun. For the microcontroller I'll use the absurdly low power and very cheap MSP430.

Oh, and if you want to create your own Internet Of Little Things, then I suggest as a minimum you edit the code to write a URI to the EEPROM, then hey presto, you're little thing is on the Internet, sharing it's temperature, or whatever else it wants to share.