Wednesday, March 30, 2011

Boba Fett project

Time ago a friend of mine, Molly, asked me to help her to prepare some electronic effects for a costume  : Boba Fett from Star Wars.
At the time I prepared some articles to document the work.
Here the material I prepared, edited for the blog.  This is the first article, others will follow.


Basically there was two areas of the costume where I helped :

  1. Rangefinder movement
  2. Rangefinder lights effects


The rangefinder is, in the character fiction, a device capable to identify and point a target.
Physically is a funny shaped box, with some flashing lights and a screen, mounted on the top of a rod/pole, on the side to the helmet.
When not in use it rest vertically. When in use it is lift down in front to the visor.
There are two flashing lights in front and a "screen" in the back of the rangefinder, just in front of the visor.
The lights are turned on when the rangefinder is lifted down.


The rangefinder has three lights, supposedly going on when in the horizontal position.
Two flashing lights in front and one green or white light inside, in order to simulate the light from a monitor screen .
It is possible to design different circuits capable to drive the lights.
  • simple
  • classic
  • flexible


The circuit is quite simple and "classic" and can even be minimized using special components, like this :

The circuit is extremely simple.
A 3V coin battery to power supply 3 LEDs and a tilt switch turn on the LEDs when the rangefinder is horizontal.
Two of them will be "flashing LED", i.e. LED with already included an oscillator, like this one found on AllElectronics.

Pros :
  • very very simple
  • not critical
  • doesn't even need a PCB
Cons :
  • the flashing LEDs can not be controlled
  • battery can not last long


Alternatively, is possible to build an astable oscillator, using a couple of transistor, so to have the LEDs flashing alternatively and not in "simil sync" as the previous circuit.
Adopting an astable oscillator is little bit more complicated and it require a PCB (a piece of sperimental board is ok).
Something like that :

The circuit seems more complicated but is really not.
Is a "classic" astable multivibrator based on two transistor NPN who drive two normal LEDs (D1 and D3).
D2 is a green or light LED.

Pros :
  • the flashing LEDs are controlled
  • the battery can last longer
  • probably is the circuit used on the "original" costume
Cons :
  • require a little PCB to host the components
  • require little bit more work to be done


The third way to drive the LEDs is, for my taste, the better.
Using a microcontroller, we can achieve the maximum about flexibility and an easy to program and  change effects.
The hardware is very very simple, based on a MSP430F2012 microcontroller.

Simply we can connect the three LEDs to the micro I/O ports using the micro PCB.
After that is only matter to write a simple firmware capable to drive the LEDs.
It is  quite easy to set up any pattern and also include some special effects on the one that simulate the screen.

The 3 LEDs will be connected to 3 I/O pin, programmed in output mode.
Another pin will be used to connect the tilt switch.
The tilt switch is not used to power supply the micro, because is not capable to give a neat on/off signal.
In this way the micro will read the tilt switch, acting also as filter.
When  the tilt switch will indicate a off position, the micro will be placed in low power mode.

Pros :

  • the flashing LEDs are controlled
  • possibility to create many effects, even using PWM to control brightness
Cons :
  • require a little PCB to host the components
  • require little bit more work to be done
  • the battery life is not high

The rangefinder is attached to the helmet.
Since the goal is to have it moving automatically, from the vertical position to the horizontal one, a motor and gears will be needed.
The main challenge for the mechanic part, is the dimension and the torque needed to move the rangefinder.
Because the dimension, some limits will exist :
  • motor/gears
    The motor and the gearbox necessary to increase the torque, trading away the speed, must be small as possible.
  • power supply
    For the same reason, the motor and the circuit will need to operate using the smallest possible amount of batteries.
    The space in the helmet is not big
  • electronic
    The motor need to be driven by an electronic circuit, capable to run it in both directions and possibly with different speed.
    Also the electronic should be small as possible.
  • no wires
    Any necessary wire should be hide as much as possible.
    So for example, the rangefinder lights will be self enclosed in the top box
    The same for the motor control. Because of that, a remote control will be included so to activate the motor remotely.
