Strobotics

It’s been long overdue but as you can see the site is getting a makeover. 

I’m also doing some long overdue housekeeping with the pages, categories and tags.  There may be some 404 page errors, I am monitoring and fixing these as I come across them, however if you’re having any problems please contact me.

I’ve also added some mobile themes for those visitors on the go. 

Over the last couple of nights I’ve been verifying the respective individual circuits of Rallylog before I get down to developing the application.

Test Results so far:

RFID Module

I’ve had a couple of problems so far, first the RFID module has very short pins that only just go through the PCB to allow for soldering, I had what looked to be a dry joint on one of the pins, after re-soldering with a bit more heat and solder all joints now are solid and is working no problems.  The Range of the card read seems to be far less than specified, so I’m wondering if the GND fills on both sides of the PCB near the RFID module could be causing this, I will remove them in the next PCB iteration. However it is working and the range is sufficient to work as required.

SD Card

I now have writing to the SD card working, had an initial problem where the pull-up resistors were causing the problem, removed and now ok.  I’m using the filelogger library (http://code.google.com/p/arduino-filelogger/) and have it writing the test message to the card.  A gotcha was an existing 1-Byte sized file needs to already exist on the SD card for the library to work.  I’m also having some problems when the card is removed and re-inserted no writing takes place.  This appears to be a library problem so will investigate further later.

USB

Another problem is the USB side of things.  I’m using an FTDI FT232RL USB-Serial conversion chip, fairly common, however the output on my Tx is garbled, I’m also assuming that my Rx is the same as I have yet to delve deeper into the problem.  It may be an unidentified solder bridge somewhere that I can’t see, the pitch on this component is pretty fine.  

I’ve checked correct bit rates but still failing.  I initially found I had problems when I went to program the bootloader and could not get any of them to work, so have filed this as a FAIL and moved on to complete the rest of the testing as I’m using the programmer interface to load my test sketches.   I’ll revist in detail later. 

UPDATE: I have downloaded the FTDI chip programmer utility and this sees the FTDI chip and alls it’s registers ok, so the USB-FTDI circuit appears to be working, but the FTDI – AVR is not.

Last Friday I received my second revision of PCBs.  As mentioned in one of my previous posts I majorly stuffed up on my LCD footprint along with some additional board changes including the larger 3V regulator and the 5V regulator PCB.  

I’m very happy with my switch to Kicad also with it’s resulting PCB below.

(Click through to flickr images for more details. Some are commented and have notes)

After verifying the PCB again (this time successfully), I set aside some time over the weekend to assemble the first unit for testing.

Rally log with all SMD components assembled

Rallylog with all components assembled and removed from the tooling strips

Test fit in Sparkfun project Case, have yet to fit the top cover, i.e. drill holes for LEDs, Buttons and LCD, will be leaving this until after testing, but happy with the results so far

My latest toy acquisition arrived in the post today, it’s a small usb microscope from Deal Extreme – http://www.dealextreme.com/details.dx/sku.35636.  I purchased this so I could do my PCB inspections alot easier. 

Some of it’s specs:

• max  resolution of 1600*1200 (these ones below were taken at VGA resolution – 640×480)
• Manual zoom levels x25 – x200
• 8 LED white light that you can control the brightness via a pot on the cable.
• Measurements and markups via the software.
• can use handheld and comes with a stand for hands free use.
• snapshop button so you can quickly take still images.
• Software filters to apply to the video stream.

The screen shot below shows me calibrating against a steel ruler with 0.5mm increments.  This is the outermost Zoom level of x25.

The calibration process is very simple once you work out how, the manual is written in “Chinglish” and not that helpful.  However I soon worked things out that to calibrate you pause the video source and then use the measurement tool to take a number of readings, from these you average the readings and enter the units and pixels measured into the calibration data, after the calibration has been performed then at the current zoom level you can make measurements, angle measurements, area calculations all through the software.

The down side is the calibration is only good for the zoom level you’re currently at so if you re-zoom you need to re-calibrate, so keep the steel rule on hand.

Here is a quick test on the rallylog board at the lowest zoom at VGA resolution.  The tracks are 10mil so not too far off with the measurements if you do the conversion.

Here is another couple, this is of the problem zone pour that I picked up in my previous blog post.

Zooming in on the above area with the microscope zoom function

Another using the emboss filter, you can see quality of the ATMega328 pads on the with HASL surface finish from Gold Phoenix (no so great on the one circled)

and with no filters applied and zoomed in.

The best thing is the price, at USD42 it’s a great addition to my toolbox.

As mentioned in my last post, Rallylog is a new open Hardware project it also uses Kicad as the EDA.  Well late last week my prototype boards arrived from Gold Phoenix and very happy with the results, well sort of…..

Testing

When I receive a new design, one of the first things I do before any components or power is applied to my boards is to check all the physical connections with my trusty multi-meter on continuity settings then with schematics in hand I proceed to check every connection and check it off on my schematic.

From the schematics below you can see how I was progressing.  the green highlights are errors I’ve picked up, only a couple of minor ones that are easy fixed, until I got to my LCD board.  This PCB design is across two boards to account for a LCD, buttons and LEDS for the UI so that I can fit it all in the sparkfun project case.  I had created a new component for the LCD module I’m using, a low cost SPI based backlit LCD module, and I had placed the top row of pins on the module the wrong way around.  Still can’t work out why I hadn’t picked it up, but these are the problems when you’re a 1 man development team and there is no one else around for a design review…sigh, anyway changes have been incorporated into REV B.

Voltage Regulator sizing

Other significant change is to the 3.3V Regulator circuit, when I initially did my power budget I calculated that my 3.3V rail power requirements would be around:

Atmega328  – 5mA
LCD – 250uA
LCD Backlight – 80mA (20% Duty cycle)
SD Card – 80mA (200mA Spec)
RTC – 300uA

In total ~ 165mA .  The 3.3V regulator I had chosen had a max load of 200mA so plenty of headroom right? Wrong!!!

After revisiting my original design I realised I had made a mistake, I had not taken into account the input voltage and the de-rating effect of the volt drop across it.  In my case a 9v battery is being regulated by an LDO regulator down to 3.3V so in the process heat is generated, the larger the difference between Vin and Vout the warmer it will get, and the warmer it gets means my Max current output of the regulator drops, so how do I find if my regulator will still cut the mustard in this design? 

After a bit of research I found that I need to calculate the maximum power that can be  dissipated by the regulator and use this along with the max power of my circuit.  In this case my LDO is a SOT23-5 device.

so for my circuit:

Power(dissipated) = (Vin – Vout) * Imax

VIn = 9V (from battery)

Vout = 3.3V

Imax = 165mA

Power(dissipated) = (9 – 3.3) * 0.165 = 0.94W

This is close enough to 1W of power to dissipate in my SOT23-5 device.  Next thing is to see if the device can dissipate this amount of power.

From my technical datasheet the device has a max operating temperature of 125DegC and the thermal Resistance from Junction to Air is 220 DegC/W.  I also need to allow for Maximum ambient temperature, in this case 40DegC.  The thermal Resistance determines how efficient heat is transferred away from the junction i.e. the lower the number the better, meaning it’s more efficient at transferring away the heat from where it’s generated.  If the temperature reaches it’s operating max then the device will thermal limit, i.e. shutdown the output, which is not good.

Power(dissipatedMAX) = (TempMax – AmbientMax) / 220 DegC/W (for SOT23 Device)

= (125 – 40) / 220 = 0.386W

So my device has a max power dissipation @ ambient (40DegC) of 0.386mW , however the power being dissipated by my circuit is ~1W which is > 0.386W, so is not good    I need to go to a larger device, or lower the input voltage, in this case it will be a larger device as I’m not changing the battery type.

Calculating again for a SOT89 LDO Regulator with some better thermal parameters.

Max Junction Temperature = 125DegC

Thermal Resistance (Junction To Case) = 35DegC/W

= (125-40)/35 =  2.42W

So compared with my original regulator this one can handle the power dissipation as 1W < 2.42W with plenty of overhead.

Now the 5V Regulator

Doing the same for my 5V rail @ 85mA using the same SOT23-5 regulator (but 5V fixed output) gives  me:

Power(dissipated) = (9 – 5) * 0.085 = 0.34W

This is less than the Max power able to be dissipated by the regulator, i.e. 0.34w<0.386w so will be ok….just….although will run a little warm.

So if I add a PCB heat sink of 25mm square around (and underneath) the regulator using vias to transfer the heat how will that go?

So re-calculating with the PCB heat sink of 25mm square copper trace that has a thermal resistance of ~ 35DegC/W

Thermal resistance from Junction to Case = 81DegC/W

(125-40)/(81 +35) = 0.732W

So by adding a heat sink integrated into the PCB has increased the efficiency of the regulator to get rid of the heat by 89%.    

What I’ve done is to add a couple of vias directly beneath the regulator and opened up the solder mask so that bare copper is directly beneath the regulator.

It has certainly been a while between posts, but I thought I write a few things about my conversion to Kicad as my EDA of choice.

Most All of my projects in the past I’ve use Eagle PCB, as it certainly has been the EDA of choice in the open hardware community.  However it was the only non-open piece in my open hardware arsenal, until now…..enter Kicad.

I’ve been keeping an eye on Kicad for the past couple of years and I’ve never really had time to try it out on a project until now. 

A bit of background

My Father is a member of a recreational collectors motor bike club and they have a number of timed competition rallies throughout the year that may go over the weekend and consist of many checkpoints across a course that are located throughout the district. 

In the past they did everything manually i.e. write down their time and details at each checkpoint, so at the end of the rally, times are tallied and winners announced etc. Since it is manual it doesn’t scale very well, at their annual run where a few hundred competitors took part it didn’t scale well at all.  Knowing the geek that I am, my father asked me if I could do anything  to make things simpler.  The club had investigated some commercial rally systems, but was pretty expensive. I volunteered to automate things a bit…..

Enter RallyLog!  An Open Hardware project that will use RFID tags to log competitor times at checkpoints.

So I now had the reason to learn Kicad for a totally Open Project.

Enter Kicad…

Kicad was originally written by Jean-Pierre Charras (more background on Kicad can be found here – http://www.lis.inpg.fr/realise_au_lis/kicad/)

It is actively being developed by a large number of volunteers at http://launchpad.net/kicad and runs on a number of platforms:

• Windows
• Linux
• Mac

Kicad is made up of a number of different applications that run under the Kicad project manager they are:

• kicad – the project manager.
• eeschema – the schematic editor.
• cvpcb – the footprint selector for components used in the circuit design.
• pcbnew – the PCB layout program.
• gerbview – the Gerber (photoplotter documents) viewer.
• 3D PCB Viewer

First Impressions

Coming from Eagle I had to unlearn how I did things within Eagle and move to the  Kicad way, this means a lot of right-clicking to do things, many things were not the same as what I was used to in Eagle, but I quickly picked things up within a day of using Kicad and now find most things fairly intuitive.

If I had a problem I found the developers and the users to be very helpful answering questions on the mailing list.

What About Your Existing Libraries?

Yes this is a big thing, especially those who have build up their own footprint libraries over time, however all is not lost! a ULP Eagle Library conversion script has been written that is run from within the Eagle Library.  This converts the library to the Kicad library format of which the Components and PCB prints are separated out into two files.  One is a library *.lib file for eeschema that contains the schematic representation of the components, the other is in a *.mod format for module footprints used within pcbnew.

In Eagle a library contains the:

• Symbol – Schematic representation, actual component and
• Device – the PCB footprint , all of which represent a component.
• Package – the actual component that links links the Symbol and Device

Kicad component library has been separated into the Schematic and the PCB side of thins, one library for each.  Now That I’ve been using things for a bit over a month I can see that it makes a lot of sense.  When I’m creating a schematic all I want to worry about is capturing the circuit, if I need a new component I create a new component in the library, not having to worry about the footprint at this point in time.  In eagle it is similar, i.e. you can create only the symbol and package without the device, but I found it long winded.

Another added bonus with the components is you can link data sheets to the individual components. Brilliant!

I successfully imported a my libraries across, I did have to manually replace the reference some components as it defaulted to U?

One thing I haven’t played around with yet is the 3D viewer.

The Process

1. Create a new project within Kicad project manager
2. Create a schematic (and components if required)
3. annotate your schematic
4. Design rules check
5. Create a netlist
6. run cvpcb and associate footprints to your components
7. run pcbnew
8. import your netlist
9. layout your PCB
10. Design rules check
11. plot your gerber output and create drill files
12. view with the built in gerber viewer.

Features and Anti-Features (pros and cons)

Pros

• 100% Open Source!
• Interface for FreeRoute build into pcbnew, so you can use a push and shove autorouter.
• In build Gerber viewer
• 3D Viewer of the PCB.
• I love the professional looking schematics it generates, even including the border information.
• Hierarchical schematics – you can place sheets with-in sheets and drill down by clicking on them
• Hierarchical Pins – have signals displayed in your hierarchical sheets as shown below.

Cons

• Drills – Kicad has no concept of drills or holes in the pcbnew program, so you have to put in a pad that has the drill and the pad size the same, unfortunately this results in plated holes unless you notify your manufacturer of the holes not to be plated.
• Component layers – I like the ability within Eagle to have a document layer for my footprints, where I can put information that will not included in my final output. (this is actually implemented in Kicad just a bit harder to find and not so intuitive)
• Lack of inbuilt scripting like eagle, however you can write scrips in any language you want and manipulate your schematics, PCB and components externally du to the open format it is all saved in.

New boot loaders for the WidgetBoards have been uploaded to both SVN and to the downloads area.  The fuse settings have also been updated in the documentation.

I’ve also integrated the Atmega328P version of the WidgetBoard into the Arduino development environment so please update your boards.txt with the one from SVN.

I have successfully re-compiled and re-flashed the firmware source to remove the console on ttyS0, as suspected the console attached to ttyS0 was the root of my problems, now avrdude will talk to the WidgetBoard!

and here is my WidgetBoard booting my test blinky on ContikiOS as seen by the gateway ttyS0

now back to writing the contiki radio driver…..

I’ve had some mixed success with the serial port hack on the Airlive device since my previous post.

After setting up the uclib development environment I have now successfully compiled avrdude so I can program the RFM12WidgetBoard located inside the device, however I had a couple of issues when trying to talk to the WidgetBoard.

Nothing happens when trying to query the WidgetBoard…data is going out the serial port but nothing being returned.

First problem I found….crossed Tx and Rx due to a silkscreen error on the WidgetBoard, the silkscreen for TxO and RxI are wrong way around on the PCB.

After fixing this problem and re-testing Avrdude it’s still not working….so further testing…..

Serial port is definitely working and I now have a serial console to the device.   When I connect up a terminal program via my FTDI USB ttl serial cable I can see the boot process and logon to the console via ttyS0, which is probably one of my problems, the bootloader may be getting confused by the console chatter. 

The trace below confirms this.  I’ve re-flashed the WidgetBoard with my blinky  example from the Contiki port, besides blinking the LEDS it also outputs a string “There is” to the serial port, you can see by the trace what the WidgetBoard is sending, and the output sent back by the console.

By default this kernel has the console attached to ttyS0 (see my previous post and the dmesg dump) so one of my next steps will is to recompile the kernel and disable the  serial console access attached to ttyS0.

The WidgetMesh network development for the Widgets is now underway, the last couple of days I’ve been learning how everything fits together in Contiki OS, as far as drivers go and how they communicate with the upper stacks, lots of looking through existing code.  I now have a reasonable idea of how things should work and how I need to write my driver.

That said the biggest problem with the WidgetMesh is going to be on chip resources, especially with the ATMega168 and maybe even the ATMmega328P, I’m not looking at running an IP stack on the mesh (well at least not yet), but the gateway/coordinator device needs to keep track of the nodes in the network.  It’s role is to manage node associations, link forming and routing within the mesh, so this will require more ram than most of the nodes will have, especially in larger networks.  It’s also the gateway to the world for the data collected.

I’ve been scratching my head as to what I’m going to use.  I was leaning towards an ARM7 hooked up to a RFM12 or WidgetBoard, something along the lines of a make controller as I have a couple at home from past tinkering, or one of these ARM9 devices running Linux, the MMnet1001, from Propox, Both these have onboard Ethernet and plenty of resources for what I want.  But it turns out that I had a solution at home already, in the form of an Airlive NAS device, WMU-6000FS.  The Airlive NAS comes with Ethernet, WIFI and x2 USB ports, also PATA or SATA hard drive, all this runs from a 12V supply, so I could also run this from a SLA battery.

The Airlive WMU-6000FS is a not so great NAS device that I evaluated for work project involving offsite replication.  The project was eventually shelved. 

The great thing is that it runs embedded Linux, after a bit of research found that I can re-flash the current device easily with a distribution from http://mgb111.pradnik.net/ will allow me to make changes to the system, whereas the current flavour is embedded and is Read only, all changes are lost at boot, however no documentation anywhere regarding serial ports, or in fact if one exists onboard. 

I proceeded to re-flash the board with FW C009-M2 Advanced firmware, this gave me console access, once in I checked that Linux is detecting a Serial Port.

-bash-3.2# dmesg | grep ttyS0
Kernel command line: rw console=ttyS0,38400
ttyS00 at 0x03f8 (irq = 4) is a 16550A
-bash-3.2#

A UART is being detected and is used by the system as a console.

Here are the memory and CPU as reported by dmesg, so plenty of resource for what I want.

Initializing CPU#0
Calibrating delay loop... 44.33 BogoMIPS
Memory: 29984k/32768k available (1418k kernel code, 2396k reserved, 337k data, 56k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
CPU:     After generic, caps: 00000000 00000000 00000000 00000000
CPU:             Common caps: 00000000 00000000 00000000 00000000
CPU: Cyrix Cx486SLC

This can only mean one thing.  Time for surgery!

Disassembly

Disassembly is very easy, two screws at the rear allow the extruded aluminium case to slide off , at least it’s solid.  Inside is a 1TB drive that I had swapped out with the original some time ago, so If all goes to plan then I’ll have plenty of storage available for the Wireless Sensor Network.

I love it when designers of hardware have fore thought to design in for future expansion, adding a second antenna is going to be simple enough, just drill out the rear cover to suit, actually the cover already as the markings on the inside for this.

Also another Spare antenna mounting hole, perfect for a reset button.

Search for the Serial Port

Prime serial port candidate CN2 (10 pin socket centre of shot) ,  The processor (top left) is an RDC 3210, a 486 equivalent.  The  datasheets (no longer available from RDC website, but found via Google) tells me that the CPU has a single onboard UART that the pin outs coincide with the rough location of the CN2 header, either it CN2 or part of the larger connecter, but I doubt it.

Continuity tests of CN2 confirm that this in indeed the serial port, some further checking and voltage measurements confirm everything I need is there. Whoot!

Adding the WidgetBoard

I moved the Wi-Fi antenna SMA across to the spare and added in an SMA pigtail to suit a 915Mhz GSM antenna that I use for my WidgetBoards.

Next wire in the Serial port to an external header

WidgetBoard trying out it’s new home with SMA pigtail connected.  Actually this is the first of my Widgetboards to use the Atmega 328P processor.

I used the third spare antenna connecter on the right for an external reset button for the WidgetBoard, may not be required, but hey, if the DTR reset does not work at least I can force the issue.

All wired up and safe and sound in a simple card surround to stop any shorts from happening.

All boxed up to see how it all all goes together, 2.4Ghz and 915Mhz antennas side by side and reset bottom right.

Next Step

The next step is to get minicom and do some further testing, along with getting a version of avrdude working from the Linux console, this will allow me re-flash the WidgetBoard locally if the need arises.

I’ve just committed my current progress on porting Contiki Operating System to the RFM12WidgetBoard to SVN.

• Serial working
• LED API implemented.
• Event timers now working.
• Added blinky example that demonstrates all of the above.

Now compiling to 5166 bytes of flash and using 387 bytes of ram.

Next step is SPI and RFM12B drivers!

I’m still alive…… Its been awhile between blog entries, unfortunately this is the busiest time of the year for me at work, the few months after the Australian financial year, projects are kicking off due to funding etc.  There is however light at the end of the tunnel and I’m hoping to get back to geeking very soon

I thought I’d let you know that a) I’m still alive, and b) what’s been happening on the development front.

In between work projects I’ve been porting the Contiki operating system to the widget as the underlying event framework for WidgetMesh.

I now have the Hello-world application up and running on the Atmega168 @10Mhz, no radio drivers or anything else for that matter just yet.  For those interested it’s been checked into SVN.  I’m learning a lot about Contiki and how it all fits in together (i.e. I know that I don’t know much at all about it)

On the hardware front the next iteration of the Widgetboard is idle, though pretty well stable as far as the design goes (might be a couple of small tweaks before boards get made).  I just need time and resources to get the next round of PCBs ordered and tested. 

Noteworthy design changes include:

• Standard smd or PTH crystal footprint, allows the use of a standard HC49 crystal of your choice.
• Lots of changes to the board supply side of things. Board voltage supply input range from 0.7V to 16VDC (probably beyond to 20VDC but just to be on the safe side…)  The core components are still powered  @ 3V
• Minor changes based from user feedback of the current board.
• A couple of optional onboard sensors to utilise the normally unused A6 and A7 analogue only ports, these can be disabled via onboard solder jumpers if these ports need to be used for something else, but has a temperature and light sensor, so the widget board can be used as a basic standalone wireless sensor.

I’ve been meaning to run off another batch of WidgetBoards and have been waiting for some processors, a month ago 40 Atmega328P processors arrived after a 5 week backorder, according to my vendor these were hard to get, hopefully supply issues will settle down after production catches up with the the initial demand for Atmega328P. 

All future widget boards will now have this processor as the default in the next batch of boards I make.

Sample parts I’ve been ordering for various future projects have been steadily rocking up and sitting in my ever growing inbox, the RFM22 arrived some time ago and I’ve not yet had time to play with them either   sigh

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:

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.

Well, back from a short break away (kid free woohoo!) and onto some widget builds.  I thought I’d document how I do my widget construction.  I actually find building SMD devices much easier than the PTH variety.

I have all my components in some neat snap together containers, this allows me to have everything at hand for the build.

[Click on images for larger size)

1) Solder paste is applied to the boards sparingly, ready for component placement

