Scargill

Archive for the ‘Arduino’ Category

Streuth.. I’ve just realised I’ve been running this blog since 2005! Doesn’t time fly. My interest in using Atmel technology for home control started with an article I wrote back in 2012 simply called “Home Thermostat”. At that time I was just playing – but messing with prototypes really isn’t much fun so shortly thereafter I design the “UberBareBoard”. That article was followed up by my first attempt at home control over the Internet and part 2 by which time I was starting to see some real potential for not only my home but our holiday cottage business and for our place in Spain.  Then came more updates as I got to grips with the more powerful Atmega1284p chip and started to develop my own PC-based test tools. By July I had it all figured out – or so I thought – using RF24NETWORK software providing a mesh-type network of radios still using the NRF24L01 radio.

Amazing how things change. The NRF24L01 boards which – I’ll grant you are cheap, continue to function poorly –they do not like stone walls and the RF24NETWORK is not a true mesh – you have to specify every node in the mesh which makes replacing boards a lot of fun.. and it really cannot handle one of the boards going offline. Finally, no-one has yet made effective use of interrupts when using these radio boards in a network – which puts further limitations on what you can do – as you spend your time constantly polling the radio network.

Over the summer, my pal Aidan and I have been working hard – we now have a decent Atmega 1284-based board to work with – you’ll see it below. Late July I discovered the Radiohead library – the nearest our little processors have come to seeing a proper mesh network.. but that now pushes the 328 chips out of the window – as the library takes them near the limit of their available program memory and as for the tiny 2K of RAM – just not enough. For boards at the end of the chain, perhaps – and I have 3 working installations using these – but for the master board, the 328 is no longer an option.

In August while enjoying the sun, it hit me – the NRF24L01 chips don’t have the ability to know how strong the incoming radio signal is – so how the hell can a network possibly know which is the best unit to route the signal through – and that started me on the hunt for alternatives – which brings us neatly into this post.

If you’ve been following my blogs you’ll know about my on-going work on home control but firstly you’ll see the phrase “Arduino” bandied around. I use this merely for convenience as I use a lot of the Arduino libraries out there – but my boards are home-grown. I’m particularly fond of the Atmega1284p chip because, unlike the standard Arduinos you see our there, this has 4* the RAM – which means it’s less likely to run out. It also has 4* the FLASH memory – so just when Arduino sketches are running out of room, the 1284p is just getting started.

I used to use hand-made boards and there are plenty of those lying around, but these days I’m using a design we put together called the “Aiduino” – so-called because my pal Aidan did the board layout. This particular design has stood the test of time and I use these on everything. It has space for both 3v3 and 5v regulators, the chip, the usual support components and that’s about it.

You’ll see a typical Aiduino above with edge connectors for all the port pins and an SPI connector near the middle. I don’t bother putting the programming interface on the board as the low-cost FDDI interfaces do that all for you – why waste valuable board space. I simply allocate a 6-way connector on the edge of the board for programming.

Armed with these boards, I have LCD display controllers (for wall mount displays), a master controller with Ethernet card and “slave” units to control lighting etc. All of these units talk to each other using NRF24L01 radios which are very cheap 2,4Ghz popular radio modules. There are two problems with these radios – firstly they are very low power and secondly they are on the same radio broadcast range as just about everything else including WIFI – and they DON’T like stone walls.

I’ve looked at the cheap FSK units as used in radio remotes – no-where near powerful enough.

Aidan and I are investigating some Atmel chips with on-board radio – these look promising but getting all of that running in the Arduino IDE and hence keeping access to the Arduino libraries – is proving a challenge but watch this space as he’s working on this right this minute. We’d like to produce (where others have failed) a tiny radio module which runs on SPI and which internally handles all the mesh coding and massive buffering – as well as offering other functions to take the load off the main boards.. Meanwhile…

I’ve looked at the RF22 modules – but these come from the USA and hence are a little expensive (inc. postage).. but only in the last few weeks have I discovered even cheaper Si4332-based radio boards from China which are compatible with the RF22 modules and hence can work with the likes of the Radiohead library for Arduino – a simple but fully functional “mesh radio” library. Not only that but these radios and library combined, unlike the slightly less expensive (but only just) NRF24L01 units, make good use of interrupts to ensure you can actually do something else while the radios are working!!

See the radio on the right – that’s one of them. They are tiny which poses a problem for prototyping as the edge connector is 0.05” pitch – but it’s do-able with care.

Below you’ll see one of my bodged Aiduinos which has the radio board mounted on top of the 1284P chip. If this all pans out I’ll make a board that incorporates the radio… and in the process of research I’ve found out some interesting things about these little radios.

I can say that I’ve had 3 of these running in mesh mode and the range covered by 3 equally spaced units (the centre one acting merely as a message relay in this case) covers from my garage, to my greenhouse – through 4 stone walls and an intermediate lightweight wall – which is WAY better than the NRF24L01 chips can manage.

At first I managing a couple of message round trips a second – I needed to get the speed up to dozens of round trips a second in order to allow me to, for example round-robin poll several units to update the mobile phone.

Well that worked too thanks to some help from the designer of the Radiohead library – a change from the library defaults brought me to 100 package round trips a second – when I say package – we’re talking about, say a 20 byte package going there and back – and with additional maintenance bytes (from, to, ID etc.)

The chip used in these radios, the Si4332 is supposed to handle a maximum +20db output  – I managed +17db – but I’m convinced the little spring aerials are now the limiting factor – with full power I can now get through 2 stone walls but not right across the house.. but WAY better than the NRF24L01 chips even when the latter have stub aerials.