The Rangefinder is placed on the top of a rod, connected to the helmet.
Usually is in vertical position but can be lowered in the horizontal position.
The idea is to make the Rangefinder move from vertical to horizontal, and back, automatically. The electronic to control the movement, will be based on a MSP430F2012 Texas Instrument microcontroller plus other components.

Like the lights, there are different possible choices.
The first is to use a normal DC motor, coupled with some gears.
The second, the one we adopted, uses a servocontroller.

  • DC motor
  • Servo

DC Motor

A RF receiver will provide the input for the microcontroller (a Texas Instrument MSP430F2012), that will drive a H bridge capable to power the DC motor in both directions.
The DC motor, geared, will in the end move the rangefinder up or down.


The alternative to drive directly the motor and play with a gearbox, is to use a servo.
A "servo" is a "servomotor". Basically a "ready to use" DC motor, with a gearbox and an electronic circuit capable to drive it.
The advantage is that the motor is already handled by an electronics, easily controllable by a microcontroller.
There are many different models of "servo". They are used in the models (planes/boats/cars) and usually have a strong torque available.

Here a schematic block that illustrate what we have to do :

Saturday, March 26, 2011

Apache log messages on the Infoglobe

The RS232 version of the Infoglobe Interface  is capable to receive RS232 messages from a system, not only from a terminal emulator.
So, in order to test this capability, here a note about how to create a "custom" log message from the server Apache and have it sent to the interface.
In order to send a log message to the interface, we have to create a specific log capable to "fit" the Infoglobe message length.
The infoglobe is capable to display a maximum of 36 characters and also some characters are not available.
Because of that we have to create a log with the minimum information possible.

Log generation

Fortunately is quite simple to create custom log files with Apache.
It's enough to open the http server configuration file (in my case, on CentOS  /etc/httpd/conf/httpd.conf) and create a log generation customized for our needs.
In this configuration file, just search for the word LogFormat.
Usually there are some LogFormat lines in the file.
We have to create our own. Here the line I prepared :
LogFormat "^%{%D,%T}t %h " infoglobe

Basically I want to display only the date/time of the access and the IP.
%t display the time, but since the default format is quite huge, I used the strtime format to create a shorter date/time string.
You can find more information about the log capabilities of Apache in the Apache documentation.

Then in the part of the configuration file where the server is defined (in my case a Virtual server) just create a log entry using the LogFormat you prepared.
In my case :

CustomLog logs/apkh_infoglobe infoglobe

Now every time someone access the server, a file called apkh_infoglobe will contains date/time and IP of the access, something like :


Note the first character.
When the Infoglobe interface receive the character '^' will display the message in rotation.

Log presentation

After restarting the server (every modification to the configuration file will require a restart of the server), every access will add a line the log file.
To send the log file, in automatic way, to the Infoglobe, is enough to use this command, assuming of course the /dev/ttyS0 (equivalent to COM1 under DOS) is connected to the Infoglobe interface :

# tail -f -n 1 log_file > /dev/ttyS0

In my example :

# tail -f -n 1 apkh_infoglobe > /dev/ttyS0

After that, every access to the server will be showed up on the Infoglobe.
That's it !

Here an extract of the log file apkh_infoglobe :


Important to remember that the tail command is sending always the LAST line as soon as it is generated.
Here a picture of the Infoglobe showing the temperature :

Here the Infoglobe showing an IP from the log :

Wednesday, March 23, 2011

CY7C68013A USB Logic Analyzer

I received to test a little board based on the Cypress CY7C68013A.
Here some notes about this experience.

The CY7C68013A USB Logic Analyzer is a small board made by a Chinese company (Lcsoft) sold on Ebay from a China reseller as a Logic Analyzer tool.
It's a small board based on a Cypress CY7C68013A micro-controller (an 8051 clone).

First impressions

The board arrived in a small padded envelop, without any cable, documentation and software.
Quite useless due the totally lack of information.
Looking over the net didn't return too much information, there are very few seller of this product.

On some Ebay auctions for this board, there were present some links to the schematics and software, however these links seems not working.

