Friday, December 30, 2011

GrandStream GXV3140

The GXV3140 is the latest IP phone from GrandStream.
Here some notes and impressions about this new phone.

First of all, the first impression is about a more professional phone.
More slim and slick, nice to see.  The screen is definitively better than the GXV3000, but smaller.
High resolution. And also the web pages used to set up the phone, are definitively "professional looking" and better organized than the older series.

So, here some pro and cons, compared mostly with the GXV3000.

  • professional looking
  • a lot, really a LOT, of functionalities  (IP radio, YouTube viewer, Skype, social networks (fb/Twitter/IM/ecc.), browser, ecc. ecc.)
  • doesn't require to be booted after every change of parameter !!
  • the screen saver is interrupted if the phone detect movement !!!! This is nice !!!
  • better organization of the screen
  • high definition video, is feasible to watch a movie
  • nice sound, both for music/movies and phone calls
  • WiFi as optional
  • much more complex to use, so I don't think is a phone suitable for non-technological people
  • a lot of functionalities but hardly multitask .. so is not possible for example hearing the IP radio and navigate with the browser
  • without an external keyboard many functionalities are limited
  • is not storing passwords for skype
  • some settings are "stuck" and is not possible to change them (bug ?)
  • different format of the xml file for the phonebook, so is not possible to share the one used for the GXV3000

So far I was able to use the phone with the services I normally use with the GXV3000.
No problem at all to call and receive calls from the other GXV3000 using different VoIP providers.
Fully compatible with Asterisk too, like the GXV3000.
And it has also Skype functionality !! It means that it can handle 3 VoIP providers SIP based PLUS Skype.

System data

Here some data about the phone :

Product Model :

Hardware Revision :

Version :

Core Version :

DSP Version :

Base Version :

Program Version :

GUI-A Version :

GUI-B Version :

Recovery Version :

Here the first update.

Thursday, December 15, 2011

GrandStream GXV3000

Short review of  the SIP videophone GrandStream GXV3000.

The GXV3000 is one of the cheap SIP videophone on the market.
Is produced by the GrandStream and is on the market for many years.
There are already a lot of information on the net about this phone, so I'm not attempting to describe the product, rather I want to point out some good qualities and some problems this phone has.

Why this phone ?

Years ago I started to build a private network, in order to talk with other family members and to close friends.
In order to cut the costs,  but still having a decent way to communicate, I opted for the VoIP.
Initially I considered Skype, but there were some security and usability issues ... for example the necessity to have a computer always on, running Skype.
People not accustomed to computer surely would have problems to handle such media.

So instead to look for a computer based solution, I started to look for a VoIP phone.
VoIP phones are now quite easy to find nowadays, and they can be really cheap, but at the time, about 6 years ago, the choice was limited and quite expensive.
Especially for a video phone.

After looking around for a while, the choice was the GXV3000, because relatively cheap and with some nice features.

The network

One of the main characteristic I looked for the phone, was the compatibility with the SIP standard.
Having a standard appliance means to have the capability to choose different VoIP providers.
The GXV3000 has the capability to support 3 distinct VoIP providers and this is quite important, since during the years  some providers can  close or they can have  problems, so it is important to always have a backup line in order to be able to call somebody.
I also set up a my PABX based on Asterisk, so to have always a backup line and the capability to use the GXV3000 as an interfonic system in the house.

The setting

Each GXV3000 of the network is set up to use 3 different VoIP providers, one of them is my Asterisk server.
It is possible to assign most of the configuration parameters using the menu on the phone, but is much more comfortable to use the web access.
Each GXV3000 has a web server inside, to easily allow to access all the phone parameters.
Each phone has it's own IP address. Assigned via DHCP by default or can be forced manually.
I chose on the phones in my local network, to assign manually the IP addresses, because in this way is easy to associate a specific IP to a phone in a specific location.
The phone in my office it will always be accessible at a specific IP and so on.
But the DHCP assignment works nicely too.

To access the setting page to the phone, is enough to open a browser (Firefox, Chrome, others) and enter the IP address of the phone.
So for example, assuming to have a phone with the IP address equal to, is enough to go on the browser and enter in the URL area :
This is what will come out :

