Sending wireless data from one Attiny85 to another

schema-manchesterI have struggled a lot with sending RF data between two Attiny85 chips, so I thought it might be helpful if I just explain how I did it. There are a number of such projects being described on the internet, but yet, it didn’t prove to be such a straightforward project, which i found to be mostly due to not using the right libraries and cores.

Attiny85 – 0.82 euro/10
10k resistor
433 MHz transmittermodule – 1 euro per set
mini breadboard – 58 cts/piece

10k resistor
433 MHz Receiver module
mini breadboard
Optional: 2 wire LCD

There are two main libraries used to send and receive data on an Arduino platform: VirtualWire and Manchester code.
As Virtualwire is a bit older, no longer supported, and supposedly can only send characters (though there is a way around that) I decided to use Manchester code.

To make a long story short, it didn’t work. I had the MANCHESTER.h and MANCHESTER.cpp file and ran into a lot of trouble, until I discovered that was the wrong/old library, you need the Manchester.h and Manchester.cpp file from here. When I used that I got my transmitter to work, I could send data to an Arduino, that was already a big relief.

However……. whatever I did, I did not get my receiver to work. In testing something on an Attiny it is very frustrating to just stare at an LED that is supposed to light, but doesnt, without knowing what and why and how.
So i decided to add an LCD to the Attiny, so at least I could see what was happening..
However, the LCD on my attiny gave me other problems… and when I solved those, that proved to be the solution for my receive problem as well: I was using the wrong core. I was using the ‘tiny core’ rather than the ‘attiny core’
The latter is the one from Highlowtech.
NOTE: it is generally accepted that the ‘tiny core‘ works with the Manchester code and the attiny core does not, so it is possible that I mixed up the two. However, I had a line added to the Attiny core that I forgot about that will make it work with the Manchester code. Open up  the “variants/tiny8/pins_arduino.h” file and add the line”#define __AVR_Attinyx5__”


The build of the transmitter is easy:
Plug the attiny chip into your breadboard,
Connect a 433 MHz Transmitter module with its data in to pin PB0 (that is pin 5 on the chip).
Connect Vcc and Ground of the transmitter module to Vcc (pin 8) and ground (pin 4) of the Attiny
Insert a 10 k resistor between pin 1 (Reset) and pin 8 (Vcc)
Connect Vcc and ground to 5 Volt
Take a 17 cm stiff wire and attach that to the antenna hole of the transmitter.
use the following program:

#include <Manchester.h>
  Manchester Transmitter example
  In this example transmitter will send one 16 bit number
  per transmission.
  Try different speeds using these constants, your maximum
  possible speed will depend on various factors like transmitter 
  type, distance, microcontroller speed, ...
  MAN_300 0
  MAN_600 1
  MAN_1200 2
  MAN_2400 3
  MAN_4800 4
  MAN_9600 5
  MAN_19200 6
  MAN_38400 7
  #define TX_PIN 0  //pin where your transmitter is connected
  uint16_t transmit_data = 2761;
  void setup() {
  man.setupTransmit(TX_PIN, MAN_1200);
void loop() {

Just a word on the 2716 that I am sending. The program is not mine, I found it as such and since it worked and I was very happy to see the ‘2716’ appear in my Arduino after days of fruitless trying, I decided to leave it there as a tribute. (it might have found it here)

Building the receiver is easy:
receive-manchester-breadboardPut the programmed attiny chip in your breadboard.
Connect a 10 k resistor between pin 1 and pin 8
Put your 433 MHz Receiver module in the breadboard
Connect the datapin (usually either one of the two middle pins) to pin PB1 (physical pin6) on the attiny.
Connect the Vcc and Ground of the transmitter module to Vcc (pin 8) and Ground (pin4) of the Attiny
Connect the LCD interface to pin PB0 (pin 5) (Clock) and pin PB2 (pin 7) (Data/Enable)
Connect Vcc and ground of the LCD to Vcc and Ground.
Attach a 17 cm (1/4 lambda for 433 MHz) to the Receiver module.
Use the following program in your chip:

#include <Manchester.h>
#include <LiquidCrystal_SR.h>
LiquidCrystal_SR lcd(0,2,TWO_WIRE);
  Manchester Receiver for Attiny
  In this example receiver will receive one 16 bit number per
  transmittion to switch a relay on or off. 
  try different speeds using these constants, your maximum possible
  speed will depend on various factors like transmitter type, 
  distance,  microcontroller speed, ...

  MAN_300 0
  MAN_600 1
  MAN_1200 2
  MAN_2400 3
  MAN_4800 4
  MAN_9600 5
  MAN_19200 6
  MAN_38400 7
#define RX_PIN 1 //= pin 6
uint8_t moo = 1;
void setup()
  man.setupReceive(RX_PIN, MAN_1200);
void loop() {
  if (man.receiveComplete()) {
    uint16_t m = man.getMessage();
    man.beginReceive(); //start listening for next message right
                        //after you retrieve the message
   moo = ++moo % 2;

The LCD is ofcourse optional. You can use an LED that gets the variable ‘moo’ send to its pin and thus will flash on complete receival of the signal, but I just wanted to make sure that what I got was what I sent

lcd-manchesterThe results are good, no garbage is being received, but the reach is about 4-5 meters, with the antennas. The antenna on the receiver only makes a small difference. The one on the Transmitter makes a big difference.
Still, this is surprising as the transmitter module is capable of switching remote switches at greater distances even on different floors.

With regard to the length of the Antennas:

as f * λ= c (frequency * wavelength = lightspeed)
λ= 299,792,458 /433,920,000
The wavelength is 0.690893386 meters.
Antenna would be λ/4= 0.172723346 meters (17.3 cm)
That is about 6.80013 inches.
If you would be using 315 MHz modules, the antenna would be: 0.238 m or 23.8 cm

You can also use the wavelength calculator.
Supposedly the transmitter module can take 12 Volts and still be steered by a 5 Volt microcontroller pin and will have a further reach then. Increasing the voltage on the receiver of course makes no difference

Once you have established The link between two attiny’s, linking one of them with an arduino should not be a problem. I use mine to send data to an Arduino ( e,g. temperature, or the status of a tripwire), or to receive data from an Arduino to steer a servo or an RGB LED.

If you want to trigger a relay, you would do it like this:

void loop() {
  if (man.receiveComplete()) {
    uint16_t m = man.getMessage();
    man.beginReceive(); //start listening for next message 
                        //right after you retrieve the message
    moo = ++moo % 2;
    if (m==2761){digitalWrite(Relay,HIGH);}
    if (m==0000){digitalWrite(Relay,LOW);}

Ofcourse you need to define the Relay pin in the ‘setup’

24 thoughts on “Sending wireless data from one Attiny85 to another

  1. Hey,

    thanks for the post. I was very happy when I found it because I am also struggling with 433RF between two ATTinys. The only difference is that I am at the moment trying to establish the communication with two 84. I say trying because I was not successful yet.

    So i decided to add an LCD to the Attiny, so at least I could see what was happening..
    However, the LCD on my attiny gave me other problems… and when I solved those, that proved to be the solution for my receive problem as well: I was using the wrong core. I was using the ‘tiny core’ rather than the ‘attiny core’
    The latter is the one from Highlowtech.

    This is basically the point at which I am stuck at the moment. I can send data with the Manchester lib: UNO -> UNO and 84 -> UNO. But when I try to receive with the 84, it won’t work. Inspired by your post, I used a variety of different libraries and cores. I use now, as you suggested, this Manchester lib and the cores by High-Low Tech. For this setup to compile, I had to complement the Manchester.cpp:

    “#if defined( __AVR_ATtinyX5__ )” —> “#if defined( __AVR_ATtinyX5__ ) || #if defined( __AVR_ATtiny85__ ) ”


    “#if defined( __AVR_ATtinyX4__ )” —> “#if defined( __AVR_ATtinyX5__ ) || #if defined( __AVR_ATtiny84__ ) ”

    However, I can still only send with the ATTiny but not receive. Therefore, I was wondering if you have any hunch why you couldn’t receive with your ATTiny in the beginning and why it worked with the setup you are using currently?


    1. Sorry to hear about your problems. Actually, I am not sure why it happened. I am not sure anymore what i did to ‘solve’ my lcd problem, but I think that was installing the proper core (my various cores had been screwed up a bit).
      It may well have to do with timing.
      I was puzzled abit by your complement to the manchester.cpp as I didnt have to do that at all, and you seem to define AVR_ATtinyX5 twice.
      Are you sure that second line shouldnt be:
      “#if defined( __AVR_ATtinyX4__ )” —> “#if defined( __AVR_ATtinyX4__ ) || #if defined( __AVR_ATtiny84__ ) ”

      Just guessing as I am not sure why the addition was necessary.

      Which core did you end up using?

      1. Hey,
        you are absolutely right, the line actually should be

        #if defined( __AVR_ATtinyX4__ ) || defined( __AVR_ATtiny84__ )

        I was a bit sloppy when I wrote the comment, in my code it is correct though.

        To be honest, I am not 100% sure anymore why the modification was necessary. I think it was because for me __AVR_ATtinyX4__ was not defined but __AVR_ATtiny84__ was instead. Therefore, I got the error

        Manchester library doesnt support your microcontroller

        at compilation. So I added the OR to the if to check for both definitions.

        At the moment I am using the High-Low Tech core for Arduino 1.6.

      2. I already figured you added the 84 because somehow the X4 didnt recognize the 84 as such.. although it should🙂
        I havent been able to get the manchetsre working yet with the 1.6 I think.. all kinds of errors, probably coz teh new file structure for the 1.6.x version doesnt see the patch for the manchester code

    2. let me add a little. Somewhere along the lines I picked up a patch for the Attiny45-85 for the manchestercode. It is not part of the Manchester library, i got it seperate, It is directly in the hardware folder.

      It contains the following files:

      Perhaps the 84 also needs some kind of patching.
      However, a guy called Tom Carpenter supposedly added the correct registers for the 84 and it should work. Link I found was this:;topic=115787.0;attach=22650.
      It is discussed here:

      Also there is another manchester library, called ManchesterRF, but i dont have much experience with that one

      1. Thanks for both of your replies. I will have a look the the patch you are mentioning.

        I also tried using the ManchesterRF but weren’t successful either. It is good to know that you didn’t try it. I guess I will toy around a bit more with it because it is newer than the one form mchr2k, I believe.

        Thanks again for your help.

        Cheers Max

  2. Hi greate tutorial(s)🙂

    I would also like to take the Manchester code and have your simple example used with an ATtiny45 .

    uint16_t transmit_data = 6761; // 0001 1010 0110 1001
    void loop()

    I want to receive with an Raspi, so I can’t take the same libary. Now I have to find out, what parts are send.
    when I have a look on IO: 0, I get
    when I encode with the Raspi
    by IEEE: 000000000000000100001011110001010
    by Thomas: 111111111111111011110100001110101

    I cant’ find the value: 6761.
    Can You help me to split it?
    greetings from Bavaria

    1. 6761 is indeed 0001101001101001 and that doesnt seem to be in there. I am not very proficient on the Raspi.
      just a question, the datastream that you measuere is that measured onthe sender or on the receiver?
      Manchester code (and other protocols as well) do not just send the bits/bytes identical to how they are fed. AsI am not sure what it is you are in fact measuring, maybe you see a problem that doesnt exist.
      idealy your manchester decoder should translate the entire pulsetrain back to ‘6761’
      So those 3 pulsetrains you are measuring, what are they exactly? I am pretty sure that is not coming out of your decoded receive signal

      1. Thanks for Your reply,
        as I wrote , I use the simple example , except that I have changed the fixed value to 6761.

        #define TX_PIN 0 //pin where your transmitter is connected

        uint16_t transmit_data = 6761;
        byte ledPin = 3;

        void setup() {
        man.setupTransmit(TX_PIN, MAN_1200);

        void loop() {

        The following I get on Pin5 / PB0 directly – ATTiny45 when it sends:
        (I hope wordpress shows the image)

        I can verify the output, I get with the Raspi
        when connect directly (input Raspi – output ATTiny) without 433MHz-Transmitter/ Receiver, with the oscilloscope-img
        I did not see if it sends a start bit and stop bit and maybe a parity byte with

      2. I was just done writing a long explanation but something happened and I lost it all.
        Anyway, my point was that the manchester protocol doesnt have start or stopbits as far as I know.
        also the code that you got on the raspi is as i presume the coded manchester signal (= the encoded 6761).
        There are two coding protocols so it is difficult to say how the ‘translate’ the RASPI received code and the binary 6761 number. if 01 is a ‘0’ and 10 is a ‘1’ then the signal could be:

        0 10 10 10 10 10 10 10 10 10 10 10 10 10 10 01 10 10 10 10 01 10 01 01 01 01 10 10 10 01 10 01 10 1
        ? 11111111111111011110100001110101? which is too big, but it could also be:
        ? 00000000000000100001011110001010? Neither is 1101001101001.
        but i still do not understand what exactly your problem is, as the translation is what your receiving manchester decoder should do

  3. Hi,
    I’m a newbee in µC.
    So I tried first to compile the code with Atmel Studio and Avrdude whithout succsess (import libaries failed). After install Arduino 1.6.7 (I don’t have an Ardoino board, so it’s not obvious to me to install the IDE), it works immediately with your well comprehensible way description.
    Just export and burn with
    avrdude -p t45 -P /dev/ttyACM0 -c stk500v2 -U flash:w:sender_fix.ino.tiny8.hex:i
    (I have an USB-programer)
    Perhabs You write a hint for other newbees to use directly Ardoino IDE with its libaries😉

    Do You allow attachments?
    if desired , I can attach a C – Code for the Raspi. Just a part to receive and covert the Machesterbits.

    1. Ralphi, by coincidence I saw some of your comments were classified as spam so apologies if I didnt see this one earlier.
      I allow attachments but I am not sure if WordPress does, but I will mail you.
      I actually never realized someone would want to do this without an Arduino IDE. I will see if it needs clarification. Thanks

  4. Hi all,
    I’m shocked. The whole 433 MHz for sensoring is outdated . I should read the signs when RF12b is no longer available etc.
    There are now ‘all in ones’ modules nrf24L01+ less then 1Eur (ebay) with more radio coverage, autoresponse, 32ByteData, CRC and so on.
    Works with Attiny84, Raspi and of course Arduino together (same time).
    After the normal starterproblems, it worked for me. I posted the sketch(es) here (in German)

    1. Ralphi, thank you for your input. I hope you have recovered from your shock.. The nrf24L01 modules exist for a longer time already, but regardless of wether they have all the qualities you sum up, they dont replace the 433 MHz.
      For one thing… for 433 you need ONE pin (besides Vcc and ground). For nrf24l01 you need 5-6 pins. Also you need an extra 3V3 voltage. The 3v3 of the UNO is insufficient.
      Anyway, try hooking it up to an attiny85 and you wont have much pins or memory left to do anything else🙂

      1. Of course, you are right🙂. The most (all) sensors you can buy, still works with 433 or 868MHz.
        And the frequency with 2.4GHz (Wifi) is just at least as much traffic as 433MHz (Wireless-Phones)/686MHz (TX29-IT Tempsensors).

        With the other things, I’m not able to follow you:
        Remember, there is the ATTiny84 just a few Cent and feet more🙂. The same VCC 1.8V and memory.
        My new sketch with sonar-Sensor(HC-SR04), 1wire Temp (DS18B20) is just 24% memory.
        I need it as level sensor for my water tank.
        The next for me is a natural gas meter. For this I’ll want to send the Unix-timestamp to assigned to the values.

        Now I have so many ways to change settings in ATTiny subsequently on the radio, that I have to make a plan to me😉

      2. seems you have a lot of projects ahead. great🙂
        I am not saying the nrf24l01 cant connected to an attiny84, just that u need more pins so that there are also a bunch of chips you cant connect it to.
        I have my house running on 433MHz and sure i could have done it with the nrf24l01 but for me just easier to do with 433MHz. I guess it is a matter of taste🙂
        Good luck with your projects. Sounds very interesting

  5. Thanks for all the information you have provided. It has been a great help. Wonder if you could assist with an issue I cannot figure out on my own. I am successful in getting the ATtiny85 and the Arduino Uno to send data from the DS1820 and transmit with the 433Mhz transmitter.
    I have discovered by using an SDR receiver and confirming with an Oscilloscope that when using the Arduino Uno the 433Mhz transmitter will transmit then go off. Carrier comes on sends data and then go off. Just the way I expected it to function. When using the ATtiny85 it also sends the data but always stay transmitting. The carrier is always on. This is not good for battery operation. What is different about the Atmega 168/328 and the ATtiny85? that would cause this to occur when using the Attiny85. I am using the same code for the Uno and the ATtiny85.

    1. I am a bit surprised by that as I do not know of any difference between the two chips in regard to that. That makes me think that somehow the attiny85 must still be sending some data even though it might be garble. As you are using the same code (and library I presume), my first thoughts go to your PSU. I am not sure if you are feeding your attiny85 from battery already or that you were still testing it with a psu, coz then perhaps glictches on yr powerline may cause the send pin to fluctuate. If you are still using a psu, I’d suggest a decent capacitor or try it with a battery. a 100nF directly over the chip is also a good idea

  6. Hello, thanks for the helpful post. I’ve tried here and I can’t get the attiny to receive… I was able to send some readings from an attiny to a nano with a very unstable connection (stopping very frequently) but not from attiny to attiny. Can you help me? Do you know what might be the issue? And also, I couldn’t find “variants/tiny8/arduino…” so to do the modifications.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s