Home Automation – Receiver

 Arduino, DIY, Electronics, Home Automation  Comments Off on Home Automation – Receiver
Aug 112015

I have made a couple of attempts over the past years to make a Home Automation Receiver with an Arduino Uno and a simple 433MHz receiver.
But so far I have failed, believing the Uno maybe wasn't fast enough for the task at hand.
By chance a colleague of mine stumbled upon my blog, and wondered if I did not have any such receiver at hand, since I had made transmitters way back in time.
I told him about my endeavors and my disbelief about the performance. Luckily he did not listen too much, and did some internet searching.
Of course there are sketches out there for the receiver task. After looking at some of them I decided to try to do one myself.
One major difference in my new sketch, compared to my older attempts, is the use of pulseIn(). Before I tried to sample with digitalRead()  but could never get a consistent result.
With pulseIn() we detect only the low part of the pulses, and by comparing the length of the low part, conclude what type of bit it was.

This is what the HW setup looks like.

Here is the sketch.

   Joakim Wesslen

   We detect data pulses by catching the low part of every pulse.   


More info at:  

Physical data structure (in air):
0        10        20        30        40        50           60
1234567890123456789012345678901234567890123456789012 34 56 7890 1234

Bits #01-52 -> TxCode (T)
Bits #53-54 -> Group (G)
Bits #55-56 -> On/Off (O)
Bits #57-60 -> ? Dimming/Channel ? (D)
Bits #61-64 -> Device Nbr (N)

Logical data structure:
0        10        20           30  
12345678901234567890123456 7 8 90 12

Bits #01-26 -> TxCode (T)
Bits #27 -> Group (G)
Bits #28 -> On/Off (O)
Bits #29-30 -> ? Dimming/Channel ? (D)
Bits #31-32 -> Device Nbr (N)


int rxPin = 12;

boolean debugOn = false;  // enable debug prints

int tPause = 0; // debugging
int tSync = 0; // debugging

unsigned long loopCounter = 0;  // stats
unsigned long dataCounter = 0;  // stats

// Setting limit boundaries
int pauseMinTime = 7000;
int pauseMaxTime = 14000;

int syncMinTime = 2100;
int syncMaxTime =  3200;
int oneMinTime = 70;
int oneMaxTime = 300;

int zeroMinTime = 1000;
int zeroMaxTime = 1900;

signed long timeout1 = 1000000;
signed long timeout2 = 100000;

#define MAX_STR 150

char bin[MAX_STR + 1];

// get a 'binary' 32 bit string from value
char *dec2binStr(unsigned long ul)
 int len = sizeof(ul) * 8;
  int c, d;
  int count = 0;

  memset(bin, len, '0');

  for (c = len-1 ; c >= 0 ; c-- )
    d = ul >> c;

    if ( d & 1 )
       bin[count] = '1';
       bin[count] = '0';
  bin[len] = '\n';
  return bin;

// log function
void ilog(const char *fmt, ...)
  char tmpStr[MAX_STR + 1];
  va_list ap;

  va_start(ap, fmt);
  vsnprintf(tmpStr, MAX_STR + 1, fmt, ap);

// debug log function
void dlog(const char *fmt, ...)
  if (debugOn) 
    char tmpStr[MAX_STR + 1];
    va_list ap;

    va_start(ap, fmt);
    vsnprintf(tmpStr, MAX_STR + 1, fmt, ap);

char binPhy[MAX_STR + 1];

// get a 'binary' 64 bit string from value
char *dec2binPhyStr(unsigned long ul)
 int len = sizeof(ul) * 8;
  int c, d;
  int count = 0;

  memset(binPhy, MAX_STR, '0');

  for (c = len-1 ; c >= 0 ; c-- )
    d = ul >> c;

    if ( d & 1 )
       binPhy[count] = '1';
       binPhy[count+1] = '0';
       binPhy[count] = '0';
       binPhy[count+1] = '1';
    count += 2;
  binPhy[len*2] = '\n';
  return binPhy;

// debug statistics printout
void printStats(unsigned long loopCnt, unsigned long dataCnt)
  ilog("Loops: %d, Packets: %d", loopCnt, dataCnt);

