Skip to main content

You are here

Solved: Cannot receive blip transmissions

9 posts / 0 new
Last post
Solved: Cannot receive blip transmissions

I am using JeeNode A and JeeNode B with RF12demo.ino on 915MHz and can send and receive full and custom packets between them- no problems.

If I load RF12 radioblip on to node A and do nothing to node B, I cannot receive the expected 1,2,3... on node B. I get no response at all even if I change the receive freq. of node B through all available freqs and even if I set node B group to zero (receive all).

I am a noobie, so any and all help would be appreciated.


Just to check - you changed the initialisation to the "wrong" band?

rf12_initialize(22, RF12_868MHZ, 5);


Thanks, martynj, I did not deliberately set the band to 868 MHz, it is the default. I did change it to 915 with no results. I did try setting the receiver to 400, 800 and 900 MHz consecutively with no results.


Maybe you can post the radioblip sketch as you upload it to node A? (I assume you're still using RF12demo.ino on B)


Thanks for the response. Both nodes are JeeNode V5 on USB 5V power, IDE =1.0

Yes, I am using unmodified RF12demo.ino on node B

I am using unmodified RF12_radioblip on node A as shown below:

#include <JeeLib.h> #include <Ports.h> #include <PortsBMP085.h> #include <PortsLCD.h> #include <PortsSHT11.h> #include <RF12.h> #include <RF12sio.h> /// @dir radioBlip /// Send out a radio packet every minute, consuming as little power as possible. // 2010-08-29 <> #include <JeeLib.h> static long payload; // this must be added since we're using the watchdog for low-power waiting ISR(WDT_vect) { Sleepy::watchdogEvent(); } void setup() { cli(); CLKPR = bit(CLKPCE); #if defined(__AVR_ATtiny84__) CLKPR = 0; // div 1, i.e. speed up to 8 MHz #else CLKPR = 1; // div 2, i.e. slow down to 8 MHz #endif sei(); rf12_initialize(22, RF12_868MHZ, 5); // see rf12_control(0xC040); // set low-battery level to 2.2V i.s.o. 3.1V } void loop() { ++payload; while (!rf12_canSend()) rf12_recvDone(); rf12_sendStart(0, &payload, sizeof payload); // set the sync mode to 2 if the fuses are still the Arduino default // mode 3 (full powerdown) can only be used with 258 CK startup fuses rf12_sendWait(2); rf12_sleep(RF12_SLEEP); Sleepy::loseSomeTime(60000); rf12_sleep(RF12_WAKEUP); }

So Node A is now on 868Mhz, Node B still on 915MHz?

JeeNode A and JeeNode B with RF12demo.ino on 915MHz


I think you should change the RadioBlip sketch initialise part to have it run on 915 MHz: apparently you have 915 MHz devices and while theoretically they can also run on 868 MHz, the range will be drastically reduced (to a couple of cm if you're unlucky), so that will explain why you weren't receiving anything, although you were cycling B through 433, 868 and 915 MHz.

So change the rf12_initialize(22, RF12_868MHZ, 5); to rf12_initialize(22, RF12_915MHZ, 5); and make sure to set B's group also to 5, ID to something else than 22. Either that, or first get the nodes talking to each other using the rf12_demo sketch, then replace the rf12_initialize line in radioBlip to rf12_config(0); since that will re-read the (working) values you set and stored with the rf12_demo sketch.


Thank you martynj and padvinder95. The problem is solved.

In the statement rf12_initialize(22, RF12_868MHZ, 5); , I did not realize that the number 5 was the group number. I also was under the mistaken impression that the group number had to be 212 (which I got from here: <nnn> g - set network group (RFM12 only allows 212, 0 = any)

In my case, everything started working once I sent the 5g command to node B.

BTW, blip could talk to demo on any frequency, as long as they were both on the same frequency. My nodes are currently separated by 1.8M. I will do some range experiments later.

Once again, my thanks to both of you!
Happy Holidays


Progress! Tough when you are starting out until you get a baseline of knowledge established.

BTW, the RFM12B chip is identical for all the bands - it is the aerial tuning circuit that has different component values for each band. If you intend to use 'wrong band' consistently, back off the power setting if possible - the mismatch reflects the output power back into the output transistors as extra heat.

Premium Drupal Themes by Adaptivethemes