Home arrow Blog arrow Zigbee arrow Atmel AT86RF230 and AT86RF231 Review
Atmel AT86RF230 and AT86RF231 Review | Print |
Written by Akiba   
Friday, 20 June 2008

To start off the series on new 802.15.4 chip reviews, I've chosen the Atmel AT86RF230/231. The AT86RF230 and 231 are essentially the same chip, however the 231 has some extra features over that were noticeably lacking in the 230. One of the most important additions was a hardware security co-processor. They also added other nice features like antenna diversity, multiple data rates up to 2 Mbps (non-standard), random number generator, and they brought out the RX/TX switch. Since I've never done a review on the 230, let's start with some of the features of that chip. The 231 contains all of the same features as well as the above mentioned extras.

The 230/231 has all of the basic features of other chips out on the market. These include things like an SPI interface, 128-byte Rx and Tx fifos, and RSSI output. One of the nice features that they included was an energy detector which is useful for energy scans. Energy scans are used in 802.15.4 and Zigbee as part of starting a new network. You would scan the channels and choose the one with the lowest energy (least traffic) and fewest networks. Normally, you'd have to convert the RSSI into an energy detection value in software, however this is done automatically in the 230/231.

Another very convenient feature they included is Link Quality Indication (LQI). This is a statistical value of the quality of the link and can be correlated to a packet error rate. The reason why this feature is valuable is that packet error rate is used in Zigbee to calculate the path cost for each router hop. A route will be chosen based on the lowest path cost, and to calculate the cost of a link, you would need to use some type of statistical algorithm in software. Since the hardware maintains a running history of the link quality of all frames, the statistical value should (hopefully) be pretty accurate. 

 The 230/231 also automated a lot of the MAC functions. Some of the noteable automations are auto-acknowledgement and automatic re-transmission if an ACK was not received within the time limit specified in 802.15.4. Auto-ACK is a tricky feature because there's one special case where you need to treat the ACK differently than a normal acknowledgement.

802.15.4 supports a special mode of transmission called indirect transmission. This mode is good for sleepy end devices since the parent buffers the data for the end device, and waits for it to wake up. When the device wakes up, it will send a data request frame to the parent inquiring if there is any new data for it. The parent will then send an ACK with the 'frame pending' bit set if there are any frames buffered for that device. The tricky part is that in the normal case, you can just kick out an ACK for any frame you receive that requests one. However in this case, you need to check your indirect transmission queue for any frames destined for that node, and then decide on whether to set the frame pending bit based on that. The timing is pretty fast since you have less than 1 msec to make the decision and send out an ACK. Any decent implementation of Auto-ACK needs to handle this case and unfortunately, the Atmel chip doesn't seem to handle it well. To set the frame pending bit in Auto-ACK mode, you need to set a register bit. However from a software point of view, that means that you need to decode the incoming frame, check your indirect tx list, and then decide to set the register bit or not. Additionally, that means that you need to set the Auto-ACK timing to accommodate the time it requires to do all of this, however that also means that all ACKs will be sent out using the worst case timing. It kind of defeats the purpose of using Auto-ACK. So far, I think that only the CC2520 handles Auto-ACK well.
A representative from Atmel informed me that the intended usage of the Auto-ACK with the indirect transmission list is as follows:
Set the data_pending flag to true for all ACKs if any frames exist in the indirect list and return a zero length frame to any node that doesn't actually have any data pending. More details can be found in the 802.15.4 specification section 7.5.6.3.

Automatic re-transmission is an interesting feature. You normally have to retry a transfer if you send it out with an return ACK requirement and the ACK doesn’t show up before timeout. However the timeout and retry is handled in hardware. It's a cute feature, but not a very important optimization. It only saves a couple of lines of code.

One of the things you need to watch out for on the 230/231 is the Rx FIFO handling. In the CC2420/2520, the Rx FIFO will buffer as many frames as can fit inside the 128-byte Rx FIFO. However in Atmel's case, each new received frame will overwrite the old one, regardless of size. That means that it's possible that the frame will be overwritten as you're reading it out. From a hardware design point of view, it would have been better if they made it a true FIFO like Chipcon/TI's case, instead of having a new frame overwrite the old one. You can enable a feature called buffer protection which prevents incoming frames from being written to the FIFO as you're reading it, however that means it will just drop the incoming frame. I'm not sure which one is better.

