SmartAlpha 433 MHz (and 866 MHz) RF Transceiver Module Notes

This entry is partly just a space for me to make notes on the SmartAlpha module from RF Solutions. If you want to contact me on any of the information contained here, please email kevin at susa dot net.

Please note that since writing this, the datasheet has changed on these devices and, at first glance, some of the anomalies I’ve seen look to have been addressed. Please also note that my observations were initially done by just running code and watching display-text and LEDs, and though I’ve since used an analyser to verify my understanding, I’ve not been particularly methodical in my approach.

If you’re in the market for a UART based RF transceiver and are considering using a SmartAlpha, I’d recommend you just go ahead and buy a couple to try out – they’re only £9 each from RS-Components, £13 from Maplin or RF-Solutions (much cheaper in larger volumes).

They’re not without their shortcomings (though some of these may actually be my shortcomings!), but they do a lot of the leg-work and save you a bunch of pins. I’ve had them reliably transmit and receive over a distance of 350 meters with breadboard wire and satellite coax for antennas, and with housing in between – not too bad!

What is SmartAlpha?

The SmartAlpha module is an RF Transceiver module produced by RF Solutions Ltd in the United Kingdom. It’s essentially a hybrid module combining a PIC16F886 based UART interface with an RFM12b RF Transceiver module by HopeRF, allowing you to drive the device with as few as 3 pins on your microcontroller (RX, TX, and CTS), and a relatively small amount of code. The SmartAlpha also exposes RSSI (digital, triggered at a predefined threshold), and has a power-down pin allowing you to put the device into low power mode.

The module implements an addressing scheme, whereby you can define the module’s address and a destination address so that only packets intended for a specified destination will get through to the UART. This means that it should be relatively easy to implement networks of RF nodes without too much protocol overhead in your microcontroller.

Configuration is done using software, whereby sending ‘+++’ puts the device in configuration mode, and sending ‘—‘ returns the device to data mode. Any data sent while in configuration mode updates the configuration table. Partial configuration data can be sent.

How well does SmartAlpha work?

Quite well so far, but not without issues, some of which I feel could have been avoided with a little more thought in design and implementation. My biggest concern with the SmartAlpha is the lack of decent documentation. Most of the device’s behaviour simply has to be observed or inferred in order to understand it. At this point in time, I do have a working system, but I’m not happy that I understand the interactions nearly as well as I’d like to. If a vendor goes to the trouble of designing and building a hybrid module, creating custom firmware for it, it seems daft not to tell customers how to actually use it, in particular the limits in which it operates.

The kind of questions that I wanted definitive answers to are: –

What events cause CTS to get taken high? e.g. Can CTS be raised while I’m transmitting to the modem?

How can I avoid RF data inferering with configuration data?

How can I be certain that the device has returned to data mode?

Are there any limitations on configuration write operations? (e.g. EEPROM tolerance)

How soon after sending a packet is the device ready to receive a response?

Observations and Notes (in no particular order)

I spent a lot of time trying to work out where spurious data was coming from, only to discover that a USB data pin on my PIC18F2550, which is directly beside the UART’s TX pin, was picking up interference when USB was active. After filtering out the noise, things started to make sense again, and my communications returned to being nice and predictable. The problem was exacerbated by using a breadboard, but it was still present to a lesser degree on a PCB.

RF data can be returned even while in configuration mode, which means that RF data can interfere with your modem configuration code. To investigate, I had three transmitters sending regular packets. The receiver was put into configuration mode and a short-packet send every 500ms. The modem should respond to a short packet by returning the current device configuration, which it did. However, periodically, a packet from one of the transmitters would appear on the output. This is seemingly anomalous behaviour – when in configuration mode, nothing but configuration data should appear on the UART, otherwise it’s impossible to differentiate between a packet sent over RF and a configuration response (other than to look for a packet that ‘kind of looks like’ a data packet or a configuration response – hardly rigorous).

When configuring the device, it may help to flush the module’s receive buffers immediately before sending ‘+++’, to minimise the risk of a data packet being returned in response to either your ‘+++’ command or your configuration data.

After sending configuration data, compare the returned configuration with that sent to ensure it has been sent correctly. Be prepared to retry if the sent and received configuration data doesn’t match.

I have had one instance, while doing continuous-running tests where a configuration value changed without my setting it – in this instance it was just the RSSI threshold byte, but I’m not confident that this couldn’t have happened to any configuration byte – had the operating frequency changed for example, the unit would no longer be reachable. To be clear, this issue was seen in a system where the receiver gets configured once at startup, and then only ever receives 4-byte (destination address) configurations thereafter. In this instance, after around 7500 packets I spotted that my RSSI indicator was flashing constantly. When I rebooted and queried the configuration state, the entire configuration data was exactly as I’d have expected, except the RSSI threshold byte, which had mysteriously become ‘0’ when it was initially configured with ‘2’. Corruption by my code during configuration can be ruled out, since the values on either side of the RSSI threshold value were exactly as expected. I’m quite certain that this happened inside SmartAlpha, perhaps a bug in the firmware.

