|
|
 Scanning barcodes using Arduino and USB Host Shield An addition of Human Input Device Class support to USB Host Shield library 2.0, announced several days ago allows using powerful and inexpensive input devices with USB interface in Arduino projects. Sample sketches demonstrating sending and receiving data to one of the most useful HID device types – boot keyboard/mouse, has been released along with the library. The beauty of boot protocol lies in the simplicity of device report – a data packet containing information about button presses and mouse movements. However, samples were designed to demonstrate all features of the class and because of that, they are somewhat heavy. In real-life applications, it is often not necessary to implement each and every virtual function – only what is needed. In today’s article I will show practical application of HID boot device building a simple gadget.
Originally, HID boot protocol was meant to be used with keyboards and mice. When USB became popular, other keyboard-emulating devices, such as barcode scanners and magnetic card readers have been migrated from PS/2 standard to USB while keeping their keyboard-emulating property. As a result, many modern “not-so-human” input devices behave exactly like a keyboard including boot protocol support. A gadget that I demonstrate today is portable autonomous barcode scanner built using Arduino board, USB Host shield, handheld USB barcode scanner and LCD display (see title picture). The operation is simple – when handheld scanner button is pressed, it scans the barcode and sends it to Arduino symbol by symbol. Arduino then outputs these symbols on LCD display. LCD is erased before outputting each new barcode by tracking time between arrival of two consecutive symbols. To keep the code simple, I intentionally did not implement any data processing, however, since Arduino sketch for the gadget compiles in just a little over 14K, there is plenty of memory space left for expansion.
Continue reading Connecting barcode scanner to Arduino using USB Host Shield
 HID r.2.0 released I pleased to announce that after a long and difficult development period Human Input Device AKA HID class support has been added to USB Host Shield Library r.2.0 and is available on gitHub – I suggest downloading the whole directory, since some modifications has been also made to core files to accommodate a new class. HID devices include popular devices like keyboards, mice, joysticks, game controllers, bar code scanners, RFID and magnetic card readers, digital scales and UPSes, to name a few.
I previously wrote about interfacing to HID devices here, here, and here. The code examples in these articles were written for legacy USB Host Shield library and can’t be compiled with current revision, however, the basic principles are the same – the device is periodically polled by the host and sends back data block called report containing changes in device controls (buttons, switches, jog dials etc.) since the last poll. Even though different devices have different report formats, for a certain device, report format is stored in the device in data structure called report descriptor. Therefore, it is possible to learn about device controls from the device itself by parsing its report descriptor.
There is one special case where report format is known in advance. Almost all HID keyboards and mice support so-called boot protocol intended for communication to very simple systems like PC configuration screen when computer runs from BIOS. Keyboard boot protocol report consists of 8 bytes containing state of modifier keys (CTRL, SHIFT,etc.) in the first byte, second byte being reserved, and up to 6 key scan codes in the rest of the report. Mouse boot protocol report consists of 3 bytes, first of which contains state of left, right and middle buttons and other 2 store X and Y travel since last poll.
In many cases boot protocol capabilities are more than enough for an Arduino project; for this reason, boot protocol class is the first to be released. To demonstrate operations of this class, 2 simple sketches has been developed, one for mouse, another for keyboard.
Continue reading HID support for USB Host Shield Library 2.0 released
 Focus Stacking Assistant var.Mini After spending a week with focus stacking assistant I realized that I need more units. I’d like to have one unit dedicated for studio work, another to carry in camera bag and yet another one to control my Nikon (code for which I’m hoping to finish soon). Full-size Arduinos are big and expensive and I wanted this controller to be cheap and portable so I built my next controller using Arduino Pro Mini 3.3V, USB Host Mini, and a small home made PCB with buttons and LED. Finished mini-assistant can be seen on title picture and uses the same code as its big brother. What follows is a build log of mini-controller. It follows traditional layout, used, for example, here – a sandwich where Arduino Pro Mini sits on top of USB Host Mini. In addition to that, I needed to add another board on top of the sandwich to carry control and indication bits.
 Step 1. The base.
Continue reading Focus stacking assistant var.Mini – build log
 Focus Stacking Assistant [EDIT] Here is a build log of mini-variant of this device.[/EDIT]
