Computing stuff tied to the physical world


RF12 configuration in EEPROM

In AVR, Software on May 7, 2009 at 00:01

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:

Picture 2.png

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:

Picture 4.png

The output from this sketch is:

Picture 3.png

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..0x3F (this can be changed in “RF12.h” if it interferes with your own EEPROM use).

  1. I can’t comunicate between the two rfm12 using that example :S You can see some photos and print screens here: http://picasaweb.google.pt/josescxavier/Rfm12#

    José Xavier 16 May 2009 at 1am

  2. They are RFM12 – 868Mhz. Bu i test with 868Mhz and the result are the same :S. It’s necessary solder the antena? Where can i connects the leds to see if something is send or receive? thanks for your answer.

    José Xavier 16 May 2009 at 2am

  3. I will try to understand your sketch and add the leds. Another question, i have the antenna that you can see in the first image od that pdf: http://www.hoperf.com/pdf/RF12TOOLS.pdf, it’s good? I have to solder it to the 2 points?

    José Xavier 16 May 2009 at 3am

  4. I don’t know. Look up the RFM12 specs. Look around on this blog. Here’s an example: http://jeelab.equi4.com/2009/04/19/production/ – i.e. 1 wire connected to 1 pin.

    Best of luck.

    jcw 16 May 2009 at 3am

  5. Hi, it’s still not working. I already solder the antena but i have the same resulta, i can configure it but anything else :S the PD2 in an arduino is the pin 2 digital, right?

    Any ideia?! :(

    José Xavier 18 May 2009 at 10pm

  6. Hi again, sorry for my questions but you are the only man that i know that is working on it. What are the value that i must define in configuration for the load capacitor? In the datasheet i have values from 8,5 to 16pf

    José Xavier 19 May 2009 at 11pm

  7. (“only man” … well, even if that were true, that doesn’t make me the HopeRF tech support guy)

    But seriously, you’re asking questions I wouldn’t know how to answer. I use the settings as currently present in the RF12 driver code, I don’t even know what some of these settings mean, sorry. Check, recheck, and simplify – that’s all I can give you as advice. I hope you can figure it out that way.

    jcw 19 May 2009 at 11pm

  8. I try this http://jeelab.equi4.com/2008/12/11/good-rf-with-rfm12b/ and i saw that the program never go out from [code]void rf12_send(uint8_t data) { Serial.println("ENTROU"); while (digitalRead(RFM_IRQ)) Serial.println("!"); ; rf12_xfer(0xB800 + data); ChkSum += data; }[/code] the while, i have in the shell always a !, any sugestion?

    Thanks for all

    José Xavier 23 May 2009 at 2am

  9. I connected a led in the IRQ line of xmit and recv and the led never blinks, it’s always off, so the IRQ line is always on and never go out from while (digitalRead(RFM_IRQ)) :S

    José Xavier 23 May 2009 at 2pm

  10. I’m continue with the debuging process.

    I think that information is wrong:

    * MOSI (MCU) –> SDO (RFM)
* MISO (MCU)  SCK (RFM)
* SS (MCU) –> nSEL (RFM)
* PD2 (MCU)  SDI (RFM)
* MISO (MCU) <– SDO (RFM)

    Can you confirm it?

    I tried a very simple code, if you have a free time it's very important to me if you can give a look at my code: http://paginas.fe.up.pt/~ee06091/rfm12_test.zip

    José Xavier 24 May 2009 at 12am

  11. It’s still not working but now the connections are ok

    José Xavier 28 May 2009 at 10pm

  12. 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.

    jcw 16 May 2009 at 2am

  13. 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.

    jcw 16 May 2009 at 2am

  14. 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).

    jcw 23 May 2009 at 10am

  15. 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/

    jcw 28 May 2009 at 5pm

Comments are closed.