Battery power bank, WiFi USB stick, and thumb drive

I then turn away to motor-less small storage, a 32 Gigs USB thumb drive so I can move on to other concern: on-the-fly encryption. Hence, I follow instructions to install True Crypt on Raspberry Pi. After unpacking of wxWidgets-2.8.12.tar.gz and TrueCrypt 7.1a Source.tar.gz in place, putting header files from pkcs-11-cryptoki2.20, and then install libfuse-dev, the following make will require long time:

$ export PKCS11_INC=/usr/local/src/truecrypt/pkcs/
 
$ make NOGUI=1 WX_ROOT=/usr/src/wxWidgets wxbuild
Configuring wxWidgets library...
Building wxWidgets library...
/usr/src/wxWidgets/src/common/string.cpp:84:39: warning: ‘wxEmptyString’ initialized and declared ‘extern’ [enabled by default]

$ make NOGUI=1 WX_ROOT=/usr/src/wxWidgets wxbuild
Compiling Buffer.cpp
Compiling Exception.cpp
Compiling Event.cpp
...
../Crypto/Aeskey.c:527:25: warning: operation on ‘ss[7]’ may be undefined [-Wsequence-point]
../Crypto/Aeskey.c:527:25: warning: operation on ‘ss[7]’ may be undefined [-Wsequence-point]
../Crypto/Aeskey.c:527:25: warning: operation on ‘ss[7]’ may be undefined [-Wsequence-point]
...
Converting Language.xml
Compiling Resources.cpp
Linking truecrypt

I created the TrueCrypt volume separately via its desktop GUI with ext3 file system to then mount it in Pi to a configured Samba share. As pointed out in a post, the following changes are added to smb.conf

...
wins support = yes
...
[pitruecrypt]
   comment= Pi Truecrypt Volume
   path=<the mount path of the USB thumb drive TrueCrypt volume>
   browseable=Yes
   writeable=Yes
   only guest=no
   create mask=0777
   directory mask=0777
   public=no

and then user-password are entered via interactive command.

For mobility, I already had the Pi as WiFi access point using hostapd (check these steps) and power bank, so it’s now matter of performance. In the case of rsync, initial sync of some 1,500 items totaling in 1 Gig size elapses in approximately the same 12 minutes of time compared to one bulk file of the same size. Of course, over the next incremental sync, it only takes less than a minute for the thousand items to just update slight differences.

Security

Back to security, there surely risk by opening Samba share to mounted TrueCrypt volume. But, for me it would be practically manageable (cross my finger). There is more concern to the fate of TrueCrypt after it is being closed in such a weird way, given that last audit finds nothing severe. Anyway, I found brute force tool, but no critical attack exists currently, unless e.g. it stays powered on and mounted, the person gain physical access. Beats me again.

A matrix keypad instance is defined by:

1. Actual GPIO pins used forming the row and column of the m x n matrix
2. Individual character in-use as symbol for each button

Hence, I instantiate and call method like

...
QPad  = matrixQPi(keyPad=keyPad,row=row,col=col)
print QPad.scanQ()

to print the character being pressed. Some examples pushed to my github explains how the above keyPad, row, and col are defined to scan-read pressed button of 2×2, 2×3, and 4×3 matrix keypads (or have it 3×4 matrix keypads in other words).

Illustration of any m-by-n matrix: 4x3, 2x2, and 2x3 keypad with different button symbols & GPIO combinations

I used deprecated Wiring-Pi Python (they already moved to 2.x version) without problem. However, you’ll fail building from latest commit and must use combination of older commits as described by my updated part of an old-post. By the way, there’s I/O expander support for WiringPi2-Python which is good, considering:

GPIO is expensive and for the sake of a keypad, you should not spend all.

(A friend told me that once)

Now it’s almost automatically attached as modem after insertion and people have been contributing to list of device-and-target device after mode-switching (find it as /usr/share/usb_modeswitch/configPack.tar.gz). At least for Raspberry Pi (RPi), I have one device list from August 2012 when playing around with XBian 0.8.3 and one from May 2012 in when using Raspbian Wheezy (2012-08-16).

Huawei E220 requires no mode-switch from vendor-product ID 12d1:1003 to function as modem

There is still wrapper for udev in /lib/udev/rules.d/40-usb_modeswitch.rule and my Huawei E153 HSDPA stick recognized and switched successfully as shown:

