Attiny85 with 433 mhz rf, worked fine nano to nano, not attiny85 to nano

Projects Programming
1

So I am creating a signal message using rf module 433mhz. I know you guys might have seen similar post.
I have read many posts but cant make things working.

receiver code on arduino nano :

#include <RH_ASK.h>
#ifdef RH_HAVE_HARDWARE_SPI
#include <SPI.h> // Not actually used but needed to compile
#endif
// driver(speed not to mess with that , receive pin , transmit pin , push to talk )
RH_ASK driver(2000, 2,4,5);
// RH_ASK driver(2000, 4, 5, 0); // ESP8266 or ESP32: do not use pin 11 or 2
// RH_ASK driver(2000, 3, 4, 0); // ATTiny, RX on D3 (pin 2 on attiny85) TX on D4 (pin 3 on attiny85), 
// RH_ASK driver(2000, PD14, PD13, 0); STM32F4 Discovery: see tx and rx on Orange and Red LEDS

void setup()
{
#ifdef RH_HAVE_SERIAL
    Serial.begin(9600);	  // Debugging only
#endif
    if (!driver.init())
#ifdef RH_HAVE_SERIAL
         Serial.println("init failed");
#else
	;
#endif
}

void loop()
{
    uint8_t buf[RH_ASK_MAX_MESSAGE_LEN];
    uint8_t buflen = sizeof(buf);

    if (driver.recv(buf, &buflen)) // Non-blocking
    {
//	int i;

	// Message with a good checksum received, dump it.
//	driver.printBuffer("Got:", buf, buflen);

    String rcv;

    for (int i =0; i < buflen; i++) {
        rcv += (char)buf[i];
    }
    Serial.println(rcv);
    } else {
    Serial.println("else");   
    Serial.println((char)buf[0],buflen);   
    delay(1000);   
    }
}

transmitter code :

#include <RH_ASK.h>
#ifdef RH_HAVE_HARDWARE_SPI
#include <SPI.h> // Not actually used but needed to compile
#endif
// driver(speed not to mess with that , receive pin , transmit pin , push to talk )
RH_ASK driver(2000, 5,3,0); // ESP8266 or ESP32: do not use pin 11 or 2
// RH_ASK driver(2000, 3, 4, 0); // ATTiny, RX on D3 (pin 2 on attiny85) TX on D4 (pin 3 on attiny85), 
// RH_ASK driver(2000, PD14, PD13, 0); STM32F4 Discovery: see tx and rx on Orange and Red LEDS

void setup()
{
  
#ifdef RH_HAVE_SERIAL
    Serial.begin(9600);    // Debugging only
#endif
    if (!driver.init())
#ifdef RH_HAVE_SERIAL
         Serial.println("init failed");
#else
  ;
#endif
//pinMode(4, OUTPUT);
}

void loop()
{
    const char *msg = "higgh";
    driver.send((uint8_t *)msg, strlen(msg));
    driver.waitPacketSent();
    delay(1000);
//    digitalWrite(4, HIGH);   // turn the LED on (HIGH is the voltage level)
//    delay(1000);                       // wait for a second
//    digitalWrite(4, LOW); 
}

Its working if i use another arduino nano as transmitter but not with attiny85.
I am able to make blink successfully run with attiny85 . so adding code to attiny85 is fine i guess.

Also i am using 3 , which is pin 2 for attiny85

I even changed 5v to attiny85 to 3 v ish still didnt work

2

I have been using ATTiny85s with 433MHz OOK/ASK radios for a few years. There are some problems with RH_ASK on ATTiny85. Bit timing is pretty sensitive and the ATTiny85 clock is possibly not accurate enough. The radios vary a lot in startup time between when a high signal is sent and the RF transmitter actually starts. This can be 10us or up to 100us and this affects the receivability of the signal. I had trouble with the RH_ASK library not actually fitting into the ATTiny85 with my app.

