Arduino and H-Bridge ebay drivers

So I’m building a small 4WD robot, and bought two types of H-Bridge chips for controlling the DC motors. The robot has those standard yellow DC motors that are available at ebay, four of them total.

The H-Bridge drivers that I’ve bought are based on the L9110s/HG7881 chip, and the more potent L298N H-Bridge chip, both of the bought at eBay (one pair each).

To keep the post short, don’t waste your money on the L9110s/HG7881 chip for driving your robot motors. While the maximum current for the DC motors would be 200mA, a grand total of 400mA (two motors) for a 800mA per channel rated L9110s chip, the chip it just burned out under the load. Magic blue smoke indeed. While the L298n chip just went along, but it has a higher power rating also. The L9110s both burned the same channel, at different times, probably due to some variations of motor load.

The L9110s is probably fine for driving static motors, that bear no load, but for anything else I have my doubts.

Monit and KDE Desktop notifications

I’m running a Monit based monitoring solution, but I do not have an email server (that I can use), so when something goes wrong and Monit Alerts is raised, I have no way receive a notification that something is wrong.

So I built a quick notification system, done in Python, that when a Monit detects an error, it notifies me by activating a KDE Notification on my desktop…

The solution that I use is quite simple and quick (Warning it’s an hack…):

My solution uses a python based network server running on my desktop listening for messages, and a python client deployed on the Monit server that sends messages, when called.

In short, the running server on my KDE desktop waits for a connection on a specific port, and when one connection is established it reads any text that comes on the connection payload and displays it using the KDE notification system:

MonitServer.py

## Monit Desktop Notification Network server
import socket
import sys
import knotify
import dbus

## Constants definition
HOST = ''    # Host IP Address. Empty means that we are the host
PORT = 29876    # Listening port. Choose any above 1024. The client must use the same port...
ADDR = (HOST,PORT)
BUFSIZE = 4096

## Send notification for the KDE notification system
def notify(title, text):
   knotify = dbus.SessionBus().get_object("org.kde.knotify", "/Notify")
   knotify.event("warning", "kde", [], title, text, [], [], 0, 0,
   dbus_interface="org.kde.KNotify")

print 'Server Started'
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print 'Socket created'
# Bind socket to local host and port
try:
  s.bind((HOST, PORT))
except socket.error as msg:
    print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1]
    sys.exit()
print 'Socket bind complete'

#Start listening on socket
s.listen(10)
print 'Socket now listening'

#now keep talking with the client
while 1:
  #wait to accept a connection - blocking call
  conn, addr = s.accept()
  print 'Connected with ' + addr[0] + ':' + str(addr[1])
  # Read the message that comes from the monit server.
  data = conn.recv(1024)
  # Send the message to the KDE notification system
  notify("Monit Alarm!", data)

s.close()

At the Monit server, I placed the following files at the Monit bin directory: notify.py and notify.sh:

notify.py

from socket import *
import sys
from datetime import datetime

HOST = '192.168.1.200'       # My machine IP. Change to the IP where the NotifyServe.py is running
PORT = 29876       
ADDR = (HOST,PORT)

cli = socket( AF_INET,SOCK_STREAM)
cli.connect((ADDR))
print len(sys.argv)
if ( len(sys.argv) > 1 ):
  message = str(datetime.now().strftime('%Y-%m-%d %H:%M:%S')) + ": " + sys.argv[1]
  cli.send( message )
else:
  cli.send("Undefined Alert!")
cli.close()

Notify.py receives a message passed as a command line parameter and sends it to the NotifyServer running on the desktop machine.

The notify.sh shell script is a wrapper for the Monit server to call the monit.py script. Keep in mind that you must use absolute paths in every single file, otherwise it won’t work.

#!/bin/bash
/usr/bin/python2      /home/monitor/monit/bin/notify.py   $1

Now on the monitrc file we can change the alert lines from (for example):

check program System_status with path "/home/monitor/ShMonitor/SystemStatus.sh"
  if status !=0 then alert

to

check program System_status with path "/home/monitor/ShMonitor/SystemStatus.sh"
  if status !=0 for 15 cycles then exec "/home/monitor/monit/bin/notify.sh SystemStatus_Problem"

I added the for 15 cycles to avoid being flooded with notifications while I solve the issue… But it really depends of the monitoring pooling cycle. Adjust as required.

So, there it is, some code snippets gather across the web, allows me to have Monit notifications right at my desktop :)

 

 

 

Arch Linux and PyQwt installation

Some things that we take for granted on other distributions, seem to take a bit of work on Arch Linux. Basically is because that Arch Linux is more or less a bleeding edge distribution, and some packages lag behind in that continuous update cycle .

