My sample order of the RFM22 were waiting for me when I arrived home late last night.

Here is a picture of the RFM22 (Left) next to the RFM12B (Right).  Pretty much the same physical size, but more pins, and a lot of very small discrete components.

So What’s New?

These new transceiver modules from HopeRF appear to be based on Silicon Labs Si4431 and Si4432 RF Chips.  Silicon Labs purchased Integration, from where the RFM12B were based on their EzRadio Series of transceiver chips.

It looks like there are a heap of new feature available, (too many to list here), including some onboard lower MAC smarts called EzyMac, while not as nice as the 802.15.4 MAC layer it looks like it can simplify things such as:

• Automatically adding pre-amble and sync bytes.
• Automatic packet size – you just push bytes into the Tx FIFO and it will create the packets of a fixed size and send for you.
• Built in basic frequency hopping.
• Built in Data Whitening, Manchester Encoding, and CRC

Some more niceties:

• 64Byte FIFO.
• Onboard A/D, allows access to read such things as an onboard Temperature Sensors, Voltage buses.
• x2 configurable GPIO ports.
• More Rx Sensitivity than the RFM12B.
• More Tx power than the RFM12B
• Lower Operating voltage.
• 8bit RSSI value.
• Three different modulation schemes to select from.

Some not so niceties:

• More current draw on Rx than the RFM12B.
• More current draw on Tx than the RFM12B (understandable seeing it also has a higher Tx Power).
• Costs about twice as much as the RFM12B ~ $USD6.00 in sample quantities direct from HopeRf vs ~$USD3.00 for the RFM12B.
• Heaps more commands/Registers to learn.
• No onboard encryption.

Feature comparison:

Print PDF

Hmm Its been a while since I revisited the RFM12 tutorials, so I thought I’d better write the next one.  Unfortunately it’s going to be too long to fit in one post so I’ll be splitting it across a couple of posts.

The last two tutorials covered a brief introduction and the physical connection to the MCU.  In this article I’m going to cover the internal commands and how we go about controlling to the RFM12 module.

It’s all done with Smoke and Mirrors!

Well not really, I wish it were that simple…as mentioned previously that the RFM12 needs to be connected as described in the previous article via SPI, the second thing we need to do is access the the internal registers of the RFM12 for it to be useful.

The SPI transfers 16-bit commands to the RFM12, as part of the SPI transfer process it will receive results (if any) back to the MCU.  These commands do specific things, such as set the band, turn on the Transmitter and so on, therefore to get an understanding of what we need to do, we need to understand what the various commands do.

It also helps if you to have the RFM12 data sheet open as go through this as I’ll be explaining  things in roughly the same order as found on the current data sheet, most of this information is direct out of the datasheet.

SPI Interface

Just before we go through the commands, we need to be able to talk to the RFM12, and seeing that we have the SPI and NSEL correctly setup as described in Part 2 we need some routines to talk to the RFM12 and it’s registers.

There are basically two ways to do this, 1) Bit banging the SPI or  2) using on-board hardware SPI peripheral.  The Hope RF programming guide offers a solution to bit banging the SPI interface so I won’t cover it here.

The following function for the AVR will provide hardware SPI support.  The important thing to note is the RFM12 SPI speed needs to be kept within the RFM12 Specs <=2.5MHz

// pins used for the RFM12B interface

#define RFM_IRQ  2

#define SPI_SS   10

#define SPI_MOSI 11

#define SPI_MISO 12

#define SPI_SCK  13

static void spi_initialize () {

    DDRB &= ((1<<DDB2)|(1<<DDB1)|(1<<DDB0)); //spi pins on port b MOSI SCK,SS outputs     

#if F_CPU <= 10000000

    // clk/4 is ok for the RF12's SPI

    SPCR = _BV(SPE) | _BV(MSTR);

#else

    // use clk/8 (2x 1/16th) to avoid exceeding RF12's SPI specs of 2.5 MHz

    SPCR = _BV(SPE) | _BV(MSTR) | _BV(SPR0);

    SPSR |= _BV(SPI2X);

#endif

    digitalWrite(SPI_SS, 1);   // Pull SPI_SS High

}