To run these radio boards, they need 3v3 power. Our Aiduinos run on 5v but have 3v3 out. You can feed the one output from the radio directly but the inputs to the chip might be damaged by direct connection to 5v logic – one option is a level convertor, another is a resistive divider. I found that for the 3 inputs that need it, 470r series resistors do the job just fine (The NRF chips work off 3v3 but will accept 5v signals directly). Why don’t I just run everything off 3v3? Speed and driving other devices, that’s why.

I’ve now modified the Radiohead library so that I can also get a flag when data is passed THROUGH the unit so it’s now possible to indicate the success of not only incoming packets but those passed on elsewhere – very handy for debugging and there’s nothing wrong with pretty lights anyway.

So there it is – what looks like a reasonably inexpensive radio solution for home control and with a tiny mod, the standard Ethernet library handles the Atmega 1284 chips no problem – it’s detailed in here somewhere but boils down to adding the chip to one of the library conditionals for the Mega boards. I did notice when these radios are running constantly, a slight decrease in range of my plug-in-the-wall mains controller handsets as they are on the same frequency range – but in my application, such all-out non-stop transmission would only occur when say the mobile phone is actually polling the units – otherwise it’s just about occasional updates and checks. As for the handsets interfering with the network – they don’t – maybe thanks to the frequency-hopping technology embedded in the boards. Incredible technology for such a low price.

Far more to come in the future. I plan to add moisture detection for our plants, gas monitoring for the home, I already have lighting and heating control working in 2 of the properties. I also have IR remote control and radio mains control underway. Do look in.

This is the latest to date in my series of articles on home control which started with my original article on a cottage thermostat in which I envisaged a very simple controller. Then came the UberBareBoard article about an Atmega328-based Arduino clone, initial attempts to master the NRF24L01 radio. The next article was the first item entitled home control and after this – then part 2 and then the winter update – then the April 2014 update and then things really started to move as I discovered better networks – then came the full mesh article – by this time I had everything starting to run the way I wanted things but for the radio network – as you’ll realise by now, that issue is starting to disappear.

As this is now abuzz-phrase you’ll see littering the press, I thought I’d put in my two-pence worth on this “new” subject.

The “Internet of Things” is a phrase used to describe things that can be controlled or monitored (or both) over the Internet.