// print decoded receiver data
void printPacketData(unsigned long data)
  ilog("Received: %s", dec2binStr(data));
//  ilog("ReceivedPhy: %s", dec2binPhyStr(data));

// receiver for home automation data
void dataReceiver(void)
  dlog("--- Wait for Pause and Sync ---");

  int i = 0;
  signed long t = 0;
  byte prevBit = 0;
  byte currBit = 0;
  // Packet data, logical structure
  unsigned long dataPacket = 0;

  // Wait for Pause bit (10500 us).
  while ((t < pauseMinTime) || (t > pauseMaxTime))
    t = pulseIn(rxPin, LOW, timeout1);
  tPause = t; // Save timing for debugging purposes
  if (t == 0)
    dlog("!!! - Pause Timeout - Start over.");
    goto start_over;

  // Wait for Sync bit (2750 us).
  while ((t < syncMinTime) || (t > syncMaxTime))
    t = pulseIn(rxPin, LOW, timeout1);
  tSync = t; // Save timing for debugging purposes
  if (t == 0)
    dlog("!!! - Sync Timeout - Start over.");
    goto start_over;

  // data collection loop
  while (i < 64)
    t = pulseIn(rxPin, LOW, timeout2);  // shorter timeout?
    if (t == 0)
      dlog("!!! - Data Timeout - Start over.");
      goto start_over;
    else if (t > zeroMinTime && t < zeroMaxTime)
      currBit = 0;
    else if (t > oneMinTime && t < oneMaxTime)
      currBit = 1;
      dlog("Incorrect data - Start over. t=%d", t);
      goto start_over;

    if (i % 2 == 1)
      if ((prevBit ^ currBit) == 0)
        // must be either 01 or 10, not allowed to be 00 or 11
        dlog("Bad data - Start over");
        goto start_over;
      // Store packet bits
      dataPacket <<= 1;
      dataPacket |= prevBit;
     prevBit = currBit;
   if (i > 0)

void setup()
  pinMode(rxPin, INPUT);
  ilog("Home Automation Receiver");

void loop()

Next, I shall try and make this into a library.

Review – Home Automation with Arduino

 DIY, Home Automation, Review  Comments Off on Review – Home Automation with Arduino
Nov 012014

This post is a review of a couple of eBooks I have received from Marco Schwartz, who runs the site over at Open Home Automation.

He has produced a series of books on the Open Source Home Automation theme. They are intended for anyone, from the complete beginner to the more experienced maker, who is interested in making a home automation system of their own.

I find the books very well structured, and easy to read and follow. Everything in the books are open source, and as such it is of course available on the internet. But these books do a very good job of putting it all together into a complete project structure.  They are very inspiring, and makes me want to start creating a project right away.

The complete series comprises:
* Introduction to Arduino
* Home Automation with Arduino
* Design Guide for Home Automation
* Internet of Things for Home Automation
* 3D Printing for Home Automation

Where the first book is for the complete beginner with breadboard projects. The rest of the books and  projects get more complex, but also more and more interresting.

You can find more info, and buy the books from here, http://www.openhomeautomation.net/home-automation-arduino/.

Micro Python

 DIY, Electronics, Python  Comments Off on Micro Python
May 182014

Received my Micro Python board on the 12th of May which is a Kickstarter project I supported back in November last year, https://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers.

I just backed the project as I thought it was an interesting idea to use python in an embedded product.
So far I haven't had time to play around with it much, but I am really looking forward to it.

Here is the official web site for the project, http://micropython.org/.

board and box

One thing I noticed though upon starting the device up is that, at least on my Ubuntu machine, I did not get the pop-up window of the pyboard drive as described in the tutorial, if I have the SD-card inserted. If the SD-card is inserted, the only thing I get is the USB drive of that card. Without the SD-card inserted, I get the pyboard drive with the files mentioned. So I will go on without the card for now.

The tutorial, http://micropython.org/doc/tut-contents, is really nice and easy to follow.

To get a micro python prompt to write instructions directly to the board do,

