Intel Edison: Measuring USB voltage on breakout board

I have been trying out a variety of power sources. One is the 4xAA battery holder to female USB Verbatim 97928 available for about $10. It seems to have a well regulated 5.0 volt output.

edisonpower

The red arrow points to the side of the “74″ diode that comes right off the micro USB connector. I measured 5.00 Volts there with the Edison running on the Verbatim 97928. On the other side (downstream) of the diode I measured 4.72 Volts with the Edison idling. This voltage drop is expected due to the forward bias diode voltage drop.

Under 100% of one core CPU load, I measured 4.98V on the USB side, and 4.66V on the Edison side of this diode while powering from the USB port on the Verbatim 97928. The miniscule apparent 20mV voltage drop on the battery/USB side of the diode is likely to come from ohmic losses in the USB connector and cable.

Based on measurements of Intel Edison power consumption, and assuming 2000mAh, I estimate 10-12 hours of battery life on 4xAA alkaline batteries assuming continuous 100% CPU of one of the two CPU cores (other core idle). Normally the Edison will be mostly resting, drawing perhaps 100mW.

Thus with mixed use, I might expect to get up to 4-5 days of continuous mixed use operation on 4xAA batteries for the Intel Edison.

Miniconda Python on Intel Edison

Since the Intel Edison is a 32-bit CPU, we use the 32-bit version. But first, we need to install GNU Tar because Busybox tar doesn’t have some needed tar options, and it’s not compatible with GNU tar archives (!).

Since original writing, AlexT_Intel has put GNU tar in the opkg repository, so you can just do:

opkg install tar


wget ftp://ftp.gnu.org/gnu/tar/tar-latest.tar.gz
tar xvf tar*
cd tar*
export FORCE_UNSAFE_CONFIGURE=1
./configure
make

The ./configure takes almost a minute on a desktop PC, so it will take a few minutes on the Edison. Likewise for the make step.
You’ll see the tar binary at ~/tar-1.28/src/tar
nano ~/.bashrc
add the line
alias tar='/home/root/tar-1.28/src/tar'

Now let’s get Miniconda

wget http://repo.continuum.io/miniconda/Miniconda3-3.7.0-Linux-x86.sh

Finally run the install (all typed on one line)

BASH_ENV=/home/root/.bashrc bash Miniconda3-3.7.0-Linux-x86.sh

when install complete, since Edison normally uses Dash shell, we create

echo "export PATH=/home/root/miniconda3/bin:$PATH" >> ~/.profile

Then reopening a Terminal window to the Edison will show
python

Python 3.4.1 |Continuum Analytics, Inc.| (default, Sep 10 2014, 17:21:42)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux

And you can use all the very easy to use conda goodness of Miniconda to trivially install packages like Numpy, SciPy, OpenCV, etc. on the Intel Edison.

Example:

conda update conda
conda install numpy scipy astropy

Python logging module versions to disk

I run Python massively in parallel with GNU Parallel across numerous remote PCs. I want to have the version numbers of the Python modules I’m using logged to disk. Here’s how I do so for Python 2.7 and 3.4

Python using NaN or None as sentinel

Sometimes I was forced to use NaN as a sentinel value, for example with the current version of Numba that can’t handle “is not None”.

The summary is that comparing to None instead of NaN is over 100 times faster. This negates the advantage of Numba when you have to compare to sentinel values!

Here’s a test with Python 3.4:

$ ipython3
Python 3.4.0 (default, Apr 11 2014, 13:05:11)
IPython 2.3.0 -- An enhanced Interactive Python.
from numpy import isnan
%timeit ~isnan(0)
100000 loops, best of 3: 3.75 µs per loop
%timeit 0 is not None
10000000 loops, best of 3: 35.6 ns per loop

And Python 2.7

$ipython2
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
IPython 2.3.0 -- An enhanced Interactive Python.
%timeit ~isnan(0)
100000 loops, best of 3: 3.73 µs per loop
%timeit 0 is not None
10000000 loops, best of 3: 41.5 ns per loop

Travis CI SciPy requirements.txt

I have noticed that currently Travis CI has SciPy 0.9.0. That’s fine for most of my things (except savgol_filter which is new in 0.14.0)

When I put SciPy>=0.9.0 in requirements.txt, even though Travis gets SciPy 0.9.0 from
apt-get install scipy
Travis still tries to pip install SciPy latest version.