In 1962  I was too young to be aware of what was happening outside of my own house! but at this time, a fellow called Licklider from MIT was describing what he called a “galactic network” concept in which computers all over the world would talk to each other. By 1969 4 machines were talking to each other in what was called “Arpanet” and the rest is well known… today, billions of machines are connected worldwide… but most folk think of everything from large computers down to mobile phones – what is slightly less well known is the massive spread late last century of “microcontrollers” which are now found in most everyday electronic gadgets (washing machines, industrial controllers etc. and which are often connected together by what is currently called “The Internet of Things”. Checkout Cloudwash if you’re interested in what might be done with domestic appliances. Here is another link to a Samsung phone controlled washing machine, the WW9000.

In 1963 my interest in electronics started with a “Philips E10” kit which started me on the path of building radio receivers, controlling lights and motors.. and I’ve been involved with electronics since then, writing articles, building machines and eventually turning my interest into a business in the 80’s and beyond.

In 1974, the X10 protocol was developed in Scotland (but strangely found much favour in America where, amongst others,  Steve Ciarcia made it popular with hobbyists -Steve Ciarcias Circuit Cellar magazine). This was a means of connecting gadgets around the home/office/factory for the purpose of remote control. In this case the signals were/are in fact sent over the mains electricity supply. Other solutions involve WIFI, Bluetooth, general radio, Infra-red and other mechanisms.

That takes care of the local connectivity while the Internet allows that remote control to extend worldwide.

In 1982, students at Carnegie Mellon University created the first ever “Internet connected soda vending machine”. I remember being fascinated at the possibilities this would bring, thousands, perhaps millions of machines of all shapes and sizes being controlled and monitored via the Internet from anywhere in the world. Of course at that time there was not even the concept of an Internet-connected mobile phone so that limited possibilities at the time – but this was enough to start me off and by May 1994 our company had developed a home control system called Appcon which basically let anyone control lights, alarms, heating and more from a PC – and by implication, by remotely controlling the PC, from anywhere. 

We used wire control and the mobile infrastructure was simply not ready for this. Today it is and we’re already starting to see simple light and heating control via mobile phones appearing on the market. We’re also seeing what I believe is only the tip of the iceberg in dire warnings in the press about security.  While Windows and the Internet in general have had a long time to get used to nasty people trying to break in and destroy – to the extent that virtually all of the public are aware of viruses, trojans and other means of destroying PCs, certainly the home control market has to date not been sufficiently important to attract large scale attempts at disruption – but it will happen – it’s just a matter of time.

Part of the problem is that the sophisticated anti-virus and other techniques used to protect PCs are simply not available to the simplest of controllers you might see in for example a remote light switch. Even HTTPS: which is a simple mechanism to encrypt data over the Intranet is mostly not available to the simplest of controllers.

Gartner reckon that by 2020, 30 BILLION devices will be connected to the Internet and bear in mind that the current IP4 system of Internet addressing allows for only 4.3 billion individual device addresses and that includes PCs and phones etc.!! Newer technologies such as IP6 which allow for a FAR greater number of devices are again not really available to the simplest of devices at this time so there are lots of changes and improvements to be made in the coming years.

In the meanwhile, much fun and entertainment is still to be had in this emerging field – enthusiasts using the likes of the Raspberry Pi, Arduino and other technologies are having a great time coming up with new ideas and new applications. The combination of local networking and remote control via the Internet has chance to dramatically change how we interact with the world in the coming years, offering massive possibilities for saving energy and doing things in completely new ways. Expect to hear a LOT more of this in the coming months.

For my own efforts I’m now controlling my own gadgets in 3 properties including modern lighting technologies and heating and already making savings on heating bills.

I’ve been working on home control now for many years on and off both professionally and today as a hobby (for now). This blog documents the latest state of play.

My first attempt at home control years ago took the form of a bunch of boards talking to each other around a building by cheap telephone cable. Simple as that may be it can be a deal-breaker when it comes to wives who don’t like wires! Today this needs to be handled as far as possible, wirelessly.

Talking to a home controller via mobile phone is a no-brainer – simply fit Ethernet capability to an microprocessor board and there are solutions out there for talking to mobile phones, one which takes some work but which yields one of the best visual interfaces to date is NETIO. I’ve developed my own Android software and that works well, but for now, visually, NETIO remains my tool of choice – though lack of updates from the designers is starting to grind a little – such is the way of Apps.

To get instructions delivered around the building, for the last year I have been struggling with a low-cost radio called the NRF24L01 – these are readily available on Ebay and are small and cheap – however they do not suffer stone walls gladly and have somewhat restrictive range, due mainly to their choice of operating frequency – 2.4Ghz which just happens to be the same range as everything from WIFI routers to cordless phones and more. Their advantage – cheap.

Within that restriction they are quite reliable – I’ve sent hundreds of thousands of data packages in a row without error. In order to get past the stone wall issue, it’s no good having a controller simply talking to radio units (which is how you avoid wires all over the house), you need some kind of network so that units can pass message from one to another. Because the Atmel Atmega328 processors I use (custom variations on the basic “Arduino” theme) are limited in capacity, as is the NRF24L01 radio, up to now it has been impossible to to manage anything more than a limited form of hopping network where certain “nodes” or slave units act not only independently but also as “relay” nodes, passing messages on to others and hence increasing the range of the system.

What has always been needed was some kind of full mesh where all units can act as gateways to others and where the failure of one unit results in the mesh re-adjusting itself automatically to handle that. Up to now that’s been a dream but the software now exists to do this – called RadioMesh.  The nearest anyone has come up with until now was RF24NETWORK, a simple network but not a mesh – in this network up to 6 units could each talk to 6 others and so on – the limitations included the need to specify exactly who would talk to who – so if one unit went down it could bring the whole network down. Accordingly I’ve been spending my evenings and weekends gutting my software to try to accommodate some new software which forms a “mesh”… and the work has paid off – I now have a rig up and running.

As you can see from the above, I’ve used the Atmel 1284p for the “master” unit – I long since gave up on the 328s for this – just not enough RAM or storage memory  – and I’m now about 2/3rds through the 128K memory that comes with the 1284.  On the other hand, “slave” boards which have no Ethernet can JUST about handle a range of functions and the mesh at the same time.

Each “slave” board has an output to control serial LED strip (which needs a separate 5v supply), 1 Infrared output, 3 normal digital outputs, 3 PWM outputs (again handy for LEDS), 2 general purpose analog (or digital) inputs and 2 temperature sensors. I’ve also incorporated an inexpensive 433Mhz transmitter to replace wireless remote controls – but that’s not 100% yet. The main board has an Ethernet Connection and also an optional output to an LCD display – the slaves also have similar outputs to an LCD display and in each case I made the decision to give the display it’s own intelligence – i.e. it’s own processor – so that I end up using the serial out on the slave boards and the SECOND serial out on the master for this purpose – hence the displays are optional without any software changes.

The master board is able to update Google Docs spreadsheets, send emails and Tweet – I’m currently still experimenting with the above as the email tools have a tendency to take too long to operate (but still work).

If you look up “Scargill home control” on Google you’ll find a host of earlier articles including some in-depth stuff and on YouTube I’ve detailed my experiences with the NRF24L01 radio units. Amazingly this has had well over 20,000 views! https://www.youtube.com/watch?v=VgmVYdSCNLs

Next steps – I’m working with a pal and we’re going to take a look at Atmel’s own mesh software for a chip they do with radio built in – we’ve a very tiny PCB on the way from China to test this out  – also I’m pondering putting the radio part on it’s own 328 chip with a slave SPI interface in order to allow it to concentrate on radio reliability while taking a whole load away from the main board. It sounds over the top but given the very low potential cost of a 328 chip and crystal, such a solution would leave more memory and MUCH more program space in the main board for improvements and new features. Watch this space.

This all sprang up from my original article on a cottage thermostat in which I envisaged a very simple controller. Then came the UberBareBoard article about an Atmega328-based Arduino clone, initial attempts to master the NRF24L01 radio. The next article was the first item entitled home control and after this – then part 2 and then the winter update – then the April 2014 update and then things really started to move as I discovered better networks – and better radios in the the September update where I discovered Radiohead, the Si4332 and RF22 radios.

I had a really interesting conversation this evening with a pal who’s into electronics as much as me.   I’ve been messing around with low-cost radio “mesh” networks which essentially give me the ability to read data and control outputs around the house wirelessly… 

For some time now, ever since the oil company tried to give us a mobile phone based oil sensor at which point I had to tell them they’d just screwed up for half of the UKs rural community for whom there are no mobile signals… I’ve been wondering how to make a safe remote reading mechanism for the oil tank.

Funny how you don’t put two and two together sometimes… there are available (from China as our lot are too greedy) some cheap ultrasonic sensors – like the ones you have in cars to help you not run people over.. for a couple of quid you get a little board with a transmitter and receiver and you can take the signal and get accuracy of sub-centimetre bouncing off stuff for distance measurement.  It occurred to me tonight – why not bounce off oil!  So the next step was – how to get that info back to me – well I already have home control measuring temperature – modifying a board would allow me to return how full the tank was – so using temperature as the equivalent if it returned say 10 to 30c – that’s 20 values – that’s a tank accurate to 5% – good enough….  and finally how to power all of that – well – my friend suggested a super-cap – after all it only needs to wake up once an hour – take a reading, report back and go back to sleep – and a little solar panel to keep the supercap charged.

When the board powered up it would talk to my network – which up to now looks like it can reliably send data from unit to unit back to base – I’m looking at a test rig here for the network – I have a board in front of me – the “receiver” – two boards in the garden acting as relays – and one in the living room sending out incremental numbers as fast as it can. Right now I’ve just received 700,000 packages without issue and I plan to leave it overnight on test  – hoping to hell it does not rain!!!

Could be onto a winner here… would be nice to add that to the armoury of info I have available at the touch of a button on my phone and tablet….  but it’s late at night – something for another day.

Another one for the techies I’m afraid….

Do you need to turn mains lights on and off but want to do it from, say and Atmel/Arduino-type setup instead of the standard remote controls you get with plug-in-the-wall mains switches? Then this might be for you. This is a variation of a blog I just put up on WordPress – with my latest updates.

This article is about decoding radio remote controls using Arduino or similar hardware and a cheap 433Mhz radio receiver (£2 on Ebay for receiver and transmitter pair) – and then use that data to control the remote switch units using a similarly cheap transmitter – and was written to serve a purpose: NONE of the existing libraries I could find out there managed to detect all of my radio remote controls.

I’m interested in adding radio remote for mains control to my house control system which is basically an Atmel 1284 chip with Ethernet and radio network. You’ll find various articles on the subject at www.scargill.net

Although it is easy to make a remote switching unit that will be part of a network and control mains lights, it is overkill and it is also quite difficult to find dirt cheap mains to 5v supplies to go into one of the limited range of plug-in-the-wall project boxes along with a controller and a relay.

With that in mind I started to look at the many mains switch remotes available out there. These generally work using simple 433Mhz radio receivers and accepting a code which could be almost any length but is normally somewhere between 10 bits and 50 bits.. the encoding techniques vary. Generally speaking these do not use any kind of “rotating” encoding for security and simply use a block of data, repeated as long as you hold the remote button.

BUYER BEWARE: If you want to control lighting using plug-in-the-wall 433Mhz controllers you should be aware of two things…

[a] the cheap controllers you find in the likes of B&Q use a single frequency which is EASILY blocked by other, similar transmitters.  I found when experimenting with a radio link at 433Mhz that it was easily blocked just by holding a button down on a mains remote controller.

[b] I found a nice cheap set of these plug-in-the-wall mains switches at ALDI recently, 3 remotes and a handset for £10 – what a bargain – but then looking at the fine print – you “train” them by turning them on and pressing a handset button within a few seconds – and that’s fine.. but, I thought, what about power cuts? Sure enough – you have to re-train them every time. What idiot came up with that brilliant idea? Going around the house re-training remotes every time the power fails? Surely not?  But I tested them and that is how they work. They are boxed up ready to be returned – not “fit for purpose”. That is, to be fair, the first time I’ve come across this but if you order online – beware!

Ok, so what could be difficult the handset lets out a 433Mhz modulated signal when a button is pressed – and the mains blocks pick up this signal, decode it and turn the plug on or off – so all you have to do is read the signal coming off the handset and use Arduino (or PIC etc) existing libraries to record and play back, right? Wrong – I had at least two handsets that use a code which was so long the existing learning libraries could not handle them AT ALL.

Eventually after much reading and learning I decided to do my own thing.

So, easy enough, (both the transmitter and receiver which I’ve linked to below have ground, power and signal leads – nothing else – the receiver appears to have two signal leads but they are connected together – you need only use either one) assuming the output of the simple receiver is LOW on standby, press the remote and look for the start bit – capture the length of each change of state until the end?  Right?

Well, no… the package is sent over and over – so you have to look for gaps between packages. Easy? Well yes except for AGC – automatic gain control. When the receivers are receiving “nothing” they get more sensitive and in my office the spikes coming out of the output were horrendous. I tried ignoring narrow pulses with limited results then I twigged.. if you run the remote control near the receiver – the noise goes away as the AGC (automatic gain control) kicks in…

So – press the remote control button – THEN start scanning – and store the gaps between pulses – say, 300 of them.  I did this with some REALLY simple code looking for high and low using the micros() function in Arduino (millis() is way too course) and keeping the code tight by simply storing the actual value of MICROS() in a long array.. ok not efficient but for temporary storage it works and I can get consistent results.

I discovered that all the controls send repeated packages with a short absence of signal in-between. Given the noise issue, the first package often gets scrambled – the breakthrough came when analysing the stored values and realising the solution is to search for the first repeat – i.e. after the first BREAK –hence ignoring the first package – previous attempts to use that had yielded varying results at the start of the package. By the time the second package kicks in the AGC has adjusted and the noise has all but gone.

So this would give me an output like this typical one from a handset.

They vary of course in length (not from key to key in that case just the order of bits varies) but from handset manufacture to another model or manufacturer).