screen /dev/ttyACM0

This is what you get from the help() function on micro python interpreter.

>>> help()         
Welcome to Micro Python!

For online help please visit http://micropython.org/help/.

Quick overview of commands for the board:
  pyb.info()    -- print some general information
  pyb.gc()      -- run the garbage collector
  pyb.delay(n)  -- wait for n milliseconds
  pyb.Switch()  -- create a switch object
                   Switch methods: (), callback(f)
  pyb.LED(n)    -- create an LED object for LED n (n=1,2,3,4)
                   LED methods: on(), off(), toggle(), intensity()
  pyb.Pin(pin)  -- get a pin, eg pyb.Pin('X1')
  pyb.Pin(pin, m, [p]) -- get a pin and configure it for IO mode m, pull mode p
                   Pin methods: init(..), value([v]), high(), low()
  pyb.ExtInt(pin, m, p, callback) -- create an external interrupt object
  pyb.ADC(pin)  -- make an analog object from a pin
                   ADC methods: read(), read_timed(buf, freq)
  pyb.DAC(port) -- make a DAC object
                   DAC methods: triangle(freq), write(n), write_timed(buf, freq)
  pyb.RTC()     -- make an RTC object; methods: datetime([val])
  pyb.rng()     -- get a 30-bit hardware random number
  pyb.Servo(n)  -- create Servo object for servo n (n=1,2,3,4)
                   Servo methods: calibration(..), angle([x, [t]]), speed([x, [t]])
  pyb.Accel()   -- create an Accelerometer object
                   Accelerometer methods: x(), y(), z(), tilt(), filtered_xyz()

Pins are numbered X1-X12, X17-X22, Y1-Y12, or by their MCU name
Pin IO modes are: pyb.Pin.IN, pyb.Pin.OUT_PP, pyb.Pin.OUT_OD
Pin pull modes are: pyb.Pin.PULL_NONE, pyb.Pin.PULL_UP, pyb.Pin.PULL_DOWN
Additional serial bus objects: pyb.I2C(n), pyb.SPI(n), pyb.UART(n)

Control commands:
  CTRL-A        -- on a blank line, enter raw REPL mode
  CTRL-B        -- on a blank line, enter normal REPL mode
  CTRL-C        -- interrupt a running program
  CTRL-D        -- on a blank line, do a soft reset of the board

For further help on a specific object, type help(obj)

To close the screen session do 'Ctrl + a' and 'Ctrl + d' in sequence.

As I said before, really looking forward to digging deeper into what I can do with this board.

Home Automation – RF Protocol, update.

 DIY, Electronics, Home Automation  Comments Off on Home Automation – RF Protocol, update.
May 012014

Since I wrote the posts on 'Home Automation RF Protocols for simple devices' back in 2012, I have received some questions and feedback, which I find very enjoyable. Unfortunately I have had to turn off the comment options, as I have also received a lot of spam. Still people who really want to, have managed to find my email address (in the 'About Me' page). Some of the questions was on devices which I haven't made the decoding of myself. This made me quite curious, so I went and bought some of these devices.

Now I have three different makers of simple devices, namely Proove from 'Kjell & Company', Anslut from 'Jula', and Nexa which is a wellknown brand not belonging to a special franchise but can be found almost anywhere.

Starting with the 'Anslut' devices, it is really similar to the Proove one when just looking at them. Here is a picture of the transmitters, with Proove to the left and Anslut to the right.



Opening the Anslut transmitter the PCB is also identical to Proove, but checking the IC, it was not the same as in my Proove transmitter.
This one was labeled,
But after some searching on the internet it seems to be made by Holtek too.
I would imagine it is just another version of their '8-Bit OTP MCU with RF Transmitter' line-up of IC:s.
The Xtal is marked 13.560 MHz, which is 1/32nd of 433.92 MHz.

The pin-out of the IC is identical to the one on the Proove device

 Vcc  9-|       |-8 Vcc
     10-|       |-7
     11-|       |-6
 Vcc 12-|       |-5 SW4
 SW8 13-|       |-4 SW3
 SW7 14-|       |-3 SW2
 SW6 15-|       |-2 SW1
 SW5 16-|      o|-1 Dout