One of my favorite shooting techniques is focus stacking. Many pictures on Circuits@Home site are made using this technique. I use Helicon Focus for post processing and even though this program has camera control built-in, it obviously requires a computer close to the object of shooting. In order to be able to control my camera in the field, I wanted to replace a laptop with simple lightweight controller able to move focus of camera lens and take pictures between steps. In this article, I will show how to build one from Arduino, USB Host Shield and several small parts.
Finished circuit can be seen on the title picture. As you may already have guessed, the sequence of shots used to produce the picture has been made with the very unit depicted on it. Focus stacking assistant is controlled by 3 buttons: first moves focus towards the camera, second moves focus away from the camera, third button starts shooting sequence. Long press on focus move button sets “near” of “far” points, after both points are set shooting sequence can be run – it always starts from “near” point. The sequence can be stopped at any time by pressing on any of focus move buttons. It is important to understand that after a point is set, subsequent focus moves must be performed with focus move buttons only.
The controller can also be set to “free run” mode. Long press on third button starts shooting sequence from current lens position (which in this case can be set by hand using lens’ focusing ring) towards infinity and will run indefinitely. It can be stopped at any moment by pressing on a focus move button.
A single LED shows states of the controller. Short blink once a second indicates “idle” state – controller is connected to the camera, PTP session is open. Continuous frequent blinking means some kind of an error – most likely, controller not being able to initialize the camera or open PTP session. 3 short blinks act as a feedback to long press, focus move, etc. Additionally, more detailed diagnostic is output to Arduino serial console.
Even while connected to the camera, Focus Stacking Assistant allows camera buttons to function as usual. For example, camera LCD can be turned on and zoom area can be moved to the area of interest and then zoomed in to help focusing. Shooting mode, as well as aperture/shutter speed/ISO can be changed. It is also possible to access or erase images on the card and perform other manipulations as necessary.
Continue reading Focus stacking assistant for EOS cameras
In this article I’ll show how to build Wireless EOS Controller designed by Manishi Barosee. I’m building it for my Canons and if I like it, I’ll see if it’s possible to modify it for other camera systems. My controller is built around full-size USB Host Shield instead of Mini which Manishi used – I’m going to do some debuggung and need space to connect probes. Also, full-size shield is much easier to work with.
The design of Yanis is simple yet elegant. It consists of Arduino board, USB Host Shield and serial Bluetooth module. An Arduino sketch reads the serial port, generates camera control commands and sends them to the camera over USB. The Android application acts as a UI for the controller and sends control data over Bluetooth. Here is very basic schematic drawing of Arduino part of the controller showing necessary connections. USB Host connections are described in hardware manual and Bluetooth module connections are shown in detail below.
I’d like to start with radio link. The Bluetooth module used in this build is RN-42 from Roving networks. It is 3.3V device and its pins are not specified as 5V tolerant which means that Tx pin of standard 5V Arduino can’t be connected directly to Rx pin of [my] RN-42. Fortunately, the 5V to 3.3V level shifter on USB Host shield has 2 extra gates and I will be using one of them to “condition” the Tx. To do this, I need to cut ground trace going to pin 9 of D6 (marked ‘HCT’ on the PCB), connect it to Arduino pin 1 and then connect pin 8 of D6 to Rx of RN-42.
 Cut pin 9 |
 Tx to level shifter |
Continue reading Building YaNis Android Wireless EOS Controller
 RN-42 paired to an Android phone
Bluetooth modules from Roving Networks are popular among DIY enthusiasts – they are small, powerful and cheap. They are used in many projects; I’m currently building Yanis Android Wireless EOS Controller which uses Bluetooth module for communication between Arduino and Android phone. I know from experience that radio links are not always easy to establish and sometimes hard to troubleshoot, that’s why I have the habit to test radio component in stand-alone mode before other pieces of the project. In this article I show how I do it with RN-42 serial Bluetooth module using simple setup and test procedure. Other Bluetooth modules can be tested in similar fashion.
In general, any Bluetooth link is established in two steps. First is called “pairing” and the result of it is an exchange of credentials, which are then stored on one or both devices. Usually, pairing needs to be performed only once – for all subsequent connections stored credentials are used. Second step is actual connection – an application on one device connects to the other device and data exchange starts.
In order to test my RN-42, I need to somehow power the module and then be able to send and receive serial data. To achieve this, I made couple connections using pieces of thin wire (actually, cut-offs of resistor pins), which can be seen in detail on the picture below. Power connector for small LiPo battery is comprised of two wire strips on the right. A serial loopback, which connects TX and RX pins (more on this later) can be seen on the left. Title picture shows the module with battery connected.
When all necessary soldering was completed, I powered the RN-42 using small LiPo battery paying special attention to polarity and went to Network Settings on my phone. First, I made sure Bluetooth is checked and then went to Bluetooth Settings and started Scan for Devices. By default, RN-42 starts in discoverable mode on power-on so there is no need to do anything special. When device is discovered, I select it and enter 1234 as pin. When device is registered as “paired”, I can check the data transfer.
To send and receive serial data over Bluetooth, I need terminal program. There are several applications on the market, my favorite is BlueTerm. To check data transfer between RN-42 and Android, I start BlueTerm, connect to RN-42 and start typing. If RN-42 works correctly, characters I type will appear on the screen.
 RN-42 connections
This happens because TX and RX pins on Bluetooth module are shorted together by a loopback wire. Data sent from the phone will appear on TX pin, then RX pin, then sent back to phone and then to the screen. To see if this is indeed the case I disconnect power from RN-42. Character echoing should stop.
This is all that needs to be done to check the module. Troubleshooting is also easy. If powered-on RN-42 won’t appear in discovery, check polarity (reverse polarity survival is not guaranteed – don’t make this mistake or you may need a new module). If polarity is correct, check battery voltage with multimeter. If voltage is within specs, check if it applies to correct pins. If everything is good but no pairing occurs, replace the module. If device is paired but no characters are echoed in terminal, check loopback pins and soldering quality.
When I confirm that my module is good, I can continue building the controller. I’ll write another post as soon as I get it working.
Oleg.
|
|
