It’s becoming a bit tedious to set up and manage JeeNodes, each with their own RF12 configuration. Prompted by a recent request, I’ve created what I think is a much more practical configuration system using some of the ATmega’s built-in EEPROM.
The basic idea is to split the configuration and the setup code. The “RF12demo” sketch which is part of the RF12 library has been extended into a general EEPROM configuration utility. Here’s its new startup screen:
So now you can type commands on the serial port to adjust settings. These are stored in EEPROM along with a description string and a 16-bit CRC checksum. When launched later on, the last settings get re-used so this becomes a set-and-forget thing.
What’s more important though, is that the RF12 library has been extended with a new “rf12_config()” call which you can use instead of “rf12_initialize(…)”. It does a couple of things:
- retrieve the settings from EEPROM and check that they are valid
- if so, configure the RF12 hardware accordingly
- display the current settings on the serial port
As a result, it’s now a lot simpler to set up a sketch with RF12 communication. All you need to do is upload and run the RF12demo once to configure things, then upload your own sketch and use “rf12_config()” to re-use the same configuration.
Here’s an example / skeleton:
The output from this sketch is:
It’s a bit cryptic to keep the code overhead small, but you can see that I configured this unit to act as node “Z” (i.e. 26), using network group 212, and operating in the 433 MHz band.
The RF12 configuration data is stored in EEPROM addresses 0×20..0×3F (this can be changed in “RF12.h” if it interferes with your own EEPROM use).
It’s still not working but now the connections are ok
Hm, hard to say. I’ve never used the DIL version. Are those extra chips level converters? You may have to go through each of the signals one by one to check pulses and voltages. Perhaps add some logic to the demo to turn leds on for reception, transmission, interrupts, etc.
(the antennas look a bit short to me for 433 MHz, although they still ought to work at close range)
It’s twice as hard to fix such problems until you can figure out whether it’s the transmitting or the receiving end that’s causing trouble. In general I tend to see spurious packets coming in within minutes, so if you don’t see those at all I’d suggest double-checking the receiving side of both units until you do.
Yes you need antenna wires. WIthout them, nothing will happen.
There is no logic for LEDs in the RF12demo sketch – I was suggesting you extend the sketch yourself to make it turn on LEDs.
That’s correct behavior. You’re waiting for something to happen, but at this point the receiver is off until something is sent out.
If you don’t have scope or logic analyzer, try connecting a led with a 4K7 resistor from +3.3V to the IRQ line. Then you should be able to “see” the interrupts (I’ve not tried this myself).
OOPS, your’right. MOSI means “Master Out Slave In”, so MOSI on MPU goes to SDI on Radio, and so on.
Thank you – I’ve edited the page to correct this mistake: http://jeelab.equi4.com/2008/12/11/good-rf-with-rfm12b/