|
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.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
Show/Hide comment form
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