To avoid possible configuration problems (which could render a unit useless in the field), I’ve decided to hold a shadow configuration space in RAM, and to only ever send configurations from this memory. The configuration response data will be compared, after every reconfiguration, with the version in RAM, and if it deviates at all, then a full configuration will get done. This also solves the problem of EEPROM write-endurance, since any time an EEPROM write caused neighbouring cells to fade, my code will perform a full configuration. However, for both these benefits, this is really 15 bytes of RAM wasted solving issues that should have been dealt with by the firmware.

RTS only really puts the module’s UART on hold, so its usefulness seems quite limited. I’d have much rather seen it implemented in a way that halts RF-packet receive operations, but leaves the module willing to accept transmit data and to return configuration packets on the UART regardless of RTS. This is reasonable, since transmit and configuration operations are host-initiated anyway – I already know when I can and can’t send and receive data with host-initiated operations!

An alternative to this could be to make the RTS pin an implied ‘configuration-mode’ pin. This would get around the problem of not knowing (for sure) that the device has left configuration mode until a packet is sent.

The 10ms delay to end a transmit packet (either short-packet data or short-config data) seems to be more reliable than transitioning RTS. I have some code that, when I do RTS=1; RTS=0;, even with a few NOPs in between, it fails to send the ‘—‘ (exit config mode) packet. Adding a 10ms delay makes it work. However, I have also seen situations where transitioning RTS does seem to work. I need to revisit this…

There seems no way to positively confirm that the unit has left configuration mode, other than to send a short packet (< 4 byes) and wait for silence. However, this means that the data will be sent over RF, so it creates unneccessary noise. I’d have much preferred that the module returned a configuration packet in response to a ‘—‘ sequence, or even just echoed back ‘OK’. Anything would be better than silently leaving configuration mode.

One technique to avoid leaving the device in configuration mode is to wait for a response from the modem after sending ‘—‘. If you get a response soon after, then there’s a good chance that the device is still in configuration mode. You can’t be certain, without analysing the response, so it may still possible to throw away a good packet of data, but it prevents you misconfiguring the device with your next packet of data.

I managed to kill one of my modules because I sent packet data to the module while it was still in configuration mode. The effectively random data sent was written to the device’s configuration EEPROM, but the firmware seemed to have a problem dealing with it. The result – a dead and entirely unresponsive SmartAlpha. Thankfully I was able to figure out that the three unused pins could be used to read/write the PIC chip, and so I was able to take the EEPROM data from a working module and flash it onto the dead one. Sure enough, it came right back to life.

The datasheet states that short data-packets will be expanded to the configured packet size before being sent over RF. This doesn’t appear to be true. When I send a 1-byte packet from a device that’s configured with a 15-byte packet size, the receiving device only receives 1 byte of data, not 15 bytes. I’d have expected the 1 byte that I sent, along with 14 padding (zero) bytes as per the documentation.

Given that the SmartAlpha works in data packets rather than streams, it would be more useful to receive the data in packets rather than in a stream. This would allow short RF packets to be sent, but full-length packets to be received by my code via the UART (e.g. padded).

If you’re implementing one to many communications (e.g. acknowledgement from a central receiver), then consider that writing partial EEPROM configuration data on the SmartAlpha will deplete the charge in other parts of the EEPROM. The Microchip datasheets suggest that the EEPROM should be refreshed after, at most, 1 million writes. Therefore, if your device is intended to run continuously over long periods of time, consider how many configuration changes (e.g. target address changes) you will be performing, and send a full configuration before it reaches this limit. Otherwise, you might find that the EEPROM returns invalid data on the next restart. It could even return invalid values during operation, depending on whether or not the EEPROM is shadowed by RAM (I’d expect it to be, since EEPROM reads are very slow and would consume huge amounts of time if drawn upon on every transaction).

If you respond too quickly to a packet, then it’s likely that it will not be received by the sending device. Possibly due to RF collision since, looking at RSSI, I can see that it’s still high on the sending device by the time I’m ready to respond. A delay of 10ms between receiving a packet and sending the response has fixed this problem, though because 5ms was found to be too short, I’ll probably wait 20ms to be sure. Hardly scientific, I know, but in the absence of more detailed information, it’s down to guess work. This issue may be more about the underlying RFM12b than the SmartAlpha’s design.

