Raspberry Pi LCD Backlight Issue

One of the cheapest ways of adding a basic display and keys to a Raspberry Pi is using one of the Adafruit clone 16x2 LCD with keypad "hat". This simple board consists of a 16x2 character LCD with 5 buttons all of which is driven through 2 main data lines facilitated with I2C and a MCP23017 (port expander).

16x2 Character LCD Hat with Buttons

Now, I bought one of these hats a while ago to play with and was quite impressed with its simplicity, however I did come across a "bug"/"limitation" in that the Adafruit Library did not cater for Back-light control. I did manage to alter the code to allow this functionality and all was well with the world.

In a recent project however in which I needed to setup 10pi's with display and buttons I found that no matter what I did I was unable to switch the Backlight off. Instead the backlight remained on and bright as long as power was supplied to the hat. After checking and rechecking my code I was forced to break out the soldering iron and start dismantelling the hat to get to the bottom of this mystery.

After probing around with a Multimeter and removing the LCD and the the backlight 1k ohm resister I finally arrived at a discovery:

LCD Issue

Can you spot the issue? Hidden away under the silkscreen of the 1k ohm resistor is a small trace that connects the Blacklight driving resistor to ground causing the LCD Backlight to remain on permanently.

The fix was simple, using a craft knife, slice away and break this connection:

LCD 16x2 Fixed

And viola, you can now control the Backlight again.

The one point to note though is that this must have been added as the adafruit libraries did not support backlight control and the manufacturer just thought it a pain to have people complaining about dimmly lit displays. To resolve this, this "bridge/connection" to ground forced the backlight to maximum brightness at all time. When cutting this away you are able to control the backlight but the "on" state the MCP is only able to sink current such that the backlight is at half the intensity as with the bridge.

Hope someone finds this useful!

Network Manager From Source on Raspberry Pi

I have compiled and installed many packages from source but I must admit Network Manager (NM) threw me a curved ball that had me debugging for 3 days.

My Pi 3 with stretch allowed for installation of the ver 1.6 line of NM through standard apt-get. However when using standard NM and Modem Manager (MM) on the pi, I faced an issue with connective. The modem would either not connect or disconnect a while after successful connection. I decided to update NM as a last resort as I was unable to pin point any issues.

Firstly there was alot of libxxx-dev packages that are prerequisites, some of which I maneged to pull from my history:

sudo apt-get install gtk-doc-tools autopoint intltool gio-unix libglib2.0-dev libdbus-1-dev libdbus-glib-1-dev libudev libudev-dev gobject-introspection gobject-introspection-dev libgirepository1.0-dev libnl-3-dev uuid-dev libnss3-dev ppp-dev libjansson-dev curl-dev libcurl4-openssl-dev libndp-dev libreadline-dev python-gobject-2-dev python-gobject-dev libnm-dev libnm-dev libmm-dev libmm-glib-dev

I then downloaded the source for the 1.8 line and followed the following process:

./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var -enable-wifi --enable-ppp --with-modem-manager-1
sudo make install

Once this was complete I finally have a working copy of NM on v1.8

A dive into MQTT


Its been awhile and that my fault, finding time and whatnot...

I have heard of MQTT and how it is a lightweight protocol that in/will revolutionize IoT communications and have recently had a use for such a mechanism.

I setup Mosquitto MQTT which is an open source MQTT server and it was pretty simple to start sending messages up to the server (called the MQTT broker) and between MQTT clients.

The issue I had was that all this information traversing through the broker was not recorded anywhere. This makes plotting historical data impossible. To achieve this functionality I wrote a crude (very crude) python script to persist MQTT messages to a mySQL database. The code for anyone interested will be located in my bitbucket account.

Arduino ESP8226-13 (ESP-13) By a Noob 4 a Noob

Arduino ESP8226-13 (ESP-13) By a Noob 4 a Noob

I have never needed to use WiFi in any of my projects thus far and I always assumed it would be pretty hard to integrate. I came across the ESP8226 very lately (2015) and after reading many online references I thought I'd give it a shot.

