My ATTiny85 is connected to a 433 transmitter and an analog sound sensor. The 433 is working fine (using VirtualWire) but when I send the reading from the sensor all I receive is a 1.

What I would like to receive is the value between 0 and 1024 like when I print the sensor to serial. I cannot check it because the ATTiny85 had no serial out.

My code is a combination of snippets I found online, I am not happy with all the magic to format the data that needs sending. I would also like to send "Reading: 637" in stead of just the number but I find the concatenation Google results extremely complicated.

Should this code send the sensor data like 672? Could there maybe be some Fuse setting blocking the AnalogRead?

#include <VirtualWire.h>

const int transmit_pin = PB0;
const int sensor_pin = PB4;
int sensor_data;
char sensor_msg[4];

void setup()

int count = 1;

void loop()

  sensor_data = analogRead(sensor_pin);
  vw_send((uint8_t *)sensor_msg, strlen(sensor_msg));
  vw_wait_tx(); // Wait until the whole message is gone
  count = count + 1;


Receiver Code as requested
This is a Pro Mini (clone) and it has an LCD attached so I can see what is going on.

#include <VirtualWire.h>
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27,16,2);

const int receive_pin = 11;
char* testje;
void setup()
    Serial.begin(9600); // Debugging only

    // Initialise the IO and ISR
    vw_setup(2000);  // Bits per sec

    vw_rx_start();       // Start the receiver PLL running


void loop()
  char buf[VW_MAX_MESSAGE_LEN];
  uint8_t buflen = VW_MAX_MESSAGE_LEN;

  if (vw_get_message(buf, &buflen)) {
    int i;
    // Message with a good checksum received, print it.
    Serial.print("Got: ");

    for (i = 0; i < buflen; i++) {
  • 1
    sensor_msg should be 5 bytes long not 4, but other than that it looks fine. What is your reception code? Maybe the bug lies there? – Majenko Mar 21 '17 at 18:01
  • Actually, one thing i just noticed. The third argument of itoa should be 10 not 4. That argument is the base you want to represent the value in. – Majenko Mar 21 '17 at 18:39
  • thanks, I've changed it. also tried HEX but 1 stays 1 obviously :D I will find an extra Pro Mini to test the sending of the data from a Pro Mini, will update my question afterwards – Thijs Mar 21 '17 at 19:31
  • 1
    I would double check the pin numbers for the attiny. They look like port bit numbers but that might just work by chance. – Mikael Patel Mar 21 '17 at 19:38
  • Ok from a Pro Mini it all works. So the code is ok and the receiver is ok. About the pins; I use PB0 to send data, so PB4 must be PB4 right? It's not possible to name it A2 but it 'should be' that pin. I will make a blinking LED on PB3 to be sure :) maybe I can have it blink analogeRead/100 or something.. – Thijs Mar 21 '17 at 19:51

I would double check the pin numbers for the attiny. They look like port bit numbers but that might just work by chance.

const int transmit_pin = PB0;
const int sensor_pin = PB4;

A quick double check with the attiny/pins_arduino.h give:

//                 +-\/-+
// Ain0 (D5) PB5  1|    |8  Vcc
// Ain3 (D3) PB3  2|    |7  PB2 (D2) Ain1
// Ain2 (D4) PB4  3|    |6  PB1 (D1) pwm1
//           GND  4|    |5  PB0 (D0) pwm0
//                 +----+

As you have found they should be defined as:

const int transmit_pin = 0; // Physical pin 5
const int sensor_pin = 4;   // and pin 3

This type of issue could be avoided by using strong data typing and object oriented design. Please see for instance Cosa ATtinyX5.hh and GPIO.hh.


Here is something that does basically the same as the sender. Cosa supports attiny and Arduino boards "out-of-the-box".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.