Each phone requires a password in order to access the parameters.
By default the password is "admin".
After entering the password different pages will allow to set up all the phone parameters.
Caution ! In order to do so you need to be familiar with the SIP protocol characteristics and the provider setting.

The web setting possibility is very important because allow the administrator of the network to set up also the remote phones. However, for security reasons, it is important to set the remote system (router) to open a specific port and set the phone to accept remote management only through that port.

I'm not describing here all the possibilities. There is a well done user manual that describes in details the meaning of each parameter.
The suggestion is ... READ IT !  It will saves a lot of troubles ! Believe me !

The Pro and Cons

Well, the phone so far has a more than positive result.
In all these years I had NO dead phones. They are working 24/7, 365 days year and they still works nicely. I'm talking about a fleet of 20 phones.

Different matter for the power supply.
The power supply of the phone is quite weak. On an average of 3 years, usually 1 power supply dies.
It is tricky though to figure it out, because they don't die suddenly, but they "degrade" after some time until they reach the point where the phone is not working anymore.
The first sign of the power supply degradation, is the LCD back-light flickering when there is an incoming call.
Usually it starts just noticeable, then after some months the effect is clearly visible and weeks after, the phone starts to act strange, sometime freeze, sometime lose settings.

So if something like that happens, DON'T PANIC !!! Is not the phone broken, only the power supply.
Any power supply capable to give 12V at 1A it will work !

Other minor problems exists with some secondary features, like the integrated browser or the news feed.
Quite hard to set up and often they simply doesn't work.

To recap, let's see a simple table.

  • cheap video phone
  • decent support
  • possibility to remote management
  • lot of documentation available
  • easy to configure/manage
  • on newer models (GXV3005/GXV3006) integration with PSTN
  • power supply weak
  • some features are difficult to set up/understand 
  • some secondary features are not working
  • no WiFi enabled


If you need a decent VoIP video phone, without open a loan, it is the right choice.
Is not the top, some features could be done better, but it's totally capable to handle the main job.
It is a reliable phone, especially if you keep handy some spare power supply :)

Sunday, October 16, 2011

Olimex MSP430F169 LCD board

Olimex has different development platforms available for the MSP430.
One of these is the MSP430-169LCD. This article contains some notes about the board, tests operations and tips/tricks.