static uint16_t rf12_xfer (uint16_t cmd) {

    // the 2 loops below each spin 4 usec with a 2 MHz SPI clock

    uint16_t reply;

    digitalWrite(SPI_SS, 0);      // SPI_SS Low

    SPDR = cmd >> 8;

    while (!(SPSR & _BV(SPIF)))

        ;

    reply = SPDR << 8;

    SPDR = cmd;

    while (!(SPSR & _BV(SPIF)))

        ;

    reply |= SPDR;

    digitalWrite(SPI_SS, 1);     // SPI_SS High

    return reply;

}

Communicating with the RFM12

Before sending any commands the the RFM12 the NSEL Pin needs to be pulled low, then pulled high when the command has been sent.

The MPU communicates with the RFM12 over the SPI by clocking 16-bit commands serially in via the SDI (MOSI) pin on the rising edge of the SCK.

The data sent to the RFM12 consist of a command code then followed by a number of parameter or data bits, this command code and parameter/data bits total 16-bits in length.

The command/data structure is then send MSB first so bit 15 is the first bit to be sent followed by bit14 and so on.  At the same time data is being clocked into the RFM12 on the SDI Pin, results (if any) are also being clocked out via the SDO (MISO) pin into the MCU MSB first, e.g. bit15 is clocked out first, then bit14 and so on.

RFM12 communicates back -NIRQ

While the NIRQ is not a required connection, it is handy for the RFM12 module to let the MPU know than an event of significance has occurred, and should be handled, instead of tying the MPU up with polling the RFM12 module to see if things have happened.

But suffice to say, the NIRQ is an interrupt generated by the RFM12 module which pulls the NIRQ pin low whenever the following occur:

• The TX register is ready to receive the next byte (RGIT)
• The FIFO has received the pre-programmed amount of bits (FFIT)
• Power-on reset (POR)
• FIFO overflow (FFOV) / TX register under run (RGUR)
• Wake-up timer timeout (WKUP)
• Negative pulse on the interrupt input pin nINT (EXT)
• Supply voltage below the pre-0programmed value is detected (LBD)

Handling the NIRQ will be covered in a future Transmitting and Receiving article.

Onto the Commands

There are 15 commands that deal with configuration, control and status of the RFM12 module.  these are listed below:

UPDATE:  Try this handy utility as you play with registers, it’s a RFM12b command  calculator  (thanks Frans, aka fotoopa, for the link!)  http://www.technofun.org/blog/2009/01/24/rfm12-rfm12b-calculator/

1) Configuration Settings Command

The configuration command as the name suggests is used to configure the RFM12  (POR denotes the Power on Reset Values)

el (bit 8): Enable internal data register.

ef (bit 7): Enable fifo mode.

The el and ef bits are used to determine how the data is moved out of the RFM module.  Most of the time you will be using FIFO mode as this simplifies things.

bits 6 – 1 (b1 – b0): This determines the band of the RFM12 module being used and needs to match the physical RFM12 module you are physically using  e.g. you don’t set the band for 433 if you are using 915Mhz module.

bits 4 – 1 (x3 – x0): Determines the load capacitance of the onboard crystal.  This allows fine tuning of the crystal frequency.  Defaults of 12.5pf should be used.

The calibration procedure uses these settings to adjust the CLK output to 10Mhz. This procedure is in the data sheet, but is pretty vague, basically hook up a frequency counter or Oscilloscope up to the CLK pin of the RFM12B module, change the Frequency of CLK to 10mhz and measure it, it it’s not at 10MHz then use the load capacitance (x3-x0) to adjust it so it reads 10MHz.  From the couple of modules I’ve tested they have all been ok at the default of 12.5pF

2) Power Management Command

The power management command controls the power to the RFM12 sub-modules, it allows you to select what circuit within the RFM12 is turned on/off.  So by disabling these circuits when not required you can control the amount power savings of the device.

The ebb, es, and ex bits are provided to optimize the TX to RX or RX to TX turnaround time as shown in the table below

This gives you an idea how the control bits are logically connected:

3) Frequency Control Command