I purchased the latest and greatest ESP-13 for a few bucks($3) together with a FTDI ($2) off e-bay I had no idea why I needed the FTDI except that it was mentioned in quite a few online ESP tutorials.

For this topic, some background is required to set the scene.

FTDI What???

In order to communicate/program the ESP-13 module we need to be able to send serial communication from our PC to the ESP device. Future Technology Devices International (FTDI) is a company that makes USB->Serial ICs. One famous one that I have purchased is the FT232RL. (notice the 232 reference i.e from back in the RS232 days). The module that I purchased off e-bay allows our PCs to expose a serial port over USB and send serial communication to an external device on COM ports. (Side note, if you had a very old PC with a serial port you would not need this FTDI board). FTDI Board

ESP What???

Now to the magical ESP chip manufactured by Espressif Systems. The ESP8266 is a module that incorporates a Microcontroller IC and a Flash storage IC. The microcontroller is pretty sweet in that is operates in the 40 ->160MHz range and with the external flash you can have access to 2MB of storage.

So the ESP is a microcontroller with some storage... but how the heck do I use it?

Reminder that I'm a noob with regards to these ESP chips so this is my understanding.

The ESP-13 (or any other ESP module) can be run as is because it is has preset/preloaded WiFi software stack. what does this mean? It can detect//connect/transmit over WiFi using a few commands that it understands (AT commands). AT commands refer to the Hayes command set commonly used to communicate with modems. AT stands for ATtention. So by supplying the chip with power and setting a few configuration pins accordingly (as defined in the datasheet) you can effectively boot the device into a "slave mode" config. In this mode the RX/TX lines allow us to send and receive AT command and information between our PC and the ESP module.

Alternatively the ESP module can be used as a microcontroller that runs your code. Remember the microcontroller is used to facilitate the WiFi software stack but like any microcontroller has GPIO, PWM, ADC, UART, I2C, I2S, IRDA functionality. This means that you can write your own code and program it directly to this chip. (<--- I have not used this method yet)


The ESP-13 module that I bought has printed on it ESP_WROOM_02 this is t he datasheet that you will find on the Espressif site. To use this chip, I needed to solder (with great precision) a break out board to use it on breadboard. ESP-13 ESP-13 Bottom ESP-13 Soldering Adaptor Board ESP-13 Breakout 4 ESP-13 Breakout

To be continued...

Interfacing TL5955 Using Arduino

You know those YouTube videos that make you think "Awsome... I want one?" well check this reactive LED table out: YouTube LED Reactive Table

Now,... to build an improved version:


  • Multi Mode
    • Clock Mode showing digital clock
    • X&O Game
    • Snake Game
    • Sound Equalization's
    • Ping Pong Game
  • More LEDs!!!
  • Finer Resolution
  • Fade Effect, Variable brightness Control

Yes the list may be ambitious, but lets see how it goes.

First up, Based on my donor table I can accommodate 48x27 (1296!!!) White LEDs Driving this array will require some thinking. I stumbled across the [b]DADDY[/b] of all LED drivers made by TI the TLC5955. This bad boy can drive 48 LEDs using a single chip.

Hmmm... I have 27 Rows of 48 LEDs, I wonder if this one chip can be multiplexed to drive all 1296 LEDs! Let the games begin.

A breakout board was created as these (TLC5955) buggers only come in teeny tiny surface mount packages.

The TLC5955 is interfaced over serial communications, It has a single input register of 769 bits that must be written and latched.

If the MSB is 0 then the remaining bits are used to code the brightness of each LED using 2 Bytes (16bits) per LED. This means 0x0000 is off and 0xFFFF is full on.

If the MSB is 1 then when latched data is transferred to the "control" register, this needs to be done only once in most cases as this register sets global brightness and features.