Checking the bit timing and coming up with values to use in the code below basically requires an oscilloscope. It does not have to actually have 400MHz bandwidth to see the point that the transmitter starts though. This is evident on a 50MHz o'scope pretty readily.

One thing I did was write a short program to scan a range of bit timing options and transmit that info at one minute intervals. I set up a receiver to log all the messages received and left that running overnight. The range of best timing values was then found in the log information by looking for values that got through. Here's a writeup: 433MHz OOK radio signalling « Projects

I have been using this more compact implementation in send-only sensor apps to good effect:

#define RESEND_COUNT 3
#define RESEND_DELAY 150

#define RADIO_BAUD_ADJUST -15  // experimentally
#define RADIO_DELAY       100  // experimentally -- 100 uSec delay before transmitter starts

   :

/* we are resend the same message a few times to
 * help with reliability.
 */
vw_set_microinterval(RADIO_BAUD_ADJUST, RADIO_DELAY);
for (i = 0; i < RESEND_COUNT; i++) {
    if (i != 0) delay(RESEND_DELAY);
    vw_send_buf(data, size);
}

  :


/* Miniature VirualWire/RadioHead RH_ASK implementation adapted for running
 * on an ATTiny85.
 */
#define TX_BAUDRATE       2000
#define TX_MICROINTERVAL  (1000000UL/TX_BAUDRATE)
#define TX_MAXLEN         12

uint32_t vw_microinterval_main = TX_MICROINTERVAL;
uint32_t vw_microinterval_advance = 0UL;

uint8_t vw_lastbit = 0;

inline void vw_txbit(const bool onOff) { digitalWrite(RADIO_TX, (vw_lastbit = onOff) ? HIGH : LOW); }

/* These should be PROGMEM or else just generated.  This way they waste too much RAM.
 */
const uint8_t vw_header[8] = { 0x2A, 0x2A, 0x2A, 0x2A, 0x2A, 0x2A, 0x38, 0x2C };
const uint8_t vw_conv4to6[16] = { 0x0D, 0x0E, 0x13, 0x15, 0x16, 0x19, 0x1A, 0x1C,
                               0x23, 0x25, 0x26, 0x29, 0x2A, 0x2C, 0x32, 0x34 };

/* Here we transmit the sequence of bits.  Generally, we can simply set the transmitter on or off
 * then wait for the fundamental but timing and go on to the next bit.  But the radios often have
 * a significant startup time that affects the timing of an OFF-->ON transition.  In order to 
 * compensate for this timing glitch, we have to shift the timing of these transitions and therefore
 * have to know the type of transition occurring.
 * 
 * In order to accommodate the timing shift, the timing delay is placed BEFORE the bit transition.
 * This is a little unnatural.
 * 
 */
void vw_rawSend(const uint8_t * p, uint8_t len)
{
  while (len--) {
    const uint8_t val = *p++;
    for (uint8_t mask = 1; mask != 0x40; mask <<= 1) {

      /* If the transition is OFF-->ON, then we do weird timing.
       */
      if (!vw_lastbit && (val & mask)) {
        delayMicroseconds(vw_microinterval_main);
        vw_txbit(val & mask);
        delayMicroseconds(vw_microinterval_advance);

      /* Otherwise, this is the normal case.
       */
      } else {
        delayMicroseconds(vw_microinterval_main);
        delayMicroseconds(vw_microinterval_advance);
        vw_txbit(val & mask);
      }
    }
  }
}

/* Allow for ajustment of the delay timing in uS.  This is
 * needed to compensate for timing inaccuracies.  The main 
 * delta alters the overall bit timing whichis generally 
 * affected by the clock speed.  "on_delay" is a value that 
 * specifically compensates for the turn on delay of the 
 * radio transmitter.  This value has to  be measured with 
 * a specific device and typical values might be in the 
 * 5..65 uS range.  Radios with small delays don't necessarily
 * need compensation, but ones with long delays will affect
 * receive accuracy unless we alter the software timing to
 * compensate.
 */
