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.