Within each band (433, 868 or 915Mhz) we have control over what frequency the RFM12 module communicates on.  So we can have various communication links occurring at the same time on the same band, but using different frequencies, or if we are getting interference on one frequency we can switch to another clear one.

Depending on what the band is determines the resolution of the frequency steps.

The frequencies available to each band are described below in this table

The 12-bit number representing the frequency can be calculated by:

#define RF12_FREQUENCY_CALC_433(f) (((f)-430000000UL)/2500UL)  // Calculate the RFM12 register value for a given Frequency at 433MHz in 2.5khz increments

#define RF12_FREQUENCY_CALC_868(f) (((f)-860000000UL)/5000UL)    // Calculate the RFM12 register value for a given Frequency at 868MHz in 5.0Khz increments

#define RF12_FREQUENCY_CALC_915(f) (((f)-900000000UL)/7500UL)    // Calculate the RFM12 register value for a given Frequency at 915MHz in 7.5Khz increments

The 12-bit frequency value must be between 96 and 3903, if not then they will be set to these values automatically.

IMPORTANT: It is also important that you keep within your countries ISM spectrum management guidelines i.e. allowable frequencies and their use when selecting your operating frequencies.

4) Data Rate Command

This command sets the bitrate of the transmitted data or the expected bitrate of the received data.  This is the RAW physical bitrate of the module.

cs: is set if the bitrate is < 2700 bps

Here is a table I’ve prepared for common values.

If you want to calculate your own bitrates use the formula:

//calculate setting for datarates >= 2700 Baud

#define RF12_DATARATE_CALC_HIGH(baud) ((uint8_t)(344828UL/baud)-1)

//calculate setting for datarates < 2700 Baud

#define RF12_DATARATE_CALC_LOW(baud) ((uint8_t)(43104/baud)-1)

When setting bitrates you also need to take into account the receiver bandwidth settings (See  Receiver control command below)

5) Receiver Control Command

Bit 10 (P20): sets the function of INT/VDI pin on the RFM12 module, it configures it as input (Interrupt from MPU) or output (VDI Valid Data Indicator).  The VDI is the default setting.  This goes high when valid data has been detected by the RFM12 module, valid data is data that has made it past the Sync pattern.  If set as Interrupt input, we can use this to send an interrupt the RFM12.  The RFM12 will then stop what it’s doing and wait for the next command.

Bits 9-8 (d1 to d0): VDI (valid data indicator) signal response time setting:

Bits 7-5 (i2 to i0): Receiver baseband bandwidth (BW) select:

The receiver bandwidth is the amount of frequency above and below centre frequency we are receiving on (See the Frequency command for more information on changing the frequency)  that the receiver is sensitive to.  So if 400Khz is select as the Receiver bandwidth and 915Mhz is the centre frequency, then the receiver will looking for a signal anywhere +200Khz above 915 and 200Khz below, i.e. 914.800 – 915.200.

The bandwidth settings is linked to both the data rate, and Tx Modulation (Deviation)commands.  When data rate is fastest a higher bandwidth is required.   There are optimal settings for the Bandwidth and Modulation for different data rates as shown below.  Having too much bandwidth can cause a higher SNR and can cause packet corruption.  Not enough bandwidth and the incorrect signal is not received.

Incorrectly setting Bandwidth and Deviation (Modulation) is usually one of the common problems.

Table of optimal bandwidth and transmitter deviation settings for given data rates (the data sheet was a bit vague in this area and did not specify frequencies etc so I don’t know how valid they are at different frequency bands but they could be used as a starting point)

Bits 4-3 (g1 to g0): LNA gain select:

The LNA gain (Low Noise Amplifier) can be selected according to RF signal strength. It can be useful in an environment with strong interferers.  Or alternately if you have two RFM12 modules in close proximity then you can drop the sensitivity of the Low Noise Amplifier.

Print PDF

For the next version of the widget,  I’m planning to have an on board boost regulator.  This design will allows the widget to run from just about any voltage source as low as 0.7v (so NiMh will be fine) and up to 5.5v, this boost regulator in conjunction with a standard LDO regulator will give me a nice input voltage range of 0.7v – 12V.  Before I finalise the design I wanted to test things to see how well it’ll work. 