As everything is so similar between these devices, I strongly suspect the decoded data to also be very similar.
This time around I have a digital logic analyzer to decode the data transmitted on the Dout pin.

To my surprise I see a packet burst consisting of SIX packets, and not four as I saw last time. Of course this is most likely due to measurement tool limitations, as I used a USB oscilloscope last time, and it might not have had the bandwidth/capacity to capture all of the data. Anyway, this is what it looks like with the logic analyzer.



Zooming in a bit on the packet burst.


Zooming in on one packet to decode bits.


Defining the pulses.
High 250 us, low about 2750 us  -> Sync
High 250 us, low about 1500 us. -> Zero (0)
High 250 us, low 250 us. -> One (1)
Last bit.
High 250 us, low 10500 us. -> Pause
A packet consist of, Sync + Data + Pause.

Decoding 'Data part' of a packet.

0        10        20        30        40        50           60
1234567890123456789012345678901234567890123456789012 34 56 7890 1234

Bits #01-52 -> TxCode (T)
Bits #53-54 -> Group (G)
Bits #55-56 -> On/Off (O)
Bits #57-60 -> ? Dimming/Channel ? (D)
Bits #61-64 -> Device Nbr (N)

As every other bit sent over the air is redundant, it is the inverse of the previous bit, the packet consist of 32 logical bits

Going back to my Proove tranmitter, and hooking it up to the digital logic analyzer, it also shows a packet burst consisting of six packets. All of the decoding is the same as for the Anslut device.
Defining the pulses.
High 250 us, low about 2500 us  -> Sync
High 250 us, low about 1250 us. -> Zero (0)
High 250 us, low 250 us. -> One (1)
High 250 us, low 10000 us. -> Pause

Time to check the Nexa device. Note this is the simple version, and cheap, of their devices.

First I open up the transmitter, and can immediately see that it is completely different to the other ones.


This is how the other side of the pcb looks like.


The component on the frontside marked 'H R4334' at position SAW101, is a SAW filter with three pins.
1 - Input
2 - Output
3 - GND

Debuging the IC, which has no markings on it, on the backside gives.

 5 -|        |- 4 
 6 -|        |- 3 
 7 -|        |- 2 
 8 -|       o|- 1

Using the oscilloscope to have a look at the signals.	 
1 - 3.8 V
2 - Dout, Pulse train when pressing button
3 - 
4 - 3.8 V noisy
5 - < 1 V rippled
6 - same as 5
7 - same as 5
8 - GND

So, we seem to have a Dout pin here too. Time to hook up that analyzer again.

This is what a packet burst looks like. Note, only five packets in the burst.

Zooming in a bit on that burst.


Finally here is how a packet looks like.


Data part time decoded:
High 250 us, low 2750 us -> Sync
High 250 us, low 250 us -> one
High 250 us, low 1250 us -> zero
High 250 us, low 10000 us -> Pause

This is exactly the same as the Proove device timing, and as expected the data part of the packet is also the same as the Anslut and Proove devices.

With this new knowledge, I have decided to update/change my 'Home Automation, RF Protocols' page to reflect my new findings, and to only have device data which I have decoded myself.

I have also updated the Arduino library that I made some years ago. Since there are some differencies between Proove/Anslut and Nexa, such as the channel code and the way to number unit 1 to 3, I made two librabries: Proove/Anslut and Nexa.

Arduino with Relay module

 Arduino, DIY, Electronics  Comments Off on Arduino with Relay module
Nov 022013

Got myself a relay module the other day, as I wanted to use an actuator, and the current supplied from the Arduino itself was not enough to make it work.

This is what I got, http://www.kjell.com/sortiment/el/elektronik/mikrokontroller/arduino/relamodul-for-arduino-p87878.

Here is how I connected the 'Songle SRD-05VDC-SL-C' relay with an actuator to an Arduino.

The pin marked:
'+'  connected to 5V from Arduino
'- ' connected to GND from Arduino
'S' connected to GPIO#2 from Arduino

