Friday, May 12, 2017


Just a brief note for spammers.

Often I receive some comments on some articles of this blog.
Many of them are clearly just spam masked as comment.
I have zero tolerance for spam comments, as soon as I identify one I'm deleting it (if already published) or I can prevent the publication if I recognize it.
On this blog comments must be approved by me, they are NOT automatically published.

So, who wants to post spam here, will have hard time and my total contempt.
Don't bother to post spam.

Wednesday, May 10, 2017

Gnuplot on Raspberry Pi

gnuplot is a program capable to produce graphs starting from set of data.
Ideal to graphically represents sensor readings.

This article assumes to use Raspbian on a Raspberry Pi, specifically in my case the Raspbian version is the one used with Dexter for GrovePi.
Since GrovePi allows to easily connect sensors to the Raspberry, gnuplot is the perfect companion for that environment.


Simple, open a terminal and digit : sudo apt-get install gnuplot

That's it :)


Once gnuplot is installed, is possible to open a terminal and digit the command gnuplot.
An interactive environment command line based will be available.
However the best way is to create a file containing the commands needed to generate a graph and have gplot reading that file to produce the graph as described in these instructions.

Data file

The file containing the data need to be in a specific format.

The time/date in the format of yyyy-mm-dd:hh-mm-ss (see the timefmt line in the command file), then the light value and (in this example) the voltage measured.
Each field is separated by a tab and each line ending with a newline (/r).

Example of data saved in the fhelper_datalogger.txt

# 2016-12-05:10-52-42 - Starting datalogger - time - light - volt 
2016-12-05:10-53-02 758 4.43
2016-12-05:10-53-24 758 4.43
2016-12-05:10-53-44 758 4.43
2016-12-05:10-54-05 758 4.43

Command file

Here an example of a gnuplot file (called testfile) used to display some information collected in the data file.
Specifically the goal is to create a graph showing the data stored in the second column of the file (light)
set title "fHelper light data vs. Time"
set datafile sep '\t'
set xlabel "Time"
set ylabel "Light"
set xdata time
set timefmt '%Y-%m-%d:%H:%M:%S'
set yrange [0:1000]
set style data line
set terminal png size 1500,800 enhanced font "Helvetica,20"
set output 'displight.png'
plot '/home/pi/Desktop/fhelper/fhelper_datalogger.txt' using 1:2
The file is taking a file called fhelper_datalogger.txt (located in the directory /home/pi/Desktop/fhelper) and will produce a file called displight.png.
The file will be saved in the same directory where this file exists and is executed.

To execute it just digit from the prompt : gnuplot testfile

Here a couple of examples of graphs obtained from the log file.
One shows the light reading and the other the voltage reading.
To obtain the voltage reading was enough to change a couple of lines from the command file.
Specifically I changed the Y axis range (0:1000 for light, 0:5 for Volt) and the plot command telling to use the first and third column in the file rather than the first and the second column (plot '/home/pi/Desktop/fhelper/fhelper_datalogger.txt' using 1:3)

Thursday, May 4, 2017

Grove Moisture Sensor bad design

Among many things, time ago I started to play with the Grove Pi system, for a fun project called fHelper, basically a sophisticated alarm to notify when a plant need water.

Basically a Raspberry Pi with a bunch of Grove sensors and among them the Moisture sensor.
Today I found out that who designed this sensor did a very poor job, using a direct current to detect the level of humidity.
The result after months of use is depicted in the pictures below.

Yep. One side is totally corroded !!
No wonder the reading was erratic.


Not sure if it was there when I bought it, but the sensor page now reports that the sensor should be used only for brief tests and not left in the soil because corrosion can happens.
Still I found totally silly to use something to design a system and then not be able to use it in a final design because it destroy itself.
You spend time experimenting with a sensor that can not be used !  Can I say is just stupid ?

Roomba 5xx - repairing a power supply

Time ago I had a Roomba 560 with an Error 5.
The problem was the power supply used to charge the battery.

Time to try to fix it.

It is a classic switch power supply and I did some measurement.
The voltage expected was supposed to be around 22V, but it was around 19V when I measured it.
Even worse, the voltage was slowly decreasing after few minutes.

There are many things that can go bad in a switching power supply, but the symptoms made me think about a bad capacitor.

So I opened it and started to look for damages on the PCB.
Particularly I was looking for discolorations around the capacitors, usually caused by the heat.
A bad capacitor can generate a lot of heat and thus be damaged.

I didn't notice anything apparent, so I checked out the two main capacitors in the circuit.
A 47uF 200V and a 680uF 35V.
Both seemed OK to a visual inspection.  Since I had around only the 47uF capacitor (but 400V) I decided to change it.  Quite unlikely to be that one the problem since is used as main filter on the 110V but better to try.

