About a year ago, while researching low startup voltage DC-DC converters I ran into Texas Instruments’ TPS61200. This monolithic synchronous rectifier boost converter has several nice features. First, the input voltage range starts at 0.3V; therefore, it’s possible to run the converter from low-voltage source such [...]]]>

1.2V to 5V DC_DC converter based on TI TPS61200

About a year ago, while researching low startup voltage DC-DC converters I ran into Texas Instruments’ TPS61200. This monolithic synchronous rectifier boost converter has several nice features. First, the input voltage range starts at 0.3V; therefore, it’s possible to run the converter from low-voltage source such as single solar cell or supercapacitor. Second, the converter is powerful – up to 1.8A for certain input/output voltage combination. (”Certain” is a key word here – see below for explanation). Another nice feature is the ability to down-regulate the output when Vin exceeds Vout; for example, you can configure the converter to run from single-cell Li-ion/Li-poly battery and output stable 3.3V over the whole 4.2V-2.7V Li-Poly range. In addition to all that, the controller has built-in undervoltage lockout feature – minimum input voltage, below which controller would shut itself off can be set with simple voltage divider. This feature comes handy when rechargeable battery is used as power source. TPS61200 also has pins for enabling/disabling and power-saving mode on/off. Device is manufactured in 2 fixed Vout configurations – 3.3V, 5V, plus adjustable variant. Maximum working input voltage is 5.5V, minimum output voltage for adjustable part is specified at 1.8V.

After much prototyping and testing I came out with a layout that works well. The result can be seen on title picture – Arduino Duemilanove board (running USB keyboard polling sketch ) , USB Host Shield, LCD display and USB keyboard all powered by single 1.2V NiMH AA cell. The circuit that makes it possible can be seen on the left side of the picture connected between the battery and USB B connector, which is used here as 5V power connector to the Arduino.

The run time of this setup from freshly charged 1800ma NiMH cell is 6 hours which makes it quite practical. It should be noted that when input voltage is much lower than output voltage, efficiency suffers ( see figure 8 in the datasheet. 3 NiMH cells in series or single-cell Li-Poly is much better for 5V output, even 4 NiMHs will work if load is light – in down conversion mode power losses in the converter increase and I found that the chip gets very warm with output current of 200ma or more while down converting.

LiPo33 closeup

Another non-obvious characteristic of this controller is maximum possible output current to input voltage relation. Figure 1 in the data sheet shows that for input voltages up to 0.6V output current is really small – less than 50ma. This is the current one should expect while running the converter from single 0.55V solar cell. Voltage drop due to battery discharging shall also be considered. For example, fresh Li-Poly cell has 4.2V terminal voltage. According to Figure 1, this gives output current of 1500mA. However, at the end of discharge (2.7V) max.output current drops to ~800ma and this current should be taken as maximum for the whole range.

The controller has built-in over-current and over-temperature protection so experimenting with heavy loads won’t kill it. I found it running not too hot with output current up to 1A. More current is quite possible when input to output voltage ratio is small and cooling is adequate.

Now let’s talk about choice of power sources. A pair of AA or AAA alkaline batteries will make good source for 3.3V generation. 3 will work well for 5V. As little as one can be used if weight and/or volume of a circuit has to be reduced. Absolute max.input voltage for TPS61200 is specified at 7V, therefore, for maximum run time a series of up to 4 AA cells can be used with big loss of efficiency at the beginning of discharge, until input voltage drops below output voltage. Also, solar cells and super capacitors can be used when loads are really light. Rechargeable batteries are another good option; however, since TPS61200 is capable of working with input voltage down to 250mv, special precautions must be taken when using rechargeables with this controller.

Draining rechargeable cell below its end-of-discharge voltage may cause damage to the cell. As a result, a cell may become non-rechargeable and Lithium cell may even overheat and catch fire. For NiMH cell, end-of-discharge is 0.8V; for Li-Poly cells recommended end-of-discharge is 2.5-2.7V. To work properly with rechargeable power sources TPS61200 has built-in undervoltage lockout circuitry – when voltage on UVLO pin drops below 250mV, the converter turns off. Therefore, desired end-of-discharge voltage can be easily set with voltage divider ( R3, R4 of the schematic). UVLO pin also has hysteresis of 50mv and this hysteresis gets multiplied by dividers’ ratio; for example, when UVLO is set to 2.5V, minimum turn-on voltage of the converter will be 3V. Capacitor C4 takes care of this issue by shorting resistor R3 during turn-on.

The closeup picture shows TPS61200-based DC-DC converter designed for 5V output and Li-Poly input. Blue part marked “0″ close to the low right corner of the PCB is a jumper across R5 (I’m using fixed-otput TPS61202 here) and two resistors placed along the edge of a board make UVLO divider. JST connector polarity is compatible with Sparkfun single-cell Li-Po batteries.

Project files can be downloaded from Downloads section. Also, PCB is available at BatchPCB. TPS61200 comes in 10 pin QFN package with thermal slug on the bottom of the package, which has to be soldered on the PCB for proper cooling. Other parts are size 0603 and 1206. Both surface mount and through-hole JST connectors can be used on the input side.

I’m getting ready to start producing this converter in 3.3V and 5V variants with 0.8, 1.6, and 2.5V end-of-discharge voltages. Please let me know if any other output or end-of-discharge voltages are necessary. Also, any other comments about this design are most welcome!

Oleg.

This is the status update on Arduino USB Host Mini development, announced 3 weeks ago. I received rev.0 PCBs last Saturday – BatchPCB is faster than ever! I made a test build (see title picture) and after fixing one major and several minor mistakes placed an order for what [...]]]>