I ordered in a couple of battery holders from Polou with an integrated boost regulator, since the widgets are designed for 3.3v operation I ordered this model http://www.pololu.com/catalog/product/796,  that provides a 3.3v 100mA supply from a single AA battery, I’m not too sure what the minimum voltage is, but is running fine on a single NiMh cell.

Well today they arrived and I now have one hooked up to my solar powered widget.  Installation was simple as the small pcb on the rear of the battery holder allows me to direct access to the cell contacts, so I soldered the solar cell +ve and –ve on the respective contacts.

From some previous tests with my solar powered widget, I was finding that the batteries would start charging when the solar cell output reached around 2.8 –2.9v, this is fine for during the day with the solar cell in direct sunlight, now with the single cell I’m finding that inside under artificial light I’m charging at around 1.5v, with plenty of overhead left.

You can see below the voltage output of the boost regulator is ~3.3v (3.322 to be exact) and the voltage from my solar cell is ~1.52v, this is inside under some standard down lights while writing this post at the kitchen table (actually one of the down lights is dead so I could expect a little more output from the cell)

Just to try something different I removed the battery, seeing if the regulator could run direct from the solar cell, unfortunately it doesn’t, I doubt the cell in the current light conditions can provide enough start up current for the regulator,  I will however try it in the natural sunlight tomorrow.

With the addition of the boost regulator, and the widget in max power savings between sensor reading (when asleep widget is drawing 1.5uA, which is most of the time) then the widget should run indefinitely from the single cell….or maybe I could just get away with a solar cell and a super cap now there’s a future project….

Print PDF

I want to deploy widgets around the home, both inside and out,  so I needed to find something that would allow some protection from the environment to the electronics, cheaply and easily.

On the weekend while doing some shopping I found the solution in the kitchen area of the local discount store, at $1.50 a piece it was the right fit for the job.  They probably won’t like U/V in the long run, but will see how they go, at that price I can replace cheaply.

(click picture for more details)

Waterproof/Dustproof housing with easy access to the internals.

This will be the standard sensor node housing.  The widget Boards and battery pack are fixed via velcro so I can easily remove for reprogramming etc. 

I still need to look at airflow of sorts for temperature, humidity and pressure sensors, will probably look at putting a couple of small vents in, this will compromise the waterproofing.  

To mount these I can put some velcro on the back and mount it on any horizontal or vertical surface.

Open and showing details of SMA pigtail connection, batteries (x2 AA side mounted) and widget board velcroed to the container (personality board removed)

Same as above, but this is for my outside sensor nodes where I’ve mounted a Solar Cell sealed on the outside, I did some initial testing and there was a filtering effect of the plastic lid and the cell, so I  decided to put the cell on the outside to get maximum efficiency, it was a pretty messy job after I used silastic to seal everything, the cell now has a smear of silicone haze across it that is appearing very difficult to remove.  So in future I think I’ll live with the slight degraded Cell performance and mount it inside, where it fits perfectly, that way I can use a couple of blobs of hot glue to fix the cell to the lid.

Print PDF

Today I did some testing on the RF side of things,  nothing scientific, just walking around the house seeing if it would dropout or report bad checksums, I’m happy to reports all is working as expected (using the 915Mhz RFM12B module)

The tests are done by using the RFM12B Example sketch found in the JeeLab RFM12B library by Jean-Claude over at Jeelab (RFM12B Arduino Library)

This library runs unmodified on the wireless widget board, just follow the instructions in the README about setting up node ids.