Being only in Chinese is not really helpful to understand what is going on, also if it appears a "button" is available, but it is  disabled (gray one).
Also the download material available on these links, is information-less.
Are basically 3 rar files named 0000.rar, 1111.rar and 2222.rar, not really self explaining.
I had to contact the vendor of the board, and he initially answered back giving me the link to the same URL I discovered not working.
After another round of contacts, the vendor sent me the files via email.

The software

As I mentioned earlier, the software associated to this board, is coming in three "anonymous" RAR files :
  • 0000.rar
  • 1111.rar
  • 2222.rar 


This file contains other rar files, some of them named in Chinese and thus with wrong/illegal names in English.
Fortunately, at least under Linux, almost all in the end was accessible.
Without entering too much in detail here some contents, for what I can say (no documentation is present) :
  • -rw-r--r-- 1 1118001 2007-01-02 00:13 56pin.rar
    Source code for the board firmware.
    There are different directories and is not clear if all the code present is part of what is written on the chip or if there are testing code, experiments, ecc.
    There is NO documentation, nor information, nor about the necessary tools to compile the code and how to load it in the chip.
  • -rw-r--r-- 1 1701745 2007-01-02 00:13 Logic Software 1.0.21.rar
    Windows version Logic analyzer program in binary, no documentation.
    It is from the USBee Suite .
  • -rw-r--r-- 1 229606 2007-01-02 00:13 Schematic.rar
    Schematic and BOM of the board


This file contains a single zip file, that in the end contains a MSIA loader (Microsoft stuff)
  • -rw-r--r-- 1 11416917 2009-02-18 02:13


Also this file contains a single zip file that contains some USB drivers for Windows.
  • -rw-r--r-- 1 8372169 2010-05-05 11:21 

To better organize the received material, I created a new tree , changing some names to better identify the pieces :
  • drwxr-xr-x 7   4096 2010-11-01 16:23 Firmware
    This directory contains the firmware supposedly on board
  • drwxr-xr-x 2   4096 2011-03-18 12:29 LogicAnalyzer
    It seems a logic analyzer code. Not sure if is equivalent to the UsbeeSuite or it is part
  • drwxr-xr-x 2   4096 2011-03-18 07:05 Msia
    Microsoft libraries
  • drwxr-xr-x 2   4096 2007-01-02 03:37 Schematics
    Schematics of the board
  • drwxr-xr-x 2   4096 2011-03-18 07:05 UsbeeSuite
    Usbee Suite 1.5.7

The hardware

The schematic present in the received files, it just illustrates the board "as is", without any indication about how to use it for the Logic Analyzer function. 
Doing some tests using the program Logic under Windows (1.0.21), it seems that the 8 inputs used are located in the port B, where PB0 is the Input 1, PB1 the input 2 and so on.
The pins not connected to a probe input, reports an high value (+5V), i.e. seems the inputs are pulled up.
Also from the tests it seems the board can support max 8Mhz as input frequency.
The possible selection of the program Logic (12 Mhz, 16 Mhz and 24 Mhz) are not working.
The program automatically reduce them to lower values if selected. 
From some tests, it appears that all the selections of frequency are working, however the combination of the frequency and the  number of samples can  cause the program to "scale down" the frequency selection.
When the jumper close to the Eeprom is removed, the board is not seen anymore as Logic Analyzer but as Cypress development board.
Probably in the Eeprom are stored the codes and/or firmware for the Logic analyzer.

The cable

The analyzer arrived without any cable, so I looked around to see what was the best approach.
Some sellers of the board (and similar one) sells a cable that can be connected to the board, but I didn't like it for the price, the endless waiting time (from Honk Kong) and the appearance.
So I decided to buy the cable  used by the Logic original hardware and build a simple adapter board to connect it.
I bought the cable from Sparkfun (TOL-09225).

Here a couple of pictures of the adapter board to connect the cable to the logic analyzer.

The Logic Analyzer

Exploring the received files, I didn't find a single piece of documentation about how to set up both software and hardware, the logic analyzer functionality.