First prototype of USB Host Mini

This is the status update on Arduino USB Host Mini development, announced 3 weeks ago. I received rev.0 PCBs last Saturday – BatchPCB is faster than ever! I made a test build (see title picture) and after fixing one major and several minor mistakes placed an order for what I’m hoping will be the final pre-production sample.

The prototype was built to sit on top of Arduino Pro Mini to make access to the parts easier during troubleshooting. On the final board USB connector is placed slightly further away from the pins; it will be possible to place Arduino on top of the shield so that the height of the “sandwich” will be less or equal to the height of USB connector.

In 2-3 weeks I’m hoping to finalize the design and start producing the USB Host Mini. Stay tuned!

Oleg.

This post announces starting of development of new Arduino USB Host Shield variant. There are several projects in the works (thanks, guys for letting me know!), where standard size Arduino board is too big. Since electronics of USB Host Shield is pretty simple, it was decided to shrink the board as [...]]]>

USB Host mini rev.0

This post announces starting of development of new Arduino USB Host Shield variant. There are several projects in the works (thanks, guys for letting me know!), where standard size Arduino board is too big. Since electronics of USB Host Shield is pretty simple, it was decided to shrink the board as much as possible. Here is the first iteration.

The initial revision of USB Host Shield in Mini form factor is shown on title picture, It is intended to be used with Sparkfun’s 3.3V Arduino Pro Mini. Intended applications include digital camera control devices, robots, as well as any other projects where size and weight has to be minimized. The Gerbers was sent to BatchPCB; I’m expecting boards back in couple of weeks. The main goals of this first prototype are manufacturability check as well as checking claims made below.

The Mini Host is simplified version of full-sized shield; only USB and GPIO are available. By default, VBUS is routed to VCC, therefore only self-powered USB devices are expected to function (even though I have at least one USB flash drive which works fine powered from 3.3V VBUS). I also provided extra pads to simplify signal re-routing, however, since there was no place left for jumpers a trace has to be cut instead. The same has been arranged for VBUS – if 5V power is necessary, Arduino Pro Mini/Shield combination can be powered with 5V on RAW pin, the VCC trace cut off VBUS and RAW and VBUS connected.

As soon as first prototype is tested, I will post CAD files and also make boards available at BatchPCB. Stay tuned!

Oleg.

Based on some discussion on the Arduino Forum, Richard has added this blog entry as work in progress on developing a library to support FTDI Serial port devices on the USB Host Shield. While cautious to publish at this early testing stage, the content here should help parallel developers.

My [...]]]>

FTDI232RL IC on a breakout board

Based on some discussion on the Arduino Forum, Richard has added this blog entry as work in progress on developing a library to support FTDI Serial port devices on the USB Host Shield. While cautious to publish at this early testing stage, the content here should help parallel developers.

My thoughts last year were that an FT232 driver for the Host Shield was not really useful. It seemed rather reverse to add a USB host plus a USB device to achieve something that can be done with a piece of wire. However USB is coming to be the baseline interface and is now the only interface offered on many serial devices.

