tag:blogger.com,1999:blog-55594480748239505322024-03-08T12:21:28.293-06:00Maniacal BitsTechnology (C, C++, Python, PostgreSQL, and others), DIY projects, tech culture, aviation, and various ramblings.Anonymoushttp://www.blogger.com/profile/14244220623475709164noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-5559448074823950532.post-80476470377552732002013-04-16T13:21:00.001-05:002013-04-16T13:29:28.323-05:00RF24 Performance Improvement w/SPI<h3>
The Up Side </h3>
The RF24 (nrf24l01, nrf24l01p, nrf24l01+) radios use the SPI protocol to communicate with its master device. The speed at which the devices communicate is controlled by the master's clock speed. Here, the Arduino is the master device. Accordingly, we can control the Arduino's SPI bus speed. On the Arduino, this clock speed is set by means of a divisor based on the speed on the CPU. For a standard Arduino, the CPU runs at 16Mhz.<br />
<br />
To reduce the chance of communication errors, a compromise was made in the RF24 driver to not run at maximum bus speed. By default of the driver, the divisor value is SPI_CLOCK_DIV4. This divides the 16Mhz clock by 4. Which drives the SPI bus at (16/4) 4Mhz.<br />
<br />
To further improve performance, it is possible to use a divisor of 2 (SPI_CLOCK_DIV2), allowing for an 8Mhz SPI bus speed. That's twice the performance of the default setting. This translates into half the latency for SPI bus communication. If you're pinched for maximum performance, this may well be a change worthy of consideration.<br />
<br />
To make this change, look at RF24.cpp. Find the line containing "SPI_CLOCK_DIV4". Change that value to one of the other supported constants to adjust the SPI bus speed accordingly. Just remember, its a divisor, so the larger the number, the slower the SPI bus speed. Inversely the lower the number, the higher SPI bus speed.<br />
<br />
<h3>
The Down Side</h3>
There are down sides to running at faster speeds. And this is why a lower value was picked for a default. At faster speeds noise becomes much more noticeable and communication between devices becomes more easily corrupted. Corrupted communications means packet loss, an increase in communication errors, and/or corrupted packets at the receiving end of things. This is important because, should a packet become corrupted during SPI transfer, it will be delivered in its corrupted form at the receiving radio. In spite of corruption, it will still pass a CRC check because it was received exactly as was transmitted - corrupted. That's not to say these things will happen. But they can happen. So caution is advised.<br />
<br />
For breadboard use, when jumper leads are long and noise is likely, I strongly encourage you to maintain a slower SPI bus speed of 4Mhz. But, once you're ready for production use, where you have everything connected properly with decoupling capacitors and short leads, a clock divisor of 2 (SPI_CLOCK_DIV2), providing for an (16/2) 8Mhz SPI bus speed, may well give your performance a tiny, extra boost.<br />
<br />
<br />
<h3>
Customization</h3>
As happens with many Arduino projects, you may find you've simplified things by converting to a simple AVR project. Many users who do this deviate from the 16Mhz clock speed to something slower or faster, as dictated for the given project. As such, if you find you've increased your clock speed to 20Mhz or even decreased to 1Mhz, don't forget you can tweak these settings as needed. Always remember, SPI bus speed is determined by the speed of your CPU. If you change the speed of your CPU, you might re-evaluate your SPI bus divisor.<br />
<br />
<h3>
History & Summary</h3>
When the original SPI bus speed was selected in
Maniacbug's code, I did observe errors when running at 8Mhz on a
breadboard. Infrequent yet present. This is why I picked a 4Mhz speed as a default value. That,
however, doesn't mean you can't try faster.<br />
<br />
Be mindful of your decision should
you decide to run at a faster SPI bus speed. Use leads as short as possible. Use decoupling capacitors as close to the radio as possible. If you're unsure, leave it where its at. Worst case, you now know you have some options to squeak every last bit of performance out of your project.<br />
<br />Anonymoushttp://www.blogger.com/profile/14244220623475709164noreply@blogger.com3tag:blogger.com,1999:blog-5559448074823950532.post-80047109745337736382013-04-08T08:51:00.002-05:002013-04-08T08:52:30.827-05:00Detour II: A USB nRF24L01 Radio Modem<i>Article is currently incomplete and unfinished. Significant progress has been made
on the firmware. Its tight on flash, needless to say. The massive bloat
of Arduino libraries >= 1.0 makes Arduino >= 1.0 completely
useless for development. As such, I've been forced to continue
development with Arduino 022 libraries. Likely I'll wind up with some
native AVR code, bypassing the Arduino libraries, simply to save space
and increase efficiency. But more to come...</i><br />
<br />
<span style="font-size: large;"><b>Creation Of A Detour </b></span><br />
Now that I've decided to focus on nRF24L01 based radios and the driver is fairly feature complete, its time to look at a computer interface for these wonderful radios.<br />
<br />
Having an easy to use computer interface for these radios will go a long way toward both making them more accessible as well as make it easier to debug and test application develop. Given the ease of development and inexpensive cost, I expect everyone using these wonderful radio modules will soon have a USB Radio Modem.<br />
<br />
The intention is to create a small footprint radio modem which plugs directly into a USB port. Once connected, the modem looks like any other RS232 serial port on the computer. In order to maintain a small footprint, most Arduino solutions are simply too large a bulky. Not to mention their power draw is generally too high because of all the extra components on board. As such, we'll not be using an Arduino for this portion of the build. Rather, we are directly using an AVR uC plus a USB interface and our nRF24 radio module.<br />
<br />
<span style="font-size: large;"><b>The Microcontroller</b></span><br />
To find a uC for our project, we need to look one which has enough flash and enough pins to satisfy our physical and software requirements. After some modest testing, I estimated 8K flash is likely to be the minimum requirement for our software footprint.<br />
<br />
Next we need to estimate the number of physical pins required for our project. We know we want at least RX, TX, RF24 IRQ, DTR, CTS, DCD, SS, MOSI, MISO, SCK, and LEDs on RX, TX, Power, and/or either an operational mode or DTR state. We know we want at least one hardware a(s)art on the uC. That makes for a minimum signal pin count of 14-I/O pins. When we add GND, power, reset, XTALx2, we have a minimal physical pin count of 19 pins. We also know we want to run at least 16Mhz because of the desired data rate of at least 1Mbps.<br />
<br />
This means our minimal requirements are 8K flash and at least 19 pins. After some searching, it looks like the ATmega8-16PU will fit out requirements, including a hardware USART port; providing for RX/TX. But, flash and memory space is tight.<br />
<br />
Since estimates indicate we're already tight on flash space, we know we won't have room for an Arduino bootloader. Basically we're looking at a AVR on strip or proto board, which means an inexpensive USBASP interface (or other) is also required for programming. Visiting ebay indicates these can be had very inexpensively for between $2.50 and $5.00. Given this purchase allows us to save so much space and opens the door for so many additional projects, its easily money well spent. I bought mine on <a href="http://stores.ebay.com/hnbfashions" target="_blank">ebay for $3.99, delivered to the door</a>. That's hard to argue with considering its built around an ATmega8L, a 12Mhz crystal, and several LEDs. Plus it comes with the interface ribbon cable.<br />
<br />
<span style="font-size: large;"><b>USB Interface</b></span><br />
There are several different ways to create this project. One way is to use an AVR uC to directly drive the USB interface via one of several software based AVR-USB libraries. This is fairly inexpensive with a reasonably low component count. Cost for this project is likely to be roughly three to five dollars including the uC. From a frugal perspective it seems like a real win. The down side of the approach is that it requires some very non-Arduino programming which can be rather involved and complex, imposes significant processing overhead and consumes roughly 1.5K of flash of the uC. With the extra software footprint, I don't believe everything will fit on an ATmega8, would would increase the cost of this solution. Also, the associated software skill level is very non-Arduino friendly. This just doesn't sound like a good beginner's path. As such, I don't believe a software USB solution will work so long as an ATMega8 is the target.<br />
<br />
An alternate path is to look at USB serial TTL interfaces readily available. Given we want this to look like a logical <a href="http://en.wikipedia.org/wiki/Rs232" target="_blank">RS232</a> serial port and some plans directly depend on making use of some of RS232's signals, we can go shopping on ebay. Technically what we're shopping for are not RS232 ports. Just the same, we do want an interface which provides many of the logical signalling convention.<br />
<br />
After shopping for various USB serial TTL interfaces, I quickly focused on the CP2102 variants. More specifically, I found some inexpensive CP2102 based boards which plug directly into a USB port and provide regulated 5v, 3.3v, RX, TX, GND, and CP2102 reset, all broken out to 90-degree pins. Also found are six additional RS232 signals (DTR, DSR, RTS, CTS, DCD, RI), plus two USB suspend signal lines (SPD, SPD/), broken out to through hole solder pads. I bought from <a href="http://stores.ebay.com/hittimestore" target="_blank">hittime_hk on ebay</a>. They were $2.88USD each, including shipping to the door. They look like the following and even come with a small, 5-pin ribbon cable.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-bzPQ3hHwyww/T0KJbEb3b4I/AAAAAAAABXU/K_oZxNw2oEw/s1600/IMG_20120220_115002.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="158" src="http://3.bp.blogspot.com/-bzPQ3hHwyww/T0KJbEb3b4I/AAAAAAAABXU/K_oZxNw2oEw/s320/IMG_20120220_115002.jpg" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-v0MR-01XSyk/T0KJb9YjCJI/AAAAAAAABXY/vtKVgg75vr4/s1600/IMG_20120220_115037.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="112" src="http://1.bp.blogspot.com/-v0MR-01XSyk/T0KJb9YjCJI/AAAAAAAABXY/vtKVgg75vr4/s320/IMG_20120220_115037.jpg" width="320" /></a></div>
<br />
<span style="font-size: large;"><b>The Plan: Pulling It Together</b></span><br />
Okay, the plan is to use a CP2102 USB TTL interface board to provide power, ground, and various RS232 logical signals to my ATmega8-16PU microcontroller. The uC in turn will be connected to the nRF24L01(P), as several LEDs, a 16MHz crystal, and several capacitors. The RS232 TTL signals will also be connected to the uC. The Atmega8 is to be programmed via an USBASP interface and <a href="http://www.nongnu.org/avrdude/" target="_blank">AVRdude</a>.<br />
<br />
The highest baud rate supported by the CP2102 is 1Mbps. According to the ATmega8 data sheet (page 153), when clocked at 16MHz, it supports an asynchronous 1Mbps data rate with zero errors. This makes it a perfect baud rate match. The catch is, out of the box, the CP2102 doesn't support 1Mbps without creating a baud rate alias. For this, we'll need to either use Silab's CP2102 software to create a baud rate alias or use the cp210x python utility available on Source Forge. After exploring this more, it turns out the python utilities does not support baud rate alias table updates. I've done some work to add this, but its currently a work in progress. So for now, its limited to 115,200 baud.<br />
<br />
To allow for proper baud rates, the uC will be statically configured for 1,000,000 baud. On the computer, we will open the serial port at a baud rate of 230,400, which the CP2102 will alias to 1,000,000 Mbps. We pick this baud rate to alias because it provides an error of 3.5% when running the ATmega8 at 16Mhz. As such, its otherwise a poor data rate to use. Furthermore, 115,200 works well so worst case we'll keep that as our fall back and goto data rate until we can get the aliases programmed on the CP2102. Honestly, I'm not sure 16Mhz on the ATMega8 even provides enough headroom to cleanly communicate at 1,000,000 baud.<br />
<br />
Since we're running the ATmega8 at 16Mhz, we'll be running this off of the 5v line provided from the CP2102 board.<br />
<br />
<span style="font-size: large;"><b>RF'n Around</b></span><br />
The nRF24L01 module is connected via a <a href="http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus" target="_blank">SPI interface</a> and controlled via the RF24 library. By default, the RF24 library uses a clock divider of 4, which means the SPI interface, given a 16MHz crystal on the ATmega8, will run at 4Mhz. Since the fastest RF data supported by the module is 2Mbs, and our CP2102/AVR interface is limited at 1Mbps, this is plenty fast, even after accounting for all the extra SPI bus traffic used to obtain and configure state from the radio module.<br />
<br />
To connect the radio, I'm using standard 0.1" headers, whereby the radio module will simply plug in. This allows for different radio modules to be interchangeably used without additional work. So please, make sure your pin-outs match those used by this project.<br />
<br />
Its very important to remember the nRF24 modules require 3.3v and should never be connected to a 5v source. Since the CP2102 TTL module provides a nice 3.3v source, its a match made in heaven. Even better, the nRF24L01 is 5v TTL tolerant, which means, while the module itself must be powered at 3.3v, we can directly connect the data lines from our uC to the nRF24 module without any additional components.<br />
<br />
<b><span style="font-size: large;">Sleep'n Time</span></b><br />
The last part of the puzzle is to make use of the CP2102's USB suspend lines. Most computers dramatically cut power to USB ports when they suspend. To be USB and battery friendly, we'll do the same thing. By monitoring at least one of these signals on our uC, we can both power down the nRF24L01(P) as well as put the uC into a sleep mode, allowing for significant power savings. The end result is we'll be very USB and laptop friendly.<br />
<br />
<span style="font-size: large;"><b>The Modem</b></span><br />
The magic of serial port modems is the ability to plug them in, open the associated serial (com) port, and start communicating with the device and/or endpoints connected on the other end of the line. This is exactly what we want here. While not connected through a phone line, we do want to allow for transparent communications with our endpoints.<br />
<br />
In days gone by I've had no end of the famous Haye's 'AT' command interface for modems. Personally I'm not a fan. The are cryptic and terse and generally not human friendly anyways. Given the flash size constraints of our ATmega8, implementing a full 'AT' command set is likely to prove too large with little in return. So rather than implement an 'AT' command set, we're going to implement an even more primitive command set - and yes, it uses binary data. Sadly, using binary data makes configuration of the operating mode non-terminal program friendly. But, once configured, the intent it to make it terminal program RX compatible and very friendly. Basically plug in and go, assuming our remote nodes are know at configuration time.<br />
<br />
Here's the functions we want to support:<br />
<ul>
<li>Set our local address. Think of this as our MAC or hardware address.</li>
<li>Configure our RF24 channel or frequency.</li>
<li>Configure the data rate mode of the RF24.</li>
<li>Turn the RF24 receiver on/off.</li>
<li>Power radio on/off.</li>
<li>Configure dynamic or fixed length payloads. </li>
<li>Configuring transparent operating mode of our modem. </li>
<li>Configuring RF24 receiver pipeline address (0-5).</li>
<li>Set Shockburst mode, timeouts, and retries.</li>
<li>RF24 CRC, off, 1 or 2 bytes</li>
<li>Store the modem configuration on EEPROM.</li>
<li>Reset the uC + RF24 module; restarting with saved configuration.</li>
<li>Scan a frequency </li>
</ul>
Command mode of the modem always follows DTR state. When DTR is high, the modem enters transparent mode. When DTR is low, the modem enters command mode.<br />
<br />
<i>Article is currently incomplete and unfinished. Significant progress has been made on the firmware. Its tight on flash, needless to say. The massive bloat of Arduino libraries >= 1.0 makes Arduino >= 1.0 completely useless for development. As such, I've been forced to continue development with Arduino 022 libraries. Likely I'll wind up with some native AVR code, bypassing the Arduino libraries, simply to save space and increase efficiency. But more to come...</i><br />
<br />
<br />
<span style="font-size: large;"><b>References</b></span>:<br />
<a href="http://www.atmel.com/" target="_blank">Atmel</a><br />
<a href="http://www.atmel.com/Images/doc2486.pdf" target="_blank">ATmega8 Datasheet</a> <br />
<br />
<a href="http://www.nordicsemi.com/" target="_blank">Nordic Semiconductor</a><br />
<a href="http://www.nordicsemi.com/eng/content/download/2730/34105/file/nRF24L01_Product_Specification_v2_0.pdf" target="_blank">nRF24L01 Datasheet</a><br />
<a href="http://www.nordicsemi.com/eng/content/download/2726/34069/file/nRF24L01P_Product_Specification_1_0.pdf" target="_blank">nRF24L01+ Datasheet</a> which also the same thing as the <a href="http://www.nordicsemi.com/eng/content/download/2726/34069/file/nRF24L01P_Product_Specification_1_0.pdf" target="_blank">nRF24L01P</a>.<br />
<br />
Please note the nRF24L01 has been officially obsoleted by the nRF24L01+ variant; which is frequently referred to as the nRF24L01P. Quoting Nordic, "This product is not recommended for new designs. Nordic recommends its drop-in compatible <a href="http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P" target="_self" title="nRF24L01+">nRF24L01+</a> or for a System-on-Chip solution the Nordic <a href="http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24LE1" target="_self" title="nRF24LE1">nRF24LE1 </a>or <a href="http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24LU1P" target="_self" title="nRF24LU1+">nRF24LU1+</a>."<br />
<br />
<a href="http://www.silabs.com/" target="_blank">Silabs</a><br />
<a href="http://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf" target="_blank">CP2102 Datasheet</a><br />
<a href="https://www.silabs.com/Support%20Documents/TechnicalDocs/an205.pdf" target="_blank">CP2102 Baud Rate Support Datasheet</a><br />
<a href="http://cp210x-program.sourceforge.net/" target="_blank">CP210x Programmer Software</a><br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/14244220623475709164noreply@blogger.com0tag:blogger.com,1999:blog-5559448074823950532.post-50476566704496767942013-04-04T11:09:00.000-05:002013-04-04T12:01:40.607-05:00RF24 - Avoiding RX Pipe 0 For Enhanced Reliability<h3>
RX Pipe 0 Is Special</h3>
<br />
The NRF24L01(+) radios have six receiving hardware pipes as part of its <i>MultiCeiver</i> design. These pipes, zero through five [0-5], each can have their own address. This sounds great, but reality is, pipe 0 is special.<br />
<br />
Pipe 0 is special because, whenever you transmit, RX pipe 0 is changed to that of the writing pipe's address. The fact this occurs is obscured, by design, by the RF24 driver. This is because the RF24 driver has specific logic for pipe 0. This is primarily why the startListening() method exists. Every time a call to startListening() is made, the RX pipe 0 address is shuffled back into the radio. Its shuffled in because whenever the radio transmits, the RX pipe 0 address is internally replaced by the radio.<br />
<br />
While not explicitly declared in the data sheet, I believe I understand why this behaviour takes place. When you enable auto-acknowledgement, the receiving radio needs to reliably inform the transmitter of its ACK/NAK status. In turn, potentially returning an ACK payload. However, the receiver doesn't directly know who transmitted the message. Its not part of the message. In order for the receiver to reply, the transmitter must be prepared to listen for a reply back from the receiving radio. As such, if the radio simply listens for a reply using the destination address, it should always match and filter properly. This is a clever idea to prevent transmitting source addresses.<br />
<br />
That's fine and all, and is rather clever, but there is a problem. The RF24 driver, in its attempt to hide this detail, creates an opportunity for lost and/or missed packets. Its a classic <a href="http://en.wikipedia.org/wiki/Race_condition" target="_blank">race condition</a>. This is a race condition because, should a transmitter send a message before the application's call to startListening() completes, the radio will completely ignore the message. Even if received, it will be silently filtered out and ignored. That means all messages destined for RX pipe 0's address will be silently ignored until the reloading of RX pipe's address completes. That completion only takes place with a call to startListening().<br />
<br />
This race condition is potentially compounded by the fact applications are free to have any amount of logic between the end of a write() or startWrite() call and the completion of a startListening() call. For almost the entire duration between [write()/startWrite()] and startListening() calls, the radio will ignore all messages addressed to pipe 0's address.<br />
<br />
The solution? Well, There really isn't a neat and clean solution. While many applications won't have issue with using RX pipe 0, and the associated message loss, high traffic networks are likely to suffer from periodic message loss and potential packet loss without full use of all retry attempts. For this second case, imagine the radio starts listening into 14-retries out of 15. That means all but one of the available retry opportunities have been lost simply because the radio was ignoring those messages. In turn, this would also drive up latency on the transmitter's side.<br />
<br />
Long story short, if you want a reliable network, don't use RX pipe 0. For small networks, use is unlikely to cause significant issue. But for a better option, just pretend you only have RX pipes one through five (1-5); for a total of five, rather than six. But if you insist on using RX pipe 0, always ensure your [write()/startWrite()] calls are as close as is possible to your startListening() call, so as to minimize the window of potential lost packets.<br />
<br />Anonymoushttp://www.blogger.com/profile/14244220623475709164noreply@blogger.com3tag:blogger.com,1999:blog-5559448074823950532.post-86046533016397794512013-04-03T15:31:00.004-05:002013-04-10T12:50:03.400-05:00New RF24 Driver Release - A Fork<h3>
New RF24 Driver Release</h3>
The RF24 driver was forked to add new features and fix bugs. These improvements are outlined below. This release's primary aim is to improve performance and increase operational reliability. I believe those aims were achieved.<br />
<br />
The intention is to once again have my features and bug fixes merged back into Maniacbug's RF24 driver. While this is currently a fork, I hope in the near future this code will be part of the official RF24 driver repository.<br />
<br />
My RF24 Fork: <a href="https://github.com/gcopeland/RF24">https://github.com/gcopeland/RF24</a><br />
<br />
<h3>
Auto-Acknowledgement Retry Bug Fix</h3>
The default timeout for auto acknowledgements is wrong. If using maximum payload size at 250Kbps, an erroneous timeout may cause errors in transmission, resulting in a failure to send. This timeout has been changed. Users who explicitly set their own timeouts via setRetries() function call are immune to this issue, assuming the provided values comply with operating requirements set out by the data sheet.<br />
<br />
<br />
<h3>
Reliability Improvements</h3>
Following each write(), the radio was explicitly powered down by the driver. I classify the previous behaviour as a bug. In order to improve reliability and performance, write() no longer powers down the radio <br />
<br />
Additionally, powering down the radio after each write also means the radio will not receive data until a startListening() method is called. This in turn means the radio is completely deaf between the end of the write() call and the end of the following startListening() call. This latency increases the likelihood of a missed transmission for a busy, multi-node network. In doing so, needlessly adds additional SPI bus traffic. This bug decreases radio reliability and wastes time on the SPI bus. Fixing this behaviour means the radio can now function optimally from standby mode while using less application time.<br />
<br />
By allowing the radio to enter standby mode, the radio will continue to listen for messages, including ACKs/NAKs, and transmissions which might otherwise be missed; as intended. The radio will respond dramatically faster from standby activation than it does from a powered down state. This in turn is a performance optimization. In turn reducing the window for lost packets.<br />
<br />
This is an important improvement because while the radio is free to process both ACK/NAK reply messages, it can also receive other messages even though startListening() has not been called. The messages will simply wait in the corresponding rx pipe until it is processed by the application. As such, this change also increases the radio's parallel pipe performance. Another performance optimization.<br />
<br />
See the <i>Compatibility</i> section for more details.<br />
<br />
<h3>
Higher Performance</h3>
The driver now has fewer delays and blocking calls. Fewer SPI read/writes now take place within various radio method call. This in turn means more CPU is available for applications. In doing so, a number of internal function calls were removed. This has the effect of very minor memory footprint improvements.<br />
<br />
<h3>
Multicasting</h3>
This driver adds support for multicasting. This allows a single transmitter to transmit exactly once, allowing for multiple concurrent receivers, without changing the radio's operational mode. This means use of this feature does not interfere with the use of auto-acknowledgement. This is because auto-acknowledgement is a radio's operational mode, whereby, the new multicasting implementation leverages a message's mode. As such, it does not interfere with auto-acknowledgements in any way.<br />
<br />
Multicasted messages are inherently unreliable. Even with auto-acknowledgement enabled, multicast messages will never be ACK'd or NAK'd. They are fire and forget. Either the message is received, or its not.<br />
<br />
To multicast a message, use the write() or startWrite() methods. There is now a third optional argument. If the third argument is not provided, or 'false' is used, it will transmit exactly as previously. If the third argument is, 'true', the packet will be multicasted.<br />
<br />
Example: radio.write( &msg, sizeof(msg), true ) ;<br />
<br />
<h3>
Closing Pipes</h3>
A new method, closeReadingPipe() has been added. This allows for a previously opened reading pipe to be shut down. A pipe which has been closed will no longer accept messages for the corresponding pipe address.<br />
<br />
<h3>
Variable Timeouts</h3>
A new method, getMaxTimeout(), is now available. This method returns the maximum number of microseconds a read/write operation will take to successfully complete. The value is calculated based on radio configuration at the time the method is called. Reconfiguration of the radio via setRetries() will invalidate the results return from getMaxTimeout().<br />
<br />
<h3>
Compatibility</h3>
Compatibility should not be an issue unless your application depends on a power management side effect. If it does, see <i>Power Management</i>.<br />
<br />
<h4>
Power Management</h4>
Power management is now an explicit mechanism. Applications which errantly rely on the driver to handle power management as a side effect, will find higher power demands. The fix is for the application to properly implement powerDown() and powerUp() calls as needed.<br />
<br />
Battery powered projects might see a minuscule increase of power requirements but ultimately its up to the application to match what was previously a side effect of the driver.<br />
<br />
<h4>
Timeout Calculation</h4>
If you previously have loops which look something like the following, where 'myTimeoutValue' is a fixed value, a better solution is now available.<br />
<br />
unsigned long t = millis() ; <br />
unsigned long myTimeoutValue = 250UL ;<br />
while( !radio.available() || millis() - t < myTimeoutValue ) {<br />
}<br />
<br />
Now, you can initialize myTimeoutValue as follows. Notice it rounds up to the next millisecond.<br />
unsigned long myTimeoutValue = 1 + (radio.getMaxTimeout()/1000) ;<br />
<br />
Doing so will ensure the minimal amount of time is spent waiting for a transmission to complete.<br />
<br />
As a reminder, if you attempt to use the code above, and if you enter that loop immediately after a write, unless you are using enableAckPayloads(), and a payload is immediately available for transmission on the remote's end, the timeout provided above will not provide time for remote's code execution to process its message and reply. As such, some experimentation may be required on a per application basis. Regardless, this mechanism allows for timed loop optimizations.<br />
<br />
<h3>
Testing</h3>
At this point, this fork has been tested by three users (me being one), on nine radios, two platforms (Arduino and Raspberry Pi), and four different makes and models of Arduino (uno, nano, mega2560, and due) of hardware. Thus far its been 100% compatible.<br />
<br />
<i>Update: At this point many people on both Arduino and rPi platform have tested this fork. All reports are good, confirming the validity of these changes.</i><br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/14244220623475709164noreply@blogger.com3tag:blogger.com,1999:blog-5559448074823950532.post-25928017086316596332013-04-02T11:12:00.002-05:002013-04-10T12:56:26.786-05:00Improve RF24 Radio Performance With Proper Addressing Schemes<h2>
<b>RF24 Addressing Gotchas</b></h2>
The NRF24L01(+) radios require addresses be configured on each of its <i>Multiciever</i> pipelines. Without much thought, people assign addresses to these pipelines. This can be problematic because of RF decoding requirements as dictated by the preamble (data transmitted in front) of each message. Read 7.3.1 and 7.3.2 of the data sheet for more information.<br />
<br />
A longer addressing scheme allows for more opportunity to disambiguate from the preamble. As such, in my opinion, the maximum available address length should be preferred. 40-bit addressing is most effective when proper addressing is provided to each pipeline. Per the data sheet, addresses which use single bit transitions should be avoided as they are more likely to confuse preamble message detection logic should the preamble become distorted from noise.<br />
<br />
As such, addresses with the following <a href="http://en.wikipedia.org/wiki/Octet_%28computing%29" target="_blank">octets</a> and/or <a href="http://en.wikipedia.org/wiki/Nibble" target="_blank">nibbles</a> (half byte) should be avoided.<br />
<br />
Octet values to avoid: <br />
'0xaa' - '0b10101010'<br />
'0x55' - '0b01010101'<br />
'0x2a' - '0b00101010'<br />
'0x15' - '0b00010101'<br />
<br />
Nibble values to avoid:<br />
'0x0a' - '0b00001010'<br />
'0x05' - '0b00000101'<br />
'0x02' - '0b00000010'<br />
'0x01' - '0b00000001'<br />
<br />
This in turn means addresses with those nibbles should not be used. Remember, a nibble is half an octet, so two of those nibbles can be used to create an octet. The octets of 0xaa and 0x55 are very bad. Always avoid them. Notice these appear in the octet list to avoid and that they are made up of a pair of nibbles from our nibble list to avoid. This is because both nibbles of both octets (both halves of the byte) are 0x0a or 0x05; making for an octet of 0xaa or 0x55. Accordingly, octets 0xaa and 0x55 represent the worst possible octet to use for an address because they exactly mirror the preamble of messages.<br />
<br />
Other nibble combinations to avoid, for example, would be 0xa1, 0x52, x12, 0x25, so on and so on. But even simple octets, such as 0x01, 0x02, and 0x05, should also be avoided.<br />
<br />
In general, use of values contained above is more likely to cause the loss of packets and in turn, require additional retransmissions if using the auto-acknowledgement hardware features.<br />
<br />
<h2>
<b>But Wait, There's More</b></h2>
The list above is hardly the exclusive list of bit patterns to avoid. In section 7.3.2, the data sheet says, "Addresses where the level shifts only one time (that is, 000FFFFFFF) can often be detected in noise and can give a false detection, which may give a raised Packet Error Rate [(PER)]. Addresses as a continuation of the preamble (hi-low toggle; [single bit transitions, as referred above]) also raises the Packet Error Rate.<br />
<br />
As such, an address of 0xFFFFFFFFFF should never be used. And in general, octet sequences of all bits on or off should be avoided. Which means, nibbles of 0x0F and 0x00 should be frowned upon.<br />
<br />
Please note addressing is a little more complex and that the tips provided here. These tips should be regarded as rules of thumb rather than absolutes. Regardless, if you follow the advice here, your reliability is generally improved (PER is reduced).<br />
<br />Anonymoushttp://www.blogger.com/profile/14244220623475709164noreply@blogger.com1tag:blogger.com,1999:blog-5559448074823950532.post-33244403401569051722012-02-14T17:01:00.000-06:002012-02-20T10:45:25.799-06:00The Arduino Learner's Project - Part II<b><span style="font-size: large;">The Rehash</span></b><br />
In my <a href="http://maniacalbits.blogspot.com/2012/01/arduino-learners-project-part-i.html">previous blog post</a> I explained the trials of simply starting the project and how I came about to creating my list of high level requirements. The requirements follow. As you can see, some have been crossed out since some purchases have been made.<br />
<ul>
<li><strike>microcontroller (uC) with enough ports</strike></li>
<li><strike>LCD for human interface</strike></li>
<li><strike>keypad for human interface</strike></li>
<li><a href="http://en.wikipedia.org/wiki/Real-time_clock" target="_blank">Real Time Clock (RTC)</a></li>
<li>power supply (and transformer)</li>
<li>wireless interface of some type</li>
<li>method for controlling irrigation solenoids</li>
<li>humidity & temperature sensor(s)</li>
<li>moisture sensor(s)</li>
<li>and eventually a nice case of some type </li>
</ul>
Since I already had purchased a <a href="http://arduino-direct.com/sunshop/index.php?l=product_detail&p=92">16x2 LCD arduino shield</a> and picked my arduino (atmega2560), I had my first three items addressed. Remember, most LCD shields come with micro switches which serve as buttons, allowing for human interaction. And so these items are crossed off our list above.<br />
<br />
<br />
<b><span style="font-size: large;">Sprinkler Basics</span></b><br />
Irrigation systems are broken into multiple zones. Each zone is sized based on the water pressure in an area. Each sprinkler head requires a fixed amount of pressure. So given a fixed amount of water pressure, each zone is broken into a given number of heads. Each zone, in turn, is controlled by a valve.<br />
<br />
Basically the way a sprinkler controller works is by triggering a <a href="http://en.wikipedia.org/wiki/Relay">relay</a> or <a href="http://en.wikipedia.org/wiki/TRIAC">triac</a> to open or close a <a href="http://en.wikipedia.org/wiki/Solenoid">solenoid</a> which opens or closes a valve. The valve in turn allows water to flow into the zone and out the sprinkler heads. Most residential solenoids require roughly 150-300mA of current while in operation. Because of water pressure constraints, normally no more than two valves (one zone) will be open at one time. By extension, no more than two solenoids need be active at one time. Though only one valve need actually be used, commonly two are used in conjunction with each other. The determining factor for one or two is based on your irrigation installation. Typically one solenoid is used per zone and optionally a master solenoid is used at the head of the system. So long as the irrigation system is running, the master value plus another for a specifically enabled zone, is active.<br />
<br />
Some irrigation systems do no have a master valve. Others do. For some systems, the master valve is used to not only open a valve, but also to turn on a primary pump (e.g. well water) and/or boost water pump (low water pressure and/or over sized zones). Please keep in mind I'm speaking generalities here. I'm aware there are exceptions. Please verify your own installation requirements before assuming the details here are valid for you system.<br />
<br />
As I'm using a relay board, my relay(s) holding current also needs to be added to the sum current required for operation. On my relay board, each relay requires 80mA while in operation. To keep two valves open requires a worst case of (300+300+80+80) 760mA of current. Once we add in the load for the uC, LCD display, radio interface, and inefficiency losses though our regulator, we'll be pretty close to our maximum of 1A. It may turn out I require a larger transformer, but for now, 1A (1000mA) remains my target. Worst case, I already have my eye on a refurbished 1.5A transformer for not a lot of bucks.<br />
<br />
<br />
<b><span style="font-size: large;">The Ultimate Power </span><span style="font-size: small;">Source</span></b><br />
There are many different directions to look at here but ultimately I decided to re-use the power supply of my existing sprinkler controller. This has the advantage in that it has the power required to directly drive the sprinkler solenoids without incurring additional cost. This meant I still needed another power supply to drive the microcontroller (uC) side of things. The catch is the transformer's input is 120VAC and output is 1A@26.7VAC. I need 5VDC for my uC, display, and relays. So clearly I need to convert 26.7VAC to 5VDC.<br />
<br />
After some asking around, most people pointed me at <a href="http://www.dimensionengineering.com/de-swadj.htm">something like this,</a> which provides for high efficiency switching regulation and minimal part count; which still requires several <a href="http://en.wikipedia.org/wiki/Ripple_current">anti-ripple capacitors.</a> After learning more about AC to DC conversion, I figured out its too small. This is because the peak-to-peak conversion will yield roughly 36VDC after basic rectification. What I really needed was something like <a href="http://www.dimensionengineering.com/SWADJHV.htm">this.</a> Which means we just jumped from a $16.25 solution to a $26.50 solution, and I still needed my own front end circuitry to rectify AC into DC. That dog won't hunt as powering the device would become one of the single most expensive components of my build. Heresy I say, as it violates my frugal nature. And so I decided to keep looking. This is when I discovered devices based on the <a href="http://www.gravitech.us/35v1aswvore.html">LM7805</a>; switching regulators. That's more like it. After shipping its basically $10. Certainly looks like a good buy and it received a thumbs up from those who previously pointed me at the more expensive counterparts.<br />
<br />
I then hit ebay and started looking for LM7805 based solutions. That's when I stumbled on LM2596 switching regulator based solutions. For cheap, <a href="http://www.ebay.com/sch/i.html?_nkw=LM2596+40v&_sacat=0&_odkw=LM2596&_osacat=0&_trksid=p3286.c0.m270.l1313">roughly $3.00 or less, including shipping</a>, you can get a variable output switching regulator. These typically accept up to 40VDC as input and can output up to 3A, so its perfect; even if I need to upgrade my transformer at a later date. Of course, this still requires rectification on the front end; but so did the higher priced solutions above. The disadvantage of this solution is that its larger. But even that is a little misleading as they all required several capacitors; two minimum, three recommended. The ebay solution has all that already included in its foot print.<br />
<br />
If you need a tiny footprint, don't care about cost, or simply don't want to wait on the proverbial slow boat from China (or HK), I'm sure you'll be happy with one of the solutions above. If on the other hand, you're looking for a cheap solution, footprint doesn't matter, or delivery schedule isn't a first order concern, head to ebay. I guess time will tell if it turns out to be a frugal or foolish purchase. Having said that, I did find other frugal hobbyists who have found ample satisfaction with these low cost devices. That said, its not clear they are all equal.<br />
<br />
Please note all of these solutions use a switching regulator for DC to DC regulation (often 85%-93% efficient). None of the above are linear regulators. For my project, this is very important as the conversion efficiency is typically much lower for the linear regulators (75%-85% efficient). In my case, would have also required a large heat sink to dissipate the heat from the inefficient conversion. Linear regulators do best when the voltage delta is small. In my case, the voltage difference is relatively very large, which results in a lot of current being converted to heat. Given my voltage spread is ~31 volts, and I only have 1A available on my transformer, and as you can see above we're already tight, I didn't consider it an acceptable loss.<br />
<br />
<br />
<span style="font-size: large;"><b>Rectifying The Situation</b></span><br />
The last part of our power source is a <a href="http://en.wikipedia.org/wiki/Bridge_rectifier">bridge rectifier. </a>This is an incredibly simple circuit. It can be built with four diodes or as a single integrated package. Basically this converts the sinusoidal wave of AC input into a heavily rippled DC output.<br />
<br />
Basically it converts the top sine wave...<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.duncansonelectric.com/blog/wp-content/uploads/2009/08/02-power-from-sinusoidal-current-1024x758.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="236" src="http://www.duncansonelectric.com/blog/wp-content/uploads/2009/08/02-power-from-sinusoidal-current-1024x758.gif" width="320" /></a></div>
<br />
...into the rippled DC wave at the bottom. I still have not decided if I'll use a bridge rectifier or make one out of diodes. In the short term I did go ahead and build a diode bridge and tested it. Super simple and easy to make. But having done so, it makes you realize how much of a foot print it requires so I certainly understand and appreciate the appeal of a smaller IC, which serves the same purpose. We'll see.<br />
<br />
What we wind up with is a complete power supply for roughly $3.00USD, including some diodes for rectification and even some capacitors, should it turn out they are required.<br />
<br />
<br />
<span style="font-size: large;"><b>The Driver</b></span><br />
From what I've found and have been told, triacs are more commonly used for commercial controllers. But to keep things simple, I'm using a relay board, which is just a collection of relays on a board. In my case, the board is also optically isolated which means I don't need to worry about 26.7VAC ever jumping into my sensitive 5V circuitry. While triacs are typically lower current draw than relays, in my case, I believe a pre-built relay board just nicely simplifies things.<br />
<br />
Relays do have a disadvantage beyond higher current draw, in that they are a mechanical device. As relays are an electromechanical device they do wear out with repeated use. But given the usage patterns associated with an irrigation system, I believe <a href="http://arduino-direct.com/sunshop/index.php?l=product_detail&p=156">my choice of board</a> will easily provide a lifetime of use. After all, if you water twice per day, three times per week, four months out of the year, you wind up with 96-cycles per year. Even if this is grossly under estimating, these relays should be good for hundreds of thousands of cycles so we should still have a lifetime of use. And even if one does fail, the relays are easy to find online and large enough for someone with bad eyes to replace them as needed.<br />
<br />
Speaking for relay failures, should a relay fail in the open condition, since my system does have a master relay, I'm still protected. Basically my system will require the failure of two relays before I need worry about my yard becoming flooded, should it fail in the open position.<br />
<br />
<br />
<span style="font-size: large;"><b>Episode Summary</b></span><br />
So far we have selected our uC, user interface, and decided how we plan on powering everything. Next we'll start looking at our radio solution which turns into a tangent project in of itself.<br />
<br />Anonymoushttp://www.blogger.com/profile/14244220623475709164noreply@blogger.com0tag:blogger.com,1999:blog-5559448074823950532.post-90907453258403822262012-01-18T13:56:00.000-06:002012-01-18T14:08:35.312-06:00The Arduino Learner's Project - Part I<div style="font-family: "Trebuchet MS",sans-serif;"><span style="font-size: large;"><b>Inception </b></span></div>I had originally considered this project many years ago while working for a hardware manufacturing company. And so I went about asking about details required for my project as hardware engineers were plentiful. I had heard rumblings of Arduino but really didn't know anything about it and I certainly hadn't explored any details. And so I trusted the answers I heard. After all, this is what he does for a living. The answers meant the project was cost prohibitive so I simply let the project go there - but not forgotten. I was disappointed to say the least.<br />
<br />
Years later I learned the information provided by my learned professional was more or less, completely wrong. I don't know what he had based his information on but it turns out it can be done for a fraction of the cost I had been told and certainly by using more frugal methods than had been suggested or what I had originally considered. I realized all this after curiosity got the better of me and I started exploring the <a href="http://www.arduino.cc/" target="_blank">Arduino platform.</a><br />
<br />
Long story short, creating your project is likely easier and more cost effective than you think.<br />
<b><br />
</b><br />
<div style="font-family: "Trebuchet MS",sans-serif;"><span style="font-size: large;"><b>The [Advanced] Wireless Sprinkler Controller</b></span></div>The project at inception was originally going to be a cheap Buffalo wireless router with some relays and custom Linux code. Once I started seriously looking at an Arduino solution, I realized it could be much cheaper yet. It was at this point I started learning about sprinkler system controllers, their defacto solenoids, and the voltage/current requirements. And so I started looking for various components to piecemeal my project.<br />
<br />
I realized early on I wanted more than just another sprinkler timer. If you check, you'll find many such Arduino based projects. Some even complete with code and schematics. None of these really scratch my itch as they are typically a generic scheduler and timer and/or the former plus a web interface. All more or less variations of a theme. None of which are terribly exciting for me.<br />
<br />
Well, I wanted none of that. I already have a nice multi-zone sprinkler controller and timer. Adding a web interface is slick but doesn't really do anything aside from save me a trip to the garage a couple times per year, plus timer adjustments after I realize the grass is getting burned. Not really sexy enough. That's when I realized I wanted a smart controller. Some investigation reveals the level of smarts I want is retail priced in the $600-$1200 dollar range depending on the specifics and brand of controller. Now that sounds like a project. While I don't expect exact feature parity with these costly commercial offerings, I do believe I can get mostly there for a fraction of the cost.<br />
<br />
You might be wondering what this does that the others don't. Well, for starters, they automatically adjust water based on an array of environmental factors. Generally speaking, the person behind the controller provides operational criteria for each zone and the controller does the rest. This means, for example, no watering while its raining and extra watering during those triple digit heat waves, all without any input from me. What this really means is the opportunity to play with lots of different sensors and embedded development while creating something practical at frugal expense.<br />
<b><br />
</b><br />
<div style="font-family: "Trebuchet MS",sans-serif;"><span style="font-size: large;"><b>The Arduino Platform</b></span></div>There is a lot of confusion about what Arduino actually is. It doesn't help that the group behind Arduino seems to take pride in obfuscating what Arduino actually is.<br />
<br />
Arduino is a <a href="http://en.wikipedia.org/wiki/Microcontroller" target="_blank">Microcontroller</a> (uC), a USB interface, (typically) power regulators (3.3v and 5v), any number of microcontroller pins pulled out to easily accessible headers, a <a href="http://en.wikipedia.org/wiki/Bootloader#Boot_loader" target="_blank">bootloader</a>, a set of high level libraries (which come at a performance cost), and a primitive <a href="http://en.wikipedia.org/wiki/Integrated_development_environment" target="_blank">IDE</a>. <br />
<br />
The <a href="http://en.wikipedia.org/wiki/USB" target="_blank">USB</a> interface provides a means of powering the board and small, attached devices, as well as a means for basic input and output (I/O). This means of I/O is also the basis for flashing (sending your program to) the microcontroller. This interface also alleviates the need to have a separate device known as an <a href="http://en.wikipedia.org/wiki/In-circuit_serial_programming" target="_blank">In Circuit Serial Programmer (ICSP)</a>; though headers are typically broken out to allow for easy attachment of an ICSP to the board. Its important to understand, this interface does not actually extend USB access to the Arduino platform as the available USB interface is completely abstracted away (and frequently controlled by a second on-board microcontroller or USB TTL chip) so as to look and act like a serial port.<br />
<br />
Next is the language. Its extremely annoying they call programs, "scripts", when in fact, <a href="http://en.wikipedia.org/wiki/Scripting_language" target="_blank">they are absolutely are not</a>. "Scripts" are typically associated with a scripting language and none of the languages supported by Arduino qualify as a scripting language. You program Arduino in <a href="http://en.wikipedia.org/wiki/C_%28language%29" target="_blank">C</a>, <a href="http://en.wikipedia.org/wiki/C%2B%2B" target="_blank">C++</a>, and Atmel AVR <a href="http://en.wikipedia.org/wiki/Assembler_%28computer_programming%29#Assembler" target="_blank">assembler</a>. The standard Arduino library does, however, do a good job of simplifying some of the more involved tasks associated with embedded development. So don't let the newly revealed truth scare you away.<br />
<br />
In a nutshell, Arduino is a rapid prototyping and development platform. And the best thing is, you need not actually deploy your project with an Arduino. You can build a system using the minimal components required, thusly helping to reduce deployment costs. Meaning you can use Arduino strictly for development and deploy with a much lower cost solution; frequently for a couple of bucks plus any external devices and sensors. Of course, to do this requires some extra hardware expertise. But if you, like me, are lacking this expertise, visit the <a href="http://arduino.cc/forum/" target="_blank">Arduino Forums</a>. You'll find you're not alone and that lots of help from a very active and friendly community is ready to assist so long as you're willing to put in the effort.<br />
<b><br />
</b><br />
<span style="font-size: large;"><b style="font-family: "Trebuchet MS",sans-serif;">Arduino Selection</b></span><br />
Once anyone starts looking at the full spectrum of official and unofficial Arduino hardware, board selection can become somewhat daunting. Doubly so when you have no idea what your code and pin count requirements will be. Since I was new to Arduino I decided I would err on the side of caution and simply get a big Arduino with the understanding I can always step down in a variety of way. After all, this is in large part, Arduino's claim to fame as Atmel makes a large selection of arduino compatible 8-bit microcontrollers.<br />
<br />
I quickly settled on a <a href="http://arduino.cc/en/Main/ArduinoBoardMega2560" target="_blank">Mega 2560</a>. The specifications show it to be a fairly robust 8-bit microcontroller (uC) and so it seems like a very sane board into which I can grow. Sadly, experience has taught me otherwise. In fact, for a general purpose development board, especially for a beginner, I can not recommend strongly enough you stay away from this board. The board is very poorly supported, making it the exception rather than the rule. Reportedly it has a minor and rarely observed hardware bug which can require physical reset to recover. Worse, the <a href="http://en.wikipedia.org/wiki/Bootloader#Boot_loader" target="_blank">bootloader</a> has a critical bug such that the <a href="http://en.wikipedia.org/wiki/Watchdog_timer" target="_blank">WDT</a> can not be used. And even more frustrating, simply flashing code which contains the character sequence of, '!!!', will cause the flash to fail. Made even more frustrating, that sequence can be generated by the compiler, so flashing your code can suddenly just start failing without any indication as to why. Also, there is an issue where the <a href="http://en.wikipedia.org/wiki/EEPROM" target="_blank">EEPROM</a> can't be programmed when its flashed, meaning your program must always setup initial state. There is also an issue accessing all of the 2560's memory in many circumstances. In the Arduino world, its by far the odd man out.<br />
<br />
It also turns out the physical form factor is at a disadvantage for two reasons. These boards are not compatible with all Arduino Shields. The second physical issue is that the uC is not socketed. This means if you burn out a pin on the uC, that's that. In contrast to most other Arduinos, they are much more forgiving because you can simply replace the socketed uC for a couple of bucks and lesson learned. Whereas, with the Mega 2560, you need to lay down another ~$55 bucks or so. Costly lesson.<br />
<br />
Compiler support is another real hit or miss issue with the Mega2560 and various Linux distributions. Turns out my then Linux distribution, Mandriva, happily provides an extremely buggy compiler. It was so bad, many of the Arduino examples would simply fail to run. I wound up having to compile my own gcc tool suite and <a href="http://www.nongnu.org/avr-libc/user-manual/" target="_blank">avr-libc</a>, which proved to be another project in its own right. And I can assure you, that's the very, very terse version of it. Eventually with the help of others on the Arduino and AVR forums, I was able to create a working environment. Sadly, Mandriva is far, far from alone here. I guess the good news is, if you run Windows, the Arduino environment is very well maintained so Windows users need not fear. If you're a Linux user, do not trust the AVR compilers out of the box unless you know for a fact it works with your uC of choice.<br />
<br />
All of these issues are known for well over a year or more at this point and there seems to be little incentive for the developers to support this hardware. So in a nutshell, unless you are absolutely positive you need the Arduino Mega 2560, avoid it at all costs. If you still want a high end Arduino, consider the <a href="http://arduino.cc/en/Main/ArduinoBoardMega" target="_blank">Arduino Mega</a> in its place. It doesn't address the socketed uC issue but it also doesn't have all the other bugs.<br />
<b><br />
</b><br />
<div style="font-family: "Trebuchet MS",sans-serif;"><b><span style="font-size: large;">"The Controller"</span></b></div><div style="font-family: "Trebuchet MS",sans-serif;"><b><span style="font-size: large;"> or</span></b></div><div style="font-family: "Trebuchet MS",sans-serif;"><b><span style="font-size: large;">"One Controller To Rule Them All"</span></b></div>To pull this project together, we need a number of different components and sensors. So the generic and very rough list looks something like this:<br />
<ul><li>microcontroller (uC) with enough ports</li>
<li>LCD for human interface</li>
<li>keypad for human interface</li>
<li><a href="http://en.wikipedia.org/wiki/Real-time_clock" target="_blank">Real Time Clock (RTC)</a></li>
<li>power supply</li>
<li>wireless interface of some type</li>
<li>method for controlling irrigation solenoids</li>
<li>humidity & temperature sensor(s)</li>
<li>moisture sensor(s)</li>
<li>and eventually a nice case of some type</li>
</ul>The uC needs to have storage to hold a program large enough to meaningfully handle LCD output, keypad input of some type, a wireless interface and associated protocol, read various sensors, and enough computing power to perform some type of environmental simulation to keep my lazy self out of the garage. It also needs to have enough EEPROM storage to maintain its configuration when power is out.<br />
<br />
Notice the wireless component of the project keeps popping up. The wireless component exists to optionally enhance environment information, allow for configuration of zones, and to obtain logged irrigation zone information (when, how long, sensor readings, etc). And of course, to not be left in the dark with more traditional Arduino sprinkler projects, the wireless component is to allow for manual operation of each zone as well as simple timers.<br />
<br />
Stay tuned to see how this progresses.Anonymoushttp://www.blogger.com/profile/14244220623475709164noreply@blogger.com0