I only have C code for a PIC microcontroller, but the process should be similar regardless of language. This code was written for a previous version of the module’s firmware and there have been changes (hopefully to fix the senseless use of handshaking signals).

In other words, some of this may not be relevant or accurate for the newer firmware. I’ve left out some of the self-explanatory functions.

Kevin: Hi, there’s a frame protocol to send data thru this module? I’m trying to use some of these, I’ve already set’em up, but, at the time I send data, just the rx led flash, but the tx, so i’m assuming that its not transmitting… any advice???

From an application’s point of view, there’s no frame protocol to consider. It’s enough to write some bytes on the UART and the module should send. The RSSI indicator can give you some idea of data being transmitted, make sure the threshold isn’t too high. A low data-rate might help for testing, since the signal indicator will flash longer, and the range/accuracy will be better.

The questions I’d ask myself initially are 1) am I configuring correctly (e.g. config data is being returned and is correct)? 2) have I exited configuration-mode (‘—‘) prior to sending? 3) am I using UART handshaking signals (RTS/CTS) correctly?

For my project I am using this smartalpha RF and I am trying to configure it with a PIC microcontroller 18F4455. Is this code above good to configure the RF with the PIC and if yes can you explain how please. I already connected the RF with the Smartalpha Setup Utility so far.

The code above was taken from a PIC18F2553 project. The addition of an LCD display helped with debugging on the PIC. I believe that the handshaking implementation changed in a later revision to the module that I used. It may be that you have to re-assess this, and implement properly for your own module revision (e.g. use both RTS and CTS).

If this is an open hardware/hobby project, I may be able to help more if you can post a link to your schematic and source code, though it’s a while since I looked at any of this stuff.

Hi Kevin,
I have purchased the smartalpha 868Mhz module and the evaluation board. I was hoping having bought the evaluation board it would make it relatively easy for me to interface my windows pc with the module. My initial aim is simple, just to be able to make the module transmit and receive. I downloaded the software utility which RF Solutions supply. This allows me to configure the baud rate, frequency etc of the module, but that is as far as I’ve got. I have sent a number of emails to RF Solutions re how do I get the unit to receive or transmit but the emails I receive assume a knowledge that I don’t have. I was hoping that I could use something like Hyperterminal to send commands to it via USB to get it to transmit and receive. I guess my question to you is, is there an easy way to talk to the unit using a piece of existing windows software, or should I give up now before I tear all my hair out?

I’ve never driven one of these modules from anything other than a microcontroller, but if you can configure the device from your PC then you’re mostly there. The data-packet is binary format, and the bytes must be received more quickly than you can type, so you’ll need to write some code to open the serial port and read/write the data.

This is old-style serial stuff, so there will be lots of examples on the net for you to hack around. I’d start by working out how to send ‘+++’ to the module and verify that you get a sensible packet of bytes in response – everything thereafter will be more of the same.

I suppose it could be used via a serial terminal emulator like Hyperterminal, using device addresses that can be generated using ASCII, and pasting from the clipboard perhaps – it wouldn’t be very practical though.

Hi Kevin & Nigel,
I have been struggling with getting the Smartalpha modules to run reliably.
Nigel,
A couple of comments regarding the Eval module and Setup utility that may help.
a) I am using a terminal program called SimpleTerm Gold (www.ptronix.com) on XP via USB. With SimpleTerm, if I type characters I can see the Tx LED flash (faintly), but I haven’t tried to receive the RF to see if the typed characters are correct. However, I do have a separate SmartAplha on a control panel, from which I am transmitting a string of characters (24bytes) at 75ms intervals, and these characters are received and displayed correctly on SimpleTerm. Hopefully this will encourage you that your idea of using the eval module as one end should work OK! Perhap shy away from Hyperterm (I understand certainly in the early days it was flaky so that’s why I went to SimpleTerm).
b) It sound like you have got the Setup Utility working, but I found the datasheet for the SmartAlpha, that I have, is misleding regarding the jumpers. I generally run at 9600Baud, – to do this I had to fit the jumper 2 (to gnd pin 13) – whereas the datasheet indicates to leave it open.
c) With the Setup Utility, I have no idea what the Tx Packet Size parameter is for! It is set to a default of 17, and if I change it, the modules stop working. I am sending 24bytes and expected to set it to 24, but that didn’t work! Also I tried setting the Rx Packet Size, and the utility just ignores it and returns ???. Same with the Rf Tx Speed. So basically, I can get it to work (mostly) with default settings only.