USB Shield Hardware
Since my last blog update, Sparkfun have released their own version of the USB Host Shield. Great to have another source of the shield, with good stock at many International Sparkfun distributors. However they did add a couple of problems too:
Sparkfun swapped the RESET and the GPX pins from the original from Oleg. This means the shield will not work with the libraries from Oleg without a modification.
The current Max3421e_constants.h from Oleg has:

/* Arduino pin definitions for USB Host Shield signals. They can be changed here or while calling constructor */
#define MAX_SS 10
#define MAX_INT 9
//#define MAX_GPX 8
#define MAX_RESET 7

These work for the shield from Oleg, and existing published code and libraries without change.

However for the Sparkfun Shield they must be changed in Max3421e_constants.h, or optionally changed when the constructor is called to:


#define MAX_SS 10
#define MAX_INT 9
//#define MAX_GPX 7
#define MAX_RESET 8


To add further complication, In the FTDI code I will describe below MAX_GPX is used, so must be uncommented in Max3421e_constants.h or added as a #define in the sketch. Again this should match the shield type as above.

The other common problem with the Sparkfun shield is that it is powered differently from the shield from Oleg. The Sparkfun Shield and the connected USB device is powered from Vin via voltage regulators. While the Arduino 5V and 3.3V supplies can be provided by either Vin or Vusb, Vin cannot be provided by Vusb. This means the Sparkfun shield must have an external Vin supply to work, while the shield from Oleg does not need this.

Library Updates
There have been some library updated from Oleg over the last months to include a number of changes to support latest applications. The latest version from Oleg should be backward compatible to existing sketches and examples.
Here again, I will propose another addtional change to the usb.h library. The reason for this is that the existing devices which have been used on the USB Host Shield, all returned either a known number of bytes during an in transfer, or the data bytes contained the length within the data itself. The FTDI device, does not do this and sends a variable length packet, without length indication within the data. Thus we need to pass the data length back to the sketch in some other way.
To maintain backward compatibility I added an new version of the in transfer:
In usb.h
byte inTransfern( byte addr, byte ep, unsigned int* nbytes, char* data, unsigned int nak_limit = USB_NAK_LIMIT );

and in usb.cpp

/* Version with pointer to nbytes, to return actual number */
/* IN transfer to arbitrary endpoint. Assumes PERADDR is set. Handles multiple packets if necessary. Transfers 'nbytes' bytes. */
/* Keep sending INs and writes data to memory area pointed by 'data' */
/* rcode 0 if no errors. rcode 01-0f is relayed from dispatchPkt(). Rcode f0 means RCVDAVIRQ error,
fe USB xfer timeout */
byte USB::inTransfern( byte addr, byte ep, unsigned int* nbytes, char* data, unsigned int nak_limit )
{
 byte rcode;
 byte pktsize;
 byte maxpktsize = devtable[ addr ].epinfo[ ep ].MaxPktSize;
 unsigned int xfrlen = 0;
  regWr( rHCTL, devtable[ addr ].epinfo[ ep ].rcvToggle ); //set toggle value
  while( 1 ) { // use a 'return' to exit this loop
    rcode = dispatchPkt( tokIN, ep, nak_limit ); //IN packet to EP-'endpoint'. Function takes care of NAKS.
    if( rcode ) {
      return( rcode ); //should be 0, indicating ACK. Else return error code.
    }
    /* check for RCVDAVIRQ and generate error if not present */
    /* the only case when absense of RCVDAVIRQ makes sense is when toggle error occured. Need to add handling for that */
    if(( regRd( rHIRQ ) & bmRCVDAVIRQ ) == 0 ) {
      return ( 0xf0 ); //receive error
    }
    pktsize = regRd( rRCVBC ); //number of received bytes
    data = bytesRd( rRCVFIFO, pktsize, data );
    regWr( rHIRQ, bmRCVDAVIRQ ); // Clear the IRQ & free the buffer
    xfrlen += pktsize; // add this packet's byte count to total transfer length
    /* The transfer is complete under two conditions: */
    /* 1. The device sent a short packet (L.T. maxPacketSize) */
    /* 2. 'nbytes' have been transferred. */
    if (( pktsize = *nbytes )) { // have we transferred 'nbytes' bytes?
      if( regRd( rHRSL ) & bmRCVTOGRD ) { //save toggle value
        devtable[ addr ].epinfo[ ep ].rcvToggle = bmRCVTOG1;
      }
      else {
        devtable[ addr ].epinfo[ ep ].rcvToggle = bmRCVTOG0;
      }
      *nbytes = xfrlen;
      return( 0 );
    }//if (( pktsize = *nbytes ))...
  }//while( 1 )...
}