And in fact it was not that the cause of the problem.
So I ordered from Mouser some 680uF 35V capacitors and, just in case, a mosfet 500V N-channel to eventually replace the one used in the power supply.

When the component arrived I immediately changed the 680uF capacitor and ... voila' !
22.75V stable.

I was lucky this time. A damaged capacitor on the output.

Reassembled the power supply, it worked perfectly to charge the "just fixed" Roomba 510.

5v Solar Power Supply for Raspberry Pi - Enhanced RPOf

This article describe an idea about a 5v Solar power supply for Raspberry to be used with the fHelper project. Another article describes some tests on the 5v Solar power supply.
in particular this article discuss about the requirements for the Enhanced RPOf (eRPOf).

The goal is to have a 5V solar power supply for Raspberry Pi capable to power up and power down automatically (or forced via a pushbutton) the Raspberry Pi.
The eRPOf will be powered by the same battery, thus it will have a voltage detector circuit to power it up.

Main characteristics

The main goal is to have the Raspberry Pi totally independent for the power supply.
The system should be able to be powered only using the sun.
Because some limits and to reduce the cost, the system will be able to shutdown the Raspberry Pi under determined conditions and re-power it later under a different sets of events.
Here a sum up of the main characteristics
  • Solar powered battery
  • Capable to give 5v 1A
  • monitoring power and shutting off nicely Raspberry before the battery is depleted
  • automatic powering up the Raspberry when the battery is back charged 
  • Push button for manual on/off operation (see RPOf)
  • Other condition to determine when powering up the Raspberry (light or time of the day or other condition)

Block schematic

The key is the eRPOf circuit that is used to turn on and off the Raspberry Pi safely, plus the trigger command can come from the charge level monitor.
If the battery level start to be close to a critical threshold, the monitor send out the off signal to the eRPOf that is removing the power to the Raspberry after sending a shutdown command (see the RPOf article).
The eRPOf in this case however will turn automatically On the Raspberry when there is enough power stored in the battery, or if the manual command is issued (pressing pushbutton) or other conditions are satisfied.
The eRPOf is powered by the same battery. The threshold to cut power to the Raspberry Pi will be set in a way to allow the battery to power the eRPOf using a voltage detector circuit.
i.e. the eRPOf will be allowed to run if the battery will have enough charge.

Let see some blocks.

  • Solar panel - solar controller - battery
    These are the keys for the solar charger.
    The battery is kept charged by the solar panel and the solar controller is capable to power whatever is connected thru the battery or, if in excess, the solar panel.
  • Relay - DC/DC converter
    Control part to power up the Raspberry. eRPOf will connect the DC/DC to the battery.
  • Charge level monitor
    Hardware component to decide when there is enough power to power on the eRPOf.
  • Power level monitor
    Optional - a way to monitor how much power is coming from the solar panel. Can be used to infer if is day or night or cloudy.
  • Other conditions
    Like the block above, a set of other possible conditions to prevent eRPOf to power up the Raspberry


Here a list of components used to build the eRPOf.
The goal is to use as much as possible "ready made" circuits, so I looked at Adafruit.
See the feasibility phase article for more details, here the list :

eRPOf details

The eRPOf is based on the original one, however it has some differences, thus it will be an Enhanced version of RPOf.
For example it must be capable not only to shut down the Raspberry Pi when the battery level is going down too much, but it must be able also to power back automatically the Raspberry when the battery level is enough to sustain the fHelper job and another condition allows that to happen.
Starting from the original RPOf based on the MSP430, here the specifics for the eRPOf.

The eRPOf will be able to:

  • monitor the battery level
  • shutdown the Raspberry Pi
  • monitor if the Raspberry Pi is turned Off (to determine if the Raspberry is already went off)
  • power up the Raspberry Pi in autonomy depending the battery level charge and other conditions
  • power up the Raspberry Pi if the push-button is pressed AND all the necessary conditions are satisfied.
    For example if the battery level is still below the threshold (level 3) pressing the pushbutton will NOT turn on the Raspberry Pi

Tentative schematic

Here a tentative for a schematic, in order to do some prototype:

The eRPOF is powered directly from the battery under charge (3.7 V nominal) and the voltage detector controls the MSP430 reset pin.
Still to decide many things, for example if make sense to have the LED for the power button since the goal is to minimize the current used.
Anyway this schematic is just a starting point to experiment and it will be likely be modified.

I/O description

Like the original RPOf, the eRPOf will use two I/O to communicate with the Raspberry Pi.
One line will be used in output mode from eRPOf to inform the Raspberry to start the shutdown sequence.
The other line will be used in input mode on the eRPOf to determine if the Raspberry Pi is running.