It’s been suggested by many to just use MiniConda with some boilerplate in .travis.yml. You can see what I’m currently using

Matplotlib ValueError on LogNorm plots

I was getting the error

ValueError: Data has no positive values, and therefore can not be log-scaled.

The issue is that I was setting vmin=0 in my pcolormesh() plot. By setting vmin=1 or some small positive value, your plots will work with norm=LogNorm() as expected.

Speed of Matlab vs. Python Numpy Numba

Here is a comparison on my Intel i7-2600 Sandy Bridge (3 year old) desktop PC.

Python 3.4.2, Anaconda 2.1, iPython 2.2.0, Numpy 1.8.2 with Intel MKL

import numpy as np
A = np.matrix(np.random.randn(5000,5000))
B = np.matrix(np.random.randn(5000,5000))
%timeit A*B
1 loops, best of 3: 2.51 s per loop

Matlab R2014b, also with Intel MKL
A = randn(5000,5000);
B = randn(5000,5000);
f = @() A*B;
timeit(f)
ans =
5.1059

So, Numpy is about twice as fast as Matlab at this matrix multiplication.
————————————————-
example 2: Using Numba in iterative algorithms.

Python
from numba import jit # inline auto compilation to C of Python code
from time import time
from numpy import diff
@jit
def f(): # declare a function
    x=0
    for i in range(int(1e7)): #generator much faster than arange here!
        x = 0.5*x + i % 10
tic = time()
f()
print('elapsed time (sec)',time()-tic)
elapsed time (sec) 0.07639932632446289

Matlab R2014b
tic, x = 0; for i = 0:1e7-1; x = 0.5*x + mod(i,10); end, toc
Elapsed time is 0.608442 seconds.

Python is 7.96 times faster than Matlab for this trivial test.
You can also find plenty of examples where Python is somewhat slower than Matlab. For me the places where Python was much faster seemed to very much outweigh the slower places.

Python: Numba 0.15.1 has bug regression: doesn’t like “is not”

Update: this has been patched I’m waiting for the next release of Numba after 0.15.1.

————-

In trying to write idiomatic Python, I use “None” like many people are taught to use NaN in languages such as Matlab–to indicate non-execution of command due to unused option or function result being undefined.

The current (0.15.1) verson of Numba does not understand the oft used phrase:

if x is not None:
    print('great work')

It gives the error:
numba.lowering.LoweringError: Failed at object mode backend
Internal error:
ValueError: 'is not' is not in list

You also can’t just say
if not x is None
You’ll get the same error. If you used the dis package maybe you’d see they evaluate the same way.

Another disallowed phrase is raise RuntimeError()
just use exit instead.

Instead I have to use NaN:

if not numpy.isnan(x):
    print('great work')

numba.bytecode.ByteCodeSupportError: does not support cellvars
can occur if you use default value e.g.
def blah(x,y=3)
or if you use nested functions.

you can see examples of this at:
https://github.com/scienceopen/numba-examples

Intel Edison vs. Raspberry Pi: OpenCV2

Using a proprietary algorithm for static image analysis on images, and running the algorithm repeatedly,

the Intel Edison is about 2.35 times FASTER than the Raspberry Pi, using only ONE of the TWO Intel Edison cores

Measured power consumption of Intel Edison

Using a multimeter and powering via J21 with a 9 Volt battery I measured:
booting up (peak): 984mW (8.2V * 120mA)
using Wifi 5GHz band (opkg update): 680mW (8.5V * 80mA)
typing text (using serial port): 346mW (8.65V * 40mA)
idle (serial port sleeps after a few seconds): 88mW (8.8V * 10mA)
powered off (LED is on adapter board): 45mW (8.9V * 5mA)

I don’t recommend powering the Edison with a 9-Volt battery, and my measurements were pretty casual. I was doing them quickly as there seems to be scarce measurements out there of the Intel Edison power draw. I did find someone else recently did benchmarks of Raspberry Pi vs. Beaglebone Black vs. Intel Edison.

I tried unplugging all USB and idle was still approx. 10mA.

The spec sheet shows the idle power with Wifi as 35mW, while my measurement is 88mW. I think likely sources for my “high” power reading are the two bright green LEDs on the USB adapter board, and the switching power conversion from 9V to 1.8V. I would expect the discrepancy to be less than observed, but my observation/measurement method may be faulty as well.

The fact remains that the Edison draws far less power at idle, perhaps 1/20 the power of the Raspberry Pi Model B at idle.