---------------Getting along in the 21st Century with half the baggage you carried in the last.------------ /*************************Low cost electronic solutions for a low impact lifestyle.************************/
Thursday, November 27, 2014
A Sneaky Week In Snowdonia
It's not every day your daily commute includes a view of Snowdon in the early morning November sunshine! |
Sometimes you just need to get away......
With an enforced week off work in late November, I decided to travel back to North Wales, where I was a student back in the early 1980's. For 3 years, Bangor, Gwynedd and Snowdonia was my immediate life.
With a bit of nostalgia, I left a very wet Surrey last Sunday afternoon, and drove the 250 miles up to southern Snowdonia.
Now 30+ years on, I am back in my old familiar university stomping ground, marveling at the changes that have occurred since I was last her, 3 decades ago. A lot more retail parks, more roads, and bigger buildings than were here when I was a student. My old hall of residence Neuadd Reichel still stands, but now surrounded by a cluster of new student accommodation blocks painted in garish pastel colours. Any Bangor alumni who remembers the Plas Gwyn and Tryfan halls, will be shocked to see how they are now demolished and replaced with the modern blocks. Gone also are the old students union building and the Theater Gwynedd - currently under re-construction, over budget and months behind schedule.
Whilst I have lost touch with almost all of my University contemporaries, I now have new friends in and around the Bangor area.
The Bothy - home for a few days |
I'm staying in a bothy, a small traditional cottage, about a mile from the village of Llanfrothen. It's a stone built Welsh cottage, located in a valley that contains a small stream.
Inside it's about 12' x 18' living space with a bed on a mezzanine floor. Roof lights make the most of the natural daylight. Downstairs a small kitchen, with two ring gas cooker, fridge and washing machine. The all important woodstove becomes the focal point of the room. Adjacent to the main living space is a toilet/shower-room. It's basic - but sometimes basic is just what we need to bring us back to realise some of our fundamental values.
The bothy is located in a wooded valley and so is well supplied with firewood for heating, there is an electric immersion water heater, telephone landline and broadband. Mobile reception here is at best flaky on some networks - at worst, non existent.
So, I'm here for a week, not exactly for relaxation, but to catch up with some of my good friends who live in this little corner of North Wales.
My hosts this week are Trystan Lea and Glyn Hudson - who founded Open Energy Monitor about 4 years ago. The bothy belongs to Trystan's father, and was once used as an architect's studio, before Trystan and Glyn took it over a few years ago as the premises for their start up, open source energy monitoring company, Megni.
Megni has now outgrown the bothy, and has moved to a serviced office premises in Parc Menai - a fairly new development on the southern outskirts of Bangor.
It's a 25 mile commute from Llanfrothen to Parc Menai - and so Trystan has wisely invested in a Nissan Leaf Electric Car. With a range of 60 miles, it easily meets his daily commute requirements - and what a commute that is, through the beautiful scenery of south Snowdonia.
Trystan's electric Nissan Leaf, on the Pen Y Pass, en route to Llanberis. |
The Nissan Leaf is an all electric super-mini. It can seat 4 adults in comfort, and has a boot that can easily swallow a couple of mountain bikes, with the back seats lowered.
A 50 mile round trip uses about 13.5kWh of mains electricity, or about £2 worth. The same trip in my Golf TDi would cost about £6.50 in diesel.
Trystan uses the Leaf on a daily basis and at weekends, recharging at night on a standard 13A extension lead, and occasionally with a top up at the office, on the end of an extension lead.
Snowdonia was an early pioneer of renewable energy. A little research shows that hydro electricity was first developed here in Snowdonia in the early 1900's. Today there are several hydro schemes in operation, including the pumped storage scheme at Dinorwic - which was under construction 30 years ago, when I started as a student here.
"Chapel in the Valley" Cwm Dyli. Hydro-electricity generated here has served this part of Snowdonia for 110 years. |
A mirror-like lake, Llyn Cwellyn - on the way to Caernarfon |
Though early morning mists we see, visions of reality....
A visit to my old engineering department revealed that Engineer's have a sense of humour too
TBC |
Sunday, November 16, 2014
As Easy as ABC (and D)
The Arduino has definitely been a major force behind the open hardware movement, democratising hardware and making it much easier to develop microcontroller based gizmos.
However, despite it's popularity, the Arduino is showing it's age and has a few flaws. It has however shown that a simple microcontroller board combined with an IDE , an ecosystem based on shields and a strong community following is certainly one way to gain traction in a market for ever more complex products.
The 8 bit AVR at the heart of every Arduino, is a success story in itself. Conceived in the early 1990s and comercialised in partnership with Atmel in 1996, the AVR is a leader in the 8 bit microcontroller market. However, there is much competition from 32 bit micros - especially ARM, so perhaps it is time to work on a new platform, with its own ecosystem, and for the next few years, there is no reason why AVR and ARM cannot co-exist in the open hardware community.
A great YouTube about the "AVR Story"
So how would you design a better "Arduino" ? Here's some of my thoughts:
1. A smaller footprint 60 x 20mm (about 1/3rd the size of an Arduino Uno).
2. Pins on a proper 2.54mm pitch that can be easily plugged into a breadboard
3. USB as standard for VCP comms, programming and power
4. Easily identified ports - arranged by function
5. A forgiving footprint. If you plug it is backwards, you won't fry the microcontroller
6. More I/O - 32 pins, as opposed to 20
7. Higher resolution ADCs: 12bit and 16 bit available. 2 DAC channels
8. More UARTS, SPI and PWM
9. Wireless connectivity - with a choice of BLE, WiFi or low power 433/868MHz
10 Upgradable as new microcontrollers arrive in the marketplace
Many vendors sell their microcontrollers in a 44 or 48 pin surface mount package. This is nice and compact, but not easy to prototype with. So let's mount the SMT device on a carrier pcb, add a crystal and reset circuit and bring the pins out to an industry standard 40 pin DIL footprint. A mini B USB connector at one end allows the device to be plugged into a laptop for programming, communications and power.
Here's one I made earlier - ARMiGo a platform for 48 pin STM32F ARM devices:
As you can see, there's a 48 pin LQFP at the centre, a mini USB B at the right hand side and a SMT crystal. The 5 pin header on the left is for programming, using the ST Microelectronics ST-Link programmer.
Now this was based on the STM32F303, a great little ARM Cortex M4 device. But it could equally use the STM32F103, or STM32F373, or STM32F411, or even the stonking Cortex M7 - a 200MHz mcu. The great thing about the STM series of ARM devices is that once you have settled on a package size, you can move up and down the family to suit the needs of your application, as packages are fully pin compatible.
The ARMiGo was my first attempt at a generic module, and I must admit, I did not get it right first time. It was tracked out in such a way that gave maximum convenience for pcb layout - rather than in a logical manner where pins were grouped by function. The other faux pas - was my power pins were at opposite corners (common on many DIL packages). If you plug it in backwards - you fry the microcontroller.
I decided to look at the DIL package AVR devices - in particular the 40 pin ATmega1284. These parts have their power pins in the centre, and the ports are generally symmetrical. Plug it in backwards, and no damage will occur.
Here's a neat diagram to illustrate this point:
This can readily be mounted on the carrier pcb and tracked out so that the various peripherals and ports appear on the correct pins. The 8 analogue inputs map to Port A. The obvious communications pins TXD, RXD, MOSI, MISO, /SS and SCK map to Port C. The PWM channels map to Port D etc.
This same philosophy could be applied t0 the 44 Pin ATmega 32U4 which is used on the Leonardo.
Summary.
This post has outlines that any 48 pin or less microcontroller from ARM and AVR families can be placed onto a small carrier pcb in such a way that the GPIO and peripherals are located in the same place. This allows the developer to rapidly switch between families or manufacturers.
More on this next time.......
However, despite it's popularity, the Arduino is showing it's age and has a few flaws. It has however shown that a simple microcontroller board combined with an IDE , an ecosystem based on shields and a strong community following is certainly one way to gain traction in a market for ever more complex products.
The 8 bit AVR at the heart of every Arduino, is a success story in itself. Conceived in the early 1990s and comercialised in partnership with Atmel in 1996, the AVR is a leader in the 8 bit microcontroller market. However, there is much competition from 32 bit micros - especially ARM, so perhaps it is time to work on a new platform, with its own ecosystem, and for the next few years, there is no reason why AVR and ARM cannot co-exist in the open hardware community.
A great YouTube about the "AVR Story"
So how would you design a better "Arduino" ? Here's some of my thoughts:
1. A smaller footprint 60 x 20mm (about 1/3rd the size of an Arduino Uno).
2. Pins on a proper 2.54mm pitch that can be easily plugged into a breadboard
3. USB as standard for VCP comms, programming and power
4. Easily identified ports - arranged by function
5. A forgiving footprint. If you plug it is backwards, you won't fry the microcontroller
6. More I/O - 32 pins, as opposed to 20
7. Higher resolution ADCs: 12bit and 16 bit available. 2 DAC channels
8. More UARTS, SPI and PWM
9. Wireless connectivity - with a choice of BLE, WiFi or low power 433/868MHz
10 Upgradable as new microcontrollers arrive in the marketplace
Many vendors sell their microcontrollers in a 44 or 48 pin surface mount package. This is nice and compact, but not easy to prototype with. So let's mount the SMT device on a carrier pcb, add a crystal and reset circuit and bring the pins out to an industry standard 40 pin DIL footprint. A mini B USB connector at one end allows the device to be plugged into a laptop for programming, communications and power.
Here's one I made earlier - ARMiGo a platform for 48 pin STM32F ARM devices:
As you can see, there's a 48 pin LQFP at the centre, a mini USB B at the right hand side and a SMT crystal. The 5 pin header on the left is for programming, using the ST Microelectronics ST-Link programmer.
Now this was based on the STM32F303, a great little ARM Cortex M4 device. But it could equally use the STM32F103, or STM32F373, or STM32F411, or even the stonking Cortex M7 - a 200MHz mcu. The great thing about the STM series of ARM devices is that once you have settled on a package size, you can move up and down the family to suit the needs of your application, as packages are fully pin compatible.
The ARMiGo was my first attempt at a generic module, and I must admit, I did not get it right first time. It was tracked out in such a way that gave maximum convenience for pcb layout - rather than in a logical manner where pins were grouped by function. The other faux pas - was my power pins were at opposite corners (common on many DIL packages). If you plug it in backwards - you fry the microcontroller.
I decided to look at the DIL package AVR devices - in particular the 40 pin ATmega1284. These parts have their power pins in the centre, and the ports are generally symmetrical. Plug it in backwards, and no damage will occur.
Here's a neat diagram to illustrate this point:
This can readily be mounted on the carrier pcb and tracked out so that the various peripherals and ports appear on the correct pins. The 8 analogue inputs map to Port A. The obvious communications pins TXD, RXD, MOSI, MISO, /SS and SCK map to Port C. The PWM channels map to Port D etc.
This same philosophy could be applied t0 the 44 Pin ATmega 32U4 which is used on the Leonardo.
Summary.
This post has outlines that any 48 pin or less microcontroller from ARM and AVR families can be placed onto a small carrier pcb in such a way that the GPIO and peripherals are located in the same place. This allows the developer to rapidly switch between families or manufacturers.
More on this next time.......
Plot It - a useful graphing programme for serial data
Sunday, November 09, 2014
Using the SDcard, RTC and SRAM on WiNode and Nanode RF
This is an update of a post to the Nanode Website from October 2012.
The original is here
Nanode and Winode are something of a departure from the usual Arduino hardware, and when functioning as a pair, form a unique extension of the Arduino platform to include ethernet and low power wireless connectivity.
stringOne = String(temp_1);
stringTwo = String(temp_2);
stringThree = String(temp_3);
stringId = String(id);
The original is here
Getting to know Nanode and Winode Hardware
- Posted: October 1, 2012
- by Ken -
- No Comments
Part 1. Using the SD Card and RTC to make a 4 channel datalogger.
Nanode and Winode are both based on the ubiquitous ATmega328 microcontroller, but include the following common functional blocks.
1. An RFM12B low power wireless transceiver module.
2. A MCP79410 Real Time Clock. This provides RTC, two alarms, 64 bytes of battery backed RAM and 1kB of EEPROM.
3. microSD socket – accepts up to 2GB microSD cards for long term datalogging.
4. 32kB battery backed SRAM. Can be used for downloading sketches or buffering larger quantities of data from the web.
Using freely available libraries it is possible to utilise these hardware blocks, and quickly put together applications on the Nanode or Winode.
The RFM12 is connected to the SPI bus and is selected by Digital 10
The MCP97410 RTC is an I2C device using An4 and An5. It’s multipurpose output connects to Digital 3 – or Interrupt 1
The SD card is also connected to the SPI bus and is selected by Digital 4
The 23K256 SRAM is connected to the SPI bus and is selected by Digital 8 (Winode) and Digital 9 (Nanode).
In this post I will look at the operation of the SD card and the Real Time Clock.
The SD card is extremely useful for long term datalogging applications whilst the RTC, as well as providing clock and calendar functions for real time control, also provides two alarms or a square wave output which can be used to wake up the ATmega from sleep at regular intervals. The RTC also contains 64 bytes of non-volatile SRAM and 1K of EEPROM.
The SD card Library is included with the Arduino IDE. For my examples I am using Arduino IDE 1.0.1. This is an easy to use library, and if you are a newcomer I suggest Jeremy Blum’s excellent video tutorial.
This has 3 examples, how to write to the SD card, read and write and how to datalog several sensors to the SD card.
This has 3 examples, how to write to the SD card, read and write and how to datalog several sensors to the SD card.
For both the Nanode and Winode, the SD card is selected with Digital 4. You will need to modify the code to use the correct chip select line.
The MCP94710 is a powerful little chip – not just a RTC, but includes 2 independent alarms, 64 bytes of battery backed SRAM and 1024 bytes of E2. If you buy the MCP94712 version, it also includes a uniquely assigned 64 bit MAC address. These devices are available from Farnell for about £1.00. It is connected to the ATmega via the I2C bus, and so needs the Wire library to support its functionality. It has a multipurpose output which is connected to the Digital 3 (interrupt 1) input of the ATmega. This can output a squarewave to generate regular interrupts, or be triggered on either of the Alarm conditions. Please refer to the Microchip MCP9471X data sheet for full details of the internal registers.
I decided to write some code to exercise the main features of this RTC and also make use of the microSDcard for datalogging.
Before using these devices we have to include the SD card and Wire (I2C) libraries – so remember to add the #include statements at the top of the code.
#include
#include
The sketch initialises the RTC and the alarms, and then writes a 64 character text message to the battery backed SRAM.
The main loop then proceeds to log the analogue input from ADC0 to the SDcard every 5 seconds. The alarm has been configured to trigger every minute, and print out the 64 byte message to the serial terminal window, as well as illuminating the LED.
The code for this demo is available here on Github Gist.
It compiles to 18054 bytes on the ATmega328.
It compiles to 18054 bytes on the ATmega328.
This second sketch on Github Gist logs the four analogue input readings to the SD card, once per second. It compiles to 19166 bytes on the ATmega328.
The sketch sends out the current time, the value of the four analogue input channels – and once per minute, acting on an alarm it outputs the message “The Quick Brown Foxy Leapt over the Lazy Dog whilst he snoozed”.
The sketch sends out the current time, the value of the four analogue input channels – and once per minute, acting on an alarm it outputs the message “The Quick Brown Foxy Leapt over the Lazy Dog whilst he snoozed”.
I found it important to declare and reserve space for the various strings:
String dataString = ” ”;
String stringZero = ” ”;
String stringOne = ” “;
String stringTwo = ” “;
String stringThree = ” “;
String stringId = ” ”;
String stringZero = ” ”;
String stringOne = ” “;
String stringTwo = ” “;
String stringThree = ” “;
String stringId = ” ”;
And then form individual strings for the analogue readings which are then concatenated together.
int temp_0 = analogRead(0);
int temp_1 = analogRead(1);
int temp_2 = analogRead(2);
int temp_3 = analogRead(3);stringZero = String(temp_0); // Form strings from the individual ADC readings
int temp_1 = analogRead(1);
int temp_2 = analogRead(2);
int temp_3 = analogRead(3);stringZero = String(temp_0); // Form strings from the individual ADC readings
stringOne = String(temp_1);
stringTwo = String(temp_2);
stringThree = String(temp_3);
stringId = String(id);
//Create Data string for storing to SD card using the CSV Format
dataString = stringId + “, ” + stringZero + “, ” + stringOne + “, ” + stringTwo + “, ” + stringThree; // Concatenate the strings to write to the SD card
An early attempt using a different approach resulted in a memory leak which caused the ’328 to crash after about 5 writes to the SD card:
This code example will be further developed to make a real time logging, 4 channel temperature controller, as part of a central heating controller project.
The next post will combine the SDcard and RTC code example with simple 2-way wireless packet communication – allowing the temperature measurements to be send to a Nanode Gateway or other RF compatible device.
November 2014 Update.
It has been a couple of years since I wrote any code for WiNode. I got back from California and had to find myself a job, so WiNode went on the back burner for a while.
It was always the intention to make the WiNode part of an integrated system based around the JeeNode RFM12B wireless communications library. This library is popular amongst the hobbyist community and is supported by several open source devices including the emonTx, emonGLCD and Nanode Gateway produce by OpenEnergyMonitor.
The first step was to include the JeeNodes library with the code example - such that packets could be received from other RFM12B equipped nodes.
I have put together a fairly simple example of this, plus the ability to read temperature values from local thermistors connected to the ADC channels 0- 3.
This code is also available as a Github Gist
WiNode Revisited
I am currently revisiting WiNode, with the intention of designing a new version aimed specifically at central heating control applications.
This will retain the RTC and SDcard of the original, but include a mains power supply based around a small encapsulated pcb transformer and bridge rectifier, and a pair of 8A rated mains relays.
The intention is that this variant will be compatible with existing central heating controllers, providing control over hot water and central heating functions, remotely via wireless, from either a display such as the emonGLCD or via a web Gateway such as the Nanode RF.
In fact any RFM12B or RFM69 based module should be able to interact with WiNode. This opens out applications for Raspberry Pi users, and also other applications that require mains loads to be switched - such as solar hot water system pumps.
I will cover more detail of the new design in a future post.
November 2014 Update.
It has been a couple of years since I wrote any code for WiNode. I got back from California and had to find myself a job, so WiNode went on the back burner for a while.
It was always the intention to make the WiNode part of an integrated system based around the JeeNode RFM12B wireless communications library. This library is popular amongst the hobbyist community and is supported by several open source devices including the emonTx, emonGLCD and Nanode Gateway produce by OpenEnergyMonitor.
The first step was to include the JeeNodes library with the code example - such that packets could be received from other RFM12B equipped nodes.
I have put together a fairly simple example of this, plus the ability to read temperature values from local thermistors connected to the ADC channels 0- 3.
This code is also available as a Github Gist
WiNode Revisited
I am currently revisiting WiNode, with the intention of designing a new version aimed specifically at central heating control applications.
This will retain the RTC and SDcard of the original, but include a mains power supply based around a small encapsulated pcb transformer and bridge rectifier, and a pair of 8A rated mains relays.
The intention is that this variant will be compatible with existing central heating controllers, providing control over hot water and central heating functions, remotely via wireless, from either a display such as the emonGLCD or via a web Gateway such as the Nanode RF.
In fact any RFM12B or RFM69 based module should be able to interact with WiNode. This opens out applications for Raspberry Pi users, and also other applications that require mains loads to be switched - such as solar hot water system pumps.
I will cover more detail of the new design in a future post.
Subscribe to:
Posts (Atom)