Of course it is implicitly assumed that those line are handled on the Raspberry Pi side as well !

One other line will be used to measure the battery voltage and another line will be used to measure the solar panel voltage.
This should allows to determine when is daylight and if there is enough power available to turn on the Raspberry Pi.

Here a detailed description of the I/O used in the project :

  • P1.3 - Reading voltage
    • Direction : Input
    • Mode : ADC
    • Description : It is connected to the battery.
      Via it the MSP430 can read the voltage of the battery
  • P1.6 - push button
    • Direction : Input
    • Mode : Digital - pull up inserted
    • Description : It is connected to the push button. Active low
  • P1.7 - relay control
    • Direction : Output
    • Mode : Digital
    • Description : It controls the relay - active high
  • P2.1 - to GPI0018 Raspberry Pi
    • Direction : Input
    • Mode : Digital - pull up
    • Description : Shutdown control - input
      Reads a line controlled by the Raspberry Pi - active low
  • P2.2 - to GPI0017 Raspberry Pi
    • Direction : Output
    • Mode : Digital
    • Description : Shutdown control - output
      Used to force a signal to the Raspberry Pi.
      When the signal is up, the Raspberry start the shutdown sequence
  • P2.5 - push button LED
    • Direction : Output
    • Mode : Digital
    • Description : It controls the push button LED (active high)

Powering ON

The power ON procedure is more tricky since everything is powered from the same battery.
We can have different states and for some of them a specific hardware solution is the only way.
Let see some states of the battery :

  1. Battery totally discharged
    When this state happens, there is no power to supply not only the Raspberry but also the eRPOf itself.
    The power to the Raspberry (via the DC/DC converter) the eRPOf must be able to run and this means that the it must be blocked if the battery is below a specific threshold
    An hardware circuit must ensure that.
  2. Battery charged (transition from discharged to charged - level 1)
    When the battery voltage is above a specific threshold, the hardware circuit will allow eRPOf to run.
    eRPOf then will execute some tests to determine if there is enough charge to power the Raspberry.
    This threshold is called level 1.
  3. Battery charged (transition from level 1)
    eRPOf will enable the Raspberry activating the DC/DC circuit when the battery charge level will raise above a threshold (higher than the one at level 1, called level 2).
    eRPOf will try to determine if the battery is charged enough before to connect the DC/DC.
    Some suggestions :
    1. verify if is night - if no light is detected or looking at the time, it means the battery is not charging, avoid to start the Raspberry in the night
    2. verify the battery charge to be above the level 2, let call the activation threshold level 3
    3. connect a resistor temporary (via a rele') to give a load to the battery in order to measure the battery voltage with a load
    4. wait some time, at least an hour, from a disconnection before to consider a reconnection
  4. Battery discharged (transition from charged to discharged - level 2)
    The eRPOf will consider the battery as discharged with a voltage level little bit above the one used by the voltage detector.
    Thus the "level 2" is referring to this threshold.
    When this happens, eRPOf will issue a shutdown command to the Raspberry and when the Raspberry will be off, remove the power to the DC/DC.
    At this point eRPOf will determine if there are the conditions to re-apply the power to the Raspberry (see event 3)
One possible way thus is to have three threshold to determine the actions
  • level 1
    battery considered totally discharged, not good even to power up eRPOf
  • level 2
    battery discharged to power up the Raspberry but still OK to power eRPOf
  • level 3
    battery level to be considered as charged enough for eRPOf and Raspberry Pi

Next articles will discuss experiments and modifications of the design of the eRPOf.

Tuesday, April 11, 2017

Roomba 5xx and Err 5 charging

Yeah OK, is just "another post about the Error 5 when charging a Roomba of 5th generation", but is just a note/reminder.
The official suggestion from iRobot is to check the battery contacts, the base contacts and relative Roomba contacts.
If all is OK, then try to change battery and if still not OK, send the unit to repair.

The first thing to do however is to measure the voltage of the power supply.
After repairing a Roomba (a 560 unit) and changing battery, after few days the Err 5 started to appear.
Measured the power supply : 19V

It MUST be at least 22 V !!
Changed the power supply with a new one, and Err 5 disappeared.

Of course is possible to have many other causes for the error, but I would say that in order to diagnose it, the sequence that did the trick for me is :

  • check the power supply. The Voltage measure must be at least of 22 V
    if OK
  • try to use a power stabilizer or at least a surge control
    if OK
  • check the battery contacts and clean up from oxide and dirt
    if OK
  • change the battery
If OK but still Err 5, well, it "could be" also a motherboard problem.

So it seems now I have a nice iRobot power supply to repair :)

Tuesday, March 7, 2017

Office gadget - the Fhelper

Ok, this is just for fun.

