PiBox 0.11.0 release

[Print This] By mjhammel ~ October 13th, 2016. Filed under: Linux, PiBox.

PiBox Media Center v0.11.0 Release


The PiBox Media Center v0.11.0 binary releases are now available for download.  This release represents the first public release that will be demo’d at this weeks Maker Faire in Colorado Springs.  It’s focus has been on performance, usability and developer functionality.

Additional Information

General Status

PiBox Media Center is a consumer oriented distributions for distributed media playback in travel trailers without Intern et connectivity. The UI is based on GTK+ with Cairo and the system runs on the Raspberry Pi optimized PiBox Developemen t Platform distribution.

Highlights for this release include

  • Support for Raspberry Pi Model 2
  • A new app: picam (webcam on the connected monitor)
  • Switched VideoLib database to JSON and added support for TV series
  • Video selection now includes poster and series artwork plus summaries
  • Video playback now supports both HDMI and analog audio
  • Major performance improvements in the video front end app and webcam playback
  • Made fbturbo the default X server
  • New functionality and JSON support to libpibox
  • Minor UI cleanup including dropping the X cursor
  • Added support for multicast registration of IoT devices along with REST interface definition
  • Major code cleanup of Pibox Network Config and associated libpnc.
  • Upgrades to latest upstream firmware
  • Verified compatibility with available upstream rootfs packages
  • Bump cross toolchain gcc to 4.8.5
  • Improved metabuild for opkgs
  • Improved cross-toolchain builds for all opkgs
  • Updates to piboxd server unit tests

PiBox Media Player’s can now perform better in video selections as long as the VideoLib app was used to reduce the size of poster art.

Full release notes can be found in the formal announcement.

Related posts

New PiBox web site and Meetup group

[Print This] By mjhammel ~ October 10th, 2016. Filed under: General.

miot-iconPiBox has a new project web site:  http://www.piboxproject.com.  I created this to help give the project a more professional appearance in order to entice new developers to the project.   The wiki remains the location of meaningful developer information.

And I created a Meetup group too:  http://www.meetup.com/PiBox-Embedded-Developers

My goal is to encourage the growth of the embedded Linux systems community here in Colorado Springs and Colorado in general.  PiBox is just a front door to that goal.  We’ll see where things go from here.

Related posts

PiBox @ CS Maker Faire, Oct 15th

[Print This] By mjhammel ~ October 4th, 2016. Filed under: General, Linux, Software Development, PiBox, Raspberry Pi.

miot-pibox-logo-2It’s official: PiBox will be at the Colorado Springs Maker Faire on October 15th. The Maker Faire will be held at Library 21c which is just North of the Northeast corner of the Chapel Hills Mall.  Last year saw around 6300 attendees and turnout is expected to be even better this year.

The goal for the PiBox booth will be to demo the current state of the project. discuss the PiBox philosophy of embedded system development, drum up interest in joining the project, see where people might take the platform and to promote the open source development style.  I’ll also show the PiBox player with mini-projector I use with our camping trailer.  I’ve created a project website but most of the content is still on the wiki.  I’ve also setup a Meetup group but haven’t decided if I’ll continue that due to the cost and the unknown interest level of the community.

I’m also hoping to gauge interest in helping younger people (or even old farts like myself) learn what real systems development means.  I’m finding it discouraging to see so much app development taught at universities.  Building apps is easy, by design.  Making systems to run apps on is hard.  But it doesn’t have to be.

The location of the PiBox booth in the library has not been set yet and may not be till the day of the event.  Updates will be posted if I hear anything sooner.

I hope to see everyone there!  Stop by and see what a Raspberry Pi can do with a custom Linux distribution!  Or just stop by and see what an old geek does with his spare time.  Or maybe just stop by to watch an episode of Jonny Quest or Robert X. Cringley’s Triumph of the Nerds!

If you have any questions about this, drop me a line.

Related posts

Why a Raspicam isn’t better than a USB webcam.

[Print This] By mjhammel ~ September 11th, 2016. Filed under: General, Linux, Software Development, Hardware, PiBox, Raspicam.

So here’s my use case:  I need a camera that is easily positioned away from the Raspberry Pi and can stream via mjpeg-streamer.  Not huge requirements.  Here is why the Raspicam doesn’t fit that use case.