As I mentioned above, the 231 differs from the 230 in that it has an integrated security processor that can handle AES 128-bit encryption. This makes it much easier to implement Zigbee applications which require security, since it would be ugly to do all the encryption and decryption inside an MCU, especially an 8-bitter. Also, it's difficult to find any real-world wireless applications that would not require security. Otherwise, it would be too easy for people to wreak havoc on your network or eavesdrop on your sensor data (would anyone really do that?). Since Zigbee seems to be popular with smart meters recently, they definitely need some heavy encryption, lest some hackers modify their reported electricity consumption. I've often thought of trying that, but I probably won't. In any case, the 231 was probably released because a chip with no encryption support will have a difficult time finding actual applications.

The 231 also supports a non-standard high data rate mode which can go up to 2 Mbps. It does this while still consuming the same amount of bandwidth as normal 802.15.4 running at 250 kbps. This is because it decreases the spreading factor which is used in spread spectrum communications to randomize (spread?) the data across the bandwidth. Thus it can increase the amount of data that it sends. This results in a loss of receiver sensitivity though, so if you're planning on using it, you should be aware of it. I can already see the streaming MP3 projects that will start because of this feature.

Antenna diversity is also supported in the 231. This means that it can support two different antennas which are located some distance apart. When a signal is received, the hardware will choose the antenna with the best reception and use that one. It's a fancy name, but that's basically what it does. It helps prevent against multi-path issues such as fading. Fading is why your cell phone bars go up and down even if you don't move the phone.

The last two new additions to the 231 are a random number generator and an external TX/RX switch. A random number generator is suprisingly useful in Zigbee. When you initialize the stack, you need to initialize many things to random values, ie: the data sequence number (DSN), network sequence number, etc… To get a true random number, you usually use a free-running timer, which is kind of a waste.

For the external TX/RX switch, this is useful for people that want to include an external RF power amp (PA) and low noise amp (LNA). These improve the transmission power and receiver sensitivity respectively. It's basically the reason why the Digi Pro can get up to 1 km of range in line-of-sight.

Whew! I guess that's about it for the AT86RF230/231. Join me next time for a review of some of the other new chips that recently came out.

Hits: 34277
Trackback(0)
Comments (13)Add Comment
...
written by Nithin Prakash, August 26, 2008
Hello Akiba

My name is Nithin from bangalore, India. I have a few query regarding RF230 and RF231. Please see below