FTDI FT232 devices
The FT232 range of devices from FTDI is now fairly large and quite a lot of data is available on the FTDI Website.
Further information was taken from linux driver sources and other USB Host sources.
I did not get a chance to test devices other than the FT232B and FT232R at this time.

Blocking vs. Unblocking code
The eventual objective is to create a version of the serial library which supports the FTDI Serial port over the USB Host Shield. The existing serial libraries allow for blocking code, especially when waiting for input. It was therefore decided to use interrupts to perform the regular tasks required for the USB protocol layers, so the FTDI libraries could appear identical to the existing serial drivers.

The MAX3421e MAX_GPX pin is set up to send a pulse output at the SOF rate of the USB (1 per ms) and this generates a pin change interrupt on the Arduino. This interrupt routine then performs the required USB tasks without need for the sketch to repeatedly call them. Some protection is also added to ensure that USB transactions generated outside the interrupt routine and any associated temporary data, are protected from the interrupt routines.

Buffer Management
Seperate data buffers are created for the transmit and receive directions.
The transmit buffer is filled by the calls to send a serial byte via the FTDI. If the buffer is filled by the byte the data is sent over the USB immediately, other wise it is sent at the next SOF interrupt.

Calls to read the receive buffer check for any characters locally, and return them if found. If there are no characters in the local buffer, a read is made to the remote FTDI device to check if any data is ready there. This process is to reduce the local buffer requirement. The first two bytes returned over USB are status bytes, not data, and these are also sent at regular intervals without data. I am not sure whether this is the best way to handle the receive buffers.

Code is here on github

Developer Si Li shared his version of PTPDevinfo.pde, which fits into older Aduinos. Si wanted to get PTP device information from Canon EOS 500D, but he only has 16K Seeduino at hand. So he stripped devinfoparser off all unnecessary strings leaving only ones essential for [...]]]>

Blue Arduino USB Host Shield tied to telephoto lens mount

Developer Si Li shared his version of PTPDevinfo.pde, which fits into older Aduinos. Si wanted to get PTP device information from Canon EOS 500D, but he only has 16K Seeduino at hand. So he stripped devinfoparser off all unnecessary strings leaving only ones essential for parsing Canon EOS camera device info.

The modified devinfoparser files are available from “Downloads” section.

A reel of ADuM4160s

Lynxmotion AL5D robotic arm

I made (hopefully) last iteration of magnetic probe amplifier board. Schematic remains the same. Layout, however, is slightly different. First, I made it more narrow to better fit Tektronix 7000-series time base plugins external trigger input, as can be seen on the title picture. Second, the amplified [...]]]>

Magnetic probe amplifier connected to external trigger input

I made (hopefully) last iteration of magnetic probe amplifier board. Schematic remains the same. Layout, however, is slightly different. First, I made it more narrow to better fit Tektronix 7000-series time base plugins external trigger input, as can be seen on the title picture. Second, the amplified probe output is made via SMx type connector – PCB-mounted SMA and SMB all have the same footprint. I used straight SMB since I have a surplus of Tektronix P6041 cables. The board layout permits soldering right-angle connector here as well. This arrangement is much handier than previous one.

Since publishing initial design I haven’t seen much interest in it, so instead of ordering a bunch of PCBs I made this board available on BatcPCB Marketplace. Schematic and board layout in Eagle 5.x format are also available. I built one board and haven’t found any errors on copper or silkscreen – if you find any, please let me know.

Oleg.

I found this little video while looking for ideas for my digital camera controller. There is also project description and summary page. Device consists of Arduino board mated with Asynclabs WiShield controlling shutter release of SLR camera via cable release port. Arduino runs TCP/IP stack and Web server while access to pre-focus, time [...]]]>

I found this little video while looking for ideas for my digital camera controller. There is also project description and summary page. Device consists of Arduino board mated with Asynclabs WiShield controlling shutter release of SLR camera via cable release port. Arduino runs TCP/IP stack and Web server while access to pre-focus, time interval and other settings is done via web browser on an iPod. In addition, it is possible to release shutter using signal from proximity sensor or even set conditions based on states of different Arduino pins.

The web interface is well designed – watch this little movie and see it for yourself. There is also a demo page, where you can play with controller functions. The “Adm” page is my favourite. I’m looking forward to see the code, which author is going to publish soon.