From the preliminary testing using some compact 1/2 wave GSM 900MHZ/1800MHZ antennas (http://www.dealextreme.com/details.dx/sku.5237)  I’m easily getting all the way around the house with no dropouts, have yet to do outside tests.

Print PDF

Today I constructed another 2 boards, very easy to do all done in around 30 minutes.  This now brings the total to 3.

Applying the boards with solder paste by hand, manually placing the components, bake them in the toaster oven together.  This time I got the LEDs the right way around and the right amount of solder paste on everything, no bridges on the CPU pins and looks like the right amount of fillet on the RFM12B module, very little cleanup work required, it’s amazing how little solder paste is required.

Add another 5 minutes to hand solder on the SMA connectors and program the boot loader on each, voila all done in around 30 minutes.

Now I have a potential “Network” I will start testing the RF side of things.  Currently I’m using the 915MHz modules.

Print PDF

Today I got a chance to do some testing on the boards. 

State of play so far:

1. Checked for shorts on power – OK
2. Did a board level continuity test – everything as per schematic.
3. Power at the correct levels and at the right places.
4. Found that my USBASP programmer needs sw2 set and now all working, I can now read and set fuses etc.
5. Arduino lillypad bootloader successfully loaded and working – Whoot!
6. ASCII sketch loaded via Arduino development environment, serial port tested at 9600, all working.
7. Jean claudes RFM12B Test Sketch loaded and working.  Can configure device and some random data is being read back from RFM12B, need a second board operational to fully test the RF side of things.

TODO:

1. Build a second device now that the basic circuit is working and verified.
2. Fully test RFM12B and wireless comms.
3. Test I/O i.e. Analogue and Digital ports, LEDS  etc
4. Customise boot loader to use onboard LEDS.
5. Document all of the above for others on the project’s website.

All in all I’m pretty happy

Print PDF

The PCBs arrived last week, unfortunately not in time for the long weekend so I haven’t really had a change to do anything until today and from my initial observations I’m happy with the results.

RFM12B PCB

2.4GHz MRF24J40MA PCB

Prototype PCB

As I mentioned on the Strobit-general Google List and the SPOT-development Google list,  they seem to have multiplied from when I placed my order to when I received them,  I calculated I would get approx 12 back of each board, in the end I received 32 of each board, go figure…..so if anyone wants a couple of free blank PCB then contact me and I can send you some if you cover the postage costs.  Please use the contact form to let me know.

Hot Out of the Oven

Today I assembled the first one!  Didn’t take long at all due to the minimal component count.  If anything I need to add more solder paste to the RFM12B footprint, but seems to have taken.

RFM12B PCB Assembled

I’ve partially assembled the board, enough to give me basic functionality so I can do some tests, while the rest of my components I’ve ordered (SMA connectors etc) arrive.  Unfortunately my stash of 0603 capacitors were actually 0805 ones in disguise, so I’ve had to use these even though the footprints are for 0603.   In the photo you can see some of them installed on their side.   Same goes for my bead, I only had some 0805 in my stash but have 0603 on order, just couldn’t wait  

I’ve enabled all the solder jumpers so I don’t need to install the switch and the BAV diode for the time being.

Changes for next board revision:

A couple of things stand out with this board revision, nothing major but niggly enough to warrant changes or at least thinking about them.

Crystal Footprint – One thing so far, I’m kicking myself for not making the crystal footprint a HC-49 SMD, I thought about it before I send the files off for fabrication, instead I opted for the sleek 0503 ceramic smd crystal, problem is they are more expensive and not as easy to come by, so I’ve added this as a change for the next board revision.  In future I’ll stick with the stock standard low cost crystal HC-49C footprint.

Switch – Do I really need it?  The onboard switch seemed like a good idea at the time, but in reality do I really need it?  I’m glad I had the fore thought to add a solder jumper to bypass it. Honestly I will probably more than likely use a switch remotely (i.e. on the side of an enclosure) or on the battery pack itself rather than on the PCB.  I may just leave the ability to have a remote switch and remove the onboard footprint all together.

LDO regulator onboard? – I’m still up in the air about this one.  Initially I wanted to keep things as low cost as possible (and I still do), and then add additional functionality via the personality boards so keeping the core board to bare minimum components, as I have only intended these to run from battery or from USB, not from a wall wart or A/C plug pack.  I have added some reverse protection with the BAV Scotty diode, but this won’t protect the board if someone connects a 9vDC source.  Anyway I think  I will wait and see how I go with testing and community feed back.

Print PDF

Jean-Claude over at JeeLabs has been playing with the RFM12 and has noted some differences between the RFM12B and the RFM12.

http://jeelab.equi4.com/2009/05/06/rfm12-vs-rfm12b-revisited/

Print PDF

HopeRF 433Mhz / 915Mhz

Experimental 2.4GHZ

Print PDF

I’ve been playing around with Googles sketchup over the weekend and have created some components, one the RFM12B module and a basic camera hotshoe to scale.  It’s been a great little exercise in learning both Alibre and Sketchup as I’ve been wanting to get some 3D modelling practice, I’m finding that it’s easier to create things in Alibre and then export them to Sketchup.  Alibre does not support texture mappings in the drawing or export to POV, but Sketchup does it brilliantly, while on the other hand, Alibre’s3D modelling is very easy to use.

Currently the workflow is:  Model in Alibre –> textures in Sketchup – > POV Rendering– > Eagle3D Components.

Keep an eye out for more to come.  I’ve started a Stobit Collection in Googles 3D warehouse  for use with this project and will be adding to it as I go.   I’ll be putting the Eagle3D component files that I’ve created online shortly.

Print PDF

I know I’m a bit slack in updates on the blog.  If you haven’t noticed I now have a twitter account  http://www.twitter.com/madeinoz so you can follow what I’m doing when it’s not getting updated here.

However since the blog is way over due for an update here is what’s been happening in a nutshell.

Strobit Trigger:

I have finally gotten off my butt and done a redesign (hah and you thought the project had died a slow death, it may have stalled slowed, but certainly not dead!)

Features worthy of note in the new design (in no particular order):

• 3V design, will run from x2 AA Alkaline or single CR123A 3V battery.
• Fairly compact board, 30mm x 70mm. (without battery)  slightly lalonger on 2.4ghz design due to antenna.
• Onboard on/off switch to save batteries when not in use.
• FTDI 3.3v breakout cable port for connecting to either RS232 or USB using the FTDI cable.
• Onboard ISCP port for programming.
• Personality daughter boards.  Will allow users to create their own hardware modules, i.e. sound trigger, light trigger, LCD UI, or whatever they like etc
• Atmega168V processor, low cost, low voltage design = longer battery life.
• Can run Arduino bootloader, so developers have access to Arduino development libraries.
• I’ve designed 2 different boards.  One using the RFM12B module at either 433Mhz or 915Mhz.  The second board I’m going to try a 2.4GHZ design using Microchips FCC certified MRF24J40MA 802.15.4 module, this is purely experimental so I don’t have any testing done yet, but I have some of these modules and would like to try them out, also being FCC certified will be an added benefit.  (not to mention I’ll be using these for a mesh sensor network project I have planned around the house)
• RFM12B board design has external SMA antenna.
• Base PCB board designs are done and I’m fairly happy with them so far, I’m just finishing a basic personality modules which I can used for testing and maybe another one so I can make up the  max designs I can have on a single panelized board (may as well get the most designs I can get fabricated when I send it off to GoldPheonix).  I’ve done some initial Eagle3D runs to get an idea of the boards and so I can post them on the blog, but I really need to learn how to create components in Eagle3D as it leaves unknown components blank, i.e. the RF modules and therefore looks incomplete.  (anyone that can help me here please contact me)

Still To Do:

• Panelize boards
• Send to GoldPheonix for PCB fabrication.
• Assemble and test.

I’ve also been playing with learning Alibre, a fantastic 3D design package (they have a free version) so I can get some ideas for building enclosures design for these boards.

RFM12B PCB

MRF24J40MA PCB

Print PDF

During the prototyping of the StrobIt Triggr, I found that I could only hit the maximum bit rate of approx 12000bps, this is a far cry from the reported 256Kbps, so what was I doing wrong?

(more…)

Print PDF

Well my new tool, a LogicPort Logic analyser from http://www.pctestinstruments.com/index.htm, arrived last week whilst in the middle of our house move and I’ve been itching to try it out, well last night I made time to play with it.  The result is, man I wish I had one of these beasts earlier.

(more…)

Print PDF

Part 2 – RFM12 Hardware Interface

In this next part of the RFM12 tutorials I’ll be covering the hardware interface, signal descriptions and how you go about hooking it up to the MCU of your choice.

(more…)

Print PDF