What I did notice were pairs of zeros… ie pulses twice the width of others. On reading up this is called Manchester coding (or a variation) – I chose to ignore this – but knowing there will never be more than TWO different pulse widths helps a lot… in reality I realise that there is only one period in this type of encoding.. see this for pictures and explanation if you are interested. http://en.wikipedia.org/wiki/Manchester_code

As you can see from that link, the clock and data are encoded into the one signal.

But for my purposes it’s really NOT important to either understand or use this knowledge. All that is necessary is to send that stream out – fixed width per pulse as per the original and if there are two identical adjascent values (ie 00 or 11, detected by longer and shorter pulses compared to a fixed value indicated by the first pulse) then obviously you simply send the status quo to the output bit for twice the length of time.

But this uses up a lot of storage.  Looking at various handsets I discovered the largest signal seems to be around 40 or so bits… I made up a 12-byte array and wrote a routine to bit-shift the entire array by one bit – hence allowing me to convert the string above to a more sensible set of bytes.

In addition I added a byte at the start which represents the width of the basic pulse – as this could be as high as 1200us, I divided this by 10 to fit into a byte. In the example below you see 33 added to the start – ie 330us pulse width. On experimenting, that slight loss of accuracy seems unimportant and it saves a byte.

And so for any given button – we now have 11 bytes (in this case) to encode it. I decided that was GOOD ENOUGH.  A little routine to read from the end backwards, sending out pulses (or no pulse) for the duration specified in the first byte – VOILA I was accurately switching mains lamps on and off via my cheap transmitter.