So I needed to use python to do some plotting with the QwtPlot widget available at the Qwt library. To use the Qwt widgets  from python, we need the Python bindings PyQwt.  The problem with this is that installing PyQwt from AUR uses the deprecated build system based on the configure.py script and the pqtconfig object that no longer exists on the most recent version of PyQT on Arch Linux.

So when we try to install PyQwt from Arch Linux AUR repository, the following error happens:

Requires at least PyQt-4.2 and its development tools.

An the installation fails. This is due to the missing pqtconfig python module. We can see that by running python and executing the following line:

import pyqtconfig as pyqtconfig

This error can be seen a fault of either: PyQwt hasn’t had no updates for the new PyQt releases, or PyQt, in it’s newest version, didn’t keep backward compatibility.

The fact is that it seems that is the PyQt package on Arch Linux that didn’t keep that backward compatibility, by dropping out the pqtconfig class/object on the package installation. Who knows…

This blog entry: http://vogelchr.blogspot.pt/2014/08/building-pyqwt-520-by-manually.html has the solution and it solves the issue with the PyQt package by installing the missing module.

Just build PyQT from sources, and at the end just copy the missing module.

  1. Download PyQt from http://www.riverbankcomputing.co.uk/software/pyqt/download
  2. Extract the package at a temporary directory
  3. Build it: python2 configure.py -v /usr/share/sip –qsci-api -q /usr/bin/qmake-qt4 
  4. Install the missing module: sudo install -m644 pyqtconfig.py /usr/lib/python2.7/site-packages/PyQt4/pyqtconfig.py

From that point, installing PyQwt from AUR works just fine.

Low cost Flex Sensor for Arduino, and others

One of the sensors that can be attached to an Arduino, or other platforms, is the flex sensor.

These sensors allow, for example, with the movement of hand fingers to control servos, and are, in many cases,  attached to glove fingers.

But these might be expensive, and there are several alternatives available on the internet to make our own flex sensors.

Well, this is my cheap alternative, and it works just fine.

The material needed to build this flex sensor is:

- An LED, 3mm preferably. Any colour will do.
– An LDR, or light dependent resistor. I’ve just picked the one that came with my Arduino ebay kit.
– Two resistors, one of 220 ohm for the LED and other, might be 10K, for the LDR.
– Some water gardening opaque tube (black), the thin ones used in automatic sprinkler systems, but for vases.

The idea is simple:

Cut the thin water gardening tube at length, for example of one finger.
At one end will be the LED, stuck inside the tube. Now the resistor can be soldered right at this point or at some other place, like a control board.

At the other end, the LDR is placed and taped out with some opaque adhesive tape.

So the schematic is the following:

flexsensor

Not shown is that the LED is at one end of the opaque tube, and the LDR is at the other end. Simpler and cheaper than this…

Now if we connect power, and a multimeter at Arduino A0 point and ground, by flexing the tube the light reaching the LDR varies, and so the tension value at this point also changes.

With a lot of flexing the voltages tends to 5V, in this case, and if the tube is completely straight the LED lights up the LDR more strongly and so the voltage at that point might end with a 2V.

By swapping the LDR with R2, then lower voltage is more flexing and more voltage is less flexing.

The 10K resistor might need to be adjusted in function of the LDR used. In my case it works fine.

And now it’s easy to use this cheap flex sensor. Just connect the “Arduino A0 port” point to one of the analogue inputs of your board, and normalize and use the values to control whatever you want.

For bonus points, the LED at the tip, is placed at tip of the fingers, and so it gives the glove a more “cyber-punk” look :)

Soldering station – Aoyue 9378

Being done with pencil type soldering irons (fixed temperature, no changing tips) that I use for my electronics projects, and unable to use my current (now old) solder iron, due to is larger tip, for precision work, I started to look for a replacement.

Everyone talks good about the Hakko 936, Hakko 888 and Wellers, but these in Europe/PT, without being Chinese counterfeit copies, are pretty expensive, (around 200€/250$ mark) and are only available in Ebay, or other online retail stores in China or HK.

At the end I’ve bought an Aoyue 9358 soldering station.

Why?

Overall I’ve seen that reviews available are positive (see Amazon, for example).

It uses Hakko tips, or compatible Hakko tips.

It is not expensive. Around 60€

Replacement parts are available, if any thing goes wrong.

So, the review:

Static analysis:

It come nicely packaged. The station is heavy due to it’s large transformer, and construction seems solid. It also came with a replacement ceramic heating element. Regarding the design, beauty is in the eye of the beholder, but I thinks is ok. Maybe the font for the Aoyue trademark, could be a bit more modern…

The soldering Iron is light, and, at least for me, ergonomic. a very nice improvement from my older soldering iron. The cable connecting from the iron to the station might be a bit short, but enough, at least for me.

