 |
| RN-XV+SD shield. Click on the image for an annotated version. |
In my quest to make a low-power magnetometer for AuroraWatch UK there are two additional periphals needed: a Wifi connection for real-time data transfer and an SD card for configuration and data logging. I wasn't happy with any of the existing XBee or SD shields. Many of them use resistor-divider networks which prevent dual 3.3V/5V operation (very useful for development), and those which do use logic-level shifters seem to ignore the problem of mixing 3.3V devices with 5V ones.
In response to this need I designed my own shield. I investigated several Wifi modules, but the main contenders were the XBee wifi module and the similar RN-XV module made by Roving Networks. Although I like the idea of the SPI interface that the XBee module offers in the end I chose the RN-XV, partly because it was cheaper but also for its better availability. Both modules use the same pseudo-standard XBee footprint so to some extent either could be used, although the circuitry is designed for the UART interface and GPIOs of the RN-XV. I also included the circuitry for the PNI MicroMag3 module. This is outside the main shield area so as to be located away from the metal casing of the SD card and away from the Wifi module, which could cause interference. To test for temperature effects an LM61 temperature sensor can be used. Unlike the optional one on Calunium this is powered from a logic output for ultra-low power consumption. The shield is designed for Calunium, but will work with full functionality on the Arduino Mega2560. It will also operate on a standard Arduino but flow control and some of the GPIO features of the RN-XV are not available.
Fitting everything onto a 80 × 100mm PCB (the largest size possible in the free version of Cadsoft Eagle) was difficult so I chose to use surface-mount components. The many jumpers are included to make the board as flexible as possible. I sent the Gerber files to Iteadstudio for manufacture. For maximum yield I used very conservative 0.012" trace widths and 0.012" minimum separation, with 0.024" ground-pour isolation. The magnetometer circuitry is easily removed from the schematic and board design if it is not needed; on the manufactured boards the magnetometer section can be removed with a guillotine without affecting the rest of the circuitry. The cut-out is carefully arranged to avoid obstructing the reset button and the USB and JTAG connectors on Calunium.
 |
| RN-XV+SD shield on Calunium. |
Eagle PCB design files available under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) licence.
I want to talk to arduino through wifi. I have a shield that connects arduino to rn-xv. And I have a sketch in my arduino telling it to turn on a led when it receives the letter "H" (for example) through serial. How can I tell (using telnet, or other way) rn-xv to send the string "H" to arduino. Thank you very much
ReplyDeleteI've only used the RN-XV to send data from the Arduino. The default configuration should allow you to telnet into the RN-XV on port 2000 and send data. The Arduino will have to parse the output of the RN-XV to read the "H".
DeleteI've tried to avoid parsing the serial output. You might be able to do the same, by setting a GPIO from the remote telnet session and having the Arduino monitor one of the RN-XV GPIO lines. It'll depend whether your shield uses any additional I/O from the RN-XV.
Steve, do you have flow control turned on for your RN-XV (set uart flow 1)? I'm following the specs, but whenever I turn flow control on, I stop receiving data from my RN-XV. The docs say "NOTE: Once flow control is enabled, it is important to properly drive the CTS pin (active LOW enabled) If CTS is HIGH, data will NOT be sent out the UART, and further configuration in command mode will be problematic as no response will be received." However, no matter what I do (driving CTS low or high), the RN-XV won't send data back to me once i turn uart flow control on. :(
ReplyDeleteHi Steve, great effort! I have a question on the flow control as I see you working with it in the code. I've noticed in my experiment receiving side (TCP server) when deserializes objects at times I am getting 3 bytes lost. The transmission speed is way below what specified on arduino and WiFly (230400 baud). I've implemented simple Cheksum and retransmission protocol on app level but thought of improving it with RTS when buffer gets full. I am not sure if I am doing things right as RTS (pin 12) on wifly gets triggered but lost bytes on the TCP Server side are still registered
ReplyDeleteCould you please share you experience working with flow control and if you manager to overcome similar problems with buffer overflows. And how? Maybe simple example?
Thanks!