I’ve received a camera with the wrong cable from a Chinese distributor via Amazon.  I discovered the cable was not reversed on the ends like it should be (the blue strip was on the same side on both ends).  So I ordered a new cable from Adafruit.com.  The new cable arrived on Friday and I installed it.  I built a new mjpeg-streamer with raspicamera support and installed it.  I updated my config.txt as required to enable the camera.

It still doesn’t work.  After a bit of research I can see no reason to want to use this camera unless you were trying to embed a camera in a box with the Pi.  I’m not trying to do that.  Let’s look at the reasons why you won’t want this camera vs a USB webcam.

  1. The cable:  It’s a ribbon cable that is stiff enough that the weight of the camera module isn’t enough to counter the cables desire to flip it out of position.  A USB cable is more forgiving and the USB cameras weight generally overrides the stiffness of the cable.  Bending the cable into submission is an option, but dangerous with ribbon cables.
  2. The connectors:  The ribbon cable connector is tricky to plug into the board compared to a USB camera.  The same connector has the same problem on the camera board.  Worse, the Sunny connector on the camera module (re: board) is so loose the camera pops out of it on the lightest touch – and you will touch it because the camera module is just a board.  It doesn’t have an enclosure by default.  I bought a tiny camera mount to set it up on my table but the camera had popped out of the Sunny connector while screwing the board to the mount and I didn’t notice it.
  3. The setup:  You have to enable the camera by changing the bootloader config.txt and rebooting.  To turn it on: change and reboot.  To disable it: change and reboot.   This matters because of the next issue.
  4. The power requirements:  the camera is power hungry, up to 300mA.  So you don’t want to leave it running (apparenty).  Not sure how this compares to a webcam. I do notice that starting the raspicam (even though it doesn’t work) causes the rainbow box (upper right in newer firmware) to show up, which says I have a voltage drop below 4.8V (so I’ve read). That doesn’t happen with a USB camera plugged into an external hub. And if disabling it is required to avoid power drain that would be a serious problem since it requires changes to the bootloader config and a reboot.  And you need to set aside at least 128M in the GPU.
  5. The sensitive nature:  According to forum posts, the board is finicky about shorting out.  Lots of talk about people frying the cameras.  I handle the Pi quite a bit and none have fried.  Why does a camera that costs about as much have more problems?  It shouldn’t.

I never got the camera working so couldn’t compare it’s quality against a USB web cam.  But I did get a USB webcam streaming 30fps on the pi TO the pi using mjpeg-streamer and omxplayer.   Given my work on PiBox infrastructure for adding apps, the USB camera was up and running in a couple of hours.  Works great.  Nearly no delay in playback.  Slight delay only if you stream to a remote player, and that can be attributed to network lag.  I haven’t even got the basic Raspicamera working much less integrated into PiBox after the same amount of time, though to be honest all I have to do is edit a config file to integrate it once it works.

Yes, this was an external USB hub with its own power supply.  Irrelevant.  The ease of setup and use of the web cam considering I already need the external hub (for USB media sticks for PiBox) means I’m better off with the USB webcam.

So I can see no reason to use the Raspicam.  At least not for my use case.

Related posts

ESP8266: its’ all about power

[Print This] By mjhammel ~ February 25th, 2016. Filed under: General, Software Development, Arduino.
Strangely, Amazon delivered the board on Sunday. But I'm not complaining.

Strangely, Amazon delivered the board on Sunday. But I’m not complaining.

Programming the ESP8266 is rather easy.  I’m using the Arduino libraries and the makeEspArduino build system because I like to use the command line, not IDEs.  Stock libraries provide everything you’d expect: Wifi setup, web servers, DNS support, etc.  There’s even a library that allows you to boot into the board as a WiFi access point with a web server to configure it to connect to your local network.  It’s a bit surprising what you can fit into 512k memory.

There are a lot of possibilities with this little board, especially the versions with more GPIO pins but even with just 1 available pin on the ESP-01 you could do some interesting things.  The key point is that is requires very little power to control some other device via wireless communications.

But power is exactly where I ran into a little problem.  Seems that the FTDI Basic board I’m using to program and power the ESP-01 has a weak voltage regulator.  It works fine for uploading new firmware.  You can see it working because both the ESP board and the FTDI board flash their LEDs while data is being trasferred.  The ESP has a bright blue LED that flashes during programming.  It also has a RED LED that shows power to the board. Both are brightly lit when I’m flashing new firmware to the ESP.