2) Components placed on each board, I usually do a board at a time. You will see x3 boards without any RF modules, these will be added at a later time depending on what band is required.

My SMD toaster oven setup.

The toaster oven is unmodified straight out of the box connected to the PID temperature controller.

PID Ramp controller with Solid State Relay output driver from E-Bay, that allows me to store up to 64 different temperature/time steps, each step can have their own PID parameters.  The ramp controller allows me to set and store my solder temperature profiles and when enabled will cycle through the temperature profile. 

The PID controller is installed in an external SCSI case I salvaged from an old external tape drive.

The thermocouple is a K-type with the shroud removed to give a fast response to temperature changes, I also have it wired to a spare PCB to give me a good indication of the PCB surface temperature in the oven

Rear of PID controller case, I’ve wired a power point directly a 10A solid state relay and fuse.  The SSR is driven by the PID output, so power is only applied when heat is required.  This allows me to use any unmodified toaster oven.

Batch ready for baking, carefully placed onto tray so no components are moved in the process.

All I do now is start the Temperature controller and let it do the rest (after closing the door) Since the Toaster oven is unmodified in any way I just turn it’s temperature knob to the max temperature and the same goes for it’s timer.  The bottom power light turns on when temperature controller is heating.

My hi-tech fuse and bootloader programmer ready for programming.  The headers give me good connections and allows for easy changeover.

Fuse and bootloader being programmed