In the other end connect the middle connector ('Common') to an external voltage source,
in my case 5V, as the actuator was a 5V actuator. The NO ('Normally Open') connector is strapped to one of the actuators input. The NC ('Normally Closed') connector is not used. The other actuator pin is connected to the external power sources GND completing the circuit.

When the GPIO#2 is put high, the external 5V source is fed to the actuator, making it move.
So the only thing you need in your Arduino sketch is 'digitalWrite' of the proper GPIO.
It took me some time to figure the relay out, since I watched some instruction on the internet on how to connect a relay, and all of them used some external diodes and transistors.
But that is not necessary with this one, as it is already mounted on the PCB of the relay module.

ASCII art of the setup:

Arduino |      -----------------
        |      |               |
        |      |     Relay     | 
   5V  --- + --|               |-- NC
        |      |     module    |
   GND --- - --|               |-- Common ---------------- 5V external src
        |      |               | 
GPIO#2 --- S --|               |-- NO -----|
        |      |               |           |       ------- GND external src
        |      |               |           |       |
        |      -----------------           |       |
---------                                  |       |
                                           |       |
                                         |            |
                                       ==|  Actuator  |=====|
                                         |            |

The vendor data sheet of the module, http://www.songle.com/en/pdf/20084141716341001.pdf

Arduino – Home Automation Project, part 2.

 Arduino, DIY, Home Automation  Comments Off on Arduino – Home Automation Project, part 2.
Apr 242012

Well, at last I have made a simple Arduino library of the previous Tx433_Proove sketch. I have pushed the complete code up on GitHub.

Here is the public class interfaces.

class Tx433_Proove
@digitalpin - the digitalpin to send data on to transmitter
@transmittercode - the unique code of the transmitter (52 bits)
@channelcode - the channel code (4 bits)
Tx433_Proove(int digitalpin, char *transmittercode, char *channelcode);

@unit - the device to turn on.
0,1,2 are the three separate devices.
3 is the complete group.
void Device_On(int unit);

@unit - the device to turn off.
0,1,2 are the three separate devices.
3 is the complete group.
void Device_Off(int unit);

Made a new page at http://elektronikforumet.syntaxis.se/wiki/index.php/RF_Protokoll_-_Proove_self_learning to give something back to a great site.

Also added a new link at http://arduino.cc/playground/Main/LibraryList pointing at the Github upload.

Arduino – Home Automation project

 Arduino, DIY, Home Automation  Comments Off on Arduino – Home Automation project
Apr 152012

Something I have thought about, on and off, for a long long time is to setup some remote controlled lamps at home.
I have read about the Tellstick from Telldus, but that requires a computer for controlling it. Also I have read and heard that the RF performance/reach is somewhat restricted.
Another solution is of course to use the Arduino together with a RF transmitter.
The different devices available in the stores are all using the same RF frequency, 433.92 MHz, with ASK modulation.

As this is the true DIY solution, I got both a transmitter and a receiver for this frequency 🙂

The transmitter, http://www.kjell.com/sortiment/el/elektronik/fjarrstyrning/433-mhz-sandarmodul-p88901
Data sheet, http://www.kjell.com/.mvc/Document/File?id=6d308334-d5c5-4ef1-8060-9fb700fc0f01

|       |
|   O   |
|       |
 | | | |
 | | | |
 1 2 3 4

pin    name
1      GND
2      Data In
3      Vcc
4      ANT

The receiver, http://www.kjell.com/sortiment/el/elektronik/fjarrstyrning/433-mhz-mottagarmodul-p88900
Data sheet, http://www.kjell.com/.mvc/Document/File?id=18c020a8-2364-4ee9-a99e-9fb700fc0d73

|                    |
|             O []   |
|                    |
 | | | |      | | | |
 | | | |      | | | |
 1 2 3 4      5 6 7 8
pin    name
1      GND
2      Data Out
3      Linear out
4      Vcc
5      Vcc
6      GND
7      GND
8      ANT

I bought the receiver to be able to sniff the data from the remote controller.