Is CC2591(RF Front end from TI) compatible with RF230. I know that it can be used with RF231 since it has a external TX/RX switch, but can it used with RF230. Can u suggest any other RF Front End IC`s that can be used with RF230/RF231. Thank you

report abuse
vote down
vote up
Votes: +0
...
written by Akiba, August 26, 2008
The CC2591 is basically a combined RF amp, LNA (Low Noise Amp a.k.a. Rx Amp), TxRx Switch, and Balun. I don't know of any other interface ICs that are targeting 802.15.4, however they don't need to be protocol specific. They just need to be able to amplify the 2.4 GHz signals. Thus you shouldn't limit yourself to 802.15.4. You may want to see if the same type of devices exist for 802.11b/g or Bluetooth. Both of those are also 2.4 GHz. 802.11b/g uses DSSS (Direct Sequence Spread Spectrum) and Bluetooth uses FHSS (Frequency Hopping Spread Spectrum) however the key point is that the amps perform efficiently at 2.4 GHz. Otherwise, you can do it the old fashioned way which is to use discrete RF and Low Noise Amps, TXRX switch, and balun. Thats the way that most of the high power 802.15.4 modules are designed (XBee Pro).

In regards to the AT86RF230, you may want to reconsider in favor of the AT86RF231 since there is no security engine on the 230. That means that if you want to do any real Zigbee or Zigbee Pro apps, you will be eating a lot of CPU cycles handling the encryption in software.

Just my 2 cents...
report abuse
vote down
vote up
Votes: +0
...
written by Yifeng, September 30, 2008
Regarding security module in Atmel's chip, the most popular CCM modes are not supported. Both 15.4 and ZigBee defines CTR, CBC and CCM modes for AES. CCM applies both authentication and encryption to provide the most thorough coverage in security, thus is the most popular mode. Lack of CCM mode in the hardware means that firmware must load the data into the FIFO and apply AES engine multiple times, depends on the length of the packet. The formula of total AES engine applied is ((payloadlen headerlen)/16 1) (payloadlen/16 1), then read them back and form the final packet before send it to FIFO again. To a firmware engineer, this almost the same as running the security engine in the firmware. smilies/sad.gif
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, September 30, 2008
Thanks for the heads up. I'm going to be using the Atmel platform as the first target platform so I'll keep my eye out for this when I implement the security. What do you think about the security engines on TI, Ember, or Microchip?
report abuse
vote down
vote up
Votes: +0
...
written by Yifeng Yang, October 01, 2008
Chipcon radio does support all security modes in MAC layer. However, there is no security provided in upper layer. Thus for ZigBee, you may have to use the stand-alone AES engine to do all security operation, just like I describe in the earlier message. Ember is a re-branded Chipcon radio, so my assumption is that they perform very similar in this case.

Microchip radio actually do upper encryption, meaning that you can apply any of the 7 security modes in the upper layers and you only need to apply those security operation once for each packet. This is a feature that beats both TI and Ember.

That has been said, Microchip radio also has a weak point: it does not provide a stand alone AES engine interface in the radio. You are perfectly fine if you stay with ZigBee residential. Once you decide to go to ZigBee PRO, the SKKE procedure requires a hash function that will call AES engine directly. For Microchip radio, this AES engine will have to be implemented in the firmware, which is about 4KB programming space and there is MCU speed requirement.

For summary, when encrypting/decrypting data, the Microchip radio has advantage because of its upper cipher engine; when establish link key in ZigBee PRO, Atmel/Ember/TI have advantage because of stand-alone AES engine in radio.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, October 01, 2008
Thanks! Its useful to know this since I'll be implementing security soon.
report abuse
vote down
vote up
Votes: +0
Open source prototyping
written by Anton, October 02, 2008
Hi,
please, do you think it makes sense to build an open and low-cost board similar to Arduino around something like ATmega64RZAV? The most important consideration is, I believe, price since one could need quite a lot of them. Sorry if this sounds stupid, I just recently got interested in all this Wireless sensor networks.
report abuse
vote down
vote up
Votes: +1
...
written by Akiba, October 02, 2008
It always makes sense to build a board, especially if you can keep the schematics open like the Arduino. Where Arduino really succeeded is that it also developed the software to run the peripherals and different applications and kept all of that open. On top of that, its cheap.

Regarding the ATMega64RZAV, one issue it will have is that the radio is the AT86RF230. That radio does not have encryption. The AT86RF231 has an encryption engine and since its part of my target platform, I will be investigating the security implementation. As you can see in one of the posts above, there have been some suspicions raised about it so I want to get to the bottom of that.
report abuse
vote down
vote up
Votes: +0
...
written by Anton, October 02, 2008
Ok, understood. Thanks for the reply!
report abuse
vote down
vote up
Votes: +0
...
written by Yifeng Yang, October 03, 2008
Today's news: Microchip and ON Semiconductor purposed to purchase Atmel. Atmel's RF business will be sold to ON Semiconductor.
report abuse
vote down
vote up
Votes: -1
...
written by Akiba, October 03, 2008
That would be horrible if the deal went through. Losing the AVR would be truly a sad thing.
report abuse
vote down
vote up
Votes: +0
new to zigbee
written by vikas, May 04, 2009
Please let me know if you have any comparison information for below 2 solutions:
Requirement is to have the high output power of 20dB with low tx output current.

The solutions considered are:
TI -> MSP430 CC2520 CC2591. The only issue is of high TX current of 120mA at 20dB.
ATMEL -> Zigbit AMP module ATZB-A24-UFL (Atmeg1281 AT86RF230 External SW PA LNA). This seems to have better power rating (50mA at 20dB Tx output pwr).

report abuse
vote down
vote up
Votes: +0
...
written by Akiba, May 06, 2009
I checked the specs for both the Zigbit AMP and the CC2591. I was suprised there was such a difference in power consumption and I can't exactly say why. I would probably question the Zigbit specs a bit though because even though they say 50 mA at 20 dB, it doesn't match up well with other vendors. 20 dB is actually 100 mW transmit power which should already be close to 50 mA of current driving the antenna even if the front end PA has a high efficiency. If you count the microcontroller, radio, supporting circuitry, and front end PA/LNA, I think a 50 mA budget would be hard to achieve.

Also, if you check the XBee Pro which puts out 17 dB from the radio, it has a current consumption of 295 mA at full power. The CC2591 spec seems more in line with this number. I guess the only real way to tell is to measure both for youself though.
report abuse
vote down
vote up
Votes: +0

Write comment

busy
 

Discuss (1 posts)
Nick
Atmel AT86RF230 and AT86RF231 Review
May 11 2011 03:51:51
This thread discusses the Content article: Atmel AT86RF230 and AT86RF231 Review

Yes. I do agree with that

votes(+10)
#2909


Discuss...
< Prev   Next >