|
|
By Oleg Mazurov  Arduino connected to Nexus S
Since Kristian’s release of SPP service for USB Host 2.0 library I got many e-mails with questions about Bluetooth serial communications in general and using the SPP class in particular. While establishing a Bluetooth connection is quite easy when using PCs/smartphones/tablets, the Arduino implementation is less user-friendly (for a good reason) and somewhat confusing. This article is intended to be a short tutorial of Arduino USB Bluetooth connectivity using an Android device as a peer – in my opinion, the simplest one to set up and communicate.
To follow this tutorial, you will need the following:
- An Arduino board ( I sell them too )
- full-size USB Host Shield 2.0
- USB Host Shield 2.0 library downloaded and installed in your Arduino library directory
- An SPP example sketch
- Bluetooth dongle – see below for detailed discussion
- Android device – a phone or tablet. The accuracy of this tutorial has been checked on Nexus S phone and Nexus 7 tablet, both running Jelly Bean 4.1.1 OS.
- A Bluetooth terminal emulator app for Android – I use Blueterm
The hardware setup is shown on the title photo (click on it to make it larger). It is a good idea to use external power supply at least in the beginning – some Bluetooth dongles are not happy when powered together with Arduino board/USB Host shield from USB cable. On a side note, it is always a good idea to use external power supply while experimenting with USB devices, especially when using current Arduino boards with their weak regulators. Also, Bluetooth code requires plenty of resources. The example used in this article compiles in ~24K and even though it would work on standard Arduino, any meaningful project will likely require a bigger board, like a Mega.
Continue reading Using USB Bluetooth dongle on Arduino to connect to Android phone
By Oleg Mazurov  Bulb mode activation code screenshot
Last week my friend Hans and I spent some time in my lab exploring which features of his Nikon D300 are available via PTP protocol. Hans is working on extended range HDR-capable intervalometer and he needed to find out a way to switch his camera into bulb mode using Arduino board and USB Host shield. After we finished I realized that while bulb mode is not tricky to activate, it is not obvious either and no hints exist in the code and examples showing how to do this. This short article is intended to fill the void.
In PTP, shooting parameters, such as shutter speed, aperture, ISO, etc. are changed by setting certain device property. For each parameter there exists a list of allowed values of this property, each property value corresponding to a parameter value. For some parameters, property and parameter value lists are dynamic. For example, starting and ending aperture values are different for different lenses; additionally, the aperture step can be changed in camera settings. Stepping can also be changed for shutter speed and exposure compensation and this can also happen during PTP session if a photographer decides to switch modes – in this case a property may become unavailable, like shutter speed in aperture priority mode. Therefore, before changing a property value for one of these parameters it is necessary to somehow retrieve a list of available property values.
The property value list retrieval mechanism is slightly different for different cameras. On Canon DSLRs, a special event is generated by the camera and sent back to PTP host at the beginning of the session and also each time camera mode was changed, lens were swapped and so on. The application needs to track those events and constantly maintain current value list for each property. On Nikon DSLR, it is possible to simply get value list for a property any time it is needed. To save memory, the list is not stored but simply requested from the camera each time a property needs changing. It is combined with actual property change in two templates – StepUp and StepDown. If you need to increase, for example, shutter speed – call StepUp. If you need to decrease it, call StepDown.
If you “step up” shutter speed on Nikon DSLR manually, the last 2 values will be 30 seconds and bulb. If you step up shutter speed using StepUp method using Nkremote sketch it will stop at 30 seconds. This happens because bulb mode is not included in the list of available property values for shutter speed but simply defined as 0xffffffff. As a result, StepUp doesn’t know that another value is available. It is still possible, however, to set the property directly and I will show you how to do it.
Continue reading PTP 2.0 library function turns on Bulb mode on Nikon DSLR camera via USB
By Oleg Mazurov  Stack of shields This is Part 1 of 3-part series of articles. Part 2 talks about hardware modifications while Part 3 explains how to deal with incompatible data formats.
Serial Peripheral Interface AKA SPI bus is a popular way to communicate peripheral IO controllers to a micro over short distances and many microcontrollers have SPI interface built-in, including Arduino. Consequently, many Arduino shields use SPI to communicate to Arduino; USB Host shield is one of them. When more than one such shield is connected to Arduino, several SPI slave devices start sharing SPI bus. SPI is designed to allow bus sharing and if correct signals are present at correct moments all devices get along just fine. In practice, however, nothing usually works as desired, shields are interfering and fixing it requires hardware and software modifications. I was recently tasked with connecting 3 SPI slave devices to Arduino and this article shows how I did it.
A reader is expected to be familiar with SPI bus in general and Arduino implementation in particular. In addition, Tronixstuff has SPI tutorial, which is a little bit more user-friendly.
1. The problem
Arduino shields with SPI interface generally have 2 sources of interference – 1 on hardware level and one in software.
SPI bus consists of 3 shared data lines – SCK, MISO and MOSI, plus one “Slave Select” AKA SS line per each device. All transfers are initiated by the host and proceed in both directions simultaneously. Only one device, the one whose SS line is asserted low, is participating in the transfer by driving its MISO line – all other devices are expected to have their MISO line in a third state.
Due to peculiarities in Atmega SPI implementation, designers of Arduino shields prefer using default SS line, which is assigned to pin 10 on standard-sized Arduino boards. If two shields are driven by the same SS, they will have their MISO line active at the same time. Best-case consequence of it is only one of the shields in the stack being able to communicate, worst-case is destroyed MISO line transmitters. Therefore, the first step in any multi-shield SPI project is to make sure each shield uses its own SS line and never expect this to be the case in default configuration.
Continue reading Running multiple slave devices on Arduino SPI bus
By Oleg Mazurov  Compatible Bluetooth Dongles [EDIT] Here is Kristian’s post with more detailed explanation of the example sketch.[/EDIT]
Kristian Lauszus from TKJ Electronics, a man behind PS3 and Xbox360 code in USB Host Shield 2.0 library did it again! I’m pleased to announce that the library now supports standard RFCOMM/SPP implementation, thanks to Kristian’s work.
RFCOMM is basic Bluetooth service and SPP is serial port emulator on top of this. The code allows interfacing standard USB Bluetooth dongles to Arduino boards using USB Host Shield v.2.0. Bluetooth dongles (the ones I’ve tested can be seen on a title picture ) are widely available, cost much less than specialized serial Bluetooth modules (I have a couple of powerful class 1 dongles bought on eBay for $1 shipped) and won’t occupy precious serial port on Arduino board. Even though most dongles are compatible with the code, there are also some that don’t work. The code has been tested for compatibility with all major OSes – Linux, MacOS and Windows 7, as well as Android devices. It will likely work with any RFCOMM client, however, more testing is necessary.
The example code is a simple SPP server. It needs to be started before attempting to connect to it from a PC/phone. Once started, the state of the server is printed on a terminal. After that, the device can be discovered/paired/connected to; it is then possible to send characters from one device to the other by means of a keyboard. In the coming days I will write a series of posts with details of connecting different Bluetooth devices to Arduino. In the mean time, enjoy the code! Please give it a try and let me know what you think.
Oleg.
By Oleg Mazurov  Logitech joystick connected to Arduino HID report parsing explained in the previous article works pretty well with properly aligned HID reports. The analog controls are placed on a byte or word boundary and buttons occupy dedicated fields. The majority of HID devices are designed this way, however, some other devices are not that simple to interface and today I’m going to show how to handle one of those.
A Logitech Extreme 3D Pro joystick is one nice HID device. It is good looking, well-built, and have a twist handle, which adds third axis to a stick making this model popular among FPV fliers since you can control pitch, roll and yaw with one hand. Also, X and Y axis are 10 bits which gives good precision. There is one problem with this joystick – its input report.
Logitech, in its infinite wisdom, decided to pack all the high and low resolution analog controls plus 12 buttons in 6 bytes of input report. The report looks like this – 10 bits of X, 10 bits of Y, and 4 bits of hat switch. After that, things become easier – one byte of Rz AKA “twist handle”, one byte of buttons, one byte of throttle (called “slider” in the report), and finally, one partially filled byte holding the rest of the buttons. Take a look at the screenshot below – two most important controls are not byte aligned, therefore, simple straightforward parsing of the report is not possible. Also, USBHID_descr won’t show this report correctly.
To demonstrate how to deal with this report I wrote a simple Arduino sketch. It was made by modifying an example from the previous article. I also made it as simple as possible – as soon as any of the controls changes its value, new report is printed on the serial terminal. The sample output is shown below followed by code explanation.
Continue reading Using Logitech Extreme 3D Pro joystick with Arduino HID library
By  This article focuses on how to use the existing USB code library and HID report descriptor info to implement joystick functionality. Human readable HID report descriptor and report information can be easily obtained using USBHID_desc.pde sketch – see previous article for details. This information will help you getting field details such as size and count info. Also, if you don’t have Arduino Mega or 2560 to run USBHID_desc, report descriptor for your device can be obtained using one of many PC tools known as USB analyzers, or even the official usb.org device verification tool. This article is written by Alex Glushchenko – a developer behind second revision of USB Host Library as well as majority of device support code.
As you may already know report is a data structure used by HID device to return the information about the certain device parameters such as joystick coordinates or button events, or receive new settings such as switching on/off LEDs on keyboard.
Report descriptor is a data structure which describes report or reports, if there are few in number, field sequence, sizes and counts. Each report descriptor consists of several items. Each item describes some field property. I am not going too deep into details on items, explaining only the most important ones which are absolutely necessary in writing your own report parser.
The items usually describe type of field (input/output/feature), minimum, maximum field values, units, value meaning (usage) etc.
Continue reading Developing Arduino code for HID Joystick
By Oleg Mazurov 
Human Interface Device class of USB devices has a unique property – a report descriptor which contains information about data that device is sending to the host as well as data that can be sent to the device. This property allows for variety of devices – keyboards, mice, joysticks, digital scales, uninterruptible power sources, GPS receivers, and even toy missile launchers to belong to a single class – HID. A vendor just needs to pick a usage table which contains controls similar to vendor’s device – every OS has a generic support for HID devices so in most cases specific device driver is not necessary. The report descriptor again makes this possible – it contains definitions or report fields therefore a generic parser can process reports from any arbitrary HID device. However, this generic parser will take too much space on small microcontroller systems such as Arduino due to the amount of constants that needs to be present in the program code.
It shall be noted that a HID report itself is a simple structure of fixed fields and when this structure is known a very lightweight parser can easily be developed. HID development in legacy USB library has stopped at this point; I thought people will just take a look at the spec and write report parser for their device. It soon became evident that very few are actually willing to do this and in rev.2.0 of the library the HID report parsing is semi-automatic – a report descriptor has to be analyzed first using USBHID_desc utility presented in this article and then actual reports for the device can be parsed using library facilities (an article about coding report parsing is here).
Continue reading Visualizing HID device reports and report descriptors
By Oleg Mazurov  A MOSFET controlling VBUS
Today I want to show a simple USB Host Shield 2.0 modification which allows controlling power to USB peripheral. I learned this technique from Camille’s comment to one of digital camera USB control articles. In short, the idea was to cut VBUS connection between USB host and peripheral, simulating disconnect state. P-channel MOSFET, inserted into VBUS, worked as a switch. I designed this capability into USB Host Shield 2.0 but never needed the functionality therefore this useful feature was left undocumented. Recently I started working with very interesting Nikon P&S camera which can be turned on and off with VBUS power so I finally made this modification. It is very simple.
Take a look at the title picture (click on it to make it larger). The modification uses existing VBUS power select pads of the shield. Out of the box, the one labeled 5V is shorted with solder bridge. First step is to remove this bridge with a solder wick so both pads are clean.
It can be seen that a MOSFET in SOT-23 package fits nicely on those pads (I’m using FDN306P). Drain and source pins are soldered to VBUS and 5V, respectively, and gate, which hangs in the air, is routed to an unused digital pin via an 1M resistor. When digital pin is low the MOSFET conducts. When digital pin goes high the MOSFET switches off disconnecting VBUS from the peripheral.
If you are going to drive high-power peripherals, like digital cameras or phones, it is a good idea to add some capacitance to 5V. I’m using 220uF low-ESR organic polymer tantalum cap in 1210 package which fits nicely on 0.1″ spaced 5V and GND pins of the shield; an ordinary leaded 100-200uF aluminum capacitor will work as well.
Oleg.
By Oleg Mazurov  A fragment of PS3 Bluetooth code
I’m quite pleased to announce that ever-popular Sony PS3 game controllers are now supported by current (rev.2.0) USB Host Library. Kristian Lauszus from TKJ Electronics developed a library to interface with Dualshock 3, as well as Move Navigation and Motion controllers via a Bluetooth dongle (only CSR-based ones are supported at the moment). This library has been merged into the main code and I will start maintaining it as soon as my Dualshock 3 arrives.
Sony PS3 controllers are advanced versions of ordinary HID joysticks. They can be interfaced via USB or Bluetooth, the buttons can be read as analog or digital and controller contains rumble motor which can be activated remotely to indicate a hit, for example. The controller also contains a gyroscope and accelerometers so it is possible to control a robot by simply waving and/or rotating the controller.
Kristian got his inspiration from Richard Ibbotson’s articles, as well as works by Tomoyuki Tanaka and others (full list can be found in PS3README file). His Wiki page gives implementation details, communication protocol, differences between controllers, as well as plenty of links to other sources of PS3 controller interfacing knowledge.
Kristian developed this library as a part of his Balancing robot project. The project is very well documented – if you are interested in robots, PID or remote control, please take a look. I also enjoyed watching this video presentation, give it a shot to see balancing robot in action.
Oleg.
By Oleg Mazurov 
Fresh update of USB Host Library 2.0 has just been posted to GitHub. The primary purpose of this release is to maintain compatibility with Arduino releases – the USB Host Library is now compiles in 1.0 as well as pre-1.0 versions of Arduino IDE. Enjoy!
Several important changes have been made to the code, some related to 1.0 compatibility and some not. The library examples were all tested and corrected, the information below is intended for developers using the library in their own projects:
- PL2302 driver.
Arduino 1.0 defines PL symbol internally (thank you, Paul for finding this out!), therefore, I needed to change name of Prolific class driver. The new name is PL2302; I updated library examples to compile correctly, if someone uses this class in their own development, the right way to define an instance of Prolific device is now PL2303 Pl(&Usb, &AsyncOper);
- NAK handling.
A bug preventing long polls of an endpoint has been fixed. Previously, if bmNakPower member of epInfo structure was left unitialized the transfer to this endpoint would stop after receiving a single NAK. With current version, the endpoint would be polled for up to 5 seconds. This is rarely desirable, so please initialize bmNakPower with USB_NAK_DEFAULT or USB_NAK_MAX_POWER. If a single poll is desired, as is often the case with interrupt endpoints, specify USB_NAK_NOWAIT and if more than maximum number of NAKs (up to 5 seconds) is necessary, specify USB_NAK_NONAK.
- Code speed.
An unnecessary delay of 20ms has been found (thank you, Alex for discovering this!) and removed from USB::setAddress() member function. As a result, every USB transfer is now 20ms faster. While generally a good thing, it could inadvertently affect data exchanges with slow endpoints. If after upgrading to the current version you start seeing more NAKs, that’s probably why.
One nice thing about Arduino 1.0 is built-in PROGMEM support for strings. It is now possible to free about 300-400 bytes of RAM by redefining USBTRACE and USBTRACE2 macros used in debugging output (thank you, John, for the tip!). For example, USBTRACE (Serial.print(F(s))) will move all USBTRACE strings to PROGMEM. The code size will increase so be careful with this feature if your code size is close to the limit for your Arduino board.
This is the end of announcement – download the code, play with it and if you have any issues please share your findings in the comments.
Oleg.
|
|