Most of the code is unique, some bits are variations on stuff I found on the web (thanks to all who’ve taken the time to put their ideas up on the web) – and is provided here UTTERLY without support – no comments on styling please – if you’re having trouble reading radio remotes for your purpose – I hope this is useful.

The transmitter and receiver are here

http://www.ebay.co.uk/itm/433Mhz-RF-Wireless-Transmitter-Receiver-Set-NEW-/131093418464?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e85c6d1e0

Change input and output pins to suit your project – any pin will do, if you get nothing having pressed your remote then sent A to the board via the Arduino serial monitor, then try messing with INTER_CMS-MS and MIN_POS_WIDTH but I suggest not before you do that, you check with a scope that something is actually coming in.

Clearly in any end gadget you make for your use, you’d not include the learning part or it’s huge TBUFF array. When I get a minute I plan to come up with a means to simply store the data in EEPROM and read from that…  mind you – if you use a 1284 chip instead of the old 328, memory isn’t quite the problem.

If you need more range, you could consider putting the transmitter (NOT the receiver) on a higher voltage up to 12v. I tested mine at 12v and the signal from the 5v logic still worked perfectly. The increase in range is noticeable – I’d say 50% better coverage.  If you blow up your board however, that’s your responsibility – don’t come back to me…

This is all suitable for short bursts to control stuff – don’t get any ideas about continuous home control signalling unless you can guarantee there are no other 433Mhz transmitters in use! I went down this route before realising it’s a non-starter and am now looking at the slightly more expensive frequency hopping chips for more sophisticated use – but if all you want to do is turn something on and off – this could be for you.

So – two programs – the first grabs the radio output and puts it up on the serial –it also has a test mode – the second is playback only…

Here’s the first with some test options…

// I used a simple 433Mhz tx and RX pair - 1 pin each needed. Output of radio assumed 1 when something there ie active high
// No interrupts or clever tricks used
// Using F() in strings merely to keep RAM down, and PROGMEM for arrays - that's the data you see on the serial display for one particular button press... 
// Could store this in EEPROM or whatever... for now could get a lot of these for a particular application into ROM without using up precious RAM
// None of the PROGMEM stuff is essential - just there to minimise RAM use
// Coding Peter Scargill June 2014. www.scargill.net

#define PIN_DATA_IN 2
#define PIN_DATA_OUT 3
#define SERIAL_SPEED 115200
#define INTER_CMD_MS 100
#define CMD_REPEATS 5
#define COMPRESSED_ARRAY 12 // assume that's enough
#define MIN_POS_WIDTH 200 // used before we have the period - assumed minimum acceptable PERIOD less than which we ignore - in Microseconds
#define MAX_NEG_WIDTH 2000 // assumed maximum acceptable ZERO state in uS above which is assumed a gap between blocks of data
#define READINGS 300 // For temporary storage while learning, need 4 bytes per reading... so WATCH OUT - 328 only has 2k of RAM
#define TIMEOUT_VALUE 3000000 // Number of microseconds before we give up the ghost - ie 3 seconds - likely won't happen due to noise

// Byron reports 39us*10 for period - didn't work - so I put in 59 - works a treat.

const byte g0[]PROGMEM={59,77,211,36,73,146,52,73,210,52,1}; // Byron D2on
const byte g1[]PROGMEM={59,217,150,109,217,178,45,91,18};
const byte g2[]PROGMEM={59,219,182,109,217,178,45,91,18};

byte tbuf;

int remno=0;

byte arr[12];

// Used to set a timeout
unsigned long start_time;
unsigned long timeout;
unsigned long current_time;

unsigned long calc;

// Stores all the values read here
unsigned long readings[READINGS];
int current_reading = 0;

// Collect serial data into an array - or timeout as you prefer
void readRadioPulses()
{
    for (int a=0;a<COMPRESSED_ARRAY;a++) arr[a]=0; // wipe the eventual storage array
    for ( current_reading = 0;  current_reading <READINGS; current_reading++) // store enough values for 2 or more packages - as long values for speed
    {
        // Waits until the input goes HIGH 
            while (!digitalRead(PIN_DATA_IN))
            {
                if (micros() > timeout) return;
            }
        // When the first value comes, save that period
        readings[current_reading] = micros();
        digitalWrite(13, HIGH);
        // Wait until the input goes low

            while (digitalRead(PIN_DATA_IN))
            {
                if (micros() > timeout) return;
            }
        current_reading++;
        readings[current_reading] = micros();
    }
}

void shiftArray(int x) // move the entire array toward the highest offset by 1 bit and add least new significant bit to offset 0
{
  for (int a=sizeof(arr)-1; a>0;a--)
    {
      arr[a]<<=1; arr[a]|=(arr[a-1]&128)>>7; 
    } 
  arr[0]<<=1; arr[0]|=x;
}