It came also with a soldering iron stand and solder stand in aluminium, nicely made. The holder allows the soldering iron to seat nicely, and in my case it has space for those irons with fumes extraction.

The tip provided is a conic 1mm tip, not ten tips like US customers can get on their package.

When on, the digital panel glows red.

Dynamic analysis:

After powering up, it heats up fast. Around 10s/15s to reach the target temperature that can be set between 200ºC to 480ºC.

I’ve tested it with lead free solder (Iron temperature set at around 350ºC) and lead solder ( at around 280º/290º).

It seems to keep and maintain the temperature during heavy soldering. Had no trouble soldering out in sequence a lot of DIP packages and connectors.

The station also has a sleep feature that can be activated that puts the iron to sleep if not moved for a while. We can ear the sensor on the iron if shaking it.

So overall a nice station with a nice price.

Apache Axis deployment on WebLogic and RedHat

Deployed in an WebLogic application server, that is running on RedHat Linux machines, I have some Apache Axis web services deployed. Version 1.6 for the record…

The issue with this software combination, was that periodically people complained that the Axis web services stopped working, for no apparent reason….

Looking at the Axis and webservices log, it seemed that it complained that some directories and files that Axis needed for working are now missing from the /tmp directory:

java.io.FileNotFoundException: /tmp/axis2-tmp-1781229799800844743.tmp/axis23357234725283571419sler.jar (No such file or directory)

It was a fact that indeed the /tmp/axis* directories where all gone, but nobody has deleted them…

A temporary solution for this issue was (because it’s solved for good now) to redeploy the web services that had the issue.

But that doesn’t solve the mystery of why the /tmp directory had files cleaned…

Well it’s simple: RedHat has on /etc/cron.daily a script to check for files that are on /tmp and had no access for more than 720 hours.

This script tmpwatch, was the culprit of deleting axis files.

So there are two permanent solutions for this:

1st) Change/disable the tmpwatch script
2nd) Move Axis temporary files to another location

Because I’m not the machine administrator, but the Weblogic administrator, I’ve choosed 2) and added the following option to the server startup:

-Djava.io.tmpdir=/opt/axis-tmp

Restarted the servers, and allas: Axis temp files in /opt/axis-tmp

Problem solved.

Rising from the ashes: NSLU2

Despite having a Synology Diskstation DS212+ for storing my data (photos, videos and PC/laptop backups), I also backup that data to an external disk connected to my faithful Linksys NSLU2 bought in 2005 using rsync from the Diskstation.

The NSLU2 is flashed ith the openSlug 5.3Beta firmware since 2009 (when it came out), with the operating system installed in a crappy 2GB SD card.

But this weekend due to a power failure, the NSLU2 failed to boot up. It kept the amber led blinking signalling that it couldn’t forward from the initial stages of booting up.

Using my desktop computer, I’ve FSCK’ed the external disk filesystem, that had some inconsistencies, nothing serious (most of the time it is dormant), and FSCK’ed the SD card, and, well, most of the /etc and /var directory where gone.

Due to having a backup of the SD card (these things die…), I’ve recovered the /etc directory, but still the NSLU2 didn’t boot.

Booting up without SD card, the NSLU2 did finish booting up, but it wouldn’t ping, neither the original IP address (192.168.1.77) neither the configured IP address. All I had on my Linux machine was incomplete at the arp table…

nslu2 (191.168.1.32) at <incomplete> [ether] on enp4s0f2

Not good….

I’ve flashed it again with the openSlug firmare, but still I was unable to ssh to it so I could initialize. Because I was able to flash it again with the upslug2 tool, it mean that the ethernet port was ok, and probably everything was ok, except the NVRAM settings that define the ip address where pretty much corrupted… Let’s hope that.

So the solution was to boot into RedBoot and erase the NVRAM (http://www.nslu2-linux.org/wiki/HowTo/ResetSysConf) with the following command: fis erase -f 0x50040000 -l 0x20000  (Attention to this command!!!! Don’t get it wrong)

And then upgrade from the RedBoot interface. The original Linksys firmware was flashed and after rebooting this firmware initialized the NVRAM with default settings: IP address 192.168.1.77, and bingo, ping works, and I can access the original Linksys Web Interface. On the web interface I’ve configured the old IP address, DNS, host name, and so on, and rebooted.

After reseting the NVRAM from redboot you must install the original Linksys firmware, because the openSlug doesn’t initialize the NVRAM.

Everything was fine, and the NSLU2 was working on the new IP. From this point on I’ve just flashed again the openSlug firmware, and formatted the SD Card (turnup with the memstick otion), and configured everything again (crontab, ntpclient and rsync daemon).

In no time I had the Diskstation again backing up to the NSLU2 external disk.

So, welcome again NSLU2 :)