Digital camera control code AKA PTP (Picture Transfer Protocol) compatible with USB Host Shield rev.2.0 Arduino library has been released and posted to GitHub. New code has all functionality of original camera control library and adds new elements, namely ability to control several cameras simultaneously and (finally!) support for Nikon DSLRs.
The code comes with numerous examples demonstrating various aspects of digital camera control. All examples were compiled using Arduino IDE rev.0022 with USB Host Shield 2.0 and PTP 2.0 libraries installed as usual (by copying the whole library directory in %arduino%/libraries) and tested on Arduino UNO equipped with USB Host Shield. There are also several examples which require Quantum Platform state machine framework, they can be recognized by qp_port.h header included in the text of the sketch. If you want to try one of those, install QP Development Kit for Arduino and then replace qp_port.cpp with this file.
More detailed explanation of library examples will follow soon. In the mean time, play with the library and try the examples. Stay tuned for the updates!
Google Open Accessory Interface is now included in USB Host Shield Library 2.0 package. It follows standard structure of rev2.0 device driver (wherever possible) and because of this is slightly different from original Arduino code developed by Google. The interface itself is pretty simple and there are many articles on the net describing it in details; in this article I will give brief overview of new code and explain the differences.
To test the code I made a little “shield” resembling Google’s one. Since the only thing I cared about while testing was data transfer in both directions, I implemented just one LED and one button. The demokit_20.pde Arduino sketch works with DemoKit.apk Android application, however, only “B1” button and “LED 1 Red” are functional. To run the sketch, you will need an Arduino board, USB Host Shield, as well as USB Host Shield 2.0 library.
The ADK class contains all necessary functionality to communicate to Android phone via ADK interface. In order for USB subsystem to initialize the device when it is connected, the instantiation should look like the following code fragment. First, the USB class is instantiated, then ADK is instantiated taking address of USB instance as the first parameter. The rest of the parameters are ID strings for the phone – they are identical to the original code.
The initialization of Android device and switching it to accessory mode is performed automatically by USB subsystem. The ADK::Init() member function is called each time a new device is detected on a bus. It first tries to determine if a device is in accessory mode already by reading its VID, PID, and if yes, configures it and reports success to the system. If device fails accessory check, the standard probing and accessory switching method is performed. If successful, device resets and appears on USB bus as an “accessory mode-capable” unit. In certain cases, Init() may be executed two times. Continue reading Google Open Accessory Interface for USB Host Shield Library 2.0 released
Here is another quick demonstration of USB Host Shield 2.0 Library. This article describes how to communicate to Navibee GM720 GPS receiver based on SiRF Star III chipset and PL2303 USB to serial converter. This GPS device is available on eBay for around $25 new, used units can sometimes be found for $10 or even less. The receiver has waterproof case, magnet mount and comes with 6 foot cable. Another nice feature of this device is its 40mA current consumption. Here are some pictures of the unit – PCB, internal antenna, as well as front and back of the original packaging.
“Classic” GPS receiver sends and receives NMEA 0183 messages via serial port at 4800 bps. Modern GPS units often support faster speeds and vendor-specific messages. However, they mimic classic GPS unit behavior – at power-on they start sending basic navigation messages at 4800 bps. The following sketch outputs messages, received from Navibee GM720 GPS unit via its built-in PL2303 USB to serial converter connected to USB Host Shield. Full text of the sketch is available on gitHub, below is just a fragment where speed is set to 4800.
The OnInit() member function is called to change serial parameters after initialization. A lc structure of type LINE_CODING is declared on line 14. It is filled with baud rate (line 15) and number of data bits per byte (line 18) and then sent to Pl instance in line 20.
One of the main motivations for adding asynchronous CDC support code to rev.2.0 of USB Host Library was to be able to use cell phones in Arduino projects – establish simple data exchange via SMS, take pictures or connect to the Internet. Second hand phones are inexpensive yet quite capable. Also, m2m (machine to machine) SIM cards start at $4-$6/mo, some even allow for free incoming SMS. All that makes a cell phone an attractive communication option for hobby projects. In this post, I will be talking about basics of cell phone control using data port and AT commands. I will also present simple terminal emulator sketch – to use the code you will need an Arduino board, USB Host Shield, as well as USB Host Shield 2.0 library.
Modern (<10 year old) phones have standard GSM chip interface implemented and accessible via so-called “data port”. The oldest phones implement TTL level asynchronous serial interface by means of “custom” USB data cable, which is just proprietary connector on one end, standard USB connector on the other end, and USB-to-serial converter chip (almost always Prolific PL2303) between them. Newer cell phones have USB-to-serial converter built-in. Motorola phones usually terminate data port on standard mini-USB connector, others, like Samsung and Sony Ericsson, use proprietary cable. The USB-to-serial converter in these phones is almost always standard CDC ACM type.
Many functions of the phone can be accessed by AT commands, similar to commands used to control Hayes phone modems. Standard GSM commands are defined in 3GPP TS 07.07 (look for the latest version, which is 7.8.0). Cell phone manufacturers also define their own AT commands. In documentation AT commands are usually presented in uppercase, however, most phones accept lowercase just as well. A command shall be followed by CR,LF (usually Enter key). If a command is accepted, OK is returned, along with response. If command is not recognized, ERROR is returned. Some commands will be accepted in certain phone states and rejected in others. Continue reading Interfacing Arduino to a Cellular Phone
What started as a quick re-factoring effort transformed to a major redevelopment, but finally all pieces fit together tightly and I am pleased to announce that initial release of USB Host Shield library ver.2.0 has been posted to github. This new version contains several major improvements:
Only 5 Arduino pins are now required for USB Host Shield to function – 3 standard SPI pins (SCK, MISO, MOSI) and 2 remappable pins (SS and INT).
The low-level interface to MAX3421E has been re-designed. Arduino pin manipulation routines has been replaced with mechanism inspired by Konstantin Chizhov’s C++ AVR pin templates. As a result, low-level transfers became approximately 3.5 times faster. Also, pin reassignment can be done much easier by passing pin numbers into MAX3421E template during instantiation.
The high-level interface to USB devices has been re-designed as well. It is now possible to connect USB hub to the shield and have many devices on USB bus, up to 7 daisy-chained 8-port hubs plus up to 44 devices connected to hub ports left after daisy-chaining, memory permitting. Also, a standard mechanism of device initialization/polling/releasing has been added to enumeration.
Several minor code improvements has also been made. NAK_LIMIT is now tied to an endpoint – it is now possible to have NAK_LIMIT set to 1 for interrupt endpoint and 32000 for bulk endpoint of the same device simultaneously. Control transfer function now accepts callback in order to split long chunks of data, if necessary. inTranser() function now is able to return actual number of bytes received.
Support for several popular device classes has been added. Device initialization and event handling is now moved to a library specific to device class, therefore user application does’n need to do this and only needs to process actual device data. The following devices are now supported by the library code: Continue reading USB Host Shield library Version 2.0 released.
Soon after Google ADK announcement it was discovered that $300 Arduino-based ADK hardware kit (out of stock at the time of this writing) is not really necessary; the same functionality can be achieved with standard Arduino board and USB Host Shield. Today, one of the developers sent me a link to GoogleADK – site, which explains how to build Google ADK hardware from standard components and use it.
The site shows how USB Host Shield looks like when all headers are soldered in place. It also has Get Started page which gives step-by-step instructions on installing necessary software components on Linux box. Word of caution – the link on this page points to the product page of old rev.1.xx shield, even though all pictures show the current rev.2.0 one.
At present, the site is pretty lean but it is a good start nevertheless. I will be monitoring it to see if any new content would come up. Arduino-Android tandem offers very interesting capabilities and I’m hoping to see many cool Android-based projects soon.
Android Open Accessory Development Kit, announced on Google IO the other day is a hot topic. Android Open Accessory support, introduced in Android 3.1 (tablet OS) and backported to 2.3.4 (phone OS), allows external USB devices to interact with Android phone/tablet switched to so-called “accessory” mode. Because phones are USB functions (AKA devices) this accessory device must act as USB host. Arduino USB Host Shield has been around for couple of years providing USB Host functionality for standard and Mega form factor official Arduinos, as well as several clones. Luckily for all Arduino enthusiasts out there, Google decided to adopt this very architecture for hardware component of ADK. As a result, said enthusiasts now have well defined and documented code layer to interact with Android devices, ready to run on Arduino board of their choice. Well, almost.
The ADK code is targeted for ADK hardware component, which is just Arduino Mega 2560 and USB Host Shield combined on a single PCB. However, they decided to move some pins around; as a result in order to use the code with standard “Arduino plus Shield” setup certain code modifications are necessary. One such modification has been posted on Romfont. I tried it and the code works well, however, this approach has issues. First, it creates yet another distro. Second, the code modification exercise would have to be repeated each time Google releases new version of ADK. Finally, it’s difficult to have both standard and Google USB librares installed in Arduino IDE at the same time. Given all that, I decided to take different approach.
Google’s variant of USB Host Shield library differs very little from official library. The only significant difference is newInTransfer() member function of USB class, which returns real length of received packet. In order to support AndroidAccessory component in official library, I simply added this function to the library code and made a new release – it is now available on gitHub. I placed it into “dev” branch for now – it will be moved to “master” after a period of testing.
[ EDIT ] Here is a link to The Tx Project source code [/EDIT]
This is another RC car related post. This time, Santiago Saldana has created a device that allows you to control any RC car,plane,helicopter, etc. using any HID joystick. The “Tx Project” makes use of an Arduino, an Assan Hack Module, a HD44780 LCD, and a USB Host Shield v1.0. The project also makes use of a Trimersion Headset for FPV control of the RC Car, a Microsoft Sidewinder Racing Wheel, and a 900 Mhz Video transmitter / receiver. Code is open source and will be made available after beta testing, or upon request if there is interest. The code makes us of my MAX3421E and USB Host libraries as well as borrowing HID parser code from the LUFA project.
First video is from an earlier version, but demonstrates the devices flexibility in USB device input. The second video is from a presentation Santiago made at Wake Forest University’s Computer Science department.
Development of Arduino_Camera_Control library (which runs on top of USB_Host_Shield library written to support USB Host Shield ) continues at steady pace. Nikon point-and-shooters has been on a test bench for the last couple of weeks and they are already talking. Even more exiting is the fact that they are talking the language we already know – the plain old PIMA 15740-2000.
Arduino-controlled Nikon P100
It also looks like that PTP protocol implementation in all Nikons is very close to the standard with very few vendor extensions and it will be possible to use the same code base for both point-and-shoot cameras and DSLRs. In this article, I’m showing a lightweight implementation of Capture command for Nikon cameras. Unlike its’ sister sketches, EOSCapture and PSCapture, this one can’t really be called NikonCapture – keep reading to find out why.
The InitiateCapture command, which is part of standard PTP command set can be seen in PTPDevInfo output of several Canon PowerShot and all Nikon cameras – see, for example, Canon A640 section, line 82 or Nikon Coolpix S4000, line 47. Regrettably, PowerShots seem to require setting D045 vendor-defined property before this command will be accepted by the camera; therefore, PowerShot-specific class would have to be instantiated, adding significantly to program size. On the other hand, Nikons are happily executing InitiateCapture as-is.
The following sketch does what other “…Capture” sketches do – it takes a shot once a second second in an endless loop. What makes it different is that it doesn’t use any vendor-specific code, compiles in ~9K and can be loaded into Atmega168-based boards leaving plenty of room for another functions.
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