// Sends the data to the serial port
void displayRadioPulses()
{
  int speed;
  byte pickone=0;
 
  for ( current_reading = 0;  current_reading < (sizeof(readings)-1); current_reading++)
    {    
      calc=readings[current_reading+1]-readings[current_reading]; 
      if (((current_reading&1)==0)&&(calc<MIN_POS_WIDTH)) { current_reading++; continue; }      
      if ((calc>MAX_NEG_WIDTH) &&((current_reading&1)==1)) { pickone++; if (pickone==1) speed=readings[current_reading+2]-readings[current_reading+1]; }
      if (pickone==1) // extract string here
          {
          if ((current_reading&1)==0) 
              { 
              if (calc>(speed+(speed/2))) 
                    {
                    //Serial.print("1"); 
                    shiftArray(1);
                    }
                //Serial.print("1"); 
                shiftArray(1);
              } 
              else 
              {
                if (calc>(speed+(speed/2))) 
                  {
                    //Serial.print("0"); 
                    shiftArray(0);
                  }
                 //Serial.print("0");  
                  shiftArray(0);              
              } 
          }
    }
 // Serial.println(""); 
  Serial.print("const byte g"); Serial.print(remno++); Serial.print("[] PROGMEM={");
  Serial.print(speed/10); Serial.print(",");
  for (int a=0;a<sizeof(arr);a++) { if (arr[a]) { Serial.print(arr[a]); if (arr[a+1]) Serial.print(",");  } }  Serial.println("};");
}

void sendRadio(const byte *m, int sz) // can't do sizeof a PROGMEM array so just pass the size
{
   int scount;
   int offs;
   int period;
   byte tmp;
   period=(int)pgm_read_byte(m)*10; // get the first value, multiply by 10 and that is your period
   for (scount=0;scount<CMD_REPEATS;scount++)
     {         
       for (offs=sz-1;offs>0;offs--) // start at the end and work backwards not including offset zero which is the (period/10)
          {
          tmp=pgm_read_byte(m+offs); Serial.print(".");
           for (int r=0;r<8;r++) { if (tmp&128) digitalWrite(PIN_DATA_OUT,HIGH); else digitalWrite(PIN_DATA_OUT,LOW); start_time=micros()+period; while (start_time>micros()); tmp<<=1; }
          } 
          Serial.println("");
        digitalWrite(PIN_DATA_OUT,LOW); delay(INTER_CMD_MS);
     } 
}

// Listens to SERIAL for inputs A=read, B=write demo - when reading press and hold handset FIRST
void SerialRequest()
{
   char c;
   while (Serial.available()==0);
   c=toupper(Serial.read());
    if (c=='A')
      {
        start_time = micros();
        timeout = start_time+TIMEOUT_VALUE;
        readRadioPulses();
        displayRadioPulses();
        Serial.flush();
      }
      
      if (c=='B') // try the example compressed code which includes (period/10) as first byte - can be any length
      {
       sendRadio(g0,sizeof(g0));
      } 

     if (c=='C') // toggle 2 codes back and forth for range testing
      {
       Serial.print(F("Test toggling..."));
       for (int a=0;a<200;a++)
       {
         sendRadio(g1,sizeof(g1));
         delay(1000);
         sendRadio(g2,sizeof(g2));
         delay(1000);
       }
       Serial.println(F("Done"));
      } 
}

void setup() // set serial speed, set output for the radio output - and put something on screen to show it's working - use built-in F() to save RAM
{
    Serial.begin(SERIAL_SPEED);    
    pinMode(PIN_DATA_OUT, OUTPUT);    
    digitalWrite(PIN_DATA_OUT, LOW);
    Serial.println(F("Send A to check or B to send example in PROGMEM"));
}

void loop() 
{
    SerialRequest(); // I could have just put the lot in here really
}

and here is the second – playback only…

// I used a simple 433Mhz tx  - 1 pin each needed. Output of radio assumed 1 when something there ie active high
// Coding Peter Scargill June 2014. www.scargill.net

#define SERIAL_SPEED 115200

#define R433_PIN_DATA_OUT 2
#define R433_INTER_CMD_MS 100
#define R433_CMD_REPEATS 5

// Byron reports 39us*10 for period - didn't work - so I put in 59 - works a treat.

const byte g0[] PROGMEM={64,77,211,36,73,146,36,73,210,52,1};  
const byte g1[] PROGMEM={64,73,211,36,73,146,36,73,210,52,1};
const byte g2[] PROGMEM={64,77,211,36,73,146,52,73,210,52,1};

void sendrad (const byte *code_buffer, int sz) // can't do sizeof a PROGMEM array so just pass the size
{
   int scount;
   int offs;
   int period;
   byte enc;
   long mydelay;
   
   period=(int)pgm_read_byte(code_buffer)*10; // get the first value, multiply by 10 and that is your period
   for (scount=0;scount<R433_CMD_REPEATS;scount++)
     {         
       for (offs=sz-1;offs>0;offs--) // start at the end and work backwards not including offset zero which is the (period/10)
          {
          enc=pgm_read_byte(code_buffer+offs);
           for (int r=0;r<8;r++) 
             { 
             if (enc&128) digitalWrite(R433_PIN_DATA_OUT,HIGH); else digitalWrite(R433_PIN_DATA_OUT,LOW); 
             mydelay=micros()+(unsigned long)period; 
             while (mydelay>micros()); 
             enc<<=1; 
             }
          } 
        digitalWrite(R433_PIN_DATA_OUT,LOW); delay(R433_INTER_CMD_MS);
     } 
}