Implementing the Arduino Code ( Why Arduino you ask?... because I got out voted by my team(I like PIC)): There exists a library for the TLC5940 that I tried to use initially but soon after abandoned that Idea for code from scratch, come on how hard can it be to write serial data?

Turns out there are multiple ways of achieving serial communications

  • Using the standard Serial.begin(); <-- maximum 115.2kHz
  • Using software based bit bang, toggling a digital pin <-- CPU intensive
  • Using SPI library on MOSI,MISO,SCK,SS pins <-- Can reach speeds of Fosc/2 (10Mhz for the ATmega2560)

It was easy enough to setup a new Arduino project that imported the SPI library. This can then be used to transfer data byte by byte. This was the problem... byte by byte? The guys over at TI have made my life hard by firstly not having a register that is a multiple of 8bits, forget that, each setting in the control data is either 3,5 or 7 bit combinations???

We therefore need a way to build up the bytes to be transferred. The register of 769 in code was increased to 776bits (97bytes) with the first byte 0000 000X where X is the control bit of the 769 bit register.

Using this method, the Control data was first written once on bootup followed by LED control data.

Now for the challenge... Can we multiplex this one IC to drive all 1296 LEDs? I got hold of a few 74HC595 serial in parallel out shift registers and have interfaced them to the arduino. each output of this shift register will enable a 48LED line therefore I need 4 of these ICs (8*4=32 >> 27).

That's as far as I have got for now.

SIM Cards, Silent but deadly

Ever give much thought to the little piece of plastic in your mobile phone? No? That's mostly because SIM cards are greatly misunderstood and perform their function extremely well. So what is it that I am getting at?

The SIM card is primarily your network identifier, it allows your device to identify and authorize itself on the home network. To do this it makes use of special security keys and algorithms. What you may not have known is that the SIM is the master of the phone, it has to possibility to dictate what the device should do.

The SIM can instruct the device to send an SMS, initiate a call, launch a web-browser, send a USSD, get network statistics including positional/location values and so much more. All this without user intervention or even consent!

Interested? In my proceeding posts I will dig further into how the mechanism around this work and how secure they may be.

Data-Whaaat? A Simple overview of Databases

I work in an environment where databases (DB) are a way of life yet many people fear the DB. This should not be the case, if you are using Oracle or mySQL the basics remain the same.

A database is a collection of objects not tables!

People immediately think about database as tables of data, this is not the full story. A database is a collection of objects, common object are tables, procedures, constraints, index's and jobs.

Objects are arranged/grouped in "schemas"!

^--get this and you are a database guru! A database has one or many schema's, a schema is normally associated with a user i.e you would log onto DBx.SchemaY where DBx is your main DB name and SchemaY is the name of a user. Within this SchemaY (or user) you have its associated objects(tables, procs ect. as mentioned above)

Each Schema is private!

The owner in possession of the schema password can "grant" other uses(i.e. their schema) access to his objects.


In 99% of cases anything before the where clause will not affect query speed! it is what comes [b]after[/b] the "where" clause that affects speed.

Raspberry PI + 3G Dongle

Oh the headache! I believe after a week of fiddling I've final got my head wrapped around this madness.

There are two primary issues that need to be taken care of when using a 3G dongle with a PI 1. A USB modem has schizophrenia! 2. Network connectivity is not "always" available.

So what do I mean "schizophrenia"? Simple, the modem actually wants to a usb cdrom/flash and assumes this personality by default in most cases. the command lsusb will list the current detected device. if it is not correct usb_mode_switch must be used to remind it that it should actually be a modem.

On point 2, sakis3g is a nifty tool to get you connected once you have figured out all of the "required" parameters. Its shortfall is that it never maintains the connection, i.e. if a connection is made and due to bad signal the connection is "lost" sakis3g runs like normal without ever telling you or attempting a reconnect. This is where UMTSkeeper comes in. This small yet feature packed tool maintains connectivity as well as logs network statistics! amongst other features that I have not played with.

Once you have all these 3 components working in harmony you should have a sweet "always" connected PI.