|
|
By Oleg Mazurov  PL2303 and Xbee on a breadboard
Despite being quite old, asynchronous serial interface is still popular these days. Xbees, Bluetooth and WiFi embedded adapters, standalone GPS modules are often equipped with asynchronous serial data port. At the same time, standard size Arduino comes with just one asynchronous port – and the same port is used to load compiled sketches and print debug messages. Using these functions while sharing serial port with peripherals is never trivial and often impossible. Recently announced revision 2.0 of USB Host Shield library allows communication with several USB devices simultaneously making it possible to talk to multiple peripherals via USB to serial converters. The converters are available from many places and cost around 15 dollars. However, any old cell phone data cable is essentially a USB to serial converter and can be used as such with not much difficulty. In this article, I will show how to modify data cable originally intended for Sony Ericsson T226 phone into general purpose USB-to-serial.
Continue reading Building PL2303 USB to Serial converter from old data cable
By Oleg Mazurov  Arduino Camera Controller Today, I’m writing about two more pieces of digital camera control firmware that have being posted to PTP gihHub repository. Alex Gluschenko, the author of PTP library for Arduino, developed two sketches, one called EOSRemote and the other EOSCamController to demonstrate PTP library capabilities. The code allows requesting camera settings, such as shutter speed, aperture, ISO, etc., change them, as well as take shots. It supports Canon EOS cameras and was tested on EOS 400D, 450D, and 7D; other cameras with similar command set ( see my collection of PTP device info dumps ) may work as well.
This is how the code works: when connection is established, camera sends back an initial packet with all its current settings along with a list of all possible values for each setting. Possible values depend on a camera model as well as lens that are mounted. For example, some cameras may have exposure compensation range from -2 to +2, others from -5 to +5; some lens have max.aperture 1.4, others – 3.5, an so on. The list of values received from the camera is placed in built-in EEPROM of Arduino microcontroller. After that, values are used in setting (called “property” in PTP lingo) change commands sent to the camera. When camera mode, such as Av, Tv, or lens is changed, camera sends initial packet again. The Arduino code tracks changes and updates the list stored in EEPROM.
Hardware requirements for both controllers are pretty standard. The EOSRemote sketch uses Arduino serial port facility for I/O, and the only hardware necessary is Arduino Duemilanove, Uno, or compatible clone, as well as USB Host Shield. User interface is designed with simple terminal emulator program in mind. It can be used with a PC connected to Arduino directly or over some distance utilizing a pair of serial to RF converters, such as ever-popular Xbee. The following screenshot shows top-level menu with camera connected and recognized.
Continue reading Arduino-based controller for Canon EOS cameras
By Oleg Mazurov  Xbee PCB
After playing with Xbee connected to a PIC I decided to transfer the design from the protoboard to make it more pretty and compact. The following board contains Xbee connectors, PIC18F26K20, bypass caps and Vpp limiter to use with old programmers/debuggers. I wrote several articles describing the circuit and it’s capabilities, see “Related posts” for more information.
As usual, Eagle files are available from download section. The PIC code written for Xbee protoboard will work here with very little modification. This board is good as a base for more complex sensors which require MCU on-board.
I am working on several applications for this board and will be posting results here this summer.
Oleg.
By Oleg Mazurov  Xbee module case
My Xbee sensor project is picking up steam. The PIC part of API module is finished, the host part is close to completion. Since Python is new to me, the development is not as fast as I would like it to be, but I’m getting there. In the meantime, I started thinking about converting my coordinator setup, consisting of bare USB board with Xbee module, to something more permanent and professionally looking.
Picture on the right shows the materials. The idea is very simple: drill a 1/4″ hole in the cap, fasten Xbee to the cap using RP-SMA connector, cut another hole in the side of a bottle for the USB cable and screw things together. The whole project was completed in 15 minutes. The all-new Zigbee coordinator is waiting.
Oleg.
By Oleg Mazurov  Setting serial speed on Xbee module
Xbee module supports two modes of operation – transparent mode and API mode. To create simple point-to-point links, Xbee works nicely in transparent mode without much coding. However, if your goal is to build a network consisting of more than two devices, AT mode becomes too difficult to bear. You will spend almost all the time switching in and out of command mode, wasting time and draining batteries in the process. On the other hand, in API mode commands and data travel in specially formatted frames and no switching is necessary. Another advantage of API mode is that serial speed on transmitters doesn’t have to match – one can be configured for 115200bps, another for 2400bps, third left with default 9600bps. There is another nice feature called remote command; you can remotely request the state of Xbee module pins, for example, or change an output pin level. It means that for simple measuring and control applications no MCU is even necessary at the sensor.
API mode requires re-flashing module firmware and some extra coding on both sides of the link. I started with upgrading the firmware. Picture on the right shows X-CTU screen with serial speed drop-down expanded – along with loading API firmware I’m changing the speed of coordinator Xbee to 115200.
Continue reading Playing Xbee. Part 4 – API.
By Oleg Mazurov  Xbee on a protoboard
First of all – breadboards are evil. Sure, they are handy. But when you spend a whole day chasing glitches which drive your logic analyzer crazy, it’s not fun. I moved my Xbee setup on a protoboard; picture on the right shows the result. The capacitor on Xbee VDD pin is essential – the module generates pretty strong spikes every time it starts transmitting and without the capacitor one should expect to see glitches every 250ms or so. The manual recommends bypassing VDD using 1uF and 8.2pF caps in parallel; I’m using 0.1uF here and it works well also.
In the previous article, I talked about switching in and out of command mode on an Xbee module running AT firmware. You can do exciting things with AT commands; however, when you interact with the module via RF link, how are you supposed to see the output of an AT command? In command mode, all output goes back to the PIC USART, so we need a method to capture it and send back to us.
The following function is called from CLI. It queries every AT command, stores the result, and sends it back after going back online. The usual way of doing that is to switch to command mode, issue all the commands capturing output to a buffer, then switch back online and send the buffer contents back. PIC18 doesn’t have enough RAM to hold such a big buffer, that’s why this function queries one command at a time. Because of that, the function is quite slow – the guard time before sending “+++” is one second plus it needs to wait for RF transmission of previous result to complete before switching to command mode for the next query. It takes approximately 3 seconds per query and querying about 60 commands takes 3 minutes.
Continue reading Playing Xbee. Part 3 – Measure and send.
By Oleg Mazurov  Xbee on a breadboard
In the previous article, I described a simple wireless setup using a pair of Xbees connected to PIC microcontroller and serial port of a Linux machine. After finishing the article, I continued working on the project and that’s what I have found so far.
First, using router firmware in Xbee module is bad for your batteries. In this configuration power consumption is steady 40ma. In addition to that, sleep is not working. After loading end device firmware power consumption dropped to 5ma on average and I was able to use Sleep pin. Measured current in sleep mode is less than 1ua – not bad. Second, PIC18F4520 is not the best PIC for sensor applications. Newer K-series PIC18s with their internal 1.2V reference, such as PIC18F26K20, are much better. In addition, they can be clocked up to 64MHz, and they are cheaper. At the time of this writing PIC18F26K20 in DIP package sells for less than $4 in single quantities on Mouser.
Continue reading Playing Xbee. Part 2 – Command mode.
By Oleg Mazurov  Xbee coordinator Couple of days ago, I picked a pair or Xbees at Sparkfun. The plan is to build low power sensor platform using PICs, Zigbee radios, and Linux. In this article, I’m sharing my experience in building with Xbees.
The BOM includes two Xbee 2.5 RPSMA radios, Xbee USB explorer, Xbee breakout, PIC18F4520 microcontroller, and a breadboard. The code is written in C18 and built in MPLAB. Project files are available in download section.
Even though it is (presumably) possible to get two Xbees talk without any configuration, I decided not to do it. First, the firmware was old; second, I’m planning on having more than two radios. In addition to that, new stack supports firmware upgrades over the air. I downloaded X-CTU and upgraded my radios to Xbee ZB; one became a coordinator( pictured on the right ), the other one a router.
Continue reading Playing Xbee. Part 1 – First impression.
|
|