// Listens to SERIAL for inputs A=read, B=write demo - when reading press and hold handset FIRST
void SerialRequest()
{
   char c;
   while (Serial.available()==0);
   c=toupper(Serial.read());
   switch(c)
   {
      case 'A' :  sendrad(g0,sizeof(g0)); break; 
      case 'B' :  sendrad(g1,sizeof(g1)); break; 
      case 'C' :  sendrad(g2,sizeof(g2)); break; 

      default  :  break;    
   }
}

void setup() // set serial speed, set output for the radio output - and put something on screen to show it's working - use built-in F() to save RAM
{
    Serial.begin(SERIAL_SPEED);    
    pinMode(R433_PIN_DATA_OUT, OUTPUT);    
    digitalWrite(R433_PIN_DATA_OUT, LOW);
    Serial.println(F("Send A to N to send examples in PROGMEM"));
}

void loop() 
{
    SerialRequest(); // I could have just put the lot in here really
}

The old remote control is starting to get a little out of hand and I’ve not even started yet. This test page controls 8 digital outputs and 3 fader controls for LED ARRAYS… offering various light-up commands now – as well as turning stuff on and off, I can control lights based on light-up and dawn settings!

Once the technology is out of the way I’m going to have to think of ways to simplify this!

Meanwhile Maureen is walking around looking bashed – the insects have got her again – they don’t half make a mess. I can see her being on anti-histamines to get the swelling down.

Remote controls I left in Spain are working but the radio link isn’t perfect, seems to vary with temperature or more likely humidity as it’s the rocks that get in the way of the signal. (Update August 2014 – all sorted – controllers in Spain operating perfectly).

Next job – throwing out old rubbish – we’re moving shortly (hence the rush to get the home control stuff ready for prime time) – so I’m going to have to be ruthless – if it’s not been used in 3 years – bin!

One for the techies

In between enjoying the sun, painting and keeping up with FSB work, I’ve been working on my home control hardware and software while here in Spain – and I’ve been constantly battling to ensure that various sensors in use don’t get in the way of the NRF24L01 radio links which need to be polled constantly (until someone comes up with a SAFE way to do this under interrupts).

One issue is the Dallas DS18B20 temperature sensors – accurate but slow (or so it seemed). Most of the Arduino code out there is rehashing of original ideas presented  in the Arduino playground – and the most popular example resets the chip – builds up the data  – resets it, reads the data – and produces a result. I say Arduino – I don’t use their boards, I do my own – but as I’m using some of the free libraries and the IDE I think the name deserves credit.

Take a look at the this typical code below – firstly it does a scan to see what is available on the wire.. Well, if you only have one Dallas chip on a wire – you KNOW it’s there! Then it checks for a bunch of chips that are not being used.. then it checks for mode  – the default will always be 12-bit operation unless you actually tell the chip otherwise! Now, you could argue that conversion time is shorter if you go for less accuracy – but are you really going to check the temperature more than every few seconds max? 

It then implements a wait of nearly a second after starting the conversion before reading it.

The problem with the existing code is that it wastes your time EVERY time it checks builds up the reading. Surely a better way would be to do that while you’re doing something else?

As I’m powering my chips from 5v I wondered if I could do away with that 1-second delay. Indeed it appeared I could – but not for all variations – for example the P suffix version just returned garbage.

Having gotten rid of all the un-necessary stuff I’ve mentioned above, it then it occurred to me… why not put the conversion at the END (ie writing 0x44) – ok on first power-up, reading will be rubbish – so I put a loop in to stop that – if the conversion is rubbish (ie over 100 degrees c) then simply loop through again after a delay – that sorts the initial case. So that does away with the delays ASSUMING you’re likely to take readings slower than 1 second apart – the important thing is to be able to minimise your time sitting in that routine. The first shot below has the delay down to around 30ms.

For my purposes I don’t need accuracy better than 1c… but simply using an integer means truncating down so I also added in a check for the 0.5c bit – to correct the temperature so it is truly accurate to the NEAREST degree C.  That got rid of the FLOAT. THEN I realised that they were using  12-byte buffer – WHY when you’re only interested in the first 2 bytes..Another 10 bytes gone.

By passing the port bit to the function you don’t have to set that up separately – so a single, self-contained function can call chips on any pin –one per pin!

Here’s the end result of version one as a complete test sketch – as they say, shorter, faster, better. Feel free to use. In my test there is a delay of a second between readings but in reality you’d be doing something else – just make sure you leave around a second before you come back to read the sensor  – or more of course. If you have sensors on Arduino bits A4 and A5 as I do – with 5k or thereabouts pullups and the +v wire going to 5v – this should work out of the box. Note the VERY short time between reading the two sensors.

But then – thanks to a chat with my friend Peter Oakes and a FURTHER read of the datasheet – I’ve realised you neither need the checks at the start if you’re on reasonably short wires NOR the address if you only have one chip per pin.

And so VOILA – a routine that takes maybe 5ms to run – yes FIVE MILLISECONDS – and uses even LESS RAM and is simpler…. enjoy. Sorry, some day I’ll figure out how to put code in here without it looking awful – hence the images. The ++result below and above is the 0.5c correction. In this final version – I’ve included a call to go into the setup – to ensure that by the time you use the function properly you’re getting proper data – ie no false data on the first read. Note that the second parameter is always 0 (zero) except in the setup routine – THAT call will take a second per unit.

I travelled down to London yesterday for the Internet show in Earl’s court. Long overdue for catching up with the latest due to being bogged down with work most of the time, I took a member of my committee along with me to go see what’s new and hopefully bring home some new ideas.