This development kit is very interesting.


  • MCU: MSP430F169 with 60K Bytes Program Flash, 256 Bytes data Flash,2K Bytes RAM
  • NOKIA 3310 LCD 84x48 pixels black & white
  • Joystick with 4 directions and push button function
  • SD/MMC card connector
  • two LEDs: status and power
  • RESET switch
  • JTAG connector
  • 32 768 Hz oscillator crystal
  • 8Mhz crystall oscillator
  • power supply voltage regulators and filtering capacitor
  • extension headers for all uC pins
  • PCB: FR-4, 1.5 mm (0,062"), soldermask, white silkscreen component print
  • Dimensions: 67x66 mm (2.65x2.6")
On the Olimex website or the Sparkfun Electronics website , is possible to download the schematic of this board, a test program and the processor specific datasheet .

Linux development environment

First of all, I installed the mspgcc development system.
Since I use Ubuntu I installed it (another article will describe that ), then I installed the program msp430-gdbproxy and the libraries from the website.

This is very critical.
The msp430-gdbproxy must be copied in the directory where is installed the mspgcc environment (usually /usr/msp430/bin, but in my case /opt/msp430-gcc-4.4.3/bin) and the two libraries and, must be copied in the directory /usr/lib.
It is vital to copy the program and libraries from the same site, i.e. compiled for the same version.
The mspgcc installation process already copy the and but very likely these libraries are NOT in sync with the msp430-gdbproxy program.

JTAG test

Then I started to see if the Olimex board was working.
I connected a 9V battery to the board (Vin and GND) and the board become alive.
Then, removing the external power, I connected the board to the JTAG connector, already hooked to the parallel port of the PC.
The board come alive, since the JTAG connector, thru the jumper P-IN (inserted by default), bring the power.

At this point, following the instructions found on the Develissimo website and from this article on the MSP430 development environment , I started the msp430-gdbproxy in a terminal.
The first time I had strange error, so I reset the board and something started finally to work.
However using the suggested command :

#msp430-gdbproxy --port=2000 msp430

I obtained this error :

debug: MSP430_Configure()
error: msp430-gdbproxy: unable to open debugger connection. Will restart

I spent quite some time tracking this error but the only thing I realized, was that the error was somehow related to the TCP port used or about some conflict with other services or the Linux configuration.
Then I started to read the mspgcc documentation and I found some notes about the msp430-gdbproxy .
In the notes it was suggested to try the command:

#msp430-gdbproxy --debug msp430

and it worked !
Only I noted that the default port was not 2000 but 2001 !
So I modified the original command using the new port :

#msp430-gdbproxy --port=2001 msp430

and ... voila' !!!
I was able to connect the Olimex board with the JTAG.

So to recap, in order to open a debug session with the card :

  • connect the Olimex board to the Jtag (parallel version)
  • open a terminal and start the gdb proxy :
    msp430-gdbproxy --port=2001 msp430
    Note ! If is not working is possible to use sudo, but in this case the absolute path of the msp430-gdbproxy must be issued.
    For example in my case : sudo /opt/msp430-gcc-4.4.3/bin/msp430-gdbproxy msp430
  • open another terminal, or a tab in the already opened, and start the gdb :
    msp430-gdb name_program_to_load.elf
Inside the gdb digit help for generic help.
Here some common operations :
  1. connect to the board (first thing to do)
    target remote localhost:2001
  2. erase the flash memory (needed to do every time before to load the new code)
    monitor erase
  3. load a program in the flash
    load name_program_to_load.elf (or .a43)
Converting the demo code

The first test is to convert the IAR demo code available for this board, for the mspgcc.
Following the conversion rules , it is possible to compile with mspgcc the code.
To simplify the process I created a makefile. Looking at what files the IAR used to create the code, I created a simple makefile :

CFLAGS=-O0 -Wall -g -mmcu=msp430x169

OBJS=main.o mmc.o system.o lcd_new.o

all: $(OBJS)
$(CC) $(CFLAGS) -o test.elf $(OBJS)

%.o: %.c
$(CC) $(CFLAGS) -c lt;

rm -fr main.elf $(OBJS)

To compile the code, simply open a terminal, go in the directory where there is the makefile and the source code and then :

  • $make clean
    to clean up the objects
  • $make
    to compile

The result is a file called test.elf that can be load directly using the procedure described above.
The code is running smoothly.

Here some notes about the joystick on the board.
The joystick is seen as 5 different switches.
The higher 4 bit of the Port1 (set in I/O - input direction - MSB) are used to carry the state of the 4 direction switches and 1 bit of the Port 2 (set in I/o - input direction) is used to carry the state of the pushbutton.
Here a table :

Signal  Name  Description 
 P1.4 B1  Right
 P1.5 B2  Down
 P1.6 B3  Up
 P1.7 B4  Left
 P2.0 B5  Pushbutton 

The signals are pulled up, so when the switch is NOT pushed the reading will be high (1).
Here a Schematic to indicate the combinations of signals (remember, a 0 means the switch is pushed).

The continue line indicates the real signals, the dotted one the combinations of signals.
The inner circles indicates the name of the connection on the schematic.
Pushing the joystick on the left for example, will generate the combination of 0x7x (0111xxxx), i.e. masking the MSB will have 0x70 (01110000).
Pushing the joystick Up and Right will generate the masked combination of 0xA0 (10100000).

Here some other link to related resources and examples.

Friday, October 14, 2011

MSP430 - IAR vs mspgcc

Updated !
There are some differences between a C program developed with IAR and one developed for mspgcc.
This article will try to address these differences in order  to port a MSP430 program developed for IAR into a mspgcc one and viceversa.
I'll try to keep update the article every time I found something or if I receive suggestions.

With the mspgcc (msp430-elf) version maintained by TI, there are further differences.

Include files


The main inclusion file necessary is related to the component used.
With IAR usually it was #include <msp43xxxxx.h> wherexxxx indicated the specific family.

With mspgcc is better to include the file io.h and set the cflags to the correct cpu.
For example :

 IAR mspgcc  msp430-elf
Family MSP430 F 2012
#include <msp430x20x2.h>
#include <io.h>
set -mmcu=msp430x2012 in cflags
#include <msp430.h>
#include <legacymsp430.h>
set -mmcu=msp430f2012 in cflags
Be sure to have -I and -L in the CFLAGS with the path to the MSP430_TI/include

In Code::Blocks, in order to add the correct mmcu flag :
  • open Settings/Compiler and Debugger 
  • go in the tab Compiler Settings/Other options
  • add the line -mmcu=msp430x2012 (or the specific mcu used)

Or, it is possible to find and include the correct header.
Looking in the file io.h is possible to see the correct inclusion. 


Some programs with IAR uses different port notation.
For example, the demo program for the MSP430F169, used in the Olimex card, uses the notation :
P3OUT_bit.P3OUT_0 to address the bit 0 of the port 3.

With mspgcc the single bit need to be addressed differently.
If a single bit needs to be addressed, it is necessary to use the mask bits.
For example, to set the bit zero to 1or the port3 :

P3OUT |= 0x01;

To set it to zero :

P3OUT &= ~0x01;

Better to prepare some defines, something like this :

#define BIT_0 0x01
#define BIT_1 0x02
#define BIT_2 0x04
#define BIT_4 0x08
#define BIT_5 0x10
#define BIT_6 0x20
#define BIT_7 0x40
#define BIT_8 0x80

and then use notation like :

P3OUT |= BIT_0


In IAR the interrupt function is a normal function with __interrupt as type.
mspgcc has a special function called interrupt.

Because of that under mspgcc no function prototypes are allowed for interrupt functions.
For example, for the Timerinterrupt function :

 IAR  mspgcc  msp430-elf
/* Timer A0 interrupt service routine */
__interrupt void Timer_A (void);
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A( void )
// Timer A0 interrupt service routine
interrupt(TIMERA0_VECTOR) Timer_A (void)
// Timer A0 interrupt service routine
void Timer_A (void)

To enable the interrupts is possible to use the function eint() or _BIS_SR(GIE);
Include the file signals.h when it is used (#include <signals.h>)

Sunday, October 9, 2011

How to use syslog

How to use syslog for our own programs.
Linux, and other systems, supports a log management system called "syslog".
It is standard and there are utilities that can interact with it.
Here what to do to use syslog to add log capabilities to your programs.
  1. In the file where syslog is used, include :
    #include <stdarg.h>
    #include <syslog.h>
  2. Create a function that redirect the messages to syslog.
    For example this function imitate printf, just use this function everytime a message need to be printed in the syslog :
    my_syslog_printf(const char *fmt, ...)
       va_list ap;

       va_start( ap, fmt );
       vsyslog( LOG_INFO, fmt, ap );
       va_end( ap );
  3. Before to write logs in the syslog system, the syslog file need to be opened.
    Do it before to start to use syslog :
    openlog("program_name", LOG_PID, LOG_USER);
    syslog(LOG_INFO, "Start log  --\n");
  4. Every time a log message need to be printed out, just use the function declared above, for example :
    my_syslog_printf("This is my log\n");
  5. Before to exit from the program, close the syslog using the function closelog().
    However usually exiting from the program automatically the log stream is closed by the system.

Note :

In openlog and closelog the "program_name" is an identifier for the particular log generator.
I usually use the program name as identifier but is not mandatory, anything that identify univocally the log stream is ok.

Saturday, October 1, 2011

Roomba repair - common problems

It's quite a while I play with Roomba.
Here a list of the common problems for these little robots (3rd and 4th generation) placed in the most probable happening order.


THE Roomba common problem is of course the battery.
On average, at least once per year, the battery dies.
It depends about the use of course, and contrary to the common sense, more a Roomba is used, more the battery last.
But as said, on average the battery last about a year.

NiCd batteries are lasting even less, mostly due to the "memory effect".
NiHi batteries are better.


The second typical  problem that can happens to your Roomba, is in the deck motor or in the deck gearbox.
The deck motor is the electric motor that drives the brushes.
Typically the problems in these areas are happening when the Roomba entangle in wires or thick carpets.
When trying to remove itself,  more trust is placed on the brushes and if this happens often, after a while the mechanic can be damaged.
Actually there are different kind of problems that can happens to that area  :

  1. broken motor gears
    The motor has a gearbox used to increase the torque.
    There are 3 gears inside the motor and they are made in teflon or plastic.
    The typical problem is that one or two of these gears, broken up, losing one or more "teeth".
    The final result is to have the motor spinning and  the main shaft not moving.
    It's enough to replace the gears to fix the problem.  Unfortunately  a new set of gears can cost more than the motor ... so often is more cheap to buy a new motor with a new gearbox (they come as single piece).
  2. broken motor
    More rare but it happens that some internal connections broke.
    In this case the only thing is to replace the motor.
  3. broken electronic
    The motor is driven by some electronic. Specifically a Mosfet is feeding the motor.
    Sometime, even more rare than the broken motor, is the electronics that fails.
    In this case "in theory" is enough to change the mosfet to fix the unit.
    Unfortunately it is extremely difficult because you need to take TOTALLY apart the Roomba in order to extract the electronic.
    Then you change the component and in order to test if the repair is correct, you need to put back totally the unit !
    It's about 2 hours work and if something goes wrong, you need to do it again !
    Unless to have a Roomba simulator , in order to test the electronic without the need to put it in a Roomba, is one of the worse case scenario for repairing a Roomba.
Also the deck gearbox can have problems :
  1. broken gears
    Like the gears in the motor, the gears in the deck gearbox can loose teeth or broke down.
    Having other broken decks is possible to substitute the broken ones.
  2. broken gearbox cage
    A couple of times I had to repair a gearbox deck cage broken.
    The gearbox cage is screwed to the deck and if broken can not keep the gears in the right place.
    Change the gearbox deck cage or the entire deck.


The third typical problem with Roomba are the wheels.
The Roomba wheel is quite complex object. It is composed by four parts :
  1. electric motor
  2. planetary gearbox
  3. sensor
  4. tire
Each one of these elements can develop problems, but the most recurring problem is on the sensor.
The sensor is used to determine the speed  of the wheel and is very simple.
A special wheel with some openings is mounted on the main shaft and the light from an infrared LED can reach a photodiode only when an opening in the wheel happens.
The problem is that dust can, and does on time, cover the photodiode, so that become insensitive to the infrared light.
The result is that Roomba loses feedback from the wheel, starting to act crazy.
The phenomenon is well known as circle dance and usually cleaning the sensor solve the problem.
With some luck can be cleaned with compressed air, otherwise the wheel needs to be taken apart.

In all these years I own many Roomba, I never saw a planetary gearbox broken.
It is rare, but is possible to have tires used so much that the rubber is incredibly thin or the electric motor defective.

Thursday, September 29, 2011

Force bash under Ubuntu

Many Ubuntu distributions use dash as default for the shell.
I prefer the classic and more powerful bash.

Here a quick way to force the bash shell as default.
Open a terminal and execute this command :

$ sudo dpkg-reconfigure -plow dash

A message will appear indicating the default shell in use (it should say "dash", in this example is bash because I already executed the dpkg-reconfigure)

Choose No.
Done. From now on the bash shell is the default one for the user.

Wednesday, September 21, 2011

Logitech Squeezebox review

Here some notes about the Logitech Squeezebox IP radio.   squeezebox.jpg
Until few months ago, my only experience with the IP Radio was with an Aluratek, until it broke down.
Since I did not have ANY KIND of support from Aluratek, even if the radio was under warranty, I decided of course to don't go again with that brand.
If maybe somebody has not understood ...  Aluratek is a no no brand for IP radio !  

Then a friend of mine  made me a nice gift with the  Logitech Squeezebox IP Radio.
Here some notes and impressions.

Pro and cons

Here a quick lists of pro and cons based on my experience so far.
Pro :
  • Well, the brand.  It is a nice product and the company support rocks !
  • Easy to operate, easy to configure
  • No needs to read manuals/documentations
  • Wired and wireless connection available
  • Very nice sound
  • Hackable !!!
  • It uses Linux !
  • Streaming server open source and available for Windows/Linux/Mac
  • With a battery it can be disconnected from the main power and become portable (battery and IR remote as expansions)
Cons :
  • The cost
  • No IR remote by default


The radio is really nice and "heavy" enough, easy to manipulate.
The user interface is based on a rotary encoder  pushable and few main buttons.  Easy to operate, though boring if you have to write something (like searching for a song or radio digiting the name).
Few problems with the wireless setting and DHCP but I think are my network problems, not a radio fault.
Setting a fixed IP and wired connected solved for now all the problems.  I'll experiment eventually in future with the WiFi. In order to have the radio working properly I had to disable the WiFi router DHCP server, keeping only the main one (on the main router).
Once set up the WiFi the radio was able to catch an address from the DHCP server.
By default the radio try to connects with a Logitech server,
Going there with a browser allows you to set up many features of the radio and found a lot of radio stations.
Then it is possible to install a server (available for Windows, Linux and Mac) in order to stream your own music from your network.
From there all the radio are accessible as well, so basically there is no need (like Aluratek) to access a specific company-related server.
And amazingly ... the radio is Linux based and the server is open source !!!
And now some more details about some characteristics/experiences.

Setting up

As I said, the radio is easy to configure and set up.
I had few problems with the WiFi setting, very probably due for my network.
I didn't want to spend too much time on that, so for the moment I solved assigning a fixed IP to the radio and connecting it in wired mode.

Both DHCP and direct IP are supported, for wired and wireless connections.
No problems.


I installed the Logitech Sqeezebox server for Debian (Ubuntu) and it worked as soon as the installation was ended.
However I had to solve a small problem (again due to my system and not to the server).

Music Library

During the server setting,  it is necessary to assign a path for the Music Library to use for the stream.
In my case the music collection is hosted on a 1 TB Hard drive.
For some reasons, the hard drive is not automatically mounted at the boot time, so the first time I turned off the PC and then back on, the server was not able tofind the scanned music.
Mounting the hard driver and restarting the server solved the problem.
probably solved the problem installing an utility called pysdm (sudo apt-get install pysdm).
This utility assigns a fixed name for a driver and mount it at every boot.
Now the drive is mounted at the boot time so the server (that starts automatically) always find the music files.


Basically the radio shows a list of the possible "networks", among them the server.
When selected, the radio try to connect to it in order to retrieve Favorites and settings.  Alarms included.
This actually created an unexpected behavior.
If the computer running the server is turned off, turning on the radio causes the PC to start !
Because of that, the PC starts automatically when an alarm is firing !
For me is an extra feature, I have the PC turned on automatically in the morning !


If in a directory containing a MP3/FLAC CD, exists the cover image of the original CD, the picture will be showed both on the radio and on the server.
I'm not sure about what name it should have.
I experimented with "Folder.jpg" and AlbumArt_Large.jpg, AlbumArt_Small.jpg and AlbumArtSmall.jpg.
In case images are added, it is necessary to force the rescan of the Music directory on the server.


Here some tips and trick about the radio.


In order to use or configure the server, simply open the browser and digit :
Of course if the server is running on a different machine, simply use the machine IP.
From the server is possible to control the radio. In my case is working also :


Server selection

In order to use the server, the radio needs to select it.
Using the radio menu and controls, select the server (it will appears with the name used during the server installation)

Wednesday, September 7, 2011

Ubuntu boot problems

One of the Ubuntu machines I have, today woke up in the bad mood.
The boot failed ending in a BusyBox splashscreen :

Busybox v1.1.3 (debian 1:1.1.3-5ubuntu12) Built in shell (ash) Enter 'help' for a list of built-commands

The problem is relatively simple, the hard drive screw up a little bit.
Many suggestions found on the net suggested to boot in Windows, do a check of the disk and re-boot.
That's nice if you have Windows installed somewhere.

For who, like me, doesn't have Windows nor even think about to install it, here a simple workaround.

  1. Look for a live Linux distro and boot the PC with it
    I used Knoppix.
  2. Look for GParted (Disk partition utility)
  3. In GParted look the drive (hard drive), select it, choose "check"
  4. When the check is finished, reboot normally
It should work.
It worked for me anyway :-)

Tuesday, August 30, 2011

Roomba repair - cleaning techniques

For 3rd and 4th Generation Roomba  

CAUTION !  What described here can damage your Roomba if you don't know what you are doing, and it also make void the warranty !
I'm not liable in case of problems following these suggestions. YOU are responsible about what you are doing.

The most recurring problem for Roomba, is related to the cleaning job is supposed to do.
Dust, hair, strings, ecc., after some time, especially if the unit is not maintained properly, can create problems.
So the first thing to do when repairing a Roomba, is to have it cleaned up.
There are different cleaning techniques, some of them can be applied sequentially to the unit, depending how much dirt is the robot.
I'm describing here the techniques I'm currently using to clean up a third or fourth generation Roomba.

Blowing the unit
The first thing is to blow the unit with compressed air or, like me that I don't have compressed air, with an electric blower.
Better to do that in an open space, not in the house, since usually is coming out a LOT of dust.
I usually open the garage door, then I prepare the Roomba removing the battery, the dust bin and the brushes.
Then I place the Roomba to be cleaned on the floor, "as is" (i.e. I don't take it apart yet) and start to blow everywhere, up and down, trying to direct the airflow in every accessible place.
Also, place the Roomba upside down to clean up the wheels and the bottom of the deck.
Usually clouds of dust and hairball can escape the unit, so better to wear a mask.

Apply the same treatment to the dust bin, removing the filter and direct the air flow also in the vacuum propeller.

Vacuuming the unit
After the initial blowing, the second stage of the cleaning, require to take apart the unit.
Remove the bumper, the top case and the rotating lateral brush.
Doing so many internal parts become exposed, and it is possible to vacuum the unit, in order to remove pieces of dust still attached to the internal parts.
It is typical to have airballs mixed with dust on the deck and dust stuck in little spaces, not accessible from the outside.

With "not so dirty" Roomba, the blowing and the vacuum are enough to have the unit clean.
In these cases is enough a wet cloth or some cleaning cloth products, to remove the dust and have back the unit like new.

Same treatment to the dust bin. Just be sure to remove the filter first.

Unfortunately many Roomba never received a decent maintenance during their life.
For these units is mandatory to proceed to the third cleaning phase.

Washing the unit
For very dirty units, it is necessary to wash them.
Depending what you have available, there are different techniques.
Having an old dishwasher available, it is possible to put Roomba in it and perform a short cycle.
I have an utility sink in garage, so what I usually do is to fill up a basin, big enough to contain the Roomba, with warm soapy water.
I use a car wash soap, in order to remove also some external greasy dirt, and a mild brush, to gently stroke in every accessible unit part.

For very dirty Roomba is maybe better to detach the deck from the unit and having it washed separately.
Put the Roomba in the warm water, agitate the water (so to allow a deep penetration) and use the brush (gently !!!) on electronics and mechanical parts.
Then rinse accurately the unit with fresh water.

The trick is then to dry the unit as fast as possible.
After moving the Roomba up and down for a while, in order to remove as much water as possibile, I normally use the blower as first drying step, so to force the water out from inside.
Then I place the unit under the sun (here in Arkansas is quite powerful) for few hours.
An alternative could be to use a dryer, of course assuming the dryer has a stable internal platform (many dryers have that option).
Is not a good idea to place the Roomba in the drum !!!

The same technique can be applied to the dust bin, unless is a dust bin with the Empty indicator.
This kind of dust bin is called Intellibin.
These dust bins have an extra electronic powered by an independent battery.
So DON'T WASH the dust bin unless you remove first the battery.
Unfortunately to remove the battery, you have to totally take apart the dust bin !


Here a video that shows how to perform a "vacuum type" of cleaning, i.e. opening the Roomba and cleaning the inside.
The video has the soundtrack in Italian but I think it can be helpful anyway.
The time necessary to do a decent job, assuming to have a little bit of experience in opening and closing the Roomba, is around 30 minutes more or less.


Sunday, August 28, 2011

Interface Roomba-USB

In order to diagnose/repair a Roomba, it is necessary to do some test and measurements.
Even if each Roomba has a diagnostic program on-board, often is necessary to have more control and a better feedback, with also some measurements.
To do so the basic tool every Roomba-hacker needs to have is a cable to connect the Roomba with a PC.

There are many ways to buy/build such cable.
This article describe how I did it, just to give ideas. Is not necessarily the best way but it worked for me.


We started from a consumer SIM USB card reader.  These readers are available on ebay and similar places for few dollars.
Here a picture of the electronic board (they usually come in some kind of plastic box).

These USB SIM card readers usually are based on a chip capable to convert the USB port into a serial one, the Prolific PL-2303.
Then a cable with a minidin connector is needed and eventually a PCB minidin.
In my specific case I used :
  • USB SIM card reader
  • 8 pin minidin PCB outlet
  • 8 pin minidin cable (at both ends)


The first thing to do is to remove from the USB SIM card some useless components, like the SIM card connector, a 74HC04 and a Crystal (3.5 Mhz).

At this point is necessary to identify on the PL-2303 the pins we need to connect.
  • Pin 1 PL-2303
    TXD -> connected to the Roomba RXD (pin 3 minidin)
  • Pin 3 PL-2303
    RTS -> connected via a transistor to the Roomba Power pin (pin 6 minidin 7 - pin 5 minidin 8)
  • Pin 5 PL-2303
    RXD -> connected to the Roomba TXD (pin 5 minidin 8 - pin 4 minidin 8)
  • Pin 7 PL-2303
    GND - pin 6/7 minidin 7 - pin 7/8 minidin 8)

Here the schematic of what we want to do :

It is very important to pay attention of the type of minidin used.In the schematic I used the original Roomba minidin 7, so the pinout is DIFFERENT from the minidin 8 !
On the net is possible to find information about the pinout and specifications, like here.
Here some pictures of cable preparation.

Tuesday, August 23, 2011

Fixing an Infoglobe

One of the Infoglobe I have, started to have problems time ago.
Initially the problem was random, one row of the message, was missing for few seconds, then working normally.
But on time, the missing row problem become permanent.
Then another row started to dim and then disappeared.

At this point I decided to open the Infoglobe and discover the cause of the problem.
Here a description of what I did, hopefully it can be useful to somebody else.

Opening the Infoglobe

As described in my first article on the Infoglobe, I opened the Infoglobe.
However, I just removed the dome. There is no need to remove the 4 screws on the bottom since the problem is located only on the rotating arm.

Once removed the dome and unscrewed the rotating arm, I removed the rotating arm for a detailed inspection.

The rotating arm removed from the Infoglobe

The problem

The rotating arm is composed by two PCBs connected at 90 degrees.
The small PCB at the end of the arm is hosting 8 LEDs (in my case, 8 blue LEDs).
In the picture, note the arrows indicating the side exposed during the rotation.

The first thing I noticed was a dark color on the side exposed in the rotation.
I think is was dust mixed to small PCB particles. The high rotation and vibration, during the years, probably caused a partial disintegration of the PCB and conductive material.
The rotation itself allowed this dust, probably also electrically charged, to deposit on the LEDs side exposed to the rotation.

Note in the picture above the dust deposit around the LED.  When the dust touched two LEDs, a short circuit happened, forcing the LED off.
Initially only for few microseconds, thus the "dimming" effect, then with enough dust, permanently.

Fixing the problem

With a very soft old tootbrush, I removed the dust from the rotating arm, especially from the PCB with the LEDs, and then I put it back the rotating arm.
It worked perfectly.

I was worried to have to re-do some soldering on the LEDs, but I didn't found any sign of detachment, so for the moment I put it back the rotating arm and close the dome again.