uint32_t vw_set_microinterval(int delta, int on_delay)
{
   vw_microinterval_main = TX_MICROINTERVAL;
   vw_microinterval_main += (long) delta;
   vw_microinterval_advance = on_delay;
   vw_microinterval_main -= on_delay;
   return(vw_microinterval_main + vw_microinterval_advance);
}

/* Send a buffer using the virtual wire OOK protocol
 */
void vw_send_buf(const uint8_t * buf, const uint8_t len)
{
  /*  First create the payload byte stream by converting to 6:4 format
   *  compute the CRC and append that.
   */
  static uint8_t payload[(TX_MAXLEN+3)*2];
  uint8_t * p = payload;
  uint16_t crc = 0xFFFF;
  uint8_t v = len + 3;
  crc = _crc_ccitt_update(crc, v);
  *p++ = vw_conv4to6[v >> 4];
  *p++ = vw_conv4to6[v & 0x0F];
  for (uint8_t l = len; l--;) {
    v = *buf++;
    crc = _crc_ccitt_update(crc, v);
    *p++ = vw_conv4to6[v >> 4];
    *p++ = vw_conv4to6[v & 0x0F];
  }
  crc = ~crc;
  v = (uint8_t)crc;
  *p++ = vw_conv4to6[v >> 4];
  *p++ = vw_conv4to6[v & 0x0F];
  v = (uint8_t)(crc >> 8);
  *p++ = vw_conv4to6[v >> 4];
  *p++ = vw_conv4to6[v & 0x0F];

  /*  Now transmit the header and the encoded payload 
   *  turn off the transmitter.  Note that the timing delay
   *  is BEFORE the bit being sent, so an advance timing delay
   *  is appended before the final radio OFF.
   */
  vw_rawSend(vw_header, sizeof(vw_header));
  vw_rawSend(payload, (len + 3)*2);
  delayMicroseconds(vw_microinterval_main);
  delayMicroseconds(vw_microinterval_advance);
  vw_txbit(0);
}
3

devshreyan:
So I am creating a signal message using rf module 433mhz. I know you guys might have seen similar post.
I have read many posts but cant make things working.

receiver code on arduino nano :

// driver(speed not to mess with that , receive pin , transmit pin , push to talk )

RH_ASK driver(2000, 2,4,5);
// RH_ASK driver(2000, 4, 5, 0); // ESP8266 or ESP32: do not use pin 11 or 2
// RH_ASK driver(2000, 3, 4, 0); // ATTiny, RX on D3 (pin 2 on attiny85) TX on D4 (pin 3 on attiny85),
// RH_ASK driver(2000, PD14, PD13, 0); STM32F4 Discovery: see tx and rx on Orange and Red LEDS




transmitter code :

// driver(speed not to mess with that , receive pin , transmit pin , push to talk )
// RH_ASK driver(2000, 2,4,5);
RH_ASK driver(2000, 5,3,0); // ESP8266 or ESP32: do not use pin 11 or 2
// RH_ASK driver(2000, 3, 4, 0); // ATTiny, RX on D3 (pin 2 on attiny85) TX on D4 (pin 3 on attiny85),
// RH_ASK driver(2000, PD14, PD13, 0); STM32F4 Discovery: see tx and rx on Orange and Red LEDS

Is your transmitter code on the ATtiny? If so, why use the ESP8266/ESP32 settings and not the ATtiny settings?

4

johnwasser:
Is your transmitter code on the ATtiny? If so, why use the ESP8266/ESP32 settings and not the ATtiny settings?

The only "settings" in that line are the pin numbers -- effectively PB3 and PB5 (physical pins 1 and 2) on the ATTiny85. Those would be reasonable. I'm not sure the O/P is disabling the reset pin, or if there is a conflict specifying PB5 without disabling reset. That is possibly something to look into. The O/P says she/he's using pin 3 and its not clear if this means PB3 (physical pin 2) or PB4 (physical pin 3). The code says PB3, physical pin 2, but it would not be the first time someone was confused by the Arduino "pin number" BS.

5

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.