We started the trip last night at Brick Lane in London  -the weather there right now is fabulous – I took the tube from Victoria to Aldgate East and walked the rest of the way with thanks to Google maps on the phone. I met up with the guys at a pub called the Princess Alice where we had a couple of beers before heading off to Brick Lane and the myriad of Indian restaurants therein.

We usually end up at the same place and so it was that we got our free beer, free starters and 20% off – it takes no bartering at all to get this. Cracking night with a fellow techie.

This morning we were up sharpish and off down from our hotel in Victoria – the Double Tree in Bridge Place,  to head off on the tube to the event.

Internet World was not as big as I’d hoped – some day I must go to one of those shows in Europe – we managed to get through it in the morning rather than the whole day but in the process, met some good contacts, I certainly gained some great ideas and generally got up to speed with what’s out there. As well as business-oriented stands the people from “The Internet of Things” were there with some fabulous Internet-connected toys.

That left only one thing to do – get back to the office in Victoria… grab some kit and head off home. As we were sitting in Earls Court having a bite to eat for lunch – and being as it was a lovely day, having no idea of distances I suggested a walk to the Thames – and that became the start of a nearly 4 mile walk along the Thames and back up to Victoria – for which I am now suffering.

On the way back I had to walk through the Centre for Life in Newcastle and there was a big sign up advertising Maker Faire this weekend which is all about robots, 3d printing machines and other interesting stuff so I’m sure we’ll end up there at the weekend… but first there’s the slight matter of the Iron Man 3 movie!

Ok, so I’ve rekindled my interest in electronics with a vengeance. I’ve a load of gadgets I’ve been wanting and not finding anything reasonably priced out there I decided to get the soldering iron out and make them myself.

And so it was that I started looking at processor boards out there to make use of the popular Arduino design. I say design, the basic Arduino is really very little more than a manufacturer’s minimum setup – but the important thing is the volume of support software out there – in particular Ethernet software making it possible to create Internet-enabled devices such as my “EtherStat” Ethernet-and-infra-red-controlled unit which has now been on test for the past couple of weeks without a hitch and which will soon end up running Hollyberry Cottage.

None of the boards out there are without issue and so three of us collectively decided we’d have our own board and I took on the design job.

Armed with Eagle PCB package with which I’m well familiar (though I had some catching up to do) and a little imagination I set off putting this together from scratch -  I should at this time thank friends Jonathan and Aidan for the encouragement and also the latter for checking my work and generating the “Gerber” files etc.

The result – here it is..I nicknamed it ”UberBareBoard” as it has everything except the kitchen sink in it (feel  free to zoom in on any of these images which should expand or “lightbox” if you click on them).

The board follows the same form factor as the original Arduino though that was only by chance as I spotted an open-source version of the board outline and connectors. Having put several commercial boards together into various test projects, I came across the same problems every time – not enough power connectors, regulator getting hot, parts too close together, same pins used multiple times- and so what you see here is fairly simple but with sufficient extra pins to make life easy for lash-ups.

In the bare-board image above you’ll see on the front-left a 10-way connector – that’s for the cheap Chinese radio boards. Lower left there’s a 6-way connection – that’s pretty standard as are the outer connectors giving access to the 19 I/O pins and power and ground. Note top left the regulator is mounted flat on plenty of copper board (both sides) to dissipate heat and there’s room for a standard power connector (standard that is unless you’re Maplins who have a HOPELESS and hopelessly over-priced selection of connectors).

At this point it’s probably better to look at the populated board. Front right you’ll see a LED which is attached to D13, a far better place than making a power led as you can see the board working on power up (it flickers). Over on the right I’ve left room for a 3-pin infra-red receiver and a LED to go with that. Top right is the reset button, left from there the standard programming connector and left again (ie upper middle) you’ll see a power (+5 and GND) connector and a 2-pin battery connector. Relevant diode and charge resistor are fitted. The empty socket is for a 24c256 chip (64K EEPROM) and centre front you’ll see 2 diodes, they’re to drop the 5v supply sufficiently to use with the radio or Ethernet modules.

Mass production? No, we scoured the web for cheap UK prototype suppliers and ended up sending off to China for a set of 10 prototypes at a reasonable price – somewhat over a fiver each – and this for fully tinned, masked, cut to size prototypes of production quality. I’ll be using these guys again – turnover was little over a week.

I’m happy to say that apart from not having sufficiently small 1k resistors to mount them horizontally (that’s what I get for using standard library parts and not checking) and getting the mounting hole layers wrong (hence no mounting holes, quickly corrected with a drill) the boards work perfectly – and I have lots of plans for them.

This article was written as a follow-up to the original cottage thermostat article – and the first follow-up to this is here – NRF24L01 transceiver and Arduino.

It’s been a quiet weekend up to now, got my grandson over, last night we had WAY too much to drink with friends so I’ve been hiding away in my office with the soldering iron to recover. The Internet Thermostat is sitting testing 24/7 – I’m determined to leave it for a couple of weeks to make sure it is reliable before actually using it to control heating!

So, having grasped the basics I’m now 90% through my next project. The board you see to your right is an 8-relay controller, capable of switching 8 devices (lights, heaters etc etc) at up to 2Kw each. You see the relay panel at the bottom, microprocessor on the left and Ethernet controller on the right. The primary control is via the Internet, from, say, my iPhone but I’ve added infra-red remote control (the little green thing top left) and tomorrow depending on the weather I plan to add short range radio control also. The idea being that this would be controllable by short range radio but also that the power of the board could be extended to a further up to 8 relays (or more) for those hard to wire places… depending on the reliability of the radio (I know it works as I had a test rig up with two of them chatting to each other – but I don’t yet know how reliable the radio is.

That’s my next job…