Video feed from the Pi(es)

I know I went silent for awhile.  New job and more.  Tons more.  I'm getting back to some of the projects, but I'm also taking on a new one.  I need to install some basic security cameras at a facility.  I'd prefer that they work using the network infrastructure (It's not a computing intensive location).  Really cheap IP cameras run around $70, and I'm not looking to pick up another maintenance hobby.

A Raspberry Pi runs $35, and the camera runs $25.  That's essentially an HD IP camera for $60 (I've got an insane number of power supplies lying around the house).  I also already own a Pi and camera to play with.

I bounced over to the Raspberry Pi foundation's website to see what they had to say about the camera.  They have some good tips on getting the camera installed.  However, I hit a couple of snags and couldn't get videos to stream over the network.  It was dinner time and I had to bounce out to have dinner with friends.

A couple of days later, I'm back, and searching around the internet.  I stumbled across Miguel's great post, and started learning a couple of things.  After a little bit of reading, I came across his updated post, which had EVERYTHING I needed to get the little computer streaming over the network.  I needed to do some apt-get update/upgrade between steps 6 and 7.  I also wrote a quick script to start the camera up:

mkdir /tmp/stream
raspistill --nopreview -w 960 -h 540 -q 80 -o /tmp/stream/pic.jpg -tl 10 -t 9999999 -th 0:0:0 &
LD_LIBRARY_PATH=/usr/local/lib mjpg_streamer -i "input_file.so -f /tmp/stream -n pic.jpg" -o "output_http.so -w /usr/local/www"

All this does is make sure the directory exists, then it creates a series of 960x540 JPEG's of quality 80 every 10 milliseconds for 9999999 seconds (I think it's seconds).  The "-th" is a thumbnail configuration, and the "&" tells this script to run in the background (I think).
The next part of the script is one that I'm not sure about.  It streams the JPEG, but I'm not completely sure I understand everything, yet.

I did mess around with the JPEG settings.  I selected the 960x540 image size because all of my monitors are 1080p, at least.  This way I can easily accommodate multiple streams on the same monitor.  I set the time lapse down to 10 milliseconds, but it didn't seem to increase the streamed frame rate.  I put quality at 80 because it was where I could read some text from across the room in my test image.  I finally messed around with all three of these settings to try to improve the frame rate, but with no real success.  It also appears that frame rate is impacted by the amount of light in the image (In theory this makes sense, but we should still be able to get decent lighting/shutter speed without sacrificing frame rates).

Great work, Miguel.  Thanks!

Preliminary Library for the ADXL345 in Python

The new code seems to be working.  I've ordered some more parts from online so that I can actually build these sensors into some real world rigs.

The new code is here, on the Adafruit site.
I'm going to try to keep the top post updated with the new code so people don't have to search through the comments (there aren't too many of them.  This went pretty quickly).  I'm going to try to make the code a little more functional, and include some of the other configuration options offered by the ADXL345.

Right now, the only thing that is really tested and seems to work well is the readAccel() function.  Calling this function will spit out the three accelerometer values (a raw number, not corrected with a gravity coefficient).  With my rig I've been able to get over 100 values per second (I think...  I can't find my scratch pad).
It spits out all three of the values because of the way the ADXL is designed to release data.  If you don't pull all three values, and instead just pull one, the ADXL "over-writes" the other two values in the stack with new data.  I figured it would be easier to just let the coder handle a couple of data values that they don't need, rather than give them an option that might give funky results later if they didn't dive deep into the datasheet.

I need to write my program for handling and graphing the data obtained by the ADXL345 for my project.  I'm probably going to have a buffer (of a user determined size) of values from the ADXL.  When the system detects an event it saves the buffer and continues writing readings until A) a specified amount of time or B) some sort of quiescent period is detected or C) an external "stop" signal is received.  I then want to output the data on a series of graphs showing the acceleration and combined vectors over time.  Again, this will probably be written in Python.  The mature version will hopefully use some sort of real-time display while recording the data.

The ADXL345, Python and Raspberry Pi

I'm working on logging data from the ADXL345 accelerometer for a DIY physics project for a friend of mine (OK, it's for me too because it involves fun physics).  I wasn't able to find a library for running the ADXL345 using Python, so I spent the day building one.

The code is over on Adafruit's forums, and it is very much a work in progress.  I'm reading data from the board and it looks like I'm able to set configuration options pretty easily.  Right now this is very much a hack in progress.  There are parts lying all over the floor, it isn't portable and it isn't easily used.

The problem is that the ADXL reports acceleration using two eight-bit values.  Here's the quick start sheet, here.
The first register uses all 8-bits to report data.  The second register uses four of the bits to report data, the other four are used to report the "sign" of the data (positive or negative).
I can't, for the life of me, figure out how to make this data usable, elegantly.

If it ain't broke...

I've spent weeks trying to figure out how I broke my Raspberry Pi.  Actually... How I broke two of them.

Well, I didn't actually break them.  Just the sensors attached to them.

Well, I didn't actually break them, it's just that they weren't reading correctly.

Here's the story:

I've been working on a couple of I2C sensors to tie into my Raspberry Pi.  The idea is to read the sensors at specific intervals, log the data, and then serve up some nice graphs.  I've been using the BMP085 temperature and pressure sensor, the TSL2561 light sensor, and the TMP102 temperature sensor (All those links go to the Adafruit forums specific to those sensors and the Raspberry Pi).

A group of us were collaborating on the TSL2561 (Hi, csalty!), when I upgraded to the newer version of Adafruit_I2C and the Adafruit_BMP085.  That's where everything went sideways.

I spent days looking at the datasheet and the Adafruit_BMP085 code.  Some of the stuff just doesn't make sense to me.  It doesn't make sense to the point that I wrote the devs saying "This is broken".

It's not, and that's pretty embarrassing.  It really looks like something in the Adafruit_I2C code changed how it pulls the information from the BMP085.  If you're looking for solutions, enable the debug mode, and check your calibration information.  Mine was VERY off using that version of Adafruit_I2C (Impossible temperatures and unstable in nature reading 200 degrees one minute negative 70 the next).  Once I switched some of the functions to the older version, things went well.  The kludge-version of Adafruit_I2C that I'm using is listed here: Modified Adafruit_I2C.py.

I also made a very specific change to the Adafruit_BMP085.py code.  I allowed the code to pass a specified bus number down the "stack" to the I2C code.  By default it does not specify a bus, and will allow the new I2C software to determine which version of the Raspberry Pi is being used, selecting the default GPIO header bus.  This way, all you have to do is call the BMP085.  It will fill in the default address, the default mode, and the default bus.  If you (like me) are using both I2C buses on your Raspberry Pi, then you MUST specify when you are using the "non-standard" bus.  The way the Adafruit_I2C.py code is written, it will only look for the version of the board and assign the "default" bus.  It has no way of knowing which bus you want to use.

I also set up the BMP085 code to pass the debug state down the code stack.  I figure if you're interested in debugging the BMP085, you're also going to be interested in debugging what is happening with the I2C code.  As part of the BMP085 calibration data, I also set it up to print out which I2C bus is being specified.

I need to make these changes to the TSL2561 code and the TMP102 code.  Both of these sensors appeared to be working just fine with the new Adafruit_I2C.py code (I've checked to make sure).

I've changed my project a little bit.  Now I'm running two parallel sets of sensors on the two different buses.  Each bus has a TSL2561 and a BMP085 sensor.  I'm logging the temperature, light level, and pressure every sixty seconds or so.  I'm manually able to generate all kinds of charts, but for right now I'm going to keep it manual.  I'll let the system run while I'm at work this week (four days), and if everything looks OK, I'll work on re-writing the webpage code.

Two I2C buses on the Raspberry Pi

I'm hoping this post can clear up some mis-information regarding the two I2C buses on the Raspberry Pi Model B rev 2.

In the upper left hand corner of the board you can see the GPIO header.  Below that is the P5 header footprint, a 2x4 series of vias.  You won't see the P5 label until you flip the board over.

Now, there are some folks that will tell you the only way to get to the second I2C bus is to access the camera S5 header (or the S2 header).  That would involve some incredible soldering work, or a socket.  I don't have the socket, and my hands aren't good enough to solder at that pitch.

However, I can solder that P5 header.  The unfortunate thing is that the P5 header is really close to the GPIO header.  Using the P5 header while using Lady Ada's Pi Cobbler header may be problematic.  I took some long headers and soldered them in place, at a slight angle.

I used a 2x5 socket on the header, and spaced it with a penny (between the 2x5 socket and the ribbon cable).

The process is actually pretty easy.  If you're a novice solderer you shouldn't be too daunted by this task.  Hey, the Pi itself is $35.  It's OK.

Once you get that done, you need to run some code.  I'll post the Python 3.x code in a bit.  Here's a link to the original code.  All that needs to be done for the Python 3.x code is to change the print statements to print() functions.  Here's the link to the RaspberryPi.org forums, where bgreat posted the code:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=33092

In hindsight, I should have looked at putting a 2x4 socket there.  I'm just not sure that I have any.

Parallelism in Hacking

I spent yesterday morning working on the datalogger, specifically making it WiFi capable.  This morning, I slept in, made my coffee and checked the news.  Over on Hackaday, Jose has created an Arduino/Pi/WiFi/X-Bee environmental monitor.  He's got his own webspace, uc4fun, where he's hosting the notes on his project.  A lot more professional looking than mine.

He's essentially doing my project (If he knows I exist, he's shaking his head saying "That guy's doing MY project").  However, he's doing it in a completely different fashion, which is awesome.  I think he's using a mix of I2C sensors (he's using the TMP102 and the BMP085) and a Sparkfun humidity sensor (Dude!  New Product Friday.... 'cuse me while I go browse...).

I think he went with the doubled up microprocessor approach because it allows him to use the ADC's on the Arduino.  So far, I've been severely limited in the sensors I can use on my build because I'm only using I2C and binary digital sensors.  His complexity gets him some serious advantages, but is also one of the main things I want to avoid (He's probably writing code for both the Arduino and the Pi.  That'll give me headaches).  I sent him a message on the Hackaday board asking why he made the choices he did.  Looking at his build and presentation, he's going to have some good answers.

I definitely wanted to avoid the multiple radio links.  Given my history with RF links, I'd like to keep that as simple as possible.