Initially I was going to get some Nexa devices. Something like these, http://www.nexa.se/PB3Ny3packsjalvlarande.htm.
But when I got to the store they didn't have these. Instead they had , http://www.kjell.com/sortiment/el/el-produkter/starkstrom/fjarrstrombrytare/sjalvlarande/fjarrstrombrytare-p50207, which is of the brand Proove. They told me it was the same thing(TM), but of course it would turn out it wasn't.

The reason for me to get Nexa was my research done prior to the purchase.
Well, well, they said it was the same in the store.

At home I fired up the Arduino IDE, and made a first attempt on controlling some lights, by just importing the HomeEasyCtrl library into a sketch as the example showed.
But of course that didn't work. It didn't even compile!
Some quick searching on the net, and I found out that old libraries, using #include "WProgram.h", needs to be updated with the following.

#if defined(ARDUINO) && ARDUINO >= 100
#include "Arduino.h"
#include "WProgram.h"
#include <pins_arduino.h>

With this change it compiles, but it does nothing with my remote controlled light.

Time for some extended research. Found out that Nexa has, at least, two different protocols. The old simple protocol, and the new self learning protocol.
A very good web site describing these protocols are http://elektronikforumet.syntaxis.se/wiki/index.php/Huvudsida, at least if you understand swedish.
I took this information, translated it, at put it on a single page here, http://tech.jolowe.se/home-automation-rf-protocols/.

My next approach, after reading up on the protocol, is to use the receiver to get the data from the remote, without needing to open it up.
After some tries, I got some result which I think is the code sent for turning on device number one.

? 1010100101101001010101100101011001010101010101010110 10 01 0101 0101 ?
? = seems like the start bit and stop bit described in the protocol does not exist.

But when I try to send this myself from the Arduino setup, nothing happens. Frustrating!
I tried this approach several times for several days, with modifications, but without any success.
As I ran out of new ideas on how to proceed, I open up the remote.
This is what it looked like.

The Xtal says 'ND13.560'.
The IC says 'Holtek HT48(or 46)R01T3 ...". Web here, http://www.holtek.com/english/.
Holtek IC pinout:
(by measurement, visual inspection and looking in the datasheet)

Dout -|1   16|- SW5
SW1  -|2   15|- Sw6
SW2  -|3   14|- SW7
SW3  -|4   13|- SW8
SW4  -|5   12|- Vcc?
?    -|6   11|- ?
?    -|7   10|- ?
Vcc? -|8    9|- Vcc?
SWx, is the buttons on the remote.

Web: http://www.holtek.com/english/docum/consumer/4xr01t3.htm
Datasheet: http://www.holtek.com/pdf/consumer/4xR01T3v130.pdf
Pin #1, Dout, is the actual data sent via RF!! This is what we want!
Time to decode (by probing Dout):
Pressing button #1 On switch and capture data with oscilloscope.
A Pause is, approx. 10 ms low.
A Sync is, high 240 us, low approx. 2.5 ms.
Data sent is: 10101001011010010101011001010110010101010101010101101001010101010
Pressing button #1 Off switch.
Data sent is: 10101001011010010101011001010110010101010101010101101010010101010
Zero = high 300 us, low 1.3 ms
One = high 280 us, low 250 us

A packet consist of:
Data 64 bits
The same packet is sent four times.

The above data is THE SAME(!) as I managed to sniff out of the air with my RX433 sketch!
Still, when I send this data, the receiver does nothing.
But if I look at the data I am sending, it doesn't look as nice as the one the remote is sending.
Especially the 'ones' are kind of distorted. The low part is not as 'distinct'. Wonder what the reason could be? Faulty HW?

Continued to probe all data patterns of the remote, while I still had it opened.

#                10        20        30        40        50           60
#       1234567890123456789012345678901234567890123456789012 34 56 7890 1234
#1 On:  1010100101101001010101100101011001010101010101010110 10 01 0101 0101
#1 Off: 1010100101101001010101100101011001010101010101010110 10 10 0101 0101
#2 On:  1010100101101001010101100101011001010101010101010110 10 01 0101 0110
#2 Off: 1010100101101001010101100101011001010101010101010110 10 10 0101 0110
#3 On:  1010100101101001010101100101011001010101010101010110 10 01 0101 1001
#3 Off: 1010100101101001010101100101011001010101010101010110 10 10 0101 1001
Gr On:  1010100101101001010101100101011001010101010101010110 01 01 0101 0101
Gr Off: 1010100101101001010101100101011001010101010101010110 01 10 0101 0101