But after the program has been flashed to the board the board needs to be rebooted to run the new program.  On reboot the ESP power LED would go dim and the firmware wouldn’t work.  Subsequent boots behaved erratically.  The dim power LED was curious and my only clue.  A few queries on SparkFun’s IRC channel led me to an issue with the FTDI’s regulator.  Apparently the ESP is very picky about the 3.3V it needs to run.  So I needed to find a separate power supply.

ESP's power light goes dim if the power supply is too weak.

ESP’s power light goes dim if the power supply is too weak.

There a lot of ways to handle this problem.  One is to throw together a few discreet components.   A simpler solution is to find a ready made board.  It needs to accept 9v-12v, so that it can be used with the tons of wall wart plugs I have laying around.  Ideally it should plug right into the breadboard I’m using for this project.

I dug around and found the one shown here on Amazon.  It’s perfect for this project because it spans the bread board providing power and ground to both sides.  And it supports either 3.3.V (which the ESP board requires) or 5V based on a switch.  It has a power button so I can turn power on and off easily without pulling wires.  More importantly, I only had to move 1 wire from my previous setup in order to use it.  And it’s cheap.  Well, I mean inexpensive.  It’s actually a nice board.  I ordered two.

Amazon managed to ship this to me on a Sunday so I had it just a few days after placing the order.  Once I plugged the power board into the breadboard I was able to test new firmware uploads without issue.

In the future I plan to power the board with a battery.  But for development, this little power board will do just fine.

Related posts

udev rule for FTDIBasic from SparkFun

[Print This] By mjhammel ~ February 15th, 2016. Filed under: General, Linux, Fedora, Arduino.
The ESP8266 came with pins already soldered, so I needed to use a breadboard to connect it to the FTDI. It's ugly but it's just an experiment.

The ESP8266 came with pins already soldered, so I needed to use a breadboard to connect it to the FTDI. It’s ugly but it’s just an experiment.

I’ve been fiddling with an ESP8266 this week that is being powered by an FTDIBasic board from SparkFun.  The setup is simple enough and it’s easy enough to get a simple web server running on it but I don’t have a power switch so the whole thing is powered through the FTDI board.  When I unplug the FTDI from the USB hub and plug it back in I get a different ttyUSBx port under Linux.  That means whatever serial terminal I’m using (Arduino’s or Minicom, for example) has to change after I connect the power.  But I want to see whatever the ESP8266 prints immediately at boot.  There is no way to manually switch ports in the terminal fast enough for this.  The solution is to use the same ttyUSBx port every time.  The way to do that is with a simple udev rule.

First, let’s look at the rule:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
   GROUP="mjhammel", MODE="0660", SYMLINK+="ttyUSBFTDI"

This line (and that’s a single line, it’s just broken to make it readable on the web) is placed in a new file called /etc/udev/rules.d/99-usb-serial.rules.  You need root permission to do this.   With the file saved, I plug in the USB connector on the FTDI board to a USB port on a hub of my Linux (Fedora, in my case) computer.  Then I can check that it worked by listing out the ttyUSB ports.

$ ls -l /dev/ttyUSB*
crw-rw---- 1 root mjhammel 188, 0 Feb 15 14:26 /dev/ttyUSB0
lrwxrwxrwx 1 root root 7 Feb 15 14:26 /dev/ttyUSBFTDI -> ttyUSB0

What this rule did was tell udev to create the ttyUSBx port – in this case ttyUSB0 – with a group of mjhammel that has read and write permissions on it.  That group is the group I’m using for my user id.  The other thing it did was to create a symbolic link from it to a device called /dev/ttyUSBFTDI.  That means that no matter what real device is created when I plug in the FTDI board I’ll always have a link to it with the ttyUSBFTDI filename.  Now I don’t have to worry about which port is actually in use.  I can always use the symbolic link.

If this doesn’t work out of the box for you then you probably just need to find the right vendor and product IDs.  List out the devices on the USB hub.

$ lsusb
Bus 008 Device 011: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC


Look for the Future Technology Devices International (re: FTDI) entry.  The two 4-digit hex numbers next to ID are the vendor ID and the product ID, respectively.  Replace idVendor and idProduct in the rules file to match your setup.  Then save the file, unplug and replug the FTDI into the USB port and you’re done.

Note that this didn’t really solve my problem, since unplugging the FTDI will drop the port and minicom and the Arduino monitor drop connection to it and do not automatically reconnect.  But at least you don’t have change your settings to figure out which port to connect to the next time you open the serial console to the ESP8266.

Related posts

Streaming just got easier, with DLNA and Roku