From some comments and the nature of the code, I think that the package (hardware and software) is a clone (hack ?) of the USBee LX series of USB instruments .
There is also another Logic analyzer code, the Logic, from Saleae , that exist also for Linux .
So in order to see if the board is actually working, here are some required steps :
  1. try to install on a Windows machine the included software :
    • USBee Logic Analyzer Suite
    • Microsoft Net extensions
    • Saleae Logic analyzer (Version 1.0.21)
  2. check the installed software in order to find hardware hook up info
  3. connect the hardware to the PC and see if is working and discover how to use the board I/O
  4. try to do the same with the Linux version

Install code

Logic 1.0.21 (Windows)

One for the Windows code in the received files, is from the Saleae, Logic, version 1.0.21.
The program requires some .Net libraries, I suspect the ones received with the rest of the code.
However the installation checks and installs them from the Microsoft website directly.
The .Net framework installation takes some time, so it is mandatory to have patience. 
After restarted the computer and completed the installation, it is possible to launch Logic, after connecting the board.
The board is recognized and the program is able to read the signals.
Status : working

Logic 1.1.4 (Ubuntu)

The Ubuntu (32 bit) version tested is the 1.1.4.
There is no need to install the code, however in the Driver directory there is an udev entry and a small script capable to copy the udev rule under /etc/udev.
So far the board is recognized (plug in) but on I have a not identified "access" problem.
lsusb recognize the board as "Lakeview Research"
Bus 001 Device 021: ID 0925:3881 Lakeview Research
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x0925 Lakeview Research
  idProduct          0x3881
  bcdDevice            0.00
  iManufacturer           1
  iProduct                2
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           46
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           4
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
can't get device qualifier: Connection timed out
can't get debug descriptor: Connection timed out
cannot read device status, Connection timed out (110)

However some info I found suggest that the board should give more information.
Status : NOT working

Logic 1.1.9 (Ubuntu)

The Ubuntu (32 bit) version tested is the 1.1.9.
There is no need to install the code, however in the Driver directory there is an udev entry and a small script capable to copy the udev rule under /etc/udev.
So far the board is recognized (plug in) but on I have a not identified "access" problem.
lsusb recognize the board as "Lakeview Research".

Status :  working

Logic 1.1.4  (Windows)

I installed also the new version of Logic, the 1.1.4, under Windows.
The installation was successful, however like the Ubuntu version, is not full recognizing the board, aborting immediately after the board is connected to the USB.
A collateral effect I had so far, is that the board is not working anymore also with the 1.0.21 version of Logic until the new Logic program 1.1.4 is dis-installed and the computer restarted.
Status : NOT working (not yet tested with the update)

Logic 1.0.33  (Windows)

On the Saleae website is also present an older version of Logic, but greater than the one present in the received files from the board vendor.
The version, only for Windows, is called 1.0.33 (present also in this website) and is working.
Status : working

USBee Suite 1.5.7 (Windows)

The other included Logic analyzer application is the USBee Suite, version 1.5.7.
The installation went well, no errors (on my Win XP machine) but the code it crash as soon as it starts, after the splashscreen.
Doesn't matter to have the board connected or not to the computer.
Status : NOT working


The board is working basically only with the version of Logic 1.0.21 and Logic 1.0.33 under Windows and with limitations (max. available frequency).
The lack of information make really complicate to try to study the reason of the failure with newer version of the Logic or Linux version, but I think has to do with a lack of information to the USB udev.
Also in order to use the board is necessary to :
  • buy a set of 9 probes
  • prepare a piggy back circuit to adapt the probe connettor
    Since the board is "generic" the probe connection are not linear but the ones available on the market are.
  • eventually optoisolate/protect the inputs
  • put the board in a case

For the price is sure an interesting object, but the lack of information and the reduced capabilities if compared with "official" products can reduce the usefulness of the product.

If having reduced capabilities, like be forced to use Windows instead of Linux and the limit in the frequency input, having to build the case for the board, play with the received material and lack of information (that this article tries to fix), then it can make sense to spend the money.

Otherwise I think the full price of the "originals" like the Saleae Logic are more than well justified.