Here is oscilloscope pictures of a data packet.

Now when I know I have the correct data from the remote, I try and change the HomeEasyCtrl lib accordingly.
But still, nothing happens when I try to send the data.
Just to rule out HW failure, I bought a second TX433 transmitter. But the result was the same. Conclusion, not a HW issue.
Start looking over my TX433 sketch again, and ... ARGHH!!!..., I found an error in my sendZero function.
Correcting that, and moving the Pause bit to after data instead of before Sync - IT WORKS!
Somehow, at least. Every fourth try fails, could it be a timing issue?
Changing the timing of the pulses, and now it works 100%!!!
The timing used now is:
Zero = 250 high, 1250 low
One = 250 high, 250 low
Sync = 250 high, 2500 low
Pause = 250 high, 10000 low.
A packet is sent as Sync + Data + Pause.

Here is my sketch for TX433 Proove,

TX433 - a 433.92 MHz ASK transmitter
Joakim Wesslen

This program handles the 'Proove' devices, not Nexa.

Found the 'Nexa Self learning' protocol description here (in swedish),
From which I started out.

But as it turns out, the Proove protocol is somewhat different.

Here is a brief description.

A packet is 64 bits in toatal (without dimming bits, whichI do not know if it handles).

Packet structure:
Bit nbr:    Name:
01-52       Transmitter code. 26 bits, but sent as 52 as every other bit is the inverse of the previous.
53-54       Group On(01), Off(10)
55-56       On(01), Off(10) (or Dim(11)?)
57-60       Channel. 1=1010, 2=1001, 3=0110, 4=0101
61-64       Switch.  1=1010, 2=1001, 3=0110, 4=0101
(65-73       Dimmer value, 16 steps. (optional))

Every message is started by a Sync (high pulse followed by a 2.5 ms low)
Every mesage is ended by a Pause (high pulse followed by a 10 ms low)
Every message is sent four (4) times.


#define DBGpin  13

#define TXpin  4
#define RETRANSMIT  4

int tOneHigh = 250; //275;
int tOneLow = 250; //170;

int tZeroHigh = 250;
int tZeroLow = 1250;

int tSyncHigh = 250;
int tSyncLow = 2500;

int tPauseHigh = 250;
int tPauseLow = 10000;

