Beaglebone Bundle: BBB, Wireless Cape & Display - Review

Table of contents

RoadTest: Beaglebone Bundle: BBB, Wireless Cape & Display

Author: swr_dmaster

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: I have worked with the IFC6410 SBC, comparable in size and power. I've used one as a media server and for a self balancing robot. I would definitely choose the BBB over the IFC due to easy of use. The only reason I would choose the IFC is the onboard graphics processor allowing OpenCL; something the BBB is missing for the balancing robot project.

What were the biggest problems encountered?: I was provided 2 months which I whittled down to just my lunch hours at work when I'm in town. After the first month of dorking with the WiFi interface cape I decided I had to set it aside and proceed with the actual project.

Detailed Review:


Was surprised by the three glitzy boxes!

But the boxes quickly went by the wayside as they were not convenient to transport the project in.

I didn't need to record my first impressions as I was simply interested in learning how to use each part.

(Won't fill your screen with images of discarded boxes)



Scratching the Surface:

Have to start learning somewhere and the first place to start is usually the included documentation.


They have some but I wouldn't call it documentation.


The touchscreen was straight forward. Simply needed an image that had a gui and it was plug and play from there.

The BBB was going to take some startup and I knew it could be a rabbit hole if I let it (in a Good way)!

The WiFi's documentation is where things start getting rough.


For example: The WiFi Interface board states exactly which pins the shorting pins should be on.

The problem comes when you try to identify the pins they are talking about.

You can find them, no problem, but which are pins 1 and which are pins 3? There are no silk screens on the board and no notes on the instructions.

To add to the confusion the instructions have a picture with all the pins to one side but the cape comes with them all on the other.



Down the rabbit hole (Not in a good way):

With the WiFi not working my only thought was 'GET THE WIFI WORKING! I don't have an Ethernet cable that long.'

I reviewed tutorials, videos, tried different images, and even tried all the blog posts dealing with troubleshooting the problem.

I finally spent a week getting a Linux system installed with the SDK for WiLink8 as found here.

I followed each and every step all the way to booting off the uSD card with the image I had it initially compile.

Unfortunately I didn't have my RS232 to TTL converter handy (found at bottom of closet) and had to set the WiFi aside as a month had elapsed.


Above is the adapter I had misplaced during our last move.


Making Progress:

I had a few ESP8266 boards that I had yet to play with that I incorporated into this project.

I guess this is a good time to introduce the project. Lets formalize it!


The Project:

I proposed an HVAC control system. It would replace the standard thermostat and smart thermostats with a whole house solution.

By using the ESP8266 WiFi boards (basically an Arduino with wifi), servos, and IR Thermometers I could control air flow and room temperature by adjusting the dampers (Air registers).

Using a cell phone to indicate the user is warm or cold and which room they were in the system would adjust air flow to compensate.

I also proposed a future project using 3 WiFi hotspots to triangulate users and adjust automatically.

Though I did not complete the project Id did find that the 8266 could be used to capture packet headers and forward the MAC address & RSSI on to the BBB.


Project Start (one month in):

Decided to start at the actuator end of the project.

I started to dig into the least resistance way to program and 8266 and found the Arduino IDE.

Using tutorials on connecting, programming, connecting to an AP, moving a servo, talking I2C, and presenting a website I produced a simple website interface.

Since I move around I setup the 8266 to present a WiFi AP the preconfigured is not available. You can then connect and point it to a local AP and provide a password.


Once on the network the 8266 has over the air programming available. This means, as long as your code doesn't crash completely, you can reload without connecting via serial.

The page displays the current reading (the reading at the time of page load), gives the user the currently commanded servo position, and an entry box for commanding a new sero position.


And the code behind it's operation is attached.


Welcome to SVG:

So I was left at a loss for the best way to build a GUI without a viewer.

I had just gotten off a project where I build a view only report containing the current state of several points as well as a historic graph of an analog.

For the graph I had used SVG graphics and found them quite simple to use.

This pointed me to use the web browser as my viewer. Simply press F11 to maximize.


(Don't ask my why the image is sideways. You can thank element14's board for that.)

Using JavaScript inside the SVG document I was able to make a single SVG image the entire user interface.

The user can touch a room, highlighting it, then select whether they need it warmer or cooler.


By using SVG in a webpage this naturally extended the control to cell phones.



And even to the PC.


The JavaScript updates a box without fill over the clicked box and sends the server a message over Socket.IO when Warmer or Cooler is selected.

The JavaScript also 'Pings' the server once connected allowing the server to send all fresh values over Socket.IO for the JS to update the SVG with.


The Server:

The beaglebone black was very similar in programming as the 8266. I'm actually glad I started with the 8266 to get my feet wet.

I tried to start by ignoring the Cloud9 IDE and do everything straight c but quickly found the examples to be helpful.

Once I switched the IDE from single display to Side by Side while keeping live debugging (which I didn't have to setup!!) I fell in love!

Having server code on the left and the client/html/js on the right I could split out the issues based on location quickly.


The server is code that runs continuously on the BBB. It hosts the web server as well.

As clients connect and disconnect the server code is notified then opens & sends the HTML page needed to the client.

The server code is also running the Socket.IO server. This server allows near real time updates in both directions.

Any time the client connects to the Socket.IO server it sends a 'Ping.'

This ping tells the server to update the client with all the current values for temperature...but only to that client.

Once the code is complete it will also use the Socket.IO to send updates from the register temperature readings once they each come in.

This will also be done with Socket.IO but as a send to the server object and thus all connected clients as opposed to only on the socket object to a single client.

I had hopes, with the Gateway Cape, of auto finding new orphaned registers and auto-registering the registers (Yum! Mouthful!).

The 8266s, unfortunately, don't have a Socket.IO server library and can only be clients.

The next step I was working on was to get the 8266s to connect to the server in a separate Socket.IO room.

The room would allow me to handle the registers and the UI clients in separate event functions.


The Math:

This step is incomplete image

The math would take each of the temperature set points for each room and run a PID for each.

The PID is a math function that allows you to get a process value onto a set point by adjusting an actuator while observing the PID configuration values.

The values include Gain, Reset, Rate, DeadBand, Max output, Min output, and loop/cycle time (how often).

I would have to have cascade PIDs as when room after room gets to temp the registers will close.

Eventually you will get down to one or two rooms trying to close off. This isn't good as the fan still wants to move air.

This will mean we will have to raise all the Min outputs for all the PIDs as the sum of the PID outputs approaches some minimum setpoint.

To translate, as all the other rooms get to a decent level we start opening them as we close the remaining open registers a bit further to ensure sufficient air flow.

I was also going to work in a historic log such that the system can guess at what an ideal temp set point would be for the person in the room at the time with all the other rooms at the temperature they are at...etc.


The Results:

This board took everything I threw at it. I had a few issues at the start with a few versions which prevented either the touch screen, the I2C port, or the DIO from working.

The board boots reliable, never crashed and, despite throwing it around and not transporting it carefully, it hasn't become bricked.

I'm running it off a 5v 2a phone charger and it is happy with the low quality power. Need to test it running of my mower's alternator and a car phone charger (the ideas!).

The software is straight forward and the examples plentiful!


If the integration with Linux could stabilize such that everything doesn't fundamentally change between revisions then we could approach the topic of documentation.

As it is now I followed at least 8 different tutorials on editing the boot/uEnv.txt but each was different and none were like what I was seeing across multiple images; not that any two images looked the same either.

Once some fundamentals are understood, assuming the next version doesn't change where the boot folder is, you can make progress in initial setup.


I am loving the interface with the IDE and the built in debugger!

The IO seems robust and plentiful!

I just wish I had more of them to play with!

Too many projects for this one BBB to participate in!


The Spoils:



Top left is the carry-along case with the entire project. Included in the small cardboard box on the left are 4 more 8266 boards, 2 of which are 201s for potential registers.

Top right: From the 8266 I have 2 pins for the IR sensor and 1 pin for the servo. To be added are 3 pins for AC, Heat & Fan allowing any register to be the HVAC controller.

The protoboard contains level shifters, i2c shifters, and a 9 degree IMU for the balancing robot. Only used the 3.3v regulator, caps, and level shifter for serial off the protoboard.

Bottom left: I cut the end off a USB B cable and used it as my 5v supply.This fed 5v to the each servo, the BBB IR sensor, the BBB, & the 8266 w/ its IR sensor.

Included on it's protoboard is a PIC microcontroller with an I2C port and 2 serial ports. The serial ports are wired into opto-isolators and into a MAX233 chip bringing then TTL levels up to RS232 levels.

This board was built to allow the ICF6410 to talk I2C to 2 stepper controllers over RS232 which have a ground at a -48VDC to the IFC ground. Bumping -48 to +5 sounded good. image


Overall I'm a bit sorry I didn't purchase one sooner. Not that the Beaglebone Black Wireless wasn't available a few years ago.

This is definitely going to be a goto board for future projects! The 8266s have their place but the BBB blows it out of the water!

I'm sure there are things I left out. Can't remember every detail. But the BBB isn't something you want to forget!


Many thanks to TI and the element14 team for producing and sharing these magnificent products!