usb_modeswitch: switching device 12d1:1446 on 001/005
...
logger: usb_modeswitch: switched to 12d1:14ac on 001/006

But I didn’t get there in the first place. Because of USB power problem (detailed in previous post), I used to plug USB devices before powering up so that I could use Y-cable injected by separate power source without powered USB-hub. It turned out that if I had plugged the USB before powering up the RPi the mode-switching didn’t occur.

The HSDPA USB modem used is Huawei E153 appearing in lsusb with vendor-product ID 12d1:1446. Using aforementioned XBian and target device 12d1:140c (suggested in Santinoli’s post), I arbitrarily succeeded to switch to modem and dial internet with pppd.

[root]$ usb_modeswitch -v 12d1 -p 1446 -P 140c

(I placed Santinoli’s config in /etc/usb_modeswitch.conf)
This wasn’t stable however (also note that XBian consumed CPU above 50% for xbmc).

Later I find out that it will automatically switch to 12d1:14ac instead when plugged in after RPi is up. However, since it also won’t switch if plugged before power-up, I also try to mode-switch manually using config file found inside /usr/share/usb_modeswitch/configPack.tar.gz archive named 12d1:1446.

[root]$ usb_modeswitch -v 12d1 -p 1446 -c 12d1\:1446

It doesn’t seem to work. Modification to something close to my previous config also fails. Hence, consistent result only occurs if the stick is plugged in after RPi up. Then I decide to use USB-hub (also detailed in previous post) to tackle power issue (it will reboot anyway if you plug in without adequate powering). However, after successful mode-switch what’s being reported in eLinux Wiki often happens: it slows down, try lsub command for example.

Currently I give up the idea of using that modem and choose older Huawei E220:

1. No usb_modeswitch. Driver attached directly by the kernel as option.ko device (this device has been on the list for long)
2. Stable. No slowing down

The E153 modem itself has been implemented to stream video using the higher ARM type BeagleBoard-xM without significant stability issue (check my YouTube demo). It mode-switched when powering up Ubuntu on the Beagle.

Y-cable for USB modem stick & various current rating-AC power adapters for smartphone/tablet to go with Raspberry Pi

eLinux Wiki lists market available USB-hubs reported to work. A decent brand (that will cost you) qualifies:

• Doesn’t leak power back to RPi via USB port (check this by unplugging the main power, then check the red LED indicator) as this will interfere with the reboot command (physical state vs software).
• Provides charging from one of its port for RPi, meaning no separate source for the exclusive 700 mA requirement. A single AC power adapter with high current rating will fit all (check single power connectivity sketch in this blog post)

An ugly situation when I plugged in WiFi stick and modem looks like:

kernel: [ 1836.871640] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
...
kernel: [ 1803.780601] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x101c with error -110.

tail of the above syslog is saying error with the (1) ethernet (this is actually also a USB 2.0 but not appearing in lsusb command) and (2) the WiFi stick used (in this case with RT5370 chipset). Then, of course (3) doing things with the just plugged modem you’ll expect more instability.

I mentioned BeagleBoard-xM which also came with similar USB ethernet on-board. Unfortunately, Beagle was more stable when my case was to have it stream a zoom-camera input to internet (check my YouTube demo). The camera decoder and modem were both USB plugged without Y-cable or additional power supply. As a standalone system, part of the design was to reboot under trouble detected by the software. Again, OS command reboot is not achievable consistently with the RPi when power backfeeds through USB port.

(PS: Note that previous comparison solely points out what to expect when dealing with USB among other considerations e.g. price, different ARM, etc. which are entirely different.)

As an absolute requirement for me, I found a powered USB-hub available in Indonesian market as 7 ports XTec Go. Yes, it leaks power back as confirmed by the vendor-product ID 05e3:0608 of the chipset listed in eLinux Wiki lists with a bunch of different names (judging the picture, Hama is closest).

$ lsusb
...
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
...

Three Musketeers: powered USB-hub (Genesys chipset), Huawei E220 HSDPA modem, and TL-WN727N WiFi stick

My el cheapo USB-hub, HDSPA modem, and WiFi stick are the matchmaking of brands shown in the above image. It achieves long uptime like 6 hours serving internet when RPi used as router. I still use separate AC power adapter on the go with me: regular 700 mA that comes with smartphone will do for the RPi, while for the USB-hub, I have 2A rating from tablet charger. However, I’ve also plugged separate 500 mA charger for the hub without problem and/or excessive heat (you need to touch the supply sometime to feel any nasty heat as some of them might have been low quality build that could blow up. Yes it did). My plan with mobility is to have power bank with dual USB charging output (this Hame has 1A and 2.1A) when no AC source nears.