In office we have a vase with a flower.
It is hard to remember to give water to the poor flower, so often the poor plant has to survive in a very dry environment.
We need something to remember us to give water to the plant.

The fHelper

Ok, there are already TONS of automatic gadgets to monitor if a flower needs water.
But the main purpose is to have fun to design something from scratch.
So here the fHelper (flower Helper).

The idea is to use a Raspberry Pi (possibly the 3 in order to have WiFi embedded, otherwise a USB WiFi dongle is needed) and the GrovePi system of sensors, to monitor the soil moist and somehow report/alert somebody about the need to water the poor plant.
To add more fun of course is possible to use the system also to gather other environmental values, interface with an IoT server, create graphs, etc.
Also it would be nice to have the project powered by the sun.


Here a shop list :


Here a list of functionalities of this gadget:

  • monitor the moisture level of the vase to determine if water is needed
  • monitor the temperature and humidity of the environment
  • monitor the amount of light
  • host a website that shows the number of time the plant is watered, how long remains without water and other amenities
  • send an email or a slack message to the people alerting when the plant needs water
  • collect in the cloud the data monitored

Assembly platform

Connect the GrovePi to the Raspberry Pi and then connect the moisture sensor, the humidity sensor and light sensor to it.
All the necessary hardware is hosted on a plexiglass support.

The Raspberry Pi with the GrovePi board will be placed on the top of the plexiglass, also to facilitate to have the moisture sensor close enough to the vase.

The fHelper close to the vase. In this early stage setting the Raspberry Pi is powered by a 10000mAh solar battery, however this battery can not be charged if is powering something. Thus a different design is necessary for the solar power aspect.
Note the Raspberry Pi on the top of the plexiglass.


The software is based on the GrovePi system from Dexter Industries.
Basically is a modified Raspbian version  with some libraries added to manage the the specific hardware.
This is because GrovePi adds also the analog capability to the Raspberry Pi.
Once the system is ready (follow the Dexter instructions) is possible to write programs in different languages to read the sensors.
For this project Python will be used.

The fHelper app needs to perform these operations in a cycle :

  • read the moisture level of the soil
  • read the temperature and humidity
  • read the amount of light
  • store in the cloud the data read
  • send messages via slack and/or email for specific events occurrence


The software part of the project is hosted on GitHub and for the moment is private.

Moisture sensor

For few months the moisture sensor was in place in the plant while running some tests.
It ended up badly, so it is necessary to rethink how to measure the humidity.
This project is quite interesting and will probably be adopted (for the moisture sensor).
A possible choice would be to buy this sensor and try to adapt it to the Grove system.

Stay tuned for updates

Monday, January 16, 2017

Energia and MSP430G2553

Recently I had a little bit more deep experience with Energia and the MSP430G2553.
Here some notes about this experience.

I did two projects so far using Energia and I have to say that a) I was able to do them really fast (well, the first one with a big start with the help of Roberto) and b) they are working surprisingly good.
For fast prototyping I would say that the MSP430 plus Energia is a good platform.
What is not good ?

Well,  is really missing a decent debugger.
I had some strange problems, like for example a restarting code without any clue about "why", or strange behavior events using the I2C on a MSP430G2452 (I solved that using the MSP430G2553).
Very very hard to figure it out these problems without any debug tool.

But also to test the logic of a sketch even a basic debugger would be a great thing.
The second big Cons of Energia is the needed memory.

It is mandatory to use chipset with at least 16K for very simple projects.
The second one I'm working on (I'll publish a separate article on that) already is over 12K and is far to be completed.
I'm sure I'll reach a point where I'll have to migrate on a bigger board, like the F2259.

Tuesday, January 3, 2017

SmartPhone audio accessory

Some notes about some audio accessories for smartphone.

Hype Retro Walkie Talkie handset

This funny toy is shaped like a traditional-style ham radio microphone.
The idea is to "transform" the smartphone into an Ham radio. For example, used with Zello can facilitate to use it in a mobile environment or for who is nostalgic about it.

I tested it on the Samsung tablet but is not working with Zello.
However is working with other applications. This suggests that there are other differences other the 3.5 mm jack pinout.

Let's open it up

The quality of the gadget is of course very low. Beside, for 5$ really is not expected to be better.

The gadget

To open it there are just four Philips screws

The little board has a small amplifier based probably on  a LM386.

There are two push button and a trimmer for the ON/OFF and volume setting.
The small push button on the top is the one that is used to start the conversation.
The big push button on the side simply mute the speaker (IMHO wrong  choice since normally the PTT button is on the side on a normal/standard mike).


The idea is to plug the mike in the smartphone audio jack and turn it on.
After that the audio output is redirected to the small speaker and when pressing the PTT button, the mike is activated.