RFM12B and ATTiny85

Added by jpadie about 7 years ago


has anyone had any luck getting the rf12 lib from jeelabs to work ‘out of the box’ with an attiny85? I can’t work out whether it’s my ineptitude that i’m getting nothing out of the test rigs or if I need to add a definition section to the top of the library to cater for attiny85’s.


ps. i’m sure all the boards i’ve knocked up are working as they all behave normally when I hook them up to an arduino nano and use the ping pong sketch (although I had to edit the sketch to add a (char) cast in the Serial.print line otherwise I just get numbers - is that anticipated?).

pps. I’m (relatively) sure that the attiny85 works ok and is being flashed ok. I can’t be definite with the ping pong sketch but it flashes nicely with a simple blink sketch (and an led…)

Replies (32)

RE: RFM12B and ATTiny85 - Added by jpadie about 7 years ago

using Martin’s code I get the following in nRFMon’s scan screen

I will try later with the jeelib code as a comparison.

RE: RFM12B and ATTiny85 - Added by jpadie about 7 years ago

and here is the trace with the jeelabs code.

i guess that means that both sets of code are transmitting ‘something’. Martin’s code showed up correctly in nRFMon with the payload being correctly registered too.

the jee lib code was lightly changed as shown

#define SS_DDR                DDRB
#define SS_PORT               PORTB
#define SS_BIT                1

#define RFM_IRQ         PIN_B4 //PCINT3
#define SPI_SS          PIN_B3
#define SPI_MISO        PIN_B0
#define SPI_MOSI        PIN_B1 //PCINT0
#define SPI_SCK         PIN_B2

within an appropriate definition block.

but nRFMon did not show any decipherable traffic. The traffic it did capture is shown in the second screen shot.

the sketch used to send the traffic was as follows

#define __ATTINY85__
#define __AVR_ATtiny85__


char payload[] = "0 1 2 3 4 5 4 3 2 1 0";

void setup () {
  rf12_initialize(1, RF12_868MHZ, 33);

void loop () {
  rf12_sendNow(0, payload, sizeof payload);

RE: RFM12B and ATTiny85 - Added by dzach about 7 years ago

That’s good news jpadie! The ATtiny85 is indeed transmitting!
The receiver front end is rather overloaded, due to the close distance between the nodes, that’s why the waterfall display appears like the Niagara falls :-)

Now the rest of the link parameters have to be matched. What you see in the little console in nRfMon is garbage. To display only good packets press the Quiet button. That will allow only good packets (CRC==0) to get through. If packets are not decoded there will be nothing in the console.

In the Jeelib screenshot, the signal peak appears to be normal but on a different frequency than the receiver, which is on the default frequency of 868MHz. To see it better, you can turn off the Spectrum checkbox and turn on Hold max. If you tune the receiver exactly on the frequency of the transmitter you may see packets decoded. A single channel difference may be a show stopper here. The decoded packets will look like this:

▼ g 33 id 1 len 21 crc 0x0000
0 1 2 3 4 5 6 7 8 9 0

In the screenshot taken when running Martin’s code there is something unusual in the display; although the frequency is correct, the center of the trace is 0 and the transmit bandwidth seems excessive. Maybe you need to check the FSK shift that Martin’s code uses.

By the looks of it, I think you may decode the Jeelib packets by just changing the frequency to match the transmitter. But I could be wrong.

RE: RFM12B and ATTiny85 - Added by dzach about 7 years ago

You may also try to reduce the front-end overload by increasing the distance of the transmitter, and/or reduce the LNA gain of the receiver.

RE: RFM12B and ATTiny85 - Added by jpadie about 7 years ago

Thank. I’m limited to a distance of a few metres by having only one laptop with me…

i’ve tried changing the frequency down to match the green dots but at that point i lose all transmission. even the garbage.
i’ve tried hard coding the pin change interrupt routines for the attiny85. which would (I think) look like this

bitClear(GIMSK, INT0); //turn off ext int on int0
bitClear(GIMSK, PCIE); //turn off pin change interrupts
uint16_t r = rf12_xferSlow(cmd);
bitSet(GIMSK, PCIE);  //turn on pin change interrups

ISR(PCINT0_vect) {
            while (!bitRead(PINB, PINB4)) //for using pinb4 as the interrupt


 if ((nodeid & NODE_ID) != 0) {
            bitClear(MCUCR, PUD);           //enable pullups generally
            bitSet(GIMSK, PCIE);             // enable pin change interrupts
            bitSet(SREG, 7); //allow interrupts globally
            bitClear(DDRB, DDB4);      // configure pin as input
            bitSet(PORTB, PORTB4);       // enable pull-up on pin
            bitSet(PCMSK, PCINT4);      // pin-change
} else{
            bitClear(PCMSK, PCINT4);

I’ve tried multiple permutations of the above. all give the same garbage (if they send at all)

i have a feeling that there needs to be more logic in the pin change interrupt routines. i.e. either in the ISR or in rf12_interrupt, to determine the direction of the change and to debounce it. I have tried the pre-configured library pinchangeinterrupt, but get no better results with that as it cannot be triggered on LOW.

i’m close to being stuck now unless anyone has any new ideas ?!

RE: RFM12B and ATTiny85 - Added by dzach about 7 years ago

jpadie I read your other thread,

Have you managed to receive correctly the packets sent by the ATtiny85?

RE: RFM12B and ATTiny85 - Added by jpadie about 7 years ago

Thanks for your interest.
I could not achieve anything better than what I have already posted in the end. I was not able to get pin change interrupts working at all unfortunately; and could not get the jeelib code to work at all without interrupts ( which it uses for each byte sending and receiving ). So have given up and am using Martin’s code with some minor modifications.

Both seemed to transmit but only Martins code was able to send fully formed packets.

I’m still interested in working with attiny85s though and am pursuing the remainder of this project with those. Just have to work out why I’m not seeing really low current draw from the circuit when supposedly it is in power down mode!