[Print This] By mjhammel ~ January 9th, 2016. Filed under: General, Linux, Video, Movies, PiBox, Raspberry Pi.

PiBox was built as a proof of concept for a variety of purposes. One of those was to serve media in my trailer when we go camping.  I use omxplayer to play videos that are provided over SMB between a server and a player system.  That works okay but the front end is not particularly user friendly.  At least it’s not easy to browse videos – they’re currently in one long list.  It’s on my list to fix but who knows when I’ll get to tit.

Most of my Roku's are older models, but they support DLNA just fine.

Most of my Roku’s are older models, but they support DLNA just fine.

The other day I was reading some tech headlines for Linux and ran across mention of running minidlna on a Raspberry Pi.  I wasn’t familiar with minidlna, or ReadyMedia as it’s now known.  A little digging uncovered that it’s an open source version of a NetGear product for streaming media: movies, music and pictures.  It works by implementing DLNA compliant protocols, a specification designed just for media sharing.  I decided I’d try it out at home first.  To see how well it worked.

The project doesn’t have Fedora or CentOS packages but it does provide a statically linked binary.  I downloaded that and found it only required install of two files: the binary daemon and a configuration file.  The configuration file is short and well commented making it easy to setup.  It helped that I had a large collection of music and videos ripped.  So I installed the files and ran the daemon as my own user (not root).

Now I just needed some software player that could handle DLNA.  Fortunatley, I have a house full of Rokus.  There is a simple player app that supports DLNA.  I clicked on it and there was my server.  I drilled down a few folders and found my music and video.  Just like that.  In my many years of trying to stream media, that has got to be the simplest tool setup I’ve ever come across.

The bad news is that most of my 600+  movies are ripped as ISO images.  That was done to get the DVD navigation, jumping to chapters, etc.  Now I’ll have to re-rip them as MP4 or MKV since the Roku doesn’t play ISO images.

I also need to see how I can add movies posters.  While MP3’s have album art, the MP4’s appear to just have filenames.  Something tells me I can fix that.  I just need to find a way to use poster art where it currently exists.

What’s interesting with this is the possibility of streaming from PiBox using ReadyMedia to a Roku in my trailer.  The Roku has an HDMI output, which will support the pico projector we use to play movies on the side of the trailer.  The PiBox provides the wifi access point, so the Roku should work fine, I think.  I haven’t tried this, but it’s something now added to my todo list.  Since omxplayer doesn’t do dlna (that I know of), this may be an alternative to using PiBox with omxplayer for the player.

Related posts


[Print This] By mjhammel ~ December 27th, 2015. Filed under: Linux, Hardware, PiBox, Raspberry Pi, Arduino.

Front side of the PCB. The back side has labels for the components as well.

My first PCBs arrived in early December, but due to the holidays I haven’t done anything with them yet.  I just wanted to show what they look like.

There are 5 small boards attached to my PCB:

  1. An FTDI Basic from Sparkfun for connecting a USB cable to my Linux box for programming the microcontroller
  2. An Arduino Mini-Pro board
  3. A RTC clock board
  4. A tiny color display board
  5. An ESP8266 board

There is also a small USB connector for power.  I don’t have to use a real USB connector for this.  I just needed the power and ground points from a USB part for Fritzing to not complain about unclosed loops in the PCB layout.  I’ll wire this directly to a power converter that takes 110V input and drops it to 5V output.  That way I can use the same power input used for the outlets in this project to power the PCB (and relays, for that matter).

Not all of these have to be connected.  I could just use the pinouts for them and wire them manually.  For example, I’ll probably just add L-shaped male headers to the board for the FTDI Basic.  It doesn’t have to be installed for the board to work.

Related posts

Learning about power

[Print This] By mjhammel ~ December 24th, 2015. Filed under: General, Hardware, Holiday lighting, PiBox, Raspberry Pi, Arduino.

What do you get when an old software geek tries to learn about electricity?  The same thing you get when you teach a 5 year old not to put their hands on the red coils on the stove.  Experience through interactivity.  Today’s lesson:  fat wires vs thin wires.

I’ve been using small gauge wire to connect relays to outlets in my power controller project. I did this because I thought I needed thick wire to handle potentially large loads through the outlets.  I expected to have multiple lights and possibly multiple water pumps attached to each outlet.  Fatter wires are used for larger loads (ever seen thin wires on power poles?).  So I chose fat wires to connect the relays and outlets.  Wire thickness is measured as a gauge.  Fat wires have a smaller gauge, which means thin wires have a higher gauge.  Why?  Beats me.  That’s just the way it is.


