Scargill

Archive for the ‘Radio Control’ Category

After several weeks of flawless weather in Spain, it’s been a struggle getting back into the swing here in the UK where it is raining more often than not. Still I can always look over there using my cameras to remind me of the sun.

Meanwhile, after months off due to a death in the family and then a broken foot (you can’t make this stuff up) Maureen is now back to work and meanwhile I’m about to embark on a series of meetings taking me from Blackpool to Crewe and onto London. It’s going to be a busy week.

Over the weekend I’ve been catching up with emails, finding out what’s going on at work – and doing a little more research into my home controls as well as catching up on episodes of “Cosmos” – which I intend to continue this week as I’ve loaded up the tablet with remaining episodes to catch late at night in my hotel (well, it beats hotel TV). Got the Bluetooth headphones all charged up and ready.

While we were in Spain I ordered a pair of cheap SI 4432-based 4.33Mhz transceivers and I had high hopes for these after the abysmal results I’ve been having with 2.4Ghz radios thanks to interference from WIFI, cordless phones and a thousand other sources of radio crap.

This weekend I tried the PA-enhanced version of the NRF24L01 radio to help me expand my home control setup – one worked – the others failed as they often seem to do – I can’t get to the bottom of it other than to suspect there is an issue with SPI (communication) speed and these radios – as the cheap ones work every time. Others have said similar. Having abandoned the more expensive types, I used my air gun to remove the aerial from one and grafted it onto one of the cheap versions. As you can see in the image below, it looks ok – simply a matter of cutting the original aerial track – 5 mounting holes and a couple of VERY short wires.

I can say for sure that the aerial-enhancement modification is robust and improves range – but I doubt it it even doubles the range which still remains pitifully short in a stone building – and of course the cost to buy these adaptors and aerials individually far exceeds the cost of them as part of a radio!

I then tried the 433Mhz units which came complete with a coiled spring aerial.  I carefully put two of these units together using our Arduino look-alike boards. These are not easy to use as the edge connector is 0.05” centres – you really need a fine soldering iron which I just so happen to have. Despite all that, I ended up with one board (apparently) working – it the code was working – but the other remained defiantly dead. So many things could be wrong – the code, the wiring, the interfacing… these are 3v3 boards and my Arduino clones are 5v. I fed the boards with 3v3 and ran the inputs to the radio via resistors. I’m pretty sure that part is correct.

In the process I found a bug in the Radiohead library I’ve been using and the authors fixed it almost immediately which is nice.

The end result looked a little messy due to wiring and resistors – but actually I was quite pleased with the overall fit for a first attempt – not so pleased with one unit apparently dead.

When I checked, the other board had 2 pins shorted – no matter what I did I could not find the short – I can only imagine it was under the 0.05” connector – even a magnifying glass showed no issues – and attempting to remove the connector with the air gun resulted in the board’s destruction. I now have a 2 week wait before I can progress this one (not that it matters as I’m in meetings for over a week). The hope is that these 433Mhz units will have a better chance of going through thick stone walls – I’ll have to wait and see. Next time I’ll nix the connector.  I’m also interested in the new cheap WIFI embedded units which can be bought from Ebay as low as £8 – for now however both the embedded software and the instructions are in Mandarin so that will have to wait a while.

In a couple of weeks I’m going to spent time with a friend as we examine the powerful Atmel radios, not in the same price class but it’s worth exploring all avenues.

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
}

I’m spending some spare time right now working on the home control. My first system is working at home in the UK with a nice little 2-line LCD giving out useful information (as well as accessing that information on the mobile phone of course) but a little while ago we spotted some inexpensive colour LCDs from China – somewhat under £3 each – well you can’t let an offer like that go.

These displays need 5 resistors to work and some software – the library to drive them took some finding and it was originally quite slow but my friend Aidan changed it to work with SPI and I did some more and eventually we got these cheap displays to work perfectly. They look really neat but for some reason my camera just won’t capture the sharp and vibrant colours so you’ll just have to take my word for it. Nice displays.

And so – as of a little while ago – my first working MK2 is ready to go. As well as peak and standby heating control I’ve added a frost setting – up to 255 days hold-off during which time the heating will only come on if the temperature gets below 5c… handy for the cave in Spain perhaps.

The LCD display shows the current humidity, the date, the inside and outside temperatures, the set and fall-back temperatures along with the number of hold-off days.  Below that is the current time (updated every second) and then the dusk and dawn times which are automatically calculated every day. The internal and external temperature displays along with humidity also have trend indicators not shown here.

All working and the phone displays you see are as they appear on my Samsung S4 smartphone…  though I’m not currently actually controlling the heat in Spain but once back in the UK I’ll adapt this to work with the controller in Wark.

The main controller, having moved to the larger 1284 chip – now has all the I/O of the radio slaves and so can function as a stand-alone unit if necessary, simply plugged into the router to give remote control. I played around for a while with adding the display onto the main board but that was slowing things down and ultimately I’ve gone with sending a package out of the serial port so that a separate board, if needed, can handle the display. For my first shot I’ve done a colour LCD board with infra-red remote input – the idea being to add temperature up and down via infra-red for the rental cottage.

I did have 4 fader (PWM) outputs on each of the boards but in the latest update I’ve added a library to both to handle the new serial LEDs – the ones that can be individually programmed and I’ve added commands to change colour and brilliance on these.

The two diagrams below show the main controller utilising a 1284 chip (for extra memory and I/O) which in addition uses a standard Ethernet card and an NRF24L01 radio board…(getting 3v3 from the Ethernet card to feed the NRF)

Below that is a slave board which merely uses a 328 chip and again the NRF24L01 board (with 3v3 regulator onboard) for communications. The master is just cluged on breadboard for now.

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 after this… the April update!