Have I tested other USB modem stick? Check my other post related to usb_modeswitch.

Updated: for those who fail to build using deprecated WiringPi-Python, check this updated post to know which commit that build without error. There is now also a Python class for matrix keypad.

My idea of having the keypad is to make alternative input available under no keyboard presence nor shell access. List of things I can think of for instances, pressed key “0″ will make the Raspberry Pi (RPi) dial GPRS to a specific ISP and act as router to the USB WiFi stick, pressed key “7″ will convert it to a router that will bridge the ethernet to WiFi, etc. In short, those key readings will invoke subsequent scripts to run inside RPi.

The physical connection schematic drawings and code are gitified (visit v1.2 of the project on gitHub). A nice animated image on how the buttons connect pins forming a matrix can be found in hackyourmind.org.

Matrix keypad: alternative quick input for Raspberry Pi to start certain command

Some remarks over what the code does:

• It only read one pressed key at a time.
• It uses no interrupt. To read input it must wait and scan (this waiting experience is by far negligible to human sense).
• Debouncing doesn’t seem necessary as WiringPi already provided this by software (I suppose this timing method on their gitHub deals with debounce).

How it works? RPi forum thread gives a general idea that applies in my case:

1. Divide the 3×4 matrix as columns and rows. 4 GPIO pins as rows are pulled-up with 10k resistors and initialized as input.
2. Other 3 GPIO pins as columns are initialized as output low.
3. First loop will scan for one pressed key being read as one of the rows pulled-low
4. After the loop breaks, all columns are set as input, then the row pin found in the loop is set as output-high
5. Second loop will scan for column being pulled-high by that row pin. Between both loops, it is assumed that the key press is still in effect. In reality, normal human act of pressing this key elapses long enough for the software to run the scans in two loops.
6. Bingo! The code reads row-column combination of the pressed key.

Example of the code’s output by calling from shell:

$ while true; do /usr/local/bin/matrixQPi.py -i; done
3
6
9
8
#
*

(In the above example ^C will throw Python KeyboardInterrupt messages before breaking the bash loop)

GPIO pin logic state (meaning voltage) are both programmable and driven by physical-connection. I choose wiringPi for practical reasons: availability of its Python wrapper and its simple syntax (glancing it at first sight). WiringPi has an option of using its own pin numbering to address it in the code instead of the original GPIO numbering (there are board revisions to watch for in some cases of usage, not mine). Every pin can be initialized as input or output.

Updated: Wiring-Pi Python is deprecated and moving to 2.x version that supports I/O expander. However, you can still find this combination of commits that will work and build without error message:

- main module: WiringPi-Python@9c77bde
- submodule: WiringPi@89bbe97

(Check how to build on my README)

Using an analog multitester, here are behavioral findings:

• GPIO pin voltage swings to high logic after reboot (the meter’s needle is rocking for a second or so). It is in low voltage afterward until being programmed or physically pulled-up.
• Two pins, wiringPi pin 8 and 9, remain in high logic voltage after reboot. They are SDA0 and SCL0 to be used as an I²C, however they can be used to read button as well. (eLinux Wiki: “there are 1.8 k pulls up resistors on the board for these pins”)
• I did short the high logic to ground accidentally, it invoked reboot. (I don’t know how many times or how long of this will brick the Raspberry Pi)

Prior to trying the push-button switch, I didn’t have proper circuitry and working with wires as probes, prone to accident that was. I found an advice to insulate the +5V pin voltage so I could worry less.

Insulate the +5V pin of Raspberry Pi

A 10k pull-up resistor and a button are enough to test the following. Go to interactive Python shell and run line by line until the button push is read as low logic (GPIO7 in this example):

# python
Python 2.7.3rc2 (default, May  6 2012, 20:02:25) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wiringpi
>>> import time
>>> INPUT=0
>>> OUTPUT=1
>>> HIGH=1
>>> LOW=0
>>> SETUP=wiringpi.wiringPiSetup()
>>> print SETUP
0
>>> wiringpi.pinMode(7,INPUT)
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
1
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
1
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
0
>>>

These basics convince me to go ahead with my goal of having a membrane (matrix) keypad as input for Raspberry Pi to run some script (see next post).

(Check also RPi common USB problems post)