Auto gain on RF receiver problem

I have a pair of 434MHZ from Sparkfun. I am using the virtualwire library and am using them to send temperature data and the number of bubbles going through a photo interrupter attached to my homebrew beer fermenting away.

When I was sending just temperature data fairly often, I got great range. Now that I am sending information once every minute or so, my range seems to have decreased. I think I am having problems with the auto gain I have read about on these receiver ICs. Any ideas how to correct? I could add an additional loop to my while statement and transmit more often than once a minute, but how often should I transmit? Thanks!

#include <VirtualWire.h>

int ledPin = 13;  // LED connected to digital pin 13
int photoPin = 2;               //
int bubblePin = 12;
int val = 0;
int tempPin = 5;  // lm34 analog pin
int tempF=0;      // temperature 
int transPin = 9; // transmit pin

unsigned long start;
unsigned long totalCount = 0;
unsigned long currentCount = 0;

void setup()
    pinMode(ledPin, OUTPUT);      // sets the digital pin as output
    pinMode(photoPin, INPUT);
    pinMode(bubblePin, OUTPUT);
    Serial.begin(9600);        // Debugging only

    // Initialize virtual wire stuff
    vw_set_ptt_inverted(true); // Required for DR3100
    vw_setup(2000);       // Bits per sec

void loop()
  start = millis(); // take the start time
  //Serial.print("Millis: ");
  currentCount = 0; // reset couter
  // do the following loop for 60000ms = 1min
  while (millis()-start < 60000)
    val = digitalRead(photoPin);
    if (val==LOW)
      digitalWrite(bubblePin, LOW);
        currentCount ++;
      digitalWrite(bubblePin, HIGH);
  // 1 minute over. print conts
  currentCount = currentCount/10000; //scale down to bubbles
  totalCount = totalCount + currentCount;
  //Serial.print("Current count:  ");
  //Serial.print("Total count:  ");
  tempF= ( 5.0 * analogRead(tempPin) * 100.0)/ 1024.0;
  //Serial.print("Temperature in Farenheit: ");

 char char_temp_f[4];
 char char_bpm[10];  //expect at most 7 characters plus 'bpm' so 10 should be big enough
 char char_total[15];  //expect at most 10 char plus 'total' so 15 should be big enough

strcat(char_temp_f, "F");
strcat(char_bpm, " bpm");
strcat(char_total, " total");

    digitalWrite(ledPin, true); // Flash a light to show transmitting
    vw_send((uint8_t *)char_temp_f, strlen(char_temp_f));
    vw_wait_tx(); // Wait until the whole message is gone
    digitalWrite(ledPin, false);
    digitalWrite(ledPin, true); // Flash a light to show transmitting
    vw_send((uint8_t *)char_bpm, strlen(char_bpm));
    vw_wait_tx(); // Wait until the whole message is gone
    digitalWrite(ledPin, false);
    digitalWrite(ledPin, true); // Flash a light to show transmitting
    vw_send((uint8_t *)char_total, strlen(char_total));
    vw_wait_tx(); // Wait until the whole message is gone
    digitalWrite(ledPin, false);

Firstly, I'm not sure why you have the following line

vw_set_ptt_inverted(true); // Required for DR3100

You don't need this because your transmitter does not have a "push to talk" pin.

Now, some general comments. I have experience with 315mhz transmitters and will assume that 434mhz is very similar.

  1. Do not expect that transmitted data is in fact received. Ideally, you would be operating in full duplex mode where both units have tx/rx units. Now when data is transmitted by unit A, it begins a timer. When unit B gets the message, it sends an acknowledgment message back to unit A. Unit A may now stop the timer. In the event that the timer reaches a preset value, A will attempt to resend.

Since you are operating in half duplex, redundancy is your friend. Consider sending a message several times (My field tests show that 8 is a good number). You are now banking on the fact that at least one of these messages will be received, but this is OK.

Make sure you implement logic in your receiving unit such that it doesn't do silly things because it's getting the same message. This is easily handled by implementing a previous_msg variable. Now only do an action if previous_msg != currently_rcved_msg

  1. Consider decreasing your baud rate. My error rate decreased significantly when I used 1000 bps instead of 2000bps on a 2400bps spec unit.