As for my current challenge – I have a basic point-to-point link, one end is a portable control panel (mentioned above), transmitting to a display. My problem is that the link works OK initially, but as I take the control panel out of range, the receiver locks up. It appears to be continually receiving, and I cannot get out of it without cycling power to the receiver.
Kevin, I was interested in your comment at the top about noise, – “After filtering out the noise, things started to make sense again” – I figure this may be relevent to me. Do you have any suggestions on how to filter the noise? Was this on the aerial, or do I have to look at my adjacent components?
Thanks & Regards, Dennis

Thanks for sharing. The TX Packet Size parameter is, I think, to allow you to send packets immediately on the last byte, rather than waiting for the timeout (was it 20ms? I forget) until RF transmission begins.

The filtering of noise was probably needed due to poor circuit design on my part – I added a couple of small smoothing capacitors to the USB lines, as I recall. Note that I was using a SmartAlpha with a PIC chip that was also acting as a USB device, so the USB lines I refer to have nothing to do with any USB to RS-232 cable that might be used to access a SmartAlpha via the evaluation board.

I’ve never used the setup utility, but I have successfully manipulated all parameters through the UART directly (e.g. TTL serial from a PIC chip).

The problem with the receiver locking up sounds to me to be related to the client software rather than the SmartAlpha – the interface is, after all, simply a Tx/Rx UART with two hardware handshaking lines (which I believe were incorrectly implemented on early SmartAlpha versions, but fixed a couple of years ago). It’s certainly not impossible that the module is truly locking up, but this isn’t the first place I’d look.

The SmartAlpha Tranceiver’s “UART” is more than just a UART, it’s a PIC16F886 micro-controller which interfaces to the smaller transceiver module piggybacked onto the SmartAlpha module.

Unfortunately, in our experience as well, the SmartAlpha Tranceivers do indeed lock up sometimes, when receiving a weak RF signal. The lock-up takes the form of the RFRX output (pin 2) going permanently low (the unit appears to be continually receiving) and the CTS line (pin 16) going permanently high. The module is then completely unresponsive until power is cycled.

I emailed Dennis your question, and your email address. btw, I corrected my wording on the previous comment regarding the UART that I think you’re referring to. I do wonder though, whether the PIC just transports data between UART/SPI, or rather RF Solutions implement further encoding (Manchester?) using the PIC, perhaps directly modulating the FSK pin/sampling DATA. Not sure if the pin connections tell anything – probably requires watching the SPI traffic for config/absence of FIFO for clues.

Hi Paul,
I guess the short answer is no – I didn’t get it working! I basically abandoned it, and implemented the project using Zigbee modules from Digi (www.digi.com). These modules worked a treat straight out of the box for a point to point wireless serial, good range, but more expensive than SmartAlpha. The worst aspect is that they are 2mm pin spacing. My next project is a multipoint application, so will use more of their features.

I recall considering an MRF24J40 based transceiver when I was originally evaluating RF modules. I believe it supports a Zigbee stack, and on price it’s on cheaper than the SmartAlpha. As usual, it’s meticulously documented by Microchip.

Kevin, you may be right about transporting data – although I guess the PIC is also doing the clever stuff to do with the module addressing, which the on-board Alpha transceiver module doesn’t do. When the SmartAlpha modules lock up, though, they don’t respond to RF or to serial communications (or to anything other than a power cycle), which points to the culprit being the PIC software.

RF Solutions are being remarkably tight-lipped and unhelpful over all this. One of their technicians admitted to being able to get the modules to lock up, but now they are just ignoring my emails and there’s no sign of a solution. I’ve also tried reading the program from the PIC but unfortunately the code protection bit is set, so there’s no chance of reverse engineering to fix the problem.

It’s frustrating as we are part way through a product trial using 200 of these modules with another 600 planned. But for an application where the RF modules are moving in and out of range, which is the case for us, it’s become clear that the SmartAlpha transceivers in their current state are quite useless. And with no interest from RF Solutions, we too are now looking to cut our losses and source an alternate part.

To add to the useful info in this post and the comments (thanks all!), we too are experiencing the lock-up problem, typically triggered by operating the modules at the limit of their range. Our solution will be to either switch to another module, or add a way to detect the lockup and automatically power-cycle the module.

Aslo, for anyone who can’t see references to the RSSI configuration in the datasheet (as I couldn’t), it’s because it only appears in older versions of the datasheet (which I found on the net). Specifically, in the older datasheet the RX and TX LED outputs are labelled as RSSI and RFU respectively.

Additionally, the later datasheet (DSSMARTALPHA-5) only lists 12 configuration bytes, whereas older datasheets (DSSSMARTALPHA-2e) list 15 – it appears the TX and RX packet size and RSSI threshold settings have been removed, with ‘RF transmission speed’ now being at office 11 instead of 14. This implies the configuration packet for older modules is different to later modules.