This looks safe, doesn’t it?

The smaller gauge wires don’t fit in the screw-down holes for the relays on the Sainsmart board. I had to trim off some of the wire to make them fit cleanly.  But the relays only handle 10A max and the distance between the relays and the outlets is less than 6 inches.  I’m running standard 110V from the wall through the relays to the outlets. So how thick do these wires need to be?

After looking at an online wire capacity chart I realized I didn’t need the smaller gauge. I could use the larger 22 gauge wire (remember that larger gauge means thinner wire) for the very short runs between the relays and outlets. This is because if I take an average load per outlet of 6 lights averaging about 75 watts per bulb (remember this is lighting for my aquaponics at the moment) I find I’m only using 450 watts over the 110V power input. Using an online calculator I can see I’m only pulling about 4.1 amps. That’s far below the max for the relays and well within the safe limits listed in the Capacity Chart for 22 gauge wire. And this gets better if the lights are switched from high wattage incandescent bulbs to LEDs and CFLs, which most of them are now anyway.

So now I’ll be able to use thinner wire inside the enclosure, leaving more room for the relays and my custom boards.  But more importantly, I won’t have a bunch of frayed wires hanging out of the tie-downs to short out the whole thing.  And remember:  short-out is Latin for frying myself, because software guys are a danger themselves, their pets, their families and essentially entire neighborhoods when handling hardware.

And yet, I’m still doing it.  Go figure.

Related posts

Adruino updates: APC w/ESP8266 and OLED LCD

[Print This] By mjhammel ~ November 20th, 2015. Filed under: Arduino.

So my little aeroponics project is growing beyond its real needs, but once you start assembling legos it’s hard to stop.  I’ve added an ESP8266 for wireless connectivity and a really small OLED LCD display.  The latter will let me monitor the system without either serial (FTDI Basic) or wireless connected.


The breadboard really isn’t necessary at this point. The only thing it holds are the LED and its resistor plus Vcc and GND busses.

Fritzing made it easy to layout the prototype on a breadboard, though after working through cleanup of the schematic and the PCB I found some problems.  First, I intended to use a USB breakout board from SparkFun connected to some headers on the PCB.  But if you try to wire this in Fritzing the circuits are not closed at the headers and Fritzing gets confused.  Instead, I found a USB part (from SparkFun) in the Fritzing parts libraries that had through holes.   Through holes are important because I need to place some traces on the PCB on the bottom side of the board.  The USB  part had connectors that were labeled Vcc and Ground which allowed Fritzing to close circuits and allowed me to create traces the way I needed them.


The layout is about 8″ x 5″ which could be a bit pricey, not to mention difficult to fit in a decent sized enclosure. It will have to be scaled down.

The next problem came after the PCB was fully routed.  The size of the PCB makes it prohibitive to get made.  OSH Park charges about $5 per square inch.  With my PCB at 8.8 x 5.3 inches that cost for a small production run (3 boards) would have been around $200.  Not horrible but really, this is such a simple project why waste the money?

So now the plan is this:

  1. Remove the FTDI Basic. The Pro Mini just needs headers to connect the FTDI Basic.
  2. The OLED LCD doesn’t need to be on the PCB. It can be connected with wires. This will allow the display to be freely placed in the most appropriate location without respect to the positioning of the PCB.
  3. With these changes I should be able to mount the ESP8266 on the back of the PCB and
  4. move the TinyRTC and USB power to a second PCB, mounted vertically with spacers. That will reduce the costs of the PCBs significantly. In fact, I should be able to do the whole thing with perfboard.

So my cost goes next to nothing.  In the end I should have two perfboards mounted together with spacers with the LCD mounted on a third perfboard (or without possibly) on some user-facing wall of the enclosure.

I still haven’t gotten to the enclosure but that will come after I find out how big this thing will be.  I still have to add in the 4 channel relay board too, plus the wires connecting all the boards and the power outlets together.


Just posted this, then went back to review the layout in Fritzing.  I realized that the ruler part I used to measure the PCB had two sides: inches and cm.  Guess what idiot was reading the cm side?  Yeah.  That’s the guy.  So it looks like the whole design may fit completely on the perfboards.  The PCB would only be 3.3″ x 2″.  Much more affordable.

Just goes to show:  there is always one more thing to review….

Related posts