char *dim[15] = {

char *On1   = "1010100101101001010101100101011001010101010101010110100101010101";
char *Off1  = "1010100101101001010101100101011001010101010101010110101001010101";

char *On2   = "1010100101101001010101100101011001010101010101010110100101010110";
char *Off2  = "1010100101101001010101100101011001010101010101010110101001010110";

char *On3   = "1010100101101001010101100101011001010101010101010110100101011001";
char *Off3  = "1010100101101001010101100101011001010101010101010110101001011001";

char *GrOn  = "1010100101101001010101100101011001010101010101010110010101010101";
char *GrOff = "1010100101101001010101100101011001010101010101010110011001010101";

void setup() {
pinMode(TXpin, OUTPUT);
pinMode(DBGpin, OUTPUT);
//  dimtest();

void loop() {
//  group(on);

void group(boolean on) {

if (on) {
Serial.println("Group on");
} else {
Serial.println("Group off");

void test() {
Serial.println("Turn on #1");
Serial.println("Turn on #2");
Serial.println("Turn on #3");
Serial.println("Turn off #1");
Serial.println("Turn off #2");
Serial.println("Turn off #3");

void dimtest() {
for (int d = 15; d >= 0; d--) {
for (int i = 0; i < RETRANSMIT; i++) {
sendCode(On1, strlen(On1));
sendCode(dim[d], strlen(dim[d]));

void sendPackets(char *pkt) {
for (int i = 0; i < RETRANSMIT; i++) {

void sendPacket(char *pkt) {
sendCode(pkt, strlen(pkt));

void sendCode(char *str, int len) {
char *p = str;
int i = 0;
while (i <= len) {
if (*p == '0') {
if (*p == '1') {

void sendZero() {
digitalWrite(TXpin, HIGH);
digitalWrite(TXpin, LOW);

void sendOne() {
digitalWrite(TXpin, HIGH);
digitalWrite(TXpin, LOW);

// Sync
void sendSync() {
digitalWrite(TXpin, HIGH);
digitalWrite(TXpin, LOW);

// Pause
void sendPause() {
digitalWrite(TXpin, HIGH);
digitalWrite(TXpin, LOW);

Something I haven't mentioned so far, but as you might have seen in the code above, is the dimming levels.
The devices I have does not seem to use the dimming levels. But when I added it, it still worked, but without dimming.
It justed continued to turn on and off. Other Proove device though, might be able to handle this. I just don't know, as I havent tried it myself.

A small side note of information is that I found out that it is ArcTech that does the HW for Proove and Nexa et al, http://www.arctech.com.tw/html/profile.htm.

A note on the antenna. As the frequency is 433.92 MHz, I used an antenna (just a piece of wire) with a length of 690 millimeters. Also tried a quarter wave antenna, length 170 millimeters, with same result as the longer one.

As I now have a working sketch for the TX433 transmitter, the next step is to make it a library, to make it easier to re-use in other projects. Something new to learn, great!

Arduino – Display project

 Arduino, DIY  Comments Off on Arduino – Display project
Mar 192012

Some time ago I got myself a display, which I was thinking of hooking up to my Arduino Uno.
After having read some examples and reference stuff on arduino.cc and on ladyada.net about the 16 x 2 displays with the HD44780 chip, I was thinking about getting me one of those.
Unfortunately, what I got hold of was a ATM1602B Display, which also is a 16 x 2, but a completely different pin out.
And this is where the problem with this module is, the pin out. The documentation is everything, but clear.
This is a link to its manual and the datasheet.
As can be seen in the provided documentation, they do not number their pins as it is usually done. Starting from 1 (or zero) in one end and increasing it as you move along. No, that seems too easy, doesn't it.
After some trial and error, and measurements, I can conclude that the physical marking on the board is the correct one. Pin number one, is the third pin from the right when looking at the display from the front! The first two pins are the A (anode) and K (cathode) for the backlight.

This is the pin list I used to get it to work.

Arduino         LCD  Name
2               6    Enable
3               7    Data Bit 0 (DB0)
4               8    (DB1)
5               9    (DB2)
6               10   (DB3)
7               11   (DB4)
8               12   (DB5)
9               13   (DB6)
10              14   (DB7)
11              5    Read/Write (RW)
12              4    Register Select (RS)
pot.-out        3    Vo
+5V             2    VDD
GND             1    VSS

Please note, that the pin #1 is actually the third pin from the right when you are facing the display (as stated above).
Here is a link to a page that really help me on the way, http://www.arduino.cc/en/Tutorial/LCDLibrary.
Here is what my final setup looks like.

The potentiometer is 10kohm, and connected between Vdd and Vss, with its output connected to pin 3 (Vo) on the LCD.

Using the LiquidCrystalDisplay library does work well, and is a real time saver to get started quickly.
And here are some simple code to get something up on the display.

/* LCD fun
   Joakim Wesslen
   LCD = ATM1602B
#include <LiquidCrystal.h>
// 4 bit setup
LiquidCrystal lcd = LiquidCrystal(12, 11, 2, 7, 8, 9, 10);
// 8 bit setup
//LiquidCrystal lcd = LiquidCrystal(12, 11, 2, 3 ,4, 5, 6, 7, 8, 9, 10);
void setup(void){
  pinMode(13, OUTPUT);  // dbg
  lcd.begin(16, 2);  // columns, rows

void loop(void){
  digitalWrite(13, HIGH); // dbg

Now when I have the basics up and running, it is time to get into the more interesting stuff to utilize the full potential of the display.

Let's see what we learn in the future!